Alle, die IT-Projekte leiten, kommen im Laufe ihrer Ausbildung und Berufspraxis irgendwann an die Stelle, wo sie lernen, dass klare Verantwortlichkeiten und definierte Entscheidungskompetenzen dem Projekterfolg zuträglich, ja fast unabdingbar, sind.
Was aber, wenn genau das fehlt? Wenn du dich in einem Projekt befindest, in dem eine Handvoll Stakeholder mitreden und jede der Parteien so ein bisschen was entscheiden darf?
Wenn dich das interessiert, dann lies gerne weiter. Ich möchte euch gerne von meinen Erfahrungen zu genau diesem Aspekt berichten. Dafür betrachten wir ein rein fiktives Beispiel. Es mag übertrieben wirken. Ist es tatsächlich aber nicht. Ich spreche dabei definitiv nicht über die Mehrzahl der Projekte, das möchte ich an dieser Stelle betonen. Doch das, was ich gleich schildere, habe ich persönlich erlebt.
Die wichtigsten Stakeholder
Zunächst muss ich euch die wichtigsten Stakeholder vorstellen:
- Der Fachbereich: Inhaltlicher Owner, darf Featurewünsche äußern und hat Mitspracherecht bei der Priorisierung.
- Die IT, Abteilung Softwareentwicklung: Hat die finanzielle Verantwortung und Mitspracherecht, was inhaltlich gemacht wird. Hat außerdem technische Anforderungen, die mit den fachlichen Features hinsichtlich Entwicklerkapazität konkurrieren.
- Das IT-Controlling: Kontrollorgan für die IT und den Fachbereich hinsichtlich Verwendung finanzieller Mittel sowie umzusetzender Inhalte. Hat außerdem ausgeprägtes Mitspracherecht in allen Bereichen, also auch fachlich und technisch. Hat organisatorische Anforderungen, z. B. bezüglich der Revisionssicherheit, und bestimmt, wann das Projekt zu enden hat.
- Die Fachbereichsleitung: Eskalationsinstanz des Fachbereichs, ihre Priorisierung ist teilweise abweichend von den Priorisierungsvorstellungen der Sachbearbeiter.
- Die Leitungsposition der IT/Softwareentwicklung: Zu Beginn der Geschichte unbesetzt. Wird später noch spannend.
Erste Maßnahmen: Diskussion über Entscheidungswege
Vier Monate nachdem ich das Projekt übernahm, lud ich die genannten Stakeholder zur Besprechung von zwei Kernthemen ein: Eines davon war „Entscheidungen im Projekt“.
In zwei, drei Folien habe ich den Teilnehmern erklärt, warum klare Entscheidungswege so wichtig sind und dass ich wahrnehme, dass hier im Projekt genau das Gegenteil der Fall ist: Keine Klarheit, niemand, der „den Hut aufhat“, jeder zwar ein bisschen, aber keine finale Instanz, die bei konkurrierenden Haltungen ein Machtwort sprechen kann.
Meine nächste Folie beschrieb ein paar Lösungsvorschläge, um die Diskussion anzukurbeln und die Teilnehmer ins Reden und ins „Miteinander“ zu bringen: z. B. den Fachbereich mit einem Storypoint-Budget und mehr Entscheidungsbefugnis auszustatten, den Entscheidungsweg prozessual abzubilden oder den Kreis der Entscheider in einen Refinement-/Replenishment-Zyklus einzubinden.
Das Feedback war allerdings ernüchternd. Genau genommen gab es gar kein Feedback dazu. Es wurde geschwiegen.
Ein überladener Backlog und neue Herausforderungen
Ganz ehrlich, das hatte ich mir anders vorgestellt. Aber machen wir erstmal weiter. Unser größtes Problem im Projekt war, dass der Backlog eine gigantische Größe hatte, aber das Projektende bereits optimistisch festgesetzt war. Wir mussten also einen Weg finden, zu entscheiden, was noch umgesetzt werden soll und was nicht.
Irgendwie haben wir dann in einer ersten Runde den Backlog etwas verkleinern und das Projekt restrukturieren können. Es blieb aber die Frage offen, was das Entwicklerteam als Nächstes umsetzen soll. Und, ob das Feature „X“ überhaupt noch seine Berechtigung hat und umgesetzt werden soll. Zudem wurden seit meiner Projektübernahme weitere notwendige Features identifiziert, die bis dato noch nicht als Feature/Story erfasst waren.
Mein Vorschlag: Sprints als Ausweg
Die Meinungen gingen nun stark auseinander. Was hat Prio? Fachliches Feature A vs. Features zugunsten der Revisionssicherheit vs. Fachliches Feature B vs. notwendige technische Features vs. X …
5 Stakeholder mit je 2–3 Meinungen. Ihr bekommt sicher gerade ein Gefühl für die Situation.
Was tun? Mein Vorschlag war der folgende:
- Wir führen Sprints ein.
- Der Fachbereich erarbeitet zusammen mit mir jeweils einen Sprintvorschlag.
- Alle Stakeholder segnen den nächsten Sprint im Rahmen des wöchentlichen Jour-Fixe ab.
- Damit alle Themen adressiert sind, erfolgt ein Mapping der scheinbar möglichen Stories auf die Sprints von jetzt bis Projektende (durch Fachbereich und mich).
Ich war positiv überrascht, aber der Vorschlag wurde einstimmig angenommen.
Rückschlag: Priorisierung im Dauerwechsel
Die Enttäuschung erfolgte eine Woche später!
Im nächsten Jour-Fixe entfachte wieder die Diskussion über die Prioritäten. Die IT-Steuerung spielte den Präsidenten-Joker und der Priorisierungsslalom begann … in den nächsten 6 Wochen wechselte unsere Prio von links nach rechts und wieder zurück – je nachdem, welcher Teilnehmerkreis gerade im Jour-Fixe anwesend war. Weitere Prio-Veränderungen erreichten das Projektteam per E-Mail. Mal aus der einen, mal aus der anderen Stakeholder-Ecke.
Notlösungen aus dem PM-Werkzeugköfferchen
Ich kramte in meinem Projektmanagement-Werkzeugköfferchen: Was war da noch so drin?
- Entscheidungen im Jour-Fixe-Protokoll schriftlich fixieren? Ja, das geschah sowieso und regelmäßig. Half aber nicht! Entscheidungen wurden revidiert und überschrieben.
- Ich führte Einzelgespräche mit den Stakeholdern, um jeden Einzelnen zur Situation abzuholen und deutlich zu machen, dass weitere Prio-Wechsel das Projekt stark verzögern.
- Arbeitshypothesen? In anderen Projekten bei diesem Kunden hatte es sich bewährt, bei offenen Fragen mit Arbeitshypothesen zu arbeiten. Also mit der am wahrscheinlichsten eintretenden Option weiterzumachen. Doch in diesem Projekt waren von mir formulierte Hypothesen nach nur wenigen Tagen nichts mehr wert.
Der Wendepunkt: Neue Leitung übernimmt
So langsam war ich mit meinem Latein am Ende. Aber inzwischen war die Leitungsposition von IT/Softwareentwicklung wieder besetzt, und nach kurzer Einarbeitungszeit war mein Projekt stark im Fokus der neuen Leitung – glücklicherweise. Ich konnte meine Sicht der Dinge nun mit der frischen Führungskraft besprechen, fehlende Entscheidungskompetenzen aufzeigen und notwendige Dringlichkeit herstellen.
Die neue Leitung holte alle Beteiligten an den (virtuellen) runden Tisch und traf zwei Entscheidungen:
- Klare inhaltliche Fokussierung bis Projektende.
- Klare Absichtserklärung, das derzeitige Projektteam über das Projektende hinaus an den weiteren Themen arbeiten zu lassen.
Insbesondere die zweite Entscheidung führte nach meiner Wahrnehmung dazu, dass die Stakeholder entspannter waren und in das Projekt eine gewisse Ruhe einkehrte. Die Zuversicht, dass man „seine“ Themen irgendwann in die Umsetzung bekommt, stieg. Die „Torschlusspanik“ nahm ab und dadurch entstandene Handlungsmuster reduzierten sich.
Fazit und offene Fragen an euch
Rückblickend würde ich mir an die eigene Nase fassen und sagen: Nachdem ich gemerkt habe, dass ich im bestehenden Projektteam niemanden finde, der ein finaler Entscheider sein kann, hätte ich außerhalb weitersuchen müssen. Ich habe möglicherweise zu viel Energie in das Ziel gesteckt, die Stakeholder zu entschlüsseln.
Welches Fazit würdet ihr ziehen? Was hättet ihr anders gemacht? Oder wie wärt ihr mit der Situation umgegangen? Schreibt das gerne in die Kommentare.
Ausblick
In meinem nächsten Artikel geht es um 10 (scheinbare) Selbstverständlichkeiten im Projektmanagement. Es bleibt also interessant und die Diskussion darf weitergehen. Seid gerne wieder dabei.
