What is a “stage-gate”?

More management jargon?

Do you come across people using the term “stage-gate”? If so, are you sure they really understand what they are talking about? Do they understand what this term means and where it comes from? All too often, I find people use as the term as yet another piece of management jargon and don’t really understand it (just like “workstream”!)

This is the type of muddle people come up with:

Example A starts well, in that there are a number of stages depicted. Unfortunately we know nothing about where the decision points are. Where does the project start or end? Also, the stages are called “stage-gates”, further confusing things.

Bad practice A


Example B has the same issues as example A except that a number of decision points have been added. This, however, doesn’t clarify matters much, for example, is stage gate 1, the first stage of the project or the activity before the project starts?

Bad practice B


Example C has all the issues raised in examples A and B, except in this case it seems the decision points (gates) are labelled as “stage-gates”.  I wonder what the stages are called – gate-stages? Notice the numbering, which infers that the “gates” are decisions at the end of a stage, rather than decisions to start a new stage.

Bad practice C

Where it came from.
“Stage-gate” is actually a registered trademark devised by Robert Cooper, to describe his stage-gate process for new product development. If you do a web search for R G Cooper or “stage-gate” you’ll find lots of good articles. If you read them, you’ll see that there is no such thing as a “stage-gate”; it is simply the name he gave to his new process.  Like my own work on project management, he talks about “gates” and “stages” as being different but related.

Depicting project life cycles
In the Workout books I use circle, arrow and diamond icons to ensure that the above mistakes do not happen. This form of iconography is now enshrined in the British Standard (BS6079), international standard (ISO 21502:2020) and UK government standard (GovS 002). If you haven’t seen them, then you really should get a copy.

  • A circle depicts activities which happen before a project starts or after it is completed.
  • A diamond represents a gate.
  • An arrow represents a stage.

Like this extract from a figure in the Project Workout:

Extract from the Project Workout.



So, if you are designing a project life cycle for your project, don’t fall into the real-life traps highlighted in the bad examples above above; make sure you understand the difference between a gate and a stage; avoid “stage-gate” (you might have to pay royalties!) and make sure your depiction of the life cycle is clear and unambiguous.

More help?

  • Books: Chapter 4 of the Project Workout tells you all about project life cycles, helping you to design one that works for your situation. Chapters 6 to 12 describe the detail for each stage and then in Chapter 13 it tells you how you can tailor it. The Programme and Portfolio Workout covers this in Chapters 8 and 9
  • Articles: You’ll also find some articles you can download from the community pages of my projectworkout.com site, including one I did for AXELOS on PRINCE2 life cycles.
  • Video: Here are some mini-videos taking you through the project lifecycle in the Project Workout
  • Click for yourself: you can investigate the model in the video above yourself. Go to the Companion site page in my projectwout.com site.
  • Another blog on the topic: Lifecycles and fuzzy back-ends.

Life cycles and fuzzy back-ends

I have just spent a really great few days at the APM’s PMO conference near Birmingham, UK. My task there was to give a “master class”, three times, to about 60 of the delegates, on the topic of “Life cycles”. This covered project, programme and portfolio lifecycles, as defined in the latest APM Body of Knowledge.  I promised the delegates, I’d write a blog about some of the key points which came out of those sessions. As project lifecycles are the most complex and the most critical, I’ll concentrate on that. By the way, congratulations to Eileen Roden for organising such a great conference!

Where does it all go wrong?

In designing gated and staged project life cycles, I have found mistakes are usually made in the following key areas: the front end and the back end and in the middle! So, lots of scope for problems there!

Getting gates wrong
Firstly, people often treat gates as “exit points” from a stage. I have never met a senior manager who makes decisions walking backwards, so this approach does not match basic human behaviour. Gates are better seen as entry points to the next stage and are, therefore, about making decisions as to what to do next. If you want to look backwards, then have a “review”.

Problems at the start
All too often, I see frameworks with minimal initiation activity, immediately followed by a load of development and testing basically going from ‘idea’ to ‘do it’ in one small step. In all but the simplest projects, such a leap is naïve and may account for why so many projects are ill-defined and doomed to failure. By all means, make it easy to start the project off, but do ensure there is rigour in the actual investigative work itself. A project comprises both investigative work and “doing” work.

Problems in the middle
I sometimes see life cycle stages with no decision point prior to them. If there is no decision point, then there is no need for a separate stage. Remember, project stages are chosen to manage risk. They are NOT steps in a process. The way risk is managed is by dividing the project into stages, each of which is preceded by a decision point (gate) prior to starting each stage. The riskier the project, the more lifecycle stages there should be.

Problems at the back end
I see many project plans which stop as soon as the output has been handed over. The only time this might work is IF:

  • the delivery has been perfect and there is no remedial or snagging to do and the outputs do not need fine tuning, launching or communicating . . . i.e. almost never.
  • the project is an ‘enabler’ as part of a programme (more likely)

This is why the last stage of the Project Workout’s life cycle covers initial operations, with closure happening only at the very end.

At the back end, people often confuse Project Closure with Post Implementation Review. The former looks at project efficiency and delivery, whilst the latter looks at benefits realisation and operational effectiveness. These two views cannot usually be combined as the measurement points are separated by time.

Also note that ‘Identify project” and ‘Review project outcome” are not stages of a project. They are activities which happen before and after the project, respectively.

Depicting frameworks
The use of the circle, arrow and diamond icons in lifecycle diagrams is designed to ensure that the above mistakes do not happen. This form of iconography is now enshrined in the latest standards (BS6079:2019 and ISO 21502:2020 and GovS 002). If you haven’t seen any of these yet, you really should get a copy. There is also an AXELOS discussion paper which you can download from my Articles page.

A five stage project lifecycle taken from the Project Workout.

Naming project gates (and stages)
As best practice is that gates are entry points to stages, then the most logical name for a gate is the name of the stage that follows. Thus the Definition Gate precedes the Definition Stage. Very simple . . . really. The only common exception is the RFS (Ready for Service) gate where the term is self explanatory. When choosing names for your stages, however, be very careful. I suggest you avoid words which can be misunderstood. In my experience the words “Concept” and “Implementation” should be avoided as they can be interpreted in many different ways and cause confusion. Similarly, avoid the word “Execution”: the International Standards Organisation has not used it in their  project management suite of standards as a majority of member states took exception to it as it can also mean “judicial killing” and hence translation into other languages can be problematic.

More help?

  • Book: Chapter 3 of The Project Workout 5th edition tells you all about project lifecycles, helping you to design one that works for your situation. In Chapters 5 to 11 it describes the detail for each stage and then in Chapter 12 it tells you how you can tailor it. The Programme and Portfolio Workout covers in in Chapters 8 and 9.
  • Standards: You will find BS6079:2019 and ISO 21502:2020 have good coverage on project life cycles, as does the UK government’s GovS 002.
  • Articles: You’ll find some articles you can download from projectwout.com site.
  • Videos: Here is a link taking you to some mini-videos on projectworkout.com site.
  • Click for yourself: you can investigate the model used in The Project Workout  yourself. Go to my companion website.