Projekt som skall ersätta gamla system misslyckas alltid!

Under mer än 30 år inom mjukvaruutvecklingsbranchen så har jag sett det ena projektet efter det andra misslyckas med att ersätta ett befintligt system. När det för ovanlighetens skulle driftsätts och ersätter ett befintligt system så har man dragit över budgeten och projektet är kraftigt försenat jämfört med de första planerna. Vi måste hitta ett bättre sätt att ersätta gamla tekniska lösningar med moderna, vilket oftast är syftet med dessa projekt.

Det mönster jag har sett genom åren är att det nya systemet tas fram i ett nytt projekt för att säkra att resurserna får jobba med detta prioriterade projekt. I annat fall dras resurserna in i supporten och vidareutvecklingen av det befintliga systemet. Utveckling och support av det befintliga systemet är oftast nödvändig tills det nya systemet tar över.

De problem som uppstår kan vara av flera slag och är oftast en kombination av alla dessa.

• Företaget lyckas inte allokera resurser till det nya projektet
• Endast nyanställda kommer loss från andra projekt
• Kritiska resurser slits mellan de olika projekten och har svårt att räcka till
• Man underskattar komplexiteten i det gamla systemet
• Det gamla systemet utvecklas fortfarande i ett snabbt tempo
• Domänkompetensen är begränsad.

Jag tänkte inte gå in i detaljer kring dessa problemområden utan konstaterar att det nya projektet inte hinner i fatt det gamla. Efter ett antal år så kommer företagen oftast till insikten att de måste fortsätta att utveckla det befintliga systemet och lyckas därmed inte ta tillvara de fördelar med ny teknologi som man hoppats på.
Ett exempel är alla system som fortfarande kör på VAX/VMS operativsystemet som var populärt att utveckla system för under 80- och 90-talet. Dessa system är det allt svårare att hitta hårdvara att köra på men ändå är det många som inte vill byta sina system eftersom det blir för dyrt med tanke på att de befintliga systemen gör det de ska.
Det största projekt i denna kategori, som jag kan komma på, är när Telia och Ericsson drog igång AXE-N projektet (minns inte namnet riktigt) för att ersätta det befintliga AXE-stationerna. Vad jag minns så lades detta projekt ner efter ett otal timmars arbete.

Vi har de senaste dryga 10 åren alltmer frångått vattenfallstänkande till fördel för agilt projekttänkande. Det kan diskuteras för och nackdelar mellan dessa metoder och oftast finns det argument som överväger för det ena eller det andra i varje enskilt projekt som skall drivas även om jag förordar att ett agilt tänkande bör ligga till grund för all systemutveckling.
Var finns motsvarande nytänkande när det gäller att driva projekt som skall ersätta ett befintligt system? Vilka processer och metoder skall vi använda när vi planerar och genomför en teknikplattformsuppdatering av ett befintligt system? Hur ser den “agila” lösningen ut för denna typ av projekt?

Min första ansats är att driva förändringarna som en del av utvecklingen av det befintliga systemet. Vad innebär det jämfört med att starta ett nytt projekt? Ja, de fördelar som jag kan se är:

• Vi har domänkunskap
• Långsiktigt och kortsiktiga övervägande måste beslutas inom projektet
• Kritiska resurser kan jobba med en sak i sänder eftersom hela projektet har samma prioritering
• Vi har kunskap om de tekniska lösningarna och dessa är testade

Nackdelar är:

• Projektet kan prioritera bort långsiktiga aktiviteter för att nå kortsiktiga fördelar
• Eftersom man inte börjar från noll så är man begränsad av det befintliga systemet.

Nu skall man inte missledas av att jag bara listat två nackdelar och flera fördelar. Dessa två nackdelar kan och är troligen väldigt svåra att hantera och kräver en hel del av projektet.

Hur skall projektet tvingas att gå framåt med teknikutvecklingen?

• Det måste vara en styrgrupp som är tydlig med vad som skall prioriteras. Sätt upp tydliga mål och gärna med incitament för de enskilda personerna att arbeta mot detta målet. Det kan vara en bonus, att man ser en framtid för sig själv osv om man når målet.
• Kostnaderna för en vidareutveckling av det befintliga systemet måste inkludera konsekvenserna av att kostnadsfördelarna och affärsnyttan av att få in nya tekniska lösningar försenas.
• Aktiviteter för att kunna byta ut delar av det befintliga systemet måste finnas. Det kan vara att gränssnitt mellan olika delar införs, att automatiska tester implementeras osv.
• Alla ändringar integreras regelbundet, minst en gång i varje iteration. Projektet får absolut inte divergera till två olika system. Det är inte ett system som skall ersätta det befintliga. Det är det befintliga som skall utvecklas i rätt riktning.

Med dessa erfarenheter så drar vi lätt slutsatsen att det befintliga systemet borde varit implementerat så att det gått att utvecklas vidare på ett enklare sätt. Problemet med detta är alltid att det är svårt att förutse vilka moderniseringar, om några, under systemets livslängd som kommer att behövas. på 80-talet var det populärt att försöka bygga systemen så att det blev återanvändbara delar, modulariserat osv. Men min enda erfarenhet av detta var att det kostade resurser och försenade drifttagandet av systemet. Detta eftersom det är så svårt att förutse ändringarna så det går inte att räkna hem investeringarna i “bra att ha i framtiden” utveckling.

Allt oftare kommer vi tillbaka till att grundproblemet är att vi skapar oss en teknisk skuld i de system som utvecklas. Det är alltifrån mindre saker som korrekt felhantering i ett udda fall, till att vi inte byter tekniska lösningar förrän det är absolut nödvändigt. Att vårda sitt befintliga system innebär kontinuerliga investeringar även när det kanske känns onödigt. Om dessa investeringar inte görs kommer systemet till slut att bli för svårt att modernisera.