Bei der Auswahl der passenden Projektmethode propagieren die einen agile Methoden, während andere argumentieren, dass man Prince2 und CMMI doch nur richtig anwenden müsse.
Doch welche Projektmethode ist für ein konkretes Projekt Erfolg versprechend? Welche Methodenbausteine passen zur Organisation?
Agil oder klassisch – Hinweise zur Methodenwahl
In der aktuellen Debatte um die passende Projektmethode diskutieren Verantwortliche sowohl klassische als auch agile Ansätze. Beide basieren auf unterschiedlichen Sichtweisen des Wirtschaftsgeschehens – und beide Herangehensweisen haben ihre Berechtigung. Bei der Wahl des angemessenen Vorgehens für das eigene Unternehmen sollte jedes Projektteam genau darauf achten, dass die gewählte Methode fürs Projektteam stimmig ist.
In der klassischen Sicht ist die Wirtschaft eine komplexe Welt: Projekte sind über umfassende Pläne abbildbar. Geprägt durch diese tayloristische Sicht gilt es, die gestellte Aufgabe so in Teile zu gliedern, dass das Team diese konzertiert und arbeitsteilig in Prozessabschnitten bearbeiten kann. Das Projektmanagement koordiniert diese Arbeitsschritte. Zentrales Artefakt ist der Projektplan, der alle Teilschritte und Zwischenergebnisse beschreibt.
Kriterien der klassischen Methoden
Klassisches Projektmanagement begreift sich als führende, ordnende und anweisende Kraft. Den Projektplan setzt man initial auf und überwacht dessen Umsetzung ständig. Änderungen und Abweichungen arbeitet man sofort in den Plan ein.
Zum Steigern der Effizienz und zum leichteren Koordinieren der Teilschritte versuchen klassische Methoden Standards zu etablieren. Um diese präzise zu gestalten, dokumentiert das Team sie schriftlich. Ein Großteil der Kommunikation erfolgt daher in schriftlicher Form. Das klassische Projektmanagement unterteilt sich in neun Wissensbereiche (manche benennen zehn Bereiche), deren Zusammenspiel im zentralen Artefakt, dem Projektplan, mündet.
Typischer Start: Am Anfang die kleinen Aufgaben
Viele Verantwortliche beginnen mit kleinen Projekten, die in ihrer Vielschichtigkeit überschaubar sind. Es sind alle Aufgaben zu erfassen, zu verteilen und deren Erfüllung zu überwachen. Das ist eine organisatorische Schwierigkeit, die etliche Wissensgebiete des Projektmanagements lediglich streift. Wachsen die Herausforderungen – zum Beispiel durch eine höhere Komplexität oder schlicht durch einen größeren Umfang – ist mehr als das Organisieren von Aufgaben gefragt. Die kleineren Projekte hat man bisher nicht geleitet, die gewählten Methodenbau- steine sind der Komplexität oft nicht angemessen.
Zahlreiche Unternehmen erkennen die gestiegenen Anforderungen nicht, so dass betroffene Manager weiter versuchen, mit dem Organisieren von Einzelaufgaben ein großes Projekt zu leiten. Dieses Unterfangen scheitert aller Voraussicht nach, denn es führt zu einem Ansatz, der im Ungefähren bleibt und dessen Methodenbausteine nicht bewusst und der Situation angepasst sind. Dieses Vorgehen lässt sich mit SWBLM („So wie beim letzten Mal“) umschreiben.
Klassische Methoden wie Prince2 stellen diesem Ungefähren einen Kanon an Bausteinen entgegen, durch deren Bearbeiten man die Wissensbereiche des Projektmanagements abdeckt. Entsprechend der Direktive schriftlicher Artefakte konzentriert sich hier die berufliche Ausbildung auf schriftliche Dokumente wie Steuerungs- und Statusberichte oder Risikoanalysen. Die Frage, wie die Projektmanager*nnen die notwendigen Daten erfassen und sichern, erfährt wenig Beachtung. Damit liegt der Schwerpunkt beim Vermitteln einer klassischen Methode auf der Leitfrage „Was“, während das „Wie“ unterrepräsentiert ist.
Kommunikation in agilen Projektmethoden
Agile Projektmethoden beantworten dagegen schwerpunktmäßig die Leitfrage „Wie“ mit zwölf Prinzipien, auf denen das agile Manifest basiert.
Entsprechend dieser Prägung stellen agile Methoden Kommunikationsrituale in den Vordergrund, die parallel den zeitlichen Ablauf der Projektarbeit bestimmen. Aus dieser Taktung und den Kommunikationsergebnissen heraus lassen sich eine Projektplanung und andere schriftliche Artefakte ableiten.
Vertreter der agilen Bewegung fordern eine kommunikative Projektsituation, in der alle Beteiligten auf Augenhöhe miteinander sprechen und verhandeln. Software-Entwicklung soll nach Meinung der agilen Bewegung durch sich selbst organisierende Teams erfolgen. Damit unterstellen die agilen Ansätze implizit, dass das Steuern eines Projekts durch einen zentralen Projektplan nicht machbar sei.
Die agile Bewegung versucht, über geeignete Methodenbausteine schnell und umfassend auf Anforderungsänderungen zu reagieren:
„Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil der Kund*innen.“
Dabei verstehen sich agile Teams als lernend. Durch den regelmäßigen Rückblick während des Verlaufs versuchen sie die Zusammenarbeit zu verbessern – und durch fortwährendes Optimieren die Liefergeschwindigkeit zu steigern.
Um diesen Lernprozess zu ermöglichen und frühzeitig Änderungsanforderungen als solche zu erkennen, setzt die agile Bewegung auf die regelmäßige und direkte Kommunikation der Beteiligten. Anschließend dokumentieren agile Projekte Vereinbarungen und Erkenntnisse schriftlich.
Einsatz agiler Projektmethoden
Agile Ansätze sollen den Weg in eine positive Projektwelt weisen. Während Teammitglieder sich in der klassischen Welt zu Ausführungsgehilfen des Managements degradiert fühlen können, verspricht die agile Bewegung eine gleichberechtigte Projektrolle. Doch gerade diese Rollenänderung erfolgt in vielen Unternehmen nicht. Arbeitet das gesamte Unternehmen klassisch-hierarchisch, ist ein Umgangswandel der beteiligten Manager*innen für ein Softwareprojekt eine eigene Herausforderung.
Hinzu kommt die Rollenwahrnehmung der IT als solche: Sieht die Firma die Abteilung als ausführende Kraft – also als Teil der Produktion, die keine eigene Stimme beim Ausformulieren der Unternehmensziele hat, ist das erfolgreiche Einführen agiler Methoden nahezu ausgeschlossen. Die agile Bewegung sieht die IT als einen ebenbürtigen Partner im Unternehmen an und setzt auf Teamarbeit als Erfolgsmodell. In vielen Betrieben widerspricht das jedoch der Wirklichkeit.
Zum Einführen agiler Methoden müssen sich die Beteiligten über eine gewandelte Sicht des Projektumfelds einigen. Indem es die Rollen anpasst und neue Methoden einführt, reagiert das Team auf diese Veränderung. Dieses Vorgehen müssen diejenigen mittragen, die in der Hierarchie über der Mannschaft verankert sind. Alle zusammen müssen sich einigen, wie man Ziele definieren und ihr Erreichen überprüfen kann. Da die übergeordneten Manager meist nicht direkt von ihren eigenen Ritualen ablassen können, sind angepasste und dem agilen Projekt- vorgehen angemessene Berichtsinhalte ebenfalls zu bestimmen.
Herausforderungen beim Wechseln der Methoden
Ein Übergang in die agile Projektwelt erfolgt in vielen Softwareteams vor dem Hintergrund hoher Unzufriedenheit mit der letzten Arbeit: Nicht selten ist direkt vor einem Wechsel ein Softwareprojekt gescheitert. Bei der Wahl einer neuen Methode favorisieren viele Teams aktuell agile Ansätze. Schließlich haftet dem klassischen Wasserfall-Vorgehen der Ruf an, sie wären umständlich und würden nicht zum Erfolg führen. Und genau dies hätten ja die vergangenen Projekte bewiesen.
Diese generelle Aussage ist jedoch zu hinterfragen: Ist das letzte Projekt daran gescheitert, dass die klassische Projektmethode nicht passte – oder daran, dass man zu wenige Projektbausteine explizit und bewusst nutzte? In vielen Unternehmen herrscht Wissensnotstand um Projektmethoden.
Das inflationäre Nutzen des Worts „Projekt“ zeigt Wirkung. Viele im Team glauben, sie würden in einem klassischen Projekt arbeiten, während sie doch nur Aufgaben organisieren – und das mehr schlecht als recht.
Ein genauer Blick auf die verwendeten Ansätze und die genutzten Bausteine zeigt zweierlei:
Das Projektteam hat eine der Situation angemessene Projektmethode etabliert, die jedoch keiner „Lehrbuch-Methode“ entspricht, aber mit einem Lehrbuchnamen charakterisiert ist. Das führt zu unterschiedlichen Erwartungshaltungen an Rollen und Rituale. Die Ergebnisse dieser Missverständnisse zeigen sich häufig spät im Projekt – und meist mit negativen Folgen für das Resultat.
Nur wenige Beteiligte können bewusst alle genutzten Methodenbausteine benennen. SWBLM zeigt sich in Reinkultur. Durch den Wechsel der Mitarbeiter kann es sein, dass das Wissen über bisher genutzte Bausteine zum Nachteil des gesamten Teams wegfällt.
Eine Methode beinhaltet die Team- Rituale während des Projekts. Daneben existieren viele Verhaltensweisen und kleine Maßnahmen, die den Projekterfolg stützen. Gerade die sind wenigen Teams in ihrer Gesamtheit bekannt. Vor einem Wechsel des Ansatzes sollten sich daher Teams vergegenwärtigen, welche Bausteine sie in ihrem Alltag gerade nutzen – und welche davon passend oder optimierungsbedürftig sind. Durch eine Reflexion des eigenen Verhaltens sichern sich die Teams dagegen ab, Bausteine abzuschaffen, die sie bisher weit getragen haben.
Eigene Projektmethoden reformieren
Vor der Wahl der Bausteine sollten Softwareteams darüber nachdenken, ob sie eher in der klassischen oder besser in der agilen Projektwelt aufgehoben sind - also ob die vor ihnen liegende Aufgaben eher komplizierter oder komplexer Natur ist. Und diese Frage ist sowohl für die Gruppe als solche als auch für die Zusammenarbeit mit allen anderen Beteiligten zu stellen.
Ist die Unternehmenskultur klassisch-hierarchisch geprägt, sollte das Teams Kommunikations- + Informationsformen ausprobieren, die für Dein agiles Wirken + die klassische Hierarchie gleichermaßen funktionieren.
Ohne umfassende Maßnahmen kann man hier nicht ein komplettes agiles Vorgehen einführen. Ein Team kann nur seine eigene Arbeitsweise ändern. Eine Änderung der Arbeitsumgebung kann nur schrittweise als Reaktion auf zum Beispiel Kommunikations- und Informationsexperimente erfolgen.
Ein Umbruch der Methode bedeutet einen Verhaltenswandel für eine Gruppe. Diese Entwicklungen – für jeden Einzelnen genauso wie für Teams – brauchen ihre Zeit. Insofern empfiehlt es sich, den aktuell genutzten Ansatz Schritt für Schritt umzugestalten. Dabei sind Bausteine,
die man bisher implizit nutzt, zu explizieren beziehungsweise
solche, die ineffizient im Projektumfeld sind, durch andere zu ersetzen.
Passende Methodenbausteine finden: Ways of Working definieren
Wenn man einen Methodenbaustein als ineffizient erkannt hat, ist es die Aufgabe aller Mitarbeiter, einen neuen zu definieren. Um eine passende Wahl zu ermöglichen, sollten die Beteiligten ausarbeiten, warum der Baustein im eigenen Projekt nicht funktioniert hat. Sobald die Gründe feststehen, kann das Team Veränderungen konzipieren, die den Projektverlauf verbessern sollen. Zum Beispiel könnten die Schritte wie folgt aussehen:
Im klassischen Projektmanagement, genauer dem Kostenmanagement, ist die Restaufwandsschätzung oft fehlerhaft. Diese sollte einen wichtigen Hinweis für den Projekterfolg und das Änderungsmanagement bieten – insofern ist allen Beteiligten daran gelegen, eine korrekte Zahl zu ermitteln. Häufig erfolgt die Restaufwandsschätzung durch einen einfachen Dreisatz: Nach Kontrolle der bisher aufgelaufenen Aufwände ermittelt man den Restaufwand durch Vergleich mit der Ursprungsschätzung. Durch dieses Verfahren erkennt man erst beim Überschreiten der Ausgangswerte, dass eine Fehlschätzung vorliegt. Um dem entgegenzuwirken, könnte das Team als wöchentliche Maßnahme eine aktive Restaufwandsschätzung (wahlweise gestützt oder ungestützt gegen Verbrauch und Ursprungszahlen) der aktiv bearbeiteten Aufgaben vereinbaren.
Aber auch mit agilen Methoden kann Veränderungsbedarf bestehen: Die Planung einzelner Sprints erfolgt bei Scrum durch Sprint Planning I und II. Während im Sprint Planning I der*die Product Owner*in Anforderungen und Prioritäten für die einzelnen Anforderungen definiert, bewertet das Entwicklungsteam unter Leitung des*der Scrum Master*in im Sprint Planning II die technische Komplexität und plant den Sprint im Detail. In vielen Gruppen entstehen in dieser Phase des Sprints zeitraubende Abstimmungsschleifen. Ursachen hierfür können sein:
Fachliche Anforderungen erweisen sich als zu wenig konkret.
Diskutierte technische Umsetzungen haben Einfluss auf die Fachlichkeit.
Wenn man diese Unstimmigkeiten als Ursachen für die Abstimmungsschleifen erkannt hat, könnte eine Änderung darin bestehen, die fachlichen Anforderungen und die resultierende technische Bewertung in einer gemeinsamen Sitzung unter Beteiligung von Project Owner*in, Scrum Master*in und Team vorzunehmen.
Beim Korrigieren einer Methode sollten die einzelnen Änderungen jeweils für sich nicht zu groß sein. Auch sollte man nicht zu viele Modifikationen auf einmal vornehmen. Gerade in Krisen fallen alle Beteiligten in altes Verhalten zurück, wenn eine Großzahl von Veränderungen zu beachten ist. Das können viele Organisationsmitglieder nicht gleichzeitig leisten. Auch hier gilt das agile Motto:
"Fokus ist Trumpf!"
Durch regelmäßige Kontrolle der Zusammenarbeit kann man die Effizienz der Veränderungen überprüfen. Das Team kann so nach und nach die eigene Methode optimieren.
Tabelle 1: Ermitteln der aktuellen Methodenbausteine
| Zurück | Im Hier und Jetzt | Voraus |
Wie? | Kommunikation | Termine, Personal, Kommunikation | Integration, Qualität, Beschaffung |
Was? | Qualität, Kosten | Anforderungen | Anforderungen, Risiken |
Leitfragen zum Identifizieren von Methodenbausteinen
Damit ein Projekt erfolgreich verläuft, sind die vier Leitfragen „Wohin?“, „Warum?“, „Was?“ und „Wie?“ zu beantworten. Während in vielen Unternehmen das übergeordnete Management die strategische Verortung eines Projekts vornimmt und an die Gruppen vermittelt, kann die Frage „Warum?“ bereits in den Teams liegen. Je stärker ein Unternehmen hierarchisch organisiert ist, desto eher befasst sich auch das höhergestellte Management mit der Frage, worin Erfolg und Misserfolg bestimmter Maßnahmen begründet sind. Je agiler ein Unternehmen aufgestellt ist, desto stärker beantwortet diese Frage das Team im Rahmen einer positiven Fehlerkultur. Die Leitfragen für das Projektmanagement lauten „Was?“ und „Wie?“
Was: Welche Aufgaben liegen an? Was genau muss das Team, was die anderen Projektbeteiligten leisten?
Wie: Wie genau geht das Team vor? Welche Rituale führt es ein? Wie gestaltet sich die tägliche Zusammenarbeit? Wie berichtet die Gruppe? Woran misst das Team Erfolg?
Eine Alternative zum schrittweisen Vorgehen ist der komplette Schwenk auf eine neue Methode. Die meisten Ansätze konzentrieren sich auf bestimmte Elemente. Durch Überprüfen der zehn Wissensbereiche des Projektmanagements sowie der zwei Leitfragen kann das Team sicherstellen, alle wesentlichen Fragen geklärt zu haben. Zum Testen empfiehlt es sich, hier ebenfalls die Tabelle 2 auszufüllen. Die Gruppe sollte gleichzeitig bei allen vorgestellten Bausteinen hinterfragen, warum man diese in eben jener Form vorgeschlagen hat – und im eigenen Umfeld evaluieren, ob der Einsatz zielführend sein kann.
Tabelle 2: Bausteine und schriftliche Artefakte, also Ways of Working, festlegen
| Zurück | Im Hier und Jetzt | Voraus |
Wie? | Retrospektive des Sprints, Sprint-Review, Projekt-Review | Statusbericht, Zeitplan, Daily Standup an der Wandzeitung, zweiwöchrige Sprints, Montag: Teamfrühstück | Pair Programming, Zeitplan für Zulieferer, API-Definition über Workshop, zweiwöchentlich: Telefonkonferenz mit Datenbank-Anbieter |
Was? | Steuerungsmeeting mit Auftraggeber, Qualitätsmanagement über QA-Abteilung, wöchentliche Aufwandskontrolle, Change-Request-Puffer von 20 Prozent im Projektbudget | „Definition of Done“ für alle Projektbeteiligten | Kick-off-Workshop zur Ziel- definition, Workshop zur Erstellung von User-Stories, Risikotabelle im Intranet, wöchentliche Restaufwands- schätzung, Sprint-Planung mit Auftraggeber und Team |
Ein Ändern aller Bausteine führt dazu, dass keiner der Bausteine wirklich eingeübt ist. Gerade in kritischen Situationen und unter Zeitdruck fallen Beteiligte auf ein älteres – das bisherige – Verhalten zurück. Im Team löst das meist große Unruhe und Unsicherheit aus. Anstelle eines neuen Ansatzes liegt so eine ungeklärte Sammlung von alten und neuen Bausteinen vor. Um dieses Chaos zu vermeiden, ist ein schrittweiser Wandel vorzuziehen.
Viele Methoden sehen eine Sitzung („Review“ beziehungsweise „Lessons learned“) am Ende des Projekts mit allen Beteiligten vor. So will man erfolgreiche und optimierungsbedürftige Verfahren ermitteln. Die Ergebnisse dienen dem Wissensaufbau in der Organisation – und sollen als Grundlage zum Verbessern nachfolgender Projekte dienen. Eine solches Vorgehen bedingt, dass alle vorurteilsfrei und ohne Nachteile für die Beteiligten über den Verlauf sprechen können. Ist eine positive Fehlerkultur nicht in einem Unternehmen – insbesondere beim Auftraggeber – verankert, sollte man eine andere Form finden, wie man das Vorgehen im Nachhinein bewerten kann.
Evaluieren und Verbessern der Projekte
Agile Methoden sehen ein stetiges Verbessern des Projekts vor, indem Teams regelmäßig im Verlauf Retrospektiven vornehmen. Durch kleine Änderungen können die Beteiligten so auf Fehlannahmen und geänderte Anforderungen direkt reagieren. Eine Retrospektive ist ein Baustein, der das „Wie“ beantwortet.
Die Leitfragen „Was?“ und „Wie?“ des Managements sind in drei zeitlichen Dimensionen zu beantworten: Im Rückblick auf abgelaufene Projekte beziehungsweise bereits bearbeitete Schritte, im Hier und Jetzt sowie im Ausblick auf kommende Aktionen.
Es ist empfehlenswert, für jede der Fragestellungen ein Ritual einzuführen, das die Antworten auf die Leitfragen gibt. Rituale vermitteln den Beteiligten Sicherheit im täglichen Geschehen. Gleichzeitig ist es schwerer, über wiederkehrende Handlungen hinwegzugehen. Hat man ein bestimmtes Vorgehen nicht ritualisiert, vergisst man die betreffende Fragestellung in Krisenzeiten oder unter großem zeitlichem Druck.
Hauptakteur*innen von Ritualen können Einzelne (zum Beispiel aus dem Projektmanagement), andere Beteiligte oder alle Mitglieder sein. Je agiler sich eine Mannschaft versteht, desto stärker beteiligt sich das gesamte Team am Beantworten. Die klassischen Wissensbereiche des Projektmanagements ordnen sich in diese Fragestellungen ein. Tabelle 1 verdeutlicht diese Zuordnung.
Das Team kann diese Tabelle auch zum Ermitteln der aktuelle genutzten Bausteine heranziehen. Beim Ausfüllen fallen Mitarbeiter*innen häufig Kommunikationsrituale auf und ein, die man bisher nicht als projektrelevant erachtet hat. Treffen sich Mitarbeiter wöchentlich zum Mittagessen, kann das ein wichtiges Element der Frage nach dem „Wie“ im „Hier und Jetzt“ sein. Dieses Element sollte man zusätzlich in der Beschreibung der Bausteine aufführen.
So kann das Team genutzte, aber bis- her nicht explizit benannte Bausteine erfassen. Fehlende Bausteine kann man durch Vergleich mit den zehn Wissensbereichen des Projektmanagements ermitteln. Durch das systematische Annähern können Teams, die bisher SWBLM gefolgt sind, ihre Methode vervollständigen.
Ein solches Zusammenstellen von Bausteinen kann sowohl klassische als auch agile Elemente enthalten.
In Tabelle 2 könnt Ihr Bausteine und schriftliche Artefakte eintragen. Bei Letzteren sollte sich das Team einig sein, auf welchem Weg (d.h. „Wie“) das schriftliche Artefakt entsteht. So ist das Erstellen eines wöchentlichen Statusberichts in einigen Teams allein Aufgabe des Projektmanagers, in anderen entwickelt und formuliert ihn eine Teamsitzung.
Fazit
Durch das Erfassen und Definieren aller Bausteine sorgt das Team für Transparenz im weiteren Verlauf. Es empfiehlt sich, beim Einführen einer gesamten Methode die Bausteine anhand der zehn Wissensbereiche des Projektmanagements und der Leitfragen „Was?“ und „Wie?“ zu prüfen. So klärt das Team sein "Ways of Working" + kann erfolgreich liefern.
Dieser Artikel basiert auf einem Beitrag der Autorin Judith Andresen zur iX "IT-Projekte erfolgreich managen" (Ausgabe 3/2013).