The Best-Kept Secret in Capital Projects

There is a body of knowledge in this industry that decides whether projects succeed or fail, and most of the world has never been taught it.

It isn't complicated. There's no certification that guards it. It simply grew up inside a small number of companies - mostly the major oil and gas operators - because those companies were spending hundreds of millions on single decisions and could not afford to get them wrong.

They learned, expensively, that the decisive part of a project is not how well you build it. It's how well you set it up before you commit the money.

So they built a system for that. And then, quietly, it stayed inside those buildings.

What the secret actually is

Stripped of the jargon, it's this:

Before you choose a solution, you agree what problem you're solving and what a good outcome looks like. Then you look at real alternatives. Then you commit money in phases - a bit at a time - and at each decision gate someone with authority genuinely decides whether to keep going.

That's it. That's the whole thing.

The pieces have names. Framing is agreeing the problem and what success looks like before anyone picks an answer. A gate is a point where a person with authority decides: continue, stop, or go back and do more work. Front-end loading is simply the work you do before you commit and the research is consistent that projects with a well-defined front end significantly outperform those that rushed into execution.

Simple ideas. Enormously difficult to do honestly. And almost never taught outside the companies that invented them.

Who was never given it

This is where it gets interesting.

In my experience working across the UK, Australia and the US and teaching people from many more countries than that - this discipline is not evenly distributed at all.

The major operators have it, deeply. Their supply chains half-have it. And beyond that, it thins out fast.

I've been genuinely surprised how often I meet capable, senior people in Europe and parts of Asia running very large projects with no structured front end at all. Not because they're less able- but because nobody ever handed it to them. The knowledge never travelled.

Newer companies have it least of all. Renewables developers, technology-driven energy businesses, infrastructure firms that grew quickly - they often have brilliant commercial people and no institutional system for making a project decision. Sometimes an ex-major employee arrives carrying it in their head, and it lives entirely in that one person until they leave.

And local and regional government may be furthest from it of anyone, while managing some of the most consequential projects there are. Public money, public consequences, and almost no exposure to the discipline that the private sector built precisely because these decisions are so expensive to get wrong.

The projects that fail quietly

Here's the part that keeps this hidden.

Badly framed projects rarely fail loudly. They fail in ways that get explained by something else.

A renewables project chooses a site and technology because a grant window was closing. The grant becomes uncertain. The community pushes back. The project collapses and it is written up as a political problem, or a regulatory problem, or bad luck.

It wasn't. A project that exists because money was available, rather than because value was defined, has no answer when either one moves. It was doomed from the beginning. But nothing in the post-mortem will say so.

A city or region commits to a major project. The estimate multiplies, then multiplies again, and eventually the whole thing is cancelled. The story afterwards is about politics or contractors.

A transformation programme gets a project manager, a charter, a plan and a budget and fourteen months later nobody is using the thing that was built. It gets called an adoption problem.

In every one of these, the same thing happened at the start, and in none of them is it named. So the lesson never gets learned, and the next project makes the same mistake.

That's why I call it a secret. Not because anybody is hiding it but because the failures that would teach it are attributed to something else.

The words exist but the practice often doesn't.

Here's the trap that catches the organizations who think they already have this.

Most large organizations now have the vocabulary. There are phases. There are gates. There's a business case template, a gate paper format, an assurance function, a review board with a calendar. On paper it looks exactly like good practice.

But the words can be present while the practice is absent. And the difference shows up in what actually happens in the room:

A real gate asks: should we continue? A hollow gate asks: is the paperwork finished? Those are completely different questions, and only one of them protects money.

A real business case compares options. A hollow one justifies the option already chosen. If there was one preferred answer and two options nobody expected to select, no decision was made - a preference was approved.

Real assurance challenges whether the project makes sense. Hollow assurance checks that the documents are consistent with each other. You can quality-check an answer very thoroughly without ever examining the question.

Real framing happens before a solution is named. Hollow framing is written afterwards, to explain the solution somebody already chose.

If you want to know which version your organization has, answer this: when did a gate last stop a project?

If the answer is "it hasn't," you don't have a gate system. You have a funding schedule with meetings attached.

Three symptoms worth checking for

Nobody can stop it. By the second or third gate there's a team, a budget line, a contractor, a number in the corporate plan, and a sponsor whose reputation is attached. Stopping has become a career event rather than a decision.

Nobody actually decided. Ask when the technology was chosen, or the site, and you get a date range rather than a date. It emerged from an early study and was never revisited. Those are decisions by drift, and they are extremely expensive to undo later.

Alignment came too late. Operations, the functions, the regulator, the community - brought in during framing, they shape the project. Brought in at commitment, they renegotiate it. Late alignment can easily turn into a delayed argument at the worst possible price.

Why local government needs this most

Public projects have every ingredient that makes framing essential, and almost none of the discipline.

The solution is frequently named before the problem is defined - it arrives as a commitment, a manifesto item, or a funding opportunity that has to be used before it expires. Alternatives are rarely examined seriously, because a preferred answer already exists in public. Consultation happens after the design, which means citizens are informed rather than involved. And the decision cycle is political, so slowing down at the start to get it right carries a visible cost while the eventual overrun arrives after someone else is in the chair.

The result is a category of project that everyone in the region can see coming and nobody can stop.

None of this requires a bigger budget to fix. It requires four questions asked early, in public, and answered honestly: What problem are we solving? What does success look like? What else could we do? What are we assuming?

What this actually gives you

Four things, in ascending order of value.

Cheaper failure. The point of a strong front end isn't only to improve good projects. It's to stop bad ones early, when stopping costs a study instead of a sanction. An organization that kills three weak projects at the first gate has created more value that year than most efficiency programmes.

Real choice. Framing forces genuine alternatives to exist before a preference becomes a commitment.

Alignment. People who helped shape a decision defend it. People who were informed of it renegotiate it (or resist it).

A decision you can defend. Criteria, options, assumptions, rationale, owner, date. Written down. That's what makes a decision auditable, teachable, and reversible on new evidence rather than on politics.

The part that's genuinely hard

The Decision Gate Process looks like a process. It's really a set of behaviours that actually work:

Stop and go back become respectable answers. Killing a weak project is recognised as protecting value, not as failure. Raising an uncomfortable assumption is treated as a contribution rather than a career risk. Challenge from a review board is understood as protecting the project, not catching people out. Teams get credit for the quality of their thinking, not only for visible momentum. And decisions leave a trail.

You can install the process in a month. The behaviours take a cycle of real projects and someone competent holding the line.

That's the difference between an organization that has gates and an organization that makes decisions.

And it's the only real secret here: 

the knowledge isn't hard to find, it's hard to practise - which is why so few organizations do, and why the ones that do are so consistently hard to beat.

I teach this as the Decision Gate Process and Opportunity Framing - the front-end operating system the best owner organizations in oil and gas run on, taught by someone who has worked both sides: major EPC contractors and owner organizations.

→ academy.wilson.biz

#epc #capitalprojects #decisiongateprocess #opportunityframing