Large-Scale Digital Projects: 5 Governance Mistakes That Lead to Fiascos
How can we explain the failures and astronomical cost overruns in Quebec's large-scale digital projects? It's a question that sparked much debate in recent years, as names like SAAQclic, Phénix, and Santé Québec have become synonymous with "derailment," "delays," "chaos," and "loss of control."
These ambitious projects, intended to simplify lives and modernize public services, have since become symbols of technological fiascos. But are these failures truly technological in nature? Several audits and investigative reports point instead in another direction: that of governance. Indeed, the problems associated with these systems often take root well before their deployment. The real issues lie in how organizations set their priorities, structure their projects, and make decisions. And this reality extends far beyond the public sector, as many private companies face the same issues.
Here are five governance mistakes that consistently crop up in digital projects gone wrong, and what can be done to avoid them.
1. Confusing the solution with the mission
Many organizations tend to launch a digital project by immediately focusing on technology: the system to implement, the software to choose, or the platform to adopt. In other words, they try to define the what before clarifying the why.
In his book How Big Things Get Done, researcher Bent Flyvbjerg cites architect Frank Gehry, who consistently begins his projects with a single, simple but fundamental question: "Why are you doing this project?" Without a clear answer to that question, the work cannot truly begin. Digital projects should follow the same logic.
Without a clearly defined mission, technology becomes an end in itself rather than a means to one. Clarifying the why before diving in is not a luxury, nor a waste of time: it is the essential prerequisite for a project that actually holds together.
Realigning projects to their purpose: the peanut butter & jelly sandwich example
Testifying before the Gallant Commission — a public inquiry into the SAAQclic fiasco — Waldo Jaquith, an American expert in digital governance, illustrated this dysfunction with a tasty analogy: that of the peanut butter & jelly sandwich.
When a child asks an adult to make them a peanut butter and jelly sandwich, they get one without having to explain every single step in detail. A government wanting the same sandwich, however, will tend to draft a 300-page request for proposals describing the viscosity of the peanut butter and the angle at which the bread should be cut, rather than simply stating what it needs. The service provider then follows the instructions to the letter... and ultimately delivers peanut butter spread directly onto the bread bag. The contract is fulfilled, but the result is inedible.
This metaphor captures the heart of the problem. Piling up technical requirements before crystallizing the mission generates more bureaucracy, but not more clarity. As long as the why is not stable, everything else remains unstable.
2. Believing in a miracle software solution
Too many public and private organizations cling to the idea that a new software solution will fix all their structural flaws. They imagine they can turn the page simply by replacing an outdated system with a more modern one. The idea is undeniably appealing, but the reality is far more complex. Without a clear vision, a coherent architecture, and well-defined processes, new software risks simply reproducing the same dysfunctions in a different environment.
This is the myth of the Next Shiny Object: the belief that a new miracle tool can compensate for a lack of vision, internal coherence, or organizational maturity. It is a particularly insidious trap because it promises a fresh start, when in fact it only amplifies existing challenges.
Premature solutioning: answering before understanding the question
Public funding mechanisms often push organizations to define a technical solution before they have even clarified the problem. This tendency, known as premature solutioning, leads governments to invest millions in an answer whose relevance has never been validated.
It is not the tools that transform digital projects, but rather the human, cultural, and strategic decisions surrounding them. Thus, modern software implemented within a poorly aligned structure does not drive transformation. Instead, it creates more costly technological debt.
3. Treating your project as an exception
Many executives believe their project is unique by virtue of its complexity, constraints, or ambitions. This conviction often ends up complicating matters, as organizations push to build fully custom solutions, with tailored approaches, simultaneous innovations, and one-of-a-kind architectures. The result: cost overruns, missed deadlines, and a growing dependence on external partners.
This is what Bent Flyvbjerg calls the uniqueness bias: the tendency to perceive one’s own project as fundamentally different from all others, to the point of believing it defies the statistical laws that govern large-scale projects. This belief fuels the appeal of custom-made solutions and leads to the dismissal of historical data and lessons learned from comparable experiences. Rather than reinventing the wheel, it is far better to rely on proven solutions and align business processes with standardized practices.
The uniqueness bias: the SAAQclic example
The report by Judge Denis Gallant, produced following the public inquiry into the SAAQclic fiasco, is unequivocal: "Testing so many new concepts within a single large-scale project could only substantially increase its risk level."
By seeking to innovate at all costs and treating its project as an exception, the Société de l'assurance automobile du Québec (SAAQ) turned what was supposed to simplify motorists’ lives into a real financial sinkhole. In addition to causing massive service disruptions, the project ended up costing approximately $955 million, more than double the original budget.
4. Sidelining in-house experts
Another structural flaw in large-scale digital transformations is giving too little weight to internal experts. Commissioner Gallant explicitly highlights this in his investigative report: the Quebec government is overly dependent on external consultants at the technical level, and should urgently address the lack of cutting-edge government expertise in digital transformation.
Of course, external partners can bring methodology, experience, and fresh perspectives to digital transformation projects, but they will never replace the organizational memory held by long-time employees. These internal resources have an intimate knowledge of the systems, processes, and on-the-ground realities. Sidelining these long-tenured employees means giving up an essential ingredient for success.
The Santa Clara County case
After years of failure with consultants imposing standardized solutions, Santa Clara County entrusted the overhaul of its permitting process to its own employees. The result: a 33% reduction in processing time, achieved not through a new tool, but through a deep understanding of user journeys.
5. Measuring compliance rather than value
The success of large-scale digital transformation projects is typically measured using two key indicators: staying on budget and on schedule. While important, these criteria say nothing about the actual value created by a project.
The Phénix payroll system is likely the most striking example: even though it was deployed in line with official milestones, the project still had over a hundred known defects and triggered a national payroll crisis. The decision was made to optimize the timeline rather than quality, sacrificing the experience of both employees and citizens in the process.
Research published by MIT Sloan Management Review and analyses conducted by McKinsey & Company highlight the importance of evaluating digital transformations based on their actual adoption and operational impact. Metrics such as real adoption rates, reduced friction in operational workflows, improved user experience, and time to first value shift the conversation entirely: the question is no longer whether a project was delivered according to the original plan, but whether it is actually generating the expected strategic value.
The courage to say no
Sticking to an unrealistic timeline just to save face invariably leads to what experts call "project distress." Mature digital leadership is measured by the ability to say no: no to premature deployment, no to an unrealistic timeline, no to a solution that betrays the initial vision. Delaying a deliverable to protect the vision is not an admission of failure. It is often the most responsible management decision a leader can make.
Governance first and foremost
Large-scale digital projects often fail from the very start, when conceptual, human, and organizational foundations are neglected. The keys to success, however, are well established:
- Clarify the mission before choosing a solution
- Resist the appeal of miracle software
- Rely on proven practices rather than reinventing everything
- Mobilize internal expertise from the outset
- Measure real usage value rather than mere contractual compliance
- Develop the managerial courage to pivot, slow down, or say no when the signals call for it
Organizations that succeed in their digital transformations are not necessarily those that adopt the latest technologies. They are the ones that have developed the organizational maturity and governance needed to steer them.
In a world where digital projects are becoming increasingly foundational, that maturity is no longer a competitive advantage — it is a prerequisite for success.
Three questions leaders should ask before launching a digital project
- What organizational problem are we actually trying to solve?
- Are the internal teams who know our processes best involved from the start?
- How will we measure the real value created for users?
Organizations that take the time to answer these questions clearly significantly reduce the risk of drift in their digital projects.
