Tidigt 2000-tal befann jag mig i Baltikum där jag ansvarade för Litauens dittills största transformationsprogram inom den privata sektorn. Mitt uppdrag som programchef var att hjälpa ett stort marknadsledande företag att genomföra ett omfattande moderniseringsprogram med ett tiotal olika delprojekt och en löptid på ungefär två år. Jag ersatte befintlig programchef i en situation där företagsledning tillika styrgrupp insett att man inte hade tillräckligt bra kontroll på programmet, att man riskerade förseningar och var osäker på utfallet som helhet.
Ett av delprojekten innebar att bygga och utrusta två moderna datacentraler belägna under huvudkontoret respektive i en fastighet i ett industriområde utanför staden. Det specifika och kritiska datahallsprojektet fortskred enligt plan – de viktigaste milstenarna som var kvar inkluderade att hinna få datacentralerna färdigställda, inspekterade och godkända i tid samt att parallellt säkerställa att leverantören av dataservrar, ett amerikanskt företag, levererade enligt beställning och avtalad tidplan, det vill säga två veckor efter att datahallarna skulle stå klara och godkända.
Dessa båda milstenar var grundförutsättningar för att resterande delar av programmet inte skulle försenas – till exempel fanns beroenden att kunna installera nyutvecklad mjukvara och att successivt introducera nya datasystem för företaget, inklusive en nationell migrering av stort antal kontor till den moderna plattformen.
"Datahallen befann sig på fjärde våningen i ett femvåningshus"
I ett riskhanteringsperspektiv fokuserade projektet på att förstå import-, tull- och transportprocessen så att inget skulle gå fel när datautrustningen slutligen anlände i hamnen för vidare transport och installation i serverhallarna.
Fyra månader tidigare hade jag ett arbetsmöte och avstämning med ansvarig projektledare för datahallarna och ställde en del kontrollfrågor kring hur man såg på just intransport och installation av servrarna. Svaren jag fick var tydliga men ganska ofullständiga – jodå, allt var ”under kontroll’’.
Jag nöjde mig för stunden men bad om ett nytt möte med en konkret genomgång av hur respektive server installation skulle gå till.
Vid näste möte var det uppenbart att man inte tänkt igenom hela processen tillräckligt noga – till exempel presenterades inga specifikationer avseende hårdvarans storlek, vikt och hur servrarna fysiskt skulle transporteras in i datahallarna.
I den ena datahallen hade man installerat en särskild transporthiss som syftade till in- och uttransport av skrymmande och känslig utrustning. Problemet var att den andra datahallen befann sig på fjärde våningen i ett femvåningshus – en industrilokal med ett vanligt och ganska trångt trapphus som enda transportväg upp till våning fyra.
Två månader innan serverleveransen stod det klart för mig att den största av servrarna vägde 1,1 ton, var stor som ett modernt side-by-side kylskåp och enligt specifikationen inte heller fick lutas mer än 10 grader. Min projektledare hade tänkt sig att man skulle kunna bära in utrustningen via trapphuset – fyra våningsplan upp.
Vi insåg att vi hade ett problem.
Hur skulle vi lyckas, med mindre än åtta veckor tillgodo, att få till en lösning som säkerställde att vi kunde transportera och installera hårdvaran i datahallen? Alternativet var att hela programmet skulle försenas i veckor med mycket stora merkostnader som konsekvens.
Torrsim och inlyftning med dummy
En månad innan leveransen av servrarna hade vi ”torrsim” med två kranförare som fick träna på att lyfta in en ”dummy” av den största servern genom taket, via den nya lastramp vi byggt genom våning fem, ner till våningsplan fyra med den nya datahallen. Personal på insidan stod samtidigt och övade på att förflytta den största servern in i hallen.
Att bygga inlastningsrampen var ingen större utmaning även om det inte var gratis. Emellertid hade vi tur att det femte våningsplanet inte var uthyrt och att vår datahall befann sig på plan fyra, även om plan fem kanske hade varit ännu bättre. Fastighetsägaren kunde konstatera att han nu hade en hyresgäst som numer hyrde ett ytterligare våningsplan.
Sammantaget gick alltså allt bra och merkostnaderna var faktiskt marginella i sammanhanget – hur det gick för projektledaren förtäljer emellertid inte den här historien.
Inom samma program, i samband med att vi planerade logistiken för att ta emot servrarna från USA, fick vi veta att delar av koncernledningen skulle träffa vd:n för den amerikanska hårdvaruleverantören. Jag kontaktade koncernchefen och berättade vem jag var och bad att man skulle ta med den baltiska leveransen på agendan för det planerade toppmötet, vilket man lovade att göra.
Resultatet blev att de servrar vi beställt inte levererades enligt plan – utan två veckor tidigare. En försening som absolut inte kunde uteslutas hade varit lika katastrofal i ett totalt programperspektiv som det sedermera undanröjda problemet med server-transporten in i datahallarna.
Vikten av att vara noggrann
Kontentan av detta är att som programledning och programledare vara extremt noga med detaljerna, ställa frågor och inte lämna någonting åt slumpen. Eller med andra ord: ”djävulen sitter i detaljerna”. Det angreppssättet gäller inte bara som programansvarig utan i lika stor utsträckning programstyrelsen, dels i initieringsfasen, dels under genomförandefasen.
I en ideal värld gör man mycket av det arbetet som en del i själva grundplaneringen av ett projekt – något som jag kommer att återkomma till i en senare artikel. I det här specifika exemplet ersatte jag befintlig programchef ungefär halvvägs in i programmet. Min första aktivitet var att tillsammans med samtliga projektledare planera om de olika delprojekten. Detta gav oss en gemensam programplan men innebar också att samtliga deltagare fick en mycket bättre uppfattning om helheten och förstod syftet med förändringsprogrammet.
När hela transformationen i ovan beskrivna historia var avslutad fick jag en fråga av den högste ansvarige chefen: ’’Var var det som gick fel från början?’’. Mitt svar var att huvudorsaken var att man som företagsledning inte hade givit projektet tillräckligt med tid och resurser att göra en noga plan – starten gick helt enkelt för fort.
Min uppfattning är att en bidragande och viktig orsak till att endast en tredjedel av stora it- och affärsprojekt samt transformationer går enligt plan, avseende budget, tid, kvalitet och realiserade effekter, är att man ofta har för bråttom att komma i mål efter att beslutet att starta projektet tagits i ledningen.
Undvik svarta svanar
Under 2012 och 2013 har vi kunnat läsa om två storbanker som skrivit av mellan 500 och 750 miljoner kronor i anslutning till att man lagt ner storsatsningar på it. Två stora statliga myndigheter genomfor systemutvecklingsprojekt som blir minst en halv miljard kronor dyrare än väntat och ett år eller mer försenade. En internationell läkemedelskoncern fick omfattande produktionsproblemen som uppstod i och med bytet till ett nytt ERP-system vilket medförde mångmiljonbelopp i förlorade intäkter därför att min inte avsatt tillräckligt med tid för test.
Listan kan göras mycket längre och alla exempel från små och medelstora företag når inte alltid fram till media – vilket kanske en del ledningar är tacksamma för.
Vad man som ledande befattningshavare ska vara medveten om nar man fattar beslutet att starta ett stort projekt är risken att man skapar en så kallad ”black swan”, det vill säga ett projekt som under genomförandeperioden snabbt blir så kostsamt att det riskerar hela verksamhetens ekonomi och framtid. Jag kommer att återkomma även till detta i en senare artikel.
Jag vill avslutningsvis rekommendera vidare läsning av Jim Collins and Morten T. Hansens bok Great by Choice som bland annat beskriver hur företagsledningar och styrelser kan undvika operationella risker och vara förberedda om något trots allt går väldigt fel.
