Budgetoverskridelser kommer sjældent som en overraskelse. De er et governance-valg.

Jeg har aldrig set en seriøs overskridelse komme som et lyn fra en klar himmel. Den kommer som rust. Langsomt. Stille. Og så på én gang opdager man, at tallet i praksis var låst fast for måneder siden.

Kritikken af Bornholm Energy Island, som beskrevet i ing.dk’s dækning af budgetproblemerne og debatten om ansvar, læser jeg som et mønster, jeg har set igen og igen i industrielle programmer: omkostningssandheden kommer sent, interfaces forbliver uklare, kontrakter underskrives under tidspres, og bagefter kan alle med god samvittighed sige: “Jeg var ikke informeret.”

Derfor mener jeg, at budgetoverskridelser sjældent er en overraskelse. De er et governance-valg. Ikke et ondt valg. Et strukturelt valg. I det øjeblik man accepterer “det afklarer vi senere” inde i scope, interfaces eller change control, vælger man en fremtid, hvor den finansielle sandhed kommer for sent til, at man kan nå at handle på den.

Da jeg som tidligere COO stod for driften i elektrificering og energilagring, var engineering-risici sjældent det første, der knækkede. Det første brud var, at leveranceafhængigheder fik lov at ligge mellem organisationer uden én tydelig ejer. Arbejdet fortsatte, men accountability for tid og omkostning gjorde ikke.

Overskridelsen er typisk kontraheret, før den bliver rapporteret

Ledere taler ofte om “visibility”, som om problemet er dashboards. Men mekanikken bag overskridelser er mere håndgribelig end det.

• Interfaces bliver defineret sent. Sen interface-definition tvinger redesign, rework og hastet indkøb. Den omkostning er reel, selv om den endnu ikke er bogført.
• Leverandørstrategier vælges af politik eller vane. Resultatet bliver enten en prime supplier, der reelt ikke er accountable, eller et modulært økosystem, hvor ingen ejer integrationen.
• Kontrakter bliver irreversible forpligtelser. Når milepæle, bod og long-lead items er sat i gang, kan man diskutere tal, men man kan ikke “af-underskrive” uden at betale for det.
• Ændringer bliver “absorberet”, indtil de ikke kan mere. Teams vil gerne være hjælpsomme. De holder tempo. De accepterer stille og roligt scope creep. Senere viser det sig som et stort tal og en “overraskelse”.

Derfor er sen opdagelse ikke en opdagelse. Det er en bekendtgørelse. Beslutningen er allerede taget – bare ikke eksplicit.

Kill-chain’en: fire governance-greb, der stopper dyr uklarhed

Her er den operator-lektion, jeg bliver ved med at vende tilbage til. Den er ikke sexet, men den virker. Hvis du vil have færre overskridelser i dette kvartal, så behandle det som en kill-chain – og bryd den tidligt.

1) Frys scope tidligt – men frys det rigtigt

“Frys scope” betyder ikke “ingen ændringer”. Det betyder, at du definerer, hvad der må flytte sig, og hvordan det flytter sig.

• Fastlæg baseline på systemniveau (hvilke outcomes der skal eksistere) og på interface-niveau (hvad der skal kobles til hvad – og under hvilke constraints).
• Prisfastsæt hver change request i det øjeblik den foreslås – ikke når den implementeres.
• Definér change authority: Hvem kan godkende ændringer under en tærskel, og hvem skal godkende over.

Da jeg som tidligere CEO drev en smart-building forretningsenhed med forbundne sensorer og bygningsstyring solgt på tværs af flere lande, kom scope drift sjældent af “dårlig product management”. Det kom af, at kommerciel hast mødte integrations-virkelighed. Salg ville have én variant mere. Service ville have én workaround mere. Engineering ville have én forbedring mere. Uden en stram change authority bliver enhver god intention til en uprissat forpligtelse.

2) Vælg en leverandørstrategi, der matcher den reelle integrationsrisiko

Der er i praksis kun to ærlige strategier i komplekse industrielle programmer. Alt andet er en hybrid, der forsøger at undgå accountability.

• Single throat to choke: én prime supplier er accountable for end-to-end leverancen, inkl. integration. Det koster. Til gengæld har du et sted at placere risikoen.
• Modulær multi-supplier: flere leverandører leverer moduler, men du tildeler eksplicit integrationsansvar og finansierer det som et førsteklasses workstream.

Modulært kan være hurtigere og mere konkurrencepræget. Det kan også være en fælde, hvis man lader som om integration er “project management overhead”. Integration er engineering plus drift plus kontraktuel design. Hvis du ikke betaler for det upfront, betaler du senere – med renter.

Hvis du vil have en dybere vinkel på leverandørdynamikker, har jeg skrevet The Fastest Way to Lose Quality Is to Treat Suppliers Like a Contract Problem. Den korte version: Kontrakter fordeler skyld, men operating mechanisms skaber resultater.

3) Tildel én ejer per interface – og gør ejerskabet målbart

De fleste store programmer fejler i samlingerne. Ikke i komponenterne.

Derfor kører jeg en enkel regel: ét interface, én ejer, én acceptance test. Ingen komitéer. Intet delt ejerskab. Hvis to personer “ejer” et interface, så ejer ingen det, når det begynder at gøre ondt.

• Ejer: en navngiven person, der er ansvarlig for definition, alignment og acceptance.
• Definition: en levende interface-spec, der inkluderer performance constraints, failure modes og operationelle ansvarsområder.
• Acceptance test: en evidensbaseret gate, der beviser, at interfacet fungerer under realistiske forhold.

Det gælder lige så meget i industriel elektrificering som i SaaS. Når jeg bygger produkter i mine egne ventures som Shopeno og IBHQ, dukker “interfaces” op som API-kontrakter, data-ejerskab og operationelle handoffs. Formen ændrer sig. Governance-princippet gør ikke.

4) Kør hårde stage gates, hvor funding følger evidens – ikke annonceringer

Stage gates er ikke bureaukrati. De er den eneste skalerbare måde, jeg kender, til at forhindre optimisme i at blive finanspolitik.

Jeg foretrækker gates, der er binære og evidensdrevne:

1. Gate 0: Scope og interfaces er baselined. Kan du ikke definere samlingerne, kan du ikke prissætte systemet.
2. Gate 1: Leverandørstrategi er valgt, og integrationsansvar er eksplicit. Prime eller modulær – men med reel ejer og budget til integration.
3. Gate 2: Kritiske risici har en finansieret mitigation plan. Ikke “vi kigger på det”. En plan med ejere og datoer.
4. Gate 3: Evidens findes. Tests gennemført, prototyper valideret eller operationelle simulationer afsluttet. Funding frigives på baggrund af bevis – ikke narrative.

Det er også her, “politiske timelines” gør skade. Når tidslinjer bliver ikke-forhandlingsbare, bytter organisationen stille og roligt sikkerhed for hast. Hvis du accepterer den handel, har du brug for hårdere gates – ikke blødere.

Den første reelle fejl er at slippe “det afklarer vi senere” ind i planen

Det lærte jeg tidligt i min karriere, i løbet af elleve år med power electronics og industriel automation. Systemerne var virkelige. De kørte i vand- og spildevandsanlæg, HVAC-miljøer og automationslinjer. Failure modes var konkrete.

Men de tidligste fejl så stadig ledelsesmæssige ud, ikke tekniske. En sen afklaring af requirements. En manglende beslutning om, hvem der ejer commissioning. En leverandør, der antog, at nogen andre validerede en edge case. Hver ting føltes lille. Tilsammen blev det til omkostning og tidsplan som realitet.

I programmer med både offentlige og private aktører bliver uklarhed endnu farligere, fordi accountability naturligt fragmenterer. Folk arbejder i god tro i deres del. Ingen ejer hele tallet.

Når tallet ejes af alle, ejes det af ingen.

Hvis du vil have en praktisk pendant til idéen i organisatoriske termer, så dækker CEO-led transformation, the operator way: five mechanisms that prevent silo theater de interne mekanikker, der forhindrer, at handoffs bliver til alibier.

En tjekliste, du kan bruge i dette kvartal

Hvis du kører et komplekst program lige nu, er her, hvad jeg ville gøre de næste 30 dage. Ingen reorg nødvendig.

• Publicér interface-registret. List hvert større interface (teknisk, kommercielt, operationelt). Sæt ét navn ud for hver. Kan du ikke navngive ejeren, har du fundet en kommende overskridelse.
• Baseline scope med regler for “allowed change”. Definér hvilke ændringstyper, der kan gennemføres uden eskalering, og hvad der skal til en formel change authority.
• Vælg leverandørstrategi eksplicit. Prime supplier med reel integrationsaccountability, eller modulær med et finansieret integrations-workstream. Lad være med at bilde dig ind, at du kan få begge fordele uden at betale for én af dem.
• Gør din næste stage gate til en evidens-gate. Vælg tre proof points, der skal være opfyldt før næste funding release. Tests, prototyper, commissioning-readiness eller valideret og prissat BOM. Evidens slår narrative.
• Installer en fast cost truth-kadence. Ét ugentligt forum, hvor current estimate at completion gennemgås med de ansvarlige ejere til stede. Ikke for at placere skyld. For at tvinge realitet tidligt.

Det her er governance som et operating system. Det handler ikke om at være streng. Det handler om at være eksplicit tidligt, så du ikke bliver “overrasket” senere.

Min vurdering: Forudsigelighed købes upfront

Folk siger ofte: “Vi skal være agile.” Fint. Men agilitet uden accountability er bare improvisation betalt af nogen andre.

Når jeg ser på store programmer som det, der omtales i kritikken af Bornholm Energy Island, ser jeg ikke en historie om én person, der fejler. Jeg ser en historie om governance, der tillader, at omkostningssandheden kommer efter den kontraktuelle sandhed.

Budgetoverskridelser kommer sjældent som en overraskelse. De opstår, når vi lader interfaces flyde, lader scope drive uden at prissætte det, og lader funding følge annonceringer i stedet for evidens. Løsningen er ikke mere rapportering. Løsningen er at vælge tidligt, hvem der ejer hvad, hvordan ændringer prissættes, og hvornår proof er et krav.