Tidligere Obama-rådgiver om it-skandaler: Det er ikke nok bare at fyre de ansvarlige

Der skal kulturændringer til i offentlige organisationer, hvis store it-projekter skal blive en succes, mener amerikansk digitaliseringsmand.

Skats EFI-system, Politiets Polsag og vores allesammens Rejsekort. Find selv på flere. Danmark har som bekendt sin andel af dyre, offentlige it-projekter, der aldrig er blevet rigtigt gode.

Og mange mennesker er i tidens løb kommet med bud på, hvad problemerne kan være. Og de fleste er blandt andet enige om, at den klassiske vandfaldsmodel med store, statiske leveringsfaser måske ikke er den bedste (læs: er den værste) tilgang til kæmpe it-projekter i en verden, hvor den teknologiske udvikling går stærkt.

At en agil udviklingstilgang er at foretrække, lader der også til at være nogenlunde konsensus om. Altså helt kort fortalt små iterative udviklingsforløb, hvor projektet - i hvert fald på papiret - løbende kan ændres og tilpasses uden det hele falder fra hinanden og prisen eksploderer.

Den agile tilgang er Greg Godbout stor fortaler for. Han har fungeret som it-rådgiver for Obama-administrationen som en af de såkaldte presidential innovation fellows. Det er særligt udpegede folk, der tjener et år ad gangen og har som opgave at få det offentlige USA til at spille rent teknologisk. Greg Godbout har i den forbindelse været med til at søsætte taskforce-gruppen 18F, der løser it-opgaver for andre offentlige institutioner ved brug af open source, agile udviklingsmetoder og lean-startup teknikker. I dag er Greg Godbout it-chef i den amerikanske miljøstyrelse EPA.

Version2 mødte ham på Dansk IT's årlige konference Offentlig Digitalisering, lige efter han var færdig med sit keynote-indlæg. Det handlede blandt andet om, at agil-udvikling er vejen frem og om, at kulturen i offentlige organisationer er vigtig, hvis it-projekter skal fungere.

Det lyder banalt, og det er det på sin vis også, medgiver Greg Godbout. Men virkeligheden er jo stadig, at it-projekter går galt, så måske er agil-udvikling og kulturændring alligevel ikke helt så enkelt.

En af de ting, der er udfordringen med agil-udvikling, fortæller han, er at folk grundlæggende ikke forstår konceptet, men de tror de gør. Det er i hvert fald, hvad Greg Godbout er stødt på i sin gøren med offentlige myndigheder i USA.

»I næsten alle tilfælde laver de det, vi kalder fake-agile. Nogen omtaler det som fragile (skrøbelig, red.), jeg kalder det agile-fall. Det er en slags udiciplineret udgave af vandfaldsmodellen,« siger Greg Godbout og fortsætter:

»Det er på en måde det værste fra begge verdener, fordi det tillader ændringer i en proces, hvor ændringer ikke er meningen.«

Resultatet af udciplineret vandfaldsmodel under dække af at være agil-udvikling ender med, at alting bliver dyrere end det ville have været, hvis det havde været en stringent vandfaldsmodel. Simpelthen fordi løbende ændringer - i bedste agile stil - bliver skudt ind i et udviklingsforløb, der fra starten af slet ikke er gearet til den slags ændringer.

»Bruger I story points?«

»Alle siger: Vi laver agil-udvikling. Det er ikke populært at sige, man ikke gør, og alle vil gerne være populære.«

Når Greg Godbout møder den slags udmeldinger, så siger han:

»Fantastisk! Hvad er dit teams velocity, bruger I story points eller måler I bare timer? Og så ser de på mig og siger: Jeg forstod intet af det, du lige sagde.«

Når Greg Godbout og 18F-taskforcen er stødt på den slags i de offentlige organisationer, hvor de forsøger at hjælpe med digitaliseringen, tager de organisationen i hånden og siger:

»Vi hjælper jer med at lave diciplineret agile, så vi når i mål,« forklarer Greg Godbout.

Diciplin er nøgleordet. Uanset om der er tale om agil-udvikling, vandfaldsmodellen eller alt muligt andet for den sags skyld, forklarer Greg Godbout.

Han fortæller, at da han selv i sit karriereforløb begyndte på agil-udvikling, så havde han heller ikke styr på det.

»Det ligger på en måde i den menneskelige natur. At sige: Jeg har styr på det, jeg laver agile. Men man skal bruge en coach.«

Det vil med andre ord sige, at det er vigtigt at have en på holdet, der rent faktisk har styr på agil-udvikling, når en organisation kaster sig over den udviklingstilgang.

Greg Godbout gætter i den forbindelse på, at der kommer et tidspunkt, hvor organisationer slet ikke italesætter deres metode som agil, fordi det er en indgroet og helt naturlig tilgang til it-udvikling. Men på dette stadie er organisationer i dag altså i udgangspunktet ikke.

»Man kan ikke mestre noget uden at have været lærling,« siger han.

Greg Godbout står bag 18F, der hjælper amerikanske myndigheder med digitalisering. På Dansk IT's konference Offentlig Digitalisering havde han taget en slide med, der viser noget om forskellige kompetenceniveauer. Han håber, at Agil-udvikling på et tidspunkt når op på det øverste trin i offentlige institutioner. Det vil sige, at det er en indgroet måde at udvikle på. Men der er et stykke vej endnu.

Hvis en organisation alligevel giver sig i kast med agil-udvikling, så kan det - udover at blive en dyr fornøjelse - også ende med, at organisationen siger: Agil-udvikling, det har vi prøvet, det fungerede ikke, påpeger Godbout.

»Det skal vi bygge. Et eco-system, der håndhæver en kultur om at være agil og adaptiv imodsætning til en kultur, hvor vi prøver at forudsige alting. Statistisk set, kommer man til at tage fejl i sin forudsigelse, så det er spild af penge. Vi bør i stedet bruge pengene på at være adaptive, men på en meget disciplineret måde.«

Nytter ikke at fyre folk

Rigtig agil-udvikling er dog ikke i sig selv nok til at sikre den digitale succes i den offentlige sektor. Kulturen er vigtig, forklarer Godbout.

Kulturen er faktisk vigtigere end de folk, der har siddet og arbejdet med et fejlslagent projekt og måske bærer en del af ansvaret for, at det gik helt galt og millioner af skatteyderkroner er endt på gulvet.

En nærliggende tanke i sådan en situation kunne måske være at afskedige de ansvarlige og ansætte nogen, der har styr på sagerne i stedet. Men det du'r ifølge Godbout ikke.

»Det er frustrerende. Man bliver vred, når man tænker på spildet. Og det bør man også blive,« siger Greg Godbout og tilføjer:

»Men samtidig. Hvis man nu fyrede folk og erstattede dem med nogle nye ... hvis man ikke ændrer policy, governance og de omkringliggende systemer, så vil jeg argumentere for, at selv de nye folk, du ansætter, og som er dygtige, de over tid komme ud på en glidebane og gradvist blive mere som den kultur, de kom for at erstatte. Så det er ikke nok bare at udskifte, det kræver en bevidst indsats at ændre organisationen grundlæggende.«

For at illustrere sin pointe bruger Greg Godbout en analogi med en plante. Hvis den bliver plantet i den forkorte jord, så dør den. Og det nytter ikke bare at plante en ny plante i den samme jord. Jorden skal udskiftes.

Og det handler i sidste ende om helt at ændre kultur i organisationen. Og det involverer ifølge Godbout blandt andet et opgør med den høflighedskultur, han er stødt på i den offentlige sektor. Altså en kultur, hvor folk ikke vil sige, når nogen gør noget forkert eller dårligt.

For at illustrere den pointe brugte han en fortælling om sin mor under sin keynote. Godbouts mor synger dårligt. Alligevel meldte hun sig til det lokale kirkekor, da hun var ung. Og først her - da korlederen gjorde opmærksom på det - gik det op for hende, at hun sang dårligt.

Hun gik hjem til sine forældre og fortalte om episoden. De reagerede ved at sige noget i retning af: Ja, min skat. Det vidste vi godt.

Og det fik hende til at føle sig forrådt, som Godbout forklarede under sin keynote.

Med andre ord gør man altså ikke nødvendigvis nogen en tjeneste ved at lade være med at fortælle dem, at de gør noget forkert eller dårligt. Og det gælder også folk, der arbejder på offentlige it-projekter er Godbouts pointe.

Kulturændring handler i Greg Godbouts verden også om et opgør med den silo-tankegang, der kan præge offentlige organisationer. Altså tænk og samarbejd bredt i stedet for smalt.

Også et opgør med den loyalitetsopfattelse, der er i organisationerne, er nødvendig, påpeger Godbout. Altså hvor en ansat måske er mere loyal overfor organisationen, sin fortsatte, en politiker og så videre end over for et it-projekt.

Men det er helt forkert, påpeger Godbout. Hvis it skal blive godt, skal fokus være på målet for projektet. Det er der, succesen skal måles.

Find Nordstjernen

Den amerikanske it-chef kalder det at finde sin Nordstjerne.

»Hvis man ikke kan beskrive sin Nordstjerne med en eller to sætninger, så kommer vi ikke til at lave noget. Jeg har ikke behov for et kort, hvis jeg ved, hvor vi skal hen,« siger Greg Godbout og fortsætter:

»Man skal have den vision, og så kan man bekymre sig om det næste trin. Man skal ikke tænke på nummer to til nummer 100 trin. Man spekulerer på trin to efter trin et. Det virker bare bedre, det er nemmere og det giver færre konflikter.«

Det med de færre konflikter hænger sammen med, at hvis alle 100 trin er i spil fra starten, så vil alle diskutere de enkelte trin, forklarer Greg Godbout. Og det er spild af tid, ikke mindst fordi, det kan vise sig, når projektet er slut, at trin 50 - 100 måske slet ikke var nødvendige.

For at nå Nordstjernen i sidste ende, så er det vigtigt at forskellige funktioner i virksomheden er involveret i projektet. Forskellige funktioner er i denne sammenhæng eksempelvis it-folk, den finansielle direktør - der måske skal bekoste projektet - og så fremdeles.

Pointen i den sammenhæng er, at folk - der må antages at kunne udfylde deres almindelige funktioner i organisationen - skal finde ud af at fokusere på målet i fællesskab i stedet for kun at fokusere på de enkelte funktioner, de også varetager i organisationen.

»Alle er sammen om det. Og det er forresten meget sjovere at arbejde på den måde. Når man tilsidesætter sin funktion - den er vigtig, men forventelig - og man faktisk er fokuseret på missionen, så bliver folk meget mere motiverede og stolte,« lyder slutsalutten fra Greg Godbout.

Følg forløbet

Kommentarer (5)

Claus Juul

Hvis jeg forstår budskabet korrekt, så kan offentlige projekter af en vis størrelse ikke være ægte agile projekter.

Offentlige projektet af en vis størrelse skal have et budget godkendt før igangsættelse, at kende alle omkostninger må også betyde at man skal kende alle forhold inden man går i gang, hvis man kender alle forhold inden igangsættelse er der vel ingen grund til ikke at vælge vandfaldsmodellen.

Bjarne Nielsen

Et overset forhold er, at hvis man har en detaljeret plan, så har man ikke det samme behov for at bemande projektet med ressourcer med det samme overblik, og lyst og mod til at udfordre løsningen. At køre agile stiller større krav til projektdeltagerne aktivt er med til at holde retningen, hvis det ikke skal køre helt af sporet.

Så, hvis pris er vigtigere end kvalitet, hvis man tror at udvikling kun er en teknisk disciplin og hvis man ikke har overskud til at gå fuldt ind i udviklingen, så er man nok bedst tjent med ikke at vælge agilt.

At man så får det, som man har bedt om og at det sjældent er det, som man tror at man bad om - og at det i hvertfald ikke det, som man i virkeligheden har brug for, er så en anden snak.

Henrik Størner

Offentlige projektet af en vis størrelse skal have et budget godkendt før igangsættelse, at kende alle omkostninger må også betyde at man skal kende alle forhold inden man går i gang, hvis man kender alle forhold inden igangsættelse er der vel ingen grund til ikke at vælge vandfaldsmodellen.

Jo netop - for afdækningen af "alle forhold" koster en herregård, og der er alligevel ALTID noget som bliver overset.

Reelt har de fleste IT projekter kun behov for 3 ting for at kunne sættes i gang:
* Hvad er - i prioriteret rækkefølge - de 5 vigtigste funktioner der skal løses
* Hvor mange penge har vi
* Hvor meget tid har vi

Hvis man forsøger at lave mere detail-specifikation er det bare spild af tid/penge, for du får alligevel aldrig implementeret mere end 5 funktioner hvis du skal holde dig indenfor budget og tid.

Og jeg vil ikke protestere hvis nogen siger "3" i stedet for "5".

Når så du har de 5 (3) funktioner klar og kun har brugt halvdelen af budgettet - så kan du begynde at tænke på de næste 5. Ikke før.

Ole Tange Blogger

Hvis jeg forstår budskabet korrekt, så kan offentlige projekter af en vis størrelse ikke være ægte agile projekter.

Og den naturlige konklusion må være, at større projekter derfor skal deles op indtil de er under den visse størrelse. Det er uden tvivl svært, men jeg er sikker på, at man på langt sigt vil blive glad for, at det kun bliver mindre projekter, der kan fejle.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen