By the QRonos product team.
Part planning usually takes one of three forms:
- 1. Spreadsheets — The most common part planning method. There's a time and place for spreadsheets, but when you're managing large amounts of complex data drawn from multiple sources, making calculations, and supporting multiple concurrent users, spreadsheets introduce a substantial risk of data quality degradation. They're also much harder to control — the perennial question being whether the latest version is in SharePoint or my inbox. And they introduce significant admin overhead: roles dedicated exclusively to maintaining BTRS spreadsheets aren't uncommon.
- 2. Individual part plans — Widespread, especially in organisations with a history of Microsoft Project use. The problem: 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. It becomes difficult to get a real-time programme overview, see where critical paths lie, and mitigate issues before it's too late.
- 3. Generic project management software — Often isn't designed to track at a part-by-part level, doesn't come with specialist implementation support for 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-part 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. A familiar shape to most — and in many places accepted as inevitable.
The three main features of a hockey-stick curve
- 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 impacting the whole programme. Engineers are often not well supported by systems for these early-phase tasks. A big OEM probably operates on three- to five-year development cycles; 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 risk to execution — 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. The period of huge management pressure, long hours, team burnout — unhealthy, unsustainable, and inefficient. And it leads directly to…
- 3. Lateness — Hockey sticks are nearly always late, with all the associated costs.
We expand on how to address all this in Part 2.