Best practice is killing your project

Someone says “it’s best practice” in a meeting and the room goes quiet. Debate over. The phrase has a peculiar authority, and almost nobody ever asks where it came from.

They should.

All “best practice” really means is that something worked somewhere else, at some point, for an organisation that probably looked nothing like yours. That’s genuinely useful information. It is not an instruction.

The context is everything, and the context never travels with the practice. A stage gate process that saved a nuclear regulator from disaster might strangle a software team. A stand-up ritual that transformed a startup might be pure theatre in a government department. The practice isn’t wrong. It’s just been lifted out of the conditions that made it work.

What worries me is the way the phrase ends conversations rather than starting them. Someone invokes it, and the thinking stops. Nobody wants to be the person arguing against best practice, because the framing makes disagreement sound like ignorance.

I’ve watched teams adopt a whole methodology this way. Not because anyone examined whether it fit, but because it was what serious organisations did, and nobody wanted to explain why they were doing something different.

Then they inherit assumptions they never examined and wonder, eighteen months later, why the process feels like it’s fighting them. It’s the same drift that turns a PMO into a tax on delivery, one reasonable-sounding addition at a time.

Here’s the habit worth building. When someone defends a decision with “it’s best practice,” ask two questions. Best for whom? And how do we know?

Sometimes there’s a real answer. Evidence, a clear reason it applies here, a genuine similarity in the problem being solved. Good. Adopt it with confidence, and adopt it faster for having checked.

Often the answer is a shrug. Someone read it in a framework. Someone did it at their last job. That’s not a standard. That’s a habit wearing a badge, and habits should have to earn their place like everything else.

Keep what genuinely serves your project. Drop the rest, however official it sounds. The same scepticism applies to the plan you wrote on day one, which was your best guess at a moment when you knew the least.

The point isn’t to ignore what others have learned. It’s to interrogate it before you inherit it. Where did this come from? What problem was it solving? Is that our problem?

If you can’t answer that last one, you’re not following best practice. You’re just copying.


Ben Webb is an award-winning project leader and strategist. Named Australian Institute of Project Management Project Manager of the Year in 2022 and nominated for the International Project Management Association’s World Project Manager of the Year in 2023, he writes about delivery, leadership and the difference between managing a project and actually getting it done.

Leave a Reply

Discover more from BEN WEBB

Subscribe now to keep reading and get access to the full archive.

Continue reading