Katastrofeprosjekter er det mange av, både innenfor software og hardware. Mange tror at det er flere katastrofeprosjekter i offentlig sektor enn i den private, men jeg lurer på om ikke den oppfatningen skyldes at det er lettere å holde ting skjult i det private, mens offentlige katastrofer kommer for en dag. På den annen side glemmes de fort.
I alle fall, de er deprimerende enkle å finne, også før de skjer. Jo lenger prosjektet er, jo mer ambisiøst det er, og, fremfor alt, jo flere beslutningstakere (eller i alle fall meningsinnehavere) det involverer, desto større er sjansen for at ting går til helsike. Mer om dette siden, men hvis du ønsker å studere et prakteksemplar i utvikling, ta en kikk på Akson – et 11 milliarders prosjekt for å skaffe tre fjerdedeler av landets kommuner (Midt-Norge skal nemlig ha sitt eget system) en felles helsejournal om fem år (og de har holdt på med utredninger siden 2011.) Akson har alle kjennetegn på en kjempekalkun, inkludert at ingen av de som har ansvar for det klarer å beskrive hva det skal gjøre annet enn i runde ordelag, samt at mellomleveranser er forsinket, men prosjektledelsen insisterer på at man skal klare å levere i tide likevel.
Her burde jeg skrive noe slikt som at du hørte det her først, men det stemmer ikke. Massevis av folk med bransje- og teknologierfaring har skrevet masse om hvor galt dette prosjektet er, men de blir ikke hørt.
Ikke jeg heller. Men nå har jeg sagt det.
Min spådom er at Akson kommer til å følge samme manus som Flexus
Hva kommer så til å skje? Vel, min spådom er at Akson kommer til å følge samme manus som Flexus, et felles billettsystem for kollektivtrafikken rundt Oslo som gikk åt skogen sånn omtrent 2010 til en pris av flere milliarder kroner. Først fikk teknologien skylden: Det franske konsulentselskapet Thales klarte ikke å lage billettautomater og systemer som fungerte skikkelig, noe som forsinket og fordyret systemet. Etter at den historien hadde husert noen dager begynte neste episode: Organisasjonsproblemet. Dette skjer gjerne ved at utviklerne tilbakeviser teknologikritikken med at de bestillende organisasjonene kom med så mange og uklare krav at det var umulig å bli ferdig, at ting tok for lang tid, og at man ikke hadde kvalifiserte nok personer i de ulike prosjekt- og styringsutvalgene.
Og det har de nok rett i, som regel. Problemet er bare (som jeg alltid sier til mine studenter) at man kan alltid skylde på dårlig prosjektledelse når noe går galt – men det forklarer ikke noe som helst.
I den tredje og siste fasen begynner man å se på bakgrunnen for hele prosjektet – hvilke feil var det man gjorde i den viktigste fasen av prosjektet – det vil si de første fem minuttene? Det er nemlig da man tar endel forutsetninger man som regel ikke er klar over at man tar.
For Flexus’ vedkommende var problemet at man hadde fem ulike selskaper med fem ulike prismodeller - avstand, tid, antall holdeplasser, antall soner, og så videre. Folk i Ruter har fortalt meg at dette ble tilsammen 2,4 milliarder forskjellige priser. Det finnes ikke den billettautomat i verden, i alle fall ikke i 2005, som kan håndtere denslags kompleksitet.
Så Flexus døde, og ble erstattet av en app som nå står for 70% av billettsalget til Ruter. At man i mellomtiden har forenklet betalingsmåtene slik at det er mulig å automatisere, snakkes det lite om.
Og hvis du lurer på manus for Akson (eller hvilket som helst annet mastodontprosjekt fremover) så kan du slutte å lure.
Stort og smidig – ja takk, begge deler!
