by the QRonos product team
To mark the first anniversary of QR_’s Business Timing and Release Schedule tool, QRonos, we thought now would be a good time to order some thoughts on the common forms of BTRS found in the automotive industry today, and how this part planning impacts programme development.
Part planning usually takes one of three forms:
1. Spreadsheets are the most common part planning method. There is a time and place for spreadsheets, but when you’re managing large amounts of complex data drawn from multiple sources, making calculations and having multiple concurrent users, spreadsheets introduce a substantial risk of data quality degradation. Spreadsheets are also much harder to control, the perennial question being whether the latest version is in SharePoint or my inbox? They also introduce significant admin overheads, with roles dedicated exclusively to maintaining these BTRS spreadsheets not uncommon.
2. Individual part plans also remain widespread, especially in organisations with a history of Microsoft Project use. The problem here is that although an engineer may have planned all the steps for his part, development is frequently divorced from everyone else’s work between snapshots or progress gateways. Accordingly, it becomes difficult to get a real-time programme overview, see where your critical paths are, and mitigate issues before it’s too late.
3. We also come across a lot of generic project management software. This often isn’t designed to track at a part-by-part level, doesn’t come with the specialist implementation support to work in a product development environment, or has been so heavily forked that support is expensive, development slow and the software dictates programme processes rather than flexibly adapting.
Resultantly, even when businesses do have a part-by-plan, we come across the same hockey stick graph again and again.
You start with the perfect plan that hits the deadline right on time. This is classic optimism bias, assuming negative things are less likely to happen to us. The home run is dependent on everything happening perfectly on time, when in reality compound contingency suggests this is exponentially less likely with every step, variable and risk introduced; when one thing goes wrong, the house of cards tumbles down and you end up with the dreaded hockey stick. This is probably a familiar shape to most, and in many places they’re accepted as inevitable.
The three main features to a hockey stick curve are:
1. The initial bottleneck – planned run rates aren’t being met, probably due to insufficient visibility on parts falling behind until it’s too late to take corrective action without impact the whole programme. Engineers are often not well supported by systems for these early-phases tasks; a big OEM probably operates on three to five year development cycles, and if it’s a task only occurring once during a programme, an engineer is at best doing the task once every three years. Even if trivial, the infrequency and unfamiliarity of the task introduces an element of risk to being able to execute to quality and on time.
2. The cliff face – the defining feature of the hockey stick, this captures the focus on gateway charges pushing hard to make up lost ground in the later stages of a programme due to not having a finger on the pulse of the earlier and middle stages. This is the period of huge management pressure, long hours, team burn-out; it’s unhealthy unsustainable and inefficient. It also leads to:
3. Lateness – hockey sticks are nearly always late, with inevitable associated costs.
We expand on how to address this in Part 2 – give the Quick Release LinkedIn page a follow to make sure you don’t miss it.