When $100 Million Technology Projects Fail, It’s the Board’s Fault—Every Single Time

2. January 2025
Kategorien
Subscribe to our newsletter

In Switzerland, rumors suggest that both Bank Julius Bär and Raiffeisen Schweiz are grappling with failed technology projects, each costing over $100 million so far. Bank Julius Bär is reportedly trying to replace its existing core banking system for the Swiss booking center with Temenos, while Raiffeisen Schweiz is attempting to build a modern e-banking app.  

Both organizations have allegedly hired third parties to review what went wrong and determine who’s to blame. While learning from failure and engaging external reviewers is sensible, the question of blame should already be crystal clear.  

When a multi-million-dollar technology project collapses under its own weight—costing shareholders, employees, and stakeholders dearly—there’s no escaping the brutal truth: the fault lies squarely with the board.  

You can explore my 20+ technology project failure case studies. Without exception, the boards involved failed to fulfill their responsibilities.  

The Board’s Job Is Oversight, Not Rubber-Stamping

Boards exist to govern. They approve strategy, allocate resources, and oversee risks. They are not passive observers—they are active stewards of an organization’s success. Yet in failed projects, it’s evident that many boards sleepwalk through their responsibilities. They fail to ask tough questions early, challenge overly optimistic assumptions, or ensure mechanisms are in place to detect and address problems before it’s too late.  

A board’s oversight role is not ceremonial. If a project spirals into disaster, the board either ignored the warning signs, delegated oversight to those ill-equipped for the job, or worse, never bothered to establish adequate checks in the first place.  

If a board lacks the expertise to fulfill its duties, it must seek external help. This could mean forming an advisory board with independent specialists or adding a temporary board member with the requisite expertise and experience. 

Failing Is Acceptable; Failing Late Is Not 

Failure is a natural part of innovation and growth. No board can eliminate risk entirely—nor should they try. But there’s a monumental difference between failing fast and failing late.  

Early failure allows a company to pivot, salvage resources, and preserve credibility. Late failure, on the other hand, is catastrophic. It burns cash, destroys morale, and erodes stakeholder trust.  

Boards must demand stage-gated project governance that clearly delineates when to proceed, pivot, or pull the plug. If a multi-million-dollar project reaches the point of no return before its inevitable demise, the board has failed in its primary responsibility—to safeguard the organization from reckless escalation.  

Why Boards Get It Wrong

So why do boards allow projects to go off the rails? Common reasons include:  

> Blind Faith in Leadership: Boards often rely too heavily on the CEO or project sponsor’s assurances. Trust is important, but blind faith is a recipe for disaster. A board’s role is to verify, not just trust.  

> Lack of Expertise: Some boards lack the technical or industry-specific knowledge to challenge assumptions. Instead of addressing this gap, they defer to management, undermining their oversight role.  

> Cognitive Biases: Boards are just as susceptible to biases as anyone else. The sunk cost fallacy, groupthink, and overconfidence often lead boards to double down on failing projects instead of cutting losses.  

> Weak Governance Processes: Many boards fail to establish robust governance frameworks for major projects. Without clear accountability, transparency, and regular checkpoints, projects are allowed to drift toward failure.  

The Path to Accountability  

To prevent future multi-million-dollar disasters, boards must:  

> Ask Hard Questions Early: Why are we doing this? What are the critical assumptions? What would make us stop? These questions must be asked before a single dollar is spent.  

> Insist on Independent Assurance: Boards should mandate independent audits and reviews for major projects. An objective view can often identify risks that insiders miss.  

> Monitor Progress Ruthlessly: Quarterly updates are not enough. Boards must demand real-time reporting on key metrics and intervene when milestones are missed.  

> Be Willing to Pull the Plug: The hardest decision for any board is to stop a failing project. But it’s also the most responsible one. Better to write off millions now than to lose billions later.  

In a Nutshell

When a multi-million-dollar project fails, the board cannot claim ignorance or absolve itself of responsibility. Failure at this scale is a governance failure, plain and simple. Boards that tolerate late-stage disasters are not just failing the organization—they’re failing every stakeholder who placed their trust in them.  

The lesson is simple: you can fail, but not that late. Boards must act as the last line of defense, ensuring that failure—when it happens—is swift, contained, and instructive. Anything less is negligence. 

That could also be of interest for you

8 Signs of troubled projects for project sponsors

19. April 2017

When you’re dealing with a troubled project, there are usually a number of red flags surrounding you. This article is written from the perspective of senior management (for instance the project sponsor, members of the Steering Committee, or the executive management). All of us have endured troubled projects that didn’t accomplish their intended business goals. Such watermelon projects,

Read more

Building Is the Easy Part…

6. March 2017

Agile Frameworks and books tell us how to build a product–that’s the easy part… What we are not told are equally important things like maintaining, operating, fixing and extending the built product. When your agile philosophies fail to cover these areas, it greatly reduces agile’s benefits. This is where DevOps comes into play. DevOps is the combination

Read more

Paying Technical Debt

15. January 2017

The metaphor of technical debt in code and design can be defined as follows: You start at an optimal level of code. In the next release, you are adding a new feature. This would take an effort E. This, of course, assuming that estimations are somewhere near reality. If the level of code was less

Read more

Outsourcing Technical Competence Is a Very Bad Idea

2. December 2016

Organizations do not lose control of large technology programs because they outsource work. They lose control because they outsource understanding. It usually starts with a familiar pattern. A company decides to implement a major system on a technology it does not truly understand. ERP, CRM, HCM, core banking, it does not matter. The internal capability

Read more

Estimating with Wideband Delphi and Monte Carlo Simulation

18. October 2015

During the LeSS training in Berlin last week with Craig Larman he mentioned the best estimating method he knows for any big software project. Wideband Delphi with Monte Carlo Simulation. I agree with him on this one hundred percent. This article will explain what Wideband Delphi and Monte Carlo Simulation is (Part 1 & 2),

Read more
Previous