It-Branchen: Havarikommission spild af tid og penge
Mens politikere er begyndt at tale om behovet for en it-havarikommission, som kan undersøge, hvorfor offentlige it-projekter kuldsejler, mener brancheforeningen It-Branchen, det vil være en direkte dårlig idé med sådan en kommission.
»Vi mener, det er spild at tid og penge, fordi vi allerede har lavet de samme analyser tidligere,« siger formand for IT-Branchens Udvalg for Digital Forvaltning Michael Holk Wätjen og fortæller, at udvalget har holdt møde om netop en it-havarikommission.
Han mener, der har været masser af analyser og rapporter på baggrund af fejlslagne projekter. Og at en it-havarikommission derfor blot vil være mere af det samme. I stedet efterlyser Michael Holk Wätjen handling:
»Det, der mangler, er handling og erkendelse hos både kunder, rådgivere og leverandører i forhold til, hvad der så skal gøres, når vi nu ved, hvorfor det går galt.«
Vi ved det allerede
Men ved vi virkelig, hvad der går galt i forhold til fejlslagen offentlig it? Ja, lyder svaret fra Michael Holk Wätjen, der fremhæver den såkaldte Bonnerup-rapport, opkaldt efter formanden for det udvalg, der udarbejdede rapporten, Erik Bonnerup.
Rapporten så dagens lys i 2001 og indeholdt en række anbefalinger til at skære i forsinkelserne og skrumpe budgetoverskridelserne ved offentlige it-projekter. Rapporten anbefaler blandt andet at bryde store it-projekter ned i mindre bidder, som hver især kan udvikles i forløb af for eksempel tre eller seks måneder.
»En af de årsager, der har været fremhævet, er, at projekterne ikke bliver brudt ordentligt ned. Der er stadig tale om megaprojekter af mange års varighed, som koster mange millioner kroner og involverer rigtig mange mennesker,« siger Michael Holk Wätjen og fortsætter:
»Hvis man i stedet delte dem op i nogle mindre projekter, som gradvist blev taget i drift og testet, så får man også hurtigt klarhed over, om det overordnede projekt har den rigtige fremdrift, eller om man arbejder i den forkerte retning.«
Overvej standardsystemer
Ud over at omsætte ordene om at bryde projekter ned i mindre bidder til handling, så bør offentlige myndigheder også stille skarpt på, om nogle af de standardsystemer, der allerede findes inden for eksempelvis økonomistyring, ikke kan bruges i stedet for at få skræddersyet it, mener Michael Holk Wätjen.
»Hvis der er et standardsystem i forvejen, og kunden i virkeligheden gerne vil have et standardsystem, så skal man lade være med samtidig at specificere en hel masse unikke krav, så der efterfølgende skal bruges en masse tid på at tilpasse standardsystemet. Man skal som kunde erkende, om man kan nøjes med et standardsystem, der eventuelt skal tilpasses, eller om man vil købe et helt udviklingsprojekt, fordi man har nogle unikke behov.«
Derudover fremhæver Michael Holk Wätjen Statens IT-projektråd, som allerede følger store offentlige it-projekter. Her skal statslige myndigheder med et budget på over ti millioner kroner fremlægge deres business case, hvorefter de får løbende feedback på projektet.
»Når man så har fået kontrakten, bliver det fulgt op af en halvårlig indrapportering og mere feedback. Der går man proaktivt ind og ser på, hvad de potentielle risici kan være, og hvad man kan gøre for at undgå, at myndigheden gentager fejl fra andre projekter,« siger han.
Og Michael Holk Wätjen efterlyser en udvidelse af det arbejde:
»Lad os udvide det arbejde til at omfatte flere projekter, også i regionerne og i kommunerne, så det ikke kun er i staten, man evaluerer projekterne. Den form for professionel sparring og hjælp til den enkelte region eller kommune ser vi langt større værdi i, end at man først ser på, hvad der gik galt, når det er gået galt.«
Mens Michael Holk Wätjen beskriver projektrådets rolle under Statens IT som proaktiv, så sammenligner han en eventuel it-havarikommissions rolle med at se i bakspejlet.
»Så kan man sidde og vente x antal år på, at havarikommissionen får kigget på nogle projekter og når frem til noget, som vi allerede ved i dag, og som der ikke bliver ageret nok på.«
Læs også Poul-Henning Kamps blogindlæg om It-Branchens holdning til en evt. it-haverikommission
- emailE-mail
- linkKopier link

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sponseret indhold
V2 Briefing | GENERATIV AI: Sådan bruger du det professionelt
Kunstig Intelligens22. marts
- Sortér efter chevron_right
- Trådet debat
Da jeg startede i hulkortbranchen, datidens IT, i 1955, blev jeg som noget af det første belært om, at man aldrig fra den ene dag til den anden skal igangsætte et nyt stort system. Det skal udvikles gradvis og afprøves i etaper, helst som pilotprojekter. Denne halvtreds år gamle erfaring er ikke forældet Med venlig hilsen til de unge løver. Især til Poul-Henning Kamp
Efter min vurdering så var deres valg af OS/2 ikke blandt de støre problemer for det projekt. Du kan trods alt stadig køre OS/2 programmer i dag og få support til den platform.
Det at styresystem var nævnt i analysen som var en del af det udbud, var til gengæld et problem. De havde jo planer om at købe nye maskiner til projektet.
Hvor det dog irriterer at IT-Branchen kalder sig IT-branchen. Det er svært at læse ud af en tekst om det er IT Branchen eller IT Brancen der mener noget.
Men et meget godt bud på hvad "IT Branchen" som organisation er for en størrelse: en forening der engang kaldte sig for "IT brancheforeningen" men nu har påberåbt sig at være selveste branchen - mage til arrogance !
Det ville svare til at "Dansk Folkeparti" tog navneforandring til "Danskerne".
Derfor vil foreningen "IT Branchen" også slå sig i tøjret, når der er tegn til at der vil komme en uvildig instans og påpege hvad der er gået galt i projektkatastrofer som de selv har mange medlemmer der er en del af.
Det i sig selv er en indikation af at der er behov for en ITHK.
Ud af den tankerække fristes man til at ønske, at de ansatte i en IT Havari kommision ikke må have cand.jur. eller cand.oecon. stående på deres CV.....men derimod som minimum være IT fagligt uddannede og samtidigt kunne opfylde et krav om at have frembragt mindst een kørende applikation der i dag benyttes af mere end 1.000 brugere - for at det er sikkert at det er folk med forstand på kørende og nyttig IT der skal vurdere hvad der i givet fald er gået galt i projekterne.
Det er vel også piloter og ingeniører der vurderer piloter og maskineriet i en fly havarikommision og ikke organisatorer... eller ?
Beskylder mobilnettet.
Der er meget litteratur om hvorfor "andre" fejler. Desværre tror jeg at mange er ligeglade med udenlandsk litteratur, fordi de ikke er it folk, fordi de er vandt til at skulle overholde mange krav fra diverse love og bekendtgørelser, fordi de mener at Danmark er anderledes på en eller anden måde, fordi de ikke har sat sig ind i udviklingen af andres fagsystemer, og fordi dette tit er det første udviklingsprojekt de er med til at bestille.
Kunden er ikke en it afdeling, men projektchefer for en faggruppe. Derfor mener jeg at vi skal have en havarikommition til at anvende den udenlandske erfaring på danske projekter. Beslutningsprocessor er nemlig ikke ens i forskelling lande hvor der er forskellige institutioner. Havde de været det ville de sikkert også kunne bruge samme system i flere lande.
Du behøver så sandelig ikke at lede udenlands for at finde rapporter om hvorfor it-projekter fejler! Her blot et par stykker i samlingen fra det offentlige Danmark...
"Professionalisering af arbejdet med it-projekter i staten" (Finansministeriet, 2010) Citat fra rapporten: "Men der er fortsat betydelige udfordringer med at gennemføre it-projekterne. Vejledningerne, rapporterne og de lokale tiltag har altså ikke haft den ønskede effekt. Det hænger blandt andet sammen med, at den hidtidige indsats har været baseret på en antagelse om, at styrelserne har tilstrækkelig høj projektmodenhed til at efterleve anbefalingerne."
"Modenhed i it-baserede forretningsprojekter" (ITST, 2007)
"Beretning til Statsrevisorerne om styring af statslige digitaliseringsprojekter" (Rigsrevisionen, 2008)
"Beretning til Statsrevisorerne om det digitale tinglysningsprojekt" (Rigsrevisionen, 2010)
"Rigsrevisionen - Beretning til Statsrevisorerne om effekten af 7 statslige it-systemer" (Rigsrevisionen, 2002)
"Anbefalinger til bedre styring af offentlig it" (Teknologirådet, 2010)
Der er masser af litteratur derude der meget hen ad vejen er fuldstændigt enige om hvorfor offentlige it-projekter fejler:
- Manglende ledelsesprocesser og styringsprincipper
- Mangel på projekt-, program- og it-porteføljestyringsværktøjer og processer
- Lav projektmodenhed hos de statslige myndigheder
- Dårligt beslutningsgrundlag for investeringen, herunder:
- Manglende risiko-, gevinst og omkostningsvurdering
- Manglende planlægning generelt i forhold til it-projektet
- Mangel på klart definerede mål ved it-projekterne
- Manglende fokus på at skabe værdi for forretningen gennem it
- Gennemførelse af meget risikobetonede it-projekter
- Dårlig styring gennem projektforløbet, herunder:
- Problematisk og manglende resource- og risikostyring
- Overskridelser af både tid og budget
- Problemer i samarbejde med leverandører og konsulenter
Der sparrede jeg lige skatteyderne for en Havarikommission :) Det er bare at læse de eksisterende rapporter...
Jeg skimmede to rapporter:
"Beretning til statsrevisorerne om effekten af 7 statslige IT-systemer"http://www.rigsrevisionen.dk/media/1868608/4-02.pdfUnderskrevet af Henrik Otbo og Peder Juhl Madsen og så vidt jeg kan finde ud af er de cand.polit. og kontorchef.
"Bedre styring af offentlig it"http://www.tekno.dk/pdf/projekter/p10_offit/p10_offit_Bedre_styring_af_offentlig_it.pdfArbejdsgruppen: Master of public management, Enterprice Architechture fra ITU, Produktionsingeniør, Master of Business Administration, Dr. merc, systemarkitekt, CTO, Solution Architect.
Umiddelbart slår det mig hvor utekniske de er. Her er ikke noget med "ORM'en kaldes uhensigtsmæssigt med for mange SQL-kald til følge" eller "Systemet blev implementeret på den forældede OS/2-platform".
Enig i at der "mangler" den tekniske side af problemstillingerne ved offentlige it-projekter. De rapporter jeg har henvist til har primært et it-styringsmæssigt udgangspunkt (styring af it-projekterne). Hvor meget litteratur der findes derude om de tekniske problemstillinger skal jeg ikke kunne sige, men hvis man bare foretager en søgning på fx. Version2 kan man nok også finde et mønster i de tekniske problemstillinger ved offentlige it-projekter. Mit bud i den sammenhæng er en blanding af issues med løsningsarkitekturen og et manglende kendskab til forretningens behov sammenlagt med valget af teknologi.
I øvrigt fortæller folks titel eller uddannelsesbaggrund ikke nødvendigvis noget om deres erfaringsniveau ud i it, så "bare" fordi de er enten cand.polit eller Kontorchef diskvalificerer det dem ikke nødvendigvis fra at have stor indsigt i offentlige it-projekter. Folk der arbejder med it i dag er umiddelbart en "broget" skare :)
Og det er jo lige præcis det der skal være ITHKs formål, nemlig at dykke ned i hvad der gik galt rent teknisk.Enig i at der "mangler" den tekniske side af problemstillingerne ved offentlige it-projekter.
På samme måde som Havarikommissionen for Civil Luftfart og Jernbane kun beskæftiger sig med at finde ud af hvorfor en given komponent svigtede, ikke med hvordan Boing ellers skal tilrettelægge deres arbejdsprocesser.
Og det er jo lige præcis det der skal være ITHKs formål, nemlig at dykke ned i hvad der gik galt rent teknisk.
Jeg tillader mig lige at bryde ind med et link:
Der er meget litteratur om hvorfor "andre" fejler. Desværre tror jeg at mange er ligeglade med udenlandsk litteratur, fordi de ikke er it folk, fordi de er vandt til at skulle overholde mange krav fra diverse love og bekendtgørelser, fordi de mener at Danmark er anderledes på en eller anden måde, fordi de ikke har sat sig ind i udviklingen af andres fagsystemer, og fordi dette tit er det første udviklingsprojekt de er med til at bestille.
Kunden er ikke en it afdeling, men projektchefer for en faggruppe. Derfor mener jeg at vi skal have en havarikommition til at anvende den udenlandske erfaring på danske projekter. Beslutningsprocessor er nemlig ikke ens i forskelling lande hvor der er forskellige institutioner. Havde de været det ville de sikkert også kunne bruge samme system i flere lande.
Der er meget litteratur om hvorfor "andre" fejler. Desværre tror jeg at mange er ligeglade med udenlandsk litteratur, fordi de ikke er it folk, fordi de er vandt til at skulle overholde mange krav fra diverse love og bekendtgørelser, fordi de mener at Danmark er anderledes på en eller anden måde, fordi de ikke har sat sig ind i udviklingen af andres fagsystemer, og fordi dette tit er det første udviklingsprojekt de er med til at bestille.
Kunden er ikke en it afdeling, men projektchefer for en faggruppe. Derfor mener jeg at vi skal have en havarikommition til at anvende den udenlandske erfaring på danske projekter. Beslutningsprocessor er nemlig ikke ens i forskelling lande hvor der er forskellige institutioner. Havde de været det ville de sikkert også kunne bruge samme system i flere lande.
Det er jo netop formålet med en havari kommissions at følge op på årsagerne til kuldsejlede projekter. Altså ikke bare at lave rapporterne men også at følge op på resultatet således at industrien kan lære af sine fejl.
Jeg ville mene at en "Havarikommission" ville være bedst tjent med at være placeret i regi af IT-Projektrådet. Er meget enig med Tommy Sadiq Hinrichsen. Synes dog det er en meget vigtig diskussion der er blevet rejst her. Synes også diskussionen bør være langt bredere end "kun" at fokusere på hvorfor projekter har fejlet. Det er en ensidig negativ erfaringsopsamling. Det er også vigtigt at opsamle de positive erfaringer med projekter der er gået godt.
Man kan undres generelt over hvorfor der ikke sker en større erfaringsopsamling end det er tilfældet. Et bud kunne være, at styrelser, ministerier, regioner og kommuner i Danmark er så autonome enheder, at de i virkeligheden ender med at modarbejde hinanden og de fælles interesser i stedet for at "række hånden over muren" og dele viden om mangt og meget. Det fordrer ikke erfaringsudveksling på tværs af myndigheder eller standardisering.
Der er sket meget i Danmark de sidste par år, men der er stadig lang vej. Med standardisering kan man komme endnu længere, men man må desværre erkende, at det skal komme fra centralt hold. Der er kommet fælles it-projektmodel, fælles business case model, fælles programmodel, it-projektråd og generelt et større fokus på styring af it-projekterne.
Myndighederne har også umiddelbart fået mere øjnene op for standardsystemer, hvilket er fantastisk positivt, hvis man så også er vidende om de begrænsninger de enkelte standardsystemer har (ligesom med alt muligt andet it). Agile metoder vinder også umiddelbart frem i selve udviklingsfaserne.
I stedet for at fokusere på programledelse og store it-projekter, burde man nok hellere netop følge en del af Bonnerup-rapporten og i stedet lave en standardisering af it-projektporteføljestyring i myndighederne: Mindre (agile) projekter (mindre iterationer), ingen store programmer og hurtigere Return on Investment. Det vil være til at føle på.
Problemet er at IT-branchens medlemmer har en klar interesse i at få projekterne til at kører af sporet, fordi penge-strømmen stopper så snart alt virker.
Jeg kan godt lide at manden understreger Bonnerup rapporten påpeger at projekter skal nedbrydes til varigheder af 3-6 måneder, og så senere siger følgende omkring IT-projektrådet.
"»Når man så har fået kontrakten, bliver det fulgt op af en halv-årlig indrapportering og mere feedback."
Så kommer feedbacken sgu kun efter projektet er afsluttet.
Jeg mener personligt at IT-projektrådet skal have flere muskler og hjælpe meget mere til ift. projektstyring og løbende kvalitetskontrol af koden.
I Bonnerup-rapporten fra 2001 står der at IT-projekter skal(/bør) brydes ned i mindre projekter.
Da man starter POLSAG i 2007, gør man netop ikke dette.
Hvad gik galt? Havde de ikke læst Bonnerup-rapporten? Hvad er det der skal til for at POLSAG ikke gentager sig? Uanset hvailke tiltag man gør, opdatere Bonnerup-rapporten, opretter en havari-kommision, så skal målet være at vi undgår en ny POLSAG.
Hej, Det kan vel næppe være udivelsesdagen for rapporten, der er et kriterium for om dens anbefalinger er gode eller dårlige. For mig virker det ikke utænkeligt at de samme fejl som blev begået den gang fortsat bliver begået.
Mvh, Martin
Jeg tillod mig at skrive mit svar til IT-Branchen i min egen blog:
http://www.version2.dk/blog/ithk-sker-der-noget-56275
Bottom line:
At "IT-Branchen" får mindre omsætning kan jeg ikke alene leve med, jeg vil næsten påstå at det følger direkte af success kriteriet for ITHK:
Bedre og billigere offentlig IT.
Jeg giver ret i at Bonnerup rapporten bør opdateres. Faktisk bør den opdateres med både positiv og negativ erfaring fra krisehåndtering på større projekter. I det hele taget skal der være mere synlighed med offentlig it. Det er jo os der betaler.
Til gengæld så vil jeg give Jakob Møllerhøj ret i at der er mange erfaringer i Bonnerup rapporten som ikke bliver brugt godt nok endnu. Og der kan man stadig forbedre, både med og uden havarikommision.
Til gæld vil en havarikommision være et godt sted at få opdateret Bonnerup rapporten. I 2001 var der jo ikke så mange webbaserede special systemer som i dag. Og der er derfor en verden til forskel.
Til gengæld så vil jeg give Jakob Møllerhøj ret i at der er mange erfaringer i Bonnerup rapporten som ikke bliver brugt godt nok endnu. Og der kan man stadig forbedre, både med og uden havarikommision.
Jo tak, selvom det lige i dette tilfælde nok ville være mere på sin plads at udtrykke enighed med Michael Holk Wätjen fra It-Branchen, der er afsender på ovenstående synspunkter.
Poul-Henning, jag misstänker att en haverikommission är att föredra före spåmän ; )
Hvis manden seriøst tror vi kan bruge en rapport fra 2001 til at fortælle os hvad der blev gjort galt i alle fremtidige IT systemer, så burde han have et helt andet job.
Spåmand f.eks.
Hvis manden seriøst tror vi kan bruge en rapport fra 2001 til at fortælle os hvad der blev gjort galt i alle fremtidige IT systemer, så burde han have et helt andet job.</p>
<p>Spåmand f.eks.
Hej Poul-Henning
Der findes andre rapporter - og erfaringer:
2012, What is the Real Cause of Failed IT Projects?:http://blog.enfocussolutions.com/Powering_Requirements_Success/bid/142165/What-is-the-Real-Cause-of-Failed-IT-ProjectsCitat: "... One would think that the failure rate would have dropped significantly over the last 20 years...However, the failure rate has not dropped significantly ... According to the CHAOS Report, the top five causes for challenged projects are:
Lack of User Input
Incomplete Requirements and Specifications
Changing Requirements and Specifications
Lack of Executive Support
Technical Incompetence
. The top five causes for failed projects are:
Incomplete Requirements
Lack of User Involvement
Lack of Resources
Unrealistic Expectations
Lack of Executive Support
..."
September 18, 2013, Why big IT projects crash:http://www.ft.com/cms/s/2/794bbb56-1f8e-11e3-8861-00144feab7de.htmlCitat: "... Although much criticism has been directed at civil servants, IT overruns are present in both the private and public sector. “The private sector is just much better at hiding these things,” says Mr Budzier. ... The problems do not end with poor forecasting. Organisations are often very ambitious in what they set out to achieve – designing long projects that require customised software. That is likely to be another mistake. ... In recent years companies have laid the blame for IT failures at the door of their contractors. The IT industry has sought to borrow methods from the construction industry, where suppliers incur penalties for late delivery. However, IT has special challenges. ..."
October 9, 2008, IT's biggest project failures -- and what we can learn from them. Think your project's off track and over budget? Learn a lesson or two from the tech sector's most infamous project flameouts.http://www.computerworld.com/s/article/9116470/IT_s_biggest_project_failures_and_what_we_can_learn_from_themCitat: "... "IT projects have terrible track records. I just don't get why people don't learn," says Mark Kozak-Holland, author of Titanic Lessons for IT Projects (that's Titanic as in the ship, by the way). ..."
2013, Why Are So Many IT Projects Failing? A recent study reports that 50 percent of companies had an IT project fail in the last 12 months. Business leaders who blame IT are missing the real project management issues.http://www.cio.com/article/744168/Why_Are_So_Many_IT_Projects_Failing_ Citat: "... IT Is Not the Problem ..."
Dilbert - Why projects fail:http://www.youtube.com/watch?v=52yjQEEdnso
Det er ikke kun danske projekter der fejler:
List of failed and overbudget custom software projects:https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projectsCitat: "... 2008 - 2013 ... Digital Media Initiative ... more than £98m (£81.7m) ... Outsourced, then insourced, then outsourced again ... Cancelled ..."
Costs of failed NHS IT project continue to rise - YouTube:http://www.youtube.com/watch?v=KIEyxi3whKM
Abandoned NHS IT system has cost £10bn so far Bill for abortive plan, described as 'the biggest IT failure ever seen', was originally estimated to be £6.4bn:http://www.theguardian.com/society/2013/sep/18/nhs-records-system-10bnCitat: "... Successive ministers and civil servants have been blamed by committee members for the NHS project, which has been described as the biggest IT failure ever seen. Bacon, who has co-written a book on failing government projects, said that the NHS's particular problems stem from the original contracts signed before 2002. ..."
31 May 2012, IT assurance company loses £7m on failed IT project. NCC Group, a UK company that provides IT security, risk and testing services, has lost £7 million after a company-wide IT implementation failed:http://www.information-age.com/it-management/finance-and-project-management/2106268/it-assurance-company-loses-%C2%A37m-on-failed-it-projectCitat: "... "This is a very frustrating position to be in," said CEO Rob Cotton in a statement. "We have invested considerable amounts of time and resource into the new system but have had to take the hard decision to revert to our old system as the new simply wasn't measuring up to our needs." ..."
2013, MI5 abandons multi-million pound IT project MI5 has abandoned a multi-million pound IT project, it is believed, becoming the latest government organisation to fall casualty to such failed schemes:http://www.telegraph.co.uk/technology/10053240/MI5-abandons-multi-million-pound-IT-project.htmlCitat: "... But it is understood that earlier this year that the MI5 had decided to admit failure and re-start with a new generation of IT specialists. ..."
10 Failed Google Projects:http://computer.howstuffworks.com/10-failed-google-projects.htmCitat: "... Google Lively is one of the most interesting examples of "right idea, wrong implementation" precisely because nobody has ever heard of it (it lasted for six months in 2008) [source: Schonfeld]. ..."
Hej Poul-Henning</p>
<p>Der findes andre rapporter - og erfaringer:
Ja, masser.
Men der er ikke noget af det du kan få nogen i den offentlige IT-projekt-mølle til at forholde sig til.
Tanken bakom en haverikommission är väl att ge spåmännen bättre arbetsvillkor ???!!!
...at dem som skal undersøges og som pt. stort set er ansvarsfri, ikke vil have en Havarikommission som potentielt vil entydigt pålægge dem ansvaret for problemerne.
...og jeg kan godt forstå deres bekymring for at det forholder sig således, hvis dem, der bestiller Havarikommisionen og udstykker rammerne for dens arbejde, er de samme som dem der har bestilt og styret det fejlslagne IT-projekt....at dem som skal undersøges og som pt. stort set er ansvarsfri, ikke vil have en Havarikommission som potentielt vil entydigt pålægge dem ansvaret for problemerne.
hvis dem, der bestiller Havarikommisionen og udstykker rammerne for dens arbejde, er de samme som dem der har bestilt og styret det fejlslagne IT-projekt.
Meningen med den Havarikommission var da forhåbentlig ikke bare at pege på fejl hos leverandøren, men også at undersøge sagen helt op til de embedsmænd og politikere, der har besluttet noget (skal vi være flinke) "naivt".
Det kan jeg for så vidt også men det ville rent faktisk medføre at IT-virksomheder ville være meget mere kritiske omkring hvilke projekter man tog....og jeg kan godt forstå deres bekymring for at det forholder sig således, hvis dem, der bestiller Havarikommisionen og udstykker rammerne for dens arbejde, er de samme som dem der har bestilt og styret det fejlslagne IT-projekt.