Debatten, om hvorfor så mange offentlige it-projekter fejler, er blusset op igen, og meningerne om, hvad der går galt, er mange: Manglende it-forståelse i de offentlige ledelser, alt for detaljerede (og ofte unødvendige) kravspecifikationer, forsinkelser og prisstigninger fra leverandøren og andet godt.
Når støvet efter slagsmålet om skyld har lagt sig, står det for mig stadig mere klart, at netop valg af udviklingsmetode, definitionen af kravsopfyldelse og succeskriterier, har afgørende indflydelse på, hvorvidt et offentligt it-projekt kan levere det forventede resultat.
9 ud af 10 offentlige it-projekter afvikles på den traditionelle "vandfalds-model" med krav om omfattende og detaljerede kravspecifikationer, før der kodes en eneste linje. Men en mere tidssvarende udviklingsmodel repræsenteret ved de agile metoder og principper synes at være en langt mere farbar vej for netop de ofte store og komplekse offentlige udviklingsprojekter.
Men udfordringen er måske ikke engang valg af metode, men snarere definitionen af hvad succeskriteriet for et it-projekt i det offentlige egentlig er?
Er det vigtigste, at det kontraktuelt aftalte leveres i tide og på budget (som Rigsrevisionen synes at foretrække), eller om de forretningsmæssige mål med projektet bliver nået? Eller med andre ord: "Operationen lykkedes, men patienten døde" eller om "Patienten blev rask"?
Den offentlige sektors tendens til at gøre digitale projekter alt for store og komplekse er uhensigtsmæssig. Der tænkes alt for meget i hele Storebæltsbroer fremfor at bryde projekterne op i mere overskuelige og hurtigt synlige størrelser.
Keep it Simple
Prioritering bør gives til de opgaver, der leverer den største forretningsværdi først, for eksempel omkostningsreduktioner, bedre service, kortere behandlingstider og lignende.
Når it-projekter gøres for store, øges kompleksiteten voldsomt. Alle parter får derved sværere ved at møde behovet for de ofte hurtige beslutninger, der naturligt følger digitale projekters virkelighed i en dynamisk og omskiftelig verden.
Årsagen er primært tilgangen med at kravspecificere alt fra starten. Det er reelt utopisk og efterlader ofte projektet i et uoverskueligt hav af detaljerede krav og beskrivelser.
Hvis man i stedet fokuserer på at definere målbare, forretningsmæssige mål og ikke så meget på, hvordan vejen hen til målet præcist ser ud, ville grundlaget for et succesfuldt projekt, der reelt gør en forskel, være til stede.
Det skal tidligt i projektet kunne bevises, at det rent faktisk er sandsynligt at indfri de forretningsmæssige mål for projektet, ved at lade leverandøren levere en afgrænset løsning, der fungerer i praksis og ikke bare ser godt ud i alenlange dokumenter og systemtegninger.
Dette ud fra devisen om, at skal du fejle, så gør det hurtigt. Så kan projektet i givet fald stoppes tidligere, før der bliver brugt alt for mange penge. At den afgrænsede løsning rent faktisk fungerer, betyder også, at den kan sættes i produktion, hvormed værdien af projektet opleves tidligere.
Så diskussionen om udviklingsmetoder er principielt ligegyldig, hvis man ikke holder fokus på, hvad man ønsker at opnå med projektet - og om man rent faktisk opnår det. Hvis man har styr på dette, er der en lang række fordele ved de agile udviklingsmetoder.
Disse kan dog kun realiseres, hvis både kunde og leverandør fokuserer på 'Keep it Simple' og har den nødvendige beslutningsdygtighed og rette kompetencer til at gennemføre et forretningsdrevet og nutidigt udviklingsprojekt. Også i den offentlige sektor.
Carsten Brogaard Jensen er adm. direktør i Valtech.
Computerworlds klummer er ikke nødvendigvis udtryk for Computerworlds holdninger, men er alene udtryk for skribentens holdninger.
