2.5 Beslut i det agila projektet

I tidigare avsnitt har de agila principerna för decentraliserat beslutsfattande presenterats övergripande och kommer här beskrivas mer i detalj. Det är inte så att beslut fattas av sig självt bara för att beslutskraften trycks ut till gruppen. Ett systematiskt arbete och träning behövs för att lyckas. Vid införande av agil projektmetod är det inte ovanligt att processen för beslutsfattande tas lite för lättvindigt. I detta avsnitt introduceras viktiga definitioner och begrepp för beslutsfattande, där sedan arbetssätt för beslut presenteras, samt en del utmaningar att hantera för att lyckas.

För att det ska uppstå en beslutssituation behövs minst två rimliga alternativ att ta ställning till och besluta om. Beslutsprocessen delas ofta in i tre delar; tiden innan beslut, själva beslutet, samt införandet. Det är inte helt ovanligt att stressade organisationer bokar in beslutsmöte även om det bara finns ett alternativ på bordet vilket gör att det inte är en beslutssituation. Men det kan självfallet vara relevant att ha ett möte för att diskutera hur problemet ska lösas.

Eftersom agil projektmetod vanligen används för komplexa projekt är det troligt att även besluten har en viss nivå av komplexitet. Ett projekt innefattar dock många beslut och en del kan vara lite enklare och en del mer komplexa.

• Enklare beslut: Kännetecknas av att problemet enkelt kan beskrivas och samtliga krav är kända, här finns även en entydig rimlig lösning. Denna typ av enklare problem löses ofta med simuleringar och kallas för en sluten beslutsprocess.
• Komplexa beslut: De mer komplexa beslut som ofta behöver tas i agila projekt, stödjs bättre av den begränsat rationella modellen. Kravbilden är ofta rörigare, med krav som är i konflikt med varandra, information som saknas och randvillkor som ändras. Många olika tekniska lösningar kan potentiellt lösa problemet men mer subjektiva bedömningar påverkar beslutet. För dessa beslut kan delar ofta hanteras med simuleringar, men i slutändan blir det en hel del subjektiva avvägningar och detta är då en mer öppen beslutsprocess. Det handlar då om att ta ett beslut med hög kvalitet som är väl grundat. Att här sträva efter ett optimalt beslut kan vara mer stressande och tidsödande än produktivt. Fortsättningsvis används därför begreppet beslutskvalitet för komplexa beslut.

För att fatta beslut med hög kvalitet är det viktigt att ha en process som säkrar att viktiga aspekter hanteras i flödet. För komplexa beslut är det vanligt att styrgrupp och/eller projektsponsor eller liknande blir involverad. Traditionellt hålls ofta ett tidigt möte med projektsponsor/styrgrupp för att sedan långt senare komma med förslag på lösning och beslut. Ett bättre arbetssätt är att sträva efter att beslut tas i så hög grad som möjligt av projektgruppen, men i de beslut som kräver involvering av styrgrupp är det viktigt att denna engageras tidigt samt att den kontinuerligt hålls informerad och att kritiska steg i beslutsprocessen stäms av. Detta arbetssätt uppfyller två syften. Det första är att säkra att projektet tar fram underlag och lösningar som ligger i linje med förväntningarna samt korrigera dessa vid behov. Det andra handlar om att bygga kunskap för att ha bättre möjlighet att vara med och fatta ett beslut med hög kvalitet.

Beslutsprocessen har följande steg;

1. Problem: Säkra att problemet är tydligt beskrivet och målen tydliga. Spendera gärna lite tid på att ifrågasätta problemet för att förstå vad det verkliga problemet är.
2. Inramning: Detta är ett mycket viktigt steg där utgångspunkten är problemet och det tänkta beslutet fokuserar på att definiera den information som behövs för det specifika beslutet. Det är vanligt att fel information och/eller för mycket information tas fram, vilket försvårar beslutet.
3. Samla data/information: Detta är processen för att samla in den data/information som definierats under 2) ovan.
4. Utveckla lösningar: Ta fram minst två rimliga lösningar. Använd gärna beslutsträd för att illustrera de olika alternativen.
5. Beslutsunderlag: Försök att inte bara presentera de olika alternativen och framtagna rekommendationer baserat på textdokument och överväg gärna att använda trade-off kurvor, tornado-diagram och liknande. Glöm inte att det vid beslutssituationen ska finnas en utvecklad implementeringsplan.
6. Beslutssituation: Har stegen 1-5 ovan genomarbetats är själva beslutsmötet vanligen lite mindre utmanande. Det är viktigt att det finns flera personer vid mötet som har kunskap om det som ska beslutas, samt att alla underlag funnits tillgängliga i god tid innan mötet.
7. Implementera: Införandet startar omgående då beslutet är taget, då det ska finnas framme en plan och resurser tillgängliga.
8. Följ upp/ lärande: Det är bra om projektgruppen reflekterar över beslutsprocessen och följer upp kvaliteten på de beslut som tas för att skapa ett lärande inför framtida beslut.

En central del i beslutsprocessen är lärandet och det är vanligt att arbetet ”går lite framåt och bakåt” i processen, vilket inte ska ses som en brist utan är en del i lärandet i beslutsprocessen och rimligen ger ett bättre beslutsunderlag.

Några exempel på fällor vid beslutsfattande är:

• att bara bekräftande information söks, personen eller gruppen har redan bestämt sig,
• att oproportionerligt stort fokus läggs på det som är känt och det man är bekväm med,
• att nyligen inträffade stora händelser eller eventuella olyckor påverkar beslutet i hög grad,
• att fel inramning av problemet eller vad? görs vilket ger bristande underlag eller
• att analys av införande saknas i beslutssituationen.

Genom att arbeta i ett tvärfunktionellt team enligt ovan beskrivna process kan flera av fällorna undvikas. Det betyder att det agila arbetssättet i projekt ger stöd för att teamet tillsammans tar fram underlag och bygger den gemensamma kunskapen som är kritisk inför beslutsfattande.