Executive summary — varför blir det jämt fel och hur borde man göra istället?
I DN-ledaren ”IT-haveriernas förlovade land” ställdes en frågan varför vi ständigt får läsa om nya it-haverier, varför man aldrig lär sig göra rätt?
Svaret är, lite tillspetsat, gamla ovanor! Gamla ovanor där det ena ger det andra. Och ja, det skulle relativt lätt gå att göra på bättre sätt!
Vad är det egentligen som brukar gå fel?
Alla vet redan att stora projekt innebär stora risker, medan små projekt innebär små risker — det håller nog alla med om. Och att det därför är lämpligt att dela ner varje stort projekt i små steg.
Att man trots det inte gör det beror på ofta att man valt en storskalig standardsystemlösning, och att man då troligen har att göra med en monolit som inte låter sig delas ner i steg — de är inte gjorda för det!
Framför sig har man ofta åratal av anpassningar, innan man kan sjösätta och få riktig feed back från verkligheten. Storskaliga standardsysteminföranden är en gemensam ingrediens i varje it-haveri.
Man har slängt på alldeles för mycket på tåget och haft föreställningen att det är ett rationellt val att göra mycket på en gång.
Beslutet att bygga stort drar med sig fler konsekvenser. Man är tvungen att anlita stort antal konsulter, över många år. Om det är fråga om odelbara monoliter som ska byggas, så är det svårt att dela ner i små steg för att prova sig fram och lära sig av hur det används.
Oftast blir leveransen en obehaglig överraskning eftersom det saknats transparens längs vägen.
Användbarheten är offrad redan från start, eftersom standardsystemet inte gått att anpassa särskilt mycket efter hur verksamheten jobbar — tvärtom tvingas verksamheten anpassa efter hur systemet jobbar.
Kort sammanfattning hur borde man göra istället
Alternativet är att underhålla sina system kontinuerligt, livcykelhantering kallat med ett trendigare ord. Ha gärna ha stora visioner, verkligen, men första steget är alltid litet.
Egenutveckla med modern teknik och moderna metoder och/eller välj det bästa från marknaden. Det kommer hela tiden nytt, så om du vill vara hålla dig ajour behöver du förnya din applikationer kontinuerligt.
När det gäller modern teknik och moderna metoder kan det medborgardrivna projektet Öppna skolplattformen ge en fingervisning om hur enkelt det är att bygga användargränssnitt om man använder sig av moderna tekniker och standarder från öppna marknaden (istället för de proprietära som standardsystem bygger på).
Men kontaktvägarna mellan systemen, infrastrukturen, behöver också vara modern. Det måste vara möjligt för system att prata med varann och utbyta information. Även att plocka bort föråldrade system. Det är här API:er kommer in. Har man dokumenterade API:er så innebär det att andra på marknaden kan tillåtas bidra med fler tjänster, till användarnas gagn.
Utforska och utveckla i små steg och användbarhet som ledstjärna, det är alltså kärnan.
Eller så enkelt som gamla rikspolischefen Bengt Svenssson en gång i tiden gjorde när han gav direktivet för det omtalade (lyckade) Javapust-projektet: Användbarhet ska vara högsta prio! Alla andra val är underliggande det valet.
Det borde för övrigt vara ett direktiv som gäller inom all offentlig utveckling: Då blir det lätt att välja rätt väg, och man kan stå stadig mot gamla ovanor, särintressen och andra intressekonflikter som kommer in från sidan.
Hur vet man att ett projekt eskalerar?
Eskalering följer liknande mönster varje gång, och alla människor beter sig på liknande sätt.
Man gör en “proof of concept” och hyfsar till den, för att visa att detta är en bra idé. Förstudien är också en glädjekalkyl.
Eskaleringen börjar i samma ögonblick som du har gjort ett prestigeladdat löfte långt fram i tiden som där du inte egentligen har kontroll över utfallet.
När du inser att du tagit fel väg känner du dig låst av sina tidigare löften, och kan inte agera. Det är lätt att tro att det handlar om investerade pengar som man inte vill förlora, och det gör det delvis, men det handlar ännu mer om utfästelser, en känsla av förlorad heder.
När utförsbacken startar hoppar många hoppar av. De som stannar kvar tystnar. Rapporter skönmålas.
För ledarna är det som att gå in i en tunnel man inte kan backa ur. Man hoppas på räddning, men förbereder sig samtidigt på en framtida blame game i slutet av tunneln, och ser till att själv inte bli svarte petter. Det slutar oftast med att man offrar CIO:n eller skyller allt på leverantören som man stämmer — mot bättre vetande — sen kan resten av de inblandade andas ut.
Man sedan länge förstått vartåt det barkar, men det känns rationellt att ta en större förlust senare än en mindre förlust nu (sunk cost fallacy).
Man ramlar sargad i mål och kastar projektet över muren till förvaltning (om det finns någon där?). Sen drar man helst till nåt roligare om man kan. Bara de trognaste stannar och tar skiten som nu börjar dundra.
Hur gör man för att bromsa ett eskalerande projekt?
Mitt svar är att det finns tyvärr inga fungerande sätt att bromsa ett eskalerande projekt — inga som visat sig fungera i verkligheten!
Det sägs att man ska jobba systematiskt med riskhantering. Det ska man. Men det är inte det som är silver bullet.
Det enda sättet jag kan rekommendera för att förebygga en eskalering, är att börja kravställa ett visst arbetssätt. Ett arbetssätt där man levererar i små steg där varje steg utvärderas mot projektets syfte och användarnytta. Bromsar gör man vid behov vid just en sådan tidiga utvärdering.
I modernt drivna projekt sker redan idag sker massor av såna inbromsningar, det står bara inte om de i tidningarna. De är smärtfria.
