Warum Microsoft Dynamics 365-Projekte scheitern – Ein Fallbeispiel aus einem Millionenprojekt

Großprojekte in der IT gelten seit Jahrzehnten als riskant. Studien zeigen konsistent, dass ein erheblicher Anteil der Vorhaben ihr Ziel verfehlt: Eine gemeinsame Untersuchung von McKinsey und der University of Oxford zu über 5.400 IT-Projekten kommt zu dem Ergebnis, dass große IT-Projekte im Durchschnitt 45 % über Budget liegen, 7 % länger dauern und dabei 56 % weniger Wert liefern, als ursprünglich prognostiziert wurde (McKinsey/Oxford-Studie, 2012).

Die Standish-„CHAOS“-Reports berichten für IT- und Softwareprojekte seit vielen Jahren ähnliche Tendenzen: Der Anteil wirklich erfolgreicher Projekte liegt je nach Jahrgang im Bereich von 16–31 %, während der Rest verspätet, über Budget, mit reduzierter Funktionalität oder ganz abgebrochen endet (z. B. Zusammenfassung hier: CHAOS Report).

Vor diesem Hintergrund ist das folgende Fallbeispiel kein Ausrutscher, sondern ein symptomatischer Ausschnitt aus einer strukturellen Problemlage.

Kontext: Microsoft Dynamics 365 Field Service im Konzernumfeld 

Ich arbeitete in einem Konzernprojekt mit einem Joint Venture aus Accenture und Microsoft zusammen – einem Dienstleister im Microsoft Dynamics 365-Ökosystem, der im Markt explizit für seine technische Expertise im Microsoft-Umfeld positioniert ist. Aufgabe war die Implementierung von Microsoft Dynamics 365 Field Service für einen komplexen, operativen Servicekontext.

Field Service – als Bestandteil von Microsoft Dynamics 365 – ist von Natur aus ein hochgradig vernetztes System: Ressourcenplanung, Einsatzsteuerung, mobile Abläufe, Serviceprozesse, SLA-Logik, Datenmodelle und Schnittstellen zu ERP und CRM innerhalb der Microsoft Dynamics 365-Landschaft greifen ineinander. Entsprechend hoch sind die Anforderungen an Architektur, Anforderungsanalyse und das Zusammenspiel zwischen Fachbereich und Implementierungspartner im Microsoft Dynamics 365-Umfeld.

Meine ursprüngliche Erwartung war schlicht: Hier treffe ich auf hohe Kompetenz. Das wird fachlich herausfordernd, aber strukturiert ablaufen.

Diese Erwartung wurde nicht erfüllt.

Erwartete Exzellenz – gelieferte Ratlosigkeit

Aus Sicht der Projektpraxis zeigten sich mehrfach Muster, die in der Literatur zu gescheiterten IT-Projekten als typische Risikofaktoren beschrieben werden (vgl. z. B. McKinsey/Oxford 2012; Standish CHAOS Report):

  1. Anforderungen werden bestätigt, ohne verstanden zu werden.
    In einer Sitzung wurden fachliche Anforderungen mit einem schnellen „Ja, das machen wir so“ bestätigt. In der Folgesitzung hieß es: „Das geht technisch nicht.“ In der darauffolgenden Sitzung wiederum: „Wir haben doch noch einen Weg gefunden.“ Diese Schwingbewegung war weniger Ausdruck technischer Limitierungen als vielmehr ein Indiz dafür, dass die zugrunde liegende Logik weder sauber analysiert noch systemisch modelliert worden war.
  2. Fehlende Rückfragen und mangelnde Exploration der Problemräume.
    Es wurden kaum Rückfragen gestellt – weder zu fachlichen Prioritäten noch zu Pain Points, Randbedingungen oder Skalierungsperspektiven. Die eigentliche Idee hinter den Anforderungen blieb oft unberührt. Statt systemischer Exploration dominierte ein lineares Abarbeiten und gelegentliches Wegducken.
  3. Technische Zusagen ohne architektonische Basis.
    Zusagen kollabierten, sobald man tiefer in das System einstieg. Je genauer wir in die Verknüpfung aus Prozessen, Datenmodell und Automatisierungen schauten, desto klarer wurde: Es fehlte nicht an einzelnen Technologiekenntnissen, sondern an Architektur, Ownership und Systemarchitektur.
  4. Anpassung der Kundenanforderungen an die begrenzte Perspektive des Dienstleisters.
    Ein wiederkehrendes Muster bestand darin, Anforderungen stillschweigend auf den begrenzten Lösungsraum des Implementierungspartners „zurechtzustutzen“. Anstatt gemeinsam zu klären, was fachlich zwingend war und wo alternative technische Wege denkbar wären, wurde der Scope implizit verschoben. Nach mehreren Runden, in denen der Fortschritt ausblieb, wurde schließlich ein zusätzlicher Experte hinzugezogen, der erstmalig eine konsistente Sicht auf die Problemstellung und sinnvolle Architekturvorschläge einbrachte. Praktisch ersetzte er damit den bisherigen Entwickler funktional – organisatorisch jedoch blieb die ursprüngliche Rolle bestehen. Das führte zu Doppelstrukturen, Abstimmungsaufwand und spürbaren Spannungen im Team: Der eine Entwickler war damit beschäftigt, seine Präsenz zu rechtfertigen; der andere versuchte, fachlich voranzukommen, ohne den Kollegen bloßzustellen. Die Reibungsverluste waren entsprechend hoch.

Diese Dynamiken sind aus der Forschung zu IT-Projektversagen bekannt: Unklare Rollen, fehlende Governance, mangelhafte Anforderungsanalyse und divergierende Perspektiven zwischen Fachbereich, IT und Dienstleistern zählen regelmäßig zu den Hauptgründen für Termin- und Budgetüberschreitungen sowie gescheiterte Einführungen (vgl. u. a. McKinsey/Oxford 2012; Überblick zu Fehlertypen z. B. hier: 3Pillar Global – Why Software Projects Fail

Eskalationspunkt: Wenn Stakeholder mundtot gemacht werden sollen

Ein kritischer Wendepunkt im Projekt war eine Situation, in der ein fachlich erfahrener Stakeholder eine präzise und aus Sicht des Geschäfts zwingende Anforderung formulierte. Da das Implementierungsteam diese Anforderung offensichtlich nicht abbilden konnte, versuchte man, das Problem nicht technisch, sondern kommunikativ zu lösen.

Konkret fiel sinngemäß der Vorschlag, man müsse „mit dem CEO sprechen, der diesem Team solche Freiheiten gibt“. Anders formuliert: Statt die eigene technische und architektonische Limitierung zu reflektieren, wurde das Verhalten des Stakeholders problematisiert.

In einem Projekt mit siebenstelligem Budget ist das ein deutliches Warnsignal:
Hier wird nicht mehr an der Lösung gearbeitet – hier werden Verantwortlichkeiten verschoben.

Die „Change-Management“-Figur als Feigenblatt

Als die Dysfunktionalität der Zusammenarbeit kaum noch zu übersehen war, kam ein weiterer Vorschlag: Man solle ein separates Change-Management-Projekt aufsetzen.

Change Management ist in komplexen Transformationsprojekten grundsätzlich sinnvoll und notwendig. In diesem Kontext wurde es jedoch als Erklärungsmuster genutzt, um die Probleme auf die Kundenseite zu verschieben: Die Nutzer seien „nicht bereit“, man müsse „die Organisation mitnehmen“ usw.

Im konkreten Fall war die Lage jedoch anders gelagert:

  • Die fachlichen Anforderungen waren klar und konsistent formuliert.
  • Es gab Stakeholder mit hoher Domänenexpertise und klarer Zielsetzung.
  • Die Blockaden lagen nachweislich in Architektur, Umsetzung und Kommunikation – nicht in einer „fehlenden Change-Bereitschaft“.

An diesem Punkt habe ich als Product Owner klar widersprochen und formuliert: Wir benötigen kein Change Management als Zusatzdienstleistung, sondern eine passende Lösung, die die tatsächlichen Anforderungen erfüllt. Change Management kann eine mangelhafte Architektur nicht kompensieren.

In der Literatur zu gescheiterten ERP- und Dynamics-Implementierungen taucht dieses Muster immer wieder auf: fehlende Projektgovernance, unklare Verantwortlichkeiten, unterschätzte Komplexität und Dienstleister, die ihre eigenen Defizite eher externalisieren als adressieren (vgl. z. B. Fallstudien zu gescheiterten Dynamics‑365‑Einführungen: Centric Consulting).

Standardisierung innerhalb von Microsoft Dynamics 365-Implementierungen vs. Systemarchitektur

In fast allen größeren IT-Landschaften wird heute – zurecht – auf Standardisierung geachtet: Standardsoftware, Standardprozesse, Standard-Schnittstellen. Aus Sicht von Betrieb, Sicherheit, Compliance und Wartbarkeit ist das nachvollziehbar.

Problematisch wird es dort, wo „Standard“ mit „ausreichende Lösung“ verwechselt wird.

Standardkomponenten bieten ein technisches Fundament, aber sie lösen nicht automatisch die konkrete Problemstellung eines Unternehmens. Sie „denken“ nicht:

  • Sie priorisieren nicht zwischen widersprüchlichen fachlichen Anforderungen.
  • Sie erkennen keine architektonischen Zielkonflikte.
  • Sie balancieren nicht zwischen heutiger Prozessrealität und zukünftiger Skalierung.

Für dieses Denken in Systemen braucht es eine Rolle, die in vielen Projekten systematisch unterbesetzt ist: die Systemarchitektin bzw. den Systemarchitekten.

Ein Systemarchitekt (oder Systems Architect) wird in der Literatur als Person beschrieben, die die Architektur komplexer Systeme so gestaltet, dass technische Komponenten, Prozesse und Stakeholderziele konsistent aufeinander abgestimmt werden (vgl. z. B. Überblick bei Wikipedia-Eintrag „Systems architect“).

Typische Aufgaben dieser Rolle sind u. a.:

  • die Verbindung von Geschäftsanforderungen mit technischen Lösungsansätzen,
  • das Denken in Szenarien und Alternativen,
  • das frühzeitige Erkennen von Architekturrisiken,
  • das Sicherstellen, dass lokale Entscheidungen das Gesamtsystem nicht destabilisieren,
  • das Moderieren zwischen Fachbereichen, Management und Entwicklungsteams.

Genau diese Perspektive fehlte im beschriebenen Projekt weitgehend. Einzelne Experten versuchten, punktuell gegenzusteuern, aber die Rolle einer übergeordneten Systemarchitektur – mit Mandat und Verantwortung – war faktisch nicht verankert.

Vor diesem Hintergrund ist die Aussage, für „Standardlösungen“ keine Millionen investieren zu wollen, kein Ausdruck von Engstirnigkeit, sondern eine nüchterne Abwägung:
Standard ist notwendig – aber nicht hinreichend. Investitionsvolumen in dieser Größenordnung rechtfertigt sich nur, wenn jemand die Verantwortung für die architektonische Kohärenz übernimmt.

Strukturelle Muster hinter dem Einzelfall

Die geschilderte Erfahrung ist biografisch, aber sie steht nicht isoliert. Sie verweist auf strukturelle Muster, die in vielen empirischen Untersuchungen zu IT-Projekten auftauchen:

  • Fehlende Systemarchitektur: Technologie wird implementiert, ohne das umgebende sozio-technische System (Organisation, Rollen, Entscheidungslogik, informelle Strukturen) mitzudenken.
  • Komplexität wird unterschätzt: Die scheinbare „Standardlösung“ wird als Plug-and-Play verstanden, obwohl Field Service, ERP und CRM in hochdynamischen Kontexten eine anspruchsvolle Architektur verlangen.
  • Verantwortungslücken zwischen Kunde und Dienstleister: Unklare Governance, diffuse Zuständigkeiten und die Tendenz, Probleme kommunikativ statt strukturell zu lösen.
  • Externe Partner ohne echte Systemarchitekturkompetenz: Dienstleister, die primär in Features und Konfiguration denken, nicht in Systemen und Wirkzusammenhängen.

Vor diesem Hintergrund erscheint die eingangs zitierte Statistik – dass große IT-Projekte im Durchschnitt massiv Budget überschreiten und deutlich weniger Wert liefern als geplant – weniger wie ein Zufall, sondern wie eine Konsequenz struktureller Blindstellen (vgl. McKinsey/Oxford-Studie, Zusammenfassung oder Flyvbjerg, „The Empirical Reality of IT Project Cost Overruns“, 2022)

Fazit: Warum Systemarchitektur in Microsoft Dynamics 365-Projekten kein „Nice-to-have“ ist

Aus meiner Sicht zeigt das Fallbeispiel deutlich:

Projekte scheitern selten an der Technologie selbst – sie scheitern an fehlendem Systemarchitektur und fehlender Architekturverantwortung.

Genau hier setze ich als Komplexitätsarchitektin an.

  • Ich analysiere technische Entwicklungsmuster, Prozesslogiken und Abhängigkeiten, bevor sie zu Blockaden werden.
  • Ich mache unsichtbare Spannungen zwischen Fachlichkeit, Technik und Organisation sichtbar.
  • Ich helfe, Lösungen zu gestalten, die nicht nur „konfigurierbar“, sondern tragfähig sind.

Microsoft Dynamics 365 Millionenprojekte dürfen nicht an Inkompetenz oder strukturellen Blindstellen scheitern – und sie müssen es auch nicht.
Die Investition in Systemarchitektur und echtes Systemarchitektur ist im Vergleich zu den Folgekosten gescheiterter Projekte gering – aber sie entscheidet oft darüber, ob aus Komplexität nachhaltiger Wert entsteht oder nur ein weiterer Eintrag in der Statistik gescheiterter IT-Projekte.

Wenn solche Situationen in deinem Unternehmen entstehen, liegt das selten am Einzelfall – sondern an strukturellen Mustern, die sich analysieren lassen.

Q&A – Häufige Fragen zu gescheiterten Microsoft Dynamics 365-Projekten

Q: Warum scheitern so viele Microsoft Dynamics 365-Projekte trotz hoher Budgets?
A: Studien zeigen, dass die Hauptursachen nicht in der Technologie liegen, sondern in fehlendem Systemarchitektur, mangelhafter Architektur, unklaren Rollen sowie unzureichender Anforderungsanalyse. Microsoft Dynamics 365 ist ein mächtiges System – aber nur dann erfolgreich, wenn komplexe Wechselwirkungen strukturiert analysiert und geführt werden.

Q: Was hätte dieses konkrete Millionenprojekt retten können?
A: Eine klar definierte Systemarchitekturrolle, tiefere Analyse der Prozesslogik, professionelle Übersetzung der Business-Anforderungen in Architekturentscheidungen, funktionierende Governance und ein Implementierungspartner, der sowohl technisch als auch systemisch denkt.

Q: Ist Microsoft Dynamics 365 selbst ein Risiko?
A: Nein. Dynamics 365 ist stabil und skalierbar. Die Risiken entstehen nicht im Produkt, sondern in Projekten, in denen technische, organisatorische und prozessuale Aspekte getrennt voneinander betrachtet werden. Ohne Systemarchitektur entsteht Fragmentierung – und damit Scheitern.

Q: Wie erkennt man früh, ob ein Dynamics‑365‑Projekt auf ein Scheitern zusteuert?
A: Warnsignale sind: Sprunghafte technische Aussagen, fehlende Rückfragen des Dienstleisters, Konflikte zwischen Fachbereich und IT, zunehmende Change‑Requests ohne klaren Grund, fehlende Transparenz und das Verschieben von Verantwortlichkeiten. Diese Muster sind empirisch gut dokumentiert.

Q: Was sollten Unternehmen bei Microsoft Dynamics 365-Projekten unbedingt vermeiden?
A: Den Glauben, dass „Standard“ ohne Systemarchitektur reicht. Dynamics‑Implementierungen benötigen eine klare, übergreifende Architektur – nicht nur Konfiguration.

Weiterführende Themen

  1. Executive Coach beauftragen? Diese Red Flags sollten CEOs vorher kennen
  2. Plötzlich Chef: Warum inkompetente Führungskräfte Unternehmen Geld kosten
  3. Warum viele „KI-Experten“ falsch liegen – die 4 größten Irrtümer
  4. Toller Job – oder versteckter Karriere-Killer?
  5. Vietnam löscht Millionen Bankkonten: Biometrische Verifizierung und Cyberangriffe als Vorwand?

👉 Wenn du verstehen willst, welche Risiken solche Entwicklungen konkret für Unternehmen haben – ich habe dazu einen Report erstellt.

Autorin von Global Insight Group Intelligence:

Michaela Schaaf-Hoffelner verfügt über mehr als 35 Jahre Erfahrung im technischen Projektmanagement und in der Analyse komplexer Transformationsprozesse.
Ihr Fokus liegt nicht nur darauf, strukturelle Risiken sichtbar zu machen, sondern vor allem darauf, die darin verborgenen Muster zu erkennen – und sie in konkrete strategische Vorteile zu übersetzen.