How Do You Choose the Right Governance Level for a Small vs Large Project?

A project manager once asked me, quite genuinely, why she needed a risk register, a stage plan, a change log and a fortnightly steering meeting for a piece of work that would be finished in eleven working days. She wasn't being difficult. She'd inherited a governance template built for a multi-year infrastructure programme and applied it, unquestioned, to a task that could have fit on one page. Nobody had told her she was allowed to do anything else.

That story sits at one end of a problem most organisations never actually solve. They solve it by accident, or they don't solve it at all. Somewhere there's a governance framework, usually built with the biggest, riskiest, most expensive project in mind, and it gets applied to everything that follows regardless of size. A two-week fix gets the same paperwork as a two-year transformation. Nobody decided this deliberately. It simply became the path of least resistance, because building a lighter version felt like extra work, and nobody wanted to be the person who skipped a control and then had to explain why when something went wrong.

The opposite failure is less visible but arguably more expensive. A large, genuinely risky project gets waved through with governance that would suit something trivial. A quick weekly email update stands in for proper stage control. A single sponsor, stretched across four other priorities, is expected to provide the assurance that should really come from a steering group with actual decision rights. This tends to happen on projects that started small and grew. Scope crept, budget crept, stakeholder count crept, and the governance never crept with it. By the time anyone notices, the project is running at a scale that needs real oversight and getting none of it.

Both failures come from the same root cause. Governance level has been treated as a fixed setting rather than a variable one. It gets decided once, early, often by habit rather than judgement, and then it stays wherever it was set regardless of what the project actually needs as it develops.

The frameworks that handle this well don't pretend there's a single correct amount of governance. PRINCE2 makes tailoring one of its seven core principles precisely because a method applied without adjustment to the specific project stops being useful and starts being theatre. The same logic holds whether or not you're running a formally badged methodology at all. The question isn't which framework you're using. It's whether anyone has actually asked, for this project, right now, how much control is genuinely warranted.

A useful way in is to separate two things that often get treated as one: project size and project risk. Size, measured in cost, duration or headcount, tells you something about how much coordination the work needs. Risk, meaning the consequence of things going wrong, tells you something quite different: how much assurance you need before you commit, and how closely you need to watch progress against plan. A small project can carry serious risk. A short piece of work that touches a live payroll system or a public-facing service needs proper sign-off and change control regardless of how few weeks it takes. A large project can, occasionally, carry modest risk, particularly if it's low stakes and highly reversible. Governance calibrated on size alone will misjudge both.

In practice, the projects that get this right tend to ask a short, honest set of questions before setting up any controls at all. What actually goes wrong if this fails, and how reversible is that failure? Who genuinely needs to see progress, and how often do they need to see it to make a real decision rather than simply feel informed? What's the smallest set of checkpoints that would catch a serious problem early enough to act on it? Answering those questions produces a governance model shaped by the work itself. Skipping them and reaching for the template produces governance shaped by whatever the last project happened to use.

There's a related discipline worth naming, because it's often the difference between governance that helps and governance that just accumulates. Review the level periodically rather than setting it once and leaving it. A project that starts small and stays small needs nothing extra. A project that starts small and grows needs its governance revisited at the point the growth becomes clear, not eighteen months later when someone finally asks why a programme-scale piece of work is still being run off a single spreadsheet. The review doesn't need to be elaborate. It needs to happen at all.

None of this is an argument against structure. It's an argument against structure applied without thought, in either direction. A three-week fix doesn't need a steering board. A three-year programme touching public safety absolutely does. The skill isn't in memorising a framework's full toolkit and using every part of it every time. It's in knowing which parts of it this project, at this scale, carrying this much risk, actually requires, and having the judgement to leave the rest on the shelf.

If you're weighing that decision on a live project and want a second opinion on where the line sits, get in touch about your PMP training options.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.