Chief Transformation-Operations-Finance-Information-Technology-HR Officer

Chief Everything Officer – wenn einer alles richten soll

Kennen Sie das? Da soll ein einzelner Interim Manager eine Transformation leiten
…und gleichzeitig CFO-Aufgaben übernehmen,
…die IT neu aufstellen,
…HR-Prozesse restrukturieren,
…und natürlich: das Tagesgeschäft am Laufen halten.

Klingt nach einem Superhelden mit Doppelabschluss in Rocket Science und Zen-Meditation. In Wahrheit passiert nämlich Folgendes:

👉 Fokus verwässert.
👉 Prioritäten verschwimmen.
👉 Fortschritt bleibt auf der Strecke.

Transformation braucht keine Superhelden. Sie braucht Struktur, Klarheit und Rollen, die voneinander getrennt sind:

🟦 CFO / COO → halten das Geschäft stabil
🟦 CTrO (Chief Transformation Officer) → schafft Kapazität, priorisiert und führt durch die Veränderung
🟦 HR / IT / Operations Leads → tragen Verantwortung in ihren Domänen

Erst wenn diese Rollen sauber getrennt sind und alle an einem Strang ziehen entsteht Geschwindigkeit – und echte Veränderung.

Kommt Ihnen das bekannt vor?
Wenn Sie in einer ähnlichen Situation sind und merken, dass „alles bei Ihnen landet“ – dann lassen Sie uns sprechen. Ich unterstütze Führungsteams dabei, Klarheit, Fokus und Dynamik in komplexe Programme zu bringen.

Die eierlegende Wollmilchsau der Transformation

Spoiler: Sie existiert nicht.

Vor kurzem bekam ich eine Anfrage:

„Wir brauchen jemanden für die Planung und Durchführung eines Carve-outs, der gleichzeitig auch die CFO-Rolle übernimmt, die Abschlüsse nach HGB und IFRS erstellt, die Liquidität plant und das Stakeholder Management führt.“

Klingt nach einem soliden Konzept – wenn man Märchen mag.

Prima, wenn die Erkenntnis gereift ist, dass man „es alleine nicht schafft“. Aber hier ist der Punkt: Ein Transformation Program Director oder Chief Transformation Officer (CTrO) ist kein Super-CFO mit Nebenjob im Change Management.
Seine Aufgabe ist nicht, Belege zu buchen oder Monatsabschlüsse zu erstellen.
Er sorgt dafür, dass ein Once-in-a-Decade-Projekt gelingt – mit Struktur, Governance und Fokus.

👉 Der CTrO schafft Kapazität, Klarheit und Geschwindigkeit – damit das Management den Kopf frei hat für Entscheidungen.
👉 Das Tagesgeschäft gehört in die Hände erfahrener Finance- und Operations-Manager – sie sichern Kontinuität und Datenintegrität.
👉 Nur gemeinsam funktioniert es: Der CFO hält den Laden am Laufen, der CTrO baut das neue Haus.

Wer versucht, beides gleichzeitig zu tun, verliert den Überblick – und am Ende auch das Momentum.

Was tun?

  • Klare Rollen definieren: Wer führt das Business, wer führt die Veränderung?
  • Governance aufsetzen, die Entlastung ermöglicht – nicht zusätzliche Komplexität.
  • Transformation als eigenes Projekt mit klaren Verantwortlichkeiten behandeln – nicht als „Nebenaufgabe“.

💬 Kommt Ihnen das bekannt vor?
Wenn Ihre Organisation versucht, Transformation nebenbei zu stemmen, sollten wir sprechen. Ich helfe Führungsteams, Kapazität, Fokus und Umsetzungssicherheit in anspruchsvollen Veränderungsvorhaben zu schaffen.

Maschinen- und Anlagenbau: Wenn Sales Maschinen verkauft, die es (so) nicht gibt

Warum falsche Versprechen teuer werden – und wie Unternehmen sie vermeiden können.

Flexibilität, Ingenieurskunst und Kundenorientierung – das sind die Stärken des deutschen Maschinen- und Anlagenbaus. Doch gerade diese Stärken können zur Schwäche werden, wenn sie ungebremst aufeinanderprallen.

Ich habe es in zahlreichen Projekten gesehen: Der Vertrieb verkauft eine Anlage, die technisch so nicht umsetzbar ist. Das ist keine Absicht, oft Zeitdruck geschuldet, oder dem Wunsch, den Auftrag zu sichern.

Das Ergebnis kennt jeder, der in der Branche arbeitet:

  • Nachträgliche Änderungen, Zusatzaufwand im Engineering
  • Verzögerungen in der Montage und Inbetriebnahme
  • Reklamationen, Claims, Pönalen

Frust auf allen Seiten – intern wie extern. Und vor allem: Margen, die schmelzen. Wo die Ursache liegt:

👉 Fehlende Diligence in der Angebotsphase – zu wenig technische Prüfung, bevor das Angebot rausgeht
👉 Keine Einbindung von Engineering und Einkauf – Restriktionen werden zu spät bekannt
👉 Unklare Lastenhefte – Kundenwünsche sind nicht präzise dokumentiert
👉 Unerfüllbare Leistungsparameter – überambitionierte Versprechen
👉 Übergabechaos zwischen Vertrieb und Projektmanagement – was verkauft wurde, ist oft nicht das, was gebaut wird
👉 Kein strukturiertes Nachtrags-Management – Änderungen bleiben unvergütet, weil niemand sauber dokumentiert

Die Lösung: Struktur schlägt Improvisation

Erfolgreiche Unternehmen haben aus diesen Problemen gelernt. Was sie tun, lässt sich in fünf Prinzipien zusammenfassen:

1️⃣ Frühe technische Machbarkeitsprüfung
Jede Kundenanfrage durchläuft ein „Technical Feasibility Gate“, bevor ein Angebot erstellt wird.
2️⃣ Klare Abstimmungsprozesse
Lastenheft vom Kunden, Pflichtenheft vom Anbieter – mit verbindlicher technischer Freigabe beider Seiten.
3️⃣ Standardisierte Übergabeprozesse
Zwischen Vertrieb, Engineering, Einkauf und Projektmanagement – mit klaren Verantwortlichkeiten und Freigaben.
4️⃣ Claim- und Nachtragsmanagement als Standardprozess
Änderungen dokumentieren, bewerten, verhandeln – nicht improvisieren.
5️⃣ Lessons Learned nutzen

Systematische Rückkopplung von Projekterfahrungen in Vertrieb und Engineering – um Fehler nicht zu wiederholen.

Der Effekt: Weniger Claims, mehr Marge

Ich habe mit einem Kunden genau diesen Ansatz umgesetzt. Das Ergebnis nach sechs Monaten:

✅ Klare Abläufe in Angebot, Übergabe und Projektsteuerung
✅ Weniger ungeplante Änderungen
✅ Nachträge konsequent verhandelt
✅ Schnellere Abnahmen
✅ Deutlich verbesserte Margen

Fazit

Kunden wollen Lösungen, nicht Versprechen. Wenn Sales und Engineering Hand in Hand arbeiten, entstehen nicht nur bessere Projekte – sondern auch profitablere.

Kommt Ihnen das bekannt vor?

Wenn in Ihrem Unternehmen Vertrieb, Technik und Projektmanagement nicht im Gleichklang arbeiten, ist das kein Einzelfall – aber es ist lösbar.

Ich helfe Führungsteams im Maschinen- und Anlagenbau, Struktur, Klarheit und Fokus in ihre Organisation zu bringen – damit Versprechen profitabel werden. Sprechen Sie mich an – ich kann auch Ihnen helfen.

Wenn Leadership zur Engstelle wird

Warum Transformation an zu viel „Wollen“ scheitert

Es ist ein vertrautes Szenario:
Der CEO und sein Führungsteam erkennen, dass die Integrations- oder Transformationsbemühungen ins Stocken geraten sind.
Zu viele Projekte, zu wenig Fortschritt, sinkende Motivation.

Also zieht sich das Team in Klausur zurück, um Ordnung zu schaffen.
Ein Tag intensiver Diskussionen folgt. Die Wände sind voll mit Flipcharts, Whiteboards und Post-its.
Ergebnis?
Alles ist wichtig. Nichts ändert sich.


Das Leadership-Dilemma

Transformationen scheitern selten an der Einsicht, dass sich etwas ändern muss.
Sie scheitern daran, dass Führungsteams nicht konsequent priorisieren.

Leadership heißt:

  • Den Mut haben, Nein zu sagen.
  • Ressourcen gezielt zu bündeln.
  • Entscheidungen treffen – und sie auch stehen zu lassen.

Wenn alles Priorität 1 ist, hat in Wahrheit nichts Priorität.

Das Ergebnis:

  • Teams verlieren Fokus.
  • Projekte überlagern sich.
  • Reporting und Meetings ersetzen Fortschritt.
  • Die Organisation ermüdet.

Fünf Hebel für CEOs, um Fokus und Führung zurückzugewinnen

1️⃣ Klarheit schaffen
Definieren Sie 3–5 zentrale Ergebnisse, die wirklich zählen.
Nicht Themen, nicht Aktivitäten – sondern messbare Resultate.

2️⃣ Priorisieren, was Wert schafft
Fragen Sie: „Was bringt uns jetzt dem strategischen Ziel am nächsten?“
Alles andere kommt auf die Liste für später.

3️⃣ Verantwortung verankern
Jedes Thema braucht einen Owner – mit Zeit, Entscheidungskompetenz und Commitment.

4️⃣ Kapazität schaffen
Transformation braucht Raum. Entlasten Sie Ihr Top-Team vom Tagesgeschäft, anstatt ihnen Transformation „on top“ aufzubürden.

5️⃣ Fokus halten – konsequent
Schützen Sie Ihr Programm vor internen Ablenkungen.
Ein CEO, der jeden Tag neue Prioritäten setzt, ist der größte Saboteur seiner eigenen Transformation.


Wenn Leadership zur Engstelle wird

Viele CEOs glauben, sie müssten mehr Themen auf die Agenda bringen, um Fortschritt zu erzeugen.
In Wahrheit entsteht Fortschritt, wenn man weniger – aber das Richtige – tut.

Transformation erfordert Mut zur Entscheidung.
Und den Willen, den Kurs zu halten – auch wenn es unbequem wird.

When Engineers “Improve” the Product into Oblivion

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.

Groupthink & Production Pressure — The Boeing 737 MAX lesson for transformation leaders

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.

Why “Industry-Standard” Exists — and what happens when you insist on changing it

(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.

The Dunning-Kruger Effect in Change Management — When Overconfidence Derails Transformation

A Cautionary Tale: The Lidl ERP Disaster (Manufacturing/ Retail & Supply Chain)

In 2011, Lidl, the German supermarket chain, launched a new SAP-based inventory ERP system aimed at modernizing its logistics—a monumental transformation for a retailer tightly linked to manufacturing and supply chain operations. However, the project quickly unraveled. Lidl’s custom record-keeping method—based on purchase price rather than retail price—didn’t align with SAP’s standard structure. This misalignment required massive customization and ultimately pushed the system to collapse. After seven years and around $580 million in losses, Lidl abandoned the project and reverted to its legacy system. The project’s failure led to executive exits at the leadership level.

This episode is a perfect illustration of the Dunning-Kruger Effect in large-scale transformation: leadership overestimated their ability to “make it work” without understanding the inherent complexity and misalignment with business culture.


What Is the Dunning-Kruger Effect?

This cognitive bias occurs when individuals with limited knowledge or experience overestimate their competence—while experts often underestimate theirs. It’s summarized as:

  • „Overconfidence among the unqualified.“ In transformations, this means thinking you can “wing it” without structure because you’ve led programs before. Reality often bites hard.

Why It Matters in Change Management

Changes like ERP rollouts or organizational restructuring are once-in-a-decade, high-stakes programs. Ignoring complexity—or relying only on internal resources—invites massive risk.

In Lidl’s case:

  • Custom record-keeping clashed with the out-of-the-box ERP design.
  • Underestimated complexity snowballed into multi-year, multi-hundred-million-dollar failure.
  • Executive turnover and unanswered key strategic questions led to unclear direction and program governance.

How to Avoid the Trap: A Better Approach

  1. Diagnose early. Run quick discovery sprints to map business logic vs. system requirements.
  2. Accept change. Clinging to dear processes and methods even in the face of transformation is a recipe for disaster.
  3. Recognize complexity. Especially when culture, process, and system don’t align.
  4. Bring in experience. Don’t rely on internal availability; use experts for structure and integration.
  5. Test small, pilot fast. Validate before big-bang rollout.
  6. Maintain operational integrity. Protect BAU — failure often derails supply, revenue, and customer trust.

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.

Operate-while-Transform: Protecting BAU While Driving Change

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.