Get Instant Access
to This Blueprint

Applications icon

Create an Agile-Friendly Project Gating and Governance Approach

Use Info-Tech’s Agile Gating Framework as a guide to gating your Agile projects following a “trust but verify” approach.

  • Organizations often apply gating and governance to IT projects to ensure resources are being used efficiently and effectively.
  • Agile project teams often complain that traditional project gating and governance interfere with their ability to delivery because traditional gating and governance were designed for Waterfall delivery methods.

Our Advice

Critical Insight

Imposing a traditional gating and governance approach on an Agile project can eliminate the advantages that Agile delivery methods offer. Make sure to rework your traditional project gating and governance approach to be Agile friendly.

Impact and Result

  • Create a project gating and governance approach that is Agile friendly and helps your organization realize the most benefit from its Agile transformation.
  • Oversee your Agile projects with confidence by adjusting the level of support and oversight they receive based on their Agilometer score.
  • Define a revised set of project gating artifacts that support Agile delivery methods.
  • Adopt a “trust but verify” approach to Agile project gating that will reduce risk and help ensure value delivery.

Create an Agile-Friendly Project Gating and Governance Approach Research & Tools

1. Create an Agile-Friendly Project Gating and Governance Approach Deck – A step-by-step guide to creating an Agile-friendly project gating and governance approach that will support Agile delivery methods in your organization.

This deck is a guide to creating your own Agile-friendly project gating and governance approach using Info-Tech’s Agile Gating Framework.

2. Your Gates 3 and 3A Checklists – The Gates 3 and 3A Checklists are used to determine when a project is ready to enter and exit the Risk Reduction & Value Confirmation phase.

Modify Info-Tech’s Gates 3 and 3A Checklists to meet your organization’s needs, and then use them to determine when Agile projects are ready to enter and exit the RRVC phase.

3. Your Agilometer – The Agilometer is used to determine a project’s readiness to use an Agile delivery method.

Modify Info-Tech’s Agilometer to meet your organization’s needs, and then use it to determine the level of support and oversight the project will need.

4. Your Agile Project Status Report – An Agile Status Report will be used to monitor project progress.

Modify Info-Tech’s Agile Project Status Report to meet your organization’s needs, and then use it to monitor in-flight Agile projects.

5. Project Burndown Chart – A tool to let you monitor project burndown over time.

Use Info-Tech’s Project Burndown Chart to monitor the progress of your in-flight Agile projects.

6. Traditional to Agile Gating Artifact Mapping – A tool to help you rework your project gating artifacts to be Agile-friendly.

Use Info-Tech’s Traditional to Agile Gating Artifact Mapping tool to modify your gating artifacts for Agile projects.


Create an Agile-Friendly Project Gating and Governance Approach

Use Info-Tech’s Agile Gating Framework as a guide to gating your Agile projects using a “trust but verify” approach.

Table of Contents

Analyst Perspective

Executive Summary

Phase 1: Establish Your Gating and Governance Purpose

Phase 2: Understand and Adapt Info-Tech’s Agile Gating Framework

Phase 3: Complete Your Agile Gating Framework

Where Do I Go Next?

Bibliography

Facilitator Slides

Analyst Perspective

Make your gating and governance process Agile friendly by following a “trust but verify” approach

Most project gating and governance approaches are designed for traditional (Waterfall) delivery methods. However, Agile delivery methods call for a different way of working that doesn’t align well with these approaches.

Applying traditional project gating and governance to Agile projects is like trying to fit a square peg in a round hole. Not only will it make Agile project delivery less efficient, but in the extreme, it can lead to outright project failure and even derail your organization’s Agile transformation.

If you want Agile to successfully take root in your organization, be prepared to rethink your current gating and governance practices. This document presents a framework that you can use to rework your approach to provide both effective oversight and support for your Agile projects.

Photo of Alex Ciraco, Principal Research Director, Application Delivery and Management, Info-Tech Research Group. Alex Ciraco
Principal Research Director,
Application Delivery and Management
Info-Tech Research Group

Executive Summary

Your Challenge
  • Many government organizations are adopting Agile project delivery methods because they have proven to be more effective than traditional delivery approaches at responding to today’s fast pace of change.
  • Government organizations have an obligation to govern projects to ensure effective use of public resources, regardless of the delivery method being used.
Common Obstacles
  • Most government gating and governance frameworks were designed around traditional (often called “Waterfall”) delivery methods.
  • Agile and Waterfall work in completely different ways, so imposing traditional gating and governance frameworks on Agile projects will stifle progress and can even lead to project failure.
  • Government organizations must adjust their gating and governance frameworks to accommodate Agile delivery methods.
Info-Tech’s Approach
  • Begin by understanding the fundamental purpose of project gating and governance.
  • Next, understand the major differences between Agile and Waterfall delivery methods.
  • Then, armed with this knowledge, use Info-Tech’s Agile Gating Framework to redefine your gating and governance approach to be Agile friendly.
Info-Tech Insight

Imposing a traditional governance approach on an Agile project can eliminate the advantages that Agile delivery methods offer. Make sure to rework your project gating and governance approach to be Agile friendly.

Info-Tech’s methodology for Creating an Agile-Friendly Project Gating and Governance Approach

1. Establish Your Gating and Governance Purpose 2. Understand and Adapt Info-Tech’s Agile Gating Framework 3. Complete your Agile Gating Framework
Phase Steps

1.1 Understand How We Gate and Govern Projects

1.2 Compare Traditional to Agile Delivery

1.3 Realize What Traditional Gating Looks Like and Why

2.1 Understand How Agile Manages Risk and Ensures Value Delivery

2.2 Introducing Info-Tech’s Agile Gating Framework

2.3 Create Your Agilometer

2.4 Create an Agile-Friendly Project Status Report

2.5 Select Your Agile Health Check Tool

3.1 Map Your Traditional Gating Artifacts to Agile Delivery

3.2 Determine Your Now, Next, Later Roadmap for Implementation

Phase Outcomes
  1. Your gating/governance purpose statement
  2. A fundamental understanding of the difference between traditional and Agile delivery methods.
  1. An understanding of Info-Tech’s Agile Gating Framework
  2. Your Gates 3 and 3A checklists
  3. Your Agilometer tool
  4. Your Agile project status report template
  5. Your Agile health check tool
  1. Artifact map for your Agile gating framework
  2. Roadmap for Agile gating implementation

Key Deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals, including:

Agilometer Tool

Create your customized Agilometer tool to determine project support and oversight needs.
Sample of the 'Agilometer Tool' deliverable.

Gates 3 and 3A Checklists

Create your customized checklists for projects at Gates 3 and 3A.
Sample of the 'Gates 3 and 3A Checklists' deliverable.

Agile-Friendly Project Status Report

Create your Agile-friendly project status report to monitor progress.
Sample of the 'Agile-Friendly Project Status Report' deliverable.

Artifact Mapping Tool

Map your traditional gating artifacts to their Agile replacements.
Sample of the 'Artifact Mapping Tool' deliverable.

Create an Agile-Friendly Project Gating and Governance Approach

Phase 1

Establish your gating and governance purpose

Phase 1

1.1 Understand How We Gate and Govern Projects

1.2 Compare Traditional to Agile Delivery

1.3 Realize What Traditional Gating Looks Like And Why

Phase 2

2.1 Understand How Agile Manages Risk and Ensures Value Delivery

2.2 Introducing Info-Tech’s Agile Gating Framework

2.3 Create Your Agilometer

2.4 Create Your Agile-Friendly Project Status Report

2.5 Select Your Agile Health Check Tool

Phase 3

3.1 Map Your Traditional Gating Artifacts to Agile Delivery

3.2 Determine Your Now, Next, Later Roadmap for Implementation

This phase will walk you through the following activities:

  • Understand why gating and governance are so important to your organization.
  • Compare and contrast traditional to Agile delivery.
  • Identify what form traditional gating takes in your organization.

This phase involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Agile gating–related facts and figures

73% of organizations created their project gating framework before adopting or considering Agile delivery practices. (Athens Journal of Technology and Engineering)

71% of survey respondents felt an Agile-friendly gating approach improves both productivity and product quality. (Athens Journal of Technology and Engineering)

Moving to an Agile-friendly gating approach has many benefits:
  • Faster response to change
  • Improved productivity
  • Higher team morale
  • Better product quality
  • Faster releases
(Journal of Product Innovation Management)

Traditional gating approaches can undermine an Agile project

  • Most existing gating and governance frameworks (often referred to as phase-gate) impose requirements on projects that are anti-patterns to an Agile delivery approach
  • For example, any gating approach that requires a project to deliver a detailed requirements document before coding can begin will make it difficult or impossible for the project to use an Agile delivery method.
  • The same can be said for other common phase-gate requirements including:
    • Imposing a formal (and onerous) change control process on project requirements.
    • Requiring a detailed design document and/or detailed user acceptance test plan at the beginning of the project.
    • Asking the project to produce a detailed project plan.
(DZone)
Don’t make the mistake of asking an Agile project to follow a traditional phase-gate approach to project delivery!

Before reworking your gating approach, you need to consider two important questions

Answering these questions will help guide your new gating process to both be Agile friendly and meet your organization’s needs

  1. What is the fundamental purpose of gating? By examining the fundamental purpose of gating, you will be better able to adjust your approach to achieve the desired outcomes in an Agile context.
  2. How does Agile delivery differ from traditional? By understanding how Agile delivery differs from traditional, you will be better able to adjust your gating approach to support Agile delivery methods.

Stock image of speech bubbles hanging on string with a question mark and lightbulb drawn on them.

Step 1.1

Understand How We Gate and Govern Projects

Activities
  • 1.1.1 Understand the Fundamental Purpose of Gating and Governance
  • 1.1.2 Create Your Gating and Governance Purpose Statement

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • A clear understanding of why we need gating and governance.
  • Defined purpose for gating and governance in your terms.
Establish Your Gating and Governance Purpose
Step 1.1 Step 1.2 Step 1.3

Exercise 1.1.1 Understand the fundamental purpose of gating and governance

Output: A better understanding of why your organization uses gating/governance

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Why do we gate/govern projects? (5-10 minutes)
  • As a group, discuss and capture your thoughts on:
    • What is the fundamental purpose of gating and governance?
    • Why do we bother gating projects?
    • What outcomes are we trying to achieve by gating projects?
Capture your findings in the table below:

Table titled 'Why do we gate/govern projects?' with a note '(e.g. make go/no-go decisions, mitigate project risks, keep projects on course, get project funding, ensure promised outcomes are delivered.)'.

Exercise 1.1.2 Create your gating and governance purpose statement

Output: Your gating/ governance purpose statement

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Create your gating/governance purpose statement (5-10 minutes)

Considering your findings from Exercise 1.1.1, make any needed adjustments to the statement below and create your organization’s gating/governance purpose statement:

Our Gating/Governance Purpose Statement:

The fundamental purpose of project governance and gating is to ensure that the organization acts as a good steward of public resources, and it does so by providing oversight that encourages projects to:

  1. Manage risk effectively.
  2. Ensure (strategy-aligned) value delivery.

Info-Tech Insight

For most government organizations, the fundamental purpose of governance is to ensure public resources are spent wisely, efficiently, and effectively.

Step 1.2

Compare Traditional to Agile Delivery

Activities
  • 1.2.1 Consider two teams and how you would train/coach each
  • 1.2.2 Consider how you would govern each team

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • An understanding of some of the key differences between the traditional and Agile software development lifecycle.
  • Start understanding what is necessary to train, coach, and govern traditional and Agile teams.

Establish your gating and governance purpose

Step 1.1 Step 1.2 Step 1.3

Traditional/Waterfall software development lifecycle (SDLC)

With many siloes and handoffs, valuable functionality is delivered only at the end of an extended project lifecycle

Diagram of the Traditional/Waterfall software development lifecycle (SDLC) consisting of multiple silos 'Siloed Responsibility', and a process beginning with 'One-time intake of business need' and ending in 'Hand-off via documents' from each silo. ''One and Done' Approach'.

Agile SDLC

With shared ownership instead of siloes, you can deliver value at the end of every iteration (aka sprint)

Diagram of Agile SDLC.
There are many Agile methodologies to choose from, but Scrum is by far the most widely used (and is shown above).

Key Elements of the Agile SDLC
  • Is not “one-and-done”: There are many short iterations with constant feedback.
  • Has an empowered product owner: This is a single authoritative voice that represents stakeholders.
  • Has a fluid product backlog: This enables prioritization of requirements “just in time.”
  • Has a cross-functional, self-managing team: This team makes commitments and is empowered by the organization to do so.
  • Has working, tested code at the end of each sprint: Value becomes more deterministic along sprint boundaries.
  • Is demonstrated to stakeholders: Allow them to see and use the functionality and provide necessary feedback.
  • Involves feedback continuously injected back into the product backlog: This shapes the future of the solution.
  • Enables continuous improvement through sprint retrospectives.
  • Is “internally governed” when done right (the virtuous cycle of sprint-demo-feedback).

Exercise 1.2.1 Consider two teams and how you would train/coach each

Output: An understanding of differing team needs based on the way they work together

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Discussion (5-10 minutes)

A picture of two relay racers labelled 'Team 1' and an army squadron carrying logs labelled 'Team 2'. The space beside them is titled 'Discuss the differences between these teams and how you would train/coach/manage each:'
Image Credit: dvids

Exercise 1.2.2 Consider how you would govern each team

Output: A better understanding of the different governance/gating needs of traditional and Agile delivery

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Discussion (5-10 minutes)

The same two teams filled in with roles, mantras, and tasks. The space beside them is titled 'Discuss differences between these teams, and how you would govern each:'
Image Credit: dvids

Step 1.3

Realize What Traditional Gating Looks Like and Why

Activities
  • 1.3.1 Capture your current gating approach (Optional)
  • 1.3.2 Consider what happens if you impose traditional gating on an Agile project (Optional)

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • An understanding of how most gating approaches are designed for traditional delivery.
  • An understanding of the impact of traditional gating on Agile teams.

Establish your gating and governance purpose

Step 1.1 Step 1.2 Step 1.3

Question: Why do traditional gating processes usually look like this?

Traditional gating approaches are typically linear in nature

1

2

3

4

5

6

GATE 1: Sponsorship Commitment 2: Concept Approval 3: Project Initiation & Planning 4: Project Execution & Quality 5: Project Deployment & Closure 6: Project Outcomes Reporting
ARTIFACTS
  • Concept Case
  • Business Case
  • Project Charter
  • High-Level Business Requirements
  • Resource Plan
  • Detailed Requirements Doc
  • Detailed Design Doc
  • Detailed Test Plan
  • Detailed Project Plan
Monthly Status Rep
  • UAT Test Sign-Off
  • Threat Risk Assessment
  • Privacy Impact Assessment
  • Deployment Plan
  • Change Advisory Board (CAB) Approval/ Authority To Operate
  • Closeout & Lessons Learned
Monthly Status Rep
  • Verify Value Delivery

Answer: Because that is how Waterfall tries to reduce risk and ensure value delivery

1

2

3

4

5

6

GATE1: Sponsorship Commitment2: Concept Approval3: Project Initiation & Planning4: Project Execution & Quality5: Project Deployment & Closure6: Project Outcomes Reporting
Team 1 from the previous slides. The first relay runner is labelled 'Business Analyst (BA)' and is handing off 'Requirements' to the second runner 'Architect (Arch)', and the title is 'Trust the Process'.
  • Linear approach
  • Prescriptive oversight
  • Relies on documents and “sign-offs"
  • Encourages siloes and handoffs (“trusts the process”)
  • Uses top-down control and oversight
  • Encourages siloed thinking and a linear approach
  • Evidence of value delivery is only seen at the end
  • Governance body “owns” the risk

(Waterfall uses siloes and documentation to “reduce risk” and “ensure value delivery”)

The problem is…

It turns out Waterfall is not that great at reducing risk and ensuring value delivery after all

Table titled 'CHAOS RESOLUTION BY AGILE VERSUS WATERFALL' with a comparison of 'Successful', 'Challenged', and 'Failed' projects using either 'Method'.
(The Standish Group)
“I believe in this concept, but the implementation described above is risky and invites failure.” (Winston W. Royce)

Exercise 1.3.1 (Optional) Capture your current gating approach

Output: Capture your current gating approach, including the artifacts asked for at each gate

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Exercise (30 minutes)

  1. Modify the model below to reflect your current gating approach.

1

2

3

4

5

6

GATE 1: Sponsorship Commitment 2: Concept Approval 3: Project Initiation & Planning 4: Project Execution & Quality 5: Project Deployment & Closure 6: Project Outcomes Reporting
ARTIFACTS
  • Concept Case
  • Business Case
  • Project Charter
  • High-Level Business Requirements
  • Resource Plan
  • Detailed Requirements Doc
  • Detailed Design Doc
  • Detailed Test Plan
  • Detailed Project Plan
Monthly Status Rep
  • UAT Test Sign-Off
  • Threat Risk Assessment
  • Privacy Impact Assessment
  • Deployment Plan
  • Change Advisory Board (CAB) Approval/ Authority To Operate
  • Closeout & Lessons Learned
Monthly Status Rep
  • Verify Value Delivery

Exercise 1.3.2 (Optional) Consider what happens if you impose traditional gating on an Agile project

Output: A better understanding of why not to impose traditional gating on Agile projects

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Discussion (5-10 minutes)

1

2

3

4

5

6

GATE1: Sponsorship Commitment2: Concept Approval3: Project Initiation & Planning4: Project Execution & Quality5: Project Deployment & Closure6: Project Outcomes Reporting

Team 2 from the previous slides. The individual squad members are labelled with company positions, the log is labelled 'Reduce Risk & Ensure Value Delivery' and the title is 'Trust the Team (Assign Ownership)'. A question beside the picture reads 'What impact will traditional gating have on Agile?'
Image Credit: dvids

Create an Agile-Friendly Project Gating and Governance Approach

Phase 2

Understand and Adapt Info-Tech’s Agile Gating Framework

Phase 1

1.1 Understand How We Gate and Govern Projects

1.2 Compare Traditional to Agile Delivery

1.3 Realize What Traditional Gating Looks Like And Why

Phase 2

2.1 Understand How Agile Manages Risk and Ensures Value Delivery

2.2 Introducing Info-Tech’s Agile Gating Framework

2.3 Create Your Agilometer

2.4 Create Your Agile-Friendly Project Status Report

2.5 Select Your Agile Health Check Tool

Phase 3

3.1 Map Your Traditional Gating Artifacts to Agile Delivery

3.2 Determine Your Now, Next, Later Roadmap for Implementation

This phase will walk you through the following activities:

  • Understand how to rework gating to be Agile friendly
  • Introducing Info-Tech’s Agile Gating Framework
  • Create your Gates 3 and 3A checklists
  • Create your Agilometer
  • Create an Agile-friendly project status report
  • Select your Agile health check tool

This phase involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Step 2.1

Understand How Agile Manages Risk and Ensures Value Delivery

Activities
  • 2.1.1 Understand how Agile projects can “self-govern”

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • An understanding of how Agile practices reduce risk and ensure value delivery, enabling projects to be largely self-governed

Understand and Adapt Info-Tech’s Agile Gating Framework

Step 2.1 Step 2.2 Step 2.3 Step 2.4 Step 2.5

Exercise 2.1.1 Understand how Agile projects can “self-govern”

Output: A better understanding of how Agile projects can largely govern themselves

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Review the insight below and discuss how Agile practices can intrinsically reduce risk and ensure value delivery (5-10 minutes)

Agile delivery teams can largely govern themselves to reduce risk and ensure value delivery by doing these three things:

  1. Working directly with an engaged product owner and stakeholders instead of through documents.
  2. Working in short iterations (e.g. sprints) instead of taking a “one-and-done” approach.
  3. Showing their work regularly (i.e. demonstrate working/tested code at the end of each sprint and be sure to get stakeholder feedback).

Diagram of Agile SDLC.

Empty field titled 'Discussion'.

The Agile gating mindset

Icon of a checklist. Project gating/governance doesn’t go away in Agile, but more of it rests with the delivery team rather than with a governance body.
Icon of a handshake. Agile-friendly gating/governance needs to support Agile delivery teams so they make good decisions over time.
Icon of a heartbeat. Your Agile gating framework should focus on ensuring delivery team health and effectiveness.

(A healthy and effective Agile delivery team will manage risk and ensure value delivery with minimal oversight.)

Stock image of shining arrows flying upward.

Step 2.2

Introducing Info-Tech’s Agile Gating Framework

Activities
  • 2.2.1 Create Your Gates 3 and 3A Checklists

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • An understanding of Info-Tech’s Agile Gating Framework
  • Your Gates 3 and 3A checklists

Understand and Adapt Info-Tech’s Agile Gating Framework

Step 2.1 Step 2.2 Step 2.3 Step 2.4 Step 2.5

Info-Tech’s Agile Gating Framework: Introduction

What it is

  • A guide to making your gating and governance more Agile friendly
  • A framework you can modify and make your own
  • A starting point that you build on (provides ideas, options, and examples)
  • (For simplicity) focused just on Agile team maturity

What it isn't

  • A prescriptive approach on how to get to a final model
  • A complete and final model you would follow “out of the box”

Info-Tech Insight

This framework is meant to be a starting point for Agile gating. You may need to extend the framework to reflect different project “tiers” (e.g. based on size, complexity, and risk).

Stock image of three scribbled checkboxes.

Info-Tech’s Agile Gating Framework

Info-Tech Note

Artifacts in bold are new as part of the Agile gating framework compared to your previous linear gating steps.

Top of the Agile Gating Framework table.

1

2

3

3A

4

5

6

GATE1: Opportunity2: Concept Approval3: Preliminary Approval3A: Full Project Approval4: Project Execution & Quality5: Project Deployment & Closure6: Project Outcomes Reporting
ARTIFACTS
  • Concept Case
  • Business Case
  • Project Charter
  • High-Level Business Requirements
  • Resource Plan
  • Agilometer
  • Gating Oversight Level Decision
  • Cost and Timeline for RRVC (precise) and FPD (ballpark)
  • Gate 3 Checklist (including RRVC Backlog)

Agile Status Report

  • Gate 3A Checklist
  • Go/Repeat/Hold/ Terminate Decision
  • Agile Health Check

Agile Status Report

  • UAT Test Sign-Off
  • Threat Risk Assessment (Final)
  • Privacy Impact Assessment (Final)
  • Deployment Plan
  • Detailed Design Document

Agile Status Report

  • CAB Approval/Authority To Operate
  • Closeout & Lessons Learned

Agile Status Report

  • Verify Value Delivery
PHASEPRE-KICKOFF
Similar to linear gating steps
RISK REDUCTION & VALUE CONFIRMATION (RRVC)
Deliver RRVC MVP before full project approval
FULL DELIVERY
Complete and deliver remainder of project

See Framework Facilitator Slides for more details

The RRVC phase is core to “trust but verify”

Icon of a checklist. Based on the Agilometer outcome, provide the right level of support and oversight for the project.
Icon of a handshake. Trust the project team to deliver a working subset (e.g. 10% to 25%) of the solution during the RRVC phase to prove their ability to successfully use an Agile delivery method.
Icon of a checkmark. Assess project health at end of RRVC phase to determine approval for the remainder of the project.
See RRVC Phase Facilitator Slide for more details
  • Not all Agile project delivery teams are created equal.
  • Adjust the level of support each project receives to improve its likelihood of success.
  • Give Agile delivery teams the freedom they need to prove themselves during the Risk Reduction and Value Confirmation (RRVC) phase.
  • Limit how much of the solution will be delivered in RRVC and monitor burndown.
  • Verify successful delivery of RRVC phase before approval of Full Project Delivery (FPD) phase.

Exercise 2.2.1 Create your Gates 3 and 3A checklists

Output: Your Gate 3 and Gate 3A checklists

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Download and review the sample checklists for Gates 3 and 3A and modify them to suit your needs (15-30 minutes)

Follow the instructions in Info-Tech’s Gates 3 and 3A Checklists tool to modify them as needed to suit your organization’s needs.

Sample of the Gates 3 and 3A Checklists tool.

Download Info-Tech’s Gates 3 and 3A Checklists

Proceed/Repeat/Hold/Terminate Decision at Gate 3A

Icon of . Go/Proceed to FPD Stage The project has successfully completed the RRVC stage and proven its ability to work effectively using Agile. Project stakeholders see value in what has been delivered to date and are prepared to continue working with the delivery team on the remainder of the project. The delivery team has adjusted their plan (scope, cost, and timeline) for Full Project Delivery based on their learnings from the RRVC. The project is approved to move forward to the Full Project Delivery stage.
Icon of . Repeat RRVC Stage The project has completed the RRVC stage, but there are reasons for not approving the project for Full Project Delivery at this time (e.g. a significant new risk has been uncovered or the delivery team is still struggling with Agile). It is agreed that the best path forward for the project is to complete another RRVC stage to address these issues before being approved for Full Project Delivery. The scope of this RRVC repeat is decided upon before starting.
Icon of . Put on Hold The project has not successfully completed the RRVC stage for one or more reasons that must be addressed before the project is considered ready to proceed. The project will be put on hold until these issues have been addressed. The project will come back to Gate 3A once this has happened.
Icon of . Terminate Over the course of the RRVC stage, the delivery team and stakeholders have come to realize that the expected benefits of the project are unlikely to be achieved or circumstances have changed in a way that makes the project unnecessary. The best path forward for the organization is to terminate the project.

Step 2.3

Create Your Agilometer

Activities
  • 2.3.1 Create Your Custom Agilometer Tool

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • An understanding that not all Agile teams are created equal.
  • A custom Agilometer tool to assess Agile project team maturity and determine the level of support and oversight required.

Understand and Adapt Info-Tech’s Agile Gating Framework

Step 2.1 Step 2.2 Step 2.3 Step 2.4 Step 2.5
Info-Tech’s Agilometer Outcomes
Color-coded Agilometer Outcomes: Green - 'Run (Self Oversight)', Yellow - 'Walk (Encourage Consistency)', Bright Orange - 'Crawl (Needs Support)', Dark Orange - 'Pre-Crawl (Not Ready)'.

Agilometer Approach

  • Examine the project on three primary dimensions:
    • Project risk
    • Potential showstoppers
    • Agile readiness–related criteria (project/org, team, PO, SM, etc.)
  • Score the project on each of these dimensions to determine the project’s Agilometer outcome (Run, Walk, Crawl, or Pre-Crawl).
  • Use the Agilometer outcome to decide on the level of support and oversight the project should/will receive.

Adjust the level of support and governance oversight for each project based on the Agilometer outcome

Info-Tech’s Agilometer Outcomes

Color-coded Agilometer Outcomes: Green - 'Run (Self Oversight)', Yellow - 'Walk (Encourage Consistency)', Bright Orange - 'Crawl (Needs Support)', Dark Orange - 'Pre-Crawl (Not Ready)'. A note pointing to a line above Pre-Crawl reads 'You must be “this tall” to start an Agile project'.

Info-Tech’s Agile Gating Approach

Two scales that get wider from top to bottom titled 'Level of Support Provided' and 'Level of Gov. Oversight Required'. Levels 'LOW', 'MED', and 'HIGH' correspond to the adjacent Outcomes and have a list of requirements for each approach.
Take a “time out”
Identify and address root causes (e.g. training, coaching, executive support, assigning proxies, and/or other interventions)
OR go back to traditional delivery

Exercise 2.3.1 Create your custom Agilometer Tool

Output: An Agilometer tool that is customized to your organization’s needs

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Customize Info-Tech’s Agilometer to reflect your organization’s needs (1-2 hours)

Follow the instructions in Info-Tech’s Agilometer tool to modify the questions and calculations to suit your organization’s needs.

Sample of the Agilometer tool.

Download Info-Tech’s Agilometer tool

Step 2.4

Create an Agile-Friendly Project Status Report

Activities
  • 2.4.1 Adopt an Agile-Friendly Project Status Report

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • Your Agile-friendly project status report template

Understand and Adapt Info-Tech’s Agile Gating Framework

Step 2.1 Step 2.2 Step 2.3 Step 2.4 Step 2.5

Use an Agile project status report to monitor progress

  • Project status reports play an important role in monitoring project progress.
  • But Agile’s “different way of working” means that traditional project status reports aren’t appropriate.
  • Avoid the temptation to use a “traditional” project status report for Agile projects.
  • Instead, start with Info-Tech’s Agile Project Status Report template and adapt it to your needs.
Stock image of paper planes.

Exercise 2.4.1 Adopt an Agile-friendly project status report

Output: An Agile-friendly project status report template that is customized to your organization’s needs

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Customize Info-Tech’s Agile Project Status Report to reflect your needs (20 minutes)

Download, review, and modify Info-Tech’s Agile Project Status Report and Project Burndown Chart templates to suit your organization’s needs.

Samples of the Agile Project Status Report and the Project Burndown Chart.

Download Info-Tech’s Agile Project Status Report template

Download Info-Tech’s Project Burndown Chart template

Step 2.5

Select Your Agile Health Check Tool

Activities
  • 2.5.1 Select Your Agile Health Check Tool

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • Your Agile health check tool

Understand and Adapt Info-Tech’s Agile Gating Framework

Step 2.1 Step 2.2 Step 2.3 Step 2.4 Step 2.5

Exercise 2.5.1 Select your Agile health check tool

Output: An Agile health check tool that meets your organization’s needs

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Review and select the Agile health check tool that meets your needs (30 minutes)

Don’t re-invent the wheel! There are many existing Agile health check tools available. Pick the one that serves you best or create your own. Review and discuss the options below to select the Agile health check approach that bests suit your organization’s needs, then use your Agile health check tool to assess project health and identify and address problem areas:

Create an Agile-Friendly Project Gating and Governance Approach

Phase 3

Complete Your Agile Gating Framework

Phase 1

1.1 Understand How We Gate and Govern Projects

1.2 Compare Traditional to Agile Delivery

1.3 Realize What Traditional Gating Looks Like And Why

Phase 2

2.1 Understand How Agile Manages Risk and Ensures Value Delivery

2.2 Introducing Info-Tech’s Agile Gating Framework

2.3 Create Your Agilometer

2.4 Create Your Agile-Friendly Project Status Report

2.5 Select Your Agile Health Check Tool

Phase 3

3.1 Map Your Traditional Gating Artifacts to Agile Delivery

3.2 Determine Your Now, Next, Later Roadmap for Implementation

This phase will walk you through the following activities:

  • Map your traditional gating artifacts to Agile delivery
  • Understand what comes now, next, and later

This phase involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Step 3.1

Map Your Traditional Gating Artifacts to Agile Delivery

Activities
  • 3.1.1 Map Your Traditional Gating Artifacts to Agile Delivery

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • A revised set of gating artifacts that are Agile friendly

Understand and Adapt Info-Tech’s Agile Gating Framework

Step 3.1 Step 3.2

Exercise 3.1.1 Map your traditional gating artifacts to Agile delivery

Output: Your Agile gating artifacts mapped to the appropriate gates

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Decide whether to keep, move, eliminate, or replace each of your traditional gating artifacts for Agile projects (1-2 hours)

Remember that many of your traditional gating artifacts aren’t appropriate for Agile projects. Download Info-Tech’s Traditional to Agile Gating Artifact Mapping tool, and for each of your traditional gating artifacts, decide how to map them to your Agile gating framework from the options below (use the examples in the Tool as your starting point):

  • Keep as is (or with minor changes)
  • Move to a different gate
  • Eliminate and replace with an equivalent Agile artifact
  • Eliminate completely (i.e. the artifact is not needed for Agile)
  • Turn into an incremental deliverable
  • Other (define a different option)
Sample of the Traditional to Agile Gating Artifact Mapping tool.

Download Info-Tech’s Traditional to Agile Gating Artifact Mapping tool

Step 3.2

Determine Your Now, Next, Later Roadmap for Implementation

Activities
  • 3.2.1 Define Your Now, Next, Later Roadmap for Agile Gating

This step involves the following participants:

  • PMO/Gating Body
  • Delivery Managers
  • Delivery Teams
  • Other Interested Parties

Outcomes of this step

  • Your now, next, later roadmap for rolling out your Agile-friendly project gating framework

Understand and Adapt Info-Tech’s Agile Gating Framework

Step 3.1 Step 3.2

Exercise 3.2.1 Define your now, next, later roadmap for Agile gating

Output: A roadmap and timeline for completing and rolling out your Agile gating framework

Participants: PMO/Gating Body, Delivery Managers, Delivery Teams, Other Interested Parties

Decide the next steps you need to take to fully define and roll out your Agile gating framework, along with owners and timelines for each (30 minutes)

Fill in the table below with your next steps. Identify who will be responsible for each step along with the timeline for completion (“Now” refers to steps you will take in the immediate future (e.g. days to weeks), “Next” refers to steps you will take in the medium term (e.g. weeks to months), and “Later” refers to long-term items (e.g. months to years):

What are you going to do now? Now What are you going to do very soon? Next What are you going to do in the future? Later
Roadmap Item Who Date Roadmap Item Who Date Roadmap Item Who Date
Finalize your Agile gating artifacts AC Jan 1 Project governance body to approve use of Agile gating framework on a pilot basis DL Feb 15 Project governance body to approve updated Agile gating framework for general use DL Jul 15
Identify pilot project(s) for first use of Agile gating framework JK Jan 15 Run pilot Agile gating project(s) AJ Mar 1- Jun 30
Gather lessons learned from Agile gating pilots and incorporate into framework AJ Jun 15

Where do I go next?

Make Your IT Governance Adaptable
  • Identify your governance needs, select and refine your governance model, and embed and automate governance decisions.
Agile/DevOps Research Center
  • Visit Info-Tech’s Agile/DevOps Research Center to find the information you are looking for on Agile/DevOps.
Deliver on Your Digital Product Vision
  • Create a roadmap that suits your objectives, the characteristics of your product, and the environment it lives in.
Extend Agile Practices Beyond IT
  • Further the benefits of Agile by extending a scaled Agile framework to the business.
Tailor IT Project Management Processes to Fit Your Projects
  • Right-size PMBOK for all of your IT projects.
Drive Business Value With a Right-Sized Project Gating Process
  • Use gating to get projects done right the first time.
Implement Agile Practices That Work
  • Improve collaboration and transparency with the business to minimize project failure.
Spread Best Practices With an Agile Center of Excellence
  • Facilitate ongoing alignment between Agile teams and the business with a set of targeted service offerings.

Bibliography

“[2022 UPDATE] A Review of Modern Agile Assessment Tools.” Vitality Chicago Inc., 28 Feb. 2022. Web.

“2021 Business Agility Report: Rising to the Challenge.” Business Agility, 2021. Accessed 13 June 2022.

“Capabilities.” Comparative Agility, n.d. Accessed 11 June 2022.

“Chaos Report 2015.” The Standish Group, 2015. Accessed 29 July 2022.

Cohn, Mike. “Incorporating Governance or Oversight into an Agile Project.” Mountain Goat Blog, 11 Dec. 2018. Web.

Cooper, Robert, and Anita Sommer. “The Agile–Stage-Gate Hybrid Model: A Promising New Approach and a New Research Opportunity.” Journal of Product Innovation Management, vol 33, no. 5, Sept. 2016, pp. 513-526.

Cox, Ali. “Not Your Average Maturity Model.” Netmind, 13 Jan. 2021. Web.

Eljayar, Ali. “Agile-Stage-Gate Approach: Exploratory Research on the Structure, Roles, and Responsibilities.” Athens Journal of Technology and Engineering, Volume 8, Issue 1, March 2021.

“Governance Principles for Agile Service Delivery.” GOV.UK, 23 May 2016. Accessed 26 May 2022.

Ivory, Hugh. “Doing the Right Things in the Right Way: Agile Governance at the Home Office.” Digital Transformation, 11 Dec. 2014. Accessed 26 May 2022.

Paluch, Stefanie, et al. “Stage-Gate and Agile Development in the Digital Age: Promises, Perils, and Boundary Conditions.” Journal of Business Research, vol. 110, Mar. 2020, pp. 495-501. Web.

PRINCE2 Agile® Wiki. https://prince2agile.wiki/. Accessed 26 May 2022.

Sommer, Anita Friis, et al. “Improved Product Development Performance through Agile/Stage-Gate Hybrids: The Next-Generation Stage-Gate Process?” Research-Technology Management, vol. 58, no. 1, Jan. 2015, pp. 34-45. Web.

“TeamHealth Radar Assessment.” AgilityHealth, n.d. Accessed 13 June 2022.

“What Is Agile Stage-Gate?” Planisware, 2022. Accessed 6 June 2022.

Wolpers, Stefan. “Agile Management Anti-Patterns — An Introduction.” DZone, 11 Sept. 2018. Accessed 18 Aug. 2022.

INFO~TECH RESEARCH GROUP

Facilitator Slides

Facilitator Slides: More on Info-Tech’s Agile Gating Framework

Consider and discuss the following aspects of the Framework:

  1. Gating Philosophy
  2. Issue/Risk Management Philosophy
  3. Decision-Making Approach
  4. Change Management Approach
  5. Status-Reporting Approach
  6. Documentation Approach

Facilitator Slides

1. Gating Philosophy

  • De-emphasize artifacts and documentation in favor of demonstrating working code regularly over the project duration and ensuring stakeholder involvement in the project.
  • Focus on creating an empowered, self-managing, cross-functional delivery team with strong ties to stakeholders, and then look for tangible proof that the team is working effectively over time (e.g. is effectively managing a backlog; demonstrating working, tested code on a regular basis; and incorporating stakeholder feedback into future work).
  • Follow a “risk a little before risking a lot approach” to gating and governance (avoid Waterfall’s tendency to discover unpleasant facts late in the project lifecycle). This is the fundamental reasoning behind the Gate 3/3A cycle (despite your best efforts to make any IT project successful, stuff goes wrong sometimes, and it is better to find out early while there is still time to adjust or even bail out if it turns out the project was just a bad idea).
  • Use your Agilometer to gauge the project’s readiness for Agile delivery and to determine the level of gating/governance support and oversight the project will need.
  • Rework the list of artifacts you will be using at each gate (avoid using the “traditional” gating artifacts, except those that are already aligned with an Agile delivery). This typically involves eliminating or reworking some of your “traditional” gating artifacts/documents.
  • Make sure you ask for the right information from projects that will allow you to make the right gating/governance decisions at the right time.
  • Remember, Agile is designed to reduce risk and ensure value delivery by empowering the delivery team and working closely with stakeholders throughout the project lifecycle. Gating/governance should focus on ensuring the delivery team has what it needs to be successful but also act as an escalation path for any problems/issues/roadblocks encountered by the project.
  • Iteration is foundational to Agile, and the same should be true of your Agile gating/governance approach.
  • Notice that the RRVC phase also provides an opportunity to measure the project delivery team’s ability to accurately estimate the project (e.g. if the RRVC took twice as long as expected to complete, then it’s likely that the rest of the project needs to be re-estimated to take this into account).

Facilitator Slides

2. Issue/Risk Management Philosophy

  • Avoid managing issues/risk separately from delivery (risk is a natural and ongoing part of delivery).
  • The project team is responsible for managing project risk on the project and may not need to maintain a formal risk registry or mitigation plan. Instead, risk is managed continuously throughout the project by the delivery team themselves wherever possible, and risk is escalated when this is not possible.
  • The project team has shared ownership and responsibility for all project risks (risks aren’t managed “by the process,” they are managed “by the team”).
  • Every team member should be prepared to address small risks directly whenever they can and should know the proper escalation path when they cannot.
  • High-level risks can/should be identified at the start of the project, but from then on, the project team will self-manage all risks and escalate when necessary.
  • To the extent possible, large project issues/risks should be addressed early in the project lifecycle in proactive and tangible ways.
  • Consider the following approach to categorizing and handling issues/risks:

    Issue/Risk Type Description How to Handle
    Common everyday risks Small to medium issues/risks that can typically be handled directly by the delivery team. The delivery team is empowered to identify and address these risks as they happen. If the issue/risk is low impact, these can be addressed “silently” (i.e. without reporting or escalation). If there is potential for the issue/risk to be medium or high impact, the risk should be shared with the SM and PO (and escalated if it can’t be addressed).
    Scrum master (SM) handles Small, medium, or large risks that cannot be addressed directly by delivery team members (e.g. too much effort involved, don’t have the right contacts or influence to affect change, specialized skills are required) and are escalated to the SM. These risks should be escalated to the SM to be handled. The SM will do their best to address the issue/risk directly whenever possible and escalate to the PO when necessary.
    Product owner (PO) handles Small, medium, or large risks that cannot be addressed directly by the delivery team or SM and are escalated to the PO. These risks should be escalated to the PO to be handled. The PO will do their best to address the issue/risk directly whenever possible and escalate to senior leaders/governance body when necessary. These risks should appear on a risk registry that is visible to the gating/governance body.
    Escalated to governance Small, medium or large risks that cannot be addressed directly by the delivery team, SM, or PO. These risks should be escalated to senior leaders and/or the governance body to be handled.

Facilitator Slides

3. Decision-Making Approach

  • To the extent possible, decision making will be done by the project team, except where there are clearly defined boundaries about which decisions cannot be made by the project team (these should be minimized as much as possible, and clear guidelines and guardrails should be defined for the few cases where it is necessary).
  • Governance/gating involvement in decision making should be as limited as much as is reasonable (so that the project team is empowered to do the right thing).
  • To the extent possible, the ultimate decision-maker for the project is the product owner, who is expected to use good decision-making practices throughout the project (this includes doing what is “right” for the project, involving stakeholders in decision making where warranted, breaking up “log jams” on stakeholder opinions, balancing risks and ensuring value delivery by the project, etc.).

4. Change Management Approach

  • To the extent possible, change management is done by the project team on an ongoing basis without needing to seek approval beyond the PO and stakeholders.
  • Large scope changes and/or changes which materially impact cost and timeline may need to be brought back to Gating for approval (or at least, confirmation that adequate consultation and buy-in from stakeholders has taken place).
  • The project team should demonstrate that they have good control over project scope by practicing effective backlog management techniques, including:
    • Estimates (even if only rough) for all backlog items.
    • Tracking of progress on a sprint-by-sprint basis (e.g. disciplined use of sprint backlog and product backlog item management) including a burndown chart or equivalent report that shows both progress and total estimated work to be completed.
    • Effective backlog management techniques are in use, including using a definition of Ready and Done, following good backlog management and sprint planning practices, effective story decomposition, etc.

Facilitator Slides

5. Status-Reporting Approach

  • Very different from traditional (minimal status reporting should be used and limited to things like confirmation that the project team is following good Agile practices, burndown charts, stakeholder feedback, active risks being mitigated, and any escalations).
  • You may want to consider an approach similar to the Agilometer but tuned to reflect Agile project status rather than Agile-friendliness and focused on “working, tested code that has been reviewed by stakeholders whose feedback is welcomed and incorporated into the project” as the best measure of a project's status/success.

6. Documentation Approach

  • To the extent possible, the gating approach should avoid using documentation as an indication of project progress and/or success.
  • All documentation approvals that hinder or are antithetical to Agile should either be eliminated or reconsidered as “evolving documents” that are only approved at the end of the project instead of before work can be started (e.g. Detailed Design Document, UAT Test Plan).

Facilitator Slides Gates 3/3A

Consider and discuss the following aspects of the Gates 3/3A:

  • Gates 3/3A (also known as the Risk Reduction and Value Confirmation phase) are core to the Framework’s approach for gating Agile projects.
  • These gates use a “trust but verify” philosophy where Agile project teams are trusted to deliver valuable output to stakeholders, but in increments (and the project’s performance at the end of each increment is examined before the next phase begins).
  • This approach helps to avoid Waterfall’s tendency to discover unpleasant facts late in the project lifecycle.
  • Prior to Gate 3, the project deliverable is broken up into two phases:
    • The Risk Reduction and Value Confirmation (RRVC) phase (which might be repeated more than once)
    • The Full Project Delivery (FPD) phase
  • The RRVC phase involves delivering just a small portion of the full deliverable with the specific goal of reducing overall project risk and validating with stakeholders that there is value in doing the FPD phase.
  • Note that the objective of the RRVC is to deliver working, tested code that has demonstrable value to stakeholders (it is not a mockup or throw-away prototype, but rather as close to production ready as is reasonable).
  • Cost and timeline for both RRVC and FDP phases are provided prior to Gate 3 (“precise” for RRVC and “ballpark” for FPD), but only RRVC funding is approved until Gate 3A is passed.
  • Precisely how much of the full project deliverable will be done in the RRVC phase is circumstance dependent, but as a rough guide, consider delivering somewhere between 10% and 25% of the full project scope (depending on size, duration, and complexity of the project).
  • The Gate 3 Checklist must be passed before entering the RRVC phase.
  • The Gate 3A Checklist result, along with the project’s Agile health check result, is used to make the Proceed/Repeat/Hold/Terminate Decision at the end of Gate 3A.
  • If the Gate 3A outcome is to Proceed to the FPD phase, the project is given approval to spend the rest of the money allocated to the project (based on the learnings of RRVC phase, the FPD phase cost and timeline may need to be adjusted).
  • Remember to use the Agilometer outcome to determine the level of support and governance oversight the project will receive (the lower the Agilometer score, the more support and oversight the project will require).

About Info-Tech

Info-Tech Research Group is the world’s fastest-growing information technology research and advisory company, proudly serving over 30,000 IT professionals.

We produce unbiased and highly relevant research to help CIOs and IT leaders make strategic, timely, and well-informed decisions. We partner closely with IT teams to provide everything they need, from actionable tools to analyst guidance, ensuring they deliver measurable results for their organizations.

What Is a Blueprint?

A blueprint is designed to be a roadmap, containing a methodology and the tools and templates you need to solve your IT problems.

Each blueprint can be accompanied by a Guided Implementation that provides you access to our world-class analysts to help you get through the project.

Talk to an Analyst

Our analyst calls are focused on helping our members use the research we produce, and our experts will guide you to successful project completion.

Book an Analyst Call on This Topic

You can start as early as tomorrow morning. Our analysts will explain the process during your first call.

Get Advice From a Subject Matter Expert

Each call will focus on explaining the material and helping you to plan your project, interpret and analyze the results of each project step, and set the direction for your next project step.

Unlock Sample Research

Authors

Alex Ciraco

Valence Howden

Visit our IT Cost Optimization Center
Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019