ITU-professor: Amatøragtigt forarbejde gjorde EFI og Polsag til IT-skandaler

EFI blev en skandale, fordi man digitaliserede en alt for kompleks gældsinddrivelse, og Polsag fordi politiet ikke havde kortlagt deres opgaver, lyder det fra professor Søren Lauesen, IT-Universitetet.

Der er rigtig meget at lære af it-projekter som EFI (SKAT’s inddrivelsessystem), PolSag (Politiets sagssystem) og Rejsekortet, mener professor på IT-Universitetet Søren Lauesen. Han har i 20 år har undersøgt offentlige it-projekter.

I denne artikel, som ITU har udarbejdet og som Version2 har fået lov til at udgive, giver Søren Lauesen sine bedste råd til at undgå flere it-skandaler.

Men lige som ved mange alvorlige flyulykker, er det ikke én ting, der går galt - men flere:

»Det er svært at se på it-projekterne og sige, at der er en eller to faktorer, som gør, at projekterne går galt. Der er oftest flere konkurrerende dødsårsøger,« siger Søren Lauesen, der på ITU underviser på kurset Anskaffelse og Kravspecifikation.

»Et gennemgående problem for alle projekterne er, at man ikke kan finde ud af at skrive kravspecifikationen, så brugernes og forretningens behov dækkes. Det har været gældende både i EFI-sagen, PolSag og Rejsekortet. Men der er også mange andre årsager til, at it-projekterne sejler,« siger Søren Lauesen ifølge ITU-artiklen.

Derfor gik EFI galt

Den største udfordring for EFI-projektet var, at man havde undervurderet, hvor mange gældstyper, der fandtes.

Derudover introducerede it-systemet en række nye arbejdsgange hos kommuner og andre myndigheder, som brugerne slet ikke var klædt på til. Endelig forsøgte it-systemet at erstatte en ekspertise i form af pantefogeden, som ikke kunne erstattes.

»Projektet var dødsdømt fra start, fordi man ikke havde styr på kravspecifikationen og fejlvurderede kompleksiteten. Man var simpelthen ikke klar over, hvad systemet skulle gøre. Det viste sig, at man skulle programmere 400 gældstyper, der hver havde 600 regler, og så skulle man teste, om systemet håndterede sagerne korrekt. Det var umuligt, og derfor nåede man ikke at teste færdig, før man under politisk pres satte systemet i drift,« fortæller Søren Lauesen.

EFI-systemet var også baseret på en række nye arbejdsgange. F.eks. skulle kommunerne nu indberette deres gældskrav og indsende dokumentation direkte i systemet.

Det resulterede i, at mange gældsposter blev registreret i systemet uden dokumentation, fordi EFI ikke testede, om den nødvendige dokumentation blev sendt med.

Hvis ikke dokumentationen var med, kunne gælden slet ikke inddrives.

Tidligere opkrævede kommunerne deres egen gæld med deres egen pantefoged og havde styr på den opgave helt nede i de praktiske detaljer.

»Tidligere kunne pantefogeden f.eks. gå ned på stamcafeen og foran venner bede skyldneren betale sit udestående. Det var effektivt, men det kan et it-system ikke. Pantefogeden kunne også banke på hos den gældsramte familie med en pludselig forhøjet el-regning og snakke med dem om el-forbrug. Det kan et it-system ikke. Socialforvaltningen kunne tage hensyn til alkoholikeren, der netop var kommet på benene og skåne ham for at blive stævnet for manglende børnepenge. Det kan et it-system heller ikke. Dermed havde man lavet et system, der ikke kunne inddrive gæld, mens man havde fyret de pantefogeder, som faktisk havde gjort et fint arbejde,« fortæller Søren Lauesen.

Det kan vi lære af EFI:

  • Skriv en problemorienteret kravspecifikation, så behovene dækkes. Skitsér en løsning, men lad den være til inspiration og ikke et krav. En problemorienteret kravspecifikation beskriver hvilke kommende arbejdsopgaver systemet skal støtte, og hvilke problemer man har i dag. Den beskriver også de forretningsmæssige mål, og hvilke krav der sikrer, at de nås.
  • Høst ikke gevinsten (fyring af pantefogederne), før den er nået. Dette kunne være undgået ved korrekt risikostyring.
  • Lav et tidligt bevis på, at det er muligt. Man kunne f.eks. have startet med et par gældstyper, f.eks. dem hvor det økonomiske potentiale var størst.

Derfor gik PolSag galt

Projektet med Politiets nye sagsbehandlingssystem havde også en række sygdomme, som tilsammen gjorde, at systemet fik dødsstødet, før det overhovedet blev taget i brug.

»Politiet havde oprindelig lavet nogle forretningsmæssige mål og en cost-benefit-analyse. Anbefalingen var, at man købte et ESDH-system og lavede enkelte tilpasninger i det, så det kunne støtte Politiets arbejde. Men den løsning ville kræve, at man tilpassede arbejdsopgaverne til systemet. F.eks. kunne man ikke forvente, at de nye skærmbilleder ville være magen til de gamle, man havde. Men Politiet glemte de forretningsmæssige mål undervejs og omformulerede målet til, at man skulle have et system magen til det gamle - blot ”mere moderne”,« fortæller Søren Lauesen.

Politiet havde ikke gjort sig klart, hvad systemet skulle kunne, hvilket kom frem under møder med leverandøren.

»40 politimænd mødte op og fortalte enstemmigt, at de ikke kunne fortælle om deres arbejdsopgaver, fordi de var fortrolige. Leverandøren kunne derfor ikke se, hvordan politiet skulle bruge ESDH-systemet, og hvilke tilpasninger der var nødvendige. Senere viste det sig, at fortroligheden blot var en undskyldning. Den egentlige årsag var, at de ikke selv havde kortlagt deres opgaver. Her tre år efter har de dog fået kortlagt arbejdsopgaverne ved hjælp af problemorienterede krav,« siger Søren Lauesen.

Stik imod anbefalingen blev resultatet, at man udbyggede ESDH systemet med cirka 100 skærmbilleder, der lignede dem, politiet havde i forvejen, hvilket komplicerede leverandørens opgave, fordi de ikke passede ind i systemet. Det betød 97.000 linjer mere kode i projektet.

»Da det, der svarer til Digitaliseringsstyrelsen, kiggede på projektet, kunne ingen pege på de økonomiske gevinster, men man kunne derimod konstatere, at driftsudgifterne blev femdoblet, og det blev besluttet at lukke projektet,« fortæller Søren Lauesen.

På det tidspunkt havde projektet kostet Politiet henved en milliard kroner.

Det kan vi lære af PolSag:

  • Undersøg behovene og beskriv dem som problemorienterede krav.
  • Husk de forretningsmæssige mål gennem hele projektet. Ved hvert styregruppemøde skal man vurdere, om målene stadig stemmer overens omkostningerne.

Derfor fik Rejsekortet en svær start:

Der har også været en række udfordringer i projektet med Rejsekortet, som andre kan lære af. En udfordring var, at leverandøren troede, at han blot skulle levere en standardløsning, som han havde gjort mange andre steder i verden.

»Leverandøren troede, at han blot skulle stille de nødvendige webservices til rådighed og lade lokale SW-huse sørge for kortsalg, regnskab, kundeservice osv. F.eks. stod der i kravspecifikationen, at der skulle være en ”funktion til at rapportere stjålne kort”, og her troede leverandøren, at det var en webservice. Men kunden forventede, at det var drift af et kontor med kundeservice,« forklarer Søren Lauesen.

Tidligt i projektet skulle leverandøren fremlægge en løsningsbeskrivelse. Den var meget teknisk og viste stort set bare, hvilke servere der skulle være og et par skærmbilleder, der viste status af de forskellige servere.

»Kunden syntes ikke, det var nok, men vidste ikke, hvad man normalt forventer af en løsningsbeskrivelse. Han gjorde derfor ikke vrøvl, men tænkte, at leverandøren jo havde lovet at levere. Så man måtte jo vente og se, hvad han leverede. Da det endelig skete, var det helt ved siden af. Revisoren kunne f.eks. slet ikke godkende det regnskabsmæssige, og revisionssporet var tabt,« fortæller Søren Lauesen.

Ifølge kontrakten skulle der også udføres usabilitytest, hvilket man gjorde, men leverandøren nægtede at rette problemerne.

»Leverandøren mente ikke, at det stod kontrakten, at han skulle gøre det. Kunden mente derimod, at det var underforstået og normal dansk praksis. Leverandøren gav sig, ligesom han også havde gjort for de andre uoverensstemmelser, men tabte nok omkring 500 millioner kroner, mens kundens udgifter kun var lidt over budgettet,« fortæller Søren Lausen.

Det kan vi lære af Rejsekortet:

  • Beskriv de arbejdsopgaver, som systemet skal støtte. Bed leverandøren beskrive, hvordan hans system støtter opgaverne.
  • Vær ikke bange for at sige, at du ikke forstår løsningsbeskrivelsen. Stil krav om, at den skal vise de skærmbilleder, som systemet vil have, og kontroller, at de er testet for usability.

De ti mest almindelige konkurrerende dødsårsager

Nedenfor er Søren Lauesens liste over ti mest udbredte konkurrerende dødsårsager i større it-projekter.

Listen er baseret på Søren Lauesens undersøgelser af projekter som SKAT’s inddrivelsessystem (EFI), Politiets sagssystem (PolSag), Rejsekortet, elektronisk tinglysning (eTL), Hovedstadens Sygehusfællesskab (H:S) med flere.

  • Sætter sig ikke ind i brugernes behov (skaber ikke win-win).

  • Ved ikke, hvordan man skal skrive kravene, så de dækker behovene.

  • Høster gevinsten, inden den er opnået.

  • Ingen forretningsmæssige mål – eller glemmer dem undervejs.

  • Kræver ind og tror, at det er gratis.

  • Tør ikke sige til leverandøren, at de ikke forstår hans løsningsforslag.

  • Skridt for skridt i grøften uden at det opdages.

  • Teknologier oversælges f.eks. SOA eller ”alt skal være webbaseret”.

  • Leverandør for optimistisk – den der vinder lyver.

  • Pengene slipper op og parterne skændes i stedet for at samarbejde.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (74)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anne-Marie Krogsbøll

"»Projektet var dødsdømt fra start, fordi "man" (min fremhævning) ikke havde styr på kravspecifikationen og fejlvurderede kompleksiteten."

Analysen lyder fornuftig, men jeg sidder og undrer mig.
Hvem er "man" i denne forbindelse?

Det lyder i artiklen som om, det er en sag mellem politifolk/skattefolk/rejsekortsfolk og leverandørerne, og at disse politifolk/skattefolk/rejsekortfolk ikke har gjort deres forarbejde og opfølgende arbejde - og at kommunikationen mellem disse politifolk/skattefolk/rejsekortsfolk og leverandørerne er gået galt.

Har disse institutioner ikke en IT-afdeling, hvis top-ledelse skal fungere som formidlere/mæglere mellem områdets fagfolk (politi, skattefogeder, trafikfolk) og IT-leverandørerne? Er det ikke disse IT-toplederes opgave at sørge for, at de i artiklen fornuftige forudsætninger for gode projekter er opfyldt, inden man sætter så store projekter i gang?

Umiddelbart lyder de opridsede forudsætninger som indlysende selvfølgeligheder - vel noget enhver projektleder arbejder ud fra, skulle man tro (jeg er ikke projektleder - could be wrong). Så hvad har disse institutioners IT-topfolk foretaget sig i disse projekter? Var de på ferie den dag projekterne blev planlagt?

Henrik Dalsager

Det er ikke noget nyt, at politikerne er utålmodige og handlingslystne.

Min kone arbejder i en afdeling i en kommune og fortæller jævnligt om en bestyrelse eller direktion der bestiller analyser af dette og hint, "til næste møde".

Hvilket betyder at der tit kun er en eller to uger til at lave dem (når analyserne skal på dagsordenen som bilag, og dagsordenen skal ud til tiden.)

Det er typisk opgaver som: "konsekvenser for ældreplejen ved besparelser på x kroner" eller lign. Som jo mildest talt er analyser der faktisk kræver at man laver en reel vurdering af hvilke centre der kunne fusionere eller hvilke der kunne flyttes til billigere bygninger og så videre. Lovgivning, økonomi, medarbejderes aftaler, organiseringer, lokalpolitiske beslutninger om placeringer af afdelinger og så videre.
Altså ting der burde kræve et par ansatte i fuld tid i nogle måneder.

Det skal selvfølgelig laves ved siden af den normale drift, da ingen af afdelingerne må have budgetter til ansatte der laver opgaver som administrationen burde.

Analysernes kvalitet bliver derefter, og det samme gør kvaliteten af de politiske beslutninger.
Der er forresten sjældent overblik i de øverste lag over hvilke afdelinger der ved hvad om hvad, og hvem der i praksis drifter hvad for hvem.
Så odds er at de relevante afdelinger der ikke er direkte i linjen mellem kerneopgaven og ledelsen ikke bliver hørt, før efter analysen er lavet og diskuteret og pågældende afdeling selv snubler over beslutningspapirer.

Det gælder afdelinger som f.eks. "teknik og miljø", eller IT.

Det er ikke uhørt at man beslutter sig for at bruge en ios baseret app til at hjælpe med medicinstyring og en android app til vagtplanen, og insisterer på at begge dele skal virke for plejecenter, og hjemmepleje, mens afdelingerne i forvejen kører surface tablets, der kun har wifi..

Jeg kan kun tro at de samme dynamikker gælder for de store IT projekter.

Så politikkere eller ledelse får en ide om noget IT sovs, og vil straks vide om det er en god ide.
Derfor følger vildt korte tidsrammer til at undersøge mulighederne, og ingen budget til arbejdet.
Så en forhastet beslutning om udbud, baseret på det materiale der trods alt er fremstillet af afdelingen der blev spurgt.

Da det nye magiske IT koster mange penge skal udbuddet så vendes i det politiske lag, og da de ikke forstår konsekvenserne af deres valg, og ikke har brugt penge og tid på at få det analyseret, vinder den billigste, eller kendteste, eller den leverandør med den flotteste sælger.

Så medmindre opgaven kan løses med en hyldevare, må udviklerne selv analysere området og håbe de kan lave et eller andet som ligner det man gerne vil have.

Det kommer aldrig til at virke godt.

Anne-Marie Krogsbøll

Tak for gode svar, Ebbe Hansen og Henrik Dalsager.

Det undrer mig bare, at artiklen for mig ser ud til helt at springe denne del af problematikken over - at "man" åbenbart går uden om de relevante fagfolk i IT-afdelingen (som vel findes?), når den slags projekter sættes i gang.

Og i Atea-sagen er det jo netop IT-afdelingens topfolk, der har været på tur m.m. med Atea i forbindelse med nogle store indkøb. Så hvorfor har disse topfolk (eller deres forgængere) ikke også sikret, at der var styr på de grundlæggende forudsætninger for projekter som PolSag, som opridses i artiklen? Er det ikke det, de er ansat til?

Hvis det skyldes politisk pres, for at det skal gå hurtigt, så er "man" vel politikerne. Men det fremgår ikke af artiklen, at det er der, problemet ligger - at intuitionernes ledelser simpelthen vælger at forbigå IT-topfolkene, fordi det skal gå hurtigt. Det er da interessant, da man så kan spørge sig selv om, hvad vi skal med disse topfolk (i IT-afdelingen eller i institutionernes ledelser).

Frithiof Jensen

Analysen lyder fornuftig, men jeg sidder og undrer mig.


Også her, Hvad med leverandören? Det lyder dybt bizart at

40 politimænd mødte op og fortalte enstemmigt, at de ikke kunne fortælle om deres arbejdsopgaver, fordi de var fortrolige.

og at leverandören blot siger "NåJa, men så laver vi eet eller andet - i stedet for: Vi kan ikke levere projektet hvis der ikke er fuld opbakning til det, kom tilbage når det er löst".

Axel Kellermann

Min erfaring (fra Politiet og Kulturministeriets institutioner) er at beslutninger om IT træffes på niveauer 2-3 niveauer over den sidste person med IT-kompetencer. Det vil sige at de vigtige beslutninger tages uden at der er de nødvendige kompetencer til stede. Dette betyder igen at muligheder og konsekvenser ikke er belyst nuanceret nok. Samtidig støder man på kontrolforanstaltninger der ligeledes ikke kommer fra sagkyndige personer, som derfor ofte er ude af kontekst og dermed ikke kan opfyldes med fornuft. Resultatet er prioriteringer, der er direkte usunde for forretningen og den egentlige sikkerhed.

Anne-Marie Krogsbøll

Axel Kellermann:
Ja, det lyder rigtigt, men spørgsmålet er så, hvorfor institutionernes topledelser vælger at gå uden om kompetencerne indenfor IT, når de skal træffe beslutninger om store IT-projekter. Det er da mærkeligt, synes jeg. Og det spørgsmål synes jeg ikke, at artiklen besvarer.

Er institutionernes topledelser under politisk pres? Så burde det fremgå af analysen som den overordnede årsag til miseren.

Eller gider institutionernes topledelser bare ikke at have nogen til at blande sig i deres beslutninger (magtfuldkommenhed eller korruption?)? Så burde det fremgå som den overordnede årsag.

Der burde være spurgt direkte ind til, hvor institutionernes IT- afdelinger er henne i processen, og til hvorfor de ikke har været tilstrækkeligt inddraget til at undgå disse ulykker.

Det altså meget mærkeligt at læse en hel artikel med mange gode analyser, og så er IT-afdelingerne tilsyneladende slet ikke inddraget - kun institutionernes topledelser og leverandørernes sælgere?

Vi må ikke håbe, at det er det samme mønster med kampflyene...

Gert Madsen

Jeg synes at beskrivelsen er alt for flink overfor rejsekortet.

Her ser man i udpræget grad den usympatiske adfærd, at man benytter "digitalisering" til at vælte arbejde og risiko over på den bruger, som man egentlig er sat i verden for at servicere.
Det handler ikke om at undlade at sætte sig ind i brugernes behov, men om at sætte brugerne til at servicere ens egne behov/ønsker.

Det er måske ikke den vigtigste grund til at der er brændt mia. af i projektet, men det er grunden til at jeg aldrig kommer til at se det som en succes.

Jesper Frimann

Vi må ikke håbe, at det er det samme mønster med kampflyene...


Det er jo ikke kun når det kommer til IT. Der er IMHO i både toplaget i det offentlige og mange dele af det private en resistens/fjendtlighed mod faglighed.
Måske fordi fagligheden har det med at tænke mere langsigtet, og i vi har i verden lige nu et ekstremt kortsigtet perspektiv, hvor man tænker i 'aktiekursen fra dag til dag', eller at ens mål.. altså hvad man får løn og forfremmelser for er baseret på månedsmål.
Der er også en mangel på konsekvens for beslutningstagere. Måske lige pt. bedst illustreret med LedelsesExit i toppen af britisk politik efter Brexit.

Man har i det offentlig outsourced sin IT-viden. Da man solgte Kommune Data og DataCentralen forsvandt der jo tusindvis af tusindvis af mande(m/k)år af IT-viden der var fagspecifik inden for offentlig administration. Sådan et hul fylder man bare ikke lige op igen. Og de 'skelet' org der blev tilbage var lille, overbebyrdet med opgaver og havde en 'mission impossible'. Og IT-afdelingerne.. der var det der ofte var tilbage var jo IT på klient siden.
Det er jo sådan set først inden for de sidste par år efter IT-skandaler for mange mange milliarder at man har staffet op igen/er i gang med det.
Business casen på salget af Kommune Data og DataCentralen... ja.. ... ... ...

// Jesper

Anne-Marie Krogsbøll

Søren Lauesens 7 gode råd:
•Skriv en problemorienteret kravspecifikation, så behovene dækkes. Skitsér en løsning, men lad den være til inspiration og ikke et krav. En problemorienteret kravspecifikation beskriver hvilke kommende arbejdsopgaver systemet skal støtte, og hvilke problemer man har i dag. Den beskriver også de forretningsmæssige mål, og hvilke krav der sikrer, at de nås.
•Høst ikke gevinsten (fyring af pantefogederne), før den er nået. Dette kunne være undgået ved korrekt risikostyring.
•Lav et tidligt bevis på, at det er muligt. Man kunne f.eks. have startet med et par gældstyper, f.eks. dem hvor det økonomiske potentiale var størst.
•Undersøg behovene og beskriv dem som problemorienterede krav.
•Husk de forretningsmæssige mål gennem hele projektet. Ved hvert styregruppemøde skal man vurdere, om målene stadig stemmer overens omkostningerne.
•Beskriv de arbejdsopgaver, som systemet skal støtte. Bed leverandøren beskrive, hvordan hans system støtter opgaverne.
•Vær ikke bange for at sige, at du ikke forstår løsningsbeskrivelsen. Stil krav om, at den skal vise de skærmbilleder, som systemet vil have, og kontroller, at de er testet for usability.

Det er jo helt indlysende gode råd. Men hvorfor er der ikke et godt råd, der hedder:
"Husk at inddrage IT-afdelingen, både i opstartsfasen og i forhandlingerne med leverandøren". Så burde de alvorligste forståelsesproblemer, som f.eks. "Politiet havde ikke gjort sig klart, hvad systemet skulle kunne, hvilket kom frem under møder med leverandøren." vel ikke kunne opstå? For det er vel børnelærdom for IT-folk, at man må starte med at gøre sig klart, hvad systemet skal kunne? Det er da i hvert fald en snublesten, jeg har hørt omtalt mange gange før - at man har sprunget dette punkt over. Og det kan og skal jo overstås inden man overhovedet lægger en sådan opgave i udbud, går jeg ud fra?

Jeg spekulerer bare over, om topledelsen er idioter, siden de ikke kan se det, vi andre kan se, eller om de er blevet lidt for gode venner med nogle leverandører, så de glemmer at inddrage deres egne forhåbentlige fagfolk på området?

Kunne forklaringen være, at topledelsen i institutionerne en dag får besøg af lobbyister (eller støder på dem på golfbanen), der siger noget i retning af "kunne det ikke være rart, hvis jeres system kunne ....bla bla... bla bla..."... og det kunne selvfølgelig være rart, det siger sig selv, og pludseligt er beslutninger taget på topplan, uden at man overhovedet har inddraget relevante afdelinger. Det ville måske passe med nogle af de erfaringer, der beskrives i nogle af kommentarerne.

Jesper Frimann

For det er vel børnelærdom for IT-folk, at man må starte med at gøre sig klart, hvad systemet skal kunne? Det er da i hvert fald en snublesten, jeg har hørt omtalt mange gange før - at man har sprunget dette punkt over. Og det kan og skal jo overstås inden man overhovedet lægger en sådan opgave i udbud, går jeg ud fra?


Igen så er IT-folk et meget meget vidt begreb, lidt som sundhedsfagligt personale.
Der er stor forskel på at vaske en patient og så lave hjertekirurgi.

En typisk offentlig IT-afdeling er ikke is stand til at køre et milliard stort offentlig udbud på et core IT-system. Det kræver at man har nogle kompetencer, som tit er blevet outsourced, og hvis man har dem, så har man hverken penge eller nok folk til at man kan afsætte tid nok til, at de kan udføre et ordentligt stykke arbejde.

// Jesper

René Nielsen

Når man byder på et udbud, så er man som leverandør nødt til byde på baggrund af udbudsmaterialet også selvom man sidder med fornemmelsen af "bilen mangler en motor".

Fordi lægger du prisen på en motor oveni - kan du være sikker på at at tabe - for de andre bydere på udbuddet gør det ikke. Den slags ordnes via Scopemanagement og ekstraarbejder.

I de udbud jeg har været med i, kommer der altid en række store flyttekasser fyldt med ringbind over hvordan man "gør i dag" og det er underforstået at sådan skal de blive ved med at være.

Når man så holder møder med de folk som rent funktionelt skal sige god for systemet, så er det første de siger, at de ikke har læst eller på anden måde sat sig ind i løsningen, selvom de har 3-4 uger til at læse de knap 50 sider som beskriver hvad der skal ske i systemet.

Det er svært at sikre fremdrift under sådanne betingelser og det bør ikke overraske nogen, at når tiden til UAT'en kommer, at der så er "huller" i systemet. Det kan ikke være anderledes når projektet og projektplanen på den måde saboterers af den part som skal leverer viden, ved konstant at møde uforberedt op og ikke leverer de aftalte leverancer til den aftalte tid.

Jeg er på ingen måde overrasket over eksemplet med de 40 politifolk men jeg tror ikke der er brug for en IT havarikommission, for den vil blot konstaterer hvad vi ved i forvejen.

Det der brug for er holdningsændring i det offentlige og at deres chefer gør noget imod at folk møder uforberedt op til sådanne møder. Eksemplet med de 40 politifolk siger jo alt De kommer uforberedte til møde og stikker en løgn for at dække over manglende forberedelse - og det var politifolk vi talte om. Man behøver ikke at være IT professor for at vide det projekt "går i hegnet"..

En IT havarikommission vil blot være en narresut, fordi vi kan godt ønske os nogle andre politikkere, men at forestille sig at politikkere ikke vil ændre lovene i løbet af f.eks. en 12-månders periode, er naivt - vi har ikke set den sidste Amadeus, PolSag eller EFI endnu.

Anne-Marie Krogsbøll

Tak for forklaring, Jesper Frimann. Det er jo sørgeligt. Jeg har åbenbart en helt forkert forestilling om, hvad en IT-afdeling i så store institutioner som politiet og Skat, kan. Det forekommer mig bare, at en del af de 7 bud ikke engang kræver IT-kundskab. Det lyder som generelle gode råd, når man har med store projekter at gøre. Og det er i hvert fald snublesten, som jeg har hørt selv menige IT-ansatte i omgangskredsen beskrive som særdeles almindelige, hver gang der skal sættes projekter i gang. Det er derfor, det undrer mig, at det er det igen og igen kan gå så galt.

Og da jeg har svært ved at forestille mig, at disse topledelser er direkte idioter, så er det som om, der mangler forklaringen på, at de for gud ved hvilken gang gør de samme fejl. Der er det, at jeg ikke kan frigøre mig fra tanken om, at der kan være konkurrerende interesser, der forvirrer dem. At en stor del af dem i deres stille sind går og tænker "det her går galt", men at "noget" får dem til at tie stille med deres viden og betænkeligheder.

Det er det, jeg savner lidt fokus på i artiklen, selv om der er mange gode observationer i den. Det store dyr i åbenbaringen: Hvorfor er det, man gør de samme fejl om og om igen, selv om der sandsynligvis ikke er tale om idioter, og selv om "man" sandsynligvis udmærket kender disse basale projektregler udmærket i forvejen - for mig at se kræver de ikke specialistviden.

Hvad er det, der gør det umuligt at lære af erfaringerne fra alle de tidligere projekter, der også er gået galt?

Hvis ikke man får skovlen under det spørgsmål, så vil historien vel bare gentage sig, selv om der er gode råd i artiklen?

Det er muligt, at du har ret - at man simpelthen har fået jaget alle de kompetente folk væk - inkl. dem som ikke er IT-folk, men som bare har erfaringer med at styre projekter af en vis størrelse - men så mangler den grundlæggende forklaring i artiklen. Og så må de 7 bud vel suppleres med det første og vigtigste: "Lad være med at skille jer af med alle de gode og dygtige folk, det kræver at gennemføre den slags store projekter".

Erik Herskind

Hvis det skyldes politisk pres, for at det skal gå hurtigt, så er "man" vel politikerne. Men det fremgår ikke af artiklen, at det er der, problemet ligger


Nej det fremgår ikke af artiklen, for den handler om fejlene, ikke om hvem, der begik dem. Artiklen giver mulighed for at lære af de fejl, der allerede er begået.
Og nej, det er ikke topledelsernes opgave at beskrive, hvad systemerne skal kunne. Det er dem, der kender opgaverne, der skal beskrive dem.
Forhåbentlig er der indskrevet i kampflyenes opgaver, at de skal kunne flyve...

Jørn Wildt

Forhåbentlig er der indskrevet i kampflyenes opgaver, at de skal kunne flyve...

Og forhåbentligt køber man dem som standard system uden ekstra opgaver som fx at skulle kunne flyve baglæns eller have særlig boks til kongehusets gravhunde. I modsætning til Polsag: "Stik imod anbefalingen blev resultatet, at man udbyggede ESDH systemet med cirka 100 skærmbilleder, der lignede dem, politiet havde i forvejen, hvilket komplicerede leverandørens opgave, fordi de ikke passede ind i systemet."

Anne-Marie Krogsbøll

Og nej, det er ikke topledelsernes opgave at beskrive, hvad systemerne skal kunne. Det er dem, der kender opgaverne, der skal beskrive dem.


Men det er vel topledelsens opgave at sikre, at disse opgaver er beskrevet, inden man går videre med projektet? Hvad er ellers topledelsen opgave?

Det er bestemt al ære værd, at man analyserer forløbene og beskriver, hvor det er, det er gået galt - det er absolut helt nødvendigt, så det er fint arbejde på det punkt.

Men når så fejlene ser ud til at være så banale, som det beskrives - at man ikke forbereder sig før møder, ikke har klarlagt behovene, ikke tør spørge ind til uklarheder osv. - så er det, jeg tænker: Har vi ikke hørt det mange gange før? Hvorfor er det så, at det er gået galt igen?

Og hvis forklaringen på dette er, som Jesper Frimann beskriver, at man har fyret alle de gode folk, der har forstand på den slags - så har man åbenbart glemt det niveau i artiklen. Men det er vel i så fald den allervigtigste lære, man kan drage af disse forløb - at man ikke kan klare sig uden ekspertise i både de faglige processer i institutionen, IT-ekspertise og projektledelsesekstpertise. At hvis man privatiserer alle disse funktioner, så bliver man en "sitting duck" for næste IT-skandale.

Poul-Henning Kamp Blogger

Beklager Rene, men du lyder lidt som en alkoholiker der 'Fandme ikke har brug for nogen der blander sig!'

Jo, når vi som samfund har smidt "nogle milliarder" ud på IT projekter som intet er blevet til, er der i allerhøjeste grad brug for en faglig udredning af hvad der gik galt, så alle parter, politikere, administratorer og leverandører kan lære af fejltagelserne så vi ikke gentager dem.

Havarikommisioner har snart 100 år på bagen og vi ved af erfaring at de virker.

Jørn Wildt

Hvad er det, der gør det umuligt at lære af erfaringerne fra alle de tidligere projekter, der også er gået galt?

Jeg kan godt forstå din frustration, men jeg tror ikke der er noget enkelt svar på det. Søren Lauesens ti bud er måske det nærmeste man kommer. Hvis du tager dem én for én, så peger de mange steder hen - fjollede udbudsregler ("Leverandør for optimistisk – den der vinder lyver."), teknologiblindhed ("Teknologier oversælges f.eks. SOA eller ”alt skal være webbaseret”."), helt almindelig manglende selvsikkerhed og forståelse ("Tør ikke sige til leverandøren, at de ikke forstår hans løsningsforslag."), politisk ignorance ("Høster gevinsten, inden den er opnået.") osv. osv. Vejen til en dårlig løsning er brolagt med gode intentioner og dårlig eksekvering.

Store IT leverancer er en tværfaglig operation, der kræver god styring, god ledelse, god IT forståelse, forandringsparathed og en god potion politisk slagstyrke. Det kan være svært at finde alle disse evner samlet i ét projekt.

Så kan man komme med nok så mange gode bud - men hvis der ikke er de tværgående kompetencer til at udleve dem, så hjælper det ikke.

Jesper Frimann

Hvorfor er det, man gør de samme fejl om og om igen, selv om der sandsynligvis ikke er tale om idioter, og selv om "man" sandsynligvis udmærket kender disse basale projektregler udmærket i forvejen - for mig at se kræver de ikke specialistviden.


Jeg tror du overvurderer groft hvor 'kloge' folk i TopManagement (tm) er.
Det er IMHO vigtigere at være 'skruppelløs', end dygtig hvis du vil opad i ledelsespyramiden.
Desuden er mange af dem bundet på hænder og fødder, af urealistiske mål, alliancer og et fokus på kortsigthed.
Den erfaring jeg har gjort mig de sidste 5-6 år er, at teknikken er det mindste problem. For at citere min 'reserve storebror' så kan man alt med IT. Det er bare et spg. viden, tid og Penge altså ressourcer.
Det problem jeg som regel støder på for at kunne udføre mit job ordentligt er 'ledelsesrelaterede' problemer.

F.eks. at man har takket en organisations model af, så der er fred i Ledelseslaget. Problemet er så bare at den organisation man har lavet, er inkompatibel med det man ønsker at gøre rent forretnings mæssigt.

Eller at din leder er bange for sine medarbejdere. Ja det er intimiderende at være leder for 10 Senior/Lead XXX'er med 200+ års erhvervserfaring og en samlet IQ på den rigtige side af 1450. Og at det bedste så er at få fyret nogle af de bedste og intimideret resten. Så når du skal videre op i pyramiden, så har de ikke lavet alt for mange problemer for dig.. som f.eks. at skrive rapporter der afslører fejlinvesteringer.

Og så er der også den klassiske.. nu har vi arbejdet her i 30 år.. og sådan har vi altid gjort.. så hvorfor fanden skal pludselig til at dokumentere tingene, eller lave om på den måde vi gør tingene.

Og så det med at turde uddelegere beslutnings kompetence. De bedste beslutninger bliver altså som regel truffet når man har dækket alle de faglige vinkler af.

// Jesper

Thomas Lodberg

Ja, det er nødvendig.

Så længe man bliver ved med at insistere på at leve i et DJØF'iseret millimeterdemokrati, så er det bydende nødvendig at have 240.000 regler blot for hvordan man kan have gæld til det offentlige.
Det samme gør jo sig gældende for rejsekortet, hvor det simpelt hen ikke kan lade sig gøre at lave simple regler for takster i offentlig transport.
Og i sundhedsplejen, hvor personalet har over 50.000 regler de skal kunne huske.
I sidste ende så er det jo os vælgere der bliver ved med at stemme på de samme politikere hver gang. Og så blive overraskede og sure over resultatet.

Jesper Frimann

Nej, jeg argumenter for at der skal ske en holdningsændring og det hjælper en IT havarikommission ikke på.

Jeg er enig.
En IT-havarikommission ville bringe værdi, hvis vi var i en slags normal tilstand, hvor der fejlede et projekt engang imellem.
Nu har Fly-havarikommissions billedet været brugt ret ofte tidligere. Så lad os fortsætte... Man ville jo heller aldrig lade overlade problem løsningen til en havarikommission, hvis det var undtagelsen at en ruteflyvning foregik uden major incidents.

De 10 dødsårsager der beskrives i artiklen er jo et vink med en Storebæltsbro om at der er nogle bagvedliggende root-cause til problemerne.

// Jesper

Anne-Marie Krogsbøll

De 10 dødsårsager der beskrives i artiklen er jo et vink med en Storebæltsbro om at der er nogle bagvedliggende root-cause til problemerne.


Ja, og der er det, jeg spekulerer over, om mon ikke Søren Lausesen også har et bud på "root cause", når han er specialiseret indenfor dette felt i mange år? Er det af en eller anden grund farligt at udtale sig om? Bider han sig i tungen?

Finn Christensen

Det forekommer mig bare, at en del af de 7 bud ikke engang kræver IT-kundskab. Det lyder som generelle gode råd, når man har med store projekter at gøre. Og det er i hvert fald snublesten, som jeg har hørt selv menige IT-ansatte i omgangskredsen beskrive som særdeles almindelige, hver gang der skal sættes projekter i gang...

Du er ganske forvent med, at der f.eks. i nogle fag eksister en lov mod xxx og i et andet fag er der en lov mod yyy (eks. kvaksalveri, vinkelskriveri etc.).

It er en usexet "teenagerknægt med bumser" - så anno 2016 er man endnu juridisk fodslæbende, og "undskylder" samt lapper kun store synlige huller, hvis medierne gider puste sagen op. Samtlige statslige og offenlige styringsorganer er underordnede, underforsynede samt spredt uden en plan og overordnet lovgivning.

Se eksempelvis Registertilsynet uden muskler og magt, og en Digitaliseringsstyrelse, som år for år gerne og troligt giver tilladelse til at XYZ hælder den næste gang it-sovs ud over alle i samfundet, hvis man blot underskriver et stykke papir på "tro og love", og det på trods af at enhver seriøs hacker/svindler/sælger kan lænse din bankkonto eller snuppe et helt register, hurtigere end en jurist kan skrive "§ 4711, Stk. 3 Mumbo Jumbo.."

Dr. Drolles patenterede Magiske It-Sauce fra en multi-milliardindustrikan kan indkøbes, anvendes og installeres uden konsekvenser. Og tilmed kan producenten selv i dag slippe afsted med at fraskrive sig ansvaret for brugen af Dr. Drolles Magiske It-Sauce.

Jesper Frimann

Ja, og der er det, jeg spekulerer over, om mon ikke Søren Lausesen også har et bud på "root cause", når han er specialiseret indenfor dette felt i mange år? Er det af en eller anden grund farligt at udtale sig om? Bider han sig i tungen?


Det har han nok. Men root-cause til hvorfor vi har alle de her IT-projekt problemer ligger jo ikke i 'IT-land'.

Vi har jo også en alt alt for stor del af Militær-Projekter, Sundheds-Projekter, Uddannelses-reformer, Miljø-projekter XXX-reformer/projekter/initiativer... etc. etc. der går galt.

Så ja... hvor mon problemet ligger ?

// Jesper

Anne-Marie Krogsbøll

Enig, Finn Christensen. Men analyser som de i artiklen beskrevne bør vel ikke vige tilbage for "systemkritik", hvis en sådan er påkrævet. De anførte bommerter er jo mest symptomer - ikke egentlige forklaringer på, hvorfor det er sådan. Hvis ressourceproblemer er den egentlige årsag - så skriv det. Hvis korruption er den egentlige årsag - så skriv det. Hvis NPM og dens bonusordninger er årsagen - så skriv det. Hvis privatisering er årsagen - så skriv det. Osv.

Ellers får vi jo aldrig rykket nælden op med roden.

Selvfølgelig vil der altid ske fejl - mange fejl - i så store projekter. Men det beskrevne ligner jo et gennemgående mønster af manglende styring, som må have en bagvedliggende årsag.

Det er måske her, den berømte "trickle Down"-effekt faktisk virker (når den nu ikke virker indenfor økonomien): Den manglende styring i toppen "trickler" hele vejen ned igennem systemet :-) (med katastrofale skandaler til følge).

Finn Christensen

Store IT leverancer er en tværfaglig operation, der kræver god styring, god ledelse, god IT forståelse, forandringsparathed og en god potion politisk slagstyrke. Det kan være svært at finde alle disse evner samlet i ét projekt.

Praktisk taget samtlige dele af den offentlige administration er baseret på drift og ændring af driften i takt med lovgivningen. Så det du efterspørger findes ikke på hylderne.. jo der er gerne nogle ildsjæle, der kan trække en del af læsset, men når det går mod syd, så går flammen ud.

Derfor har leverandøren for det meste både forud for projektet, undervejs og ved aflevering af et projekt en for stor finger med i spillet. Det nævnes også både direkte og inddirekte ifm. de nævnte projekter.

En IT-havarikommission vil uden forudgående overordnet lovgivning og hele kæden af it-minister/departement/styrelser herunder blot blive endnu et løsgående missil, og en underordnet blindtarm uden tilstrækkelige midler, muskler og indflydelse - en sovepude.

Simon Rigét

Dette og mange andre store IT projekter bygger på en dejlig ønskedrøm om at udlicitering til det private erhvervsliv løser alle problemer. Selv briterne, der var meget fremme i skoene med privatisering, har erkendt at det ikke virker for store IT projekter. Problemerne er

  1. Man kan ikke lave en ordentlig kravspecifikation, fordi man ikke kan vide hvad man vil have, før man har det. Det er en iterativ proces.

  2. Man kan ikke beskrive et system så detaljeret at man får det man ønsker sig, uden at skrive koden selv, eller kan pege på eksempler. Det kræver erfaring og indsigt. Det er igen en iterativ proces, hvor brugerne er med i loopet.

Ved stædigt at fastholde en politisk ideologi der ikke virker i praksis, overlader man en masse beslutninger i processen, til medarbejder der hverken har kompetence, overblik eller interesse i at træffe de beslutninger, der bringer systemet i en retning der er til gavn for bruger og samfund.

Kort sagt: put en god ide igennem en forfejlet politisk ideologi; volà så har du alle de gode kendte danske IT projekter fra Amanda, EP og frem til i dag, men stor sandsynlighed for gentagelse i mange varianter.

Løsningen er naturligvis at
1. Bevarer kompetencen i de offentlige IT afdelinger.
2. Betale en anstændig løn, så de gode medarbejder har lyst til at blive der.
3. Udliciterer/tilkøbe små velbeskrevne delopgaver, under ledelse af IT afdelingen.

Jørn Wildt

Den manglende styring i toppen "trickler" hele vejen ned igennem systemet :-) (med katastrofale skandaler til følge).

Det er der vist ikke meget tvivl om er rigtigt: større IT-projekter kræver forandringer og forandringsledelse, hvilket igen kræver støtte fra topledelsen. Hvis topledelsen er fraværende kan organisationen ikke forandres, og hvis organisationen ikke kan forandres, så fejler IT-projektet.

Og hvis IT-projektet ikke kræver forandringer - hvad er så pointen? Forventningen er jo at der skal være en gevinst(*) ved projektet, og hvis alle laver præcist det samme før og efter, så er der li'som ikke vundet noget.

(*) Polsag er åbenbart en undtagelse: "Men Politiet glemte de forretningsmæssige mål undervejs og omformulerede målet til, at man skulle have et system magen til det gamle - blot ”mere moderne"".

Så, jo, topledelsens skal være med. Ikke til at definere detaljerede krav. De skal levere den politiske gennemslagskraft der skal til for at skabe forandringer og plads til nye og bedre rutiner.

Jørn Wildt
Chresten Christensen

Så længe man lave disse stor it-opgaver, begræser man også antallet af mulige leverandøre af løsninger, da der kun er få store firma der er i stand til at løse store it-opgaver.
Man skal i stedet for opdele opgaverne i minder stykker med klare specifikationer, og lad dem være offentlig tilgængelig, eller tilgængelig i en støre kreds. Hvis man samtidig, under opdelingen af opgave, tager med i overvejelsen at der sandsynligvis er andre offentlige indstandser, med samme eller lignende opgaver, og laver en koordinering med dem, og måske lige frem laver en standart for løsninger og opgave specifikationerne, vil man sandsynligvis få en beder og billiger løsning.
Denne job kunne udføres af en kompetent national it styring organ, med samarbejde til EU, for at koordinere med dem.
Hvorfor er det så ikke allerede lavet; tja de store IT-firma har ikke meget interesse i en sådan løsning. De modarbejdet det både med lovlig og ulovlige midler (bestikkelse).

René Nielsen

Beklager Rene, men du lyder lidt som en alkoholiker der 'Fandme ikke har brug for nogen der blander sig!'


Sikke da nogle blomsterne ord. Må jeg være lidt direkte og spørge om hvor mange offentlige IT-projekter du (Poul-Henning Kamp) har deltaget i?

Men jeg mener ikke tiden er til at kigge ud over havet og tænke dybe tanker om hvordan projektet burde havde grebet situationen an og så skrive det i en fin rapport på glitret papir – idet det er sådan jeg ser en IT havarikommission. Med tiden kan det godt være at der bør være en slags IT havarikommission, men lad os starte med fundamentet og få det på plads, før vi bygger tagkontruktionen.

Jeg er sikker på at andre kan bidrage, men til en start skal 1) projektdeltagerne være 100% allokeret til projektet og 2) projektet skal havde de folk som organisationen allernødigst vil undvære, for det er dem om kender ”forretningen” og som kan være med til at ”forme fremtiden”.

Jeg vil nødigt bruge udtrykket ”eksport af idioter” for det mener jeg ikke, for de folk som jeg har mødt på projekter har været flinke og rare menneskerne, men de har grundlæggende ikke fået tid nok til projektet og i en hel del tilfælde havde de ikke nok viden om de emner som de skulle svare på, til projektet.

Det kan jeg ikke tolke som andet end at nogen har prioriteret, at der var noget som var vigtigere end projektet.Fair nok, men er det leverandørens eller projektets skyld? Er det ikke først og fremmest et ledelsesansvar? Måske burde man indføre den engelske belønningsmodel for offentlige ledere - hvor lederne bliver belønnet med alt fra ridderslag til stribet solskin.

Derfor mener jeg at det er uden betydning hvad opgaven hedder, hvis IT projektet ikke får den rette viden, i rette tid og i rette mængde. Og før den slags bliver ændret – tjener det i mine øjne ikke noget formål med en IT havarikommission.

Søren Lauesen

Jeg (Søren Lauesen) ser fejl både hos IT eksperterne, forretningen og politikerne. Fx kan meget få IT-folk skrive problemorienterede krav. Use cases, user stories, agil udvikling, etc. hjælper ikke. Og kommer IT-arkitekterne eller driftsafdelingen med, går det helt galt. Så bliver det dynger af tekniske krav og standarder der fjerner opmærksomheden fra det væsentlige. Hvordan ser problemorienterede krav ud? Se "Vejledning til kravskabelon SL-07". Den viser en fuld kravspecifikation for en elektronisk patientjournal baseret på det princip.

René Nielsen

Så er det bare at jeg forsigtigt spørger, hvor den holdningsændring skal komme fra, specielt hvis vi undlader at undersøge, hvad der går galt.


Det er et godt spørgsmål - Men modsat vil jeg spørge om hvad en IT havarikommission kan bidrage med ift. f.eks. Rigsrevisionens beretning?

http://www.rigsrevisionen.dk/publikationer/2013/92012/

Skulle det hjælpe at en IT havarikommission skrev det samme som Rigsrevisionen?

Anne-Marie Krogsbøll

Tak for svar, Søren Lauesen :-)

Men alligevel:
"»40 politimænd mødte op og fortalte enstemmigt, at de ikke kunne fortælle om deres arbejdsopgaver, fordi de var fortrolige. Leverandøren kunne derfor ikke se, hvordan politiet skulle bruge ESDH-systemet, og hvilke tilpasninger der var nødvendige. Senere viste det sig, at fortroligheden blot var en undskyldning. Den egentlige årsag var, at de ikke selv havde kortlagt deres opgaver. Her tre år efter har de dog fået kortlagt arbejdsopgaverne ved hjælp af problemorienterede krav,« siger Søren Lauesen."

Her er det, jeg synes, at det er meget mærkeligt, at det kan ske. Havde de ikke i god tid fået oplyst, at de skulle klargøre deres opgaver? Havde de været på terrorbekæmpelse i døgndrift i 3 uger i træk, så de ikke har haft en ærlig chance for at udføre opgaven? Har deres nærmeste ledere sagt til dem, at det var endnu en af topledelsens fjollede ideer, og at det ikke skulle prioriteres højt?

Hvordan kan det ske, at 40 politifolk simpelthen ikke udfører deres del af projektet? Og når det sker - hvorfor er der så ikke nogen, der siger "Det går ikke! Vi kan ikke gå videre, før I har udført jeres del af opgaven, så nu sætter I jer en uge på rumpen og løser denne opgave". Eller "det er urealistisk, at vi kan gennemføre dette projekt på en god måde, når vore ressourcer er så pressede. Vi må vente på bedre tider, inden vi går videre." Der savner jeg et spadestik dybere analyse.

Den slags kiks har jo intet at gøre med IT som sådan - det er kiks i ledelsen eller dovne medarbejdere.

At disse offentlige IT-systemer er så kæmpestore, at ingen har rigtigt overblik, og at der derfor vil opstå uforudsete ting - det er én ting. Men at man dummer sig på den måde som det beskrives her - det er der jo ingen god forklaring på - i hvert fald ikke en, som fremgår.

Men dog glædeligt, at man i dette tilfælde har taget ved lære og rettet op på tingene.

Gert Madsen

Skulle det hjælpe at en IT havarikommission skrev det samme som Rigsrevisionen?


Næppe.
Det er så vidt jeg kan se udmærket, hvad Rigsrevisionen kommer frem til, men det er nok ikke sandsynligt at de vil komme på banen særligt ofte.
Formodentlig vil en Haverikommission komme frem til noget tilsvarende. Men en Haverikommission vil kunne behandle væsentligt flere tilfælde, og give nogle linier, som man kan håbe vil få nogle chefer til at tage IT-projekter alvorligt.
Det gør jo ikke noget at man kigger på projekter, hvor man bare har sendt nogle få hundrede millioner i kloarken.
Der er ingen garanti for, at det vil hjælpe at sætte fokus på det. Men det er da bedre end at trække på skuldrene, og med det nuværende spild, skal der kun en lille bedring til, for at det hele har tjent sig hjem.

Jens Bengaard

Der var to ting der faktisk blev gjort rigtigt vedrørende Polsag.

Den ene er, at de satte systemet i pilotdrift på Bornholm inden det blev rullet ud i resten af landet. Det var rædselsfuldt for de bornholmske politifolk, men i det mindste blev de øvrige politifolk forskånet for systemet.

Den anden er, at de valgte at trække systemet tilbage, da resultaterne fra Bornholm kom ind.

Sune Hybert

IT afdelingen aner heller ikke hvordan systemet skal virke. Det gør kun brugerne af systemet. IT afdelinger er vel sjældent gearet til udvikling. De tager sig af support, installationer, indkøb af hardware mm.
Flyt dem fra IT afdelingen ned i den afdeling der skal have nyt system og lad dem være i praktik der i en period, så de kan se, hvad der skal til.

Peter Kyllesbeck

IT havarikommisionen skriver for IT folk og I deres rapporter ville den tekniske substans blive udlagt.


Og hvad så hvis den tekniske substans viser sig at være i orden, men at processen den skal løse ikke er det (og dermed løser teknikken ikke den egentlige opgave)?

Processen skal være klart defineret (og som regel også simplificeret) inden man begynder at hælde en teknisk IT-substans ud over en proces man ikke har defineret (nogen kalder det IT-sovs).
Operationen lykkedes, men patienten døde.

Finn Christensen

...Den manglende styring i toppen "trickler" hele vejen ned igennem systemet :-)

Der er skam ad libitum styring via styringsgrupper, men så længe ens referencegruppe giver bedre point for en anden adfærd end, smulerne der gives for teknik og it-projekt, så spilder vi velmenende og kloge ord. Faglig modvilje, grænsekrige og blindhed kan selv en blindtarm som en havarikommission ikke flytte, men vil alene støje, indtil den bliver smidt på et sidespor.

Husk vores amputerede Finanstilsynet i de go' gamle dage indtil vi fik Finanskrigen - her var der x.xxx mia. på spil. Vi skulle have krak og massedø i sektoren, samt se statens fallit lige ud for næsetippen, før der nølende kom øget personale, både evner og muskler samt fart over feltet, hyppige lovændringer, stramninger, rejsende kontrollanter på landevejen med hyppige tilsyn, seriøse nedskrivninger hos banker.. ;)

Jeg har en drøm.. gid vi lavede den samme seriøse opstramning for vores it over de næste par år og f o r i n d e n krakket.

Markus Hornum-Stenz

spørgsmålet er så, hvorfor institutionernes topledelser vælger at gå uden om kompetencerne indenfor IT, når de skal træffe beslutninger om store IT-projekter. Det er da mærkeligt, synes jeg

Det er måske ikke så svært at forstå, når man tænker over det.
Offentlige beslutningstageres handlekraft er i forvejen underlagt politiske, lovmæssige og økonomiske bindinger.
Der skal ske noget politisk bestemt, det skal være lovligt og må koste x kr.
I den situation er det vanskeligt at forholde sig til de tekniske restriktioner der måtte være i forhold til et IT-projekt, og som tekniker er det svært at skulle levere data til en løbende opfølgning af projektets business case.
Reelt set er de fleste IT-projekter en magtkamp mellem dem som gerne vil lave et system som virker og kan drives i en hverdag (typisk de mennesker som skal bygge, drive og bruge systemet) og dem som gerne vil have et system, som løser en bestemt politisk opgave, typisk en besparelse (dem som bestiller, sælger og køber et system - ofte reelt tre forskellige parter)

Mikkel Lauritsen

Selvfølgelig vil der altid ske fejl - mange fejl - i så store projekter. Men det beskrevne ligner jo et gennemgående mønster af manglende styring, som må have en bagvedliggende årsag.

Root cause er nok nærmest, at der aldrig er nogen enkeltperson eller gruppe bestående af et begrænset antal personer, som forstår hvad IT-systemet skal kunne, fordi det kræver indgående viden om problemdomænet.

Brugerne forstår det ikke. De er måske nok dem, som har tingene tættest på til daglig, men det er ikke ensbetydende med, at de ved hvorfor de gør som de gør og kan løfte sig op til den mere generelle forståelse af domænet, som er nødvendig for at kunne designe software.

Udviklerne forstår det ikke. De er ikke tæt på domænet i dagligdagen og kommunikationen med brugerne er ikke nødvendigvis på plads, så selv hvis de har styr på de tekniske detaljer er det ikke sikkert, at koden stemmer overens med virkeligheden.

Projektlederne forstår det ikke. Deres primære opgave er at sikre resourceallokering og ikke, at folk forstår, hvad de arbejder med - hvilket i øvrigt tager tid fra et sikkert allerede presset budget.

Ledelsen forstår det ikke. De deltager ikke selv direkte i projekterne, men har uddelegeret opgaverne til medarbejdere.

Bemærk, at det ovenstående ikke skal forstås som en kritik af nogen af grupperne, men bare som en konstatering af tingenes tilstand.

Så IMHO er det vejen frem at acceptere, at man aldrig opnår det fulde overblik; underinddele i mindre projekter, og så i øvrigt være med på, at man skal lave ændringer, når man kollektivt er blevet klogere af erfaringerne. Brugerne skal være indstillede på, at første version ikke er endelig; udviklerne skal lave vedligeholdbar kode; projektlederne skal sikre at øvrige projektdeltagere sætter sig bedst muligt ind i tingene; ledelsen skal undlade at tage forventede besparelser ind på forhånd.

Poul-Henning Kamp Blogger

Og hvad så hvis den tekniske substans viser sig at være i orden, men at processen den skal løse ikke er det (og dermed løser teknikken ikke den egentlige opgave)?

Så er det formodentlig noget i den stil havarirapporten indeholder.

Nogen gange når havarikommissionen for transport også bare frem til at nogen dummede sig. Oftest anbefaler det i samme åndedrag hvorledes gentagelser kan undgås, men i et fåtal af tilfælde må de bare notere sig at existerende regler og tiltag blev tilsidesat.

Den primære grund til at jeg plæderer for en IT havarikommission, er at det idag er fuldstændig tilfældigt om der bliver foretaget en undersøgelse og selv hvis der gør, er det stort set umuligt for IT fagfolk at få adgang til resultaterne så de kan blive klogere.

Jesper Frimann

Root cause er nok nærmest, at der aldrig er nogen enkeltperson eller gruppe bestående af et begrænset antal personer, som forstår hvad IT-systemet skal kunne, fordi det kræver indgående viden om problemdomænet.

Det er ellers det man har/burde have IT-arkitekter til.
Og hvis man har dem, og de har en vis kvalitet og man lader dem gøre sit arbejde. Så har tingene med at have en lidt bedre succes rate.

// Jesper

Jesper Frimann

Den primære grund til at jeg plæderer for en IT havarikommission, er at det idag er fuldstændig tilfældigt om der bliver foretaget en undersøgelse og selv hvis der gør, er det stort set umuligt for IT fagfolk at få adgang til resultaterne så de kan blive klogere.


Det kan du have fuldstændig ret i. Men f.eks. en fly-havarikommissions mission er jo at finde den/de anormalitet (er), root cause(s), der gjorde at tingene gik galt, når det en sjælden gang sker. Det være sig en procedure , en process, en materiel komponent, whatever.

Sandsynligheden for at dø i en flyulykke er 1 til 4.7 millioner når du tager en tur.

Sandsynligheden for at et stort offentlig IT projekt fejler er vel.... ja... 1 til "noget der er mindre end 10".

Det er et helt andet ballgame, her er det at fejle ikke en anormalitet, det er normalt. Og så nytter det ikke at bruge et fin-tunings instrument som en Havarikommission til at fikse fejlene. Der skal noget helt helt andet til. Det kræver den store hammer, med et meget større mandat end en Havarikommission vil ha'.

Når man så har fikset de fundamentale fejl og man begynder at se 'normale failure rater', så kan vi sagtens blive 100% enige om at så er en IT-haveri kommission jo et glimrende feedback mekanisme.

// Jesper

Peter Stricker

Sandsynligheden for at dø i en flyulykke er 1 til 4.7 millioner når du tager en tur.

Sandsynligheden for at et stort offentlig IT projekt fejler er vel.... ja... 1 til "noget der er mindre end 10".


Her giver du jo et godt argument for en IT havarikommision.

Kunne det tænkes, at mange års havarikommisioner har været medvirkende til den forholdsvis lave risiko ved luftfart?

Frithiof Jensen

Dette og mange andre store IT projekter bygger på en dejlig ønskedrøm om at udlicitering til det private erhvervsliv løser alle problemer


De ideologiske krige imod eksistensen af en kompetent og effektiv offentlig sektor skal sådan cirka kun löse to problemer:

Det problem er hvordan man bedst får en masse private snuder ned i truget med skattepenge, det andet er at "bevise" at "det offentlige" altid er ineffektivt og dårligt ved at köre det i sänk, så man kan "löse" problemet med endnu flere privatiseringer og "nedskäringer" - hvilket er new-speak for flere ressourcer til de rigtige lommer.

Poul-Henning Kamp Blogger

Sandsynligheden for at dø i en flyulykke er 1 til 4.7 millioner når du tager en tur.

Sandsynligheden for at et stort offentlig IT projekt fejler er vel.... ja... 1 til "noget der er mindre end 10".

Som sagt, at studere historien er en god ting.

Q: Hvordan tror du ulykkesfrekvensen for flytransport kom så langt ned ?

A: Ved systematisk at undersøge hvad der gik galt hver evig eneste forbandede gang, så man lærte noget og ikke blev ved med at gentage de samme fejl.

Jens Bengaard

Men tror du at en luftfart Havarikommission havde været et acceptabelt tiltag, hvis der drattede sådan et par fly ned om dagen ?
Vi er pt. ikke i den situation, hvor 'normale' tiltag er nok.

Flyhavarikommissionen i USA blev dannet af Kongressen, på foranledning af bekymrede flyselskaber. De var nervøse for at flyvning ville få et så dårligt ry at passagerne forlod dem, så de ville gerne have området reguleret rent sikkerhedsmæssigt.

Omfang og beføjelser har ændret sig løbende lige siden.

Peter Kyllesbeck

Nogen gange når havarikommissionen for transport også bare frem til at nogen dummede sig. Oftest anbefaler det i samme åndedrag hvorledes gentagelser kan undgås, men i et fåtal af tilfælde må de bare notere sig at existerende regler og tiltag blev tilsidesat.


Men det ændrer jo ikke på hvordan transportopgaven er løst eller hvordan den kan forbedres for brugerne.
Derfor bør man gøre sig processen klar inden man går i gang med det tekniske.
For mig synes en havarikommission at klarlægge, hvorfor driften af et system fejlede, og ikke om systemet løste opgaven/processen.

Anne-Marie Krogsbøll

Jesper Frimann

Det er ellers det man har/burde have IT-arkitekter til.


Ja - men netop IT-arkitekter er i følge Søren Lauesens svar en ekstra kilde til problemer:

Jeg (Søren Lauesen) ser fejl både hos IT eksperterne, forretningen og politikerne. Fx kan meget få IT-folk skrive problemorienterede krav. Use cases, user stories, agil udvikling, etc. hjælper ikke. Og kommer IT-arkitekterne eller driftsafdelingen med, går det helt galt. Så bliver det dynger af tekniske krav og standarder der fjerner opmærksomheden fra det væsentlige. Hvordan ser problemorienterede krav ud? Se "Vejledning til kravskabelon SL-07". Den viser en fuld kravspecifikation for en elektronisk patientjournal baseret på det princip.

Der er mange gode bud på, hvorfor opgaven er så svær i det offentlige i de mange kommentarer. F.eks. magtkampe og modstand hos personalet - som jo kunne været en god årsag til, at 40 politifolk møder op og ikke kan/vil bidrage med noget, når leverandøren beder om at få præciseret arbejdsopgaverne.

Det er denne type forklaringer, jeg synes mangler lidt i artiklen, selv om der i øvrigt ser ud til at være gjort et stort arbejde med at analysere disse kuldsejlede projekter. At man ikke bare konstaterer, at f.eks. 40 politifolk møder uforberedte op til vigtige møder, men at man også kigger på, hvorfor de møder uforberedte op, og hvordan det kan lade sig gøre, at den slags får lov at spænde ben for angiveligt vigtige samfundsanliggender - for det lyder jo så banalt, at man skal kunne beskrive, hvilke opgaver man forventer, at det nye system skal kunne løse. Der ligesom være en bagvedliggende grund til, at sådanne situationer kan få et omfang, der ligefrem kan være med til at true sådanne projekter. Synes fodfolket simpelthen ikke, at der er behov for det nye system? Hvad forbinder de med det nye system? Føler de, at de er blevet sat i en urimelig situation, hvor de ikke har fået tid til at løse den stillede opgave? Osv.

Et spadestik dybere er nødvendigt, hvis ikke historien skal gentage sig.

Jesper Frimann

Som sagt, at studere historien er en god ting.

Q: Hvordan tror du ulykkesfrekvensen for flytransport kom så langt ned ?

A: Ved systematisk at undersøge hvad der gik galt hver evig eneste forbandede gang, så man lærte noget og ikke blev ved med at gentage de samme fejl.

Det er jo simpelt hen ikke rigtigt. Før et fly overhovedet får lov til at gå på vingerne, igen hvis vi bruger det amerikanske system som billede, så skal det jo være godkendt af FAA.
Hvis du mener at FAA ingen indflydelse har på flysikkerheden... så ja..

Giver den amerikanske havarikommission input til FAA ? Ja selvfølgelig.

For at komme tilbage til essensen i mit argument og som jeg synes er understøttet af artiklen, så er de ting som Søren Lauesen påpeger jo lidt på linje med (igen så bruger vi fly billedet) at man har valgt at designe et fly uden vinduer i cockpittet, eller at man har valgt at bygge et fly til transatlantisk trafik, som kun har tank kapacitet til at flyve halvvejen.
Sådanne fejl skal fanges før projektet søsættes, ikke af en havarikommission.

// Jesper

Jesper Frimann

Ja - men netop IT-arkitekter er i følge Søren Lauesens svar en ekstra kilde til problemer:

Det kan de også sagtens være. Alle kan være en ekstra kilde til problemer.

Men generelt er det som regel IT-arkitekten (eller en gruppe af IT-arkitekter), der fungere som bindeled mellem 'forretningen' og 'teknikken'.
En god IT-arkitekt kan som regel tale både 'Forretningsk', 'Projektledersk', 'Driftsk' og 'Udviklingsk', ud over at vedkommende kan 'Arkitektsk'.

Men jeg tvivler stærkt på at Søren Lauesen mener at IT-arkitekter er til skade for IT-projekter :)

// Jesper

Anne-Marie Krogsbøll

Sådanne fejl skal fanges før projektet søsættes, ikke af en havarikommission.


Det er da fuldstændigt rigtigt, men når nu det er gået galt - den ene gang efter den anden - er det så ikke vigtigt at kulegrave, hvor, hvorfor, hvordan det er gået galt? Egentlig synes jeg jo, at Søren Lauesen gør noget i den retning, selv om jeg også synes, at der mangler et par ekstra spadestik i kulegravningen, før det efter min mening for alvor vil rykke noget.

Hvis selve ordet "havarikommission" (som jeg egentligt godt kan lide, når det jo drejer sig om "havarerede" projekter) er en snublesten, der skaber forvirrende mentale billeder hos nogen, så kunne der måske findes et andet ord, som dækker bedre?

Ikke at jeg lige har et godt ord, men det har andre måske? "Hvor gik projektet galt"-kommission?

Anne-Marie Krogsbøll

Jesper Frimann.

Men generelt er det som regel IT-arkitekten (eller en gruppe af IT-arkitekter), der fungere som bindeled mellem 'forretningen' og 'teknikken'.
En god IT-arkitekt kan som regel tale både 'Forretningsk', 'Projektledersk', 'Driftsk' og 'Udviklingsk', ud over at vedkommende kan 'Arkitektsk'.


Jeg kan høre, at det nok netop er IT-arkitekterne, jeg savner tilstedeværelsen af i artiklen, som bindeled, mæglere, formidlere - det er lige præcis deres fravær, som vel gør, at politifolk og leverandør går helt galt af hinanden?

Spørgsmålet er så, om de faktisk ikke har været med (det lyder jo utroligt), eller om fraværet i artiklen afspejler, at Søren Lauesen mener, at de skaber ekstra problemer :-(

Jens Bengaard

Hvis selve ordet "havarikommission" (som jeg egentligt godt kan lide, når det jo drejer sig om "havarerede" projekter) er en snublesten, der skaber forvirrende mentale billeder hos nogen, så kunne der måske findes et andet ord, som dækker bedre?

Jeg tror, det handler om noget andet. En havarikommission er god til at systematisere og rapportere på hændelser. De kan også anbefale tiltag, der undgår lignende hændelser i fremtiden.

Men der er nogen der skal sætte tiltagene i værk. Her kan jeg godt være lidt bekymret, fordi vi taler om stærkt politiserede projekter. Noget af det første, en IT-havarikommission bliver nødt til at arbejde på, er at sikre en tilstrækkelig transparens i et projektforløb til at kommissionen overhovedet er i stand til at udføre sit arbejde. Det vil de fleste politikere sikkert kun gå med til, så længe referaterne fra deres egne møder holdes uden for kravet. Jeg tror det bliver en kamp.

Anne-Marie Krogsbøll

Men der er nogen der skal sætte tiltagene i værk. Her kan jeg godt være lidt bekymret, fordi vi taler om stærkt politiserede projekter. Noget af det første, en IT-havarikommission bliver nødt til at arbejde på, er at sikre en tilstrækkelig transparens i et projektforløb til at kommissionen overhovedet er i stand til at udføre sit arbejde. Det vil de fleste politikere sikkert kun gå med til, så længe referaterne fra deres egne møder holdes uden for kravet. Jeg tror det bliver en kamp.


Der tror jeg bestemt, at du har ret. Og det er netop et af de niveauer, jeg savner i atiklen - det er som om, den går på listefødder uden om den type kritik.

Men hvad skal vi så gøre? Bare give op, og vænne os til at føle os til grin for vore egne milliarder den ene gang efter den anden? Det er så alvorligt for samfundet med disse evindelige skandaler/katastrofer indenfor vitale samfundsinstitutioner, at vi efter min mening er nødt til at insistere på at få dem undersøgt ordentligt - og så må man tage slagsmålene om åbenhed, og håbe, at man vinder bare en gang imellem.

Her kommer den evindelige mørklægningslovkatastrofe endnu engang i fokus - den må væk, ellers kommer der aldrig styr på disse ting (selv om jeg lige i denne sammenhæng ikke kan huske, om mørkelygten har slået til i forhold til disse projekter)

Mads Hjorth

Jeg har kun overfladisk fået forklaret rapporten (og synes jeg har andet at bruge min sommerferie på), men et bud på en radikal løsning kunne være: Drop projekt-tanken!

Hvad hvis det offentlig blot leverer nogle services, nogle af dem endda digitale. Services forbedres kontinuert og der indkøbes alene konsulentydelser per løbende time.

Projekt-skabeloner og it-udvikling der betragtes som anlægsudgifter begynder at virke lidt gammeldags. Særligt i en verden hvor dev-ops og agile metoder vinder udbredelse.

Hvad hvis det var programmøren der tog telefonen om natten når skidtet ikke virker? Eller service-lederen der skulle på tv og forklare hvorfor løsningen ikke er integreret med andre services?

Bjarne Jensen

Hvordan kan det være, at det ofte er uprofessionalisme som hersker i mange af de danske og offentlige it-projekter? Fordi der ganske enkelt kun sidder folk (ofte udviklerne), der kikker på it-tekniske sider uden ordentlige at få afprøvet web/app systemerne overfor rigtige it-brugere, der hele tiden har UX funktionelle/logiske udfordringer med at bruge systemerne! Netop dette er årsagen til at UX, samt it-forretningsanalytiker rollerne er opfundet. Men ansætter man reelt disse (udover udviklerne) i Danmark? Det er der meget der tyder på, at man ikke gør, da man spare disse mere kreative UX folk og it-forretningsudviklere væk! Ansvarlige tror fejlagtigt at projekter altid handler om teknik, så man glemmer de mere test og bruger-venlige sider af sagen! Få nu ansat agile it-forretningsanalytikere, samt UX/CX designer og kom op på et 100% professionelt plan og driv websites og apps, såsom Google gør det! Dvs. SMÅ trinvise Agile BA/UX forbedringer og test af websites løbende... BA betyder "it-forretningsanalytikere", på engelsk "Business Analysis" forkortelsen! For BA/UX handler om hvordan man AGILT driver en OPTIMAL "Digital business", men mange offentlige it-projekter har ikke UX og IT-forretninsanalytikere ansat, derfor ikke så mærkeligt, at mange offentlige IT projekter naturligvis fejler BA/UX brugere og forretningens mål...

Log ind eller Opret konto for at kommentere