Hopp til hovedinnhold

Jeg vil fortelle om reisen teamet mitt tok der vi gikk fra å jobbe output- til outcomefokusert.

Oppgaven var å lage et nytt system, slik at vi kunne fase ut det gamle.

En ny og en gammel pc

I det gamle systemet hadde vi veldig begrenset innsyn i bruken. Det var noe funksjonalitet vi visste vi måtte dekke, og andre ting vi var mer usikre på. Basert på dette ble det utarbeidet en liste med oppgaver vi skulle gjøre.

Målet var å gjøre så mye som mulig på kortest mulig tid. Vi skulle implementere det vi hadde planlagt av funksjonalitet og målte bruk i gammelt system mot det nye.

Vi jobbet jevnt med denne listen av oppgaver vi hadde sett for oss og etterhvert viste målingene at vi nærmet oss "ferdig".

Ma
Migrering av funksjonalitet over tid

Dialog med brukerne lærte oss at vi hadde prioritert feil

Når vi begynte å prate med brukere dukket det ofte opp problemstillinger som vi på teamet selv ikke hadde pratet om. Vi mistenkte at vi hadde oversett noe i planleggingen av det nye systemet.

Ute på besøk hos brukerne viste det seg at de var frustrerte over manglende funksjonalitet. Vi innså at listen av oppgaver vi hadde laget ikke viste hele bildet. I samtale med brukerne avdekket vi en dissonans mellom hva vi på teamet tenkte var viktig og hva brukerne våre var opptatt av.

Måloppnåelse handler om brukerne, ikke oppgaveprogresjon

For å skjønne hvor avhengige brukerne våre fortsatt var av det gamle systemet satt vi opp en måling. Resultatet overrasket oss.

Det viste seg at selv om vi hadde gjort over 90% av oppgavene vi hadde planlagt, så brukte fortsatt 75%(!) av brukerne våre det gamle systemet – daglig.

Det ble tydelig at vi ikke løste de viktigste problemene lenger, og vi endret hvordan måloppnåelse så ut for oss. Tidligere var målet nådd når alle oppgavene var implementert – nå var det når brukerne tok i bruk det nye systemet.

Denne endringen førte til at vi flyttet fokuset vårt bort fra antall fullførte oppgaver og heller mot å fokusere på ønsket utfall. I stedet for å gjøre antakelser om hva som var viktig hadde vi nå bevis og en kvantitativ måling på hva brukerne syntes var viktig.

Svar fra brukerne om hva som var viktig for dem
Svar fra brukerne rundt hva de brukte i gammelt system og dermed var viktig for oss å støtte i det nye

Disse målingene ga oss et utgangspunkt for å si noe om hva som var riktig problem for oss å fokusere på, for å påvirke flest mulig.

Det starter med et fokus på bruker

Heller enn å implementere funksjonalitet og si oss ferdig når det er ute, så er nå målet vårt å skape en effekt for bruker. Utfallet vi fokuserer på er at det som lages gir verdi for bruker. I vårt tilfelle – om det tas i bruk i dette nye systemet i stedet for det gamle, og viktigst av alt at bruken av det gamle systemet går ned.

At vi har laget noe vi tror løser et problem betyr ingenting. Om det vi gjør ikke fører til ønsket effekt har vi heller ikke oppnådd målet. Da må vi lære av feilen vi gjorde, gjøre nye antakelser om hva som vil føre til ønsket utfall og prøve igjen.

Tidligere fokuserte vi på output – hva vi skulle lage. Nå prøver vi å fokusere på outcome – hva det vi lager fører til av effekt. Når vi prater om veien videre bør vi ikke snakke om hva vi skal gjøre, men hva vi ønsker å oppnå.

Liker du innlegget?

Del gjerne med kollegaer og venner