Reboot without a control model remains expensive

03.07.2026

6 min read

Many digitalization programs proceed without clear capex and operating responsibility. Capex refers to one-time investment expenditures, while opex covers ongoing operating and licensing costs. CIOs and CDOs in the DACH region need a robust governance model before approving additional programs.

Key Takeaways

Ownership before the next euro. Without an overall accountable owner, follow-up contracts continue; in the case of Smart-eID, over €90 million was spent despite a “highly likely” risk of failure.
Separate capex and opex. Investment approval, operational handover and ongoing economic viability reviews keep benefits, service levels and residual risks in distinct accounts and roles.
A single accountable role. The CIO owns architecture and operations, the CDO owns the portfolio and benefits, and the business owns the proof of benefit; shared outcome accountability creates committees.
Gate and terminate. Four gates with hard stop criteria override automatic roll-forward; the supervisory board governs via capex caps, opex burden, high risks and benefit evidence.

Why programs without owners fail

A digitalization program without a designated overall accountable owner remains a loose collection of initiatives. Budget, timeline and promised benefits are scattered across multiple lines. No one is ultimately responsible for overall success. When the business claims the benefits, IT delivers the platform and the CDO maintains the narrative, the role that resolves conflicts and triggers cancellations is missing.

The German Federal Audit Office describes this pattern in its advisory report of July 2025 on administrative digitalization for the Bundestag’s budget committee. According to the report, the federal government exercised insufficient control. Digital strategies remained mere inventories without robust deficit analysis. Goals were often unmeasurable. Parallel developments produced “wild growth.” Funds flowed even though economic viability was unproven, risks were ignored or staff resources were lacking. The report cites the Smart-eID project as an example: as early as 2021, the Federal Ministry of the Interior rated the risk of failure as “highly likely.” Yet more than €90 million was spent. The initiative failed. For EfA solutions (once-for-all), the federal government allocated roughly €500 million to the Länder without prior checks on the economic viability of the intended solutions. Many solutions remained confined to a single state or municipality-or were never used at all.

In publicly traded companies, the same gap often appears as a portfolio lacking binding prioritization. The program remains visible, but accountability for results remains negotiable.

Failure rarely starts with technology. It begins when no one is willing to formally own the cancellation of an unproductive initiative. Follow-up contracts, license renewals and integration work continue even when business benefits can no longer be demonstrated. Therefore, the IT governance model must enforce ownership before budget approval and not allow it to be retrofitted later.

Separating Capex, Opex, and operational risk

Teams often treat Capex approval as a one-off investment decision. Once the project goes live, the initiative status disappears while Opex, license costs, and operational risk rise. Without separate accounts and distinct responsibilities, ongoing operations become the residual item of the investment decision.

A robust model separates three decision layers. First, investment approval with business case, architectural fit, and benefit hypothesis. Second, operational handover with service levels, capacity, and security requirements. Third, continuous economic viability checks that weigh Opex growth and risk positions against the originally promised benefits. The ISACA governance framework COBIT 2019 bundles this separation precisely: EDM02 governs benefit delivery, APO05 manages portfolio governance and prioritization, and the DSS domain oversees ongoing operations. ITIL 4 complements this with service level management and change enablement, where teams assess risks before approval and control changes in live services.

Operational risk must be part of the approval logic. Releasing new channels, data flows, or AI components means assuming failure, compliance, and dependency risks in live operations. When Capex and Opex are mixed in one line, the risk remains invisible until it surfaces in an incident or audit. Separation brings clarity: who invests, who operates, and who bears the residual risk.

Role matrix for CIO, CDO, and line-of-business

A steering model lives or dies by a role matrix that defines decision rights and escalation paths. The CIO is accountable for architectural integrity, operational readiness, and security and procurement standards. The CDO governs portfolio priorities, benefit logic, and alignment with business models. The line-of-business owns the functional requirements, benefit validation, and change management within processes.

The matrix must pre-empt conflicts. Who decides when roadmaps clash? Who halts a project if benefits fail to materialize? Who covers costs when the line-of-business expands scope while the platform must stay stable? Without these clarifications, parallel steering emerges: CDO programs alongside IT projects, line-of-business tools beside enterprise architecture. COBIT 2019 provides RACI matrices (Responsible, Accountable, Consulted, Informed) for each governance and management objective and organizational decision structures. ISACA is clear: RACI charts do not replace accountability; they clarify it. Multiple “Accountable” roles for the same outcome create a committee. Single-point accountability is what creates ownership.

Dual roles are possible; shared accountability for the same outcome is not. If CIO and CDO are one person, the separation of platform responsibility and portfolio governance still requires documentation. The line-of-business may set requirements, but it may not create shadow IT as a permanent state. The matrix only works when it is tied to budget and approval rights.

Gate logic for approvals and terminations

Governance of digitalization programs needs gates that both release and terminate. At least four gates are practical: concept and architecture approval, investment release, operational takeover, and periodic benefit and risk reviews. Each gate requires hard kill criteria, not just traffic-light colors.

Kill criteria must be set before the first euro is spent. Examples include missing benefit validation, failed operational takeover, unresolved security gaps without a remediation plan, or architectural drift from the target state. If terminations are only negotiated politically, ongoing expenses are protected and honest stop decisions are penalized. Robert G. Cooper’s Stage-Gate model has formalized this logic for decades: at every gate, gatekeepers evaluate predefined criteria and decide on Go, Kill, Hold, or Recycle. Gates are investment decisions that commit resources. Status meetings track progress; gates commit and release funds. Germany’s Federal Audit Office, in its 2025 report, recommends exactly the same structure for public digital funds: release only if projects contribute to digital policy goals, are economical, implement standards, and address risks.

Gate logic belongs in the portfolio, not in individual project methodologies. A project can run methodically sound yet be strategically redundant. That is why the steering committee needs the authority to terminate initiatives despite partial successes when Capex commitments, Opex trajectories, or operational risks outweigh the benefits. Approval without a kill option becomes an automatic continuation mechanism.

What the Supervisory Board Really Needs to See

The supervisory board doesn’t need feature lists or PowerPoint reboots. It needs a concise view of capex commitments, opex trends, critical operational risks, and the status of benefit verification for each program. This includes ownership, the next gate decision, and explicit options to halt or recalibrate initiatives.

Only what leads to actionable decisions is report-worthy. A status light without a decision template merely absolves management while blocking the supervisory board. A few key metrics with unambiguous interpretation are far more useful: invested and still committed capex, ongoing opex burden per program, open high-risk issues, and the share of initiatives with confirmed benefits. The German Corporate Governance Code (DCGK) sets the framework: Principle 4 requires an appropriate and effective internal control and risk management system. Recommendation A.5 demands that the annual report disclose the key features of these systems and include a statement on their appropriateness and effectiveness. Principle 6 obliges the supervisory board to be involved in decisions of fundamental importance and requires reserved approval rights. IT and digital risks fall under this oversight mandate as soon as they materially affect business operations.

Political program narratives are no substitute for corporate governance. Public digital initiatives may provide orientation, but they neither replace capex discipline nor operational accountability within your own organization. The supervisory board should ask about the control model, not the marketing of the next reboot. Transparency emerges when stop decisions are as reportable as go decisions.

Approving further digital programs without defining ownership, capex–opex separation, role matrix, and gate logic merely funds incrementalism instead of governance. The IT governance model is the prerequisite before the next reboot-long before the next cost overrun.

Frequently Asked Questions

How do you effectively link the role matrix to budget and approval rights?

The matrix only takes effect when the accountable role also controls the funds. Capex approvals and Opex accounts run through the designated owner; scope expansions by the department trigger new gate reviews. Parallel budgets outside the matrix create shadow governance and invalidate the documented RACI logic.

What distinguishes a real gate from a status meeting?

Status meetings track progress. Gates decide on resource allocation and terminate or continue initiatives based on predefined criteria. Gatekeepers choose Go, Kill, Hold, or Recycle; without an abort option, every approval becomes an automatic continuation. The logic belongs in the portfolio because methodically sound individual projects may be strategically redundant.

How can operational risk remain controllable after go-live?

After investment approval, operations take over with service levels, capacity, and security requirements. Subsequent periodic economic reviews assess Opex growth and risk positions against the promised benefits. New channels, data flows, or AI components introduce failure, compliance, and dependency risks into the approval logic, keeping the burden visible in separate accounts.

What decision brief does the supervisory board need instead of mere traffic-light charts?

Only what is actionable is reportable. Useful metrics include invested and still committed capex, ongoing opex burden per program, open high risks, and the share of initiatives with confirmed benefit realization. Every traffic light requires ownership, the next gate decision, and explicit abort or recalibration options. This ensures oversight of material digital risks.