Autor: Diethard Engel

How feature creep, missing change control and weak specs create waste — and sometimes sink companies.

Engineers and developers love to make things better. That’s the job. But there’s a dark side: when “make it better” becomes “add everything possible,” products grow more complex, delivery slips, maintenance costs explode — and the customer often never pays for the extra work. The result is double cost: (a) you build things the customer didn’t ask for; (b) your engineering team is taken away from true value-adding work.

Below I explain the practical danger, show real examples from the press, and give a concrete prevention playbook (specs, checkpoints, governance, contractual levers) you can implement tomorrow.

---

Two media-reported cautionary tales

Juicero — the poster child for over-engineering
Juicero built an expensive, internet-connected juicer that squeezed proprietary packs. Customers and journalists discovered the packs could be squeezed by hand — making the $400 machine redundant. The company raised ≈$120M, saw terrible press and had to shut down. This is classic over-engineering + product-market mismatch: lots of engineering, little customer value.

Quibi — big spend, wrong product fit
Quibi raised roughly $1.7–1.8B to build a premium short-form video platform. Despite A-list content and technical polish, it failed fast: the product didn’t map to how people used mobile video (user behaviour + pandemic effects), adoption lagged, and the venture shut down within months. This shows that high engineering and production investment won’t save you without product-market fit.

These cases are different — hardware and platform content — but they share the same root causes: unclear or optimistic specs, insufficient validation with users/operations, over-investment in non-differentiating features, and weak change control.

---

What it costs (concrete impacts)

• Direct development cost for unbilled features (engineer hours × fully-loaded rate).
• Opportunity cost: engineers not available for revenue-critical work (lost feature velocity).
• Time-to-market delays — losing first-mover advantage or missing seasonal demand.
• Technical debt & maintenance burden — more bugs, longer regression tests, higher support cost.
• Customer confusion & training cost — more features → steeper learning curves.
• Reputational & financial risk — from failed launches, lost customers or public embarrassment.

·

---

Why this happens (the mechanics)

• Gold-plating mindset: engineers add “nice to have” improvements because they can – and it’s fun.
• Weak requirements discipline: vague or verbal specs (“we need it to be faster / nicer”) without measurable acceptance criteria.
• No change control process: ad-hoc requests go straight into developer queues with no cost/time impact logged (no change orders).
• Poor prioritization: lack of value-based prioritization (cost of delay, ROI).
• Incentives misaligned: teams rewarded on feature count or engineering metrics rather than customer outcomes or margins.

---

The concrete guardrails (checklist you must implement)

Product & Requirements

1. Lastenheft / Pflichtenheft (Requirements Document)
   o Lastenheft (what the customer needs / business requirements) → signed by Product Owner / Customer.
   o Pflichtenheft (how supplier will meet those needs / technical spec) → signed by Engineering Lead and Customer.
   o Include measurable acceptance criteria (performance numbers, conformance tests, UI workflows).
2. Traceability Matrix
   Map every requirement to design items, tests and acceptance criteria. This prevents “hidden” features sneaking in.
3. Definition of Done & Acceptance Tests
   No feature considered done until automated/manual acceptance tests pass and customer signs off.

Change Management & Governance

• Formal Change Request (CR) / Engineering Change Order (ECO)
  Every deviation from spec or new request must be logged as a CR with: description, business value, effort estimate, impact on schedule/cost, owner. No work without CR approval.
• Change Control Board (CCB)
  Weekly CCB (product + engineering + finance + sales + legal) to approve/reject CRs. Thresholds: small changes = PMO approve; large changes = executive sponsor sign-off.
• Freeze Dates & Stage Gates
  Requirements freeze for each release; late changes routed through CCB and must pass a risk/benefit gate. Use incremental releases (MVP → pilots) rather than big-bang.

Prioritization & Economics

• Value & Cost-of-Delay Prioritization
  Use WSJF (Weighted Shortest Job First) or Cost-of-Delay to rank backlogs; include maintenance and technical debt as items.
• Feature ROI & Payback Calculation
  For any requested feature, require a short ROI or payback note: projected revenue, margin improvement or cost reduction.

Delivery & Quality

• Pilot & Customer Validation
  Put new features into a pilot group (representative customers/shops). Measure adoption & operational impact before scaling.
• BOM & Configuration Freeze (hardware)
  Freeze Bill-of-Materials prior to production. Any ECO to BOM requires sign-off and a cost/rework estimate.
• Release Risk Registry & Smoke Tests
  Maintain a risk register; pre-release smoke tests for critical flows. If risk > predefined threshold, hold release.

Contract & Commercial

1. Change Order Clauses in Contracts
   Clearly define scope, change order process, billing rates for out-of-scope work and acceptance criteria. No invoicing without signed acceptance.
2. Acceptance & Warranty Gates
   Define formal acceptance procedures (UAT / FAT / SAT) and linked payment milestones.

People & Culture

1. Product-Engineering Partnership
   Embed a Product Owner who owns the backlog and business outcomes, authorized to say “no”. Train engineers on the commercial consequences of gold-plating.
2. Incentives
   Reward outcomes (customer adoption, margin) not just feature velocity. Recognize engineers who simplify.

---

Example governance workflow (fast version)

1. Requirements written & signed (“Lastenheft”).
2. Engineering produces specs (“Pflichtenheft”) + effort estimate.
3. Baseline agreed and BOM released.
4. Dev proceeds; any new ask → CR → CCB within 3 days.
5. Small CRs processed by PMO (documented); medium/large CRs require sponsor approval and updated timeline/cost.
6. Pilot in controlled environment; acceptance tests executed.
7. Production roll-out once pilot KPIs met.

---

Hard truths and caveats (alternative viewpoints & uncertainties)

• Not all customization is bad. Some features are differentiators. The guidance above is not “no customization” — it’s: choose it consciously with full visibility of cost, risk and upgrade impact.
• Regulation & safety can force extra work. In medical, aerospace or food, some extra engineering might be non-negotiable. Those cases need early alignment with compliance experts and likely a different commercial model.
• Market signals can change fast. Occasionally you must pivot and add features; the key is for pivots to follow the change control path and be time-boxed and ROI-oriented.

---

Bottom line (what to do tomorrow)

1. Implement a simple Change Request form and CCB (even a one-hour weekly meeting) — stop untracked scope drift immediately.
2. Require a 1-page ROI for any non-trivial feature before committing engineering hours.
3. Pilot big features in a controlled environment before full roll-out.
4. Add a “no work without CR” rule and enforce it for one month — you’ll see the backlog clear and true priorities emerge.

I can help you design your requirements and processes around this topic, run implementation workshops and save you potentially millions.

If this resonates – let’s talk.

If the situations I describe sound familiar—and you’re unsure what the next step should be—let’s connect. I help executive teams create clarity, focus, and momentum in complex transformation environments.

When speed and delivery optics become the dominant metric, safety and reality-checks get squeezed out. The Boeing 737 MAX story is a vivid, costly and tragic example of what happens when organizational pressure, normalization of deviance and groupthink overwhelm engineering caution.

Below: the short version of what happened, the hard numbers, the early warning signs to watch for — and the specific interventions I recommend.

---

What happened (short, factual)

• Two similar accidents (Lion Air 610, Oct 29, 2018; Ethiopian Airlines 302, Mar 10, 2019) led to 346 deaths in total and the worldwide grounding of the 737 MAX. Regulators and investigators linked both crashes to the aircraft’s flight-control logic (MCAS) activating on faulty angle-of-attack input and pushing the nose down.

• Investigations and hearings exposed a range of issues: Boeing failed to disclose MCAS behavior adequately to pilots; pilots were not properly trained about the system; design and certification choices reduced redundancy; and there was a broader failure of oversight by regulators. The accidents exposed “normalization of deviance” — small anomalies accepted as normal — and cultural failures inside Boeing.

• The financial and commercial consequences were massive: the grounding and recovery effort created direct costs estimated around US$20 billion and indirect losses higher still (order cancellations, reputational damage). Boeing later reached a criminal-fraud-related settlement and other payouts totaling more than US$2.5 billion under the DOJ agreement.

---

How management reacted — and what was missed

• Pressure to compete: The MAX program had strong commercial pressure to compete with Airbus’s A320neo family. That commercial urgency focused attention on schedule and cost rather than a conservative engineering cadence.
• Design decisions & non-transparency: MCAS was introduced to retain handling characteristics but was not fully documented in pilot manuals; early briefings and risk disclosures were insufficient.
• Regulatory delegation & reduced external challenge: Certification practices that delegated inspection authority to Boeing (and other systemic weaknesses) muted independent scrutiny.
• Normalization of deviance: Small anomalies or “workarounds” became accepted, and warning signals were not escalated effectively.

The practical outcome: risk signals were either downplayed, rationalized, or not elevated fast enough — classic groupthink under production pressure. The result was tragedy, long grounding, legal exposure and enormous financial loss.

---

Early warning signs leaders should watch for

1. Delivery optics become the dominant measure — speed and schedule trumping quality and safety indicators.
2. Shortening or skipping validation cycles — fewer test iterations, cut corners in QA or simulation.
3. Dissent thinning out — previously vocal engineers, operators or frontline staff stop raising concerns.
4. One-voice messaging — presentations and reports accentuate the upside; negative evidence is buried or minimized.
5. Rapid scope compression — “We must ship” becomes a mantra and alternatives/pilots are dismissed.
6. Delegated oversight without independent gates — quality gates owned by delivery teams without neutral reviewers.
7. Normalization language — talk that frames anomalies as “not material” or “we’ve handled this before.”
   If you spot more than one of these signs, treat it as a red flag and act immediately.

---

If you spot the signs — immediate actions I would take as a transformation lead

1) Pause, triage, and create an independent gate

• Stop the sprint. Create an independent risk gate owned by a neutral senior (risk/compliance or an external expert) with authority to pause the program.
• Require a short, focused triage that answers: What are the current failure modes? Who raised them? Were they acted upon?

2) Run a pre-mortem (fast, strict)

• Facilitate a structured “it’s 12 months later and this failed — why?” session. Use a red-team to force alternative scenarios. Capture the top 5 failure causes and immediate mitigations.

3) Re-establish independent verification

• Bring in external subject-matter experts or auditors to validate key assumptions, test data and safety-critical designs. Don’t rely solely on internal sign-off.

4) Rebalance KPIs

• Add and elevate lagging and leading quality/risk KPIs to the dashboard (e.g., number of unresolved safety anomalies, time-to-fix critical defects, rate of dissent flagged). Pair schedule targets with risk burn-down metrics.

5) Protect dissent & whistleblowers

• Implement safe channels for engineers and frontline staff to escalate concerns without career penalties. Publicly reward those who surface risks.

6) Enforce “no big-bang” without pilots

• Where possible, require representative pilots / phased rollouts in operational conditions, with go/no-go criteria pre-agreed and tested.

7) Document decisions (decision logs)

• For every major choice, capture the evidence considered, who argued what, and the rationale — so the organization can retrospectively learn and avoid repeating the same mistakes.

---

Final thought — culture beats checklist, but both are needed

Boeing’s MAX crisis is a stark reminder: even firms with deep engineering heritage can fall prey to groupthink and production pressure. A culture that elevates candour, independent verification and humility — combined with concrete risk gates and pre-mortems — is the only reliable defence. Put another way: process and governance are the scaffolding; culture provides the workers who keep it standing.

---

About the Author
Diethard Engel is a seasoned independent advisor with over a decade of experience in business transformation, post-merger integration, and carve-out readiness. He supports CFOs, CEOs, and Private Equity teams in designing and executing high-impact programs — from industrial portfolio management to organizational and process optimization. With a strong background in Controlling and Financial Management, his expertise also extends into Supply Chain, Procurement, and Business Systems. Diethard works pragmatically, with a personal touch and a clear focus on results — especially in mid-sized companies where fast decision-making is key. Industry experience includes chemicals, machinery & equipment, automotive supply, life sciences, FMCG, professional services, and food production.

(Or: Don’t force the software to fit your bad habits.)

ERP and other enterprise software ship with industry-standard processes for a reason. Vendors and platform teams have observed thousands of implementations and baked best practices into their products. Choosing to adopt those standards — or consciously departing from them — is a strategic decision. Treating it as an ideological one (“this is how we’ve always done it”) is where trouble starts.

Hard fact: ERP projects have a high failure rate when organizations over-customize or fail to align processes to the target system.

Below I explain why the standard is the standard, share two real-world cautionary examples, and give a short, practical playbook for how to adopt a new standard safely — plus the risks and opportunities you should be ready for.

---

Two cautionary examples

Haribo — mapping workflows went wrong
Haribo’s SAP S/4HANA migration exposed a painful truth: insufficient mapping of legacy processes to the new system led to inventory tracking failures and product shortages. The immediate business result was material sales disruption for a core product. This was not a technical bug in isolation — it was a failure to reconcile shop-floor reality with the ERP’s process model.

Target Canada — compressed timelines + new inventory system
Target’s ill-fated Canadian expansion is a textbook case where an aggressive go-live timetable and unready supply-chain systems produced empty shelves, wrong inventory counts and severe reputational damage. Analysts point to new inventory software, rushed cutover and data/operational misalignment as central causes. The lesson: implementing a new standard process at scale without adequate testing and paced rollout creates catastrophic operational risk.

---

Why the “standard” matters

1. Embedded domain knowledge. Vendors encode patterns observed across many customers — they are not random. Using the standard leverages that collective learning.
2. Lower TCO and faster upgrades. Less customization → fewer integration points → easier upgrades and lower long-term cost.
3. Predictable behavior. Standardized processes are easier to test, monitor and govern at scale.

But standards are not gospel. You must evaluate where your business has a genuine, defensible reason to deviate — and where deviation is just legacy inertia.

---

When changing the standard makes sense (and when it doesn’t)

Change the standard if:

• You have a documented, recurring competitive practice that genuinely creates measurable differentiation (e.g., unique pricing model, proprietary manufacturing step).
• You can quantify the expected incremental margin or strategic benefit and it clearly outweighs the customization/maintenance cost.
• You have the resources and governance to carry forward custom code and test it across upgrades.

Don’t change the standard if:

• The reason is “this is how we’ve always done it.”
• The benefit is marginal and hard to measure.
• You can achieve equivalently with minor process redesign or a configuration (not customization).

---

What it takes to adopt a new standard — the execution checklist

1. Executive decision & trade-off mandate
   Senior leadership signs a clear “fit-to-standard” decision: we adopt vendor best practice except for pre-approved deltas. Document the business case for any deltas.
2. Fit-to-Standard workshops (Explore / sandbox)
   Run structured sessions where the vendor shows the preconfigured process in a sandbox; identify gaps by capability (not by habit). Capture deltas explicitly.
3. Reference-class benchmarking
   Compare your process metrics against industry peers to validate whether your way really delivers superior outcomes.
4. Delta-governance & gating
   Only approved deltas proceed to build; each delta must include ROI, test plans, upgrade impact and a 3-year maintenance estimate.
5. Data & master-data cleaning
   Heavy investment up front in data quality and master-data alignment (the most frequent root cause of go-live issues).
6. Pilot → scale approach
   Pilot the standard (and any deltas) in representative sites (top & bottom performers) and validate operationally for a full business cycle before broad rollout.
7. Change management, training, and visual work instructions
   The people side matters. Simple, local language instructions and on-the-job training reduce “workarounds” that reintroduce legacy behavior.
8. Smoke tests and rollback plans
   Define success/failure criteria and automated smoke tests. Have rollback and fallback processes in place for critical customer-impact flows.
9. Upgrade & lifecycle plan
   Treat customization as a product that must be supported through upgrades; budget and ownership must be explicit.

---

Risks (if you force the software to fit old ways)

• Integration fragility — custom code breaks more easily and increases TCO.
• Upgrade paralysis — future upgrades become expensive or impossible without full rework.
• Operational disruption — inventory, order-to-cash and manufacturing flows can fail, harming revenue. (See Haribo / Target.)
• Hidden governance costs — ongoing patches, vendor/sii disputes, and shadow IT.

---

Opportunities (if you adopt the standard sensibly)

• Faster time to value — fewer dev iterations, quicker stabilization.
• Lower long-term cost of ownership — predictable upgrades, smaller support footprint.
• Easier scaling — standardized operations are repeatable across sites/regions.
• Better analytics & transparency — consistent processes generate reliable KPIs.

---

Practical example: a recommended mini-roadmap (3 high-level milestones)

1. Decision & Discovery (4–6 weeks) — Fit-to-Standard workshops, select pilots, map deltas and run ROI tests.
2. Pilot & Validate (8–12 weeks) — Deploy standard + approved deltas in 2 representative sites (one top, one bottom), test hard for a full operating period.
3. Scale & Govern (12–24 weeks) — staged rollout, training, governance, upgrade plan, and metrics dashboard.

---

A final, blunt thought

Industry-standard processes are not arbitrary. They’re codified experience. That doesn’t mean never customize — but it does mean you must choose customization deliberately, with full transparency on cost, upgrade-risk and operational testing. Too many high-profile failures (Haribo, Target Canada and others) began with the same human error: treating process as identity rather than as a lever to improve.

Want to talk through a concrete decision framework you can apply to your ERP or operating-model program? I can help you run a focused fit-to-standard workshop, identify defensible deltas, and design a pilot that protects the business while unlocking faster value. Connect with me on LinkedIn or by email: diethard.engel @ de-mcs.de.

J.C. Penney’s $1B loss under a celebrated CEO wasn’t about strategy—it was about overconfidence. The Dunning–Kruger Effect shows up in change management more often than we admit: leaders underestimate complexity, teams assume they’ll “figure it out,” and culture gets sidelined.

In my new article, I explore how this bias derails transformations—and what to do instead.

Another Cautionary Tale: The Dunning–Kruger Effect in Change Management — When Overconfidence Derails Transformation

Consider J.C. Penney’s 2012–13 transformation under CEO Ron Johnson—a proven executive from Apple and Target. He confidently rolled out “fair and square” pricing and drastically redesigned stores. But he underestimated how deeply customers valued coupons and markdowns. He moved fast, but without testing or aligning with the brand’s culture. Within 14 months, revenue had fallen 25%, the company lost nearly $1 billion, and thousands of jobs were cut.

This dismissal of core stakeholders and cultural dynamics is a textbook case of the Dunning-Kruger Effect in transformation initiatives.

---

What Is the Dunning–Kruger Effect?

At its core, it’s a cognitive bias: those with limited knowledge often overestimate their competence, while experts tend to underestimate it.

In transformation contexts:

• Leaders may assume change is simple: “just tweak processes,” or “everyone will adapt.”
• Teams may overload under the assumption that “we’ll figure it out.”

---

Why It Matters in Change Management

Change is complex, high-stakes, and fraught with resistance.

The Dunning–Kruger Effect manifests as:

• Ignoring stakeholder pushback
• Rushing without embedding governance or testing
• Overconfidence in “patch-on-the-fly” solutions

And the consequences? Delayed returns, broken morale, failed programs.

---

A Framework to Mitigate It

1. Diagnose before you decide—use structured interviews, quick diagnostic sprints to ground assumptions.
2. Surface hidden risks—on culture, governance, stakeholder alignment.
3. Bring in experienced leadership early—not just internal availability.
4. Test early, iterate fast—pilot first, scale later.
5. Stay humble—be prepared to course correct mid-transformation.

---

Why Familiarity Matters

Transformations often fail not for lack of intent, but because they’re treated like “change on the side.” The Dunning–Kruger trap lies in ignoring the hidden layers—culture, governance, resistance, and BAU alignment.

Skill, experience, and discipline are not optional. Without them, transformation becomes a mirage.

Transformation doesn’t fail because of strategy. It fails because the business can’t execute change while keeping day-to-day operations running.

I’ve seen this pattern again and again:

• Management is already at 120% capacity.
• A major transformation or integration lands on top.
• Leadership is expected to run BAU and lead the program. The result? Delays, firefighting, stalled projects, missed synergies — and, most critically, lost business performance.

That’s why I built the Operate-while-Transform capacity model. It protects BAU while accelerating transformation.

---

The Core Idea

Business-as-usual must not suffer because of transformation. Shareholders expect performance and change. To deliver both, we need a deliberate capacity model that frees bandwidth for transformation without risking revenue, customers, or employees.

---

How it Works

1. Capacity Scan Map management workload. Where is leadership consumed by routine? Where is true change capability hidden?

2. Offload Routine Work Shift recurring or transactional activities (reporting, approvals, admin) downward or outward. Create air cover for managers.

3. Sharpen Decision Forums Redesign meeting cadence and governance so leaders spend time on decisions and priorities, not updates or firefighting.

4. External Program Muscle Bring in experienced transformation leaders to drive structure, speed, and orchestration. Execution discipline comes from outside, not from overstretched insiders.

5. BAU Health Check Track operational KPIs (OTD, revenue, customer metrics) in parallel with transformation KPIs. If BAU slips, you re-balance early.

---

What It Takes

Even the best-designed capacity model fails without top management’s true commitment.

• Leaders must prioritize change alongside BAU, not treat it as optional.
• They must protect time and attention, resisting the temptation to drown the program in unnecessary meetings, reviews, or politics.
• They must walk the talk: if management drags its feet, employees will too.

In short: Operate-while-Transform works only if leaders want it to work.

---

Why It Works

• Speed: Freed-up capacity accelerates execution.
• Focus: Leaders can actually lead transformation instead of juggling tasks.
• Security: BAU KPIs stay in view — ensuring no loss of revenue or customers.
• ROI: Faster execution means faster synergies, earlier cash impact, and higher deal value.

---

The Payoff

When you protect BAU and accelerate transformation, value lands earlier:

• Synergies realized faster
• Costs reduced earlier
• Growth captured without losing customers
• Employees stay engaged — because daily work doesn’t collapse under the weight of change

---

💡 Operate-while-Transform isn’t about working harder. It’s about designing capacity deliberately so transformation can succeed without breaking the business you’re transforming.