Högrisk vs lågriskprojekt

Försvarets SAP-projekt blev en Miljard kr dyrare än förväntat och tog 8 år att bli färdigt. Varje gång jag läser nyheter som det här misslyckade projekt och liknande blir jag så otroligt uppgiven. Det är ett slag i ansiktet på oss som slåss om budgetar för IT-projekt. De här mastodontprojekten har misslyckats redan innan de har börjat för att de gör en massa generalfel som moderna IT-projekt inte ska behöva lida av. Här kommer mina tips för att undvika att ett projekt springer iväg i kostnad och tid.

Högrisk:

Externa parter

Kunder, leverantörer eller andra externa parter som jurister eller byråer är en stor risk för att försena ditt projekt. Alla andra organisationer av människor som är utanför din organisation bidrar till komplexitet och det kostar. De jobbar på andra sätt, i ett annat tempo, och kommunicerar på ett annat sätt. Ju fler externa parter desto fler täta och gärna återkommande avstängningar behöver ditt projekt. Ju fler externa parter, desto högre risk. Ta höjd för det!

Ovana beställare

Alla inom IT har eller kommer attjobba med ovana beställare. Det är ofta projekt som börjar med att nån säger ”jag har en ide” istället för att identifiera ett problem. När jag var på Nordic Exommerce Summit tror jag det var Footways VD som sa: ”det du är bra på, kan du outsourca”. Poängen med det uttalandet är att ett sånt projekt kan du kravställa korrekt, oavsett om du vill byta lager eller affärssystem. Förstår du inte vad du köper kan det bli väldigt dyrt.

Inte planera för förändring

När det gäller projekt i Försvarets storlek finns det ingen chans att kravställarna kan naila alla processer och affärsvärden med en gång, för de är inte permanenta. En organisation utsätts hela tiden för nya intryck utifrån och inifrån. Kraven hos en organisation ändras med 1% i månaden är en gammal doktrin som säkert inte är vetenskapligt underbyggd, men ändå sätter fingret på problematiken. För 8 år sen hade knappt den första iPhonen kommit ut, en teknik som ändrar hur hela organisationer jobbar. Hur skulle Försvaret kunna planera för det?

För få milstolpar

Detta hänger ihop med punkten ovan. Du kan inte införa ett system efter 8 år till en hel organisation. Du behöver införa små steg hela tiden och testa hur de faller ut. Bygg en skalbar miljö och attackera de områden där du ser problem. Det går att införa SAP för en avdelning eller en grupp och skala ut den så fler personer kliver ombord successivt. Jag vet inte var de här jätteprojekten kommer från, men antar att det är riktigt skickliga SAP-konsulter som övertygar Försvarets upphandlare om att de måste ta höjd för allt på en gång och sluta ett ramavtal för att det ska funka över huvud taget.

Otydliga beslutsmandat och otydliga beslut

Vem är det som har sista ordet? Det måste vara en person som har en väl underbyggd förståelse för projektet. Är det ett litet projekt kan en person hålla koll på allt. Är det en grupp av beställare med olika mindre projekt krävs koordinering och beslutsstrukturer. De viktigaste besluten är ofta inte om vi väljer lösning A eller B utan vilka affärsbeslut vi väljer att prioritera nu och vilka vi väljer bort helt för tillfället.

Features får prioritet över processer

I ett IT-projekt är det extremt mycket tid som slösas på lösningar framför problem. Det är mänskligt att exempelvis tänka ”jag behöver en knapp som laddar ner den här rapporten”. Istället måste man tvinga sig att fundera på vad knappen representerar i min arbetsprocess eller mitt dagliga arbete. Du kanske inte alls behöver en knapp. Du behöver ett sätt för din chef att följa ditt arbete utan att du behöver lyfta ett finger för att rapportera. När man har koll på processerna kommer många lösningar naturligt.

Sebastian Siemiatkowski, VD på Klarna sa att han skulle hjälpa till ur egen ficka och bygga en ny sajt, när arbetsförmedlingen lade ner sitt 100 miljoner kr dyra sajtprojekt. Jag bidrar gärna också, men med rådgivning.

###

Denna post är nummer 65 i en serie av 100 poster i utmaningen #blogg100 där jag främst fokuserar på hur vi skapar Trettis nya sajt men även reflekterar kring e-handel och IT. Alla åsikter är mina egna.