Originally published by QR_ Director Ian Quest on Medium.
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've represented a point where we pause, understand where we are, and make sure we're fully ready to continue to the next stage — with full agreement and minimum risk.
But barring a few exceptions, gateways normally mean long hours in the build-up to special meetings to drive progress, rushed designs and 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" — while giving the impression of progress and no doubt helping to flush out issues that had been sitting in boxes — is usually counter-productive. It encourages optimistic reporting, leaves 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 where senior management can get a finger on the pulse of the programme, and where programme managers earn their rewards and recognition for getting through them. It's natural that they receive significant attention — but they were never intended as a tool for driving progress.
Every single part has its unique journey from the CAD definition to being in a kit ready for build. There are many steps and interactions required at different times through the programme — and it's those activities 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 like prototype builds, you need to know that you're ready, that the prerequisites are done, and that you're not carrying excessive risk. 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, granular data — and can consolidate and sum it in useful ways — there's no need (or excuse) for a simplified, 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 has two main tenets: progression — the series of mini-gateways that track progress each week, rather than tracking only the final output at a gateway (releases); and maturation — we don't throw things over the fence from department to department or from phase to phase, starting our data again in a new system; the data matures and gains new depth as we progress through the project.
Breaking the habit
Changing this approach takes strong policing to prevent reverting to old habits when people get complacent. 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 that way.
Detailed analysis of the last few programmes in terms of time, quality, and cost will usually shine a 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 items required to fulfil the specific key event should be hard-linked to the gateway. Other items that will be required between gateways should be attached to their specific dates — not 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. This part-by-part detailed planning approach may look like an intimidating task, but it's actually really achievable. If you want to know how you're tackling delivery and what risks you're carrying, there's simply no simplified option that will do this.
3. Track from day one
I've often heard objections to the idea of tracking from day one — that you don't know your BoM well enough to track against until later in the programme. While this is true for specific parts, it's rare that you can't predict with reasonable accuracy what will and won't be in the BoM from very early on. Without it, you're simply driving blind for a period, and your understanding of risks and of items that may have been forgotten remains poor. Give yourself a detailed plan to track against and you'll only have the changes that need special attention.
The tracking process and tools also require effort and focus — a drive for accuracy, regular refreshing of data, personalised views, and as much automation as possible. The disjointed home-made Excel trackers, while 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 a gateway is approaching, it'll be hard to maintain momentum at other times. Focus on what needs to be done this week; get the chief engineer to chase up the five parts carrying the greatest risk of late delivery; and repeat the 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-planned 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 it needs to be underpinned by the right data.
6. Be focused — start with one new programme
It's 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'll need to prove to everyone that this approach works — which means a successful pilot, and if you're spread too thin, that 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
Changing this won't be easy, but in reality there's 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 won't for long.
