Förändringsdrivna IT-projekt

Känner du igen följande scenario? Desto mer komplext ett uppdrag är, desto mer behöver planen ändras längs med vägen. Ofta blir vi besvikna när förändringar kommer och spräcker budget eller tidsplan. Hur kunde vi inte se risken från början?

Staceydiagrammet nedan visar intressenters behov samt hur nivå på kunskap om den tekniska lösningen förhåller sig till projektets komplexitet.

I projekt ”Simple” vet vi vad och hur vi ska utföra uppdraget, vi kan ofta följa en lista med actions i turordning. I projekt ”Anarchy” däremot är det lönlöst att försöka skapa en plan från början. En naturkatastrof så som en Tsunami skulle falla i denna kategori.

Stacydiagram

Stacey Complexity model. Källa: https://www.scrum-tips.com/2016/02/17/stacey-complexity-model/

De projekt vi på Unified Commerce tar oss an befinner sig ofta i en komplex miljö. E-handelslösningar, PIM, MDM, digitala strategier eller knyta ihop flertal system är komplext. Att konfigurera system som ska effektivisera och förenkla vardagen, förbättra kundupplevelse samt öka ROI och är komplicerat och allt som oftast vinner alla på att planera vartefter som projektet utvecklas.

Vi och beställaren har ingen gemensam detaljerad karta eller plan för att nå målet från första början. Planen detaljeras däremot med tiden. Vi känner inte till kundens organisation i detalj från början, de känner inte till vår tekniska lösning eller långa erfarenhet från liknande projekt.

F√∂r√§ndringskostnader 

Röda kurvan visar att ju längre ett feltänk eller en teknisk defekt får existera, desto dyrare blir det att fixa den. Det finns flera orsaker till att kostnaden ökar med tiden, men två viktiga faktorer är följande:

1. Med tiden kommer ny utveckling att byggas ovanpå felet, vilket innebär att vi behöver backa all ny utveckling och bygga om den igen.

2. Den röda kurvan kommer med för mycket planer från början. Vid iterativ planering och jobba med utvecklingssprintar där kunden är deltagande minskar vi risken genom att planera om i varje sprint. Desto längre in vi är i projektet, desto fler intressenter kommer att påverkas av felet. Att fixa ett fel när det bara är en specifikation kan ta en minut. När det har kodats, testats och rullats ut till tusentals användare kan kostnaden för en rättning bli dyr. Ännu en gång så specificerar vi inte allt från början utan under vägen, det vill säga i varje ny sprint.

Att skapa ett krossfunktionellt team med bästa kompetensen från kunden och Unified commerce långa erfarenhet, och genom att ha gemensamma mål och en vision har man nått en bra bit på vägen. Förstår även projektteamet och de viktiga intressenterna att planering tar tid och måste göras hela vägen mot målet, inte bara från början, då har man ännu större chans att lyckas. Kan det vara så att de rätta frågorna dyker upp först längre fram i projektet när vi har bättre perspektiv? Se inte sena förändringar som ett misslyckande utan som en möjlighet till förbättring.

Jens Andersson
Projektledare
jens.j.andersson@sigma.se

2018-05-21

Unified Commerce
PIM
E-handel
Web