Hvordan gjør man de tøffe prioriteringene?

Vi har nettopp lagt det gamle fiskale året bakk oss og mange avdelinger og bedrifter sitter med revisjon av sitt strategiske målbilde eller produktveikart. Det er mange ønsker og listene blir fort lange: de fylles med nye ideer, gamle utsatte initiativer og gjerne noen eksperimenter som fort kan anses som risikofylte, men veldig spennende.

Å prioritere blant disse er ofte krevende. Enda mer krevende for en arbeidsgruppe er å komme til konsensus på hva som skal gjøres først og hva skal utsettes til senere. Pareto-prinsippet sier at omtrent 80% av effektene kommer fra 20% av årsakene. Sagt på en annen måte: 80% av selskapets eller prosjektets fordeler kommer fra 20% av tiden de ansatte bruker. I smidig produktutvikling, vil den samme regelen bety at omtrent 80% av verdien kommer fra 20% av produktkøen. Men hvordan kan man enklere prioritere hvilke oppgaver som må inngå i denne “magiske 20%” og med dette oppnå større gevinster. Jeg ønsker å vise dere enkelte teknikker som kan hjelpe dere å gjøre denne prosessen mer effektiv.

100-dollar Test

Testen med 100 dollar, som en metode for avstemming, er en ganske enkel og grei teknikk. Først er det viktig å samle teamet i en prioriteringsøkt og lage en liste over oppgaver som skal prioriteres. Alle deltakerne får en begrenset mengde lekepenger (vanligvis 100 dollar, eller 500 kroner e.l..). Hver av dem skal fordele beløpet på de gitte alternativene (leveransene, brukerhistorier, oppgaver, krav, prosjekter). Etter det kan dere summere opp de totale poengene for hvert alternativ og prioritere dem deretter.

MoSCoW Analysis

MoSCoW analyse er velkjent metode for prioritering som kan brukes i mange ulike sammenhenger. Bokstavene står for: Must have, Should have, Could have, Won’t have this time. Først samler man teamet i en prioriteringsøkt og lager en liste over alternativer. Deretter må oppgavene sorteres i ulike kolonner basert på følgende kriterier:

Must have

Ingen vits å levere uten dette.
Leveransen er ikke lovlig /forsvarlig uten dette.
Leveransen er ikke levedyktig.

Still spørsmålet «hva skjer hvis dette kravet ikke blir oppfylt?» Hvis svaret er «avbryt hele leveransen», så nytter det ikke å starte arbeidet på noe som ikke oppfyller dette kravet.

Should have

Viktig, men ikke essensielt
Kan være ugunstig å utelate, men leveransen er fortsatt levedyktig
Kan trenge en slags workaround, f.eks. forventningsstyring, det kan forventes noe ineffektivitet, papirarbeid osv. Workaround kan være midlertidig.

En måte å skille et «should have» fra en «could have», er å gjennomgå graden av smerte forårsaket av at kravet ikke blir oppfylt, målt i forretningsverdi eller antall berørte personer.

Could have

Ønsket, men mindre viktig
Mindre innvirkning hvis det blir utelatt (sammenlignet med en «should have»)

Når et problem oppstår og fristene er i fare, så er «could have’s» førstevalget hvis noe skal fjernes fra listen.

Won’t have this time

Dette er ting som gruppen har avtalt ikke vil bli levert (som en del av denne leveransen). De er viktige å dokumentere, siden de hjelper å tydeligjøre omfanget og avgrensningene av leveransen. Slik unngår vi også at de blir introdusert eller «snik-innført» på et senere tidspunkt. Dette hjelper også til å styre forventningene.Enkelte oppgaver blir rett og slett ikke med. «Won’t Haves» kan være veldig kraftfulle når det gjelder å holde fokus på hva som faktisk er viktig.

Priority Poker

Priority poker er et raskt og enkelt spill for å prioritere oppgaver i leveransen. Det kalles det fordi det er veldig likt «planning poker» (en teknikk for å estimere brukerhistoriene som ofte brukes i smidige utviklingsprosjekter).

Før fasilitator av workshopen starter, samler han alle team medlemmene som trenger å være involvert i prioriteringsprosessen. Moderatoren må også utarbeide en liste over oppgaver som skal prioriteres, og et sett med prioritetskort som skal gis til hver spiller. Antall kort i dette settet avhenger av hvor mange prioritetsnivåer som er nyttige å bruke i dette tilfellet. Ofte kan man benytte en 5-punkts skala (f.eks. Veldig høy prioritet, høy prioritet, middels prioritet, lav prioritet, veldig lav prioritet), men dette kan man tilpasse etter behov. Antall kort tilsvarer tallene på skalaen. Deretter leser moderatoren opp navn på oppgave som skal prioriteres. Hver deltaker velger kortet de synes er den mest hensiktsmessige rangeringen for den oppgaven, og legger kortet med forsiden ned på bordet. Når alle deltakerne har tatt sitt valg, blir alle kortene snudd samtidig. Forskjellene blir diskutert og spillet fortsetter til estimatene er rundt samme nivå. Hvis det er sterke uenigheter i gruppen om hvordan et oppgave skal prioriteres, kan den som ga den høyeste poengsum, og den som ga laveste, forklare hvorfor de mener dette skal prioriteres ned eller opp. Så gjentar man poenggivning etter disse forklaringene er gitt. Slik fasiliterer man dialog og skaper felles forståelse for eventuelle utfordringer.

Dette var et innspill i noen øvelser som har hjulpet meg mange ganger, og som er svært anvendelige når man trenger å gjøre noen tøffe prioriteringer. Håper dere finner innlegget nyttig. Kom gjerne med innspill, kommentarer og tips til hvordan vi kan jobbe bedre i team.

Kilder: https://www.agilebusiness.org/page/ProjectFramework_10_MoSCoWPrioritisation https://www.amazon.com/Managing-Software-Requirements-Case-Approach/dp/032112247X https://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415 https://www.sixsigmadaily.com/remembering-joseph-juran-quality-improvement/

‍