Lise Gerd Pedersen bloghoved

Hvordan gransker man et kuldsejlet projekt?

På debatmødet i går eftermiddags på ITU præsenterede professor Søren Lauesen fra ITU sin undersøgelse af fejlslagne IT-projekter, og hvad man kan lære af dem. Det er i princippet et interessant forskningsprojekt, men jeg har et problem med hans empiri.

Som eksempel gennemgik Søren Lauesen sine observationer vedrørende POLSAG-projektet. Jeg tilbragte som CSC-ansat et par år som informationsarkitekt på netop det projekt. Trods fortsat tavshedspligt vil jeg tillade mig at pege på nogle misforståelser, hvad angår de dele af projektet, hvor jeg har insiderviden.

Min kritik af Søren Lauesens empiri falder i flere kategorier. Jeg har præsenteret Lauesen for disse kritikpunkter allerede i januar, så dette er ikke et bagholdsangreb.

Den ene kategori er de direkte misforståelser. Eksempelvis baserer Lauesen sin kritik af projektets krav på de designdokumenter, som er udarbejdet af kunde og leverandør i fællesskab som specifikation til programmørerne. Det er ikke krav, men løsninger. Lauesen har tilsyneladende ikke set den kravspecifikation, som var grundlaget for kontrakten.

Og nej … skærmbillederne blev ikke designet i arbejdsgrupper på 40 personer uden brugerinvolvering og blik for, hvad standardsystemet kunne tilbyde. Designet foregik i langt mindre arbejdsgrupper med stærk brugerinvolvering og genbrug af så meget standardfunktionalitet, som man kunne blive enige om.

Anekdoten, at politiet skulle have sagt, at deres arbejdsprocesser var hemmelige, har jeg aldrig hørt fra andre end Lauesen. Min oplevelse var derimod, at politiet beredvilligt og konstruktivt forsøgte at delagtiggøre os i deres arbejdsprocesser. Jeg kan ikke afvise, at anekdoten kan have fundet sted, men den er i hvert fald ikke repræsentativ for projektet.

Den anden kategori er, at Lauesens empiri ikke er objektiv. Det er for mig tydeligt, at han har talt med Rigspolitiet og underleverandøren (Scanjour), men ikke hovedleverandøren (CSC). Muligvis har CSC ikke ønsket at medvirke – det ville ikke forbavse mig. Men det betyder, at hans nedslagspunkter ikke er repræsentative for projektets problemer.

Den tredje og sidste kategori er Lauesens forslag til, hvad man ”bare” kunne have gjort, for eksempel i forhold til de systemer, POLSAG skulle integrere med. Virkeligheden var mere kompleks end som så. Lauesens beskrivelse afspejler, at han simpelt hen ikke har tilstrækkeligt kendskab til systemlandskabet til at gøre sig klog på alternative løsninger. Lauesen har i øvrigt set sig gal på SOA som et arkitekturprincip … er der videnskabeligt belæg for det? (nu og dengang)

Det skal retfærdigvis siges, at de problemer, Lauesen peger på, er sandsynligt forekommende i mange projekter, samt at hans løsninger generelt er fornuftige. Så kan det måske også være mindre vigtigt, om dette eller hint problem forekom på dette eller hint projekt.

Misforstå mig ikke – der var gigantiske fejl på POLSAG i alle lejre. Jeg er ikke ude på at forklejne katastrofen eller retfærdiggøre nogen af parterne. Mit ærinde er at stille spørgsmålstegn ved, om det er muligt og hensigtsmæssigt at dissekere IT-projekter på denne måde – og det fører mig hen til det næste.

På mødet i går blev en eventuel IT-havarikommission også debatteret. Lars Frelle-Petersen påpegede, at når et projekt går galt, kommer Rigsrevisionen ind over. En eventuel IT-havarikommission ville kun være et ekstra lag. Fortalere for en IT-havarikommission vil måske hævde, at Rigsrevisionen ikke har tilstrækkelig teknisk indsigt. Men det er jo derfor, at Rigsrevisionen i kulegravningen af POLSAG-projektet allierede sig med blandt andre netop den Søren Lauesen, som nogle mener er selvskrevet til en IT-havarikommission.

Det er selvsagt umuligt for en (eller få) person(er) på kort tid at skaffe sig et overblik over disse fejlslagne, kæmpe IT-projekter. Hvert af dem har kørt over en lang årrække med måske hundredvis af mennesker og adskillige organisationer involveret. Et sådant projekt genererer stabler af skriftligt materiale i form af rapporter, arbejdsdokumenter, korrespondance osv. Det vil tage år at komme igennem det.

Baserer man empirien på mundtlige udsagn (interview), må man tage sig tiden til at verificere udsagnene. Det kan ske ved, at flere parter udtaler det samme, eller ved at man fremskaffer skriftlig dokumentation. Dermed kan man måske foretage en kritisk frasortering af eventuelle misforståelser, efterrationaliseringer, selvforherligelse og mudderkastning.

Én udfordring er at få afsat midler til en evt. IT-havarikommissions interne arbejde. En anden er spørgsmålet om, hvem der skal finansiere leverandørernes medvirken. Leverandørerne skal i givet fald afsætte tid til at finde dokumenter, indgå i interviews samt forholde sig til og afvise eller bekræfte andre parters udtalelser. Det vil næppe være populært hos en leverandør, der netop har tabt en stor sum penge på et kuldsejlet projekt. Hvis det offentlige i udbuddene indskriver en forpligtelse til at medvirke i en sådan undersøgelse, vil det være en risiko, som vil få tilbudspriserne gå op på samtlige projekter. Nogen skal jo betale.

Så selv om tanken om en IT-havarikommission lyder tillokkende, tror jeg ikke, at en sådan er indsatsen værd. Vi kender jo allerede mange af de generelle problemer, også uden at dissekere yderligere. Der er i øjeblikket store indsatser i gang for forhindre fremtidige katastrofer. Lad se fremad i stedet for tilbage!

Relateret indhold

Lise Gerd Pedersens billede
Lise er selvstændig it- og enterprise-arkitekt (www.archit.dk). Hun har arbejdet professionelt med it - tilfældigvis især offentlig IT - siden 1980, både på leverandørsiden og som offentligt ansat.

Kommentarer (81)

Kommentarer (81)
Heino Svendsen

Findes nok ikke... Desværre er det sådan i dag, at især politikere og DJØF'ere har et behov for at vaske hænder, så de kan pege fingre ad andre. Aben skal fodres, så den bliver større, og så skal den ende på et skrivebord et sted. Helst med en næse til følge, for man fyrer/straffer jo ikke en Fellow DJØF....

Men hånden på hjertet, så tror jeg, at det bliver svært at implementere objektive undersøgelser, idet de, som betaler for dem, ofte har en agenda, som skal underbygges..."Giv min konklusionen, og jeg skal give dig undersøgelsen, som beviser den"

Jeg så gerne, at man undersøgte objektivt, men jeg tror desværre, at det aldrig kommer til at ske...

Poul-Henning Kamp Blogger

"Så selv om tanken om en IT-havarikommission lyder tillokkende, tror jeg ikke, at en sådan er indsatsen værd. Vi kender jo allerede mange af de generelle problemer, også uden at dissekere yderligere."

Ja, vi kender "de generelle problemer", politikere der tror at IT er magisk tryllesovs, firmaer der lyver i udbudet i forventning om hæftige Change Requests osv. osv. osv.

Men en IT-havarikommisions opgave er ikke at pege på de generelle problemer, men derimod at kortlægge de specifikke problemer.

Imellem hvad du skriver ovenfor og hvad Søren Lauesen sagde i onsdags, er det tydeligt at vi ikke allerede ved hvad de specifikke problemer er.

Der er i allerhøjeste grad brug for en IT-havarikommission!

Og uden ITHKs rapporter om hvilke specifikke fejl der blev begået, hvorledes skulle alle de inkompetente personer som Lars Frellesen helt korrekt påpegede er det største problem, nogensinde blive klogere ?

Peter Lind

På mødet i går blev en eventuel IT-havarikommission også debatteret. Lars Frelle-Petersen påpegede, at når et projekt går galt, kommer Rigsrevisionen ind over. En eventuel IT-havarikommission ville kun være et ekstra lag. Fortalere for en IT-havarikommission vil måske hævde, at Rigsrevisionen ikke har tilstrækkelig teknisk indsigt. Men det er jo derfor, at Rigsrevisionen i kulegravningen af POLSAG-projektet allierede sig med blandt andre netop den Søren Lauesen, som nogle mener er selvskrevet til en IT-havarikommission.

Hvis Søren Lauesen har udført arbejde for Rigsrevisionen for at komme til bunds i hvad der gik galt, men ikke har kunnet få oplysninger fra CSC, så er Rigsrevisionen jo dybest set irrellevant i disse sammenhænge. Så skal deres autoritet enten udvides (hvis det er problemet) eller der skal tilføjes en anden myndighed (såsom den foreslåede havarikommision) der specifikt fokuserer på projektet der gik galt og derfor forholder sig til alle sider af sagen.

En anden er spørgsmålet om, hvem der skal finansiere leverandørernes medvirken. Leverandørerne skal i givet fald afsætte tid til at finde dokumenter, indgå i interviews samt forholde sig til og afvise eller bekræfte andre parters udtalelser. Det vil næppe være populært hos en leverandør, der netop har tabt en stor sum penge på et kuldsejlet projekt. Hvis det offentlige i udbuddene indskriver en forpligtelse til at medvirke i en sådan undersøgelse, vil det være en risiko, som vil få tilbudspriserne gå op på samtlige projekter. Nogen skal jo betale.

Eller det vil være et ekstra incitament til ikke at indgå kontrakter man ikke kan holde - alternativt et ekstra incitament til at gøre alt hvad man kan for at holde dem. Alt andet lige bliver det også et konkurrenceparameter.

Lad se fremad i stedet for tilbage!

Det er ved at være en noget fortærsket holdning. Kan vi ikke nok få den erstattet med "Lad os se fremad og tilbage". Ellers har vi ikke set det sidste til store IT-katastrofer i det offentlige.

Mogens Lysemose

Om en IT-haveri-komission giver værdi/"sandheden" afhænger helt af hvordan den bliver konstrueret og med hvem, som Lise Gerd Pedersen skriver. Der findes forskere (og dekaner) der er tendensiøse eller til fals for at fabrikere den ønskede konklusion.
Det har vi bla. set "Bæredygtigt" landbrug benytte sig af. Hvis man sætter udygtige eller uhæderlige "specialister" i spidsen for et en kommision (eller et projekt!) bliver resultatet nok derefter.

Jeg mener i øvrigt det er de GENERELLE problemer man burde løse først, for det er jo mange af de samme faldgruber de offentlige (og også mange lidet kendte private) IT-projekter falder i.
Hvis man kan redde 50%-75% af alle fremtidige problemprojekter på den måde er det da en enorm forbedring som langt vil kunne overgå gevinsten ved at kende de specifikke problemer for hvert projekt.

Den kritik som Lise Gerd Pedersen og Lars Frellesen påpeger med usaglige uvidenskabelig konklusioner og anekdote-baseret forskning virker helt rigtigt; det lyder som elendig forskning grænsende til videnskabelig uredelighed.

Per Christensen

"Der var gigantiske fejl på POLSAG i alle lejre". Dette er jo interessant nok, og Søren Lauesen dissekerer så projektet og påpeger f.eks. at skærmbillede designprocessen ikke blev lavet på en hensigtsmæssig måde. Denne viden løser bare ikke noget som helst. Vi ser disse projektet igen og igen.

Svaret ligger i hvordan projektet kom frem til at gennemføre designprocessen på "den forkerte måde".

Var det politik, organiseringen, manglende viden, ligegyldighed, manglende mod eller hvad ?

Havde manden bag den forkert designprocessen bare mest gennemslagskraft ?

Det er her nøglen til at undgå gentagelser ligger.

Gert Madsen

"Lad se fremad i stedet for tilbage!"
Den som ikke lærer af historien er dømt til at gentage den.

Men det er måske helt nye fejl, som bliver begået hver gang ?

Niels Henrik Sodemann

Dit eget indlæg dokumenterer fuldt ud, at der er et issue (forudsat, selvfølgelig at dine udsagn er korrekte), idet du bringer ”nye” oplysninger frem, uanset at du er underlagt tavshedspligt.

En IT-havarikommission (ITHK) skal være uafhængig og det er explicit ikke ITHKs opgave at fastslå skyld eller foretage ansvarsplacering. Formålet er at lære af havarierne.

Rigsrevisionen er derimod som oftest direkte part i de kuldsejlede projekter (ved ikke at have stoppet dem undervejs ifm. med deres revisioner) og medvirker til at placere ansvar, bål og brand, hjælper f.eks. Statsrevisorerne med at udtale kritik af for eksempel ministre, ministerier, styrelser og tilsyn på baggrund af rapporter. Mange af undersøgelserne foregår i dølgsmål af forskellige interne hensyn og ofte med udgangspunkt i de foreliggende kontrakter.

Rigsrevisionen og de undersøgelser, der igangsættes er således systemets undersøgelse af sig selv. Det ender således i en difus suppe, som f.eks. POLSAG, hvor der er svært at drage læring fra. Igen, din egen post dokumenterer behovet.

ITHK er derfor ikke ”et ekstra lag”, men har et helt andet formål. Læring…

Jesper Frimann

ITHK vil løse problemet, er ved at blive sådan en "Ceterum censeo Carthaginem esse delendam" altså "I øvrigt mener jeg, Karthago bør ødelægges", for mange 'herinde'.

Det er efter min mening lidt synd, for det virker lidt som spørgsmålet for/imod en sådan konstruktion skygger for en mere interessant debat, nemlig hvad er der skal til for, at det offentlige på IT fronten at få lavet en acceptabel succes rate på deres projekter.

Hva' er det så der skal til ?

// Jesper

Bente Hansen

Med EFI og undersøgelse i SKAT. Så er der nok mere lydhørt, for løsningen som ikke generer den samme antal næser til Politikere.

Spildte penge, dårligt borg server, ulovlige eller manglede retsordning for den offentlige administration er ikke noget der rykker.
Men en naturlig del af NPM. Som er en tilsigtet politisk strategi fra TH på den liberalistiske højrefløj.

Det er når toppen selv risikere at komme i fedtefadet, eller når deres gode venner som lever af eller i det offentlige, kan miste jobbet, eller ikke at blive genvalgt. At der er mulighed for at lave tiltag som forhindre det sidste, ved at løse det første.

Lise Gerd Pedersen Blogger

@Poul-Henning: Selv om Lauesen har gransket specifikke projekter, er der for mig at se ikke noget nyt i de fejl og kure, han er nået frem til. Jeg tror, at der for ethvert af disse projekter har været kompetente personer, der har advaret. Inkompetencen har især ligget i ledelseslaget. En ITHK kunne måske finde eksempler på endnu flere specifikke fejl, men det nytter jo ikke noget i sig selv.

@Mogens: Jeg er helt enig i, at hvis vi starter med at få løst alle de generelle problemer, vi allerede kender, så er vi nået et godt stykke af vejen. Derfor synes jeg, at vi skal fokusere på det. Når vi så har klaret det og begynder at kede os, kan vi gennemtrevle gamle projekter for at finde endnu flere forbedringsmuligheder ;-)

@Peter: Du har ret i, at udsigten til at skulle bidrage til en ITHK-undersøgelse kunne være et incitament for leverandørerne. Men da kunderne ofte er (i hvert fald medvirkende) årsag til kuldsejlinger, vil leverandørerne skulle beregne risiko under alle omstændigheder.

@Niels: Ja, der er en væsentlig forskel på at placere ansvar og at uddrage læring. Men er der vandtætte skodder? ITHK’s resultater skal vel fremlægges, for at det giver læring? I så fald vil projektets parter forsøge at redde deres eftermæle. Lauesens mislykkede dissekering af POLSAG er i øvrigt det bedste bevis på, at det er svært at uddrage læring, alene på grund af projekternes enorme omfang. Med mindre projekter kan vi bedre gennemskue det.

@Jesper: Enterprise arkitektur (surprise!). Se næste blogindlæg.

Poul-Henning Kamp Blogger

@Poul-Henning: Selv om Lauesen har gransket specifikke projekter, er der for mig at se ikke noget nyt i de fejl og kure, han er nået frem til.

Jeg noterer mig at alle jeg har talt med, som har læst Sørens rapport, har været overraskede over hvad den indeholdt.

Det er selvfølgelig fint hvis du personligt har 100% styr på situationen, men det er jo indlysende for enhver at det ikke er noget ret udbredt fænomen.

En ITHK kunne måske finde eksempler på endnu flere specifikke fejl, men det nytter jo ikke noget i sig selv.

Huh ?

Har du aldrig hørt om at lære af sine fejltagelser ?

Jeg kan varmt anbefale at du bruger nogle aftener på at studere hvorledes andre teknologiske brancher profesionaliserede sig selv, eller blev professionaliseret ved lov.

Den helt centrale komponent er altid at fejltagelserne bliver udret kompetent, således at de kan blive dokumenteret, kommunikeret og dermed ikke gentaget.

I alle disse tilfælde har der været fagfolk der beroligende har sagt "vi ved godt hvad der er galt" og i stort set alle tilfælde jeg har fundet, har de taget grusomt fejl.

Niels Henrik Sodemann

"I øvrigt mener jeg, Karthago bør ødelægges", for mange 'herinde'.


@Jesper,
Ja, der er rigtig mange, der er af den opfattelse, at problemerne (som der jo trods alt er nogenlunde koncensus om eksisterer) bedre løses med tro og drømme end viden. Det gælder vel også mere end halvdelen af panel deltagerne. Nu er det som udgangspunkt ikke noget galt med tro og drømme, alle forandringer / innovationer har selvfølgelig en komponent heraf. I langt de fleste tilfælde dog i en symbiose med viden.

Der er jo heller ikke, så vidt vi ved, endnu sket tab af menneskelig. Ressourcetabet har dog været ekstremt stort, ressourcer der kunne havde været brugt til rigtig mange positive forandringer.

Jeg har personligt utrolig svært ved at skulle acceptere at der findes en særlig præmis for offentlige it-projekter, der skulle muliggøre professionalisering baseret på tro og drømme alene. Hvis der er nogen der kan forklare denne præmis, så lytter jeg selvfølgelig gerne.

Niels Henrik Sodemann

ITHK’s resultater skal vel fremlægges, for at det giver læring? I så fald vil projektets parter forsøge at redde deres eftermæle.


Ja, der vil helt sikkert blive nogle, som får forfængeligheden i klemme.

Det har sikkert heller ikke været sjovt for tidligere tiders flyproducenter, at se deres design og fly blive dissekeret, da de fald ned fra himmelen i en lidt strøm.

Der er selvfølgelig nogle af dem der er lukket, men mange har da overlevet tab af forfængelighed og har bistået konstruktivt i havarikommissioner, således at flytrafik i dag er en helt anden og væsentlig mere sikker industri.

Søren Lauesen

Lise Gerd Pedersen har jan. 2017 læst og kommenteret den engelske rapport jeg har skrevet om de 5 projekter. Det jeg sagde og viste ved paneldebatten er kun en lille del af den rapport. Lad mig først indrømme at Lise har ret i at der ikke var 40 personer i designgruppen. Jeg tænkte på de 40 personer i den indledende analyse, som skete før Lise kom ind i projektet. Så jeg vil simpelthen fjerne årsag G9, som kun var der en kort periode. Ved genlæsning kan jeg også se at jeg forklarer for lidt om 1:1 kravet under årsag A2. Sådanne korrektioner er netop formålet med at offentliggøre rapporten, så tak for det, Lise.

Lise antyder at jeg ikke har sat mig ordentlig ind i sagerne og bare fremfører min egen mening, fx om de "hemmelige arbejdsprocesser". Jeg har faktisk undersøgt det så grundigt som muligt. Lad mig uddybe nogle ting: De 40 betjente og hemmelige processer ved Politiets første møder med Scanjour, er hvad Rigsrevisionen fik at vide ved mødet med Scanjour. Jeg har senere fået hele min rapport om PolSag valideret af personer der på det tidspunkt var i Politiet eller hos Scanjour. Lise, ting kan godt finde sted uden at du har hørt om dem.

Rigsrevisionen snakker normalt kun med myndighederne, men i undersøgelserne af IT-projekterne, har vi haft særdeles grundige møder med leverandørerne. (Jeg har dog ikke været med ved EFI). Og de har alle været meget interesseret i at give deres forklaring på hvad der skete. I PolSags tilfælde mødtes vi både med CSC og Scanjour, da projektet var lukket. Til RR's overraskelse var det første leverandørerne spurgte om dette: "Kan I fortælle os hvad formålet med PolSag er? Vi har gentagne gange spurgt Politiet, men ikke fået svar". Dette punkt er hovedårsagen til at projektet blev lukket. Og ikke nok så meget agil udvikling kunne have hjulpet.

Jeg har læst den oprindelige kravspecifikation og de yderst grundige overvejelser af de mulige integrationer. Som forklaret under årsag A5 blev det meget dyrt at integrere. SOA var ikke "bare lige". Jeg kan ikke genkende at jeg anfører løsninger der er "bare lige". Under årsag A2 forklarer jeg hvor mangelfulde de oprindelige krav var og hvad de efterhånden blev erstattet med. Det de blev erstattet med kalder jeg "design-level requirements", som gør at man ikke længere kan se om Scanjour's system kunne bruges uden eller med mindre ændringer.

Det er korrekt at jeg advarer mod naiv brug af SOA og troen på at det er "bare lige". Interesserede kan få en videnskabelig undersøgelse af hvad problemerne er. Den er Christoffer Pagaards kandidatafhandling, som fik topkarakter.

Jeg har frittet Lise for at få hendes bud på hvad der kan gøres, men jeg synes ikke vi kom længere end til at der skulle mere kvalificerede folk på projekterne. Jeg drømmer om at finde ud af hvad disse ekstra "kvalifikationer" skulle være. Min rapport giver et bud på 36 årsager man skal lære at undgå og 19 behandlinger man skal kende til.

Jesper Frimann

Fortegnsfejl!

Uden ITHK vil problemet ikke blive løst.

Her ville det så have været nemmest bare at skrive "I rest my case....".

Men lad os i stedet fokusere på:

Der skal mange andre tiltag til, men en indiskutabelt nødvendig forudsætning er at der skaffes gennemsigtighed i de IT projekter der går galt, så vi alle kan lære noget af dem.

Det er jeg sådan set enig i. Men her er en ITHK jo "the Nuclear Option", altså det tool/våben, man hiver op af skuffen sidst. Når alle andre mekanismer er fejlet.
Og når først det kommer i spil, så .. ja.. ruller der hoveder... eller det er hvad der normalt gør i en privat

Det man så kan sige om 'Det statslige offentlige' er at rigtig mange af de føromtalte mekanismer, som skal sikre gennemskuelighed, standardisering og 'forbedring gennem feedback', ikke eksisterer.

Jo da, man har da et projektråd bestående af erhvervsledere og man har fokuseret på execution af projekter (projektledelse). Men det har bare ikke så meget med det IT-faglige og det faglige i det ministerie man nu kører projektet at gøre.

Ja, disse tiltag kan hjælpe, men har kun et stærkt begrænset virkefelt IMHO.

Det der mangler er IMHO Enterprise Arkitektur... forstået på den måde, at man respektere det faglige i det forretnings område man beskæftiger sig med, og kobler det tæt sammen med IT-faglighed, på en formaliseret og topledelse sanktioneret måde.

Og det behøver ikke være så fancy, der er også rigtig meget rugbrødsarbejde i EA. Og jeg vil hellere implementeret 'rugbrøds tiltagene' før vi implementerer 'The nuclear option' (ITHK).

// Jesper

Poul-Henning Kamp Blogger

Det er jeg sådan set enig i. Men her er en ITHK jo "the Nuclear Option", altså det tool/våben, man hiver op af skuffen sidst. Når alle andre mekanismer er fejlet.

EFI har efter alt at dømme kostet hver evig eneste danske skatteyder noget der minder om 50.000,-

Hvor meget mener du der yderligere skal til, før vi er nået til det "sidst" hvor en ITHK er berettiget ?

Til sammenligning koster Havarikommissionen for Transport ca. 15 mio om året.

Niels Henrik Sodemann

rigtig meget rugbrødsarbejde i EA. Og jeg vil hellere implementeret 'rugbrøds tiltagene' før vi implementerer 'The nuclear option' (ITHK).


@Jesper og Lise, I kan se EFI kravspecifikationen her: https://drive.google.com/drive/folders/0B5S8wWMh34NHRDR4MjFZeWlqMVE. (selve kontakten holdes stadig i dølgsmål) Der kan vel nærmest ikke laves mere EA rugbrødsarbejde end det der fremgår af specifikationen. EA er sikkert brugbart lige som PRINCE, et projektråd og meget andet. EFI er alligevel endt som den ultimative nedsmeltning. Man kan selvfølgelig drømme om / tro på at EA, PRINCE og/ eller et projektråd kan forhindre fremtidige nedsmeltninger.
Det kan selvfølgelig også være at alt EA arbejdet er lavet forkert / inkompetent, men det kræver vel en undersøgelse at vurdere?

Hvorfor ikke blot lægge forfængeligheden til side og lade en ITHK lave uvildige uafhængige undersøgelse af nedsmeltningerne? Skal tro og drømme gå forud for viden?

Jesper Ravn

EFI har efter alt at dømme kostet hver evig eneste danske skatteyder noget der minder om 50.000,-
Hvor meget mener du der yderligere skal til, før vi er nået til det "sidst" hvor en ITHK er berettiget ?

I det offentlige, er det min klare opfattelse, at lederne ikke leder og tager ansvar, men at de administrerer.
Når medarbejderne ser denne ansvarsforflyttelse, vil det automatisk gennemsyre resten af organisationen.
Dette ses også på de enorme milliardbeløb, som staten hvert år brænder af på ekstern konsulent bistand og new public management visioner.
Dette betyder samtidig også, at man nedbryder medarbejdernes faglige kompetencer, selvstændige tankegang og ansvarsfølelse.
Endelig så har ledelsen og alle medarbejderne en mundkurv på til omverden, selv om de godt kan se, at projektet allerede i startfasen er en katastrofe. Det kommer først frem, når budgettet er rødglødende og den sidste konsulent lukker og slukker.

Jeg er bange for at ITHK, vil forværre ovenstående. Ansvarsforflyttelse og 0-fejls kulturen vil blive endnu mere sygelig og konsulentbistanden vil blive endnu dyrere.
Med ITHK vil du også lamme den involverede organisation, samt dens samarbejdspartnere og leverandører.
Med det mener jeg, at ITHK skulle undersøge og kortlægge alle beslutningsprocesser der var gået forud for det fejlslagende projekt. Det ville formentlig kræve, at man skulle indkalde og ligefrem afhøre mange af de involverede medarbejdere og samarbejdspartnere der indgik i projektet. Deraf udtrykket lammelse.
Med dette scenario, kan det vel ikke blive ret meget værre, at arbejde som projekt/IT-medarbejder indenfor for det offentlige.

Jesper Ravn

Vi er på den anden side af hvor tro, drømme,”klare opfattelser” og ”bange for” er en rimelig præmis at fortsætte på. Vi må have viden og skabe læring.

Ja vi må have viden, men først og fremmest må vi have en ledelsesstruktur der fungerer, leder og tager ansvar. Forhold dig så også lige til resten af mit indlæg og det jeg skrev omkring ITHK.

Resten af dit bullshit, fremmer ikke min forståelse overfor dine argumenter.

Niels Henrik Sodemann

Forhold dig så også lige til resten af mit indlæg og det jeg skrev omkring ITHK.


Det har jeg forholdt mig til. Om den konkrete årsag ligger forud for projekt, under projektet, om det er ledelsen, teknikken, kontrakten, kulturen, projektmodellen, leverandøren, teknikken, love / regler eller et eller andet er ikke centrale. Årsagen skal findes og dokumenteres til fremtidig læring.

For at citere Winston Churchill ifm. med den havarikommission der blev nedsat for at udrede ” de Havilland Comet” katastrofen (se: https://en.wikipedia.org/wiki/De_Havilland_Comet)

"The cost of solving the Comet mystery must be reckoned neither in money nor in manpower."

Jesper Frimann

Jeg har personligt utrolig svært ved at skulle acceptere at der findes en særlig præmis for offentlige it-projekter, der skulle muliggøre professionalisering baseret på tro og drømme alene. Hvis der er nogen der kan forklare denne præmis, så lytter jeg selvfølgelig gerne.

Nu har jeg arbejdet både i/med/for det offentlige, det 'ex offentlige' og det private, næsten altid i større organisationer/virksomheder.

Og problemerne er meget ens, selv om der er forskelle mellem 'det offentlige' og det 'private'. Der er lidt mere konsekvens og man 'hvis man vinder' får man altid tilgivelse i det private.

Jeg var meget positivt overrasket over kvaliteten af den debat der var på ITU (tak til PHK for at gøre opmærksom på den på sin blog her), jeg ville bare have ønsket, at den havde varet 3 timer .. og selvfølgelig, at jeg selv kunne have været tilstede. Jeg så den så senere som podcast.
Alle deltagerne havde IMHO gode pointer, og jeg var faktisk meget overrasket over Lars Frelle-Petersen ærlighed.

Mit take er at 'det offentlige' aldrig rigtig er kommet sig over frasalget af DataCentralen og KommuneData. Det 'Brain Drain' og den decentralisering af IT er man sku' aldrig rigtig kommet sig over. Tænk hvor mange tusinde IT-folk, der så at sige alle arbejdede inden for et specifikt fagområde, nemlig offentlig IT. Det tragiske er når man, som jeg har gjort som en del af mit arbejde førhen, har siddet og læst gamle DataCentralen og Kommune Data dokumenter og standarder der er 15-20 år gamle, så får man en lidt anden respekt for fagligheden, der var til stede på det tidspunkt i de daværende offentlige IT-virksomheder.

Problemet er så at i dag, der er digitalisering styrelsen et 'vedhæng' på Finansministeriet. Og hvis du f.eks. læser den arkitekt hvidbog man arbejder på. Så er det alt sammen anbefalinger og man bør ...
Jeg mener, at hvis man skal rette op på offentlig IT, så skal man have en organisation med kritisk størrelse og beføjelser til, at tage styringen og have beslutningskompetence over IT i andre ministerier, styrelser m.m.

Som det er i dag, kan IT-faglige leasons learned, anbefalinger og rapporter jo ikke nødvendigvis genbruges på tværs af ministerier og styrelser. Simpelt hen fordi man ikke har samme EA.
Så for at genbruge den her havarikommissions jargon, så er et ministerie et busselskab, et andet et flyselskab, et tredje en taxa service og et er DSB.

Sådan forsimplet lidt.

// Jesper

Jesper Frimann

Der kan vel nærmest ikke laves mere EA rugbrødsarbejde end det der fremgår af specifikationen.


Du mener vel det modsatte ?
(Og ja jeg har læste hele baduljen for noget tid siden, faktisk i forbindelse med mit sidste job :))
Bilag 22 side 4. Her beskriver man hvordan man har dokumenteret alle forretnings processer etc. etc.
Det havde man så ikke........... altså reelt havde man ikke et fyldestgørende billede, af ens forretning.

Hvorfor ikke blot lægge forfængeligheden til side og lade en ITHK lave uvildige uafhængige undersøgelse af nedsmeltningerne? Skal tro og drømme gå forud for viden?

Nu kommer der jo nok også en undersøgelse. Og du kan nok være rimelig sikker på at grunden til at EFI gik galt.. ikke har så meget med IT at gøre :)

// Jesper

Niels Henrik Sodemann

Og du kan nok være rimelig sikker på at grunden til at EFI gik galt.. ikke har så meget med IT at gøre :)


@Jesper, Det er nok præcis her vores uenighed grunder. Jeg mener, at alt hvad der sker fra det tidspunkt en politiker synes at lovgivning skal ændres, har noget med IT at gøre.

Hvis vi nu bruger den fortolkning af IT, kan du så ikke se det hensigtsmæssige i en uvildig uafhængig og offentlig tilgængelig undersøgelse af katastroferne udført af et organ der ikke er fedtet ind på nogen vis og til fremtidig læring?

Jesper Ravn

Det har jeg forholdt mig til. Om den konkrete årsag ligger forud for projekt, under projektet, om det er ledelsen, teknikken, kontrakten, kulturen, projektmodellen, leverandøren, teknikken, love / regler eller et eller andet er ikke centrale. Årsagen skal findes og dokumenteres til fremtidig læring.

Ja, jeg har forstået, at du vil have kæmpe root-cause analyser, som skal forhøre og udstille alle de involverede projektmedarbejdere og som mens det står på, vil nedfryse/lamme organisationerne mfl.

Hvad med at forbygge og starte med at erkende, at den offentlige organisatoriske struktur som vi ser den i dag, ikke er gearet til, at kunne favne disse monster projekter.

Du skriver ”Årsagen skal findes og dokumenteres til fremtidig læring”
Jeg spørger så, hvad vil du bruge dette til, når politiske målsætninger, visioner, teknologisk udvikling og kravspec til nye projekter, konstant vil ændre sig?

Vi lærer tilsyneladende heller ikke af vores fejl, hvis vi ser på området indenfor IT-sikkerhed.
Du ved, det er noget bøvlet noget og vores fokus er på visioner og form og ikke indhold.

Michael Cederberg

Men en IT-havarikommisions opgave er ikke at pege på de generelle problemer, men derimod at kortlægge de specifikke problemer.

Jeg så gerne at man kunne holde ærlige post-mortems på store projekter – havarikommission eller ej. Men det kommer aldrig til at virke på rigtigt store projekter – specielt dem der involverer mange underleverandører. Internt i store organisationer er der magtkampe og hvis man kan skyde skylden på andre er det helt fint. Nogen gange bliver katastrofeprojekter udråbt som succeser fordi alle har brug for succes. Nogen gange blive reelle succeser overset, fordi de ikke gjorde stort væsen af sig. Og så snart der er underleverandører involveret, så er der pekuniære hensyn.

Når jeg læser Lises beskrivelse så passer det godt med ovenstående. Der er alt for mange modstridende interesser involveret til at man får ærlige svar.

Jeg er gennem årene kommet til den konklusion at dem der stiller krav til projekter reelt ikke har en chance for at gøre det på en ordentlig måde (de gør det sjældent mere end en gang i løbet af et arbejdsliv). Samtidigt har os der omsætter krav til software altid har svært ved at ramme tilnærmelsesvist rigtigt rent ressourcemæssigt (selvom vi har gjort det mange gange, så er næsten alle projekter nye og med anderledes udfordringer).

Ovenstående passer dårligt med en verden hvor den der betaler gerne vil vide hvad han køber og hvad det koster – inden han underskriver kontrakten. Yderligere tror dem der stiller kravene sjældent på at der nogensinde kommer en fase 2 af projektet. Af samme grund har de interesse i at hælde alt ind i fase 1. Og så videre …

Niels Henrik Sodemann

udstille alle de involverede projektmedarbejdere


Nej, det er explicit ikke ITHKs opgave at fastslå skyld eller foretage ansvarsplacering. Se @phk's oprindelige post her: https://www.version2.dk/blog/it-haverikommission-nu-51199.

ikke er gearet til, at kunne favne disse monster projekter.


Det er viden som har været tilgængelig siden Bonnerup-rapporten, som helt tilbage fra 2001. Lad os nu antage at du har ret i din tro på, at det er årsagen. Så er det vel hensigtsmæssigt at få det fastslået som en årsag, men da også hvilke mekanismer, der f.eks. har søsat et EFI projekt mod bedre vidende.
Igen, ikke for at fastslå skyld eller foretage ansvarsplacering, men for at sikre at det ikke sker igen.

Jesper Ravn

Nej, det er explicit ikke ITHKs opgave at fastslå skyld eller foretage ansvarsplacering. Se @phk's oprindelige post her: https://www.version2.dk/blog/it-haverikommission-nu-51199.

Jeg har læst den.
Vil du være sød at svare på og forholde dig til den praktiske udførelse af ITHK og effekten af denne, som Jesper F, Michael C og jeg har svaret tilbage på.

Jeg skriver lige mine modargumenter igen.

Praktisk udførelse af ITHK, leder mine tanker hen på McCarthy og USA i 1950’erne.

kæmpe root-cause analyser, som skal forhøre og udstille alle de involverede projektmedarbejdere og som mens det står på, vil nedfryse/lamme organisationerne mfl.

ITHK vil give lav lærings-og videns effekt, da politiske målsætninger, visioner, teknologisk udvikling og kravspec til nye projekter, konstant vil ændre sig.

Vi skal forbygge og starte med at erkende, at den offentlige organisatoriske struktur som vi ser den i dag, ikke er gearet til, at kunne favne disse monster projekter.

Jesper Ravn

Vil du være sød at svare på og forholde dig til den praktiske udførelse af ITHK

            Håndtering som f.eks. havarikommissionerne for jernbane og luftfart, se: http://www.havarikommissionen.dk/index.php?lang=da  

Æv Niels. Jeg havde håbet, at du ville nuancere dine synspunkter noget mere til debatten.
Vi kan ikke diskutere videre, når du ikke vil forholde dig til de kritik punkter af ITHK, jeg og andre har skrevet tilbage på.

Niels Henrik Sodemann

Vi kan ikke diskutere videre, når du ikke vil forholde dig til de kritik punkter af ITHK, jeg og andre har skrevet tilbage på.

Det kan jeg da godt svare tilbage på.

kæmpe root-cause analyser, som skal forhøre og udstille alle de involverede projektmedarbejdere og som mens det står på, vil nedfryse/lamme organisationerne mfl.

Når et projekt kører i hegnet under det nuværende paradigme er der en lang række instanser der træder i kraft og laver undersøgelser. På større projekter vil Folketingets Finansudvalg undersøge sammen med Rigsrevisionen, Kammeradvokaten, en hær af konsulenter mfl. Omfang og særligt ”ubehagelighedsgrad” for de involverede i det nuværende paradigme overstiger langt tanken med ITHK. Tanken med ITHK er netop ikke, som i den nuværende ”jeg må gøre alt for, at det ikke ser ud som om, at det er min skyld kultur”, at hænge individer og organisationer ud. Udover at det nuværende paradigme er ekstremt ubehageligt for de involverede, så bliver det særligt slemt ved at informationer, kontrakter, rapporter mm. holdes i dølgsmål. Formålet med ITHK er derimod læring for at sikre at evt. fejl ikke gentages.

Vi skal forbygge og starte med at erkende, at den offentlige organisatoriske struktur som vi ser den i dag, ikke er gearet til, at kunne favne disse monster projekter.

Måske, men der er ligesom Professor Kim Normann Andersen postulat om at det hele bliver fikset, blot det private overtager, ingen evidens for påstanden. Jeg er personligt dog uanset helt enige med jer om modellen, særligt hvis man kan fjerne hele udbudscirkusset. EU udbud var tiltænkt at skabe fri konkurrence og gennemsigtighed. Det modsattes synes at være resultatet på IT området. Men igen, det er en holdning som er baseret på min tro og som jeg ikke kan dokumentere.

Uanset om en eller anden ny model måtte virker, vil jeg fastholde at en institution til uafhængig uvildig undersøgelse af havarerede projekter med krav om fuldstændig fremlæggelse til fremtidig læring er et godt og på nuværende tidspunkt helt nødvendigt tiltag. Omfanget og konsekvenserne af katastroferne er helt astronomiske.

Jesper Frimann

Udover at det nuværende paradigme er ekstremt ubehageligt for de involverede, så bliver det særligt slemt ved at informationer, kontrakter, rapporter mm. holdes i dølgsmål. Formålet med ITHK er derimod læring for at sikre at evt. fejl ikke gentages.

For pokker Niels Henrik Sodemann, det er jo netop en ændring af det nuværende paradigme, som jeg og mange andre argumenterer for.
Det vi bare siger er, at man ikke bør bruge en ITHK, som den mekanisme man bruger til at ændre det nuværende paradigme.
Det er jo heller ikke den 'rigtige havarikommission' der har skrevet luftfarts regler, og er hovedbidragsyderen til alle flydesigns. Man starter jo ligesom et sted, og bruger også mange andre mindre intrusive 'feedback' mekanismer til at foretage ændringer og forbedringer.

Hvis det havde været tilfældet ville det have været på baggrund af millioner af millioner af døde flypassagerer....

Desuden så har den rigtige havarikommission også et begrænset virkefelt, den har jo ikke større autoritet end rigsrevisionen. IT er ikke alt.... selv om du åbenbart gerne vil gøre det til det.

// Jesper

Poul-Henning Kamp Blogger

Når et projekt kører i hegnet under det nuværende paradigme er der en lang række instanser der træder i kraft og laver undersøgelser.

Det er faktuelt forkert.

Det er kun et fåtal af de offentlige (og private!) IT-skandaler der bliver undersøgt bare nogenlunde ordentligt og kun et fåtal af de undersøgelser der bliver foretaget resulterer i et dokument med erfaringsopsamling.

Hvor er f.eks det dokument der gør os klogere på hvorfor vi spildte disse 36 mio kroner: https://www.version2.dk/artikel/undervisningsministeriet-spilder-36-mill...

Problemet med de undersøgelser der faktisk foregår, primært fra rigsrevisionens side, er at de stort set udelukkende fokuserer på at få ansvaret placeret.

I forhold til ikke at begå de samme fejl igen, er det inderligt ligegyldigt hvem der dummede sig men altafgørende hvordan de dummede sig.

Derfor har vi brug for en ITHK

Jesper Ravn

Uanset om en eller anden ny model måtte virker, vil jeg fastholde at en institution til uafhængig uvildig undersøgelse af havarerede projekter med krav om fuldstændig fremlæggelse til fremtidig læring er et godt og på nuværende tidspunkt helt nødvendigt tiltag. Omfanget og konsekvenserne af katastroferne er helt astronomiske.

Ok, her er vi så bare uenige. Jeg mener kommende tiltag, skal ske med forebyggelse via en radikal kulturændring i det offentlige, hvor man opsætter nye simple succes kriterier til arbejdsgange, IT-projekter og systemer i staten.
Når alt føles som kaos omkring en, er der intet der slår en lavpraktisk brianstorm :-)
Det kunne være følgende:

Få de nødvendige interne ressourcer og spidskompetencer tilbage i offentlig IT.
Hvordan gør man så det?

Ændre kulturen, så man får værdier tilbage som f.eks. arbejdsglæde, ansvarsfølelse og faglig stolthed.
Hvordan gør man så det?

Ledelsen, projektledere og mellemledere skal alle gå foran og vise medarbejderne at de tager ansvar og støtter deres kollegaer også i svære tider.

Ledelsen skal lære sige fra overfor politiske målsætninger og højtflyende visioner.
Det kunne f.eks. være at sige, dette kan ikke lade sig gøre på en forsvarlig måde. Vi anbefaler derfor at lovgivningen forenkles og laves om.

Medarbejderne skal kunne sige fra over ledelsen med tilsvarende argumenter.
Ledelsen eller de ansvarlige projekt-chefer skal kunne mærke konsekvensen, at være ansvarlig for et-hoved-under-armen-projekt eller system. Her tænker jeg på 10 kolde bagi.

Juster lønninger, så man kan fastholde erfaringen og et højt kompetence niveau.
Giv bonusløn til alle medarbejdere på projekter der overholder deadlines og virker efter hensigten.

Alle projekter og systemer skal igennem en standard vurdering og startes op via en PoC i miniskala med korte deadlines.
Hvordan gør man så det?

Findes der tilsvarende standard systemer rundt omkring verden vi kan benytte eller starte op fra.
Findes der tilsvarende leverandører, der har prøvet dette før og kan hjælpe os godt på vej og ikke kun vælge den leverandør der er billigst.
Erkend at man i disse projekter og systemer ikke kan tilgodese og opfylde alle parters krav og ønsker.
Alle projekter og systemer, skal have del-leverancer, så det ikke bliver overskueligt og man bevarer fokus.
Alle systemer skal først laves som en PoC og virke i miniskala med en kort deadline. Dette skal startes op ud fra en punktplan og skal være meget kortfattet. Alt det andet blah, blah dokumentation skal der først bruges tid på bagefter, hvis PoC’en er vellykket og godkendt.
o.s.v….

Michael Cederberg

Vil du være sød at svare på og forholde dig til den praktiske udførelse af ITHK
Håndtering som f.eks. havarikommissionerne for jernbane og luftfart, se:

Forskellen mellem transport og IT er at man med transport forsøger at standardisere processer til en sådan grad at piloters, mekanikeres, etc. arbejde til en stor grad handler om at følge velbeskrevne procedurer. Når der opstår et problem, så har de fleste aktører en interesse i at finde en forbedring der sikrer at problemet ikke opstår igen. For såfremt en fejl gentages så kan man i de fleste tilfælde se at det er en gentagelse, man kan udpege skyld, spørge om hvorfor de samme lavede fejlen en gang til.

Med IT er det aldrig gentagelse af den sammen eksakte fejl – det handler om store variationer af den sammen fejl (og man kan have lange diskussioner om hvorvidt det faktisk er den samme fejl). Der er således en interesse i at skubbe ansvaret over på andre.

Måske, men der er ligesom Professor Kim Normann Andersen postulat om at det hele bliver fikset, blot det private overtager, ingen evidens for påstanden.

I praksis kan man ikke købe et one-off produkt, hvis man ikke forstår indgående hvordan det er lavet. Problemet for det offentlige (og nogen private) virksomheder er at man tror man kan købe IT på samme måde som blyanter eller bygninger. Jeg læser med stor glæde om PHK’s husbyggeri og lægger mærke til hvor mange detaljer han har fingeren på. Hvis han havde bestilt et standardhus så havde han ikke behøvet helt den samme detail forståelse.

Med IT er de fleste vigtige krav nye hver gang. Hvis vi gør det helt samme to gange, så har vi i princippet fejlet. For så skulle vi have genbrugt ”koden” fra første omgang. Det er anderledes med de fleste andre ting.

EU udbud var tiltænkt at skabe fri konkurrence og gennemsigtighed. Det modsattes synes at være resultatet på IT området.

EU udbud fungerer kun hvis man ved meget præcist hvad det er man vil have. Som tidligere beskrevet, så ved folk det sjældent når det handler om IT (med mindre det handler om implementering af en eller anden standard). I øvrigt er det også svært at specificere krav i andre tilfælde – fx rengøring (hvordan specificerer man i detaljer hvad det er for et arbejde ISS skal udføre?). For slet ikke at glemme mange lederes forsøg på at koge krav ned til nogle få ”key performance indicators”.

Giv bonusløn til alle medarbejdere på projekter der overholder deadlines og virker efter hensigten.

Med det resultat at alle estimater bliver 6 gange højere og projekter når deres deadlines selvom kvaliteten er lav.

Poul-Henning Kamp Blogger
Lise Gerd Pedersen Blogger

Tak til Søren Lauesen for kommentarerne til min kritik. Et par uddybninger.

Jeg har senere fået hele min rapport om PolSag valideret af personer der på det tidspunkt var i Politiet eller hos Scanjour.


Men ikke hovedleverandøren, CSC? Det er mit subjektive indtryk, at historiefortællingen er skæv, og at der er problemer, der er gået under radaren. Jeg skal i øvrigt huske at komme med den disclaimer, at jeg valgte at forlade CSC i foråret 2009 efter afslutningen af POLSAG designfasen. Jeg har ingen insiderviden om, hvad der siden skete.

Lise, ting kan godt finde sted uden at du har hørt om dem.


Jeg skriver jo netop, at jeg ikke kan afvise, at det kan have fundet sted, men at det ikke er repræsentativt for projektet. Det er særdeles relevant at pege på det reelle problem, at arbejdsprocesserne ikke var kendte (A8). Men at nogle politifolk på et konkret møde i opstarten har været i tvivl om, hvortil deres tavshedspligt gik, ser jeg ingen grund til at gøre sig lystig over i aviser, TV og nu en videnskabelig rapport.

Det er lidt i klasse med, at du forleden nævnte ”et system til grisetransporter” … jeg går ud fra, at du med det hentyder til, at der i 2007 kom en ny lov med en klippekortordning i fm. dyretransporter (lige som ”klip i kørekortet”). Det førte naturligvis til en ændringsanmodning, idet man også skulle kunne registrere det i POLSAG. I langstrakte projekter ændrer virkeligheden sig undervejs, og det håndterer man professionelt med ændringsanmodninger og justering af kontrakten. Så hvorfor er ”grisetransporter” interessante i den sammenhæng du omtalte dem? (ud over underholdningsværdien)

Det de blev erstattet med kalder jeg "design-level requirements", som gør at man ikke længere kan se om Scanjour's system kunne bruges uden eller med mindre ændringer


Som jeg skriver, var disse dokumenter ikke krav, men løsningsspecifikationer til programmørerne. På dette tidspunkt havde designgruppen (hvori deltog både erfarne politifolk og ScanJour specialister) tygget igennem, hvorvidt standard kunne anvendes til de enkelte arbejdsopgaver, eller om det var nødvendigt at foretage specialtilpasninger. Designprocessen kunne godt føre til mindre ændringer i arbejdsprocesserne. Jeg synes, at du skal genoverveje A3 og C6.

Jeg kan ikke genkende at jeg anfører løsninger der er "bare lige".


Nej, det er også forkert udtrykt fra min side. Jeg beklager. Du angiver faktisk ikke alternative løsninger, men kritiserer på en og samme tid, at man vil have det hele på en gang (A7), og at man serviceenabler de legacysystemer, man fortsat vil integrere til. Det system, POLSAG skulle erstatte, var tæt integreret med mange andre gamle systemer, både opslag og ajourføringer (ikke kun ”feed”). Det ville være at tage det hele på en gang, hvis man havde valgt at udskifte samtlige systemer i et (endnu større) big bang. I stedet valgte man en serviceorienteret arkitektur med de udfordringer en sådan giver. En af dem har givetvis været, at man i pilottesten havde både det gamle POLSAS og det nye POLSAG i drift samtidig med hver deres type integrationer – det kan være forklaringen på de to versioner af ATKS. Det var næppe en blivende løsning (men jeg gætter her).

Jeg har frittet Lise for at få hendes bud på hvad der kan gøres, men jeg synes ikke vi kom længere end til at der skulle mere kvalificerede folk på projekterne. Jeg drømmer om at finde ud af hvad disse ekstra "kvalifikationer" skulle være.


Jeg mener, at det allerstørste problem er mangelen på digital ledelse og (anvendelse af) arkitektkompetencer på kundesiden. Konsulenthuse og leverandører er dybest set sælgere, der tilbyder den vare, som kunden forlanger. Da Rigspolitiet (eller Finansministeriet?) besluttede sig for, at POLSAG skulle indkøbes på en FESD-kontrakt, afholdt CSC/ScanJour sig ikke fra at tilbyde sådan en løsning. Jeg er overbevist om, at der på alle de kuldsejlede IT-projekter har siddet kvalificerede folk, som blot ikke er kommet til orde – både hos kunden og hos leverandørerne.

Det er selvfølgelig glimrende at identificere begåede fejl og udtænke kure. Men før vi får gjort staten til en bedre indkøber, som også gør brug af den indvundne viden, flytter det ikke så meget. Derfor mit næste blogindlæg.

Michael Cederberg

Det er måske forbigået din opmærksomhed, men det har IT branchen også arbejdet henimod.
Hvorfor tror du f.eks hele "COTS" fænomenet startede ?

Jo, men det er ikke pointen. Vi snakker ikke om problemer i projekter der går ud på at installere af Windows på 5000 computere. Vi snakker om at få standard software til at fungere sammen med anden software og til at understøtte netop de arbejdsprocesser en given organisation har. Og det er netop i denne opgave problemerne opstår.

Når man vælger standard software, så vælger man også at udføre nogle bestemte arbejdsprocesser på en eller flere foruddefinerede måder. Og da organisationer af både gode og dårlige grunde er forskellige så gør man ting på forskellige måder, derfor skal softwaren eller organisationen tilpasses. Om man gør det ene eller andet, bør afhænge af hvor essentielt netop ens specifikke arbejdsproces er (dette glemmes ofte).

Så selvom vores løsninger består af flere og flere standard komponenter, så vil store one-off projekter have deres egen unikke sammensætning og deres helt egne udfordringer. Og det er der problemerne opstår.IT bliver aldrig billigere for vi vil hele tiden kræve mere af det. De fleste problemer som skal løses er ikke tekniske, men processuelle. Jeg forstår nu stadigvæk ikke hvordan man kan bygge et system som POLSAG og så først i testfasen opdage at det aldrig vil kunne levere acceptable svartider. Det er et teknisk problem og det er mig en gåde hvordan man kan nå dertil.

Bente Hansen

Jeg forstår nu stadigvæk ikke hvordan man kan bygge et system som POLSAG og så først i testfasen opdage at det aldrig vil kunne levere acceptable svartider. Det er et teknisk problem og det er mig en gåde hvordan man kan nå dertil.


Enten har du ikke arbejdet ret meget, eller i mange år med EDB, Systemer, OS, CPU'er, Driver, Standarder, Ledelse, Kunder, Specifikationer, .... Som Amanda, OS2, Vista,

Som Windows gennem tiderne - som Windows MC til XP.
Hvor MS var stolt over at have rettet de første 2.000 fejl, de manglet så de sidste 20.000. Et OS, som kun skulle på gaden, for at sælge nye OS, i en tid mens Vista var stærkt forsinket. Nok først med Win10, det begyndt at fungere sådan nogenlunde, hvorefter Microsoft tilsyneladende har nedlagt det.,

Fancy hjemmesider, som laves på lokalnet med 10 mb, af skoledrenge. Som dog også har lidt lange svartider, på et 56K modem

Jeg undres ikke. Men jeg forundres dog over hvor meget amatøragtig og uduelig ledelse der er, når man tænker på deres uddannelse og løn. For selv om CSC og KMD er nogen PAPhoveder, man efter outsourcing til indien, og fyring/flygtning af alt teknisk og udviklingsmæssigt fra Danmark. Ikke skal vælge som leverandør.

Så ligger alt ansvar, ledelsen, godkendelsen ved toppen af kunden. Altså ved Politikerne, og ledelse laget lige der under.

Det er derfor at SKAT sagen gør så ondt på dem, appen ligger nemlig kun et sted. Og nu bliver det svært at give skylden til en enkelt mand, som passet arbejdet for nu 70 ansatte, eller at tage give det til mellemleder, også sende dem til Herning, med et spark i røven på et par millioner.

Som jeg har forstået det på Polsagen, var det også meget dårligt ledelse og total mangel på indsigt og styring af EDB projekter, i toppen af Politiet, der har største del af skylden og ansvaret for hvordan det gik.

Det var udnævnt som superbruger, da man kunne blive administrator ved at kunne formatere en diskette. Også har "peter princippet" ordnet resten.

Michael Cederberg

Enten har du ikke arbejdet ret meget, eller i mange år med EDB, Systemer, OS, CPU'er, Driver, Standarder, Ledelse, Kunder, Specifikationer, .... Som Amanda, OS2, Vista,

Jeg er ked af at sige det Bente, men jeg er efterhånden en af dinosaurerne i denne branche så jeg har set lidt af hvert. Og intet af det du skriver er undskyldning for at levere et administrativt system som må kasseres på lange svartider. Allerede i 80’erne kunne man lave systemer af den type. Specifikt er der ingen undskyldning at man først finder ud af det efter at have brugt en halv milliard kroner.

Der kan sagtens være problemer med en stump kode, for svag hardware i opstartsfasen, et dårligt shortcut hist og her, etc. Men en kompetent arkitekt ved på forhånd hvor svaghederne er og har en plan B og C for at fikse dem. Og ingen af dem går ud på at købe den dyreste server på markedet eller andet hardware wizardry. Selvfølgeligt får man overraskelser undervejs, men ingen af dem bør gøre at man må kassere det i den afsluttende testfase. Hvis man ikke på forhånd er sikker på at opgaven kan løses, så skal man ikke gå i gang med den slags.

Poul-Henning Kamp Blogger

Ok, her er vi så bare uenige. Jeg mener kommende tiltag, skal ske med forebyggelse via en radikal kulturændring i det offentlige, hvor man opsætter nye simple succes kriterier til arbejdsgange, IT-projekter og systemer i staten.

Det er utvivlsomt et godt sted at starte.

Men vi skal stadig have en mekanisme til at undgå at lave de samme fejl igen og igen og igen.

Den mekanisme hedder "at lære af egne OG ANDRES fejl" og den forudsætter at man kan få at vide hvad det er for fejl andre har lavet.

Poul-Henning Kamp Blogger

Det er selvfølgelig glimrende at identificere begåede fejl og udtænke kure. Men før vi får gjort staten til en bedre indkøber, som også gør brug af den indvundne viden

Helt enig.

Men det faktisk det smukke ved en ITHK: Når de har offentliggjort deres rapport forventes det at alle, for hvem dens indhold kan være relevant, sætter sig ind i den.

At komme bagefter og sige "det havde jeg aldrig hørt om" er det samme som at sige "Jeg er ikke kompetent til mit job."

Den kritiske detaljer her er at rapporterne er offentligt tilgængelige.

Som jeg sagde tidligere: Det kan godt være at du mener at du har lært alt hvad der kan læres af POLSAG, men jeg kan garantere dig, at 9 ud af 10 IT folk stadig ikke har lært noget af POLSAG,

Jesper Frimann

Alle andre havarikommisioner starter deres arbejde så snart, der har været et havari. Hvorfor skulle ITHK være anderledes?

Hele min (og andres pointe) er jo netop at starte før, der er sket et haveri. Der eksisterer jo allerede omfattende opsamlet viden og dokumenteret erfaring, om hvordan man minimerer risikoen for at projekter fejler og hvordan man stopper uhensigtsmæssige projekter før de overhovedet startes op.

Hvorfor vente på at en ITHK bruger årevis.. på at dissekere endnu flere store fejlede offentlige IT-projekter for at komme til samme konklusion ?

Grunden til at det offentlige IT-projektråd har en gavnlig effekt er jo, at der sidder nogle erhvervsledere med noget erfaring og ledelses kompetence, der kan gøre en forskel.

Jeg mener så lidt, at det at man fra digitaliserings styrelsen fokuserer så meget på netop IT-projektrådet er lidt et symptom på nogle af de "kultur uhensigtsmæssighed", der er i det offentlige. Nemlig at for, at man kan ændre noget skal det være en gruppe af 'Chefer', der kommer med 'det der skal til'.

Det ville IMHO meget mere gavnligt, hvis det var fagligheden i den offentlige institution + IT-faglighed der kom med indputtet og 'det der skal til'.

F.eks. er jeg rimelig sikker på, at der bare i den her diskussions tråd er nok IT-faglighed til stede til, at man ville kunne have en signifikant gavnlig effekt på offentlig IT projekter generelt. Hvis f.eks. ville lytte i toppen af digitaliserings styrelsen...

// Jesper

Poul-Henning Kamp Blogger

Hele min (og andres pointe) er jo netop at starte før, der er sket et haveri.

I taler forbi hinanden.

Du taler om hvad man skal gøre for at undgå yderligere havarier, et emne der fortjener fuldt fokus og indsats.

Vi taler derimod om hvad vi gør når der er sket havarier.

Hvis du har 100% ret kommer havarikommisionen aldrig til at lave noget og vi spilder i værste fald 15 mio/år, på at de sidder og kigger forventningsfuldt på telefonen.

Hvis du derimod ikke har 100% ret, vil der fortsat ske havarier og ITHK vil sørge for at vi i det mindste bliver klogere af de spildte penge.

Uanset hvem "du" er, tror jeg ikke en meter på at vi går fra skod til perfekt i et trin, dertil er der for mange inkompetente skidesprællere hele vejen rundt om bordet.

Derfor finder jeg det utroligt hovmodigt og sige "vi har ikke brug for en ITHK, de vil bare rende i vejen." Selv idag, årtier efter den blev oprettet, bidrager Havarikommissionen for Transport stadig med ny viden og indsigt.

Niels Henrik Sodemann
Michael Cederberg

Lad os lige se på interessenterne når det gælder flyulykker:

  • Ejeren – køber standardprodukt, i praksis ansvarsfri hvis han følger producentens forskrifter
  • Producenten – såfremt problemet kan opstå igen, så er det bedre at tage skylden nu og fikse problemet
  • Underleverandører – samme som producenten, bortset fra at ansvar nogle gange kan skubbes over på andre
  • Ansatte – liv og lemmer for dem selv eller kollegaer, er beskyttet af fagforeninger sådan at fejl kun i meget grelle tilfælde ramme personligt
  • Regulerende/certificerende myndigheder – beskyttet mod retsforfølgelse, regler skabt over mange årtier, meget konservativ når det gælder introduktion af ny teknologi
  • Undersøgende myndighed – ingen interesse i at beskytte nogen, forslag følges ofte ikke

For IT projekter ser det anderledes ud:

  • Ejeren – køber ”one-off” produkt, er typisk håbløs til at stille krav til produktet, står med hele ansvaret når produktet er leveret
  • Producenten – kommer aldrig til at lave samme produkt igen, eneste interesse for at tage ansvar er PR (i bred forstand)
  • Underleverandører – stort set samme som producenten, bortser fra at ansvar nogle gange kan skubbes over på andre
  • Ansatte – ingen positive side ved at tage ansvar for fejl
  • Regulerende/certificerende myndigheder – stort set ikke eksisterende
  • Undersøgende myndighed - ???

Det er to meget forskellige verdener. Jeg kan ikke se at en ITHK kan fungere når ganske få har interesse i at få afklaret hvad der er sket.

Jeg forstår det heller ikke. Det er i sandhed en gåde. Kan du ikke se det hensigtsmæssigt i at få det undersøgt og dokumenteret?

Jo det kan jeg. Jeg kan bare ikke se hvordan man kan lave noget der fungerer.

Anne-Marie Krogsbøll

I IT sammenhæng er det meget nemmere at tale sig ud af det, hvis man ikke ønsker at få det beskidte vasketøj udstillet.


Et eksempel på det kan høres i torsdags-"Deadline"s tåkrummende interview med Peter Loft, som fortæller, hvorledes han/ministeriet/ministeren tilsyneladende valgte at stole blindt på KMD på trods af diverse advarsler om, at det var ved at gå galt - for man var jo deres største kunde, og havde sådan et godt forhold til dem.
https://www.dr.dk/tv/se/deadline/deadline-tv/deadline-2017-05-19

Poul-Henning Kamp Blogger

Det er to meget forskellige verdener. Jeg kan ikke se at en ITHK kan fungere når ganske få har interesse i at få afklaret hvad der er sket.

  1. Det er ikke "ganske få" der har en sådan interesse, det er i yderste konsekvens alle landets skatteydere der har en interesse.

  2. Læs Søren Lauesens rapport ? Den er et glimrende eksempel på den type viden der vil komme ud af en ITHK.

  3. At du "ikke kan se hvordan det skal fungere" når Søren Lauesen nu i 3 runder ført eksistensbevis for at det kan lade sig gøre tyder på at du burde genoverveje dine dogmer?

Jesper Frimann

I taler forbi hinanden.

Du taler om hvad man skal gøre for at undgå yderligere havarier, et emne der fortjener fuldt fokus og indsats.

Vi taler derimod om hvad vi gør når der er sket havarier.

Ja. Det er jeg 100% klar over.
Men nu er det sådan, at forebyggelse og at tage problemer i opløbet er lang lang at foretrække. Så hvorfor så ikke starte med det, istedet for bare at insistere på at en ITHK er 'Løsningen' (TM).

Hvis du har 100% ret kommer havarikommisionen aldrig til at lave noget og vi spilder i værste fald 15 mio/år, på at de sidder og kigger forventningsfuldt på telefonen.

Hvis du derimod ikke har 100% ret, vil der fortsat ske havarier og ITHK vil sørge for at vi i det mindste bliver klogere af de spildte penge.

Hvis der er en ting jeg er sikker på, så er det hvor lidt jeg ved. Så derfor er jeg helt sikker på, at selv om jeg fik 100% indført det 'regime' jeg ved virker, så ville der stadig være katastrofe projekter.

Uanset hvem "du" er, tror jeg ikke en meter på at vi går fra skod til perfekt i et trin, dertil er der for mange inkompetente skidesprællere hele vejen rundt om bordet.

Der er rigtig mange inkompetente folk. Men der er også mange kompetente folk. Og sjovt nok så er min erfaring, at hovedparten af de kompetente folk sidder i 'den faglige del' af styrelser, ministerier og virksomheder.

Der hvor inkompetencen er størst er helt klart når det kommer til ledelseslaget i og mellem IT og forretningen.
Det er også helt naturligt, da det kræver en kombination af menneskelige egenskaber og færdigheder, som ikke alle får mulighed for at udvikle. Men jeg har da mødt en håndfuld folk, der 'ku det der'. ( PO/OLR ...) Jeg er så personlig ikke en af dem. Men da denne type af ledere er lige så svære at finde, som hønsetænder, så må man gøre noget andet. Og det andet er IMHO Enterprise Architecture, hvor du så at sige formalisere, at IT-fagligheden får noget at skulle have sagt. Og det du gøre er at du erstatter 'SuperLederen' der både forstår IT, forretningen, mennersker og ledelse med en gruppe af folk (Ledere og IT-folk) der så at sige til sammen magter at udføre SuperLederens rolle.

Og nej, man kan ikke gå fra r*ven af fjerde division til superligaen på et split sekund. Det kræver mange års hårdt arbejde. Hvilket også er grunden til, at mange af os siger.. at vi er nødt til at gå i gang nu.. vi kan ikke vente.. For det er i høj grad en spørgsmål om at ændre kulturen.

Derfor finder jeg det utroligt hovmodigt og sige "vi har ikke brug for en ITHK, de vil bare rende i vejen." Selv idag, årtier efter den blev oprettet, bidrager Havarikommissionen for Transport stadig med ny viden og indsigt.

Jeg er helt med på, at:

1) det skal være muligt at udføre en IT-haveri mæssig funktion
2) At der skal være feedback loops der fremmer at 'man' lærer af sine egne/afdelingens/projektet/andre projekter/andre ministeriers fejl og erfaringer.

Og det tror jeg stort set alle er.

MEN nu er det sådan at implementation er vigtigt.

Og der er allerede en rigsrevision, så måske var det en bedre option, at man havde et IT-revisions kontor, der kunne assistere rigsrevisionen med at lave IT-revisions delen ? Et kontor der også kunne assistere datatilsynes m.fl. med IT-revisions kompetencer ?

Mht. feedback loops, så er sådan 'lær af dine fejl' jo allerede en af hjørnestenene i mange af de frameworks, som 'det offentlige' og deres leverandører bekender/formelt bruger/burde bruge. Det er en del af PRINCE2, OiO/TOGAF/ITIL m.fl. og det er ud over de påbud man får fra datatilsynet, rigsrevisionen m.fl.

Fordi der kommer endnu en Feedback mekanisme i brug (IT-haverikommision), hvorfor skulle denne så gøre en forskel, når nu alle de andre feedback mekanismer ikke har magtet det ?

// Jesper

Poul-Henning Kamp Blogger

Men nu er det sådan, at forebyggelse og at tage problemer i opløbet er lang lang at foretrække. Så hvorfor så ikke starte med det, istedet for bare at insistere på at en ITHK er 'Løsningen' (TM).

Der er ingen der siger at ITHK er 'Løsningen'.

Løsningen er at vi bliver klogere og bedre.

ITHK leverer materiale til den process.

Hvis der er en ting jeg er sikker på, så er det hvor lidt jeg ved. Så derfor er jeg helt sikker på, at selv om jeg fik 100% indført det 'regime' jeg ved virker, så ville der stadig være katastrofe projekter.

Men du mener ikke at det hjælper noget at lave systematisk erfaringsopsamling på disse havarier og sprede denne viden til hele branchen, så folk kan lære noget deraf ?

Den logik kan jeg slet ikke følge...

Og der er allerede en rigsrevision, så måske var det en bedre option [...]

Nej, Rigsrevisionen er formodentlig et dårlig sted at placere ITHK og hvis du vil vide hvorfor, så sammenlign rapporterne om IC4 fra Rigsrevisionen og Havarikommissionen.

Rigsrevisionen tager sig af skyldplacering og alt "han sagde, de sagde" fingerpegeriet.

Havarikommissionen tager sig af at ledningerne er trukket forkert og toget ikke kan bremse.

Det er to helt forskellige tilgange, som begge er nødvendige.

Jesper Frimann

Der er ingen der siger at ITHK er 'Løsningen'.

Well.... det er jeg da glad for at høre.

Løsningen er at vi bliver klogere og bedre.

Enig.

ITHK leverer materiale til den process.

Kan vi sige... en ITHK er en af flere mekanismer der leverer materiale til den process ?

Men du mener ikke at det hjælper noget at lave systematisk erfaringsopsamling på disse havarier og sprede denne viden til hele branchen, så folk kan lære noget deraf ?

Nej, det er jo ikke hvad jeg skriver. Jeg siger jo netop, at man altid kan bliver klogere, derfor er der vigtigt at selv i den mekanisme man laver til systematisk erfaringsopsamling, der er der indbygget en erfarings opsamling således at denne mekanisme selv kan bliver bedre.

Selv om jeg har .. en hel del erfaring.. så kan jeg stadig lære nyt, og forhåbentlig er har jeg nogle år endnu, før jeg størkner helt og skal sættes over i hjørnet af kontoret for 'Gamle Sure Mænd (M/K)' og kun bruges i ROnly-mode.

Nej, Rigsrevisionen er formodentlig et dårlig sted at placere ITHK og hvis du vil vide hvorfor, så sammenlign rapporterne om IC4 fra Rigsrevisionen og Havarikommissionen.


Det er heller ikke hvad jeg skriver, og det er så absolut heller ikke noget jeg ville anbefale. Jeg skrev at man skulle lave et IT-revisions kontor, der kunne assistere med IT-revision.

Igen så er jeg fortaler for at man laver et selvstændig IT-styrelse uden for nogen andre ministerier, og hver ville det være naturligt at placere et IT-revisions kontor, der så kunne trække på de faglige kompetencer i sådan en selvstændig styrelse. Ellers så ville det blive en for stor org. med for mange folk med viden der hurtigt ville blive forældet fordi de ikke bruger den og følger med.

Rigsrevisionen tager sig af skyldplacering og alt "han sagde, de sagde" fingerpegeriet.

Havarikommissionen tager sig af at ledningerne er trukket forkert og toget ikke kan bremse.

Det er to helt forskellige tilgange, som begge er nødvendige.

Det er sådan set heller ikke rigsrevisionens formål at lave skyldplacering. (http://www.rigsrevisionen.dk/om-os/raadgivningsprincipper/).

Derimod kan Statsrevisorerne, godt pege fingre...
(http://www.ft.dk/Statsrevisorerne/Arbejde.aspx)

// Jesper

Niels Henrik Sodemann

@Michael Cederberg

Jo det kan jeg. Jeg kan bare ikke se hvordan man kan lave noget der fungerer.

Hvad er det, der gør at du ikke tror at en kommission (med hjælp fra dygtige IT folk) kan finde ud af om et system har problemer med svartid, hvilke komponenter der er problematiske samt at finde ud af om svartider har været rejst som et issue undervejs i projektet (f.eks. ved at kigge på projektleder møder).

Tror du ikke også at Kommissionen kan udrede om kontrakten havde en delprøve der kigge på svartider og om den er blevet afholdt?

Michael Cederberg

Det er ikke "ganske få" der har en sådan interesse, det er i yderste konsekvens alle landets skatteydere der har en interesse.

Ja, men det er ganske få af informationsleverandørerne til ITHK som har den interesse. Så selvom det kunne være i landets interesse at få CSC til ærligt at fortælle hvad de mener gik galt i POLSAG så gør de det ikke. De har et rygte at passe på. Det samme med KMD/EFI og de andre.

Læs Søren Lauesens rapport ? Den er et glimrende eksempel på den type viden der vil komme ud af en ITHK.

Jeg synes det er en glimrende rapport. Men jeg har to problemer med den. For det første tror jeg ikke han har fået ærlige svar over hele linjen. Der er således en stor risiko for at mange store problemer er udeladt. Samtidigt er der en stor sandsynlighed for at nogle af problemstillingerne fordrejet sådan at de primært rammer modparten (det her kunne blive meget længere, men tiden er ikke til det).

For det andet så er mange af SL’s konklusioner direkte overlappende med fx Steve McConnells ”Classic Mistakes Enumerated” fra 1996 som jeg godt kan lide. Vi kender godt problemerne – de er ikke specielt nye og velbeskrevne. Det svære er at finde processer der undgår dem.

At du "ikke kan se hvordan det skal fungere" når Søren Lauesen nu i 3 runder ført eksistensbevis for at det kan lade sig gøre tyder på at du burde genoverveje dine dogmer?

Jeg er ikke enig i at SL har gjort det. Han har lavet undersøgelser men at den beskriver de reelle problemer vil jeg forholde mig skeptisk overfor (dette er ikke en kritik af SL). Fx hørte jeg fra en der var med på et af projekterne at en stor del af en af de audits som blev lavet, gik ud på at lave statisk kodeanalyse på hele kodebasen. Resultatet var med til at beskrive koden som at have ringe kvalitet. Og hvor det er fint og i nogle tilfælde fornuftigt at score højt på statisk kodeanalyse, så siger det ganske lidt om kodekvalitet og absolut ingenting om arkitektur.

Jo det kan jeg. Jeg kan bare ikke se hvordan man kan lave noget der fungerer.
Hvad er det, der gør at du ikke tror at en kommission (med hjælp fra dygtige IT folk) kan finde ud af om et system har problemer med svartid, hvilke komponenter der er problematiske samt at finde ud af om svartider har været rejst som et issue undervejs i projektet (f.eks. ved at kigge på projektleder møder).

Jeg tror det er svært at få alle nuancerne med, og uden det så ender man nemt med konklusioner som er direkte forkerte. Ydermere så ender man nemt med at slå ned på den enkelte undersøgers kæpheste. Uden at have været med til møder forstår man ikke hvorfor beslutninger er taget og hvad overvejelserne var. Og nogen af parterne kan have interesse i at skjule deres fejl i det omfang det kan lade sig gøre. Såfremt det ikke kan lade sig gøre kan man altid skyde dem over på andre. Når projektet er slut og alle er gået hjem, hvem er der til at modsige?

Tror du ikke også at Kommissionen kan udrede om kontrakten havde en delprøve der kigge på svartider og om den er blevet afholdt?

Det er jeg sikker på den kan. Men det er bare sjældent det der er problemet. Man kan ikke teste om arkitekturen er dårlig. Som jeg forstår det POLSAG projektet, så var en af grundene at man brugte et ORM lignende modul som generede en enorm mængde database interaktionen. Den slags kan være svært at fange i test – med mindre man lige præcist rammer den situation hvor det sker (fx latency, data). Men det er typisk noget som en dygtig arkitekt kan se meget tidligt i designet (som jeg forstår det var der også folk der stillede spørgsmålstegn ved dette tidligt).

Personligt mener jeg udover hvad der tidligere er beskrevet, at kunden ikke forstår hvad han køber (det har SL også med i C3). Kunden skal i POLSAG forstå at den planlagte løsning ikke vil fungere. Desværre er det de færreste organisationer der har råd til at sætte dygtige folk til at følge med i hvad leverandøren laver. Folk som er dygtige nok til selv at kunne løse opgaven såfremt de havde folkene.

Niels Henrik Sodemann

@Michael Cederberg
Øhh,

Så selvom det kunne være i landets interesse at få CSC til ærligt at fortælle hvad de mener gik galt i POLSAG så gør de det ikke. De har et rygte at passe på. Det samme med KMD/EFI og de andre.

Som Lise nævner i blog og som det fremgår af f.eks. EFI kontrakten, så har leverandøren tavshedspligt. Tavshedspligt er fastsat af kunden og dennes juridiske rådgiver. Hvad er det der får dig til at synes at det er en dårlig ide at tvinge parterne til at bistå med at opklare hvad der gik galt?

Michael Cederberg

Som Lise nævner i blog og som det fremgår af f.eks. EFI kontrakten, så har leverandøren tavshedspligt. Tavshedspligt er fastsat af kunden og dennes juridiske rådgiver. Hvad er det der får dig til at synes at det er en dårlig ide at tvinge parterne til at bistå med at opklare hvad der gik galt?

Det er derfor en Havarikommission har og skal have lovens bogstav i ryggen.

Med mindre der er meget detaljerede beslutningsreferater for hele projektforløbet så vil det ikke være til at sige hvem der har ret. Og hvis man kan dømmes for usandheder, så vil alle firmaer komme med uendelige forbehold hver gang de siger noget. Jeg tror ikke der kommer noget ud af at alle slæber advokater med for at vurdere hvad de kan sige.

Bjarne Nielsen

Med mindre der er meget detaljerede beslutningsreferater for hele projektforløbet så vil det ikke være til at sige hvem der har ret. Og hvis man kan dømmes for usandheder, så vil alle firmaer komme med uendelige forbehold hver gang de siger noget.

Det er sikkert sandt, men det er jo "han sagde, de sagde". Og flg. IT-havarikommissions-ideens ophavsmand, så er det ...

Rigsrevisionen tager sig af skyldplacering og alt "han sagde, de sagde" fingerpegeriet.

Jeg kan så godt sidde tilbage og tænke over, hvad der bliver tilbage til en sådan kommission, når diverse "han sagde, de sagde" komiteer har fået deres? Specielt set i lyset af den seneste høring, hvor Søren Lauesen kun tilskrev 3 af sine 36 skadevirkninger til udførelsen - så der er tilsyneladende ikke meget tilbage, som kan skyldes "at ledningerne er trukket forkert" - og det vil sige IT-havari-kommissionen, for PHK siger selv:

Havarikommissionen tager sig af at ledningerne er trukket forkert og toget ikke kan bremse.

Forstå mig ret: jeg tror bestemt at en PHKs IT-havari-kommision har sin plads og berettigelse, og jeg kan kun være for, at vi drager maksimal læring af fejl - men jeg er på ingen måde overbevist om, at det er en nødvendig endsige tilstrækkelig betingelse for at undgå at fremtidige projekter kuldsejler (specielt fordi, at det åbenbart kun er PHK selv, der selv efter så megen debat, forstår præcist hvad det går ud på).

Derfor bliver jeg også en smule træt, når jeg ser den kæphest blive bragt af stald ved alle festlige lejligheder - jeg frygter at den tager opmærksomheden fra at få adresseret de væsentligste problemer (ikke mindst fordi at det er blevet et buzzword, som alle siger, men kun en forstår - og så spilder vi tiden med at tale forbi hinanden).

Poul-Henning Kamp Blogger

Med mindre der er meget detaljerede beslutningsreferater for hele projektforløbet så vil det ikke være til at sige hvem der har ret.

For N'te gang: Det er ikke ITHK's opdrag at afgøre "hvem der har ret" men derimod "hvad der gik galt".

Hvis konklusionen på det er "Der existerer ikke et eneste møderefererat" så burde det være nemt at undgå samme problem på fremtidige projekter.

Michael Cederberg

For N'te gang: Det er ikke ITHK's opdrag at afgøre "hvem der har ret" men derimod "hvad der gik galt".

Hvis man læser NTSB's eller lignende havarirapporter, så er en vigtig del at finde ud af hvem gjorde hvad. Ikke for at tildele skyld, men for at afdække hændelsesforløbet. Men i næsten alle de rapporter jeg har læst er det ligetil at assigne skyld.

Som jeg skrev tidligere i denne tråd, så har stort set alle stakeholders i NTSB havarirapporter en interesse i at alt kommer frem og samarbejder af samme grund hen mod det ”ædle mål”. Og som jeg tidligere skrev, så har stakeholders i store IT projekter ikke nødvendigvis samme interesse.

Så selvom det ikke er en havarikommissions opgave er at afgøre hvem der har ret eller skyld, så vil en velunderbygget rapport alligevel fortælle det. Derfor kan man ikke forvente ordentligt samarbejde.

Hvis konklusionen på det er "Der existerer ikke et eneste møderefererat" så burde det være nemt at undgå samme problem på fremtidige projekter.

Det kan sagtens være. Men man kan også dræbe projekter med bureaukrati. Mødereferater handler ikke kun om at skrive dem. De skal også læses, diskuteres og i nogen tilfælde rettes til …

Poul-Henning Kamp Blogger

Hvis man læser NTSB's eller lignende havarirapporter, så er en vigtig del at finde ud af hvem gjorde hvad. Ikke for at tildele skyld, men for at afdække hændelsesforløbet. Men i næsten alle de rapporter jeg har læst er det ligetil at assigne skyld.

Du kan danne dig din egen mening om hvem der har skyld, men i det danske samfund har vi nogle helt klare procedurer for at afgøre om folk er skyldige eller ej og indtil de konkludrer andet, er folk uskyldige.

Og som jeg tidligere skrev, så har stakeholders i store IT projekter ikke nødvendigvis samme interesse.

(Jeg tror du overvurderer hvor høj moralen er i transportbranchen, forskellen er alene at de efterhånden har vænnet sig til at have en HK)

Men det er netop fordi IT-Branchen(-s medlemmer) tydeligvis ikke har denne interesse, er samfundet bliver nødt til at sætte tommelskruerne på dem via lovgivning.

En ITHK er kun en del af den nødvendige lovpakke, der bør også indføres autorisationskrav og erstatningspligt.

Niels Henrik Sodemann

@Michael Cederberg:

Så selvom det ikke er en havarikommissions opgave er at afgøre hvem der har ret eller skyld, så vil en velunderbygget rapport alligevel fortælle det.

Nej, de offentlige it-projekter, der bliver diskuteret her er baseret på kontrakter med fastsat ansvar. Kontrakterne kan f.eks. fastlægge at det er leverandørens ansvar at levere til en given milepæl. Hvis det ikke sker er leverandør i mislighold og kan sanktioneres.

Det er uendeligt meget anderledes end ”hvad der gik galt”, som kan benyttes til fremtidig læring.

I et tænkt eksempel kunne leverandøren til et inddrivelsessystem være ansvarlig for at systemet aldrig kom i luften og vil kunne sanktioneres som hjemlet i kontrakt ved f.eks. ikke at få kontraktsum udbetalt eller ved at skulle betale erstatning for tab. ”Hvad der gik galt” kunne f.eks. være at man forsøgte at IT enable urealistisk mange regler.
Det første håndteres af jurister med udgangspunkt i den indgåede kontrakt og afgøres i sidste ende ved en domstol.

”Hvad der gik galt” tjener til fremtidig læring, således at de der igangsætte fremtidige projekter forsøger at undgå de samme fejl.

Michael Cederberg

(Jeg tror du overvurderer hvor høj moralen er i transportbranchen, forskellen er alene at de efterhånden har vænnet sig til at have en HK)

Jeg tror du undervurderer hvor meget højere den er indenfor luftfartsbranchen. Når det gælder jernbaner er jeg mere tvivlende overfor alle aktørerne, inklusive havarikommissionen. I øvrigt tror jeg en jernbanemateriel-indkøbs-havarikommission vil løbe ind i samme problemer som jeg tidligere har beskrevet en ITHK vil opleve. En fin syndebuk vil dog være tidligere ledelser i DSB – de har ingen mulighed for at forsvare sig (selvom de givetvis ikke er skyldfrie).

En ITHK er kun en del af den nødvendige lovpakke, der bør også indføres autorisationskrav og erstatningspligt.

Jeg ønsker ikke at vi får samme krav til udvikling af IT systemer, som man har indenfor luftfart. Det vil standse alt udvikling. Man kan også blive for konservativ, og autorisationskrav er noget der hører til brancher hvor udviklingen går langsomt. Jeg ville gerne luge ud i klamphuggere, bløddyr, narrehatte, hundehoveder, (socialdemokrater), talentløse skiderikker og amatører i vores branche. Men jeg er bange for at det vil bremse den udvikling og kreativitet som også er vigtig.

Erstatningspligt kan det offentlige og andre interesserede skrive ind i kontrakter. Det vil gøre alle projekter meget dyrere og skabe et endnu dårligere samarbejdsklima. Jeg er ikke sikker på det er en god ide – jeg har lagt mærke til at byggebranchen heller ikke har fundet den optimale løsning og i nogen tilfælde vælger anden retning.

For konsum-elektronik kunne jeg godt ønske mig en større grad af ansvar. Men det er noget der skal laves på EU eller EU-USA plan.

I et tænkt eksempel kunne leverandøren til et inddrivelsessystem være ansvarlig for at systemet aldrig kom i luften og vil kunne sanktioneres som hjemlet i kontrakt ved f.eks. ikke at få kontraktsum udbetalt eller ved at skulle betale erstatning for tab.

Ja, men måske var det ikke leverandøren der var problemet. Måske opdagede kunden halvvejs i projektet at det bestilte projekt ikke ville virke eller ikke opfylde de reelt krav. Der er mange muligheder. Det er sjældent kun den ene part som er problemet når IT projekter går galt.

”Hvad der gik galt” kunne f.eks. være at man forsøgte at IT enable urealistisk mange regler.

Måske. Men hvem skulle vurdere det? For at vurdere det, så skal man ind og forstå alle de mange regler. Måske var der faktisk kun 3 arketyper og resten var variationer deraf. Det kræver indgående viden og vurderingen er ekstrem subjektiv. Jeg har i min karriere set projekter udskreget som succeser selvom de fleste så det som en fejltagelse. Succeser fordi dem der skrev ”historien” havde brug for en succes. Jeg har også set det omvendte. Både når man ser på hele projekter og på dele af projekter.

”Hvad der gik galt” tjener til fremtidig læring, således at de der igangsætte fremtidige projekter forsøger at undgå de samme fejl.

Det kan der ikke være to meninger om. Problemet er at blive blot tilnærmelsesvis enige om ”hvad der gik galt”.

Bente Hansen

så der er tilsyneladende ikke meget tilbage, som kan skyldes "at ledningerne er trukket forkert


Som med Apollo, hvor fremtidigt fejl, blev løst ved at afkorte kabler så meget, at de kun kunne nå, hvis de var isat korrekt.

Eller i Airbus projektet, hvor cockpit og resten af flyet ikke kunne koblet sammen. Med et modsat problem :-)

Så jeg tror at PHK, mening med en haverikominition, er den samme som bragte Amerikanerne på måneden. At finde alle fejlene i hvert projekt, også dem som ikke gik helt galt, som har hindre, eller kostet for mange resurse.

Også indarbejde de erfaringer i en best practise, helt fra lovgivning, tilbudsgivning, til afviklingen af projektet,


En af de ting man kan lære, er nok ikke at sørge for, at der er en økonomisk fordel i ikke at levere et projekt. Det har kommuner lært på den hårde måde med KMD, men hvorfor skal det ikke skrives ind i et check bog.
Jo tror ikke at det har den store gang på jorden, at få det gennemført, da netop indkøb og beslutninger om systemer. Skal tages af politiker, der også har mange andre agendaer, end kun at få et projekt til at lykkes, og netop mere viden, som efterfølgende viser de ikke følger anbefalinger, kan få pilen til at pege på dem. Se abe kampen i SKAT. Her nytter en havarikommission ikke, da den vil blive gennemvædet af politik.

Lars Lundin

@Lise Gerd Pedersen

Jeg ved at du har årtiers erfaring med IT, for det oplyser du selv.

Derfor er det ekstra skuffende når din konklusion bare gentager mantraet:

"Lad se fremad i stedet for tilbage!"

1) Inkompetente og bevidst underbydende firmaer får lov at fortsætte,
2) Forvalterne af statens dyre IT-udbud får ingen mulighed for at lære af deres fejl

Alt dette til stor skade for skatteyderne og for IT-branchens omdømme.

En IT-havarikommission som skitseret af PHK vil være en væsentlig forbedring.

Michael Cederberg

Du kan danne dig din egen mening om hvem der har skyld, men i det danske samfund har vi nogle helt klare procedurer for at afgøre om folk er skyldige eller ej og indtil de konkludrer andet, er folk uskyldige.

For virksomheder og enkeltpersoner kan offentlighedens ”domstol” være nok til at man går konkurs. For mindre end en måned siden var halvdelen af nationen i oprør over KMD, selvom få ved hvad der er op eller ned i sagerne. Hvem ved hvad misæren kommer til at koste KMD, selv hvis de aldrig bliver dømt til noget. Offentligheden kan være farligere end domstolene nogen gange.

Det sagde flyfabrikanterne forresten også da man begyndte at lave systematiske undersøgelser af deres vrag.
De fik ret, i en kortere årrække, og det gjorde underværker for flysikkerheden.

Boeing bygget 10 forskellige modeller af civile jetfly, hver i nogle forskellige versioner. De fleste er der bygget over 1000 af. Det er med andre ord serieproduktion. Software udvikling er enkeltstyksproduktion. Ganske anderledes.

FAA og EASA stiller krav til fly og certificerer færdigdesignede fly. De har stiller ikke krav til processen omkring flydesign, men der er krav til det færdige resultat. Det du foreslår er markant anderledes.

Niels Henrik Sodemann

@Michael Cederberg

Hvem ved hvad misæren kommer til at koste KMD, selv hvis de aldrig bliver dømt til noget

Du får blandet en del begreber sammen, hvorfor dine slutninger bliver noget forkerte.

I den pågældende sag har kunden ophævet kontrakten. Det er sædvane i offentlige kontrakter at det kan ske, såfremt der foreligger væsentlig misligholdelse. En væsentlig forsinkelse ift. den i kontrakten fastsatte overtagelsesdata vil sandsynligved kunne udgøre en væsentlig misligholdelse. Der er dog ofte et bods system, der går forud for ophævelsen bed overskridelse af tidsplan, f.eks. med dagbøder. Det er oftest også sådan at kontrakterne fastlægger at tvister skal forsøges løst først gennem forhandling, derefter ved mægling af en af Parterne i fællesskab udpeget mægler. I sidste ende i Voldgiftsretten.

Man kan således være ansvarlig og have betydelig økonomisk bet inden man er dømt foran en dommer.

Problem, skyld og ansvar er således forskellige begreber og må bruges rigtigt.

Skyld og ansvar kan udrede økonomi, inkl. bod og erstatning mv., samt give anledning til uddeling af ”næser”. Når begreberne bliver brugt korrekt, må det være klart at skyld / ansvar er noget meget andet end ”hvad der gik galt”.

Niels Henrik Sodemann

@Jesper

Det er altså dig der lige har overset stævningen :)

Nej, det har jeg ikke. Her er det dig der roder begreber sammen.

Man kan sagtens være i mislighold i en kontrakt og få den ophævet uden at skulle betale erstatning. Erstatning har til formål at genoprette en skade eller et tab, således at forholdene (for den skadelidte) så vidt muligt bringes tilbage til situationen før den skadevoldende adfærd. Erstatning er således et ekstra skærpende begreb.

Uanset om leverandøren bliver dømt ved domstol til at betale erstatning, så vil leverandøren lide økonomisk tab af en del af det aftalte vederlag i tilfælde af misligehold.

En leverandør kan også påtage sig skyld / være ansvarlig uden at kontrakt ophæves eller at man kommer i retten (se f.eks.: https://www.version2.dk/artikel/kombit-truer-eg-med-opsigelse-millionkon...). I den pågældende sag er ansvar og ”hvad der gik galt” muligvis to forskellige ting.

Jesper Frimann

Nej, det har jeg ikke. Her er det dig der roder begreber sammen.


Nej Niels, det er dig, der er ude af en forkert tråd og tangent IMHO.

Jeg er sådan set ikke uenig med dig i det du skriver vdr. kontraktuelle forhold.

MEN Michael skrev, hvor du citerer følgende fra:

Hvem ved hvad misæren kommer til at koste KMD, selv hvis de aldrig bliver dømt til noget

var bare, at selv om KMD ikke skulle blive dømt til at betale noget som følge af den stævning som SKAT har præsenteret KMD for. Så vil hele polemikken koste KMD i form af dårlig presse m.m. Det er i det mindste sådan jeg læser det.

Michaels kommentar var et svar på følgende fra PHK:

Du kan danne dig din egen mening om hvem der har skyld, men i det danske samfund har vi nogle helt klare procedurer for at afgøre om folk er skyldige eller ej og indtil de konkludrer andet, er folk uskyldige

Tja ja.

// Jesper

Niels Henrik Sodemann

@Jesper

at selv om KMD ikke skulle blive dømt til at betale noget som følge af den stævning som SKAT har præsenteret KMD for. Så vil hele polemikken koste KMD i form af dårlig presse m.m. Det er i det mindste sådan jeg læser det

Ja, men pointen er at det allerede har kostet KMD uanset om de bliver dømt eller ej, da kontrakten er hævet. De har sikkert også kostet indirekte på rigtig mange måder.
I overser to væsentlige pointer ifm. offentlige it-projekter under det nuværende paradigme:
- Man kan være ansvarlig / skyldig UDEN at blive dømt i retten
- Man kan være ”hvad der gik galt” UDEN at være ansvarlig / skyldig

Den samlede pointe er selvfølgelig at skyldig / ansvarlig / dømt kan være helt dekoblet fra ”hvad der gik galt”.

Michael Cederberg

Du får blandet en del begreber sammen, hvorfor dine slutninger bliver noget forkerte.

Jeg er ked af at jeg ikke var præcis nok. Som Jesper skrev, så var min pointe at KMD allerede er dømt i offentligheden for de sager selvom der ikke er faldet dom i nogen af dem. Hvorvidt kunden var berettiget til at hæve kontrakten ved vi heller ikke. Men deres omdømme har lidt skade.

I sagerne står KMD med en dårlig sag, fordi de har svært ved at skyde tilbage på opgavestilleren. Jeg har ingen viden om hvem der har skylden i KMDs sager, men skal vi ikke gætte på at det er begge parter. Der er ingen tvivl om at KMD i den nuværende situation godt kunne tænke sig en mere objektiv vurdering af sagen og at diverse købere er godt tilfreds med at KMD sidder med aben.

Hvorvidt nogen af dem skulle have interesse i generelt at eksponere egne eller andres fejl overfor en ITHK er jeg mere tvivlsom overfor. Også selvom en ITHK ikke dømmer eller vurderer skyld.

Niels Henrik Sodemann

Hvorvidt nogen af dem skulle have interesse i generelt at eksponere egne eller andres fejl overfor en ITHK er jeg mere tvivlsom overfor.

Der er ingen, der har sagt at det bliver nemt. Skyld / ansvar i de foreliggende kontrakter bliver meget binært foran en dommer og det gør jo selvfølgelig at fronterne bliver meget skarpe mellem parterne. Du har da helt sikkert ret i, at der ikke er mange der har den helt den store interesse i at bidrage.

Derfor skal der selvfølgelig være vidnepligt for ITHK.

Der hvor ITHK adskiller sig, er jo netop at ITHK ikke skal bruges til at udregne et enkelt beløb og således ikke behøver at komme til en binær konklusion.

”Hvad der gik galt” og som man kan uddrage læring af kan være mangfoldige og pege i mange retninger.

Log ind eller opret en konto for at skrive kommentarer