Projektmanagement-Flussdiagramme: Von der Planung bis zur Ausführung

Projekte scheitern auf vorhersehbare Weise: unklare Verantwortlichkeiten, mehrdeutige Genehmigungskriterien, nicht erfasste Änderungen am Projektumfang und Entscheidungen, die informell getroffen und dann vergessen werden. Ein Projektmanagement-Flussdiagramm verhindert diese Fehler nicht durch Magie — es verhindert sie, indem es den Prozess so explizit macht, dass Unklarheiten auftauchen, bevor sie zu Problemen werden.

Dieser Leitfaden behandelt, wie Flussdiagramme in Projektmanagement-Methoden integriert werden, welche spezifischen Abläufe am wertvollsten zu dokumentieren sind und wie man PM-Flussdiagramme entwirft, die Teams tatsächlich verwenden, anstatt sie abzulegen und zu vergessen.

Wie Flussdiagramme in PM-Methoden passen

Die Projektmanagement-Methode bestimmt, welche Prozesse dokumentiert werden müssen, nicht ob Prozesse dokumentiert werden müssen. Jeder Ansatz — Waterfall, Agile, hybrid — hat Entscheidungspunkte, Genehmigungsgates und Eskalationspfade, die von einer visuellen Darstellung profitieren.

Waterfall und prädiktive Ansätze

Waterfall-Projekte haben definierte Phasen mit formalen Gates dazwischen. Flussdiagramme dienen in erster Linie als Gate-Definitionen: Welche Bedingungen müssen erfüllt sein, um eine Phase zu verlassen, wer genehmigt den Austritt und was löst einen Rückfall in die vorherige Phase aus? Die sequentielle Natur von Waterfall macht es besonders geeignet für lineare Flussdiagramme, die den Projektzeitplan widerspiegeln.

Agile und iterative Ansätze

Agile-Frameworks haben auch Prozesse — Sprint-Zeremonien, Backlog-Verfeinerungskriterien, Definition of Done, Eskalationspfade für Impediments. Das Missverständnis, dass Agile „weniger Prozess" ist, bedeutet, dass viele Agile-Teams ohne dokumentierte Workflows operieren, bis sie auf ein Problem stoßen, das der nicht dokumentierte Prozess nicht konsistent handhaben kann. Sprint-Planung, Release-Genehmigung und Stakeholder-Änderungsanfragen profitieren alle von klaren dokumentierten Abläufen.

Hybride Ansätze

Die meisten reifen Organisationen nutzen hybride Ansätze: Agile-Delivery innerhalb von Waterfall-Governance-Strukturen. Projektinitiierung, Budgetgenehmigung und Lenkungsausschuss-Eskalationen folgen formalen Gate-Prozessen. Der tägliche Lieferbetrieb folgt iterativen Agile-Methoden. Flussdiagramme dienen beiden Ebenen — Governance-Abläufe für die Waterfall-Ebene, operative Abläufe für die Agile-Ebene.

Wichtige Projektmanagement-Flussdiagramme

Projektinitiierung und -genehmigung

Bevor ein Projekt beginnt, muss es genehmigt werden. Initiierungsabläufe sind oft die am inkonsistentesten ausgeführten Prozesse in Organisationen — einige Projekte werden gründlich geprüft, während andere durch informelle Kanäle schnell genehmigt werden.

Projektidee oder Geschäftsbedarf identifiziert
        ↓
Informelle Machbarkeitsbeurteilung
        ↓
Projektcharta erstellen:
  - Business Case
  - Ziele und Erfolgskriterien
  - Umfangsgrenzen
  - Übergeordneter Zeitplan und Budget
  - Ressourcenanforderungen
  - Risiken und Annahmen
        ↓
Charta von Abteilungsleiter geprüft
        ↓
Genehmigung zum Weiterverfahren an Lenkungsausschuss?
        ↓ Nein → Charta überarbeiten oder Initiative abbrechen
        ↓ Ja
        ↓
Lenkungsausschuss-Überprüfung
        ↓
Strategische Ausrichtung bestätigt?
        ↓ Nein → Verschieben oder ablehnen → Entscheidungsbegründung dokumentieren
        ↓ Ja
        ↓
Budget genehmigt?
        ↓ Nein → Umfang überarbeiten oder Budgetanfrage eskalieren
        ↓ Ja
        ↓
Projekt formal genehmigt → PM zugewiesen → Projekt initiiert

Die Entscheidung „Genehmigung zum Weiterverfahren" ist der Punkt, an dem viele Organisationen inkonsistent sind. Dokumentieren Sie die Kriterien explizit: Welches Detailniveau des Business Case ist erforderlich? Wer kann bis zu welchem Budgetschwellenwert genehmigen? Was passiert mit Projekten, die verschoben werden statt abgelehnt?

Stakeholder-Genehmigungsworkflow

Während der Projektdurchführung erfordern Lieferergebnisse und Entscheidungen die Genehmigung von Stakeholdern. Ein unklarer Genehmigungsprozess führt zu verzögerten Unterschriften, Genehmigungsumfangserweiterungen (jeder möchte alles genehmigen) und Entscheidungen, die nach formaler Genehmigung wieder in Frage gestellt werden.

Lieferergebnis oder Entscheidung erfordert Genehmigung
        ↓
Erforderliche Genehmiger basierend auf Typ und Auswirkung identifizieren
        ↓
Genehmigungspaket vorbereiten (Dokumentation, Entscheidungskriterien, Empfehlung)
        ↓
An Genehmiger weiterleiten
        ↓
Einzelner Genehmiger oder sequenziell?
        ↓ Sequenziell → Erster Genehmiger prüft → Genehmigt?
                          ↓ Nein → Mit Kommentaren zurückgeben
                          ↓ Ja → An nächsten Genehmiger weiterleiten
        ↓ Parallel → Alle Genehmiger prüfen gleichzeitig
                      ↓ Alle genehmigen? → Fortfahren
                      ↓ Einer lehnt ab? → Zur Lösung des Widerspruchs zusammenkommen
        ↓
Alle Genehmigungen erhalten?
        ↓ Nein → Lösung von Einwänden facilitieren
        ↓ Ja
        ↓
Genehmigung mit Unterzeichnern und Datum dokumentieren
        ↓
Mit genehmigtem Lieferergebnis oder Entscheidung fortfahren

Definieren Sie, wer die erforderlichen Genehmiger sind, nach Lieferergebnistyp — bevor das Projekt beginnt, nicht wenn das Lieferergebnis fertig ist. Mitten im Projekt zu entdecken, dass ein Lieferergebnis drei zusätzliche Überprüfungen benötigt, die nicht im Plan waren, ist ein häufiger Zeitplanverderber.

Sprint-Planungs-Workflow (Agile)

Die Sprint-Planung in Scrum hat eine definierte Zeremoniestruktur, aber der Prozess, Stories für die Planung bereitzumachen, die Kapazität zu bestätigen und sich auf das Sprint-Ziel zu verpflichten, profitiert von expliziter Dokumentation — besonders für Teams, die neu sind oder eine hohe Fluktuation haben.

Vorheriges Sprint-Retrospektiv abgeschlossen
        ↓
Product Backlog verfeinert (Stories geschätzt, Akzeptanzkriterien definiert)?
        ↓ Nein → Notfall-Backlog-Verfeinerungssitzung
        ↓ Ja
        ↓
Team-Kapazität bestätigt (Urlaub, Schulung, Overhead-Zeit)
        ↓
Sprint-Ziel vom Product Owner vorgeschlagen
        ↓
Team prüft Top-Backlog-Elemente
        ↓
Story passt zum Sprint-Ziel und ist bereit (Definition of Ready erfüllt)?
        ↓ Nein → Für diesen Sprint überspringen oder verfeinern
        ↓ Ja → Zur Sprint-Kandidatenliste hinzufügen
        ↓
Geschätzte Kapazität erreicht?
        ↓ Ja → Keine weiteren Stories hinzufügen
        ↓ Nein → Weiterhin Backlog prüfen
        ↓
Team verpflichtet sich auf Sprint-Ziel und Backlog
        ↓
Sprint beginnt → Tägliche Stand-ups, Task-Board aktualisiert
        ↓
Sprint-Review und Retrospektiv am Ende

Die Definition-of-Ready-Prüfung ist der Punkt, an dem dieser Ablauf oft zusammenbricht. Teams ziehen Stories, denen Akzeptanzkriterien fehlen, die ungelöste Abhängigkeiten haben oder Klärungen erfordern, die Planungssitzungen entgleisen lassen. Das Flussdiagramm macht die Bereitschaftsprüfung explizit statt implizit.

Risikobewertung und -eskalation

Risikomanagement wird oft als einmalige Aktivität während der Projektinitiierung behandelt. Effektives PM behandelt Risiko als einen laufenden Prozess mit dokumentierten Identifizierungs-, Bewertungs- und Eskalations-Workflows.

Risiko identifiziert (von jedem Teammitglied)
        ↓
Risiko dokumentieren: Beschreibung, Kategorie, potenzielle Auswirkung, Auslösebedingungen
        ↓
Wahrscheinlichkeit bewerten (Hoch / Mittel / Niedrig)
        ↓
Auswirkung bewerten (Hoch / Mittel / Niedrig)
        ↓
Risikobewertung = Wahrscheinlichkeit x Auswirkung
        ↓
Hohe Bewertung (H x H oder H x M)?
        ↓ Ja → An PM und Stakeholder eskalieren → Minderungsplan entwickeln → Verantwortlichen zuweisen
        ↓ Mittlere Bewertung → In Risikoregister eintragen → Wöchentlich überwachen
        ↓ Niedrige Bewertung → Protokollieren und akzeptieren → Monatlich überprüfen
        ↓
Risikoverantwortlicher überwacht Auslösebedingungen
        ↓
Risikoauslösebedingung erfüllt?
        ↓ Ja → Minderungsplan ausführen → An PM berichten
        ↓ Nein → Überwachung fortsetzen
        ↓
Risiko gelöst oder akzeptiert?
        ↓ Ja → Risiko schließen → Ergebnis dokumentieren
        ↓ Nein → Eskalieren, wenn Minderung unzureichend

Risikoregister ohne Eskalationspfade werden zu Dokumentationsübungen. Das Flussdiagramm sollte numerisch definieren, was „hohe Bewertung" bedeutet, an wen eskaliert wird und wie der erwartete Reaktionszeitraum ist.

Änderungsanfrageprozess

Umfangsänderungen sind unvermeidlich. Nicht dokumentierte Umfangsänderungen sind toxisch — sie fügen Arbeit hinzu, verbrauchen Budget und hinterlassen keine Aufzeichnung darüber, warum der ursprüngliche Plan geändert wurde. Ein Änderungsanfrageprozess, der zu bürokratisch ist, wird umgangen; einer, der zu locker ist, führt zu Umfangserweiterungen.

Änderungsanfrage eingereicht (von jedem Stakeholder)
        ↓
Änderungsanfrage protokollieren mit: Antragsteller, Beschreibung, Begründung, gewünschter Zeitplan
        ↓
PM führt erste Auswirkungsanalyse durch:
  - Umfangsänderung (was wird hinzugefügt oder entfernt)
  - Zeitplanauswirkung
  - Budgetauswirkung
  - Ressourcenauswirkung
  - Risikoauswirkung
        ↓
Auswirkung übersteigt PM-Autorität des Projekts?
        ↓ Ja → An Lenkungsausschuss mit Empfehlung eskalieren
        ↓ Nein → PM prüft mit wichtigen Stakeholdern
        ↓
Änderung genehmigt?
        ↓ Nein → Ablehnen mit dokumentierter Begründung → Antragsteller benachrichtigen
        ↓ Ja
        ↓
Projektplan aktualisieren: Umfang, Zeitplan, Budget
        ↓
Änderung an Projektteam kommunizieren
        ↓
Änderung innerhalb der aktualisierten Projektbasislinie umsetzen
        ↓
Änderungsanfrage schließen → Änderungsprotokoll aktualisieren

Jede genehmigte Änderung, die die Basislinie betrifft, sollte eine formale Aktualisierung des Projektplans und eine erneute Unterzeichnung der überarbeiteten Basislinie erfordern. Das Änderungsprotokoll dokumentiert die Entwicklung des Projekts — wenn es nach dem Projekt überprüft wird, erklärt es, warum sich die endgültige Lieferung vom ursprünglichen Plan unterschied.

Projektabschluss

Projektabschluss ist der am konsequentesten übersprungene PM-Prozess. Teams liefern das endgültige Ergebnis und gehen weiter, ohne Lektionen zu lernen, Verträge zu schließen und Stakeholder ohne formale Abnahmedokumentation zu hinterlassen.

Endliches Lieferergebnis abgeschlossen
        ↓
Kunden- oder Sponsor-Abnahmeprüfung
        ↓
Abnahmekriterien erfüllt?
        ↓ Nein → Lücken dokumentieren → Offene Punkte lösen → Zur Überprüfung zurückkehren
        ↓ Ja
        ↓
Formale Abnahme unterzeichnet
        ↓
Administrative Schließung:
  - Projektaufzeichnungen und Dokumentation aktualisieren
  - Projektdateien archivieren
  - Projektressourcen freigeben
  - Finanzkonten schließen
        ↓
Lessons-Learned-Sitzung durchgeführt
        ↓
Erkenntnisse dokumentiert und mit PM-Community geteilt
        ↓
Projektabschlussbericht an Stakeholder herausgegeben
        ↓
Projekt offiziell geschlossen

Die formale Abnahme ist aus vertraglichen und finanziellen Gründen entscheidend. Ohne ein unterzeichnetes Abnahmedokument gibt es keinen Bezugspunkt für Streitigkeiten darüber, ob das Projekt das geliefert hat, was versprochen wurde.

Flussdiagramm vs. Gantt-Diagramm vs. Kanban-Board

Projektmanager verwenden mehrere Visualisierungstools, die jeweils für unterschiedliche Informationsbedürfnisse geeignet sind. Zu verstehen, wann welches verwendet werden soll, verhindert Über- und Unterdokumentation.

Tool	Am besten für	Was es zeigt	Was es fehlt
Flussdiagramm	Prozessdefinition, Entscheidungslogik, Genehmigungsworkflows	Wie ein Prozess funktioniert, Entscheidungspfade, Bedingungen	Zeitplan, Ressourcenallokation, Aufgabenstatus
Gantt-Diagramm	Zeitplanverwaltung, Abhängigkeitsverfolgung, Zeitplankommunikation	Aufgabenreihenfolge, Dauer, Abhängigkeiten, Meilensteine	Entscheidungslogik, Prozessbedingungen, Workflow-Verzweigung
Kanban-Board	Verwaltung laufender Arbeit, tägliche Aufgabenverfolgung	Aktueller Stand der Aufgaben, Flusseffizienz, WIP-Limits	Prozessregeln, Entscheidungspunkte, formale Genehmigungsanforderungen
RACI-Matrix	Verantwortungszuweisung	Wer was tut, wer genehmigt	Wann, wie oder welche Entscheidungen getroffen werden

Die praktische Antwort ist, alle vier für unterschiedliche Zwecke zu verwenden. Prozesse mit Flussdiagrammen definieren, Arbeit mit Gantt-Diagrammen planen, die tägliche Ausführung mit Kanban-Boards verwalten und Verantwortlichkeiten mit RACI-Matrizen klären. Der Versuch, ein Tool die Arbeit aller vier erledigen zu lassen, schafft Visualisierungen, die keines davon gut erfüllen.

Effektive PM-Flussdiagramme erstellen

Die richtige Detailtiefe finden

PM-Flussdiagramme, die jeden möglichen Szenario erfassen, werden so komplex, dass sie niemand referenziert. Flussdiagramme, die wichtige Entscheidungspunkte überspringen, versagen, wenn diese Entscheidungen eintreffen. Die richtige Detailtiefe ist: jeder Entscheidungspunkt, der in der Praxis echte Verwirrung oder Inkonsistenz verursacht, und nicht mehr.

Beginnen Sie damit zu fragen: „Welche Fragen stellen Teammitglieder oder Stakeholder wiederholt zu diesem Prozess?" Diese Fragen zeigen, wo der Prozess unterspezifiziert ist. Jede wiederholte Frage entspricht einer Entscheidungsraute, die in das Flussdiagramm gehört.

Prozess von Richtlinie unterscheiden

Ein Flussdiagramm dokumentiert den Prozess — die Abfolge von Schritten und Entscheidungen. Richtliniendokumente dokumentieren die Regeln, die diese Entscheidungen regeln. Halten Sie sie getrennt. Das Flussdiagramm sagt „Risikoniveau bewerten" und leitet zu drei Pfaden. Das verknüpfte Richtliniendokument definiert, wie das Risikoniveau berechnet wird. Die vollständige Risikobewertungsrubrik in das Flussdiagramm einzufügen macht es unleserlich; sie wegzulassen macht das Flussdiagramm unvollständig. Verweisen Sie auf die Richtlinie, betten Sie sie nicht ein.

Stakeholder-Review einbauen

Ein PM-Flussdiagramm, das darstellt, was der PM glaubt, dass der Prozess ist, aber nicht was Stakeholder tatsächlich tun, wird ignoriert. Vor der Fertigstellung eines PM-Flussdiagramms:

Entwurf basierend auf Ihrem Verständnis des Prozesses
Entwurf mit jedem Schlüsselteilnehmer im Prozess durchgehen
Fragen: „Wie sieht dieser Schritt aus, wenn Sie ihn tatsächlich ausführen?" und „Was passiert, wenn X auftritt?"
Basierend auf der tatsächlichen Praxis überarbeiten, nicht auf idealer Praxis
Notieren, wo tatsächliche Praxis von der Richtlinie abweicht — diese Abweichung ist entweder ein Schulungsproblem oder ein Richtlinienproblem, und sie muss gelöst werden

Ausnahmebehandlung planen

Jeder PM-Prozess erzeugt Ausnahmen. Der Änderungsanfrage-Workflow oben geht von einem rationalen, sequenziellen Genehmigungsprozess aus. Die Realität beinhaltet: der Sponsor ist während eines kritischen Entscheidungsfensters nicht verfügbar, eine Umfangsänderung wird mitten im Sprint statt an einem formalen Gate entdeckt, und zwei Änderungsanfragen interagieren auf eine Weise, für die keine von beiden allein ausgelegt war. Erstellen Sie explizite Ausnahmepfade für die häufigsten Abweichungen und dokumentieren Sie Eskalationspfade für den Rest.

PM-Flussdiagramm-Vorlagen mit Beispielen

Gate-Review-Vorlage für Projekte

Phasenabschlusskriterien erfüllt?
        ↓ Nein → Lücken identifizieren → Sanierungsplan → Zurückkehren, wenn Kriterien erfüllt
        ↓ Ja
        ↓
Gate-Review-Meeting
        ↓
Alle Pflichtartefakte eingereicht?
        ↓ Nein → Gate-Frist verlängern → Fehlende Artefakte anfordern
        ↓ Ja
        ↓
Prüfer bewerten: Qualität, Vollständigkeit, Bereitschaft zum Fortfahren
        ↓
Gate-Entscheidung:
        ↓ Bestanden → Nächste Phase autorisieren
        ↓ Bedingt bestanden → Mit dokumentierten Bedingungen fortfahren
        ↓ Nicht bestanden → Zur Phase zurückkehren → Erkenntnisse adressieren → Erneut prüfen
        ↓ Gehalten → Projekt pausieren → An Lenkungsausschuss eskalieren

Ressourcenkonflikt-Lösungsvorlage

Ressourcenkonflikt identifiziert (zwei Projekte benötigen dieselbe Person oder Ressource)
        ↓
Projekte, Aufgaben und Zeiträume im Konflikt identifizieren
        ↓
PM jedes Projekts bestätigt, dass Konflikt real ist (kein Planungsfehler)
        ↓
Kann Konflikt durch Zeitplananpassung gelöst werden?
        ↓ Ja → Neuen Zeitplan koordinieren → Beide Projektpläne aktualisieren
        ↓ Nein
        ↓
An Ressourcenmanager mit Analyse eskalieren:
  - Geschäftliche Auswirkung jedes verzögerten Projekts
  - Dauer des Konflikts
  - Berücksichtigte Alternativen
        ↓
Ressourcenmanager entscheidet Priorität
        ↓
Prioritätsprojekt erhält Ressource → Zeitplan des anderen Projekts angepasst
        ↓
Beide PMs benachrichtigt → Pläne aktualisiert → Stakeholder informiert

Problem-Eskalationsvorlage

Problem identifiziert (Risiko materialisiert, Blocker, Entscheidung erforderlich)
        ↓
Problemschweregrad: Geringfügig / Bedeutsam / Kritisch
        ↓
Geringfügig: PM löst innerhalb von Team innerhalb von 2 Tagen
Bedeutsam: PM eskaliert innerhalb von 24 Stunden an Projektsponsor
Kritisch: PM eskaliert innerhalb von 4 Stunden an Lenkungsausschuss
        ↓
Empfänger der Eskalation prüft Problem
        ↓
Entscheidung oder Anleitung gegeben?
        ↓ Ja → PM setzt Entscheidung um → Problem gelöst → Ergebnis protokollieren
        ↓ Nein → Weitere Eskalation → Meeting einberufen

PM-Flussdiagramme mit Flowova erstellen

Projektmanagement umfasst zahlreiche überlappende Prozesse, und sie konsistent über den Projektlebenszyklus hinweg dokumentiert zu halten erfordert Tools, die die Erstellung und Pflege effizient machen. Flowova's Projektmanagement-Anwendungsfall unterstützt PM-Teams mit:

KI-gestützter Entwurfserstellung — Beschreiben Sie einen PM-Prozess in einfacher Sprache und generieren Sie ein erstes Flussdiagramm zur Überprüfung mit Stakeholdern, was die Zeit für die Erstellung von Grund auf erheblich reduziert.
Inline-Bearbeitung — Flussdiagramme entwickeln sich, wenn Projekte voranschreiten und Lektionen gelernt werden. Knoten und Verbindungen direkt bearbeiten, ohne zwischen Zeichnungs- und Bearbeitungsmodi zu wechseln.
Teilbare Formate — PM-Flussdiagramme müssen Stakeholder erreichen, die nicht dieselben Tools wie der PM verwenden. Als PNG für Präsentationsfolien exportieren, im Mermaid-Format für Wikis oder als Live-Link für Team-Reviews teilen.
Strukturiertes JSON-Modell — Für Organisationen, die PM-Flussdiagramme in Projektmanagementplattformen oder Intranets einbetten, ist das zugrunde liegende JSON sauber und parsierbar und ermöglicht die Integration ohne manuelle Neuformatierung.

Das beste PM-Flussdiagramm ist das, das während des eigentlichen Projekts referenziert wird, statt bei der Initiierung abgelegt zu werden.

Häufige PM-Flussdiagramm-Fehler

Jedes Feld als Prozessschritt machen. Flussdiagramme, bei denen jedes Feld ein Rechteck ohne Entscheidungsrauten ist, sind Prozesslisten, keine Flussdiagramme. Wenn es keine Entscheidungen gibt, kommuniziert eine nummerierte Liste die Information klarer. Entscheidungspunkte für jede echte Wahl oder Bedingung hinzufügen.

Nur den idealen Pfad zeigen. Ein Flussdiagramm, das nur den Happy Path zeigt — alles geht richtig, niemand lehnt etwas ab, keine Ausnahmen treten auf — bietet keine Orientierung, wenn die Realität abweicht. Jede Entscheidungsraute sollte mindestens zwei ausgehende Pfade haben, und der „Nein"- oder „Abgelehnt"-Pfad sollte irgendwohin nützlich führen.

Nach Projektlernerkenntnissen nie aktualisieren. Post-Projekt-Retrospektiven decken Prozesslücken auf. Die Erkenntnisse aus einer Lessons-Learned-Sitzung sollten das entsprechende Flussdiagramm aktualisieren, bevor das nächste Projekt beginnt. Wenn das Flussdiagramm nicht die tatsächliche Best Practice widerspiegelt, trainiert es das nächste Team in einem veralteten Prozess.

Jargon ohne Definition verwenden. Begriffe wie „Stage Gate", „RAID-Log" und „Basislinienzeitplan" bedeuten in verschiedenen Organisationen unterschiedliche Dinge. Klare, eindeutige Sprache verwenden oder auf Definitionen verlinken. Im Zweifelsfall durch die zugrundeliegende Aktion ersetzen: „Umfangs-, Zeitplan- und Budgetbasislinie aktualisieren" statt „re-baselinen".

Fazit

Projektmanagement-Flussdiagramme beweisen ihren Wert an den Grenzen des Projektlebenszyklus: Initiierungsgates, die verhindern, dass schlechte Projekte beginnen, Änderungsanfrageprozesse, die verhindern, dass Umfangserweiterungen unsichtbar anwachsen, Eskalations-Workflows, die Probleme zu den richtigen Entscheidungsträgern leiten, und Abschlussprozesse, die institutionelles Wissen erfassen, bevor es sich zerstreut. Diese Flussdiagramme zu erstellen, bevor sie benötigt werden — nicht als Reaktion auf die Probleme, die sie verhindert hätten — ist das, was eine dokumentierte PM-Praxis von einer ad hoc-Praxis unterscheidet.