Die Diskussion kehrt zurück, obwohl sie schon geführt wurde
In einem ausdrücklich fiktiven Projekt entscheidet ein Team, Anfragen zunächst per E-Mail statt über eine komplexe Plattform zu bearbeiten. Drei Monate später fordert jemand die Plattform erneut und fragt, warum sie nie eingeführt wurde. Die Beteiligten erinnern sich unterschiedlich: zu teuer, zu langsam, rechtlich schwierig? Ein kurzer Eintrag könnte zeigen, dass damals vor allem die geringe Anzahl von Anfragen und der unklare Prozess entscheidend waren. Die neue Nachfrage ist dann weder automatisch ein Fehler noch bloße Wiederholung. Vielleicht hat sich das Volumen inzwischen geändert. Ohne festgehaltenen Kontext lässt sich beides schwer unterscheiden.
Ein Protokoll lohnt sich besonders bei Entscheidungen, deren Begründung nicht aus dem sichtbaren Ergebnis hervorgeht. Es sollte die spätere Zusammenarbeit erleichtern, nicht jede Kleinigkeit verwalten. Die AWS-Dokumentation zu Architectural Decision Records beschreibt für technische Architekturentscheidungen mindestens Kontext, Entscheidung und Folgen. Dieses Prinzip lässt sich vorsichtig auf andere Projektentscheidungen übertragen. Für eine Urlaubszeit oder eine leicht umkehrbare Formulierung braucht es oft keinen eigenen Eintrag. Für eine Plattformwahl, einen erheblichen Prozesswechsel oder eine Grenze im Projektmanagement schon eher.
Den damaligen Informationsstand ehrlich zeigen
Beginne mit dem Anlass: Welche konkrete Frage musste beantwortet werden, bis wann und für wen? Halte danach die betrachteten Optionen fest, auch „vorerst nichts ändern“, wenn das eine reale Wahl war. Schreibe nicht erst im Nachhinein eine glatte Erfolgsgeschichte. Unterscheide bekannte Beobachtungen von Erwartungen. „Wir erhalten zurzeit etwa zehn Anfragen pro Woche“ wäre ein zu prüfender Befund. „Eine Plattform spart uns sicher Zeit“ ist ohne Messung eine Annahme. Ein Link auf eine Hypothese oder einen kleinen Versuch kann zeigen, was vor der Entscheidung tatsächlich untersucht wurde.
Ein nutzbarer Eintrag kann auf eine Seite passen: Datum, Status, Frage, Kontext, Optionen, gewählte Lösung, wichtigste Gründe, erwartete Nachteile, Verantwortliche und Anlass zur erneuten Prüfung. Ergänze Referenzen auf Belege oder Gespräche, sofern sie zugänglich bleiben. Vermeide Sätze wie „Das Management hat entschieden“, wenn unklar ist, wer die Folgen trägt oder Änderungen freigibt. Notiere aber nur Personen, die für Verständnis und Umsetzung relevant sind. Ein Entscheidungsprotokoll ist kein öffentlicher Pranger für unterlegene Vorschläge.
Ein Beispiel, das eine spätere Änderung zulässt
Für das fiktive E-Mail-Projekt könnte der Kern so lauten: „Am 5. Oktober wählen wir einen gemeinsamen Posteingang für eingehende Anfragen. Die Bearbeitungszahl ist derzeit klein und der Ablauf wird erst beobachtet. Eine Plattform wäre schneller bei verteilten Rollen, verursacht aber Einrichtungsarbeit, bevor der Prozess geklärt ist. Wir prüfen erneut, wenn Anfragen regelmäßig liegen bleiben oder mehrere Personen gleichzeitig Statusänderungen benötigen.“ Das sind erfundene Angaben, keine Empfehlung für jede Organisation. Gerade die Auslösebedingung macht den Eintrag nützlich.
Wenn sich die Bedingungen ändern, ändere die alte Begründung nicht stillschweigend. Erfasse eine neue Entscheidung und verweise auf die frühere. So wird sichtbar, dass die erste unter anderen Voraussetzungen getroffen wurde. AWS empfiehlt bei überholten Architekturentscheidungen einen neuen Eintrag und den Status „superseded“ für den alten. Eine ähnliche Praxis ist für allgemeine Projektarbeit sinnvoll: Historie bewahren, aktuellen Stand klar markieren und die Übergabe an neue Beteiligte erleichtern. Das ist besonders hilfreich, wenn eine Roadmap über Monate hinweg angepasst wird.
Beteiligte einbeziehen, ohne ein Abstimmungsarchiv zu bauen
Notiere, wessen Wissen für die Frage nötig war und wer von der Entscheidung betroffen ist. Eine technische Wahl kann den Support oder Vertrieb stark berühren. Ein Stakeholder muss nicht jede Formulierung billigen, sollte aber früh genug über relevante Folgen sprechen können. Halte wichtige Einwände knapp und fair fest, vor allem wenn sie eine spätere Prüfung auslösen könnten. Viele Details einer Besprechung gehören eher in normale Notizen. Das Entscheidungsprotokoll soll den Punkt zeigen, an dem eine Wahl mit bekannten Nachteilen getroffen wurde.
Wähle einen Ort, den das Team tatsächlich benutzt, und eine einfache Benennung. Fortlaufende Nummer, Datum und verständlicher Titel genügen oft. Verlinke den Eintrag dort, wo die Entscheidung Wirkung hat, etwa in einem Projektplan oder einer Aufgabenbeschreibung. Speichere keine Zugangsdaten und keine unnötigen personenbezogenen Details im Text. Prüfe nach einigen Wochen, ob jemand einen alten Eintrag schnell findet und die damalige Wahl ohne Zusatzgespräch versteht. Wenn nicht, verbessere Auffindbarkeit und Sprache statt weitere Pflichtfelder einzuführen.
Die richtige Frage ist nicht „War die Entscheidung perfekt?“
Bewerte später, ob die damaligen Gründe mit dem damaligen Wissen nachvollziehbar waren und welche neuen Informationen hinzugekommen sind. Ein unerwünschtes Ergebnis beweist nicht automatisch, dass die ursprüngliche Entscheidung unvernünftig war. Ebenso ist ein gutes Ergebnis kein Beleg für jede Begründung. Das Protokoll trennt diese Ebenen und verhindert, dass eine spätere Sicht die Geschichte umschreibt. Es darf ausdrücklich festhalten: „Wir wussten es nicht und wählten eine reversible Lösung.“ Auch das kann eine sorgfältige Entscheidung gewesen sein.
Für deinen nächsten Schritt suche eine wichtige Frage, die im Team erneut auftaucht. Schreibe einen einzigen Eintrag mit zwei echten Alternativen und einem konkreten Anlass zur Überprüfung. Bitte eine nicht beteiligte Person, den Text zu lesen: Kann sie die Entscheidung, ihren Grund und ihre Grenze erkennen? Wenn ja, ist das Dokument bereits nützlich. Wenn die Antwort nur aus einem langen Sitzungsprotokoll hervorgeht, kürze auf die wesentlichen Übergänge. Ein gutes Entscheidungsprotokoll spart später nicht das Denken, sondern gibt ihm einen verlässlichen Ausgangspunkt.
Häufige Fragen
Welche Entscheidungen gehören in das Protokoll?
Vor allem solche, deren Grund später gebraucht wird: schwer umkehrbare, folgenreiche oder wiederholt diskutierte Entscheidungen. Kleine Alltagskorrekturen benötigen normalerweise keinen eigenen Eintrag.
Darf ein alter Eintrag geändert werden?
Tippfehler kannst du korrigieren. Wenn neue Informationen eine andere Entscheidung rechtfertigen, halte sie in einem neuen datierten Eintrag fest und verknüpfe ihn mit dem alten. So bleibt der damalige Informationsstand erkennbar.