Every organisation has them…

Not the polished process map in Visio, not the beautifully governed approval workflow, not the operating model that took six workshops, three steering groups and a forty-page slide deck to agree… what you will pretty much always find is the route people actually take: The Desire Path.

If you’ve walked across a park in an urban area, or some form of campus, you’ve seen one. A nice, manicured and prepared path that curves neatly around a patch of grass, and track of dust or mud which cuts directly from A to B. No signs, no governance, no communication plan. Just a lot of people independently arriving at the same conclusion: there’s a quicker/easier way.

The interesting thing about desire paths is that they are feedback. Nobody organised a campaign against the official route, nobody raised a RAID item, nobody submitted a change request. People simply adapted their behaviour to get the outcome they needed.

And in organisations, we do exactly the same thing. When governance becomes friction, people find a workaround. When approval chains become excessive, people have conversations outside the process. When service desks become cumbersome, people phone someone they know. When delivery frameworks become detached from reality, teams quietly create their own.

Very often we treat these workarounds as the problem; but really they are symptoms. A well-worn desire path tells us something important: the users have finished the design exercise, and they have already voted. When hundreds of people consistently choose an unofficial route, the question shouldn’t be “how do we stop them?”, but “what are they telling us?”

The best product designers understand this instinctively. The best urban planners understand it. The best delivery leaders should too. Because process exists to enable outcomes, not to become one.

Every time your organisation creates another checkpoint, approval board, sign-off gate or mandatory form, you are making a bet: that the value created exceeds the friction introduced. Sometimes that is absolutely true, and the organisation genuinely needs control, assurance, compliance and risk management. But sometimes we are building decorative pathways while people are already walking through the grass.

The real test of any process isn’t whether it looks sensible on a PowerPoint slide. It is whether people use it when nobody is forcing them to. If they don’t, don’t blame the people. Follow the path. It is probably trying to tell you something.

It came up recently (again), a classic way governance falls down is that it treats a small enhancement the same way it treats a two year regulated programme. Same forms, same gates, same board slot. So the small stuff drowns in process, the big stuff gets the same shallow attention as everything else, and the teams doing the work quietly build a private way of getting things done that the governance never sees. Once that happens the reports are, putting it kindly, what you want to hear, rather than useful reality and everyone knows it.

The fix is not more control. It is tiering. Deciding, up front, how much governance a piece of work actually earns, based on its value and its risk. So simple, so easy, so why do you still see poor PMs struggling with 30+ “projects” on which all they do is admin!?

I was asked this week how I would solve this, and it struck me that my answer hasn’t changed since the first time I tackled something like this … literally decades ago!

Three tiers, decided at intake

Tier 1 is the work that can hurt you. High value, high risk, regulatory, cross-platform, or client-facing. It gets a lean business case with a stated benefit hypothesis, an executive sponsor, incremental funding, and an independent assurance review sampled during delivery. Not a fifty page document. Enough rigour to be sure the money is going somewhere sensible and the thing is on track.

Tier 2 is moderate value, single team. The team lead owns it inside written guardrails. The benefit is recorded so you can check it later. It shows up on the portfolio view so dependencies and capacity stay visible, and it reports by exception. No need for everyone to gather, in a monthly board meeting to talk about it while it is behaving.

Tier 3 is the enhancement, the small change, the near-BAU work. It runs on the backlog. No portfolio approval, no gate, no ceremony. It is governed by work-in-progress limits, a definition of done, and the release pipeline. It is visible for capacity and dependencies and nothing more.

The point of the tiers is not the labels. It is the discipline of asking, before anything starts, how much scrutiny this actually deserves. Apply top-tier rigour to everything and delivery quietly starts routing around you. That is the most common way a control function turns into the thing people avoid.

The rules that make tiering hold

Tiering on its own is not enough. Three things keep it honest.

Read the data out of the delivery tooling. The plan, the flow, the actuals, the risks, all captured once where the work happens. As long as it stays within tolerance, nobody is wasting time writing some form of words that amounts to, “it’s on track”.

Escalate on a threshold, not on a judgement call. Set the tolerance when the work is approved. A breach fires on its own. That removes the personal cost of raising a problem, which is the thing that normally keeps bad news moving slowly. A colleague of mine is very fond of saying that bad news is not like red wine, it does not get better with age! You want the news travelling while there is still time to do something about it.

Delegate real authority, and write the guardrails down. Inside the guardrail, the team decides and moves. Cross it, and it escalates automatically. A change to funding, to the benefit, or to a regulatory commitment is a breach. A scope change, if it’s funded and within contingency, is really something for the project, not the sponsor.

One BIG Caveat - be clear that just because the metrics don’t demand escalation, that doesn’t mean the PM (or whoever) cannot raise an alarm, and effectively ask for help. Even if all they need is a 2nd pair of eyes and reassurance … that is part of what you are there for!

Why I build it this way

I did not arrive at this from a framework. I arrived at it from watching governance fail at scale and having to rebuild it.

On a multi year regulated programme covering more than forty projects and up to a hundred people, I built the reporting and control environment from the ground up, and (frankly) for my benefit. As the Delivery Lead, in a culture where everyone wanted to tell me everything, you end up drowning, unless you set things up to manage by exception.

Setting up group demand management and benefits realisation elsewhere taught me a harder lesson. Benefits tracking that starts at project closure never happens. You define the benefit at the start or you never measure it at all.

And most of the recovery work I have done on stalled programmes came down to the same move. Every one was stabilised by re-establishing governance, reporting and control, not by adding people. It comes down to the responsible people having clear line-of-sight to the actual data and the actual problem(s) and (usually) making the hard-calls.

Leave method to the teams

One last thing, because it is where a lot of governance goes wrong now. Govern outcomes and guardrails. Leave method to the teams doing the work. Asking an Agile team to stop and produce waterfall artefacts for a governance forum is the fastest way to lose both the pace and the honesty of the data. You do not need their ceremony to change. You need their data to be true and their guardrails to be clear.

Good governance is cheap, quiet, and mostly invisible until something is genuinely off track. If yours is loud, expensive, and produces reports nobody trusts, the answer is almost never more of it.

Rightsize it, and trust your people (but leave guardrails up)!