Norsk myndighed omstrukturerer kæmpe it-projekt: 3 milliarder kroner dyrt projekt er langt sværere end ventet

Et stort offentligt it-projekt er slået fejl, og nu bliver arbejdsgangene reorganiseret. Det samlede budget er på tre milliarder kroner.

It-systemerne hos det norske Arbejds- og Velfærdsdirektorat går tilbage til 1976, og der var brug for en helt ny, moderne platform. Men projektet Moderniseringsprogrammet, som skulle sikre nye it-systemer, er en større udfordring end man havde regnet med, og nu skal der organiseres forfra. Det skriver Aftenposten.

It-projektet begyndte i 2010 med indledende øvelser, og i sommeren 2012 gik 200 udviklere i gang med at kode og designe, mens eksterne leverandører skulle hjælpe med de mere specialiserede dele af projektet.

Det samlede budget frem til projektets afslutning i 2018 var på 3,3 milliarder norske kroner, hvilket svarer til 3 milliarder danske kroner.

Målet var oprindeligt at udvikle første etape af de nye systemer fra bunden af, men det måtte man opgive og valgte i stedet at bruge et eksisterende it-system til pensionsudbetaling som udgangspunkt. Heller ikke den metode fungerede dog, og alt i alt var projektet blevet meget mere kompliceret end forventet, har projektledelsen tidligere meldt ud. Hvad der skal ske nu, er endnu uklart.

Arbejds- og Velfærdsdirektoratet har 18.000 ansatte og står for udbetalingen af en række ydelser til borgerne i Norge. Hvert år udbetaler NAV, som myndigheden også bliver kaldt, omkring 300 milliarder kroner.

Opdateret 31/10-2013

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Kristian Sørensen

Det er jo ikke engang gjort med 300 udviklere.

Der skal til det tal tilføjes testere, brugerfladefolk, folk til kravstyring overfor kunden og ikke mindst en del overhead i form af administrativt personale til at holde styr på alt dette.

Er de mennesker som har udtænkt dette, slet ikke klar over hvor svært det er at sammensætte og sammenspille så mange mennesker?

Det vil tage år, med øve opgaver, før sådan et hold er bare nogenlunde oppe at fungere i en grad hvor de kan arbejde effektivt. Bare sådan noget essentielt som at få på plads hvordan man håndterer at en udvikler opdager noget som strider mod kravene eller mod en anden afdelings udviklingsarbejde. Hvordan erkendes og videreformidles det i organisationen, så det i tide og med tilpas vægt får indflydelse på kravforhandlingen eller på andre afdelingers arbejde

  • 1
  • 0
#2 Pelle Söderling

Det var også min første tanke - hvordan pokker skulle det kunne gå godt at tage 200 mennesker og sætte til at "kode og designe". Det er skisme mange mennesker og det kræver altså en hel masse organisering at få det til at gå op i en højere enhed. Desuden kræver det at der er en hel masse fælles retningslinjer, guidelines, frameworks, arkitektur og ikke mindst forretningsbeslutninger der skal være på plads inden man klar til at slippe så mange folk løs på et projekt.

Efter min erfaring fungerer det bedst at tage en lille gruppe meget erfarne personer (både arkitektur, design og kode) der stikker hovederne sammen i den indledende fase og får styr på hvordan tingene skal køre og fungere. Disse bør stå for at udstikke retningslinjerne, opbygge grundframeworket, få arkitekturen på plads og blive enige om hvilke standarder der skal køres efter for projektet. De bør også opdele projektet i nogle del-projekter og vurdere hvilke kompetencer der er krævet for at løse hvert delprojekt - der vil ofte være mange delprojekter her som ikke kræver eksperter og her smider man så de lidt billigere udviklere på. På denne måde vil man relativt nemt kunne beskæfte mellem 10-20 mand på et stort projekt.

Det tager i min verden år at opnå at kunne beskæftige 200 mand uden at hele organisationen falder fra hinanden og mit gæt er at 9/10 må have siddet og "triller tommelfingrer", lavet redundant arbejde eller ganske enkelt ikke vist hvad de skulle.

  • 4
  • 0
#4 Pelle Söderling

Det lyder også ret sandsynligt ja :-)

Jeg tror man indenfor det offentlige er relativt vant til at man-power er noget der skalerer forholdsvis lineært. Ergo flere folk = hurtigere resultat.

Sådan fungerer software-udvikling altså bare ikke. Snarere tværtimod, det er snarere i kategorien "for mange kokke fordærver maden".

  • 1
  • 0
#5 Lars Wive Marcussen

Jeg var på projektet indtil maj og de 200 var inkl. testere, arkitekter, forretningsfolk/sagsbehandlere etc. Og NAV havde faktisk gjort sit forarbejde, og man havde besluttet at starte med et proof of concept med den mindst benyttede offentlige ydelse, der så i sommers skulle havde været evalueret før man besluttede om man gik videre. Der var dog ingen der troede at man ikke ville gå videre med projektet. Som jeg så problemerne var det nok som der forleden blev nævnt i en artikel fra GOTO at agile ikke skalerer godt nok. Selvom de forsøgte med et arkitektur team, hvor deltagerne også sad ude i scrum teamsne. De forskellige firmaer benyttede forskellige værktøjer (såsom apache libs)og ingen procedure for at genanvende dem, der var ikke en "lognings politik" og indtil jeg beklagede mig til en af NAV's arkitekter var der kun javadoc for omkring 15% af metoderne, etc. Og udviklingen var mere fokuseret på "nu skal vi levere noget nyt" end at det skal kunne vedligeholdes.

  • 8
  • 0
#8 Kristian Sørensen

Hvordan får vi Politikerne til at læse Version2?? :)

Kun ved at det er i deres personlige interesse at følge de råd og vejledninger der kan læses her på version2.

Hvis de i stedet har personlig vinding ved at have mange folk under sig, administrere store magistrater, sidde i bestyrelser for store quasi-offentlige "firmaer" etc. ja så fortsætter de nok med det.

  • 2
  • 0
#10 Jørgen K. Hansen

nok mere den praktiske anvendelse.. code over documentation er et dogme, men ikke et krav.. så før vi kan konkludere noget som helst og smider brænde på bålet af "we know better", så skal vi vide lidt mere om:

  • er der brugt SCRUM fuldt ud? eller bare "kind of SCRUM"?.. de fleste større organisationer tror at de stadig kan køre med ugentlige rapporteringer via excel ark, og faste krav til kvalitet og funktionalitet.
  • havde de lavet de nødvendige organisatoriske ændringer for at omfavne den agile tankegang
  • i så store projekter er SCRUM of SCRUMS et must..blev det brugt?
  • javadoc er ikke som udgangspunkt kvalitets befordrende, da det ofte alligevel misbruges til ligegyldigheder. Dokumentér det der er nødvendigt... kod deklarativt.. alt for mange koder efter det sidste nye smarte designpattern.. men glemmer at vedligeholdelse oftest ender på laveste fællesnævner.. kort kode er sjældent god kode.. blev kodestandard analyseret og kravsat/overholdt?
  • enhver SCRUM master på et så stort projekt sørger naturligvis for at ledelsen hyrer en Agil guru ind, som har prøvet den størrelse projekter før, og sørger for at han konstant holder øje med at det kører fornuftigt.. hvis man kan køre projekter i USA med 3-500 mand, så kan man også håndtere 200 i Norge.
  • projektet burde være delt op i grundtanken: en lille kerne der skal virke først (hul igennem), og så bygge ud derfra.. blev det gjort?

såå.. mere info, ellers gætter vi bare.. det gør jeg også.. men vil undlade at konkludere noget inden vi har mere info ;-)

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