Designing the stages
This is the third in a series of articles on how to implement and enhance a gate process (also known as stage gate process). The series sets out to highlight some of the issues associated with the introduction and operation of gate processes, and to offer some advice in the context of consumer products.
One of the reasons for writing this series is that much of the literature seems to be more aligned to engineering and technology products than to my interests, which are primarily food and fast-moving consumer goods.
In my first article I defined my scope as “the application of gate process as a key element of product portfolio management, and the process between gates (the stages) as well as the gates themselves.” I gave a brief history of the gate process, the goals and benefits, and a list of issues that are symptomatic of a badly designed or badly implemented process, or are frequently encountered where no gate process exists.
In my second article I commented on the first steps in setting up gate process, or sorting out one that has significant issues: stakeholder engagement; mapping existing processes; project management for the gate process implementation.
In this article shall be shall be covering the design of the stages, and highlighting the importance of flow.
Had you been following the steps in my earlier articles you will now have a hierarchical business model (“HBM”) mapping existing product development and launch processes, which you developed with key stakeholders. Engagement of other stakeholders will have started through their involvement in validating the model. You will also have a list of key outputs/deliverables generated during the processes. The next step is to create a flow model.
Creating a flow model
Reflecting on creating a flow model raises a couple of questions:
Q1. Current or ‘to be’ model?
Once you have validated the HBM there is little purpose in flow charting existing processes. Go straight to the ‘to be’ model. The HBM and list of outputs are all you need.
Q2. Radical redesign or optimisation?
It depends on the state of the existing process. The HBM gives some insight to how inefficient, inadequate, or broken, is the existing process. For example, there may be poor quality, late or missing inputs, causing delays and rework . Most likely you are looking at refinement of existing process rather than radical redesign… but how radical depends on the extent of existing dysfunction.
In validating the HBM you may already have questioned the value of some existing activities. I suggest you review the outputs and deliverables:
- Why do you want them, are they really necessary?
- Are any outputs not used as inputs later in the process, or not valued by users?
- Are there duplications?
- Are there changes that you would want to make?
- Can you simplify or combine them?
When processes are out of control, lots of outputs are created for the comfort factor. People like to keep their own records and versions. Another cause is lack of timely collaboration. Many activities and outputs may not be necessary when the new process is operating, under control, and supported by systems to provide visibility of status and progress. There may be many easily visible iterations, loops and exchanges that could be eliminated.
- Remove superfluous outputs.
- Redesign flows to eliminate duplicated effort and competing activities.
- Reconcile new activities and outputs with existing.
Sometimes the new process falls into place at sub-process level. Sometimes a fundamental review of activities is needed and then a reconstruction of the parent sub-processes. Sometimes it is possible to move activities, merging them with earlier or later sub-processes, which can result in the elimination of loops or have significantly beneficial effect on flow.
If you are going for a radical redesign then use the reviewed outputs from HBM to validate the new model. In any event, you are going to have to convince stakeholders that nothing of importance has been lost in the new process. Being able to correlate and reconcile the new and old is going to be very helpful. Track and log any changes, deletions, merges and replacements, and the reasons.
You now have a draft flow model. It is likely to be a fairly complicated network of activities – some sequential and some running in parallel. At this stage I would still be using a very basic notation, have typically 200-300 activities and 100-150 key deliverables. If I am building the flow model, up to this point it will be with minimal consultation of other stakeholders There will have been widespread (and essential) consultation in validating the HBM . The flow mode is essentially a translation into a different view. For this I would involve no more than two or three people, with perhaps a few more consulted to clarify possibilities in some of the sub-processes. Although we are intent on developing the ‘to be’ model, the first draft is a logical reconstruction from information already gathered.
Although you may have thoughts of wider consultation, at this stage it will most likely be inefficient and may be counter-productive. The analogy I would make is in trying to get a large group of people to agree the route for a road trip. It is easier look at a proposed route for the complete journey and debate alternatives rather than to debate the possible choice of direction at each turn along the way. Wider consultation can come later. There will be a good few changes as other stakeholders are involved, but first there is some more work to do.
Determining the critical path
The next step is determining critical paths. I use the plural because changing activities around will often cause the critical path to move. Usually we are looking to make the critical path as short as reasonably possible within the constraints of quality and acceptable risk.
You will need to know the duration of key activities:
- when unconstrained by available resource
- whether fixed time, or resource dependent
- product/volume dependency
- any waiting times
If you want to get really sophisticated you can build a knowledge-based system to calculate the duration of the entire process according to the product specification and other parameters.
When you have identified the critical path, you may have views about reducing the duration of specific activities, or moving them around to run more activities in parallel. Try making the changes and assess the impact on the critical path. Also do some ‘what ifs': what if we could reduce the time of activity X, or lift constraint Y? Readers who understand Theory of Constraints will have some idea where we are heading. We are, in effect, projecting what will happen as constraints are removed. After exploring the possibilities you will have a good understanding of alternative critical paths. Also you will probably have made some improvements to the flow model.
You are now ready to consider positioning the gates.
Positioning the gates
Common usage of stage gate process has defined stages, ending in a gate. Where the activities sit is pretty much self-evident. I have already stated that much of the literature is not aligned to my interests, so I want to take a different approach. First I will explain why.
Flow is really important for many food and fmcg products, where speed to market with new developments is crucial. Retailer listings and promotional events on branded products are often confirmed at short notice. Retailers often want their own brands to be developed and launched on short timelines. For a food/fmcg manufacturer, speed is a competitive advantage.
The differing control requirements of branded, generic, customer branded, licensed or outsourced products may necessitate different sub-processes. These can influence the positioning of gates.
Another consideration is the development of packaging. For many fmcg and food products, packaging conveys both the brand image and differentiates the brand from otherwise similar (sometimes identical) unbranded product. Packaging design, artwork and reproduction can suffer from poor control or avoidable iterations particularly if Marketing are indecisive or make late changes. Careful (unconventional) positioning of gates can be used to lock designs before reproduction commences.
Common use of stage gate process has all activity coming to a stop pending approval at each gate. This means that all gates will be between activities on the critical path, in which case, approvals are time-critical. If there are delays in approvals, these delays add directly to the overall duration. Given that approvals are often required from senior management, many projects get held up at the gates.
If we take the gates out of the critical path the timing of approvals can float, to a degree. This conflicts with the general purpose of gates, to limit commitment pending approval of the previous stage and to confirm the project is continuing to meet ‘go’ criteria. The aim is to speed up flow.
In practice, the activities that run past the gates, unchecked, may not be particularly critical. So first you need to determine which are the critical activities:
- the ones where you want to review outputs;
- the ones you definitely don’t want to start without prior authorisation.
Then you need to consider activities that are dependent on critical path activities. If these are critical activities (as defined above) then the preceding critical path activity may need to run to a gate. One way round this is to grant conditional gate approval in advance – subject to satisfactory completion of the unchecked activity. Signing off the unchecked activity can then be delegated to the programme controller.
Clearly if we consider various potential critical paths and find a long list of activities that could by-pass a gate, doing so would defeat the purpose of the gate. In practice there may be one or two exceptionally long activities which, if run past the gates, could substantially reduce the overall duration. It is this kind of substantial shift that you need to be looking for.
So positioning of gates need not follow convention. There may be substantial improvements in flow by judicious positioning.
Now that you have redesigned the flow and inserted the gates, you need to put this past the stakeholder community. Expect to make a few more changes!
Next week I shall be commenting on the control of stages and the design and operation of the gates.
- How to Implement and Enhance a Gate Process – Part 1
- How to Implement and Enhance a Gate Process – Part 2
- Overcoming obstacles to successful change programmes