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. 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-Project 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 British Standard (BS6079 Part 1). If you haven’t seen it, then you really should get a copy.

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 standard 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 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.
  • Articles: You’ll also find some articles you can download from site.
  • Video: Here is a video taking you through the project life cycle in the Project Workout
  • Click for yourself: you can investigate the model yourself. Go to my companion website.

About Robert Buttrick
Robert Buttrick is the author of the Project Workout. He has been providing advice and guidance since the publication of the first edition of his best-selling “flagship” book, the Project Workout in 1997 and now its 4th edition. The principles laid out in the publications, take a holistic view, ensuring that culture, systems, processes and accountabilities are mutually compatible. The book has been translated into French, Korean, Chinese, Russian and Romanian . . . but not yet into Latin! Robert received a Distinguished Service Certificate from BSI for services to national and international project management standards; he is a Member of the Chartered Institute of Marketing, Chartered Engineer and an Honorary Fellow of the Association for Project Management. He currently works as a consultant and is a Visiting Teaching Fellow at the University of Warwick.

4 Responses to Life cycles and fuzzy back-ends

  1. PM Hut says:

    Hi Robert,

    Actually “Gates” are really exit points from a stage. You cannot exit the stage unless the gate is open – and the gate opens only if the requirements of the previous stage are all met.

    We did publish an excellent post on “gating” about 4 years ago, you can find it here:

    • The reason I call them entry gates is that the actual decision is to start a new stage. You set whatever criteria you want for that. If your criteria is that absolutely everything planned for the previous stage has been completed, that that is your choice. I have never found that practical. It’s all about risk management. What is the risk of proceeding if some things are not complete versus what is the risk of holding all work up on the next stage because some this aren’t finished? Sometime it really matters, and other times it doesn’t. The other scenario where “exit doesn’t work” is in product development. The development stage may continue even though a trial stage has started; i.e. the start of the trial stage is triggered part way through the development stage. My book, Project Workout, chapter 3 deals with this.

  2. If YOU want to make the criteria for starting a stage that EVERYTHING in the previous stage has been done, then that is your choice; in my approach, it is simply one of the criteria to be met at the gate. However, I don’t advocate this as a general rule and neither does BS6079 Part 1. There are many situations when starting a stage before the current stage is fully completed, all t’s crossed and i’s dotted, makes sound business sense. It is all about risk. However, it does mean the decision makers have to be mature and really take the risks into account – not just blunder on in blind delusion mode. For example at the PMO conference ,one person said she kept the “must be completed before start of next stage” rule as the people in her organisation weren’t at a level of maturity necessary for the criteria to be changed – they would keep ,sneaking past the gate..

    let’s also look at a practical example. Look at the project lifecycle diagram in the blog. Notice the Trial Stage starts part way through the Develop and Test Stage, as in this case a Trial can start when sufficient capabilities have been developed and the trial does not need to wait until everything has been developed. In this case an explicit decision is made to START the Trial Stage, when ready, You’ll find RG Cooper follows this approach in all his product development publications and papers. In your approach, you couldn’t have a gate to start the trial stage as there is no stage completed at this point in time.

    So, in brief, your approach is a specific scenario which can be accommodated in the approach I describe. Whereas, my approach cannot be accommodated in the strict “must finish previous stage” approach you advocate.

    You may find reading the Frameworks chapter in Project Workout helps. Many people are so used to the “rule” you describe from quality based software methods (which are NOT project management), it takes a while for the difference to dawn on them.

    If your rule works for you, then fine; the key is to design a gated lifecycle with clear rules that you do not have to break for “pragmatic” purposes.

  3. Pingback: What is a “stage-gate”? | Project Workout Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: