Något av det svåraste för en ledare och projektledare kan vara att lära sig hur man ska prioritera inom organisationen.
Det kan finnas krav och önskemål från alla möjliga håll och kanter, och det gäller som ledare att styra upp situationen och få kontroll över alla områden och vad som anses vara viktigast för både kunden och företaget.
Det är viktigt att förstå behovet som finns hos kunder eller användarna.
Vikten av att prioritera rätt
Företag som tar till sig sina kunders krav, önskemål och prioriteringar när de tillverkar och levererar sina produkter, är betydligt bättre och mer vinstbringande än de som inte gör detta.
Organisationer som förstår sina prioriteringar samt lägger dem i rätt ordning efter hur pass viktiga de är för själva genomförandet är ännu bättre. När ett företag har listat upp alla sina prioriteringar och krav är nästa steg att lägga dem i den ordningen utefter hur det ska genomföras.
Analysverktyg för prioritering – MoSCoW
Det gäller att använda de resurser som finns tillgängliga inom företaget på rätt sätt samt att lägga mest krut på det som är viktigast.
Varför ska man slösa tid och pengar på irrelevanta områden som inte fokuserar på det som är viktigt och som leder till vinst?
Det finns ett mycket bra verktyg för att få hjälp med att strukturera upp företagets prioriteringar och komma på rätt spår. Detta verktyg kallas för MoSCoW-metoden och grundades av en engelsman vid namn Dai Clegg under början av 1990-talet.
MoSCoW-metoden används idag av organisationer världen över inom området företagsanalys.
Vad är MoSCoW-metoden?
MoSCoW-metoden är ett prioriteringsverktyg som används inom företagsanalys, projektarbete samt inom ledningsarbete.
Metoden används inom dessa områden när du behöver visualisera och tydliggöra vilka områden och krav som ska prioriteras i vilken ordning för att kunden skall få ut det som de vill och behöver av projektet.
MoSCoW-metoden används ofta i samband med ett DSDM-projekt, vilket står för Dynamic System Development Method. Du kommer att kunna läsa mer om DSDM längre ned i artikeln. Många gånger används MoSCoW-modellen inom mjukvaruutveckling.
En MoSCoW-analys är en väldigt vanlig och effektiv teknik som används för att se sambandet mellan krav och prioriteringar. Detta på grund av att den innehåller tre mycket tydliga prioriteringsnivåer, men den täcker även de krav som i slutändan inte alls kommer att bli inkluderade i den nuvarande leveransen eller i projektet.
Detta fungerar mycket väl på grund av att modellen ger oss möjligheten att på ett tydligt sätt komma överens om de olika prioriteringar och krav som ska vara inkluderade eller exkluderade inför den kommande leveransen.
Själva ordet MoSCoW är en akronym och står för följande begrepp:
M – Must have (Måste ha)
“Must have”– punkter är de som anses vara obligatoriska krav för leveransen.
Dessa måste finnas där för att projektet ska kunna röra sig framåt över huvud taget.
Om man ställer sig frågan, ”Vad händer om X inte finns?”
och svaret då är ”Då kommer vi inte vidare alls”, då har man hittat en punkt som är Must have.
Men om det finns något sätt för att komma vidare utan denna X-punkt, då har man hittat en ”Should have”– punkt eller ”Could have”– punkt.
Att kategorisera ett krav som en Should have – eller Could have – punkt betyder inte att den inte kan levereras, utan endast att leverans inte är garanterad. Om man exempelvis arbetar med mjukvaruutveckling i ett så kallat DSDM-projekt finns det i ”The DSDM Atern Handbook” fyra olika kriterier för att identifiera ”Must have”- punkter:
1. Kan inte leverera på utsatt tid och datum utan detta.
2. Finns ingen mening med att leverera slutprodukt på utsatt tid och datum utan detta. Om detta inte går att leverera finns det helt enkelt ingen anledning till att visa upp lösningen på utsatt tid och datum.
3. Vi följer inte lagen utan att leverera detta.
4. En leverans utan denna punkt leder till en produkt som inte är säker att använda.
S – Should have (Borde ha)
“Should have”- punkter är de krav som borde ingå i projektet om det är möjligt. Om projektet har kapacitet och tid för detta och om det inte utmanar någon av de Must have- krav som finns, då borde dessa krav levereras eller ingå i prioriteringen inom det specifika området.
Should have- punkter och krav kan definieras som:
1. Viktiga men inte avgörande.
2. Kan vara smärtsamma att lämna utanför, men lösningen är fortfarande genomförbar.
3. Kan komma att kräva någon form av tillfällig lösning eller omväg så som att förändra förväntningarna, lite ineffektivitet, pappersarbete och så vidare. Denna lösning är ofta bara temporär.
Ett bra sätt för att skilja ett Should have-krav från ett Could have- krav är att titta på den andel smärta som grundar sig i att kravet inte kan uppfyllas. Då syftar man på företagets värde eller den andel människor som blir påverkade av denna avsaknad.
C – Could have (Kunde ha)
“Could have”– punkter är de krav som skulle kunna inkluderas så länge de inte påverkar några av Must have– eller Should have-kraven.
Detta är krav som hör till möjliga punkter att genomföra och dessa kommer endast att levereras i sin helhet i bästa möjliga scenario. Om ett problem uppstår som innebär att deadlinen är i fara, då är de en eller flera av dessa krav och punkter som man ska välja att först släppa taget om inom den existerande tidsramen.
Could have-punkter och krav kan definieras som:
1. Önskvärda men mindre viktiga.
2. Mindre påverkan på helheten om de utelämnas i jämförelse med att utelämna ett Should have-krav.
W – Wont have (Kommer inte att ha)
“Wont have”– punkter är de krav som tenderar till att inte bli inkluderade till leverans eller att bli implementerade just nu.
Men de är krav som man kan önska att implementera inför en framtida leverans.
Dessa är alltså de krav som projektteamet har kommit överens om inte ska levereras inom den aktuella tidsramen. Dessa sparas i den lista över prioriterade krav där de sedan kan hjälpa till att klargöra omfattningen av projektet. På detta sätt undviker man att de här kraven blir informellt återintroducerade vid ett senare tillfälle.
På det här sättet får man även hjälp med att kontrollera de förväntningar som kan finnas kring vissa krav, och att dessa helt enkelt inte kommer att kunna vara en del av den färdiga och presenterade lösningen, i vilket fall inte denna gång.
Detta är en viktig punkt som tydliggör de mer bärande kraven ännu bättre genom att verkligen utesluta det som inte går att genomföra just nu. Det blir tydligt var fokus bör ligga.
DSDM och MoSCoW
Vad är DSDM?
DSDM är en agil metod som riktar fokus på hela projektet och har utvecklats av företag och organisationer för att förbättra och strukturera arbetet och lönsamheten. DSDM består av åtta kriterier vilka ser ut som följande:
1. Fokus på behov
2. Uppvisning och behärskning av kontroll
3. Tydlig kontinuerlig kommunikation
4. Leverera i tid/följa utsatt tidsram
5. Samarbete
6. Bibehålla bra kvalitet
7. Stegvis utveckling från en stabil grund
8. Iterativ utveckling
DSDM går att applicera på de flesta situationer och är inte begränsad till vissa områden. Metoden granskar hela processens livscykel med hjälp av ovanstående punkter. DSDM öppnar även upp för att interagera med andra beprövade metoder, såsom förenklade workshops samt modellering och iterativ utveckling. DSDM går således att applicera på alla typer av projekt och uppgifter, oavsett storlek eller inriktning.
Metoden presenterades 1994 av en samling företag och organisationer, samt andra aktörer inom mjukvaru-hantering och utvecklingsindustrin. Metoden togs endast fram i syfte att förbättra och är endast till not-for-profit.
