Wer ist verantwortlich? Oder auch: Wer hat Schuld?

In den letzten Monaten bin ich immer wieder mit der Frage konfrontiert worden, wer verantwortlich sei. Es handelte sich dabei um agile Sortwareentwicklungsprojekte in Organisationen, die noch nicht „geübt“ mit agilen Vorgehensweisen war. Hintergrund waren in der Regel Probleme in der Projektdurchführung (z.B. langsamerer Fortschritt als erwartet) und die Suche nach dem Äquivalent eines Projektleiters. 

Die übliche Antwort erfolgte dann im Sinne „der Product Owner ist verantwortlich dafür, dass das Richtige gebaut wird. Der Scrum Master ist verantwortlich für die Effizienz des Teams. Das Entwicklungsteam ist für die Herstellung und Qualität verantwortlich“. Aber die Antwort befriedigte nicht den Fragenden. Wen muss ich denn jetzt in den Arsch treten, damit es schneller geht? 

Mal abgesehen von grundsätzlichen Punkten wie Führungskultur zeigt sich hier ein Phänomen, was ich „Illusion von Kontrolle“ nennen möchte. Es existiert die Illusion, dass eine starke Person (der Projektleiter) die Kontrolle über das Projekt hat. Das war in klassischen Projektvorgehensweisen nicht so und ist im agilen Kontext weiterhin nicht der Fall. Lassen Sie uns mal typische Probleme im Projektalltag ansehen. 

Der Projektfortschritt ist langsamer als erwartet, ein Meilenstein ist in Gefahr. Ein Klassiker. Was sind denkbare Maßnahmen? 

• Ein trotziges Aufstampfen „das muss aber funktionieren. Die Faulenzer müssen mal loslegen. Arme und Beine bilden rotierende Scheiben ohne Bodenkontakt“. Hilft das? Natürlich nicht. 
  • In der Regel ist das Projektteam motiviert und möchte ein erfolgreiches Projekt abliefern. Beleidigungen und Unterstellungen bewirken eher das Gegenteil. 
  • Sind tatsächlich Faulenzer im Team, werden diese durch bloßes Aufstampfen nicht zu Top-Performern. Hier muss an den Ursachen gearbeitet werden, was aber keine kurzfristigen Erfolge zeigen wird. Ob diese Aufgaben ein Projektleiter oder ein Scrum Master übernimmt, ist beliebig. 
  • Maßnahmen wie Überstunden oder Wochenendarbeit sind nicht nachhaltig. Es besteht die Gefahr, dass das Team ausbrennt und die Produktivität und Qualität langfristig geringer wird. 

• „Wir müssen das Team vergrößern“. Eine Maßnahme, bei deren Wirksamkeit und Umsetzbarkeit ich Zweifel habe. 
  • Adding more resources to a late project makes it later. Brooks Gesetz ist sicherlich sehr pointiert formuliert. Nichtsdestotrotz ist „mehr Leute“ nicht immer eine geeignete Lösung und schon gar keine einfache Lösung. Es müssen diverse Dinge bedacht werden, z.B. die Projektphase, die Teamzusammensetzung, Komplexität der Software, Know-How der neuen Teammitglieder, Kommunikationsarten, Teilbarkeit der Aufgaben usw.  
  • Sofern man von der Wirksamkeit überzeugt ist, stellt sich ja die nächste Frage: wo kommen diese Menschen her? Wir reden ja nicht über Bleistifte, die man im Katalog bestellen kann, sondern über Menschen. Hier ist ein Projektleiter in keiner besseren Position als ein agiles Team. 
    • Es werden interne Mitarbeiter gesucht. Üblicherweise sitzen nicht Heerscharen von fähigen Mitarbeitern däumchendrehend auf der Bank. Diese müssen also aus anderen Projekten abgezogen werden. Dies kann der Projektleiter in derRegel nicht entscheiden, die Entscheidung über die Priorisierung mehrerer Projekte trifft eine Programmleitung, ein Portfoliomanager, eine Geschäftsführung etc. 
    • Es werden externe Mitarbeiter gesucht. Häufig hat ein Projektleiter nur ein fiktives Projektbudget. Sobald ein externer Mittelabfluss notwendig ist, ist eine Führungskraft mit echter Budgetverantwortung involviert, welche die Entscheidung trifft. 

• Wir müssen den Scope reduzieren. Eine Entscheidung, die ein Projektleiter äußerst selten trifft, ein Product Owner hingegen sehr wohl. 
  • Wird ein Reduzierung des Scopes notwendig, unterbreitet der Projektleiter üblicherweise einen Vorschlag für den Auftraggeber oder Lenkungsausschuss. Dieser trifft dann die endgültige Entscheidung. 
  • Ein Product Owner mit weitreichendem Mandat kann diese Entscheidung selber treffen. Aber selbst ein PO als „Erfüllungsgehilfe“ des Auftraggebers kann die Entscheidung einfacher herbeiführen, da die wichtigsten Scope-Elemente bereits umgesetzt sind. 

Die Kosten laufen aus dem Ruder. Das Projektbudget reicht nicht. Hierfür kann es – bei Softwareentwicklungsprojekten - aus meiner Sicht nur drei Gründe geben.  

• Möglichkeit eins: Die Projektdauer ist länger als erwartet, die höheren Kosten sind eine Konsequenz daraus. Dann siehe oben.  
• Möglichkeit zwei: das Projektteam ist größer als erwartet. Siehe oben.  
• Möglichkeit drei: das Projektteam ist zu teuer, d.h. der Anteil interne / externe Mitarbeiter ist anders als geplant oder die Tagessätze der externen Mitarbeiter sind höher als geplant. Eine Kostensteigerung aus diesen Gründen kann ja eigentlich nicht überraschend sein, sondern ließe sich zu Projektbeginn leicht ausrechnen. Aber sei es drum, leicht und schnell lässt sich diese Situation auch nicht ändern. Ein Ersatz externer Mitarbeiter durch interne dauert ca. 3-9 Monate und lässt sich nur unter Mithilfe der Linienorganisation stemmen. Ein Ersatz externer Mitarbeiter durch „günstigere“ funktioniert tendenziell schneller, aber auch hier ist der Handlungsspielraum eines Projektleiters häufig eingeschränkt. 

Das Projekt liefert nicht das erwartete Ergebnis. Dies ist aus meiner Sicht der GAU. Und es betrifft insbesondere Projekte, die mit klassischen Vorgehensweisen durchgeführt werden. Hier ist der Zeitraum zwischen Anforderungsformulierung und Sichtbarkeit der Ergebnisse besonders lang. Und die Gründe hierfür sind für einen Projektleiter auch nur schwer zu kontrollieren. 

• Die Anforderungen sind unvollständig. Dieses Problem versucht man häufig, durch Abnahmen der Anforderungsdokumentation oder des Fachdesigns in den Griff zu bekommen. Damit ist man „formal“ aus dem Schneider, aber der Anforderer hat immer noch das Problem, dass die Anforderungen nur teilweise umgesetzt sind. 
• Die Anforderungen haben sich geändert. Was heute richtig ist, kann in 12 Monaten schon wieder anders sein. Als Projektleiter hat man wenig Möglichkeiten, diese Problematik zu lösen. 
• In jedem Fall kommt man um eine schwierige Entscheidung nicht herum. Das Projekt kann eingestellt werden oder es kann nachgearbeitet werden. Beide Entscheidungen trifft selten der Projektleiter, sondern entweder der Auftraggeber oder der Lenkungsausschuss.  

Diese Beispiele zeigen aus meiner Sicht recht deutlich, dass ein Projektleiter ein Projekt in Schieflage nicht alleine retten kann. Er ist eventuell alleine verantwortlich, aber für die Lösung gravierender Probleme ist er auf die Mitwirkung anderer angewiesen. Es gibt eine Illusion von Kontrolle. Allerdings ist es sehr viel einfacher, einen Schuldigen zu finden… 

Mich interessiert brennend Ihre Sicht auf dieses Thema!

Vertiefende Beiträge: 

• https://tisquirrel.me/2014/07/04/ok-but-who-is-resposible-for-delivery/ 
• https://www.scrumalliance.org/community/articles/2014/october/who-is-responsible-for-schedule-slippage 
• https://softwareengineering.stackexchange.com/questions/311047/dealing-with-failed-sprints-and-deadlines 
• https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think