Ustyrlige statslige it-projekter skal holdes i stram snor
Offentlige it-projekter er unødigt komplicerede og teknologisk unikke. Kompleksiteten resulterer gang på gang i vildtvoksende budgetter og tidsplaner på projekter, som ikke engang rammer deres mål. I stedet kan de lære af privat udbudte it-projekter.
Det fastslår Lars Frelle-Petersen, digitaliseringschef i Finansministeriets Center for Effektivisering og Digitalisering. Han er med i den arbejdsgruppe, som for et år siden gik i krig mod ustyrlige statslige it-projekter. I starten af marts, i tide til forårsrengøringen, får regeringen serveret et sæt anbefalinger. Mål: At spare milliarder af kroner.
For det er ikke småpenge, offentlige it-projekter overskrider deres budgetter med. Finansministeriet opgjorde i sommer til Folketingets finansudvalg, at en række projekter i snit blev 39 procent dyrere, mens tidsplanerne gennemsnitligt voksede 74 procent over deadline.
To af Skatteministeriets it-projekter topper listen over skidt styrede budgetter. Budgetterne for SKAT fase 1 og eIndkomst-projekterne er vokset henholdsvis 94 og 339 procent over deres bredder.
Derfor er arbejdsgruppen gået grundigt til værks, og Lars Frelle- Petersen forventer en livlig diskussion i kølvandet på gruppens rapport.
»Vi skal blive bedre til at risikovurdere vores projekter, for vi sprænger tidsrammerne, og overskridelserne er store,« siger Lars Frelle-Petersen, der ikke lægger fingrene imellem, når han skal finde grunden:
»Manglende erfaringer og dermed en urealistisk forventning om, hvor hurtigt det kan lade sig gøre.«
Og selv om private virksomheders it-projekter også går galt, er Lars Frelle-Petersen ikke i tvivl om, at private virksomheder kan lære offentlige myndigheder en del om styring.
»En række private virksomheder har med stigende succes kunnet gennemføre projekter, der bedre overholder krav til såvel pris og tid som funktionalitet. På de offentligt gennemførte projekter er det snarere reglen end undtagelsen, at det ikke lykkes. «
Derfor tæller arbejdsgruppens tilknyttede rådgivere virksomheder som Danske Bank, DSB, Dong, Mærsk, Nykredit, Novo Nordisk, men også to professionelle vagthunde med blikket skarpt rettet mod dårlig styring og budgetskred: Professor Bent Flyvbjerg fra Oxford Universitet - en spidskompetence på overskredne anlægsbudgetter, som for Rigsrevisionen ofte har undersøgt både metro, broer og store offentlige byggerier - og Rigsrevisionen selv.
Blandt Lars Frelle-Petersens rådgivere er Lars Fruergaard Jørgensen, it-direktør i Novo Nordisk og en af det private erhvervslivs mest kompetente. For ham har det været interessant at være med i rådgivergruppen, fordi han kan se, at staten i dag står med samme udfordringer, som de private virksomheder for fem-ti år siden.
Eksempelvis er de private blevet bedre til at risikovurdere og til at reagere på vurderingen, end de tidligere var, og end staten i dag er, vurderer Lars Fruergaard Jørgensen:
»Da vi på Novo Nordisk som nogle af de første lavede en database til kliniske data, viste projektet sig at blive langt mere kompliceret, tage længere tid og blive dyrere, end vi havde regnet med, fordi vi ikke fra starten forstod, hvor svært det var. Det er en problemstilling, der ligner statens, at starte på noget meget avanceret uden at have forståelsen for, hvor komplekst det er. Og så skrider det,« siger Lars Fruergaard Jørgensen, der mener, at staten ofte er langt mere villig til at løbe risici:
»Staten er på nogle områder først til at implementere avancerede teknogier, der har været førende inden for både funktionalitet og løsninger, men som har gjort projekterne risikable. Private virksomheder kaster sig ikke ud i så risikable projekter, men vælger teknologier, der har vist sig at virke andre steder. I dag erkender vi, at vi ikke skal gøre det, hvis noget er for svært,« fastslår Lars Fruergaard Jørgensen.
Dén erfaring, at standardsystemer oftest er at foretrække frem for unikke, men usikre projekter, er Lars Frelle-Petersen mere end villig til at annektere:
»Usikkerhed er en vigtig grund til, at det går galt. Jo mere usikker man er på projektet, og jo mindre tillid, man har til leverandøren, desto mere forsøger man tilsyneladende at specificere sig til større sikkerhed. Man reagerer med livrem og seler,« fastslår han. Og så bliver der specificeret helt ned til blå tænd/slukknap og rød volumenknap.
»Men når man skriver en kravsspecifikation på 5-8.000 sider, er det svært at undgå modsatrettede krav. Desuden kan det, man skriver ned, altid være genstand for fortolkning. Selv om det af og til er nødvendigt med omfattende kravsspecifikationer, er nogle myndigheder ikke helt klar over, hvad det indebærer, når de stiller så mange krav,« vurderer han.
»Leverandører har over for os påpeget, at de ofte kunne levere standardsystemer, hvis der blev stillet færre detaljerede krav. For de nødvendiggør specialudviklinger og ender i komplicerede udviklingsforløb, hvor it mere skal tilpasse sig organisationen end omvendt. Og så bliver det dyrt,« vurderer Lars Frelle-Petersen.
Rapporten til regeringen bliver også offentligt tilgængelig. Den bygger bl.a. på mere end 60 interviews med private virksomheder, konsulenter, leverandører og brancheorganisationer og et omfattende dokumentationsmateriale på de enkelte projekter, der er forsøgt sammenlignet og erfaringerne uddraget.
Kommentarer (5)
Det er velkendt, at der er et erkendelsesforløb for softwarehuset: Hvordan ser denne forretning ud, hvad skal vi lave, hvilke processer skal vi understøtte mv.
Det som der sjældent bliver anerkendt af hverken leverandøren og kunden selv er at kunden skal igennem en tilsvarende erkendelsesproces.
Igen og igen ser vi at der bliver produceret en kravspecifikation som bliver sendt i udbud. Den der byder lavest vinder. Alt dette gøres fordi kunden tror at de nogenlunde kan overskue hvilket system de i virkeligheden ønsker. Det kan de ikke.
Når udviklingen så går igang, så bliver både kunden og leverandøren klogere og ender derfor med at lave noget andet end det først antagede. Fordi de indser det er nødvendigt. Men det gør ondt økonomisk, fordi alt dette nye ligger uden for de oprindelige krav, og det gør ondt tidsmæssigt fordi alle havde brug for at blive klogere undervejs, og det har man sjælden taget i betragtning.
Man skal ikke være chefpsykiater i Statspsykiatrien for, at se hvorfor budgetterne bliver sprængt.
Fokus på processer kan betyde manglende fokus på det vi i virkeligheden skal gøre, nemlig at opfylde kundens behov. Processer er fint, men de skal gi' mening og ikke være hæmmende for fremdrift: Lean tanken.
Mere fokus i projekterne på hvad kundens egentligt behov er end blindt at følge kravene. Tillid og samarbejde, men det kræver forståelse for kundens domæne/forretningsområde blandt udviklerne. Også at udviklere er forretningsrettede og ikke kun blindt koder ud fra oplæg.
Det nytter ikke at vi vedvarende tror at et software projekt kan projekteres og specificeres på forhånd, og at vi således behandler et software projekt som et stykke landevej eller for den sags skyld anlæg af et parcel hus. Vi er nødt til at finde en måde at køre vores projekter på så den erkendelsesproces bliver tilgodeset. Først da vil vi begynde at se færre kuldsejlede projekter
At følge disse få guidelines er desuden ganske i tråd med det Agile Manifesto
...problemet er fast-scope. Det er ikke vanskeligt at overholde en aftale om fast pris - det vanskelige er som det nævnes ovenfor, den mentale model der dikterer stramt fastlagte detaljer på et alt for tidligt tidspunkt (læs krav spec).
Idé - Lav mindre og simplere projekter. Drop krav spec'en, og beskriv istedet visionen på max én A4 side.
Så nærmer vi os partnering og agile programming:
Skab hurtigt en prototype til at diskutere krav omkring, som implementeres inkrementel og lig en timebox over projektet.
Jeg vil æde min gamle hat på at også her gælder den gamle 80/20 regel:
80% af funktionaliteten (læs: basis funktionaliteten) er implementeret efter 20% og så koster finesser (læs: det som kun få % af brugerne har brug for) kassen.
Eller: I følge Glenday dækker 6% af en virksomheds produkter 50% af omsætningen. 30% dækker allerede 95%. Kunne det ikke tænkes at dette også gælder IT-systemer? Se på jeres egen måde at bruge f.x. en tekstbehandling eller jeres mobiltelefon på...
Jeg synes jeg kan læse mig til at der er en række vandfald forude ...
Ja, sådan læser jeg "krav specifikationer på flere 1000 sider.
Jeg synes at de statslige IT projekter bør være som følger:
Skriv om hvad man gerne opnå på et overordnet plan (det er politikernes opgave). Den overordnede plan må ikke kunne fortolkes (man skal være præcis uden at gå i alt for mange detaljer).
Lav en række delmål. De første delmål bør være at plukke de laveste frugter først. Altså at lave den software som giver mest for pengene først - f.eks. målt i besparelser.
Test at det virker!
Derefter - byg så på i iterationer, men altid sådan at der er noget der virker (fra 1. delmål af og fremefter for hvert tilføjede delmål).
Idé - Lav mindre og simplere projekter. Drop krav spec'en, og beskriv istedet visionen på max én A4 side.
Hvad med en struktureret folde-ud specifikation i XML? Så bestemmer man selv antallet af sider.
Måske kan specifikationen også indeholde interaktive eksempler og javascripts, eller små tegnefilm. En enkelt tegnefilm, kan spare tusinder af ord.
I nogle tilfælde, er det ikke en god idé at "overspecificere". En overspecifikation, levner ikke mulighed for kreativitet. Men, det er vigtigt, at man altid specificerer det nødvendige.
I nogle tilfælde, har man måske også ønsker, forestillinger, ol. til hvordan det kunne gøres. Det er ikke nødvendigvis en del af en krav specifikation, men hvis kunden har sådanne ønsker, og idéer, kan de være udmærket at have kendskab til, så der kan tages efter dem, og det kan diskuteres med kunden.
