In the second post from our 7-part series exploring Stage and Gate processes, we examine the core principles of Phase Gate.
The basic idea of stage and gate models is to break the project down into key stages, each with a key focus to help define and progress the development of the new product. Implicit in this is the concept of reducing risk and managing investment as to avoid costly and wasteful mistakes. Between each of the stages are the gates – decision points on whether to allow the project to continue further, into the next stage.
The basic principles are hardly rocket science, but in practice it is not easy to get the process to really work well, and to ensure the right balance of rigour and practicality. The key to success really lies in addressing the finer details of how the process will work in your organisation.
A typical stage and gate process will have the following stages:
- Idea – Alternatively may be referred to as ideation, concept or discovery.
- Feasibility – Often referred to as scoping or definition, although we favour the term feasibility because this infers some degree of assessment on the viability.
- Business Case – Sometimes referred to as planning or assessment. Again, we have a preference for the term business case, because it indicates the function of assessment quite critically whether the project looks like it will be any good or not, from a commercial risk and return perspective.
- Development – Depending on the context this stage could be described as build or some other descriptor.
- Test – Alternative terminologies are validation, proving, piloting. The aim is to check the project has produced something viable, to meet the needs and objectives originally envisaged.
- Launch – Other terminology may be implementation, monetisation, release etc.
So, as you can see the stages flow naturally, and depending on your specific context it is quite easy to re-purpose the basic concepts involved. This re-purposing is more than just window dressing – it is important to ensure the process and the perspectives are aligned to your particular business.
Above, we described all of the stages. For a large or complex project this is typically appropriate, and it is generally right to have approval gates between each of those stages. However, when a project is small, or short duration, or simply very low risk, then that level of procedural rigour becomes a bit of an unnecessary overhead. Another example of a situation where the overhead should be reduced is where a customer has pre-ordered or committed to a contract, thereby reducing risk.
Gate Decisions
Gate decisions can be any of the following:
- Go – Proceed to the next stage, with approval to spend or use resources within agreed limits. Typically, part of the Go approval involves an agreement on what deliverables must be produced in the next stage as deliverables to the following gate. It is essentially an agreement on the terms of reference for the next stage of work.
- Kill – If the project is deemed not to have sufficient merit, then kill puts an end to it. Quite straightforward in principle, though as we shall discuss later in the section on implementation – Kill decisions are frequently avoided even when they should be made. It’s hard in practice to kill a project – people get upset, object, find alternatives, lobby for support – we shall revisit this topic later.
- Hold – This means the project has merit, but for any number of reasons it is not appropriate to continue at this point in time. The reasons to hold may be any of the following – not enough resources, not the right timing, market not yet right, not currently a good fit, an interdependence on other projects or technologies that are not yet ready.
- Rework – Typically this means ‘go back and do some more work’. This could be due to the deliverables presented to the gate not being of sufficient quality or completeness, or it may be a fundamental issue with the project, perhaps involving a change in scope or objectives.
The actual process of making decisions at gates is termed a gate review, or a gate meeting. This is generally a formalised process, with defined criteria on what is required at each gate. The advantage of there being predefined criteria is that you get more consistency and objectivity. Without the predefined criteria, it is all too easy, and nice human nature, to find reason in most projects to press ahead with optimism and rose-tinted views on why they will “probably” be good products. Hope is a wonderful thing, until it goes wrong! The criteria bring objectivity. They also bring great debate when trying to agree them up front. More on that later, when we discuss implementation.
That’s a quick overview, in subsequent blog posts we will explore the detail of specific stages and gates, and the deliverables involved. In the implementation section we will also discuss some of the most important factors that become the keys to success.
For more information on Innovation Management, follow us online or sign up to our newsletter.
