The first steps
This is the second of a series of articles on how to implement and enhance a 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 this article I shall be commenting on the first steps in setting up gate process, or sorting out one that has significant issues. The particular subjects that I want to cover are stakeholder engagement, mapping existing processes, and project management for the gate process implementation. It will be helpful, in developing the context, to deal with these in reverse order. First I want to clarify where I see gate process sitting in relation to other project management methodologies.
Gate process v. project management
The main application of gate process is to control new product development and launch (“NPD”), and existing product development (“EPD”). This can include packaging modifications required, for example, for promotions. Besides controlling individual product developments, the purpose is to manage the product portfolio and the allocation of resources across product developments and, sometimes, other business change projects. The gate process provides a template (or templates) for similar/repetitive projects.
Many businesses use gate process only for NPD and EPD. Some use it for NPD, EPD and also for projects that might otherwise be run using project management methodologies (e.g. Prince2 or PMBOK). Where used, gate process supplants project management methodologies but it is not a universal alternative.
I would still use Prince2 (or similar) for major projects with substantial dedicated resources run outside the gate process (for example, a new factory or a new ERP system). And I would use Agile for certain software developments, both within and outside the gate process.
Many businesses have a myriad of competing and conflicting projects, running in different departments or at different levels of a company hierarchy, usually with little or no governance. These projects will have varying degrees of strategic alignment and often result in substantial waste. A single projects database controlled by a gate process is a great way of bring these disparate projects under control, ensuring that resources are directed to maximum effect. It is also a great way of sharing ideas and knowledge. If this sounds bureaucratic, it does not need to be. I shall return to this in a later article.
Project management for gate process implementation
There is the question of whether to manage the design and implementation of the gate process itself using project management methodology. For a first-time implementation of a gate process, unless sponsored by the Chief Executive, I would use a slimline version of Prince2 (or similar). The design and implementation of a gate process does not need a massive amount of internal resource, so the project management can be relatively light.
If it is going to control NPD or major business-change projects, a gate process is going to touch nearly all areas of the business. To implement a gate process you will need appropriate sponsorship and buy-in at senior level, you will need to borrow some key people, and in due course you will need to communicate with all people who would normally be involved in the types of projects you wish to control. If the implementation is not sponsored by the Chief Executive you will almost certainly need a project board or steering group, and some formal controls, to ensure senior management is aligned and committed to providing the necessary resources. The background to initiating a project will also have a bearing on the sequence of events, which I will cover later under the heading “Running order”.
For enhancements of existing processes, the need for formal methodology depends on the extent and root cause of the issues that need to be addressed. The ownership of sub-processes and the existence of any political factors will have a bearing. It is usually better to start a project with a project initiation document (“PID”) then scale back the formalities, than start without one, have the project stall, and then put in place the formal controls.
I shall leave readers to consider what is appropriate for their circumstances.
Mapping existing processes
It is essential to map existing processes for product development.
I have witnessed a significant number of change projects – mergers, integrations, new systems, new business processes – where insufficient attention has been paid to existing processes. At best, operators had to improvise to keep the business functioning. At worst, a catastrophic failure necessitated a u-turn and restoration of original ways of working. Existing processes need to be mapped in sufficient detail. How do we know that we have sufficient detail? That’s down to a little experience and a lot of commonsense. Appropriate methodology helps.
I would not use BPMN for existing processes. Trying to create a model that all key stakeholders can agree to is potentially very time consuming. The aim of mapping existing processes is to flush out all essential activities and entities (inputs and outputs). The sequencing of activities is not critical at this stage; in fact disagreements between stakeholders over sequencing are often an indication that the existing process is failing. So attempting to produce an accurate flowchart, which we intend to replace, is a waste of time (all the more so if done to BPMN standards).
The risk of missing essential activities or deliverables is increased where there is market or product segmentation, for example, there may be differing requirements and sub-processes for branded, generic, customer branded, licensed or outsourced products.
My preference is to use a hierarchical business model. If combined with a simple validation test, it is guaranteed to create a comprehensive model, capturing all the essential elements. I am not going to explain now in detail how to build a hierarchical model but I will provide a few comments and tips.
If redeveloping an existing gate process, then the highest level of the hierarchical model could be each of the existing stages. If designing a new process, and you have no other preference, you can try starting with the conventional stages: Discover; Scope; Build Business Case; Develop; Test & Validate; Launch. An alternative, that I find a better fit for food and fmcg, is more suited to process manufacturing: Generate Ideas; Define Concept; Establish Concept Feasibility; Develop Capability; Prepare for Launch; Launch.
Working progressively down from the highest level of the model, disaggregate the stages into sub-processes, activities and, if necessary, tasks. The beauty of the hierarchical model is you can develop it with individual stakeholders, adding new sub-processes and activies, or switching things around as you consult more stakeholders. There comes a point at which you will need to gather a cross-functional team to reconcile gaps and duplication, and any differences in terminology.
The result is a diagram containing
- a list of activities,
- a list of outputs in approximate order they were created,
- the job title currently responsible for each activity/output.
These are key inputs to the design of stages, which I shall cover in my next article.
To conclude my comments on mapping, I have two further tips. If any entity is modified or updated then treat the output as a new entity (e.g. provisional launch plan, final launch plan). There may be some ambiguity about responsibility; I would not worry about it at this stage.
Stakeholder engagement
It is necessary to do some work initially, to define the scope and context, in order to gain senior management commitment to a plan. You may not be setting out to re-design the entire process. Perhaps you are intending to eliminate a few bottlenecks. Even so, the root causes may be far removed from the symptoms. This will become clearer as you map existing processes.
I suggest all Heads of Function are informed at the outset. At this stage (mapping) you will be on a fact-finding exercise. You will be seeking a commitment to support this initial investigation. You will need to involve a few knowledgeable members of staff to map existing processes – surprisingly few if you choose the right people.
There is a body of opinion that that believes you can never start communication too early. Once you start, however, the momentum needs to be maintained otherwise the lack of communication can have an adverse effect. At this stage, unless you are intending a first-time implementation, I would keep it relatively low key.
A lot depends on the prevailing culture and practices. For example, you might use existing communication mechanisms (cascades or newsletter) to let all stakeholders know you are mapping existing processes with a view to making improvements, making it clear that any changes will be subject to executive approval to initiate an improvement project; also, all stakeholders will be able to comment on existing processes, and will be consulted during the design and implementation of any changes. I would certainly see this broad communication being necessary after the senior management team have been presented with, and have approved, the PID.
The mapping process is a great way of engaging stakeholders. Involve a few key people early on, to develop a provisional model, then put this to wider groups of stakeholders for their contribution and to test the model. Keep a log of issues raised, which the new process will need to address.
I have covered stakeholder engagement in projects and programmes in earlier article entitled “7 Essential Elements of Stakeholder Engagement“. My comments there apply to gate process design and implementation. The only additional point that I wish to make here concerns the ‘running order’ of engagement, mapping and the PID.
The running order
As I commented earlier, it is necessary to do some work initially to define the scope and context in order to gain senior management commitment to a plan. The background to initiating a project will also have a bearing.
For a first-time implementation of a gate process there may be very clear drivers and goals. Some clarification of the scope may be necessary but the intention to create an entire process already exists. So the scope is relatively clear. In this case, regular Prince2 practice holds good. The regular practice is to initiate the project with a PID, which is communicated to all stakeholders and signed off by the business sponsors. Mapping of existing product development processes would take place in the first phase of the project.
When enhancing an existing gate process the scope may be less clear. Tinkering with sub-processes may bring some benefits but is not going to produce a lean process. If there are significant numbers of issues throughout the process, it usually pays to do a complete re-design. The initial drive to make changes may have come from an oblique angle. For example, I ended up completely re-designing a gate process having started investigating how to reduce packaging waste. In a case like this, different stakeholders are likely to have different views on what should be retained and what should be changed. Mapping existing processes will be helpful in exposing all the issues.
Consequently it may make sense to map existing processes and even produce an outline design before formal project initiation. Involving stakeholders in the mapping and validation of the existing process model, and capturing their issues, helps to ensure they are fully engaged. The PID then becomes the start of the detailed design and implementation phases.
Next week…
Next week I shall be covering the design of the stages, and the importance of flow.