Business & Finance

The Difference Between Projects That Get Approved and Projects That Get Built, by Gord Reynolds

In infrastructure delivery, approval is often treated as a finish line. A project is sanctioned, funding is committed, schedules are announced, and teams are told to move forward with confidence.

According to Gord Reynolds, that confidence is frequently misplaced.

Approval creates permission. It does not create readiness.

Over and over, Reynolds has watched projects move from approval into execution carrying unresolved constraints that were visible long before construction began. The paperwork was complete. The business case was accepted. The optics were strong. But the conditions required for success were still missing.

And once momentum takes over, those gaps become far more expensive to address.

The false comfort of approval

Formal approval has a powerful psychological effect. It signals legitimacy. It quiets dissent. It creates a sense that risk has been managed, even when it has merely been documented.

Organizations often focus heavily on managing risk at the start of a project but pay little attention to the final outcomes. 

“Most organizations concentrate on front-end risk and are surprised when results fall short,” Reynolds says.

Approval reduces perceived uncertainty without reducing real uncertainty. It shifts the conversation from should we proceed to how fast can we move, even when the underlying system is not yet executable.

This is where many projects quietly go wrong.

Permission without authority

One of the most common failure patterns Reynolds sees is the mismatch between responsibility and authority. Projects are approved with ambitious timelines, but the people expected to deliver them lack the power to resolve the conflicts that will inevitably arise.

Utilities remain fragmented. Decision rights are vague. Trade-offs are escalated endlessly or avoided altogether. The schedule advances, but authority does not.

“A project manager without authority is just a punching bag with a calendar,” Reynolds says.

Approval assigns responsibility without granting control. When execution pressure mounts, teams are forced to improvise around constraints they were never empowered to remove. At that point, delays are framed as surprises rather than as the predictable outcome of decisions deferred earlier.

Readiness is not a document

Reynolds is careful to distinguish readiness from compliance. A project can satisfy every formal requirement and still be unready to execute.

Readiness shows up in simpler, harder-to-ignore ways. Utility information is complete, current, and trusted. Sequencing reflects real-world constraints rather than optimistic assumptions. Decision authority is explicit and enforceable. Trade-offs have owners, not committees.

These are not technical luxuries. They are the conditions that allow cause and effect to be understood and managed.

“This leads to that,” Reynolds says. “If you don’t understand cause and effect, you’re not managing a project. You’re reacting to it.”

Approval often masks this reality. It creates the impression that understanding exists because permission has been granted. But permission does not clarify dependencies. It does not resolve conflicts. And it does not substitute for judgment informed by shared, reliable information.

The danger of relying on individual understanding

In complex systems, personal confidence can be misleading. Leaders and project teams often assume they understand enough to proceed, even when that understanding is partial or siloed.

“If you’re relying on your own understanding in a complex system,” Reynolds warns, “you’ve already limited the outcome.”

Approval amplifies this risk. Once a project is sanctioned, questioning assumptions can feel disloyal or disruptive. Teams push forward based on what they think they know, rather than what the system can actually support.

The result is not bold execution. It is a reactive delivery.

Approval should raise the bar, not lower it

Reynolds argues that serious leaders treat approval as the beginning of accountability, not the end of scrutiny. Approval should trigger tougher questions, clearer authority, and earlier confrontation of trade-offs, not a rush to declare momentum.

The most damaging failures rarely come from unknown risks. They come from known issues that were documented, deferred, and then rediscovered under pressure.

Being effective requires resisting the urge to equate motion with progress. It requires staying focused on outcomes rather than optics, and on executability rather than enthusiasm.

Approval is necessary. It is never sufficient.

Until leaders close the gap between permission and readiness, many projects will continue to look successful on paper while quietly accumulating the conditions for failure.