Mens Finansministeriet sammen med en række andre ministerier er i gang med at udarbejde en udredning af årsagerne og mulige løsninger på offentlige it-projekters fiasko-magnetisme, peger embedsmænd fra IT- og Telestyrelsen på, hvordan det offentlige kan udvikle mere effektive it-løsninger.
Våbenet hedder agile udviklingsmetoder som erstatning for den traditionelle vandfaldsmodel, som det offentlige har en tendens til altid at falde tilbage på i større, offentlige it-projekter.
"I foråret 2008 blev vi klar over, at det store projekt med at lave en ny version af oio-kataloget (Offentlige Informationer Online som it-standarder, specifikationer og teknologier, red.) var ude af trit med omverdenens krav og behov. Vi droppede derfor den traditionelle vandfaldsmodel og satsede på agil udvikling," forklarer kommunikationsmedarbejder Arvid Bro Thuestad, som var ansvarlig for sitets sociale funktioner.
Han fortæller, at også Infostrukturbasen med informationer om indholdet af databaser hos det offentlige, hvis formål er, at det skal blive nemmere at udveksle data mellem det offentlige, virksomheder og borger, også var noget forældet og kunne udvikles mere tidssvarende i projektet.
"Grundet migrationen fra Infostrukturbasen stod vi i en situation, hvor vi hurtigt skulle i gang med at udvikle en løsning, som kunne i komme i produktion, og det muliggjorde den agile metode, fordi vi så at sige kunne spise elefanten i små mundfulde," forklarer projektlederen fra IT- og Telestyrelsen, Martin Høegh Mortensen.
Som at stå på ski i Norge
IT- og Telestyrelsen benyttede den agile Scrum-metode i sin Digitaliser.dk-løsning, der bliver brugt som ressourcebibliotek, udviklings-, og diskussionsforum mellem borgere og IT- og Telestyrelsen.
Hele projektet blev leveret til tiden og til en pris, der lå på en fjerdel af det oprindelige site, isb.oio.dk, som oven i købet har færre funktioner og datamateriale end Digitaliser.dk.
Martin Høegh Mortensen oplyser, at der skete agil udvikling for omkring 13 millioner kroner i projektet.
Udover budgetterne blev holdt, var den største lære i projektet, at det er meget hurtigere at sadle om med Scrum-metoden i forhold til vandfaldsmodellen. Omsadlingen skete eksempelvis, da styrelsen undervejs i projektet ud fra brugernes behov kunne se, at der var brug for et event-modul.
"Det er helt sikkert, at Digitaliser.dk ville have set helt anderledes ud i dag, hvis vi havde valgt en vandfaldsmodel i sin tid. Jeg er også sikker på, at resultatet ville være dårligere. I processen er vi løbende blev klogere på, hvilken funktionalitet, der skulle prioriteres, og det betyder, at vi ikke har fået udviklet en masse redundant funktionalitet, men derimod den, som har været forretningsmæssigt vigtigst," forklarer Martin Høegh Mortensen.
Han bliver suppleret af Arvid Bro Thuestad, der fortæller om en af de store styrker ved Scrum:
"Når jeg står på ski i Norge, har jeg fra barnsben af fået indprentet, at det aldrig er for sendt at vende om, hvis vejret bliver dårligt. På samme måde bør man tænke it-projekter. Det er aldrig for sent at sadle om."
Del og hersk
Arvid Bro Thuestad forklarer, at Scrummetodens opdeling i mindre iterationer gav meget bedre kontrol over, hvordan koden til sitet blev afleveret.
"Projektet blev delt op i en række korte udviklingsforløb. Hver gang vi har startet et nyt forløb prioriterede vi udviklingsønsker ud fra, hvad der var tilbage af budgettet og den tid der var til rådighed," forklarer han.
Tre måneder efter de indledende møder var styrelsen ude med en beta-version af sitet, som havde til formål at indsamle information om brugernes adfærd og funktionsbehov på sitet. De blev så indført i de næste udviklings-iterationer.
Gørelsen og ikke størrelsen
IT- og Telestyrelsen siger med baggrund i erfaringerne fra Digitaliser.dk, at man skal være yderst opmærksom på, at agile metoder kræver mere dedikerede projektledere end normalt, fordi metoden appellerer til et stort samlende overblik over hele projektets forløb.
Vandfaldsmodel er optimal til det offentlige
Samtidig understreger projektleder Martin Høegh Mortensen, at det kræver flere ressourcer hos kunden - i dette tilfælde IT- og Telestyrelsen - at udvikle agilt.
"Vi har haft daglig kontakt til udviklerholdet og deltaget i de møder, som er en del af Scrum. Og internt har vi løbende modnet funktionalitetsønsker og prioriteret disse. Så Scrum er tidskrævende for kunden, og det er en forudsætning for projektets succes, at man er til rådighed, når det kræves," forklarer han.
Til gengæld er der ifølge Martin Høegh Mortensen ikke nogen begrænsninger for, hvor store it-projekter, man kan udvikle med agile metoder.
"Jeg er sikker på, at man kan tilføje alle it-projekter agilitet og jeg tror, at det vil give gode resultater i mange tilfælde. Jeg tror også, at man kan bruge agile metoder på store projekter."
"Man skal bruge agil udvikling, når det giver mening, og når både kunden og leverandøren begge er indstillet på det. Ikke nødvendigvis altid," understreger Martin Høegh Mortensen.
Vandfaldsmodellen er god nok
It-analysevirksomheden Interresearch har haft en noget anden oplevelse med det offentlige som kunde, og forstår ikke helt kritikken af den traditionelle vandfaldsmodel.
Interresarch vandt sidste forår et udbud om levering af det såkaldte Trivselsmeter, som er et online-værktøj til gennemførsel af trivselsmålinger og arbejdsmiljø-vurderinger i staten, kommunerne og regionerne, hvor Personalestyrelsen, KL og Danske Regioner stod som kunder med Finansministeriet som underskriver af kontrakten.
Produktet blev leveret i slutningen af året med tre delleverancer undervejs, efter Interresarch havde arbejdet ud fra en fast kravspecifikation. Allerede ved første delleverance i juli kunne de første beta-testere komme på systemet og gennemføre trivselsmålinger.
"Hele projektet lagde op til, at vi skulle følge kravspecifikationen ret nøjagtigt, og det virkede perfekt. Især efter brugerne ved første leverance kunne give os feedback, så vi kunne fejlrette," forklarer Interresearchs direktør Richard Amdi Madsen.
"Som leverandør er vi jo meget interesserede i at få gennemført alle faserne og være enig med kunden om, hvornår en fase er afsluttet, så vi kan begynde på en ny. Eller var vi jo aldrig blevet færdige," fortsætter han.
Kedelige erfaringer med det offentlige
Richard Amdi Madsen understreger, at uden faste aftaler om projektets faser, ville det hurtigt kunne have udviklet sig til en langstrakt affære med det offentlige som kunde.
For selskabet har nemlig tidligere forsøgt sig med mere iterative metoder i det offentlige uden den store succes.
"Vores oplevelse med prototyping var, at ingen ville tage ansvaret for de mange delleverancer, som vi leverede undervejs. Derfor havde vi svært ved at lukke delprocesserne. Den slags kræver jo en meget omfattende tjek-liste, hvor kunden er klar til at lukke leverede features efter aftalen med det samme," forklarer Richard Amdi Madsen.
Han understreger, at det i høj grad handler om kunden - i dette tilfælde det offentliges - it-parathed til at forstå den software, som de får i hænderne.
"Så selvfølgelig kommer softwareleveringen an på mennesker, og hvor parat kundens medarbejdere er til at modtage leverancerne," fastslår han.
