iX | Gezielte Wahl (Teil 1)

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 zum Unternehmen?

Agil oder klassisch – Hinweise zur Methodenwahl

Cover-Foto iX März 2013
Cover-Foto iX März 2013

In der aktuellen Debatte um die passende Projektmethode diskutieren Verantwortliche sowohl klassische als auch agile Ansätze. Beide basieren auf unterschiedlichen Sichtweisen des Wirtschafts- geschehens – 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ür die Mannschaft 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 Stan- dards 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.

Wissensbereiche des klassischen Projektmanagements

  • Integrationsmanagement: eine Projektlandschaft aufbauen, Schnittstellen definieren und abstimmen.
  • Anforderungsmanagement: Projektziele aufnehmen und überwachen, Anforderungsänderungen aufnehmen, bewerten und einarbeiten.
  • Terminmanagement: Termine von Aufgaben, Meilensteinen, Teilprojekten sowie des Gesamtprojekts definieren und überwachen. Das Terminmanagement setzt auf dem Projektplan auf.
  • Kostenmanagement: Budget des Teil- und Gesamtprojekts definieren und überwachen. Das Kostenmanagement setzt Impulse für das Anforderungsmanagement während des Projektverlaufs.
  • Qualitätsmanagement: Qualitätskriterien zum Erreichen des gesetzten Ziels definieren und überwachen – hier definiert das Team Projektprozesse und standardisiert Projektvorgänge.
  • Personalmanagement: Notwendige Personalressourcen ermitteln und beschaffen. In diesen Bereich fallen Aufgaben der Teamentwicklung und des Wissensaufbaus der beteiligten Mitarbeiter.
  • Kommunikationsmanagement: Projektinformationen aufnehmen und verteilen, insbesondere den Informationsaustausch zwischen den Projektbeteiligten koordinieren.
  • Risikomanagement: Projektrisiken aufnehmen, bewerten und überwachen, sowie den Umgang mit ihnen definieren beziehungsweise Gegenmaßnahmen treffen.
  • Beschaffungsmanagement: alle Projektbeteiligten und Zulieferer integrieren.
  • Veränderungsmanagement: Anforderungsänderungen aufnehmen, bewerten und in das Projekt einarbeiten. 

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 Heraus- forderungen – 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 Methoden- bausteine 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 der Projektmanager die notwendigen Daten erfasst und sichert, 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.

Prinzipien des agilen Projektmanagements

  • Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
  • Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
  • Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklerteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
  • Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbst- organisierte Teams.
  • In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten an. 

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 organisiernde 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 des Kunden.“ 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 alten, 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 für ein Softwareprojekt nicht zu erwarten.

 

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 Mannschaften 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 Unterneh- men 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 Beteilgte 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 Mannschaften 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. 


Gezielte Wahl, Teil 2 | Dieser Artikel ist erstmals in der iX im Heise-Verlag, Ausgabe März 2013, erschienen. Der Text ist abweichend von den anderen Blog-Einträgen in der Sie-Form und nicht geschlechtsneutral formuliert.


Kommentar schreiben

Kommentare: 0