Mens vi venter på resultatet af den ‘endelige’ DSB-ekspertundersøgelse af IC4´s fremtid, kan vi starte på besvarelsen af det centrale spørgsmål: Hvorfor gik DSB’s IC4-projekt til 5 mia. kr. så galt? Der kan konstateres en forsinkelse på mindst otte år, en samlet budgetoverskridelse på ca. 5 mia. kr., uafsluttede indkørings- og driftsproblemer og tabt tillid til DSB og IC4 togene. Derfor leder vi efter de oprindelige årsager til det fejlslagne projekt.
Kontraktens fortrolighedsklausul betyder, at vi kildemæssigt er henvist til offentliggjorte erklæringer og undersøgelsesrapporter fra DSB og Trafikministeriet, samt pressens evt. andre kilder, men ikke til DSB’s og leverandøren AnsaldoBredas korrespondance og fremdriftrapporter. Derfor må vi basere os på de offentlige oplysninger og på erfaringerne fra andre store internationale tekniske projekter for at kunne fremkomme med hypoteser om årsagerne.
Den første af disse erfaringer er, at ca. 75 pct. af projekters risici, forsinkelser, fejl og budgetoverskridelser stammer fra projektets udviklingsfase fra start til kontrakt. Det gælder følgende årsager:
-
Fejlvurdering vedr. påtænkte teknologi og kompetencer, herunder evt. non-proven-technology, parternes tekniske erfaring og kvalitetskontrol fra tidligste designfase, fabrikation, testing og aflevering mv.
-
Fejlvurdering af projektets aktiviteter og tidsplan; herunder specielt kontraktlige terminer for godkendelser og aflevering.
-
Utilstrækkelige og for lavt niveau af personresourcer forudset til projektgennemførelsen (kvalitativt og kvantitativt).
-
Fejlbedømmelse af nødvendig projektledelse (kvalitativt og kvantitativt) for DSB og AnsaldoBreda.
-
Fejlbudgettering hos alle parter hver især.
-
Fejlvurdering af parternes ledelsesmæssige involvering hver især og samlet for projektet.
På det foreliggende grundlag er det svært at pege på en særlig overvægt af én eller få af disse årsagstyper; men det synes, som om de alle har gjort sig gældende med deraf følgende betydelige IC4 projektrisici.
Primært var AnsaldoBreda ikke en solid, erfaren og stærk dieseltogleverandør, som DSB tilsyneladende troede – tværtimod. Dernæst ser vi nærmere på den helt kritiske ‘IC4-togcomputer’ (styrings- og kontrolsystemet), der er den største usikkerhedfaktor for pålidelig IC4-togdrift. Dette systems udvikling og test har vi to gode kilder til belysning af.
En af IC4’s systemintegratorer, ingeniør Finn Jensen, svarer på spørgsmålet om, hvorfor der er så mange problemer med styrings- og kontrolsystemet, og hvad der det grundlæggende problem er: »En system-integrator som mig ville som noget helt naturligt anlægge en topdown synsvinkel på noget så komplekst som integrationen af de mange systemer i et IC4 tog.
De italienske konstruktører er begyndt stik modsat. De er begyndt fra bunden uden et klart og samlet billede af det samlede system og dets funktionalitet. De har stolet på, at de nok skulle få tingene til at spille sammen i sidste ende ved hjælp af software – justeringer«. Men det skulle vise sig at være en helt forkert bedømmelse.
Samtidig vurderede lektor Erik Frøkjær fra Datalogisk Institut, Københavns Universitet, at der fortsat vil opstå problemer med styringssystemet, hvis man ikke (grundlæggende) fik dem til at virke ordentligt, og at det kunne tage lang tid, når DSB havde valgt at basere sig på AnsaldoBredas eksisterende softwaresystemer.
- Formulating objectives and strategies for new system
- Information flow and functional analysis
- Cost-benefit analysis of system scope, integration and functions
- Design of IT & automation architecture and approval
- Outlining of system design requirements
- Basic system design and approval*
- Detailed system design & functional description
- Programming & training of systems engineers
- Testing with client before release
- Installation & training of operators
- ‘Cold/dry testing’ and corrections
- ‘Hot/wet testing’ and final corrections
- Acceptance Tests & As Built Documentation
- Operation & Service
Kilde: Finn Felding, Management of International Projects. Lejre 2014: Chapter 4 p.78
Notes: Contract signing during this activity; QA check at the end of each and every stage (or step)*
Denne skribent, der har betydelig projektledererfaring med udvikling, design, afprøvning, idriftsættelse og aflevering af tekniske anlæg med integrerede styrings- og kontrolsystemer, er helt enig med de to eksperter. Deres anvisninger førte ikke til nogen konsekvensbeslutning i DSB. Tværtimod fortsatte AnsaldoBreda og DSB med at overføre viden fra Italien til Danmark på basis af de eksisterende styringssystemer som følge af forliget mellem DSB og AnsaldoBreda i maj 2009. DSB accepterede at overtage togsæt uden test og færdiggøre dem i eget regi.
Det er derfor ret tvivlsomt, om AnsaldoBreda og DSB respekterede nedenstående helt almene, anerkendte og accepterede faseplan for automations delprojektet (se boksen til højre).
Også på det kontraktlige område er der grund til at betvivle DSB’s projekt-professionalisme. Det gælder kontraktens regler for leverandørens misligholdelse (uenighed mellem DSB og Advokatfirma), tæt styring af udviklings- og projekteringsgodkendelser og møder med underskrevne referater og endelig leverancer til DSB af tog, herunder test/idriftssættelse inden den den meget vigtige afleveringsforretning.
Disse betingelser for en stærk kontrakt og en effektiv kontraktadministration på projektlederplan synes ikke opfyldt. Som det sidste eksempel kan nævnes mistanken om den svage projektledelser hos både DSB og AnsaldoBreda, hvilket i sig selv er skæbnesvangert. Det er ikke en kritik af projektlederne, men af topledelserne hos de to parter.
Det var også de to topledelser, der trods alle IC4-, AnsaldoBreda og DSB-risiciene kastede sig ud i IC4-projektet på en ‘selvmorderisk måde’ med en alt for lav pris, en usikker og for kort tidsplan, et alt for lavt budget og AnsaldoBredas manglende erfaring med moderne hurtige dieseltog.
Leave a Reply