Project Governance vs Organisational Governance: What’s the Difference?
A project board meets, considers a change, approves it, and records the decision. Four months later the finance director declines to release the money, because a commitment of that size is reserved to a capital committee the board had never heard of. Nobody acted improperly. The project had built its governance as though it were a self-contained system, when it was always a connection to a larger one.
Organisational governance is the standing structure of authority, accountability, policy and strategic direction that the organisation runs on, whether or not any projects exist. Project governance is how a particular piece of work operates inside that structure: the forums, the decision rights, the reporting and the escalation route for this project. The first sets boundaries the project did not choose. The second is the project's design, drawn inside them.
Where the line actually falls
Section 1.3.2 of The Standard for Project Management deals with the join between the two, and treats them as connected layers of a single system, which is the framing that makes the practical questions answerable. The layers are not a hierarchy of importance and they are not the same thing at different scales. They do different jobs.
Organisational governance answers questions that outlast any project. Who may commit the organisation to what. Which decisions are reserved to a board or a committee. What the policy position is on procurement, data, safety, recruitment and risk appetite. What the organisation's strategy requires and what it will not entertain. A project manager cannot change any of that and should not try, and time spent proposing a governance arrangement that cuts across it is time that will be handed back.
Project governance answers questions that exist only while this work does. Who is the sponsor and what have they been delegated. Which forum takes which decision, how often it meets, and what it needs in front of it. What the thresholds are inside the delegated limit. How escalation works when something exceeds the project's authority, and to whom. What gets reported, to whom, and what triggers a conversation between reports. All of that is genuinely yours to design, and designing it well is most of the value governance adds to a project.
What you inherit and what you design
The inherited set is worth writing down explicitly at the start, because it is usually discovered late and expensively. The scheme of delegation sets what your sponsor can actually approve, which is frequently less than everyone assumes. Procurement policy sets how you may buy, from whom, and above which value a competitive process becomes mandatory. Statutory and regulatory duties sit on the organisation regardless of the project's view of them. Risk appetite, where it has been stated at all, sets what the organisation is willing to carry. Information and data policy sets what you may do with what you hold.
The designed set is everything inside that envelope. Which forums exist and who sits on them. The cadence at which they meet, matched to how fast this project actually generates decisions rather than to the corporate calendar. The thresholds at which the project team, the sponsor and the board each take a decision, set as figures rather than adjectives. The reporting content, chosen so somebody could act on it. And the escalation route, named as a person and a forum, tested before it is needed. A project that has these written on one page is better governed than one with a thirty-page framework nobody reads.
The three ways the join breaks
The first is a project assuming authority the organisation has reserved. This produces the scene at the top of this article, and it is the most common failure because it feels like competence at the time. The remedy is dull and reliable: before a board is stood up, read the scheme of delegation and write the sponsor's actual limit into the terms of reference.
The second is escalation into a void. A project reaches something beyond its authority, raises it correctly, and finds there is no organisational forum that owns the decision. Cross-functional decisions are the usual victims, because the project sits between two directorates and neither has been given the call. Where no route exists, the escalation has to create one, and that is a sponsor's job rather than a project manager's.
The third is a governance design that has outlived its risk profile. Arrangements set when a project was novel and contentious stay in place once it has become routine, and a monthly board with eleven attendees carries on reviewing work that no longer needs it. Governance should be proportionate to risk and complexity, and proportionality is a judgement that has to be revisited, not made once. Knowing when to reduce governance takes as much nerve as knowing when to add it, and a structured PMP exam preparation course treats proportionality as a standing question, because it sits underneath most governance decisions.
A retailer replacing self-service technology across two hundred stores ran its programme governance well and hit the join anyway. The programme board had authority over the rollout, and the store estate was governed separately by a property function with its own standards for what could be fixed to a shopfront. The programme's chosen unit needed a power and data route the standard fixture did not provide. The programme manager escalated, discovered that no forum owned decisions crossing programme delivery and estate standards, and spent six weeks getting one convened. The technology was never the problem. The organisation had no place where that particular decision could be taken, and the programme found out by needing it.
For a PMP® candidate, the distinction to hold is that organisational governance is the standing system and project governance is a temporary arrangement inside it. In any situation describing a project decision that feels stuck, the useful question is whether the authority to take it sits inside the project at all, because escalation and negotiation are different responses and only one of them fits.
Half an hour with whoever administers the scheme of delegation, before your first board meets, is the most useful preparation available. Ask what your sponsor can approve, what has to go higher, and where decisions that cross functions are taken. Write the answers into the terms of reference in plain figures. Projects rarely fail because their governance was too simple. They fail because somebody assumed an authority that was never theirs, and nobody checked while checking was free.
Interested in going further?
Working out what a project may decide for itself, and recognising early when a decision has no home anywhere in the organisation, is a skill that takes some exposure to how different organisations arrange themselves. Omega's PMP® Exam Preparation covers governance as the connection between a project and the structure around it.
The Standard for Project Management, published within the PMBOK® Guide Eighth Edition, sets out the governance connection in full.
Ad · Amazon affiliate link.
References
A090: Project Governance Explained: Who Decides What, and Why
A093: Choosing a Project Governance Model
A096: How to Recognise a Governance Question on the PMP Exam
A094: Governance Metrics That Actually Tell You Something
A053: AI Governance for Project Managers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
