”Projektet planerades i detalj vartefter vi genomförde det, steg för steg, exakt enligt vårt Gantt-schema och avlevererade slutresultatet precis på utsatt tid och exakt enligt kundens förväntan.”
Om det var så min projektledarverklighet såg ut så hade jag aldrig börjat skriva några krönikor. Det hade helt enkelt inte funnits något intressant att skriva om.
I praktiken tycker jag att projektledarskap handlar om att hålla sitt projekt på vägen – ibland rullar allt på enligt plan och ibland har man själv eller teamet anledning att göra en insats för att förebygga dikeskörning. Min idé med mina krönikor här är att ta upp ämnen inom projektledning som jag inte funnit självklara svar på. Kanske har ni andra lösningar och då finns det möjlighet att kommentera.
Ämnet jag grävt ner mig i den här veckan är oväntade projektstopp. Nu pratar jag inte om någon mindre dipp för att ett par medarbetare blivit sjukskrivna utan om ett totalt stopp. Två gånger i min karriär har jag råkat ut för att projektet jag lett stannat av helt och det är inte speciellt lätt att hantera. All planering åker plötsligt i papperskorgen.
Det kan förmodligen finnas flera möjliga orsaker till att man får ett projektstopp. En vanlig anledning jag kan tänka mig är när kunden säger stopp, men det är inte speciellt svårhanterat. Då vill man ha ett stopp. Det är värre med oväntade stopp som man inte kunnat förutse.
Båda gångerna då jag råkat ut för totalstopp så har orsaken varit att vi väntat på den tekniska plattformen som projektet vilar på. Man kan alltid planera sitt IT-projekt och komma igång med de tidiga faserna i utvecklingen, men förr eller senare så måste arbetet sättas samman i den gemensamma, tekniska miljön. Om den då saknas så glider projektet snabbt in mot ett totalstopp.
Att plattformen inte kom på plats berodde (båda gångerna!) på att upphandlingen lades utanför mitt projekt. Det är alltså en stor risk, och för mig är den lite oväntad. Min egen uppfattning var att en part som tidigare genomfört upphandlingar borde vara erfaren nog att påpeka risk för försening. Då hade jag blivit medveten om förseningsrisken redan från början.
Båda gångerna har beställaren också haft en roll i förseningen. Att låta upphandlingen fortgå över lång tid för att, om möjligt, få ett bättre pris var ett medvetet beslut i styrgruppen. Andra gången jag råkade ut för det här så var jag snabb och avvecklade resurserna i projektet på olika sätt genom att växla in dem på andra arbetsuppgifter, mm, men risken är alltid stor att ett projektstopp ger stora och mindre synliga kostnader om folk sitter sysslolösa och bara kostar pengar.
Hur hanterar man då bäst oväntade projektstopp? Personligen ser jag bara två möjligheter – antingen vill beställaren fortsätta vänta och då måste resurserna ut ur projektet fortast möjligt, eller också måste man raskt fatta nödvändiga beslut, modifiera sin planering och snabbt komma upp på banan igen.
Jag tror att en grundregel om man vill undvika stopp av det här slaget är att se upp med upphandling som ligger utanför projektet. Orealistiska prisuppgifter utan skriftliga offerter kan man inte släppa in i sitt projekt från första början, det är regel nummer ett. Skriftliga gissningar från en förhandlare duger inte. Regel två är att förhandlare som lovar att de ska nå nya fantastiska lågpris om de bara får hållas måste man se upp för, speciellt om de inte finns i projektet utan har en gräddfil in i styrgruppen där de kan powerpointa projektet in i total handlingsförlamning. Har man en realistisk budget från början samt beslutanderätt över upphandlingen så löser man sånt här rätt enkelt inom sitt projekt – då gäller det bara att våga ta beslut.