Key Concepts
Governance is simply how we are going to work together. It is not control for its own sake; it is the framework, functions, and processes that guide how decisions get made and work gets done. Even agile teams use governance, from the Product Owner’s authority over the backlog to the team’s ownership of its own estimates.
To some people from the agile community, the word “Governance” sounds controlling. A little Big-Brother-ish, heavy on oversight and direction. But governance just means “how we are going to work.” If you are running Scrum or XP, you have already established a governance structure for your team and business representatives. The Product Owner gets to decide what goes into the product backlog and the priority of work items. It is the team that creates estimates and makes their own local decisions. These are examples of project governance at work.
PMI defines Project Governance as “The framework, functions, and processes that guide project management activities in order to create a unique product, service, or result to meet organizational, strategic, and operational goals.” Put another way, governance is our structure for working. It helps everyone make the right decisions at the right level. Without it, decisions stall, escalations happen too late, and small disagreements turn into project-threatening problems.
Governance typically starts at the top of a hierarchical organization. Owners, executives and stockholders decide on the strategy that ripples down to the selected and funded portfolios, programs, products and projects. Then we get involved as project managers, Scrum Masters, team leads and project team members to execute these projects and product development activities. While we typically get some leeway and autonomy to run these initiatives, they must be compatible and aligned with the broader organizational governance structures.
3.1.1 Use Organizational Process Assets (OPAs).
Full ECO Title: “3.1.1. Describe and establish the structure, rules, procedures, reporting, ethics, and policies through the use of organizational process assets (OPAs).”
Most of what we need to set up governance does not have to be invented from scratch. Organizations already have standard templates, decision rules, reporting formats, ethical codes, and policies; these collectively are known as Organizational Process Assets, or OPAs. Our job is to pick the right ones, adapt them to the project, and make sure stakeholders agree on how they will be used.
Organizational Process Assets (OPAs)
Organizational Process Assets is the collective name for all the procedures, processes, policies, documentation, and knowledge bases used by an organization. Project managers and teams may recommend changes to OPAs to improve how projects operate, but they are usually owned and updated by the Project Management Office (PMO). Common OPA examples include:
- Standard templates for project work
- Specific organizational standards
- Guidelines and criteria for aligning project work
- Organizational communications requirements
- Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria
- Procedures for officially opening and closing a project
- Corporate knowledge bases for storing project information, including project files, policies and procedures, human resources documentation, and lessons-learned and retrospective findings
Components of Project Governance
Project governance covers the full spectrum of how the project will work and operate. This includes the life cycle, how we will handle changes, how we make decisions, and how we align with others. Standard components include:
- Acceptance Criteria – how deliverables and project success will be approved, and by whom.
- Issue Resolution – how problems and issues will be resolved.
- Roles and Responsibilities – who does what in the project team, in other groups, and among external stakeholders.
- Communication Processes – the forms and procedures for communicating.
- Decision-Making Processes – how things get decided and who is involved at each level.
- Strategy Alignment – guidelines for aligning project governance with organizational strategy.
- Project Life Cycle – which life cycle approach will be used.
- Review Processes – how increments, stage gates, or phases will be reviewed.
- Change Processes – how changes will be handled, including who is involved for review and approval of changes above the project manager’s authority.
- Stakeholder Alignment – the process to align internal stakeholders with project process requirements.
Governance Board (Project Board or Steering Committee)
Most projects of any size operate under a governance board, sometimes called a project board or steering committee. The board provides oversight and may include project sponsors, senior managers, and PMO resources. Their typical responsibilities include reviewing key deliverables, providing guidance for project decisions, and authorizing changes that exceed the project manager’s authority. Projects using Scrum or scaled frameworks such as SAFe often run an intermediary governance board between the team and organizational governance, so the team is shielded from oversight overhead while the business still gets the visibility it needs.
Guidelines for Determining Appropriate Governance
- Start with the right model – choose the most appropriate governance goals for the type of project, then keep them simple. A knowledge-work project with a high possibility of change suits an agile approach with everyone clear on the implications and roles. A well-understood and predictable domain suits a traditional life cycle.
- Be transparent – document and publicize the governance processes so they are visible to relevant stakeholders. Task boards and information radiators make work visible. Visual impediment lists, risk lists, and team calendars help show additional project information.
- Governance evolves – remember that governance is an evolutionary process. Phase gate reviews and retrospectives are good opportunities to discover what can be improved and instigate enhancements.
3.1.2 Define Success Metrics.
Governance is the structure for getting the right decisions made at the right level. Success metrics are how we measure whether those decisions are taking us where we said we were going. Without them, governance becomes paperwork and meetings. With them, the board has a basis for asking real questions and the team has a basis for showing real progress.
Project success has two dimensions, and useful governance metrics cover both:
- Project outcome success – how well the project realizes business value. This shows up in financial measures (revenue growth, return on investment) and non-financial measures (first to market, customer acquisition, process or technological improvements, environmental and social goals, compliance achievement).
- Project management process success – how well the project performed against its constraints (budget, scope, timeline, quality). This is the execution side, and it is what the project manager has the most direct influence over.
A project can succeed on one dimension and fail on the other. The Sydney Opera House was planned at AU$7 million over four years and finished at AU$102 million over fourteen years. As a feat of project management it was a clear failure. As a delivered outcome it became a UNESCO site and a global icon. The Montreal Overpass that was demolished after a year because the design did not match the bridge it was supposed to connect to is the opposite case: process failure that destroyed value delivery. Governance metrics need to look at both dimensions or they only see half the picture.
Selecting Useful Success Metrics
- Tie metrics to the agreed business case and benefits, not to whatever is easy to count.
- Define a small set of measures the board will actually look at. Long lists rarely get reviewed.
- Mix leading indicators (early signs of progress) with lagging indicators (confirmed outcomes).
- Set thresholds and tolerances so the board knows when a measure is heading off track.
- Confirm who owns each metric, how often it is reported, and where the data comes from.
3.1.3 Outline Governance Escalation Paths and Thresholds.
Don’t wait until there is an issue before discussing how to handle problems. People will be emotional and difficult to reason with or gain consensus among. This is why we create and gain agreement on fire evacuation plans before there is a fire. The same goes for handling project problems and breaches of agreed governance processes.
Two ideas sit at the heart of escalation: thresholds and tolerances. A threshold is a predetermined value of a measurable project variable that triggers action when reached. A tolerance is the quantified description of acceptable variation around a quality, risk, budget, or other project requirement. Together they tell the project manager when something can be handled inside the team and when it must go up the chain.
Phase Gates
Traditional projects are often divided into phases. After each phase there is typically a phase gate, also known as a governance gate, tollgate, or kill point. Phase gates are predetermined review points where a decision is made to:
- Continue to the next phase
- Continue with modification, or
- End the project or program
They are used to check if each phase has fulfilled the exit criteria and is eligible to move to the next step. Phase gates may review progress, spend, sponsor confidence, user feedback, and product quality. Reviews typically include sponsors, PMO members, or steering committee members. Rather than the project manager, these stakeholders get to decide if the project continues, gets modified, or stops. They act as gatekeepers and advisors at a level above the authority of the project manager.
Escalation in Practice
Issues and risks that occur during a phase should be escalated if they threaten the acceptance criteria for a phase gate. Be proactive; do not wait for the gate review to report a problem. First, try to address it within the project team. If that is not possible, escalate the issue and seek guidance from the PMO, program manager, or steering committee, whoever is assigned for escalated issues. The escalation rule is simple: if the issue is within tolerance, work with the team to find a resolution; if it is outside tolerance, escalate to the responsible stakeholder authorized to take action.
Governance is structured around phase gates and a defined Change Control Board. Decisions about scope, schedule, and budget changes above tolerance go to the board.
Every iteration demo functions as a mini governance review. The Product Owner has delegated authority to make most scope decisions; only changes that materially affect outcomes are escalated.
A lightweight set of release plans and tolerances is agreed upfront. The Product Owner manages day-to-day changes inside that envelope, and anything that threatens the envelope is escalated through traditional governance channels.
Deliverables and Tools
- Organizational Process Assets (OPAs) – The collective name for an organization’s procedures, processes, policies, templates, documentation, and knowledge bases used to run projects. Typically owned by the PMO.
- Governance Board (Project Board, Steering Committee) – A group of senior stakeholders, sponsors, and PMO representatives that provides oversight and decides changes outside the project manager’s authority.
- Project Management Office (PMO) – The organizational group that maintains standards, templates, and processes, and provides or supports project governance.
- Acceptance Criteria – The set of conditions a deliverable must satisfy before approval. A core governance component that defines what “done” means at each gate.
- Roles and Responsibilities – Documented description of who does what in the project team, in other groups, and among external stakeholders.
- Communication Processes – The forms and procedures used to share information, raise issues, and report status.
- Decision-Making Processes – The defined approach for how decisions are made and who is involved at each level.
- Change Processes – The governance-approved process for raising, evaluating, and approving changes, including the rules for who can approve at what level.
- Review Processes – The defined approach for reviewing increments, stage gates, or phases.
- Project Life Cycle Selection – The choice of predictive, agile, or hybrid life cycle for the project, made as part of establishing governance.
- Phase Gates (Governance Gates, Tollgates, Kill Points) – Predetermined review points where authorized decision-makers decide whether to continue, continue with modification, or stop the project.
- Thresholds and Tolerances – Predetermined trigger values and acceptable variation ranges that define when escalation is required.
- Success Metrics – Measures of project outcome (business value delivered) and project management process (performance against constraints). Useful governance metrics cover both.
- Leading and Lagging Indicators – Leading indicators give early signs of progress; lagging indicators confirm outcomes. A useful metric set mixes both.
- Information Radiators – Big visible charts such as task boards, impediment lists, risk lists, and team calendars that make governance information transparent.
Related Topics
- 1.3 Lead the project team
- 2.1 Develop an integrated project management plan and plan delivery
- 2.9 Evaluate project status
- 2.10 Manage project closure
- 3.2 Plan and manage project compliance
- 3.3 Manage and control changes
- 3.4 Remove impediments and manage issues
- 3.5 Plan and manage risk
- 3.6 Apply continuous improvement to processes
- 3.7 Support organizational change
FAQ
What is project governance?
The framework, functions, and processes that guide how the project is managed (PMI definition).
Does governance apply to agile teams?
Yes. The Product Owner deciding backlog priority and the team making its own estimates are examples of project governance at work.
Is governance about control?
Not control for its own sake. It defines how we are going to work and who decides what.
Congratulations! you earned the Project Governance Badge. 