Skuggprojekt

IT-projekt tar nästan alltid genvägar, det ligger i generna hos projekt. Dessa genvägar minskar risken för projektet och projektet hinner leverera mer funktionalitet. Låter fantastiskt, men det finns naturligtvis en baksida; genvägarna ger ofta teknisk skuld och gör förvaltningen onödigt dyr.

Problemet med genvägar i ett IT-projekt är att de negativa aspekterna kommer fram först efter att projektet är klart och drabbar en annan budget än projektets eget. Projektet ser framgångsrikt ut, men företaget har drabbats negativt med en skuld som någon måste betala.

Varför tar projekt genvägar?

Det finns några huvudskäl till att projekt tar genvägar; få in mer funktionalitet, minska risken för projektet och egna teknikpreferenser.

Mer funktionalitet

Det finns få projekt som hinner göra all önskvärd funktionalitet inom projektbudgeten. Genom att hålla nere på en del kvalitetsdelar såsom förvaltningsbarhet, testbarhet, osv kan projektet frigöra resurser för att hinna leverera mer funktionalitet.

Den som har beställt projektet är inte den som drabbas av dessa genvägar, så denne har ofta inget emot detta byte. Projektet “slipper” hålla hög kvalitet, levererar mer funktionalitet – med bibehållen projektbudget och beställaren är nöjd.

Den negativa konsekvensen är att man har skjutit ner kostnader till förvaltningen som antingen aktivt måste lyfta leveransen till önskad kvalitet eller som passivt drabbas med ökad förvaltningskostnad.

Minskad risk

Det här är vanligt när företaget har bestämt sig för att prova någon ny teknik (som ofta inte projektet själv har valt) och projektet får pålagt på sig att använda den nya tekniken under projektet.

Det blir en börda för projektet som har svårt att förutsäga konsekvenserna; nyheter betyder att man måste ägna tid åt att lära sig och det innebär dessutom ofta obehagliga överraskningar såsom svårare att testa, specialfall som ingen tänkt på förut, komplicerat att gå i produktion, mm.

Eftersom ett projekt strävar efter att minska risker, så kommer dess medlemmar försöka hitta sätt att komma runt att använda det nya. Minsta problem med det nya kommer innebära att projektet går till styrgruppen och kräver att få jobba på det gamla, trygga sättet. Styrgruppen vill alltid minska risk, så den säger gärna ja till att återgå till det trygga.

Den negativa konsekvensen är att företaget aldrig får igenom det nya, utan ligger kvar i ett gammalt, “tryggt” teknikval – som till slut leder till stora infrastrukturprojekt för att föra in ny teknik.

Egna teknikpreferenser

Om projektet själva hittat en teknisk lösning som man är förtjust i sker det omvända mot ovan. Här blundar projektet för motsvarande risker och kan lägga mycket tid på att kompensera för brister med den nya tekniken. Det gäller speciellt nya, oprövade tekniker som en enskild utvecklare smyger in i projektet.

När det senare upptäcks att projektet har dragit in en tveksam teknisk komponent (vid exempelvis en teknisk granskning av projektet, eller i värsta fall vid överlämnandet till förvaltning), så hävdar projektet att det är för sent för att backa ur och byta lösning. Ju senare i projektet desto dyrare är det att backa ur teknikvalet.

Eftersom den tekniska lösningen inte är ett strategiskt val så finns det inget som säger att den kommer att fortsätta att användas, utan nästa projekt kommer troligtvis använda någon annan teknik. Konsekvensen är att förvaltningsorganisationen får en växande flora med tekniska lösningar som den måste kunna hantera, vilket är dyrbart för företaget.

Olösbart problem?

Jag har sett hur man på olika företag försöker åtgärda problemet med att projekt tar genvägar på olika sätt:

• Arkitekturgranskningar för att upptäcka avvikelser från företagets riktlinjer
• Icke-funktionella krav som ska definiera projektets leveranskrav ur ett kvalitetsperspektiv
• Tekniska granskningar för att upptäcka egna teknikval, avvikelser från kvalitetskrav och potentiell teknisk skuld
• Låta förvaltningsorganisationen komma in tidigt i projektet för att påverka detta i positiv riktning

Jag kan inte säga att dessa åtgärder varit särskilt effektiva i att påverka ett projekts inneboende instinkt: Att leverera så mycket funktionalitet som möjligt inom tids- och penningbudget.

Omfamna projektets drivkrafter

Jag tror man ska sluta att arbeta mot projektens natur och istället bejaka dess drivkrafter. Mitt lösningsförslag är att införa ett extra projekt, ett “skuggprojekt”, som ansvarar för att huvudprojektets leverans blir förvaltningsbar och hjälper huvudprojektet med ny teknik.

Skuggprojektet ska som namnet antyder jobba i nära samarbete med huvudprojektet.

Minska risk

Skuggprojektet kan minska huvudprojektets risk genom att:

• Utbilda huvudprojektet i de existerande och nya tekniker som företaget bestämt att projektet ska använda
• Stötta projektet i införandet av ny teknik
• Hjälpa till med nya strategiska val
• Lösa problem som uppstår med teknik som projektet måste använda
• Göra tekniska granskningar (arkitektur och kod) för att upptäcka avvikelser från företagets riktlinjer och hjälpa projektet att styra över till strategiska val

Mer funktionalitet

Saker som företaget tjänar på att göra, men som inte huvudprojektet tjänar på tar skuggprojektet på sig. Exempelvis att ta fram en bra strategi, verktyg och regler för felhantering och loggning. Kanske att dokumentera delar av projektet.

Genom detta kan huvudprojektet använda sin budget nästan uteslutande på att leverera funktionalitet.

Teknikpreferenser

Här har jag än så länge inget positivt sätt att ta hand om detta. Jag tror på att vara hård här. Om teknik som inte stöds av företaget smygs in så anser jag att projektet helt enkelt får ta smällen och bygga om.

Om man bara är väldigt tydlig med detta så kommer projektets inneboende krafter göra att detta inte uppstår eftersom det både innebär risk och minskad funktionalitet i slutleveransen.

Hur man lägger upp ett skuggprojekt

Skuggprojektet ska ha en egen budget. Det innebär att man öronmärker en viss del av huvudprojekts budget till kvalitet. När man estimerar ett projekt har man ofta lagt undan pengar till detta, men när projektet är igång så gör de inneboende krafterna att dessa pengar istället används till mer funktionalitet.

Ett skuggprojekt ska helst bestå av personer från förvaltningen. Det innebär att man får in förvaltningen tidigt i projektet, något som man ofta talar om, men inte får till eftersom man inte vet vilka roller dessa ska ta i ett vanligt projekt.

Exempel

Jag har bara varit med om ett skuggprojekt, men de positiva resultaten av det inspirerade mig och det ligger även bakom att jag skrev den här bloggen. Exemplet är från ett företag i Stockholm. Företaget skulle införa ett kampanjsystem. Kampanjsystemet behövde integrera med en mängd system och i samband med införandet av det nya systemet ville företaget lyfta integrationerna från klassiska filöverföringar nattetid till händelser som ska utlösas direkt när något sker och som kringliggande system direkt ska agera på.

Eftersom projektet skulle bli det första som använde den här nya tekniken innebar det kraftigt ökad risk för projektet. När projektet dragit igång började man jobba enligt anvisningarna, men så snart man stötte på problem började man aktivt arbeta för att få använda filöverföringar istället.

Företaget införde då ett skuggprojekt som fick i uppgift att stå för teknikinförandet och ge huvudprojektet verktyg och stöd för att den nya tekniken skulle bli lika enkel eller enklare att använda än filöverföringar. De pengar som budgeterats för att projektet skulle använda den nya tekniken flyttades över till skuggprojektet.

Huvudprojektet kunde nu fokusera på sin huvuduppgift, att införa kampanjsystemet, och det nya sättet att integrera upplevdes nu som enklare och bättre än det gamla sättet istället för att ses som en risk och ett hinder.

Slutsats

Eftersom jag bara har ett exempel att luta mig mot så kan jag inte dra för långt gående slutsatser, men det jag tycker mig se är att genom att skapa skuggprojekt som ansvarar för att huvudprojektets leverans blir förvaltningsbar kan man utnyttja huvudprojektets drivkrafter positivt och samtidigt få ett resultat med hög kvalitet.

För mer information kontakta: lars.lindberg@xlent.se