I den sidste tid har der været skrevet meget om fejlede, dyre offentlige it-projekter også her på QED. I en kommentar på Thomas Wittenburgs indlæg “Rejsekort og de fyrretyve it-rædsler” blev det nævnt at det kunne være rart med konstruktiv kritik ligesom Poul Foged udøvede da han skrev om Cookie-krisen (I og II).
Denne konstruktive tilgang kan man finde i mange rapporter gennem tiden f.eks. Bonnerup-rapporten, som helt tilbage i 2001 kom med en projekt-checkliste med 31 punkter, som skal være afklarede eller som man skal være opmærksom på i et it-projekt – alle punkter omkring styring og vilkår for projekterne. Det var udenfor Bonnerup-rapportens scope at kigge på teknologi-valg, men de har dog generelle betragtninger med, såsom at man skal undersøge om der er et standardsystem som kan dække behovet og man skal undersøge om der er mulige løsninger i andre afdelingers/styrelsers it-systemer – altså, er problemet allerede løst?
Af andre gode råd kan nævnes modning af den modtagende organisation. Er organisationen parat til at samarbejde om et it-projekt? Er kompetencerne til stede? Afsætter man de mest uerfarne/nemmest undværlige medarbejdere til projektsamarbejdet eller er projektet forankret og prioriteret helt oppe i toppen af hierakiet? Har man styr på visionen og er den kommunikeret ud til alle stakeholders? Hvad er de organisatoriske ændringer som systemindførelsen medfører – og hvordan udføres de løbende under systemudviklingen? Hvilke komponenter skal der være med i risikovurderingen? Hvilke erfaringer har andre med de valgte samarbejdspartnere – hvad kan forventes?
Mit favorit-råd af de 31 er uden tvivl, den simple “Think Big – Start Small”! Noget man har sagt længe, men som vist ikke helt er blevet en del af den offentlige kultur.
Spørgsmålet er om vi har glemt de pointer som rapporter såsom Bonnerup-rapporten lagde frem? It-projekter er f.eks. stadig ikke små nok – tag bare eksemplet Polsag. Kontrakterne er nok blevet mere agile, men er fremgangsmåden? Er det offentlige en professionel, moden kunde, når det køber it-systemudvikling?
Som Kristjan nævner i sit blogindlæg om IT-haverikommissionen synes brancheorganisationen IT-branchen det er spild af tid at lave flere undersøgelser før vi har lært af de forrige. Hvis vi stadig laver de samme fejl, som kortlagt i en rapport fra 2001, hvad er så pointen i at kortlægge de samme fejl igen og igen? Omend Kristjans konklusion er at det ikke er det eneste argument imod en it-haverikommission og Kristjan pointerer at vi allerede forsøger at implementere Bonnerup-rapporten (og andre rapporters) anbefalinger om at være mere agile og lave mindre projekter*, så man kan diskutere om det stadig er en valid kritik fra IT-branchen. Desværre er der store kulturelle forskelle i tilgangen til it-projekter og det kan være svært at generalisere på tværs af disse forskelle. Dette hænger igen sammen med modningen af den modtagende organisation – og der tror jeg den største udfordring ligger. Det skal så siges at jeg mener at Bonnerup-rapporten gør et godt stykke arbejde med at pege hen hvor man skal kigge efter problemer og så er det op til projektet selv at finde ud af om der er noget at komme efter i det konkrete tilfælde.
Vi har længe arbejde på at blive bedre til at definere projekter og have fokus på samarbejdet mellem leverandør og den offentlige kunde, men det er først for nyligt at vi har fået fokus på modtagerorganisationen med f.eks. et A-team af projektledere med meget erfaring. Jeg tror personligt at Bonnerup-rapporten stadig har mange gode anbefalinger at byde på som nogle af de modtagende offentlige kunder kan bruge til at blive mere professionelle omkring deres it-indkøb.
Som Kristjan påpeger er det godt at man vil kigge løbende på projekters relevans – men der er altså også noget at lære i gamle rapporter endnu, hvis man skal dømme efter de offentlige it-skandaler gennem tiden også efter 2001.
*om alle 31 punkter på Bonnerup-rapportens checkliste allerede er under overvejelse er svært at vide – i så fald vil jeg glæde mig til at se hvordan det går fremtidige projekter.
Mange af de store IT projekter som fejler nu, er startet op før man virkelig gik over i retning mod agilt og mindre projekter, så der går nok lidt tid før vi ser effekten. For os der arbejder med offentlige projekter, er der dog sket en markant forandring i mange af de udbud vi efterhånden ser, så der er håb forude.
Jeg sad sidst på et offentligt projekt i 2010 – og da var projektet nystartet. Agile metoder var bestemt ikke noget man var begejstret for – men man indførte da et dagligt standup… som i praksis var afrapportering. Det var ikke et kønt syn.
Med risiko for at virke som et surt opstød. Sikkert fordi jeg er pissetræt at høre SKI ansvarlige, it-chefer og andre med potentiel power til at gøre en forskel, tude om agile (er det noget med en hund) / adrætte metoder og processer og den kæmpe gevinst man kan opnå.
Bonnerup-rapporten omhandler nogle mislykkede projekter fra før lean-kanban-agile tiden. Store projekter med kæmpe foranalyser der langsomt flytter sig gennem en årrække. Jeg tror de fleste som arbejder med professionel IT har fundet ud af at brugerkrav ændres eller flyttes > 25% pr. år. Hvilket vil sige at mål ændre sig 100% på 4 år. Et hint som bonnerup-rapporten indikere med al tydelighed. Mange har lært af dette og af egne erfaringer og projekterne er blevet mindre gennem de sidste mange år.
Er succesraten blevet forbedret? Nej ikke som jeg ser det. Måske, ikke.
At bruge udviklings-metoden, organisationen eller enkelte medarbejders kompetencer er for mig at se blot et udtryk for tiltagende ringe planlægning og styring af projekterne. At bruge ord som “agile” i den forbindelse siger kun mig noget om ansvarsforflygtigelse.
Som du nævner tror jeg også at den offentlige kultur spiller en kæmpe rolle. Desværre har dette offentlige fænomen gennemsyret hele vort samfund og selv ganske små afdelinger hvor man “direkte kan mærke smerten” kan lide af samme bias.
Hvis man kombinere den historiske offentlige kultur og fremtidens håb om stadig vækst, flere features, mindre tid, hurtigere til marked, osv har man nok historiens dårligste vilkår for god, solid og robust software …
Ligesom TV-Avisen vil jeg afslutte med en positiv linje. Fede artikler på http://www.qed.dk – thumbs up
Frank, jeg tror faktisk ikke det har noget at gøre med den offentlige kultur. Jeg tror det er et spørgsmål om at offentlige styrelser mv. ofte er store organisationer, og det er dér skoen trykker. Der er masse af store private projekter som er mislykkedes, eller i hvert fald er blevet voldsomt dyrere/forsinket, og størsteparten (alle?) af disse har haft det kendetegn at de foregår i en stor organisation.
Jeg tror det har både noget at gøre med offentlig kultur og store organisationer – og så laves der ofte højrisiko-systemer alene fordi det skal bruges af en hulens masse mennesker fra dag 1, når systemet går live (hvis man ser bort fra brugertests og indfasningsperioder selvfølgelig).
Jeg har fuld forståelse for at det går galt med størrelsen af projekter i det offentlige (og andre steder, selv om vi ved bedre). Det er menneskelig natur at vi gerne vil dække en hel masse aspekter og have en masse features i vores nye vidunderlige it-projekt – men som vi ved; hvis ikke vi begrænser os, kan vi knække nakken.
Er der nogen der rent faktisk har tal for antal succesfuldt gennemførte it-projekter i det offentlige og antal kuldsejlede projekter? Kan de mange skandaler vi hører om nu være et resultat af at der bliver gennemført flere projekter og dermed kuldsejler et større antal projekter absolut set? Måske har vi ikke brug for en IT-havarikommission, men bare en entitet til mere vidensindsamling omkring de offentlige projekter, så vi ikke udtaler os på et tyndt grundlag? Måske en Bonnerup 2 med fokuseret vidensindsamling enten med nye fokusområder eller borende dybere i de gamle?