Jag fick i uppdrag att leda ett projekt inom Länsförsäkringar AB med syfte att byta ut ett system som användes av handläggare på Länsförsäkringarnas lokala kontor i Sverige vid kundkontakter och bokning av kundmöten.
Projektet omfattade flera olika kompetensområden och hade beroenden till bland annat integrationer, systemarkitektur, kravställning, inköp och externa leverantörer.
När jag kom in i projektet var en av mina första uppgifter att skapa mig en tydlig bild av helheten – vad som redan fanns på plats, vilka beslut som var fattade och vilka frågor som fortfarande behövde lösas.
Utmaningen
Projektet hade många beroenden och flera olika perspektiv som behövde vägas samman innan det gick att fatta beslut om vägen framåt. Jag behövde snabbt förstå vilka personer som ansvarade för kravställningen, vem som hade ansvar för systemarkitekturen, vilka integrationer som berördes, vilka möjliga systemlösningar som fanns och hur projektets rapportering och beslutsvägar skulle fungera.
Samtidigt behövde två möjliga systemlösningar analyseras på djupet för att skapa ett tillräckligt bra beslutsunderlag inför projektets styrgrupp. En ytterligare utmaning visade sig när detaljerna kring den valda lösningen började ta form. Det blev då tydligt att lösningen hade ett hårt beroende till ett annat integrerat system som behövde uppgraderas innan vår lösning kunde implementeras.
En planerad uppgradering fanns omkring ett halvår fram i tiden, vilket gav projektet en viss marginal – men också ett tydligt beroende som behövde hanteras.
Så arbetade jag
Jag började med att kartlägga projektets befintliga underlag, kontaktpersoner, ansvar och beroenden. Jag identifierade bland annat:
- vilka som ansvarade för kravställningen
- ansvarig systemarkitekt
- aktuella integrationer
- möjliga systemlösningar på marknaden
- projektets besluts- och rapporteringsvägar
- vilka behov och förväntningar uppdragsgivarna hade på projektets rapportering.
Utifrån kartläggningen skapade jag en samlad bild av hur jag uppfattade uppdraget och projektets förutsättningar. Den bilden stämde jag sedan av med uppdragsgivarna så att min tolkning kunde verifieras, kompletteras och förankras innan jag gick vidare. Därefter gjorde jag en djupare analys av de två systemlösningar som hade valts ut som möjliga alternativ. Jag tog fram ett initialt beslutsunderlag med bland annat risker, fördelar och nackdelar för respektive alternativ. Underlaget presenterades och diskuterades med integratörer, arkitekter och kravställare. Deras perspektiv och synpunkter arbetades in innan frågan lyftes till projektets styrgrupp. Beslutet blev att gå vidare med en Oracle-baserad lösning.
Att göra komplexitet begriplig
Parallellt med det övriga projektarbetet utvecklade jag en enkel månadsrapportering i form av en onepager. Syftet var att ge ansvariga på de lokala kontoren runt om i Sverige en snabb och tydlig bild av projektets läge. Rapporten sammanfattade bland annat projektstatus, aktuell progress, vad som pågick just nu och aktuella risker. Målet var att mottagarna snabbt skulle kunna förstå var projektet befann sig, vad som hände just nu och om det fanns något de behövde känna till – utan att behöva sätta sig in i projektets alla detaljer.
Rapporteringsmodellen blev mycket uppskattad. En ansvarig ville lyfta modellen till ett centralt tekniskt råd, med syfte att få den godkänd som standard för rapportering i liknande projekt. För mig blev det ett fint kvitto på att enkel och tydlig kommunikation kan göra stor skillnad när komplex information behöver nå många olika mottagare.
Riskhantering när förutsättningarna förändras
När detaljerna kring den valda systemlösningen började ta form blev det tydligt att projektet var beroende av att ett integrerat system uppgraderades enligt plan. Jag gjorde därför en fördjupad riskanalys utifrån de förutsättningar och den information som då fanns tillgänglig. Riskerna och konsekvenserna presenterades för styrgruppen, som gav sitt godkännande att fortsätta enligt plan. Det fanns vid den tidpunkten egentligen inga andra realistiska alternativ, vilket gjorde det särskilt viktigt att synliggöra beroendet och dess konsekvenser och samtidigt skapa en plan för att hantera risken.
När omvärldsläget sedan förändrades försenades den planerade uppgraderingen av det integrerade systemet på obestämd tid. Projektet behövde därför senare pausas.
Från beslut till nästa steg
Efter beslutet om systemlösning behövde inköp involveras för att avtal skulle kunna upprättas med leverantören. Först när den processen var klar kunde projektet gå vidare till den mer detaljerade dialogen med leverantören och få tillgång till rätt kompetenser för att besvara de tekniska och verksamhetsmässiga frågor som återstod. Projektet drevs därmed stegvis, där varje fas skapade förutsättningar för nästa samtidigt som nya beroenden och risker behövde identifieras och hanteras.
Resultatet
Under min tid i projektet skapades en strukturerad grund för det fortsatta systembytet. Projektet gick från ett befintligt och delvis spretigt underlag till en tydligare helhetsbild, ett analyserat beslutsunderlag och ett förankrat val av systemlösning. Genom att involvera arkitektur, integration, kravställning och andra berörda funktioner innan beslut kunde fattas skapades en bredare förankring kring den valda vägen framåt. Samtidigt etablerades en tydlig och uppskattad modell för löpande projektkommunikation till de lokala kontoren.
Min uppdragsgivare uppskattade särskilt min förmåga att arbeta självständigt och driva frågor framåt, även när de var komplexa. Den breda kompetensen gjorde det möjligt att ha en bra och konstruktiv dialog både med verksamhetens representanter och med kollegor inom IT-infrastruktur. Projektet behövde till slut pausas eftersom det integrerade system som vår lösning var beroende av inte kunde uppgraderas enligt den ursprungliga planen.
Min viktigaste lärdom
Det här uppdraget bekräftade för mig hur viktigt det är att börja med att skapa en gemensam bild av uppdraget innan man börjar lösa problemen. I komplexa IT-projekt är det lätt att snabbt hamna i detaljer. Men innan man kan fatta välgrundade beslut behöver man förstå helheten: vilka behov som finns, vilka beroenden som påverkar projektet, vem som behöver vara involverad och vilka beslut som faktiskt behöver fattas.
Jag tycker också att det är viktigt att skilja på att ta fram ett beslutsunderlag och att fatta själva beslutet. Min roll var att samla in information, analysera alternativen, synliggöra risker och konsekvenser och skapa ett underlag som gjorde det möjligt för styrgruppen att fatta ett välgrundat beslut. Och kanske lika viktigt: komplexitet behöver inte kommuniceras komplext. Ibland är den bästa lösningen en enkel struktur som hjälper människor att snabbt förstå det viktigaste.
För mig är det en central del av projektledarrollen:
Att skapa tillräckligt mycket struktur för att komplexitet ska bli begriplig – och tillräckligt bra underlag för att andra ska kunna fatta välgrundade beslut.