We Know How to Build Better Infrastructure. So Why Don’t We?
The real barriers to delivery aren’t technical they’re cultural, institutional, and human.
I ended my last piece with an important question:
Can we build fast, fairly, and democratically?
As rhetorical (and “only choose two”) as it might sound, the reality is it doesn’t have to be a compromise. We have decades of hard-earned experience showing us what we have been doing wrong, and what can be done to fix those shortcomings.
Let’s explore a few concrete and meaningful ways we can actually build better.
Procurement: Invisible, but key.
If you hear about procurement, chances are something went terribly wrong: underscoped, over-budget, delayed, or quietly de-scoped into irrelevance.
And yet, we do not talk about it enough: we only do so when it fails us, or becomes headlines. Except, procurement isn’t just a bureaucratic step: it’s the foundation for everything we build, physical, digital or metaphorical.
And it matters a lot: it is the first real battle between ideals, constraints and established structures. Somehow, we expect procurement to find a way to balance all those, and still match the expectations set by policy makers, community consultations, and press conferences.
Most of the time, that tension isn’t resolved, it’s buried quietly. In boilerplate clauses, outdated risk models, and rigid templates that punish flexibility or “out of the box” thinking.
Failures in infrastructure delivery aren’t due to malice, incompetence, or apathy. They stem from early decisions made in silo, before anyone realizes the structure itself is flawed. Ironically, the ways to fix procurement are generally the simplest.
Build scope with delivery teams, not just for policy.
Too often, we set project scopes in isolation. They're shaped by ambition, politics, or planning models before anyone checks in with the people who might actually build them. That’s how we end up with requirements that look good on paper, but fall apart under real conditions.
If we want projects to be deliverable, we need to bring people from a variety of fields into the room, and early. That can mean your own internal teams, industry partners, or even people who have done similar projects before. The important thing is you need someone who understands what it takes to actually get it done right.
We saw a glimpse of this in the HFR project, when the government opened a Request for Expressions of Interest before finalizing scope. It was a way to ask, quietly: “How can this be done, and who might be able to do it?” That kind of early input should be the norm, not the exception. Even Metrolinx is doing it.
Scope isn’t just a document: it’s the framework for decisions that will shape everything that follows, budgets, timelines, trade-offs, and public trust. If it’s built in a silo, the delivery will be too.
Design contracts for desired outcomes, not to shift blame.
We’ve normalized contracts that treat infrastructure delivery like a risk negotiation: whoever agrees to carry the most uncertainty for the lowest price wins. Delivery shouldn’t work like that.
Taking on risk isn’t the same as having the capacity to manage it. When contracts isolate responsibility, they discourage openness, punish transparency, and make failure harder to see until it’s too late.
If delivery is the goal, contracts need to reflect that delivery is a team effort. Institutions often rely on external partners for the perspective and expertise they don’t have internally, so why design contracts that frame those partners as expendable or adversarial? If we build a scope that is realistic, every party should feel ownership over it. The plan should belong to all the groups delivering it, not just the one who wrote the cheque.
That means structuring work so people can solve problems together, not just survive them alone. It is also why many jurisdictions are shifting toward more collaborative models, like Progressive Design-Build, Alliance Contracting, or Integrated Project Delivery. These structures aren’t silver bullets alone, but they create space for shared ownership, faster feedback loops, and fewer incentives to hide problems.
They recognize that complex projects don’t just need contractors. They need collaborators.
Engagement: It feels symbolic, but it is strategic.
We’ve seen what happens when engagement is sidelined: projects move faster and timelines shrink (pandemic excluded). Instead of being late and expected, RFPs hit the street before the opposition and NIMBYs are organized. The CDPQ model has shown that delivery can accelerate when decision-making is kept close and public input is minimized.
The REM pulled it off. The REM de l’Est didn’t. Like it or not, people will figure out how to work around those tricks.
Delivery isn’t just about speed. It’s about building systems that can survive controversy, setbacks, and the scrutiny that comes once the ribbon is cut. And that only happens when people feel like they were part of the process, not just informed about it afterward.
Start early, and let it shape the solution.
We already have the technical tools to model projects and optimize outcomes. What we often miss is the context: the on-the-ground knowledge about how people live, move, and interact with the systems we’re building.
Engagement done right isn’t about consensus. It’s about getting actionable insight into the world the project will land in. That means starting before the scope is locked, and using public input not just for validation, but for shaping what the project needs to solve.
The best buy-in doesn’t come from messaging alone: it comes from solutions that feel grounded and designed with more than just ambition. Listening, iterating, and adjusting based on real constraints doesn’t mean abandoning a project. It means making it fit where it lands.
Engagement doesn’t end when the drawings are done.
One of the quiet failures of major projects is that engagement stops the moment design is finalized. Once the renderings are published and procurement begins, the public disappears from the process, even though they’re the ones who will live with the outcome for decades.
They aren’t the audience: they are partners, whether we choose to treat them that way or not.
This is one of the real limitations of the CDPQ approach, and that “go fast and break things” mentality. It sure can move fast, but it is opaque and becomes a “us versus them” mentality. When friction appears during construction or after launch, there’s no relationship and social capital left to work from. No shared understanding. No space to course-correct.
Engagement that ends with design is messaging. Engagement that continues through delivery is ownership.
If we want systems people can trust, we have to keep talking while they’re being built, not just before they’re approved. The people affected by a project should see themselves in it, not just be told they were considered at some point. That includes vulnerable populations, Indigenous communities, and those whose needs rarely make it into renderings. Public infrastructure should serve all of us, not just those with the time and privilege to attend consultations.
Delivery is a culture.
We talk about infrastructure as if it’s just a question of scope, contracts, and cost control. But none of that means much without the people who carry it forward, across years, teams, governments, and problems that were not in the original masterplan.
Delivery is not something that happens because a contract was signed. It happens because someone stays with it. Someone who sees it through the quiet setbacks, the missing pieces, the messy coordination. Someone who feels a sense of ownership, even if their name isn’t on the plaque.
That kind of ownership isn’t abstract. It comes from the people who carry the project between binders and barricades: procurement officers, site supervisors, engineers, operations staff and so many more. The ones who catch the things that fall between disciplines. They’re rarely the ones quoted in announcements, but without them, nothing moves. They aren’t just delivery heroes, but the translators for all the fields of expertise needed to make them happen.
This is where public delivery often falters. Not because people don’t care, but because no one is set up to hold the thread. Roles turn over. Context gets lost. Problems get passed along instead of solved.
If we want better delivery, we need institutions that can hold knowledge, and people who are trusted enough to use it well. People who can connect the technical and the human. People who care about what happens after the ribbon is cut.
Because in the end, delivery isn’t just about finishing something. It’s about what it becomes, and whether it works for the people it was meant to serve.
We’ve known those answers for a while.
We already know how to build better. The tools, models and talent exists. This isn’t a breakthrough reflection, in fact, it’s one we do every time a project fails to deliver on its premise.
What’s missing isn’t innovation.
It’s alignment, care and the willingness to design systems that work not just on paper, but in practice.
We keep saying we want better outcomes, but we do not change how we measure them. Delivery is more than a ribbon-cutting date or an on-time, on-budget report. It has to include time to benefit. Ease of use. Operational resilience. And whether people actually trust the system once it’s live.
Because building better starts with knowing what better looks like: this is not a technical challenge, but rather a cultural one. One I want to be part of solving.