Noe av det vanskeligste for ledere og prosjektledere er å prioritere. Dette gjelder både for linjeoppgaver, i smidige leveranser og i prosjekter. Det vil alltid være mange ønsker og meninger fra ulike hold, og det gjelder å holde hodet kaldt og få et overblikk over hva som er viktigst for virksomheten, prosjektet eller produktet, kunden og sluttbrukeren.
Virksomheter som tar hensyn til kundenes krav, ønsker og prioriteringer i et prosjekt eller i utviklingen av et produkt, er betydelig bedre og mer lønnsomme enn de som ikke gjør det. De som også forstår prioriteringene sine og evner å sette dem i riktig rekkefølge etter hvor viktige de er for prosjektet, er enda bedre. Et godt hjelpemiddel for å gjøre prioriteringer er metoden MoSCoW.
I dette blogginnlegget skal vi se nærmere på hvordan man kan bruke MoSCoW-metoden for å prioritere mellom ulike krav og oppgaver i et prosjekt.
Hva er MoSCoW?
MoSCoW er en prioriteringsmetode som ofte blir brukt innenfor ledelse, prosjektledelse, virksomhetsanalyse og spesielt i smidige team. Metoden gjør det enklere å skape en felles forståelse og bruke tilgjengelige ressurser på det som faktisk er viktigst.
MoSCoW ble oppfunnet av Oracle-ansatt Dai Clegg i 1994. Selv om metoden ofte blir brukt for å prioritere mellom ulike krav fra kunder i prosjekter så er den like godt egnet til oppgaver som går inn under den daglige driften av en virksomhet eller i team som driver med kontinuerlig utvikling.
MoSCoW-metoden brukes ofte i forbindelse med et DSDM-prosjekt, som står for Dynamic System Development Method. Et prinsipp i DSDM som brukes i forbindelse med MoSCoW er Timeboxing. Det innebærer at man deler opp prosjektet i trinn, hvor hver del får et eget budsjett og en tidsramme. Innenfor hver fase må det prioriteres hva som skal løses. Slik kan også prioritering foregå fasevis eller man kan avgjøre hvorvidt et krav skal tas helt ut av prosjektet.
MoSCoW-analyse er en effektiv teknikk når man har behov for å se sammenhengen mellom krav og prioriteringer. Den inneholder tre tydelige prioritetsnivåer, men dekker også kravene som til slutt ikke vil bli inkludert i den nåværende leveransen.
MoSCoW er et akronym for fire prioriterings-kategorier og står for:
- Must have - (må ha)
- Should have - (børe ha)
- Could have - (kunne ha)
- Won’t have - (vil ikke ha)
På norsk brukes gjerne akronymet MåSKVa. MoSCoW fungerer godt fordi modellen skaper en felles forståelse på hvorfor de ulike kravene må inkluderes eller ekskluderes og prioriteringen av rekkefølgen av disse blir tydelig for alle i teamet.
M – Must have (må ha)
Must have-kriteriet representer de oppgavene eller kravene som prosjektet ikke kan leveres uten. Dette kalles gjerne Minimum Usable Subset og bør ikke bestå av mer enn 60 prosent av det totale omfanget. En «must have»-oppgave skal være så viktig at dersom man fjerner en slik oppgave vil det være meningsløst å levere prosjektet eller produktet. For eksempel hvis du skal lage en ny webside til en kunde så kan du ikke levere det uten en navigasjon for websiden. En grei måte å få sjekket kriterier inn og ut av Must have-kategorien er å stille seg spørsmålet; Hvis denne oppgaven eller kravet ikke kommer med – kommer vi oss videre da? Hvis svaret er nei, så er oppgavene en Must have. Hvis man kommer videre uten denne oppgaven eller kravet, da har man kanskje funnet en Should have eller Could have.
S – Should have (bør ha)
Det neste kriteriet, Should have, representer det som er viktig, men ikke essensielt. Å ekskludere oppgaver eller krav her er ikke avgjørende for prosjektresultatet eller produktets levedyktighet, men kan kreve noe omarbeid som for eksempel å styre forventinger eller enn manuell løsning. Dette kan være en midlertidig løsning, men Should have-oppgavene kan bli utviklet senere. Om prosjektet har tilgjengelig ressurser, og det ikke går i veien for et Must have-krav som finnes, så burde disse kravene leveres eller inngå i omfanget som prioriteres.
C – Could have (kunne ha)
Could have er et krav som er ønskelig, men mindre viktig og som har en mindre innvirkning på prosjektet eller sluttproduktet. En måte å differensiere mellom disse er å se på hvilken verdi det tilfører sluttproduktet eller gevinstrealisering av prosjektet. Det kan også være lurt å prioritere ut fra størrelsen på gruppen som denne oppgaven eller denne prioriteringen berører. Jo større innvirkning det har, jo mer sannsynlig er det at kravet burde være en Should have. I et beste fall vil man være i stand til å levere alt som ligger under Could haves. Hvis det dukker opp problemer eller man står i fare for å ikke nå en tidsfrist så kan en eller flere av oppgavene som i utgangspunktet er definert som en Could have bli droppet for å nå tidsfristen. Oppgaver som ligger under dette kriteriet bør ikke representere mer enn 20 prosent av det totale omfanget.
W – Won’t have (vil ikke ha)
I et hvilket som helst prosjekt, vil et team være enige om at det er visse oppgaver eller krav som det ikke er mulig eller nødvendig å levere. Dette er Won’t have-krav som ikke vil bli inkludert akkurat nå, men som man kanskje ønsker å implementere på et senere tidspunkt.
Disse bør loggføres i en Prioritized Requriements List (PRL) slik at man får en god oversikt over omfanget av prosjektet og at det blir enklere å eventuelt ta inn oppgaven eller kravet senere. Dette gjør det også lettere å styre forventinger til hvilke krav som vil være med når prosjektet eller produktet er ferdig.
Ved å ekskludere det som ikke kan implementeres akkurat nå, blir det tydeligere hvilke oppgaver og krav fokuset bør være på.
Gjør det enklere å prioritere rett
MoSCoW er en enkel og effektiv måte å prioritere arbeid på. Ved å fokusere på de viktigste oppgavene først så vil hovedkomponentene av prosjektet bli ferdig raskere, og man kan eventuelt legge til det som er mindre viktig senere. Metoden bidrar til å sikre en felles forståelse for prosjektet slik at alle vet hva som jobbes med, og hvorfor akkurat den oppgaven eller det kravet ble prioritert først.
Å bruke MoSCoW betyr også at både kunde- og prosjektgruppen kan bestemme at noen oppgaver eller krav ikke bør være med i prosjektet i det hele tatt. Det bidrar til å man får luket ut unødvendige deler tidlig og at man holder ting smidig og enkelt. MoSCoW er en av aspektene ved smidige leveranser som hjelper teamet med å minimere bortkastet tid, krefter, ressurser og penger.
I AgileSHIFT finnes det en egen mal for prioritering som er kompatibel med både MoSCoW-metoden og enkel numerisk prioritering. Du kan lese mer om maler og agendaer for smidige sprinter med AgileSHIFT her.
