Sieben Thesen zum agilen Projekt-Management

Immer mehr Unternehmen möchten - und müssen - agil sein, auch im Projekt-Management (PM). Doch obwohl diese Methode offenbar eine gewisse Anziehungskraft ausübt, scheuen viele Projektleiter am Ende doch den Griff in den agilen Handwerkskasten, wenn es an die konkrete Umsetzung geht. Die Bedenken sind häufig berechtigt. Denn längst nicht jedes Projekt und vor allem nicht jedes Unternehmen sind für die vermeintlich selbststeuernde Methodik geeignet.

Dazu ein Beispiel: Ein Großunternehmen setzt ein Programm zur Evaluierung, Entwicklung und Einführung eines neuen IT-Systems auf. Das Programm mit 200 beteiligten Mitarbeitern gliedert sich in zehn Projekte mit bis zu je drei Teilprojekten. In neun Projekten kommen auf oberster Ebene Methoden des klassischen PM zum Einsatz, in einzelnen Teilprojekten auch agile Methoden. Das zehnte Vorhaben mit einem Budgetrahmen von rund 30 Millionen Euro wird komplett agil gemanagt.

Eine Zwischenbilanz nach drei Jahren ergibt Folgendes: Die neun auf oberster Ebene klassisch betriebenen Projekte sind durchweg erfolgreich. Zwar sind klassische Projektplanung und iteratives, agiles Vorgehen auf Teilprojektebene im Hinblick auf Zeitplanung und einheitliches Reporting nicht immer einfach unter einen Hut zu bringen, aber am Ende funktioniert es meistens doch.

Risikofaktor agiles Projekt-Management

Der eindeutige Verlierer ist das komplett agil geführte Projekt. Während der gesamten Laufzeit macht es vor allem mit unklarer Kostenplanung, ständigen Nachforderungen in Sachen Budget und intransparenter Zeitplanung von sich reden und entwickelt sich schließlich zum Risikofaktor für den gesamten Release-Plan. Im konkreten Projekt kam es dadurch am Ende zu wesentlichen Abweichungen von der ursprünglichen Zeitplanung.

Doch was lief schief und was lässt sich daraus lernen? Die folgenden sieben Thesen geben Antworten auf diese Fragen.

These 1: IT-Projekte werden immer komplexer

Statement: Die wachsende Nachfrage nach agilen PM-Methoden wie zum Beispiel Scrum ist Folge des enormen Komplexitätszuwachses insbesondere in IT-Projekten.

Projektmitarbeiter, die schon länger im Geschäft sind, wissen, wovon die Rede ist. Kunden verändern immer häufiger und immer schneller ihre Anforderungen. Aber auch die schiere Komplexität der Projektinhalte und -ziele lässt den Bedarf an innovativen Vorgehensweisen ständig größer werden. Die Vorteile agiler Projekt-Management-Methoden mit Vorgehensmodellen wie Scrum liegen dabei auf der Hand. Weit mehr als die klassischen Methoden bieten sie die Möglichkeit, den Kunden von Anfang an mit ins Boot zu nehmen. Das erhöht nicht nur die Erfolgswahrscheinlichkeit des Projekts, sondern meist auch die Zufriedenheit im Team.

These 2: Agiles Projekt-Management birgt Sprengstoff

Statement: Obwohl agile Methoden viele Vorteile haben - beispielsweise schnellere Ergebnisse und mehr Zufriedenheit bei den Kunden, sind längst nicht alle Unternehmen dafür geeignet.

Hintergrund: Selbststeuernde Teams und größere Freiheit in der Projektabwicklung bergen enormen Sprengstoff für den Betriebsfrieden. Viele Iterationsschleifen und Prototyp-Provisorien führen nicht zwangsläufig zum erwünschten schnellen Erfolg, sondern können am Ende - aufgrund andauernder zusätzlicher Anforderungen - auch Frustration und Stagnation fördern.

Die Anwendung agiler PM-Methoden ist mehr als reines Handwerkszeug, sie erfordert einen Mentalitätswandel und Umdenken bei Auftraggebern, Stakeholdern und insbesondere beim Management. Über diese "politische" Reichweite von agilem PM sollten sich alle Beteiligten vorab im Klaren sein. Sonst heißt es schnell: Katastrophe inklusive.

These 3: Mehr Vertrauen, weniger Kontrolle

Statement: Agiles PM stellt hohe Anforderungen an die Projektbeteiligten und erfordert einen Vertrauensvorschuss vom Management.

Agiles PM und darauf aufbauende Vorgehensmodelle wie Scrum arbeiten mit selbststeuernden Teams, definierten Rollen, einer engen Einbindung des Kunden und fixen Arbeitszyklen (time boxes).

Projektteam und Management müssen sich damit auf ein völlig autarkes Vorgehen einlassen. Für das Management heißt das: Es muss mehr vorausdenken (zum Beispiel in Bezug auf die Priorisierung von Anforderungen) und zum richtigen Zeitpunkt die Zügel aus der Hand geben. Und für die Mitarbeiter bedeutet das: Extrem selbstständiges Arbeiten, mehr Verantwortung, aber auch deutlich mehr Transparenz in Bezug auf die eigene Arbeitsleistung. Denn in einem agil geführten Projekt wird etwa anhand der Programmierleistung jeden Tag deutlich, was der Einzelne zum Gesamterfolg beigetragen hat. In einem klassischen Projekt kann sich der Einzelne dagegen deutlich besser hinter der Mannschaftsleistung verstecken.

Nicht genug damit, dass das alles meistens neu und ungewohnt ist. Für den Großteil der Unternehmen bedeutet es auch eine neue Führungskultur, die Fragen aufwirft:

• Können die entsprechenden Funktionen kompetent besetzt werden?

• Sind die Mitarbeiter dafür geeignet und qualifiziert?

• Ist das Kundenverhältnis reif für diese Vorgehensweise, haben beide Seiten ausreichend Vertrauen?

Der Einsatz agiler Projektmethoden hat also Konsequenzen - für die Personalentwicklung und die Führungskultur. Denn zum einen müssen agil geführte (Teil-) Projekte von erfahrenen Projektleitern (oder sogenannten Scrum Mastern) aufgesetzt werden, beteiligte Personen und Stakeholder gegebenenfalls geschult und begleitend gecoacht werden. Zum anderen fördert die Auseinandersetzung mit agilen Ansätzen die Selbstkontrolle und -steuerung. Das wiederum impliziert Kontrollverlust und Neujustierung der Kräfteverhältnisse in der Unternehmenshierarchie. Daran haben erfahrungsgemäß nicht alle Beteiligten sofort großes Interesse.

These 4: Weniger ist mehr

Statement: Agile Methoden eignen sich mehr für kleine Projekte.

Agil geführte Projektteams sollten nicht mehr als zehn Mitarbeiter haben. Bei größeren Teams müssen die beteiligten Rollen eingeübt und sicher anwendbar sein. Generell ist es vorteilhaft, wenn einzelne Teammitglieder mit agiler Methodik vertraut sind. Der Grund: Weit mehr als jede andere Methode eröffnet das agile PM die Möglichkeit, über die Erstellung von Prototypen direkt auf die Anforderungen der späteren User einzugehen - und nicht daran vorbei zu entwickeln.

These 5: Agiles Projekt-Management schafft Flexibilität

Statement: Insbesondere in Situationen mit unklaren Anforderungen können agile Methoden hilfreich sein.

Nicht nur die Projektgröße ist ein entscheidendes Kriterium, auch die Ausgangssituation kann für oder gegen den Einsatz agiler Methoden sprechen. Denn während sich klassische Methoden aufgrund besserer Planbarkeit und besserer Controlling-Möglichkeiten eher für Großprojekte und umfangreichere Programme eignen, können agile Methoden unterstützend wirken, wenn Anforderungen (noch) unklar sind oder sich besonders schnell ändern.

These 6: Projekt ist nicht gleich Projekt

Statement: Agiles PM ist nicht per se gut oder schlecht. Es ist vielmehr unter bestimmten Bedingungen ein sinnvolles Vorgehensmodell.

Jedes Projekt ist anders, jedes Umfeld hat seine eigene Dynamik. Trotzdem gibt es Kriterien, die Hinweise darauf geben, ob sich ein Projekt für die agile Methodik eignet und welche Hürden für agiles PM es birgt . Jedes Unternehmen sollte sich folgende Fragen stellen:

• Ist das Projekt beziehungsweise das Unternehmen in einem Umfeld mit komplexen Produkten, Unklarheit und sich häufig wechselnden Anforderungen angesiedelt?

• Verfügt der Betrieb über das notwendige Know-how und Personal?

• Wie verträgt sich die agile Methodik mit der etablierten Unternehmens- und Führungskultur?

These 7: Klassisch mit Agil erzeugt Synergie-Effekte

Statement: Die Kombination beider Methoden ist ideal. Es gilt der Leitsatz: Alles zu seiner Zeit und immer dann, wenn es passt.

Elemente des klassischen Projekt-Managements können die Einführung und Anwendung agiler Methoden deutlich erleichtern. So zeigt die Erfahrung, dass klassische Bausteine wie klar definierte Ziele, Meilensteine oder Termin- und Budgetvorgaben häufig positiv aufgenommen werden. Sie dienen allen Beteiligten als wichtige Orientierungshilfe, nicht zuletzt internen Interessenvertretern wie etwa dem Management.

Doch Agiles und Klassisches lässt sich auch durchaus mischen. Dabei muss an der einen oder anderen Stelle natürlich feinjustiert werden, etwa in dem Sinne, dass herkömmliches Reporting auf Programmebene auch iterative Vorgehensmodelle der unteren Ebenen zulässt (was die häufig eingesetzten Wasserfallmodelle zumindest im Grundsatz nicht gerade erleichtern).

Gelingt die Synergie von agil und klassisch, kann sich ein idealtypisches Vorgehensmodell entwickeln, das schneller Ergebnisse bringt und dabei durch eine intensivere Einbindung der Betroffenen zu höherer Zufriedenheit bei den Projektbeteiligten führt als jedes andere.

Fazit

Agile Methoden sind ein "Must have" im Werkzeugkasten jedes Projektleiters und Projektverantwortlichen. Sie sind nützliche Hilfsmittel, wenn es darum geht, den Herausforderungen einer Projektumwelt zu begegnen, die einem ständigen Wandel unterliegt.

Viele Beispiele zeigen allerdings, dass die konkrete Umsetzung im Projektalltag nicht ganz einfach ist. Vorsichtige Dosierung zum Einstieg und eine gute Einbettung in die Projekt-Management-Kultur des jeweiligen Unternehmens sind entscheidende Erfolgsfaktoren.

Im erwähnten Beispielprogramm wurde inzwischen übrigens auch das bislang eher unrühmlich verlaufene zehnte Projekt auf klassische Projekt-Management-Methodik umgestellt. Auf Teilprojektebene wird weiterhin mit agilen Elementen gearbeitet. Seitdem ist das Projekt klar auf Erfolgskurs.

Die zentrale Frage für Projektverantwortliche im Zusammenhang mit agilen Methoden scheint daher nicht zu sein, ob man sie anwenden soll oder nicht, sondern eher, ob und wie genau ein agiles Projektumfeld sinnvoll gestaltet werden kann. Evolution statt Revolution ist - kurz gefasst - das bislang erfolgversprechendste Konzept. (Computerwoche)

Eric Marischka ist Partner bei Assure Consulting. Er leitet und begleitet seit über zehn Jahren sowohl klassisch als auch agil geführte Projekte.