Agilt projekt blev tre år forsinket og 38 millioner kroner dyrere

Illustration: REDPIXEL.PL/Bigstock
Nyt, agilt udviklet it-system til domstolene bliver tre år forsinket og et tocifret millionbeløb dyrere end først antaget. Ingen overraskelse, siger professor i offentlig it.

37,9 millioner kroner

Sådan lyder ekstraregningen for at gøre første del af et forsinket it-system klar til domstolene, inden der står 2014 på kalenderbladene.

Det fremgår af et aktstykke til Folketingets finansudvalg, hvori justitsminister Morten Bødskov (S) beder om flere penge til at få systemet gjort færdigt.

Hvis pengene bevilges, vil systemet ende med en pris på 106 millioner kroner, når det efter tre års forsinkelse er klar ved udgangen af 2013. Herefter skal domstolene kobles på systemet, hvilket er et helt it-projekt i sig selv.

»Merudgifterne skyldes, at den valgte it-løsning nu underbygger sagsbehandlingen af andre fagområder end civile sager og straffesager, stigende renteomkostninger som følge af den forsinkede ibrugtagning (på cirka tre år, red.) samt en fordyrelse af projektets indledende foranalyse,« hedder det i aktstykket.

I dokumentet får risikovurderingen af projektet samtidig et nøk opad fra middel til lidt over middel.

Foranalyse, renter og ekstra funktionalitet

It-systemet hedder Juridiske Fagsystemer og er et ESDH-system (Elektronisk Sags- og Dokumenthåndtering), som skal bruges hos Danmarks Domstole. Det omfatter blandt andet Højesteret, Østre- og Vestre Landsret, Tinglysningsretten og 24 byretter.

Systemet erstatter en stribe gamle, forældede systemer og skal både skære ned på papirstakkene hos retterne og sætte mere fart på sagsbehandlingen.

Version2 har talt med Domstolsstyrelsen om baggrunden for, at projektet er blevet forsinket og fordyret, men styrelsen ønsker dog ikke at udtale sig til citat.

Men faktum er, at foranalysen til projektet er gået hen og blevet 3,8 millioner kroner dyrere end ventet. Derudover er 8,5 millioner kroner løbet på i renter på grund af forsinkelsen, fremgår det af aktstykket. De to poster udgør tilsammen cirka en tredjedel af ekstraregningen.

De resterende 25,6 millioner overføres fra et uafsluttet it-projekt, der skulle ende med et særskilt system til behandling af tvangsauktion og skiftesager. De opgaver føres nu i stedet ind under paraplyen hos Juridiske Fagsystemer, og dermed skal systemet altså kunne håndtere flere sagsområder end oprindeligt planlagt.

Ministeren erkender i aktstykket, at præsentationen af ekstraregningen »burde være sket på et tidligere tidspunkt«.

»Den sene forelæggelse skyldes navnlig, at planlagte forelæggelser som følge af ændringer i tidsplanen løbende er blevet udskudt indtil en mere sikker tidsplan - bl.a. i lyset af den ændrede implementeringsplan - kunne fastlægges.«

Men de tre års forsinkelse skyldes også, at domstolenes it-infrastruktur har skullet opgraderes sideløbende med udviklingen af systemet. Samtidig er flere nøglemedarbejdere på projektet blevet flyttet over på Tinglysningsprojektet i 2010. Og de foreløbige test af Juridiske Fagsystemer har vist, at der er 'behov for yderligere kvalitetssikring,' fremgår det af aktstykket.

It-professor ikke overrasket

Hvis de 37,9 millioner kroner bevilges, vil systemet altså løbe op i en samlet pris på 106 millioner kroner. Den pris dækker dog kun første fase af systemet, der senere skal kobles sammen med de enkelte retter landet over under projektets fase 2.

Professor og ekspert i offentlig digitalisering ved Aalborg Universitet, Kim Normann Andersen, er ikke overrasket over forsinkelsen af projektet.

»Det her er jo et af de større it-projekter. Og det er efterhånden common sense, at den slags enten bliver forsinket, ramt af fejl, eller at man ikke får det, man havde regnet med. Eller en kombination af de tre ting,« siger Kim Normann Andersen til Version2.

Som Version2 kunne skrive i 2010, gik Domstolsstyrelsen over til et agilt udviklingsforløb efter at være raget uklar med leverandøren af forgængeren til Juridiske Fagsystemer, it-systemet Civilstraffe, der endte med at blive droppet i 2007. Leverandøren var dengang Software Innovation.

Læs også: Domstolsstyrelsen ændrer taktik: Bygger agilt ovenpå skrottet ESDH-projekt

Ifølge Kim Normann Andersen er der absolut intet i vejen med at gå den agile vej, hvor softwaren udvikles og evalueres langt hyppigere end med den traditionelle vandfaldsmodel. Det er tværtimod det, som flere eksperter har efterlyst i årevis, i takt med at store hanelefanter blandt offentlige it-projekter er segnet som fluer.

Men risikoen er, at man mister det store overblik, når ikke modellen følges af stram projektstyring.

»Det er en svær balance, fordi den agile model som regel giver bedre løsninger. Men problemet med den agile metode kan være, at styrbarheden forsvinder,« siger Kim Normann Andersen til Version2.

Teknisk review på vej

Domstolsstyrelsen oplyser til Version2, at den tre år forsinkede fase 1 af Juridiske Fagsystemer ventes færdiggjort i slutningen af 2013.

Fase 1 dækker udviklingen af selve infrastrukturen og de delkomponenter, der skal understøtte sagsbehandlingen. I projektets fase 2, som der endnu ikke er afsat penge til, skal domstolene kobles på systemet.

Domstolsstyrelsen afventer nu et teknisk review af Fase 1, som skal gøre styrelsen klogere på, hvad der skal ske i fase 2.

Prisen for anden fase kendes endnu ikke, men er ifølge aktstykket et selvstændigt it-projekt, som skal en tur forbi Statens It-projektråd før start. Dermed ligger prisen på 10 millioner kroner eller derover.

Globeteam og Dansk System Industri A/S er leverandører på systemet systemet i den første fase, mens konsulenthuset Devoteam fungerer som rådgiver.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Morten Hoffmann

Professor Kim Normann Andersen citeres for at have sagt at "problemet med den agile metode kan være, at styrbarheden forsvinder" ? Et af omdrejningspunkterne i agil udvikling er netop at sikre styrbarhed bl.a. ved at håndtere forandringer, frem for stædigt at holde ved en tidligere plan.
Måske det offentliges problem gemmer sig i brændfeltet af politik, administration og systemisk adfærd, sådan at agile projekter har næsten for megen "styrbarhed" og derfor kræver kompetent "product management" (som i f.eks. Scrum)? Mon PM delen er varetaget af stridende interessenter i form af diverse styrelser og fagsystemer?

  • 15
  • 0
Thomas Vestergaard

Hvis først vi er derude hvor vi accepterer dette som sund fornuft, så er alt håb vist ude.


Hvorfor det? Hvad mener du, der taler for, at det skulle være muligt at lave et præcist estimat up-front på projekt af den her kaliber?

De mest præcise estimater fåes ved at sammenligne en opgave med noget, man tidligere har løst og ikke udfra hvor mange timer nogen bestemte personer mener en given opgave vil tage. Jeg tvivler bare på, at der har været særligt mange "lignende opgaver" at sammenligne med.

Så synes jeg egentlig, at følgende citat er langt mere problematisk:

»Den sene forelæggelse skyldes navnlig, at planlagte forelæggelser som følge af ændringer i tidsplanen løbende er blevet udskudt indtil en mere sikker tidsplan - bl.a. i lyset af den ændrede implementeringsplan - kunne fastlægges.«

Det lyder nærmest somom den projektansvarlige ikke har været villig til at formidle de informationer omkring at projektet var på vej ud af kurs, før han også havde en løsning på, hvordan det kom tilbage. Så er der ikke meget ved, at bruge en metode, der giver tidlige information omkring det, som den agile tilgang burde give, når man på governance niveau sætter det over styr.

  • 4
  • 1
Poul-Henning Kamp Blogger

Hvorfor det? Hvad mener du, der taler for, at det skulle være muligt at lave et præcist estimat up-front på projekt af den her kaliber?

Problemet er ikke om estimatet er korrekt, up front eller anderledes.

Problemet er at projektet er forkert angrebet.

Lavede de en prototype ?

Nej, det gjorde de ikke og derfor begik de alle fejlene i den software der skulle leveres.

ALLE projekter bør bruge 5-10% af budgettet på en prototype.

  • 7
  • 1
Christian Nobel

@Thomas.

Det jeg sagde var, at hvis først vi begynder at tale om sund fornuft at tingene går galt, så har vi da for alvor et problem.

Det jeg egentlig ville frem til, men som åbenbart skal skæres ud i pap er, at hvis KNA havde brugt udtrykket "common knowledge", ja så ville man jo bare trække på skulderen, nemlig fordi der ikke er noget nyt under solen.

  • 5
  • 0
Flemming Nielsen

Hvis ikke jeg tager meget fejl af artiklen, så stammer 2/3 af budgetoverskridelsen (25,6 mio. kr.) fra overførslen af

"et uafsluttet it-projekt, der skulle ende med et særskilt system til behandling af tvangsauktion og skiftesager"

Med andre ord: det oprindelige scope for projektet er udvidet, hvilket forklarer 2/3 af budgetoverskridelsen. Så; spis brød til, kære venner.

Man kan så spørge sig selv, hvorfor budgettet for det uafsluttede projekt ikke er overført til det samlede projektbudget, men her kan der evt. være politiske og styringsmæssige årsager.

Foranalysens fordyrelse og rentebelastningen pga. 3 års forsinkelse er den reelle "skandale" i denne historie.

Men naturligvis er "scope creep" også en klassisk projektledelsesproblematik, som man ser på mange projekter. Hvorvidt agile metoder så giver mere plads til og tolerance overfor, at scope netop KAN creepe (i opadgående retning), så der skal leveres MERE fra projektets side, skal jeg lade være usagt .... men det er vel egentlig dette, der er den interessante faglige diskussion for publikum herinde.

  • 3
  • 0
Rune Larsen

Er det agilt, at levere et produkt efter 3 år, der stadigt ikke er integreret med brugerne?

Det lyder som om den store fejl blev begået, da projektet blev delt op i en "udviklingsdel" og en "tilkoblingsdel".

  • 11
  • 0
Flemming Nielsen

@Rune:
Det skal jeg ikke kunne sige - jeg er ikke agil ekspert. Til gengæld har jeg en del erfaring fra store SAP projekter, hvor løsningen skal ud til mange forskellige dele af en stor organisation, og her er det altså helt normalt, at man først udvikler en fælles koncern template løsning, og så laver lokale tilpasninger ifm. roll-out/implementering til de enkelte lokationer.

Hvorvidt dette passer med den agile logik, skal jeg lade være usagt, men når man både gerne vil standardisere så meget som muligt, så man kører på en fælles løsning i videst mulige omfang, og samtidig skal tage højde for legitime, lokale forskelle, så er det uomgængeligt en nødvendighed at splitte op mellem udviklingen af en koncern template, og den efterfølgende roll-out.

  • 1
  • 0
niels henrik højbjerg

"Hvorfor det? Hvad mener du, der taler for, at det skulle være muligt at lave et præcist estimat up-front på projekt af den her kaliber?"

nej det kan man selvfølgelig ikke.
men underligt nok liver det ALTID dyrere og det tager ALTID længere tid.
det bliver ALDRIG billigere og det tager ALDRIG kortere tid.
og det er meget tendentiøst - man fristes til at tro at der er nogen der taler mod bedre vidende.

  • 1
  • 0
Josef Assad

ALLE projekter bør bruge 5-10% af budgettet på en prototype.

Det har de jo også gjort nu, det er bare en ex post facto prototype. Vi kan bare håbe at din tommefingerregel om 5-10% viser sig at være pessimistisk; der er sikkert en eller fem større it leverandører der med glæde vil byde på udvikling af et ESDH system til over DKK 1,17 mia. (DKK 106 mio / 90%)

Bare den ikke ender som prototype nummer 2...

  • 3
  • 1
Flemming Sørensen

Det er da muligt, at jeg tager fejl (jeg håber det faktisk inderligt), men for mig ser det faktisk lidt ud som om, at folk går mere op i at sætte ord på hvordan de arbejder (i dette, og mange andre, tilfælde; agilt), i stedet for faktisk at lave et produkt. Lidt mindre fokus på ord, og lidt mere fokus på produktet, ville muligvis være en god ting.

  • 1
  • 0
Ole Laursen

Er det agilt, at levere et produkt efter 3 år, der stadigt ikke er integreret med brugerne?

Det lyder som om den store fejl blev begået, da projektet blev delt op i en "udviklingsdel" og en "tilkoblingsdel".

Enig. Man kan ikke udvikle på noget i tre år og forvente at ramme rigtigt, alene det at der er brugt 3.8 mio mere på en foranalyse lugter langt væk. Man må håbe virkeligheden er en anden end beskrevet her, ellers er der vist nogen der har købt katten i sækken ("ah, super, der står agilt udviklet på æsken, det er vist det eksperterne tilråder").

  • 2
  • 0
Rune Larsen

@Flemming
Feedback loop'et er essentielt i agil udvikling. Uviklingsorganisationen skal løbende producere færdige del-leverencer, som evalueres så realistisk som muligt. Herved får man tidlig information om hvordan det leverede fungerer og passer på de opgaver, der skal løses med software. Denne information fødes løbende tilbage til udviklingsorganisationen, som herved kan tilpasse det resterende arbejde med den nye forståelse.

Feedback loops er velbeskrevne i bl.a. kanban, som grundlæggende handler om at trække udviklet software ud hvor det giver værdi hurtigst muligt.
"Inspect and Adapt" og "Limit WIP" er blandt kanbans mantraer.

Med den viden vi har om software-udvikling i dag, er det svært at se det give mening at udvikle software, der ikke skal kobles til før efter 3 år.

  • 2
  • 0
Ole Laursen

ALLE projekter bør bruge 5-10% af budgettet på en prototype.

Jeg synes det er en lidt snæver indgangsvinkel.

Mange interne systemer er i virkeligheden ret enkle, processerne er måske lidt indviklede at beskrive og tager lidt tid at nå til bunds i, men i virkeligheden ikke særligt svære at programmere. En nogenlunde fornuftig arkitektur (som bør være barnemad for professionelle udviklere med erfaring fra lignende projekter), og så er det største problem at få bygget noget der virkeligt er brugbart for folk. Der er her en inkremental udvikling kommer ind i billedet med løbende feedback og læring for begge parter, udviklere og brugere, og såmænd også de der skal betale.

  • 1
  • 0
Klaus Enevoldsen

Fra aktstykket kan man læse:

Afslutningen af fase 1 forventes at ske ca. 3 år senere end oprindeligt planlagt, jf. Akt 118 af 30. april 2009. Forsinkelsen kan primært tilskrives følgende fire forhold:

  1. En ændret strategi i forhold til implementeringsforløbet, jf. nedenfor.

  2. Nødvendigheden af en større opgradering af domstolenes it-infrastruktur sideløbende med udviklingsarbejdet.

  3. Udskiftning af nøglemedarbejdere for at kunne tilgodese Tinglysningsprojektet i 2010

4 Testforløbet har indikeret behov for yderligere kvalitetssikring, før systemet er klar til udrulning

Ad 1) Man har ændret scope/business casen uden at sige det til dem, der skal betale for systemet.

Ad 2) Hvis det kan foregå sideløbende med udviklingsarbejdet, hvorfor bruges det så som en undskyldning for forsinkelsen?

Er der ikke bare tale om at man har designet et system, der ikke kunne køre på det hardware, der var i forvejen. Altså skulle man have bedt om flere penge til ny hardware, eller have designet arkitekturen til eksisterende hardware. Længere er den ikke.

Ad 3) Man har ikke haft de rigtige folk på opgaven - og ikke taget konsekvensen deraf. Konsekvensen er naturligvis at man udskyder projektet og starter med de rigtige folk.

Ad 4) Dårlig kvalitet fordi man ikke har inspiceret produktet undervejs - ergo de har ikke kørt agilt.

Bum!

  • 1
  • 0
Jørgen Elgaard Larsen

Jeg forstår heller ikke, at de taler om et agilt projekt. Det er muligt, at programmørerne har brugt en form for agil proces, men projektet som sådan kan umuligt betegnes som agilt med det feature creep, der åbenlyst har været.

Hvis projektet virkeligt havde været agilt, ville de naturligvis være gået i drift med en udgave uden de ekstra features - de kunne så komme på senere.

Men der kan naturligvis være et politisk problem med "release early, release often". Man er jo ikke sikker på at få bevillinger til de næste iterationer. Så er det tillokkende at udskyde release til et big bang og bare sige at projektet blev dyrere. Så vil det være sværere at sige nej til ekstrabevillingen, idet man så vil tabe investeringen.

På den måde modvirker forvaltningskulturen, at man kan lave agile projekter.

  • 1
  • 0
Viggo Jørgensen

"Globeteam og Dansk System Industri A/S er leverandører på systemet" ... globeteam var det ikke dem som lavede den der 'bestilte' kritiske rapport omkring POLSAG, alting hænger sammen på den ene eller anden måde :).

  • 0
  • 0
Flemming Nielsen

Min erfaring med at arbejde i den offentlige sektor er, at "forretningen" udemærket godt kender deres egne processer og fagområder, og som sådan godt ved hvad der er brug for at få leveret af IT løsning, rent forretningsprocesmæssigt, for at få dækket hele "hullet" fra A til Z, således at den manglende understøttelse af den forretningsmæssige værdikæde er dækket ind.

Problemet er blot, at man oftest beskriver dette behov ved hjælp af alenlange tekstbaserede dokumenter, og i et sprog, som enten er meget indforstået, til tider obskurt og ofte lidt floskuløst m. overordnede og upræcise forretningstermer, som et team af udviklere, arkitekter og integratorer kan have meget svært ved at få en præcis og utvetydig mening ud af.

Der mangler simpelthen standarder for et "fælles sprog" som formidler den fornødne mængde af viden, således at både fagspecialister, områdeledere, projektledere, arkitekter og udviklere alle er rimelige afklarede med, hvad der skal laves.

Metoder som BMPN og UML til forretningsmodellering, begrebsmodellering og inddækning af løsningsarkitektur er ganske simpelt ikke gængs viden og terminologi blandt mange af de DJØF'ere, som sidder som specialkonsulenter og projektledere og styrer behovs-/kravsspecifikationen (eller ekvivalent i et agilt projekt).

Man er cand.jur., cand.oecon. eller cand.polit. af uddannelse, og den slags arkitekturmæssige metoder, "sprog", begreber og værktøjer anvendes sjældent, selv om det gradvist er på vej, f.eks. med arkitektur tiltagene under OIO, FORM og STORM (se Digitaliseringsstyrelsen).

Hvis den offentlige sektor ville hjælpe sig selv bedre ift. IT projekter (og især de store og komplekse projekter), så burde de holde igen med lønkravene, og istedet satse på at få noget efteruddannelse ved overenskomstforhandlingerne.

Men omvendt lader der også til at være en del på leverandør siden, der måske bilder sig ind, at den hellige grav er velforvaret ift. de større, komplekse projekter og leverancer, hvis blot der står "agil" på det hele. Det virker sgu nærmest "religiøst" og en smule skræmmende, for at være helt ærlig, for den offentlige forretningsmodel er yderst kompleks, lovtung ad pommern til og nærmest at sammenligne med et multinationalt konglomerat á la Mærsk eller det gamle Østasiatisk Kompagni, blot tilsat en faktor 10 og spredt ud over et hav af forskellige aktivitets-, forvaltnings- og serviceområder ... og så ER det sgu bare ikke nok, at bilde sig selv ind, at en hurtig, agil turn-around tid i del-leverancerne vil få alle brikkerne på bingopladen til at falde på plads i sidste ende. Det er KOMPLEKST, kære venner, og der er en del, der skal gennemtænkes, før man begynder at kode noget som helst ... ellers havner man nemt i en blindgyde pga. inkonsistenser og inkompabilitet i datamodelleringer, forretningsprocesser der ikke hænger sammen og alt muligt andet snask man kan komme ud for, hvis man fokuserer for snævert (agilt) fra starten af et langt projektforløb.

Jeg har stor respekt for de gode erfaringer med den agile tilgang på de mindre projekter ... men i denne case er der vist tale om et stort projekt, med en vis kompleksitet, og det bør man nok ikke glemme inden man farer i det kritiske blækhus.

  • 2
  • 0
Klaus Enevoldsen

Jeg har stor respekt for de gode erfaringer med den agile tilgang på de mindre projekter ... men i denne case er der vist tale om et stort projekt, med en vis kompleksitet, og det bør man nok ikke glemme inden man farer i det kritiske blækhus.

Google, Facebook, Microsoft m.fl. kører alle agile. Afdelingen hos Microsoft, der laver Team Foundation Server frigiver hver måned en ny version af deres produkt. Hvis de kan, så kan "vi" også.

Kompleksiteten bliver mindre, jo mindre klumper man deler projektet op i.

I starten af et agilt projekt bør man koncentrere sig om at eliminere de største risici. Alt i et agilt projekt er et eller andet sted en risikovurdering.

  • 0
  • 0
Poul-Henning Kamp Blogger

I starten af et agilt projekt bør man koncentrere sig om at eliminere de største risici. Alt i et agilt projekt er et eller andet sted en risikovurdering.

s/agilt//g

Det gælder alle projekter og der er ingen grund til at blande nogen IT buzzwords ind en sandhed om projektstyring som både Sun Tzu, Julius Cæsar og Carl Von Clausewitz har kommenteret på.

  • 2
  • 0
Normann Aa. Nielsen

Af egen erfaring kan jeg melde, at overblikket - den røde tråd - forsvinder i backloggen, hvis denne kun er opgavedrevet. Som udvikler kan man i hvert fald ikke overskue situationen, fordi man konstant skal have fokus på det nære. Og uden overblik kan man kun lave lokale styringstiltag, hvilket ikke er specielt hensigtsmæssigt i store projekter. Det er præcis det, som Kim Normann Andersen påpeger.

Så der skal en overordnet fremdriftsplan, hvor mål, vision, håb og drømme er nedfældet. Og ikke mindst milestones, standarder etc. Nogen kalder det for en arkitektopgave, men det er for snævert, og bliver hurtigt for virkelighedsfjernt. Skal man endelig anvende agile metoder, så er Crystal Clear måske vejen frem. Men: Der er ingen tilpas store projekter, hvor man ikke på et tidspunkt taber overblikket, og begynder at lave lokal implementation. Det er kun et spørgsmål om forhalelse af tidspunktet.

  • 0
  • 0
Normann Aa. Nielsen

Hvis du releaser hurtigt - kommer der hurtigt svar og ønsker om nye features / ændringer af de eksisterende => Feature creep, og du taber overblik.

Hvis du releaser langsomt - kommer der ved hver release en lang liste over beklagelser over den håbløse virkemåde, og brok over de lange leveringstider. Dermed går du i gang med at løse beklagelserne, og ændre på modeller etc => Feature crap.

Dammed if you do - dammed if you don't.

Begge situationer skyldes manglen på OVERBLIK. Og man får det ikke gennem nogen af situationerne.

  • 0
  • 0
Log ind eller Opret konto for at kommentere