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.
What are gates on projects?
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:
- This misses the point of gates: Gates are when we agree whether we can–and want to–start or continue a project; therefore, all projects (including agile projects) will need to gain some form of approval to kick-off and keep going.
- Agile projects already include a soft gate at the end of each and every iteration or sprint: In the review session, the product owner sees what has been delivered and can choose whether to continue the project or stop if enough has been delivered. While not many agile projects do this, it is one of the distinct advantages of the agile approach, that you can stop 80% of the way through and get 80% of the system (whereas on a waterfall project, you would likely get nothing delivered at all).
- Cooper’s original representation of the stage-gate process as five stages was predicated on the typical new product development process from the 1970s, that is, of tangible products rather than software. In any case, the five-stage model was a simplification for ease of communication. This has been as misunderstood as Royce’s much-maligned report that, on the page following the traditional cascading waterfall diagram, showed that he recommended feedback loops between stages, and iterating at least twice (preferably more). Likewise, Cooper always understood that you could loop in developing a prototype and showing it to customers, and that has since been incorporated into variants such as Stage Gate Express and Next-Gen Stage Gate.
What’s wrong with gates anyway?
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.
Towards lean governance
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:
- look at potential new ideas,
- review current work in progress, and
- consider the feasibility results to confirm whether a product manager should bother building a business case for a new product idea.
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.
