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, Project Governance is our structure for working. It helps ensure everyone makes the right decisions.
To some people from the agile community, the word “Governance” sounds controlling. A little Big-Brother-ish, heavy on oversight and direction, but as we saw in the definition above, Governance just means “How we are going to work.” So if you are following Scrum or XP, you have already established a governance structure for your team and business representatives.
For example, we know that the Product Owner gets to decide what goes into the product backlog and the priority of work items. Likewise, it is the team that creates estimates and makes their own local decisions. These are examples of project governance at work.
2.14.1 Determine Appropriate Governance for a Project
(E.G., replicate organizational governance )
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.
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, make decisions, align with others, etc. The image below depicts some standard governance components.
- Acceptance Criteria – How will deliverables and project success be approved, and by who?
- Issue Resolution – How problems and issues will be resolved
- Roles and Responsibilities – Who does what in the project team, other groups, and external stakeholders
- Communication Processes – The forms and procedures for communicating
- Decision-Making Processes – How do things get decided, and who is involved at each level
- Strategy Alignment – Guidelines for aligning project governance and organizational strategy
- Project Life Cycle – Which life cycle approach will be used
- Review Processes – How will increment or stage-gate and phases 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
Guidelines to Determine Appropriate Governance for a Project
- Start with the right model – Generally, we should choose the most appropriate governance goals for our type of project and then try to keep them simple. So, if undertaking a knowledge work type project with a high possibility of change, we likely want to use an agile approach and make sure everyone understands the implications and roles involved. Or, in a well-understood and predictable domain, use a traditional life cycle.
- Be Transparent – We should also document and publicize our governance processes so they are transparent to all the relevant project stakeholders. We want to eliminate confusion or people not knowing what is going on. Task boards and information radiators make our work visible. People can see what we are working on, what is coming next and what has just been completed. Likewise, visual impediment lists, risk lists and team calendars help show additional project information.
- Governance evolves – remember that governance is an evolutionary process, and we should take advantage of the lessons learned as we execute the project. Phase gate reviews and retrospectives are great opportunities to discover what can be improved and instigate enhancements.
2.14.2 Define 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.
Traditional projects are often divided into phases. After each phase, there is typically a Phase Gate that is a review point. As shown below.
Phase gates (also known as governance gates, tollgates or kill points) 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. They may review many aspects of the project, including progress, spend, sponsor confidence, user feedback, and product quality.
Escalation
Phase gate reviews typically include sponsors, PMO 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 gatekeeps and advisors at a level above the authority of the PM. Issues and risks that occur during a phase should be escalated to this group if they threaten the acceptance criteria for a phase gate.
Be proactive, do not wait for the phase 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 your PMO, program manager or steering committee – whoever is assigned for escalated issues.
Phase Relationships
Most organizations use a sequential relationship between phases. Meaning subsequent phases only start when the previous phase is complete and passes the phase gate review. This reduces the risk and uncertainty levels but may reduce options for shortening a project’s schedule.
Some organizations use overlapping relationships between phases meaning they allow elements to run in parallel. This enables workstreams to occur simultaneously, reducing the project schedule. However, it increases the level of risk and may cause rework if something from the previous phase directly affects other currently executing to subsequent phases.
Applying Governance to the Project Life Cycle
When executing traditional life cycle projects, consider the following recommendations:
- At the beginning of a phase, check the assumptions and risks associated with the phase’s deliverables. Ask: Are they still valid? Has anything changed? Does it still look like we can successfully produce the required deliverables knowing what we do now, or do things need to change?
- After the phase’s deliverables are produced, review them to ensure completeness and acceptance. This will pre-empt any nasty surprises at the phase gate review. Be a harsh critic and look for reasons someone may object to passing the phase gate – then address any potential issues.
- Understand a phase can be closed or the project terminated when significant risks are discovered for the project or when the objectives are no longer required. While disheartening, this is actually a good thing. We need to stop pouring time, money and talent into bad ideas and instead divert them to more productive endeavors.
Agile Governance
Agile projects typically operate without phase gates, but similar governance is ever-present. Every Sprint/iteration demo is a mini phase gate review where the product owner and other stakeholders review and evaluate the project’s performance. They get to see the rate of progress and quality of the emerging deliverables while also learning about issues, budget consumed and likely completion dates.
As a result of the review, the product owner might reprioritize the product backlog, update the release roadmap or work with the Scrum Master and team to adjust plans or objectives. Hopefully, most of the time, the message is “Continue as you are,” but changes and even project termination are real options.
Most changes are handled by the Product Owner, who has been given autonomy to direct the project within the bounds of the charter. However, if issues, changes or general lack of progress threaten the planned benefits, the Product Owner will escalate concerns to a Product Manager, PMO or program manager similar to traditional projects to gain direction.
Hybrid Governance
Some organizations use a combination of traditional and agile governance models. They might start with a proof of concept followed by a review. Then if everything looks promising, approve agile development of the product or service.
Optionally, some organizations insert a review before final delivery. Maybe to ensure additional checks and assurances are performed prior to distribution. Perhaps to engage a larger group in the final acceptance.
As with all hybrid approaches, there are many ways of blending traditional and agile techniques together. (Whether they are needed, add value, or are inserted as an emotional or political crutch can be debated. Typically, organizations that use hybrid approaches have a valid reason for doing so, even if it is just easier than changing the surrounding mindset. )
Final Thoughts
Governance describes how project ecosystems work. While there is no single universally best model, making sure everyone understands the processes in play and having options to update them when necessary is universally beneficial.
Deliverables and Tools
- Identify governance structure
- Create an aligned project team
- Project change and configuration control
- Meetings
- Use organizational process assets
- PMIS
- Update documents
Related Topics
- 1.12 Define Team Ground Rules
- 2.9 Integrate Project Planning Activities
- 10 Manage 2.Project Changes
- 2.13 Determine Appropriate Project Methodology/Methods and Practices
- 2.16 Ensure Knowledge Transfer for Project Continuity
- 2.17 Plan and Manage Project/Phase Closure or Transitions
- 3.1 Plan and Manage Project Compliance
- 3.3 Evaluate and Address External Business Environment Changes
Further Reading
Congratulations! you earned the Project Governance Badge. Explore these topics via an interactive mind map. (Click the nodes to expand/collapse, drag to pan, scroll/pinch to zoom.)
