As I have worked on the ‘Agile Extension to the Business Analysis Body of Knowledge‘ over the last year, I have repeatedly come across the assertion–by many agile practitioners–that we no longer need gate meetings on projects. From my experience in leading project governance this confused and concerned me, so I have looked into this and believe I have discovered why this perception has arisen, and more importantly have concluded that gates and governance are vital and need defending.
Before we get into what’s happened and why it needs to be overcome, let’s first understand what we mean when we talk about gates on projects:
In mythology, gates are portals through which the hero passes from one realm to another, often with a gatekeeper or guardian who ensures that the hero is worthy to gain entrance. So, on projects, gates are the means by which the project continues from one stage to the next — or not!
There are records of such end-of-stage reviews being called ‘gates’ for well over 50 years; however, the ‘Stage Gate Process’ came to prominence in 1985, when Robert G Cooper published his book ‘Winning at New Products‘. Stages and gates are most typically represented as a series of process rectangles and decision diamonds, where the gates are the decision points between each project stage. This makes it relatively easy to understand at a glance and is the reason the logo of Cooper’s Stage Gate International is a diamond between two squares.
It is this representation that leads many agile practitioners to consider gates to be symptomatic of the waterfall project life-cycle, and as they consider everything waterfall to be bad, by extension gates must be bad too.
This is wrong on several levels:
For now, let’s accept that gates are just points of review and (re)commitment, and happen on all projects. Is there anything inherently wrong with gates that should give agile practitioners cause for worry?
Project gates are the point at which a project’s readiness is confirmed and its continuation is agreed. This means that gates are closely connected with project governance — getting projects to agree what they will do up front and confirming that they have done what they agreed by the end.
When we’re looking at a new or in-flight project in this way, we have to consider many different questions and typically have to talk with a lot of people, who often meet in different locations and at different times. This means that the gate, which should be a simple decision of whether to start or continue something, becomes a long drawn-out affair, often lasting several weeks. This elapsed time between key events then leads to the gate itself becoming a multi-step process, with several sub decision points on the way, and this is why gates are one of the biggest headaches for projects in general, and for project managers in particular.
It doesn’t have to be like this! In my current role. I coach product managers through the early stage product development process, and as part of this I lead fortnightly assessment sessions with the senior leadership team to:
To make this effective, I had to provide the senior leadership team with tools to be able to assess and compare new product ideas and see at a glance all the possible and in-flight work so they could prioritise where they should and should not be investing the company’s money.
Traditionally, assessment and prioritisation had been carried out separately, so one of my challenges was to look at ways of streamlining this. I considered running them in series (the existing approach), in parallel, or within the same meeting. Achieving both in the same meeting was agreed as the most efficient approach, and thus was born the double-diamond representation, indicating that we assess an idea and then if it passes the assessment we prioritise it against other initiatives immediately.
This now means that our early gates are simpler, with all key decision-makers present, where a product manager presents their idea and senior leadership assess its current state and fitness to proceed / continue, be held, reworked, or cancelled.
With the success of this, I want to pursue this further, to work towards an even leaner governance, and I have started having discussions with our technical shared services area, engaging with project managers, business analysts, and their governance team, to explore how this thinking can be extended. It’s going to be an interesting ride.