1) Make the “cost of delay” visible
Problem: Work products are “sitting around” and costing money without delivering any value. Downtime and misprioritization can have enormous negative economic impacts in product development.
How-to: For the top 10 task packages, estimate: value per week of delay (revenue, margin, risk, contractual penalties, market window).
Result: A ranking of task packages by cost of delay, adherence to which leads to an optimal cost-benefit ratio for the invested resources.
2) Set strict WIP limits (flow instead of multitasking)
Problem: Too many parallel projects or work packages force frequent context switches, waiting times, and coordination costs.
How-to: Define a maximum number of concurrent work packages (WIP) per team/discipline. Do not work on more than the maximum WIP concurrently. Actively prevent the start of new work packages until the WIP falls below the maximum value (“Start finishing”).
Result: The throughput of completed projects or work packages increases, deadlines are met more reliably, and costs per project or work package decrease.
3) Frontload the learning: Early validation instead of late rework
Problem: Errors and misconceptions only become apparent late in the process and lead to costly change cycles
How-to: Define the top 5 development risks (e.g., related to technology, suppliers, regulatory approval, user behavior). Design a quick learning test for each risk (e.g., simulation, prototype, HiL, pilot customer).
Rule: No “moving forward” without proof of learning.
Result: Fewer late changes, lower overall change effort, more suitable solutions
4) Stabilize changes with “Impact-First” Change Control
Problem: “Minor” changes snowball because their impacts were not made transparent.
How-to: Every change must include:
- Impact on costs / deadlines / quality / risk
- Affected modules & interfaces
- Additional testing and documentation efforts
- Decision: Stop / Go / Revise (Change Board)
Result: Change decisions are based on facts, not opinions. Unexpected change costs decrease.
5) Integrate systematic reuse
Problem: Reuse often fails due to a lack of rules, transparency, or platform ownership.
How-to: Define standard building blocks (e.g., mechanics, E/E, software, interfaces). For new developments: Justification required (business case + risk). Measure the reuse rate and “development effort per variant” as development metrics.
Result: Fewer variants, including lower follow-up costs, and reduced development effort.