The ‘Gateway Charge’ has had its day

7 tactics for speeding up New Product Development by reducing ‘management by gateway’

For many years, gateways have been an important element of programme management. Timed around key decisions being made or key activities about to start, they have represented a point where we pause, understand where we are and ensure we are fully ready to continue to the next stage with full agreement and minimum risk.

However, barring a few exceptions, gateways normally mean long hours in the build-up, special meetings to drive progress, rushed designs & definitions, hurried reviews, broad percentage targets rather than specific ones and an optimistic assessment of status. When we hear “we made the gateway!”, we’re left wondering if it was really a success or just another box checked.

This ‘gateway charge’, whilst giving the impression of progress and doubtless helping to flush out issues which had been sat in in-boxes, is usually counter-productive. It encourages optimistic reporting, leaving things until the pressure is on and makes understanding status between gateways very difficult.

Gateways as a proxy for management

These gateways form a natural point when senior levels of management can get their ‘finger on the pulse’ of the programme and when programme managers earn their rewards and recognition for getting through them. It’s natural then that they receive significant attention, but they were never intended as a tool for driving progress.

Every single part has its own unique journey from the CAD definition to being in a kit, ready for build. There will be many steps and interactions required at different times through the programme and it is these activities that we should manage closely — every day of the programme. The gateway should be a parallel confirmation activity, not the main thing driving efforts.

Ditch the Gateways?

Gateways do have a role to play. At key milestone events (e.g. prototype builds) you need to know that you are ready; that the pre-requisites are done and that you are not carrying excessive risk. And this should be measured in an objective and independent way. But we need to greatly reduce their emphasis as a driver for progress and build up our ability to manage the detailed plan, every day.

Progressive Maturity (Every Day is a Gate-day)

Given the way modern systems handle complex and granular data and can consolidate and sum this data in useful ways, there is no need (or excuse) for a simplified and dumbed down view. Each part can have its individual plan and those plans can be set from a very early stage to create — effectively — lots of mini gateways. This has similarities to the ‘sprint’ methodology used by the tech sector which has proven so effective at maintaining progress.

Progressive maturity is an approach to this issue with two main tenets: Progression; i.e. the series of mini gateways that track progress each week, rather than just tracking the final output at a gateway (e.g. releases) and Maturation; i.e. we don’t throw things over the fence from department to department or from phase to phase and start our data again in a new system, but the data matures and gains new depth as we progress through the project.

Breaking the habit

Changing this approach will take a concerted effort as well as strong policing to prevent reverting to old habits when things get difficult. First, you and your organisation need to believe this is something that can and must be improved. If, for the majority, it is ‘the way it is’ then it’s likely to fall flat.

Detailed analysis of the last few programmes in terms of time, quality and cost will usually shine light on the scale of the opportunity, but don’t underestimate this part of the journey; there are decades of gateway habits to overcome.

Once everyone is pointing in the same direction, there are some useful tactics to help make it work:

1. Gateway content reduction

For a gateway to be taken seriously, the content required for that gateway should be pared down to the minimum: Only the items required to fulfil the specific key event should be hard linked to the gateway. Other items which are required between gateways should be attached to their specific date and not just be ‘binned’ to gateways.

2. Plan every part

Given the wide variety of lead-times, tooling lead-times and required-by dates for parts, trying to group them for simplicity isn’t usually very helpful. Whilst this part by part detailed planning approach may see an intimidating task, it is actually readily achievable and if you wish to know where you truly are and what risks you are carrying, there is simply no simplified option that will do this.

3. Track from day 1

I’ve often heard objections to the idea of tracking from day 1 in that you don’t know your BoM well enough to track against until later in the programme. Whilst this is true for specific parts, it is rare that you can’t predict with reasonable accuracy what will and won’t be in the BoM from very early on. Without this, it simply means you’re driving blind for a period and your understanding of risks and the extent of items which may have been forgotten remains poor. Give yourself a detailed plan to track against and you’ll only have the changes which need special attention.

The tracking process and tools also require effort and focus, ensuring a drive for accuracy, regular refreshing of data, personalised views of the data and as much automation as is possible. The disjointed home-made excel trackers, whilst well-intentioned and often the only available option, tend to give the approach a bad name.

4. Add more weight to inter-gateway goals

If we only do daily reviews and add extra attention when we have a gateway approaching, it will be hard to maintain momentum at other times. Focus on what is needed to be done this week, get the chief engineer to chase up the 5 parts carrying the greatest risk of late delivery and repeat this process every single week. If this is done well, the gateway will be a formality.

5. Make intelligent demands

Be realistic with suppliers, don’t force them to accept a timeline that happens to meet yours if it’s not truly achievable. If the programme needs to be re-timed due to delays, don’t just expect the next stage to win the time back — look at the plan for each part, highlight the issues and decide what can be achieved or expedited before demanding a date you may have promised others. This can be a big culture shift and needs to be underpinned by the right data.

6. Be focused: start with one new programme

It is always easier to start a new approach with a new programme and embed new behaviours early. Put in more effort than you believe necessary at the start to get things set up well and do as much as you can before the project even starts. Ultimately, you will need to prove to everyone that this approach works, so you need a successful pilot and if you’re spread too thin, this may be difficult.

7. Give gateway assessments to an independent team

Marking our own homework is ok, but when the pressure is on it can lead to more and more risk being built into the programme for the future. Keeping the ‘marking’ on the gateways independent, with someone who has no need to push it through will help keep things honest.

No Real Option

As discussed above, changing this won’t be easy but in reality, there is no option. If the tech world hasn’t already shown us the way with its approach to agile development, then those tech companies taking on the mobility challenge are really starting to show us now. Products are being developed in around half the time of traditional OEMs and although the challenge of high-volume manufacturing is holding them at bay for the time being, it will not for long.

This insightful piece was written by Ian Quest, Director at Quick Release Ltd. Find out more and connect with him here.

Find out more about Quick Release and our service offerings on our website here, or our LinkedIn page, here.

#car #automotive #automotivenews #electricvehicles #electrification #autonomy #autonomousvehicles #mobility #ridesharing #startupsIAN