top of page

Governance vs Management: The Hidden Tension That Derails Otherwise Good Projects

Writer: Pip Rudhall Hyett
Pip Rudhall Hyett
Sep 30
7 min read

Governance vs Management: The Hidden Tension That Derails Otherwise Good Projects


If you have ever sat in a steering group meeting where the board wanted to get into the details of a task schedule, or watched a project manager quietly make a decision that really should have gone upstairs first, you have seen this problem in action. It rarely looks dramatic.


It looks like mild confusion, duplicated effort, and decisions that take three meetings instead of one.


In complex projects across Central Otago, Queenstown Lakes and wider Otago, this is one of the most common - and most avoidable - reasons good projects lose momentum. Not bad people. Not bad ideas. Just a blurry line between governance and management that nobody has taken the time to draw clearly.


In this article, we will look at practical ways to:

•      Understand the real difference between governance and management

•      Get clear on what a board should (and should not) do in a project

•      Pin down who is actually responsible for delivery

•      Separate governance from the day-to-day work of operations


These are people-first strategies drawn from project work across Central Otago, Queenstown Lakes and Otago, where projects often span multiple organisations, community boards and stakeholder groups with genuinely different roles to play.



Governance vs Management: What Is the Real Difference?


At its simplest, governance is about direction and oversight - deciding whether a project should happen, what success looks like, and what risk is acceptable. Management is about delivery - making it happen, day by day, decision by decision, task by task. The tension shows up when either group starts doing the other’s job.


1.    Governance asks "should we", management asks "how do we" 


Boards and steering groups exist to test whether a project remains worth doing, well resourced and within acceptable risk. Project managers exist to work out how to deliver it. When a board starts designing the "how", or a project manager starts quietly deciding the "should", the roles have blurred.


2.    Governance is periodic, management is continuous 


Governance typically operates in cycles - monthly steering groups, quarterly board papers, milestone gateways. Management operates every day, often every hour. Confusion creeps in when governance groups expect day-to-day visibility, or when project teams wait for a monthly meeting to make decisions that were theirs to make all along.


3.    Governance owns risk appetite, management owns risk response 


A board sets how much risk the organisation or community is willing to carry. The project manager identifies, tracks and responds to risk within that appetite. Trouble starts when a board tries to manage individual risks directly, or a project team quietly accepts risk beyond what governance would sanction.


4.    Work with governance on a "no surprises" basis


One of the fastest ways to build trust with a governance group is to make sure they are never blindsided. If you get even a sniff of a possible high risk heading your way, flag it lightly and early. That way, if it does land and becomes a real risk, they are already warmed up to it, and the conversation is about what to do next rather than why nobody mentioned it sooner. Boards forgive bad news far more readily than they forgive surprises.


5.    Write the boundary down, early 


Most governance and management tension is not personality, it is ambiguity. A short one-page document that sets out what the board decides, what the project manager decides, and what gets escalated saves months of friction later. In multi-agency projects across Otago, this single page is often the most valuable artefact in the whole project.


A board’s job is to hold the project accountable to its purpose, not to run it.
A board’s job is to hold the project accountable to its purpose, not to run it.

What Does a Board Do in a Project?


A board’s job is to hold the project accountable to its purpose, not to run it. That distinction matters more than it sounds.


1.    Set and protect the direction 


The board confirms why the project exists, what success looks like, and whether that is still true as circumstances change. If the case for the project shifts, the board is the group that revisits it - not the project manager working alone.


2.    Approve the big decisions, not the small ones 


Boards should be making calls on scope changes, funding, major risk and significant trade-offs - the decisions that shift outcomes, cost or reputation. Sign-off on a supplier email or a workshop agenda is not a board decision, and asking for it slows delivery without adding value.


3.    Provide oversight, not supervision 


A good board asks sharp questions about progress, risk and benefits, and holds the project manager to account for answers. It does not sit in on daily stand-ups or rewrite the project plan. Oversight builds confidence; supervision erodes trust and doubles up work.


4.    Scale the governance to the project 


Not every project needs the same weight of governance. The level of formality, the size of the group and how often it meets should all flex to suit the size, scope and risk of the work in front of you. A small, low-risk piece of work might need a short monthly check-in with two or three people. A high-risk, multi-organisation programme might need a formal steering group meeting fortnightly with full papers. It can also change as the project moves through its phases - stepping up through a high-risk build or a tricky consenting stage, and easing back once things are steady again. Checking whether the governance setup still fits is a sensible thing to do at every major milestone.


5.    Remove obstacles the project manager cannot move alone


Boards are often the only group with the authority to unlock funding, resolve conflict between organisations, or make a call between competing community priorities. In Central Otago and Queenstown Lakes, where projects frequently cross council, iwi, community and commercial interests, this is often the single most valuable thing a board does.


Does your project have one clear owner? If not, let's start there.
Does your project have one clear owner? If not, let's start there.

Who Is Responsible for Project Delivery?


Delivery has one clear owner, even though many people contribute to it. When that ownership is fuzzy, accountability disappears along with it.


1.    The project manager owns delivery 


The project manager is accountable for turning the approved direction into results - on time, on budget, to the agreed quality, within the risk appetite the board has set. That accountability cannot be shared out or quietly absorbed by the board when things get hard.


2.    The sponsor is the bridge between governance and delivery


A strong sponsor translates board decisions into direction the project manager can act on, and carries delivery realities back up to governance. Without a sponsor doing this work well, governance and management drift apart and communication breaks down in both directions. 


It is worth saying that not every project has a sponsor. On smaller pieces of work the role often does not exist as a named position at all, and the project manager will report directly to whoever holds the decision-making authority. That is perfectly workable - what matters is that the link between governance and delivery is deliberate rather than left to chance, whoever is holding it.


3.    The team is responsible for the work, not the outcome


Individual team members are accountable for their piece of the plan - a report, a build, a stakeholder relationship. The project manager remains accountable for how those pieces come together into the outcome the board approved.


4.    Name it in writing 


A simple RACI, even sketched on one page, clarifies who is Responsible, Accountable, Consulted and Informed for the decisions that matter. In projects spanning multiple organisations across Otago, this single exercise resolves more delivery arguments than any escalation process ever will.


What Is the Difference Between Governance and Operations?


Governance and operations sit at opposite ends of the same project, and confusing them is where a lot of the pain in "governance vs management" actually comes from.


1.    Governance decides whether and why, operations decides how and when 


Governance sets the direction, the funding envelope and the risk appetite. Operations is the daily reality of resourcing, scheduling, problem-solving and adjusting as things unfold on the ground.


2.    Governance looks forward and across, operations looks close and now 


A board should be scanning the wider picture - benefits, risk, alignment with strategy. Operational teams are focused on the next fortnight of delivery. Both views are necessary, and neither should try to substitute for the other.


3.    Escalation is the bridge, not a failure 


Operational issues should only travel up to governance when they touch risk appetite, funding, scope or reputation. Escalating everything overloads the board and slows delivery; escalating nothing leaves the board blind to real risk. Getting this threshold right is one of the sharpest signs of a well-run project.


4.    Keep operational decisions where they belong 


When boards start directing rosters, supplier choices or day-to-day sequencing, decisions slow down and the people closest to the work lose the authority to solve problems quickly. Trust the operational layer to operate, and reserve governance time for genuinely governance-level calls.



Bringing It Together


Governance and management are not competing forces - they are two different jobs that depend on each other to work well.


When you:

•      Draw a clear line between direction and delivery

•      Keep boards focused on oversight, not supervision

•      Give delivery a single, accountable owner

•      Protect operational decisions from governance creep

•      Work with governance on a "no surprises" basis, and scale it to suit the project

...you remove one of the quiet but persistent reasons projects stall, even when the people involved are capable and well-intentioned.


At Rudhall Hyett, we help boards, sponsors and project teams across Central Otago, Queenstown Lakes and wider Otago get clear on exactly this - who decides, who delivers, and where the line sits between the two.


If governance and management have started to blur on your project and progress is slower than it should be, get in touch with Pip and let’s talk through where the tension sits and how to resolve it.


Comments


bottom of page