Warum „Best Practices“ im Projektmanagement oft schaden

„Das ist Best Practice.“ Kaum ein Satz beendet Diskussionen im Projektmanagement schneller. Eine Methode hat sich anderswo bewährt. Also wird sie übernommen. Das Problem: Projekte unterscheiden sich in Risiko, Komplexität, Technologie, Regulierung, Teamstruktur und Unsicherheit. Genau deshalb können vermeintlich bewährte Vorgehensweisen die falsche Wirkung entfalten. Warum „Best Practices“ im Projektmanagement oft schaden, liegt nicht an den Methoden selbst. Kritisch wird es, wenn Unternehmen sie ohne Kontext übernehmen. Professionelles Projektmanagement kopiert keine Rezepte. Es versteht Prinzipien, bewertet den Projektkontext und entscheidet bewusst, welche Praktiken tatsächlich helfen.

Best Practices sind Vorgehensweisen, Methoden oder Instrumente, die sich in bestimmten Situationen wiederholt als hilfreich erwiesen haben.

Typische Beispiele sind:

Das Problem beginnt beim Begriff „best“.

Er suggeriert:

Diese Vorgehensweise ist anderen überlegen.

Unabhängig davon, wo und wie sie eingesetzt wird.

Genau das ist bei Projekten selten der Fall.

Das Project Management Institute formuliert den Gegenentwurf inzwischen sehr deutlich. Die aktuelle achte Ausgabe des PMBOK Guide von 2025 betont Anpassungsfähigkeit und Tailoring ausdrücklich. Praktiken, Werkzeuge und Techniken sollen an Team, Organisation und Projektumfeld angepasst werden.

Die entscheidende Frage lautet deshalb nicht:

„Was ist Best Practice?“

Sondern:

„Was ist für dieses Projekt unter diesen Bedingungen die passende Praxis?“

Die Unterscheidung wirkt sprachlich klein.

In der Anwendung ist sie entscheidend.

Best Practice suggeriert eine optimale Vorgehensweise.

Good Practice beschreibt dagegen eine bewährte Möglichkeit, die sich in bestimmten Kontexten als sinnvoll erwiesen hat.

Professionelles Projektmanagement arbeitet eher mit Good Practices.

Denn Projekte sind per Definition einzigartig.

Ein millionenschweres regulatorisches Transformationsprogramm benötigt eine andere Steuerung als:

Schon frühe Forschung zu Projektmanagement-Ansätzen kam nach Untersuchungen von mehr als 600 Projekten und über 1.000 Interviews zu einem klaren Ergebnis: Projekte unterscheiden sich erheblich, und der Managementansatz muss zu Projektart und Kontext passen. Ein „One size fits all“-Ansatz führte in den untersuchten Umfeldern wiederholt zu Problemen und Verzögerungen.

Eine erfolgreiche Organisation arbeitet mit Scrum.

Ein anderes Unternehmen übernimmt Scrum.

Ein Konzern verwendet ein umfangreiches Stage-Gate-Modell.

Eine kleinere Organisation führt dieselben Gates ein.

Ein PMO besitzt 15 verpflichtende Templates.

Das nächste PMO übernimmt dieselben Vorlagen.

Dabei wird häufig nur die sichtbare Methode kopiert.

Nicht aber der Kontext, in dem sie funktioniert hat.

Dieser Kontext kann beispielsweise enthalten:

Die Methode war möglicherweise nur ein Teil des Erfolgs.

Wird sie isoliert kopiert, kann der Effekt völlig anders aussehen.

Nehmen wir ein etabliertes Vorgehensmodell mit:

Für ein 20-Millionen-Euro-Projekt kann das angemessen sein.

Für ein internes Vorhaben mit:

ist dasselbe Modell möglicherweise absurd.

Das Projektteam produziert dann mehr Governance als Projektergebnis.

Umgekehrt funktioniert es genauso.

Ein leichtgewichtiges Scrum-Board reicht nicht automatisch für ein sicherheitskritisches Großprojekt mit gesetzlichen Nachweispflichten.

Deshalb gilt:

Nicht die Methode bestimmt den notwendigen Aufwand. Das Risiko und der Kontext bestimmen ihn.

PMI bezeichnet diese Anpassung als Tailoring. Prozesse und Werkzeuge sollen unter anderem anhand von Größe, Komplexität, Dauer, Kritikalität und organisatorischem Umfeld angepasst werden.

Eine standardisierte Methode vermittelt Sicherheit.

Wenn alle vorgeschriebenen Schritte durchgeführt wurden, entsteht schnell das Gefühl:

„Wir haben professionell gearbeitet.“

Aber:

Ein ausgefülltes Risikoregister bedeutet nicht, dass Risiken beherrscht werden.

Ein Business Case bedeutet nicht, dass das Projekt wirtschaftlich sinnvoll bleibt.

Ein Lenkungskreis bedeutet nicht, dass Entscheidungen getroffen werden.

Ein Daily Scrum bedeutet nicht, dass ein Team agil arbeitet.

Ein Lessons-Learned-Workshop bedeutet nicht, dass jemand daraus lernt.

Methoden sind Mittel.

Keine Ergebnisse.

Die gefährliche Entwicklung beginnt, wenn Methodentreue zum Ersatz für Wirkung wird.

Dann fragt das PMO:

„Wurde das Template vollständig ausgefüllt?“

Statt:

„Hilft uns diese Information bei einer Entscheidung?“

Viele Projektstandards starten mit einem nachvollziehbaren Ziel.

Zum Beispiel:

„Wir brauchen mehr Transparenz.“

Daraus entsteht ein Statusbericht.

Später möchte Finance zusätzliche Daten.

Das Portfolio Management ergänzt Kennzahlen.

Die Geschäftsführung braucht eine andere Sicht.

Risk Management fordert weitere Felder.

Nach drei Jahren besteht der Monatsstatus aus 14 Seiten.

Niemand würde dieses Reporting heute so neu entwickeln.

Aber jede einzelne Ergänzung hatte irgendwann einen guten Grund.

Best Practices besitzen deshalb einen natürlichen Wachstumseffekt.

Kaum jemand entfernt Regeln.

Neue Anforderungen kommen dagegen regelmäßig hinzu.

Das Ergebnis:

Good Practice + Good Practice + Good Practice kann schlechte Gesamtpraxis ergeben.

Projekte brauchen deshalb nicht nur Lessons Learned.

Sie brauchen gelegentlich auch Lessons Removed:

Scrum funktioniert in vielen komplexen Produktentwicklungen gut.

Daraus folgt nicht:

Scrum löst jedes Projektproblem.

Ein Unternehmen leidet beispielsweise unter:

Die Reaktion lautet:

„Wir werden agiler.“

Teams führen Sprints, Dailys und Retrospektiven ein.

Das eigentliche Problem bleibt bestehen.

Oder:

Ein Unternehmen hat schlechte Projekttransparenz.

Die Reaktion:

„Wir brauchen ein neues PPM-Tool.“

Nach Einführung des Tools sind dieselben Rollen und Prozesse weiterhin unklar.

Das Problem wurde digitalisiert.

Nicht gelöst.

Die richtige Reihenfolge lautet deshalb:

Nicht:

Ein weiterer Effekt entsteht bei Entscheidungen.

Statt selbst zu bewerten, was sinnvoll ist, verweist man auf die Methode.

„Das fordert der Standard.“

„So macht man das im Projektmanagement.“

„Das ist bei uns Prozess.“

Damit verschwindet persönliche Verantwortung hinter der Methodik.

Dabei fordert gerade professionelles Projektmanagement Urteilsfähigkeit.

Die aktuelle PMBOK-Ausgabe verbindet Projektmanagement ausdrücklich mit Value Delivery, Adaptability und Accountability. Prozesse werden wieder stärker beschrieben, jedoch bewusst nicht als starrer, verpflichtender Ablauf.

Standards sollen Entscheidungen unterstützen.

Nicht das Denken ersetzen.

Eine Organisation hat eine standardisierte Methode eingeführt.

Nun funktioniert ein Projekt anders.

Das Team möchte:

Die Antwort lautet:

„Das entspricht nicht unserem Standard.“

Genau hier wird Standardisierung gefährlich.

Denn neue Projektbedingungen können neue Vorgehensweisen erfordern.

Eine 2025 veröffentlichte empirische Untersuchung zu agilen Transformationen kommt zu einem ähnlichen Ergebnis: Agile Transformation ist kein One-size-fits-all-Prozess. Die Forschenden beschreiben Tailoring als eigenständigen Prozess, bei dem Praktiken anhand konkreter Projektbedingungen zu einer passenden Arbeitsweise konfiguriert werden.

Eine lernende Organisation fragt deshalb:

„Warum möchten wir abweichen und verbessert die Abweichung unsere Erfolgschance?“

Nicht:

„Warum hältst du dich nicht an die Vorlage?“

Ein dokumentiertes Transformationsvorhaben eines großen öffentlichen Versicherers liefert ein gutes Beispiel.

Die Organisation modernisierte eine umfangreiche Legacy-Landschaft und wollte gleichzeitig von klassischen Vorgehensweisen stärker in Richtung Agile wechseln.

Erste agile Projekte erzielten Erfolge.

Trotzdem stellte sich heraus:

Ein einheitliches agiles Framework ließ sich nicht sinnvoll auf die gesamte Organisation übertragen.

Unterschiedliche Projekte benötigten unterschiedliche Kombinationen aus klassischen und agilen Elementen.

Daraufhin entwickelte die Organisation einen stärker kontextbezogenen Ansatz, statt eine einzige agile Vorgehensweise verbindlich vorzugeben.

Die entscheidende Erkenntnis war nicht:

Agile funktioniert nicht.

Sondern:

Ein einziges Agile-Modell funktioniert nicht überall gleich gut.

Auch eine 2023 veröffentlichte Fallstudie aus einer öffentlichen Institution zeigt den Nutzen von Tailoring.

Statt vorhandene Projektstandards unverändert zu übernehmen, untersuchte die Organisation ihre tatsächlichen Anforderungen und passte Methoden während des Projektlebenszyklus gezielt an.

Das Ergebnis war ein eigener Rahmen, der als Grundlage für die Professionalisierung des Projektmanagements diente.

Der wichtige Unterschied:

Die Organisation fragte nicht:

„Welchen Standard führen wir ein?“

Sondern:

„Welche Elemente helfen uns bei unseren konkreten Projekten?“

Hier liegt die andere Gefahr.

Wenn starre Best Practices problematisch sind, könnte man daraus schließen:

„Dann macht eben jeder Projektleiter, was er will.“

Das wäre genauso falsch.

Tailoring bedeutet nicht:

Tailoring bedeutet:

bewusst entscheiden, welche Elemente eines Projektmanagement-Rahmens in welcher Intensität benötigt werden.

PMI beschreibt dafür einen klaren Ansatz:

Dieser Grundgedanke war bereits in früheren PMBOK-Ausgaben prominent und bleibt auch im aktuellen Standard erhalten.

Bevor du eine vermeintliche Best Practice übernimmst, beantworte sechs Fragen.

Beispiel:

Ein tägliches Meeting ist kein Ziel.

Das Ziel könnte sein:

Blockaden schneller erkennen und die tägliche Zusammenarbeit koordinieren.

Vielleicht ist ein Daily dafür sinnvoll.

Vielleicht nicht.

Je höher:

desto stärker können Governance und formale Kontrollen notwendig sein.

Bei bekannten Anforderungen kann detaillierte Vorausplanung sinnvoll sein.

Bei hoher technologischer oder fachlicher Unsicherheit helfen häufiger:

Betrachte:

Komplexität beeinflusst den Steuerungsbedarf erheblich.

Ein sehr erfahrenes Team benötigt möglicherweise weniger formale Leitplanken.

Ein neues oder unerfahrenes Team profitiert stärker von klarer Struktur.

Zum Beispiel:

Tailoring endet dort, wo verbindliche Anforderungen beginnen.

Unternehmen müssen ihre Projektmethodik nicht abschaffen.

Sie sollten sie anders strukturieren.

Elemente, die für alle relevanten Projekte erforderlich sind.

Zum Beispiel:

Elemente, die grundsätzlich empfohlen sind, aber angepasst werden dürfen.

Beispielsweise:

Werkzeuge für bestimmte Situationen.

Zum Beispiel:

Dadurch entsteht ein Methodenbaukasten statt eines Methodenhandbuchs.

Ein Unternehmen mit vielen Projekten kann nicht jedes Projekt vollständig individuell designen.

Deshalb sind Projektklassen sinnvoll.

Beispiel:

Ein von PMI beschriebenes Praxisbeispiel nutzte ebenfalls mehrere Komplexitätsstufen. Je komplexer das Projekt, desto höher waren methodischer Aufwand und Monitoring.

Damit entsteht Standardisierung mit Kontext.

Du kopierst die sichtbare Praxis.

Nicht dessen Kontext.

Eine Methode zu kennen bedeutet nicht automatisch, sie richtig auszuwählen.

Ohne regelmäßig alte Regeln zu entfernen.

Der Prozess wird korrekt durchgeführt.

Das Projekt profitiert trotzdem nicht.

Der Kontext kann sich verändern.

Auch die Methode muss überprüft werden.

Eine begründete Abweichung kann professioneller sein als blinde Compliance.

Dadurch gehen Vergleichbarkeit, Governance und Wiederverwendbarkeit verloren.

Bewährte Praktiken sind besonders wertvoll, wenn:

Ein Unternehmen, das regelmäßig ähnliche Rollouts durchführt, muss das Vorgehen nicht jedes Mal neu erfinden.

Auch sicherheitskritische Prozesse profitieren von Standardisierung.

Best Practices schaden also nicht grundsätzlich.

Problematisch werden sie, wenn Wiederholung angenommen wird, obwohl der Kontext sich wesentlich unterscheidet.

Auch Anpassung kann scheitern.

Vor allem wenn:

Tailoring erfordert mehr Kompetenz als das Befolgen einer Checkliste.

Denn jemand muss beurteilen:

Was ist wirklich notwendig?

Der Einstieg kann in sechs Schritten erfolgen.

Liste auf:

Frage:

Welches Risiko reduziert oder welche Entscheidung verbessert dieses Element?

Gibt es keine gute Antwort, gehört es auf den Prüfstand.

Zum Beispiel nach:

Was muss in jedem relevanten Projekt vorhanden sein?

Dieser Kern sollte klein bleiben.

Definiere, wann zusätzliche Elemente notwendig werden.

Zum Beispiel:

Budget über fünf Millionen Euro → Investment Gate erforderlich.

Hohe technische Unsicherheit → früher Proof of Concept.

Nicht nur:

„Haben wir die Methode eingehalten?“

Sondern:

„Hat uns die Methode geholfen?“

Damit wird das Projektmanagement selbst lernfähig.

Best Practices sind etablierte Vorgehensweisen, Methoden oder Werkzeuge, die sich in bestimmten Projektumfeldern bewährt haben. Sie sollten als Orientierung verstanden und an den jeweiligen Kontext angepasst werden.

Weil Projektgröße, Risiko, Unsicherheit, Kultur und Organisation unterschiedlich sind. Eine Methode kann in einem Umfeld sehr wirksam sein und in einem anderen unnötige Bürokratie oder falsche Steuerungsimpulse erzeugen.

Tailoring bezeichnet die bewusste Anpassung von Vorgehensweisen, Prozessen, Werkzeugen und Governance an Organisation und konkretes Projekt. Die aktuelle PMBOK-Ausgabe nennt die Anpassung an Team, Organisation und Umfeld ausdrücklich als zentralen Bestandteil modernen Projektmanagements.

Nein. Gemeinsame Mindeststandards schaffen Orientierung und Vergleichbarkeit. Der Umfang und die konkrete Anwendung sollten jedoch an Risiko, Größe und Komplexität angepasst werden.

Scrum ist ein Framework für komplexe Produktentwicklung und kann in passenden Situationen sehr wirksam sein. Es ist jedoch keine universelle Lösung für jedes Projekt. Auch agile Transformationen benötigen kontextabhängige Anpassung.

Ein modernes PMO sollte nicht möglichst viele Standards erzeugen. Es sollte einen klaren Rahmen, einen Methodenbaukasten und nachvollziehbare Tailoring-Regeln bereitstellen. Gleichzeitig kann es prüfen, ob Projekte weder über- noch untersteuert werden.

Best Practices sind nicht das Problem.

Der Glaube an universelle Best Practices ist es.

Ein Projektmanagement-Ansatz funktioniert nicht deshalb, weil er bei einem anderen Unternehmen erfolgreich war oder in einem Methodenhandbuch steht.

Er funktioniert, wenn er zum konkreten Problem und zum jeweiligen Projektkontext passt.

Genau deshalb hat Tailoring im modernen Projektmanagement eine so zentrale Bedeutung. Selbst der PMBOK Guide – Eighth Edition stellt Anpassungsfähigkeit, Value Delivery und die Auswahl geeigneter Praktiken ausdrücklich in den Mittelpunkt.

Die entscheidende Frage lautet daher nicht:

„Welche Best Practice sollten wir einführen?“

Sondern:

„Welche Steuerung benötigt dieses Projekt, damit wir mit möglichst wenig unnötigem Aufwand verlässlich Wert erzeugen?“

Dafür braucht es Standards.

Aber flexible Standards.

Es braucht Methoden.

Aber keine Methodengläubigkeit.

Und es braucht Projektleiter und PMOs, die nicht nur Prozesse kennen, sondern beurteilen können, wann diese Prozesse sinnvoll sind.

PURE Consultant unterstützt Unternehmen dabei, Projektmanagement- und PMO-Strukturen so zu gestalten, dass Standards Orientierung schaffen, ohne Projekte unnötig zu belasten. Im Mittelpunkt stehen skalierbare Governance, praxistaugliche Methoden und ein Projektmanagement, das sich am tatsächlichen Nutzen orientiert.