How Do You Run a Project in a Hybrid Governance Environment?

There is a particular kind of tiredness that comes from sitting in a steering board meeting on Tuesday morning, defending a business case with numbered sections and a RAG status column, and then walking into a stand-up on Tuesday afternoon where nobody has looked at that document and nobody plans to. Both rooms think they are running the project properly. Neither is wrong. That is the part most guidance skips over.

Most organisations that describe themselves as "hybrid" arrived there by accident rather than design. A programme office that has always demanded formal sign-off inherits a delivery team that has always worked in sprints, or the reverse happens, an agile team gets absorbed into a structure built around phase gates and assurance reviews. Nobody sat down and designed the combination. It simply exists, and the project manager in the middle is expected to make it behave as though it were intentional.

The instinct, understandably, is to treat this as a problem to be solved once. Pick a framework, adapt it slightly, write a one-page guidance note explaining how "our version" of governance works, and move on. It rarely survives contact with a real project. The steering board still wants to see a business case with a defined scope and a benefits case before it releases funding, because that is how it manages risk, and no adapted framework changes what a finance director is personally accountable for. The delivery team still needs the freedom to discover, mid-sprint, that a requirement was wrong, because that is how software actually gets built, and no governance document changes what a working system requires. The tension is not a communication problem. It is two disciplines with genuinely different assumptions about how certainty is created, being asked to coexist inside the same project.

What experienced practitioners actually do, rather than what the frameworks suggest they should do, is quietly hold both systems at once and translate between them continuously, rather than merging them into a single hybrid process on paper. A senior PM I worked alongside on an infrastructure programme described it as running two clocks. One clock ticks in stage gates, quarterly investment reviews, and a business case that has to be defended in front of people whose job is to say no. The other ticks in sprints, retrospectives, and a backlog that changes shape every fortnight. Her actual job, she said, was never to merge the two clocks into one. It was to keep translating what one clock was showing into language the other clock's owners would trust.

That translation looks unglamorous in practice. It looks like taking a sprint's worth of genuinely messy, half-finished progress and writing it up, honestly, as a RAG status the steering board can act on without either overstating confidence or triggering unnecessary alarm. It looks like taking a stage gate's list of approved scope and translating it into a backlog the team can actually plan two weeks against, rather than a document they read once and ignore. Neither translation is difficult on its own. Doing it every single reporting cycle, without letting either side quietly drift into believing the other side's discipline is optional, is the actual skill.

I once watched a project manager catch a delivery lead in a corridor between two meetings, phone in one hand showing that week's sprint board, a printed page of the business case in the other, working through exactly this translation out loud before either of them went into their next room. Nothing about the exchange looked formal. It was two people making sure the story they were each about to tell, to a governance board and to a development team respectively, didn't quietly contradict each other. That five minutes did more to keep the project coherent than either the stage-gate template or the sprint ceremony did on its own.

Where this breaks down is when one side is treated as the "real" governance and the other as a concession. A governance board that views sprints as an implementation detail beneath its notice will keep demanding certainty the delivery team cannot honestly provide, and will eventually get told what it wants to hear rather than what is true. A delivery team that views stage gates as bureaucratic theatre will stop taking funding reviews seriously, and will be blindsided when a gate genuinely closes. Both failure modes look, from the outside, like "poor communication." They are actually a refusal to accept that both disciplines are load-bearing, and that translating between them is a real piece of ongoing work, not a one-off setup task.

None of this requires abandoning either framework, and it is not a call for a looser, less accountable version of either one. A governance board that asks harder, more specific questions is doing its job well. A delivery team that protects its ability to adapt mid-sprint is doing its job well. The project manager's role in a genuinely hybrid environment is not to soften either discipline until they stop colliding. It is to stand deliberately at the point where they meet, and keep making the translation, cycle after cycle, so that neither clock ever quietly stops being trusted by the people watching the other one.

If you're working through what proportionate governance looks like for your own project, or want to think through where your organisation's version of this tension actually sits, get in touch about your 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.