Governance Without Bureaucracy

Somewhere in most delivery programmes there is a sentence everybody agrees with and nobody examines: governance is slowing us down. As a description it is often accurate. Work does sit still waiting for approval, reports do take half a day to assemble, and decisions that could have been settled in a corridor travel up two levels and come back a fortnight later. As a diagnosis it is usually wrong, because it treats the delay as a property of governance itself rather than of the way this particular governance was set up. Strip the controls out and the delay goes, along with any confident answer to whether the project is still worth funding.

The more useful question is narrower. Which parts of this control system are producing decisions, and which parts are producing material that nobody acts on? Once that separation is made, most of the apparent conflict between control and pace turns out to be recoverable without anyone having to argue about whether governance is a good thing.

Most governance load is information, not decision

A practical audit of any governance arrangement runs on three questions. Which decision does this artefact or meeting feed? Who takes that decision? What would they do differently on the strength of it?

The first two questions are usually answerable. The third is where the weight falls away. A great deal of project reporting exists because somebody once wanted assurance about something, got a report, and never revisited whether it was still needed. Nobody removes it, because removing a report looks like reducing transparency, and the cost of keeping it is spread thinly across other people's weeks. Over a couple of years an organisation accumulates a reporting layer that consumes real effort and changes almost nothing.

Governance that produces no decision is administration wearing a governance label. That is worth saying plainly, because it also protects the controls that do work. When a project manager proposes retiring a report, the credible version of that proposal names the decision the report was meant to support and explains where that decision will now be taken instead. The weak version simply asks for less paperwork, and it deserves the refusal it normally gets.

The PMBOK® Guide treats this as a tailoring question rather than a fixed design. Section 2.1.7 sets out tailoring considerations for the governance performance domain, and the orientation there is that the intensity of governance should be matched to the project's context rather than applied at a standard organisational setting. That is a more demanding idea than it first appears. It means the default governance package your organisation hands you is a starting position, not an answer, and that arguing for a lighter or heavier arrangement is part of the job rather than an act of rebellion.

Thresholds set in advance are what make delegation safe

The single largest source of avoidable governance delay is unstated authority. When nobody has written down what the delivery team may decide alone, every decision of any consequence travels upward, and the caution driving that is entirely rational at the individual level. A team lead who approves something that later goes wrong will be asked why they did not escalate it. A team lead who escalates something trivial will be mildly irritating for ten minutes. The incentive only points one way.

Thresholds fix this by moving the judgement forward in time. Decide once, calmly, at what point a change, a cost variance, a schedule slip or a risk becomes something the sponsor or steering group needs to see. Then most decisions genuinely never have to travel, and the ones that do arrive with a reason attached.

Setting thresholds well is less about the numbers than about what the numbers are standing in for. A round figure borrowed from another project tells you nothing. Better criteria are the ones that describe consequence: is this reversible, and how quickly; does it change a commitment somebody outside the project has already made; does it touch safety, regulatory approval, contractual obligation or a published date; and who carries the loss if the decision turns out to be wrong. Two changes of identical value can sit either side of a sensible threshold, because one can be undone in a sprint and the other cannot be undone at all.

This is also where exam relevance is genuine rather than forced. The 2026 PMP Examination Content Outline places project governance in the Business Environment domain, which accounts for 26 per cent of exam items, and the first task in that domain is defining and establishing project governance. One of its enablers is outlining governance escalation paths and thresholds. The examinable idea and the practical one are the same idea: thresholds are part of designing governance, not something you improvise when the first difficult decision arrives.

Raising a limit is not the same as loosening control

A project to install automated inspection cells across two production lines had a change control board that met monthly. On paper this was proportionate. In practice the board approved almost everything below about fifteen thousand pounds without discussion, and the engineering team could not raise orders for long-lead components until it had met. Two of the four cells were standing part-built on the floor with their guarding still on pallets, waiting on parts that could not be ordered because a board that would approve them anyway had not yet sat.

The instinctive fix is to meet more often. The better response starts by noticing what the board is actually for. It was not controlling spend, because it approved everything in that band. It was recording spend, and it was doing so at a cost of up to four weeks per item.

What worked was a change in both directions at once. The delegated limit rose to fifteen thousand pounds, with the project manager able to approve within it against written criteria and a consolidated schedule of approvals going to the board each month. In exchange, the board's remit sharpened: anything affecting the commissioning sequence, the safety case or the regulatory sign-off went to the board regardless of value, including changes that would previously have been waved through at two thousand pounds. Control did not reduce. It moved to where the consequence of being wrong actually sat. If you want to work through this kind of trade-off in a structured, instructor-led setting, the PMP® Exam Preparation course develops the same habit of reading consequence rather than applying a standard control set.

The point that survives beyond this example is the exchange. Governance that is only ever relaxed erodes, and everyone involved knows it. Governance that is retuned, with something tightened as something else is released, is defensible in front of a sponsor and an auditor alike.

Where the control sits when delivery is iterative

None of this is an argument that predictive governance is heavy and adaptive governance is light. Both arrangements fail, and they fail in opposite directions.

In predictive delivery the characteristic failure is the one described above: control applied uniformly, so that low-consequence decisions carry the same procedural weight as high-consequence ones. In adaptive delivery the characteristic failure is the assumption that because reviews and planning sessions happen frequently, governance is being exercised. Cadence is a delivery rhythm. It becomes governance only when someone with the authority to stop, redirect or refund the work is present and is making a decision that gets recorded. A well-attended review at which nobody could have said no is not an oversight mechanism.

Hybrid arrangements need the most deliberate thought, because the common error is to apply one control set across both halves. A project with a regulated hardware element and an evolving software element does not need the same change threshold on each. The hardware stream may reasonably require formal approval for anything touching the physical build, while the software stream operates with a much higher delegated limit and a monthly consolidated view. That is not inconsistency. It is the same principle, which is to place control where reversal is expensive.

For a working project manager the practical test is simple enough to apply on a Monday morning. Take the governance arrangement you have inherited and mark each element with the decision it feeds. Anything you cannot mark is a candidate for retirement or repurposing. Anything you can mark deserves a threshold, so that the people doing the work know what is theirs to decide. Governance stops feeling bureaucratic at roughly the point where everyone can tell you which decisions travel and why.

Andre Malowney

Interested in going further?

Deciding where a threshold belongs, and defending that decision to a sponsor who has been burned before, is a judgement that builds faster with structured practice than with reading alone. The PMP® Exam Preparation course works through governance design, escalation and change decisions across predictive, adaptive and hybrid contexts, so the reasoning holds up whichever kind of project you are handed next.

If you want to see how governance intensity is framed as a tailoring decision rather than a fixed package, the PMBOK® Guide Eighth Edition is the source to work from.

Ad · Amazon affiliate link.

References

A095: Governance in Predictive Environments
A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What’s the Difference?
A093: Choosing a Project Governance Model
A096: How to Recognise a Governance Question on the PMP Exam

PMP and PMBOK are registered marks of the Project Management Institute, Inc.