I en projektorganisation sker prioritering ofta i samband med att vi bestämmer vad som ska ingå i ett projekt. Vi har krav, funktioner eller lösningar och behöver avgöra vad som ska få plats inom en begränsad tid och budget.
Ett naturligt sätt att göra det är att klassificera innehållet: High, Medium eller Low, Must, Should eller Could. Det hjälper oss att skilja det som måste ingå i leveransen från sådant vi kan avstå från om tiden eller pengarna inte räcker. Flera saker kan vara High eller Must samtidigt. Det är inget konstigt med det. Vi försöker framför allt avgöra vad som ska ingå i det scope vi planerar att leverera.
När vi organiserar utvecklingen kring produktteam förändras frågan. Vi arbetar mot önskade effekter och behöver avgöra vilken förflyttning som är viktigast att fokusera på nu.
Det kräver någon form av gemensam grund för våra val. Strategisk betydelse kan spela in, liksom förväntad effekt, tidskritikalitet, risk och hur mycket kapacitet något kräver. Exakt vilka principer vi använder är mindre viktigt än att vi är överens om dem innan vi börjar argumentera för våra egna förflyttningar.
Prioritering uppstår egentligen först när alternativen ställs mot varandra. Vad händer om vi väntar med den ena medan vi gör den andra? Vad kostar det oss att vänta? Vad får vi genom den ordning vi väljer, och vad väljer vi samtidigt att skjuta på? Det är samma typ av ekonomiskt resonemang som ligger bakom exempelvis Cost of Delay och Weighted Shortest Job First.
Men när vi går från att organisera utvecklingen i projekt till att arbeta i produktteam följer ofta ett välbekant sätt att prioritera med oss. Kraven och lösningarna har kanske ersatts av Epics som beskriver önskade förflyttningar, men vi fortsätter att prioritera dem på ett välbekant sätt:
Öka kundlojaliteten: High.
Minska tiden för onboarding: High.
Minska återkommande produktionsincidenter: High.
Öka självservicen: Medium.
Det ser ut som att vi har prioriterat våra förflyttningar. Men vilken ska vi fokusera på först?
När varje Epic bedöms för sig är det lätt att nästan allt blir High. Kundlojaliteten är avgörande för affären, problemen i onboarding gör att vi tappar kunder och produktionsincidenterna kostar pengar och skapar frustration. Självservice kan samtidigt frigöra betydande kapacitet. Alla har bra argument, och om Low i praktiken riskerar att betyda inte nu och kanske aldrig finns det starka incitament att åtminstone hamna på Medium, helst High.
Efter ett tag har vi kanske fem High, tre Medium och en Low. Vi har lagt mycket tid på prioritering, men fortfarande inte bestämt vad som ska gå först.
Vi har klassificerat hur viktiga saker är. Vi har inte prioriterat mellan dem.
En rak prioriteringsordning, eller stack ranking, tvingar fram ett annat beslut. Inte för att siffrorna 1, 2 och 3 är bättre etiketter, utan för att något faktiskt måste gå före något annat. Om något flyttas upp behöver något annat flyttas ner.
Två saker kan båda vara High. De kan inte båda vara först.
Det betyder inte att ordningen blir en ny plan för framtiden. När vi lär oss mer, uppnår effekter eller förutsättningarna förändras kan också ordningen förändras. Den visar helt enkelt vårt bästa beslut just nu om var vi ska lägga vår begränsade kapacitet.
Klassificeringsfällan i prioritering uppstår när vi prioriterar varje Epic för sig, när vi egentligen behöver prioritera mellan dem.
Fler fällor
Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam
Se helheten
Klassificeringsfällan i prioriteting är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.
Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.
