Ein Projektteam einer mittelgroßen Gemeinde verbringt die erste Sitzung zu einem neuen Fallmanagementsystem mit der Frage, ob das Projekt nach Prince2 oder nach einer schlanken Scrum-Variante angegangen wird. Es wird abgestimmt, am Ende der Sitzung steht die Methode bereits auf der ersten Folie der Präsentation. Die Anforderungsliste für das System selbst besteht zu diesem Zeitpunkt aus drei Stichpunkten auf einem halben Blatt: keine Abnahmekriterien, kein Verantwortlicher pro Anforderung, keine Unterscheidung zwischen Muss- und Kann-Anforderungen. Drei Wochen später, als der erste Sprint beginnt, stellt sich heraus, dass niemand sich einig ist, was 'eine funktionierende Fallübersicht' genau bedeutet.
Diese Reihenfolge, zuerst die Methode, dann erst die Anforderungen, kommt häufiger vor, als man denkt. Und die Forschung zeigt, dass es die falsche Reihenfolge ist.
Was die Forschung zeigt
Dvir, Raz und Shenhar untersuchten 2003, womit Projekterfolg tatsächlich zusammenhängt. Ihr Befund: Erfolg korreliert mit der Qualität der Anforderungsdefinition, wie präzise festgelegt ist, was das Projekt liefern muss, und nicht mit dem Ausmaß, in dem ein formaler PM-Prozess umgesetzt wurde. Mit der Methodenwahl selbst, so gründlich sie auch in einem Handbuch oder einer Vorlage ausgearbeitet ist, hängt das kaum zusammen. Mit den Anforderungen schon.
Das ist eine unbequeme Erkenntnis für alle, die viel Zeit in die Auswahl und Dokumentation einer Arbeitsweise stecken. Ein Projektplan mit einem straffen Prince2-Gerüst, Rollen, Phasenübergängen, einem PID, alles nach Lehrbuch, wirkt professionell. Bleibt die darunterliegende Anforderungsliste aber vage, kauft der Auftraggeber Scheinsicherheit: Die Form stimmt, der Inhalt nicht.
Die Nuance, die dazugehört
Das ist kein Plädoyer dafür, Governance und Prozessvereinbarungen einfach fallen zu lassen. Andere Forschung, von Serrador und Turner aus dem Jahr 2015, findet durchaus positive Zusammenhänge zwischen Prozessreife und Projekterfolg. 'Inhalt vor Prozess' ist also kein universelles Gesetz, die beiden Forschungslinien widersprechen sich an diesem Punkt. Was bestehen bleibt: Die Anforderungsdefinition darf nicht hinter einer Methodendiskussion verschwinden, auch dann nicht, wenn diese Diskussion selbst sinnvoll ist.
Was das für den Projektstart bedeutet
Konkret: Wenn ein Projektplan die ersten Wochen vor allem damit verbringt, welche Methode verfolgt wird, welches Framework, welche Vorlagen, welche Besprechungsstruktur, während die Anforderungsliste ein Platzhalter bleibt, steht die Reihenfolge auf dem Kopf. Die Methodenwahl kann durchaus früh stattfinden, aber nicht anstelle der Festlegung der Anforderungen. Eine Anforderung, die zählt, hat einen Verantwortlichen, ist überprüfbar (man kann im Nachhinein prüfen, ob sie erfüllt wurde) und steht unabhängig von der Art, wie das Projekt gesteuert wird.
Für alle, die einen Projektplan vor dem Kickoff bewerten, ist das eine konkrete Frage neben der nach Governance und Phasierung: Stehen die Anforderungen da, unabhängig von der gewählten Arbeitsweise? Ein Plan, der bei der Prozessgestaltung hervorragend abschneidet, dessen Anforderungen aber kaum über eine Absichtserklärung hinauskommen, verdient an dieser Stelle einen kritischen Blick. Nicht weil der Prozess nicht zählt, sondern weil ein straffer Prozess das Fehlen präziser Anforderungen verdecken kann, und genau das ging beim Fallmanagementsystem schief.
Ein konkreter Schritt
Setzen Sie bei der nächsten Sitzung zum Projektplan die Anforderungsliste ganz oben auf die Tagesordnung, vor das Gespräch über die zu verfolgende Methode. Lassen Sie jede Anforderung einen Verantwortlichen und ein Abnahmekriterium bekommen, bevor das Team zur Frage übergeht, welches Framework darum herum gebaut wird. Das kostet eine Stunde zu einem Zeitpunkt, an dem die Diskussion ohnehin noch die Form betrifft, und verhindert, dass eine gut dokumentierte Methode später auf einem leeren Fundament steht.