Neuer Ärger beim Projektmanagement

Die Kriegserklärung kommt in schlichten Worten daher: "Reagieren auf Veränderung [zählt] mehr als das Befolgen eines Plans", steht im agilen Manifest, dem vor gut zehn Jahren veröffentlichten Grundsatzpapier der agilen Software-Entwicklung. Dass dieses Prinzip von Vertretern klassischen Projektmanagements noch immer als Angriff aufgefasst wird, beobachtet Hans-Bernd Kittlaus, freier IT-Projektleiter und mit seinem Unternehmen Innotivum Consulting Berater für Aufgaben von CIOs und CTOs. "Denn ein Plan, der bei agilen Methoden zweitrangig ist, ist für Projektmanager ja gerade das Wichtigste", sagt Kittlaus.

Ob Prince2 oder das Wasserfall-Modell in der Software-Entwicklung: Bei Methoden wie diesen wird der Ablauf von Projekten möglichst genau geplant. Gleichzeitig verbreiten sich gerade in IT-Projekten in den letzten Jahren immer stärker agile Methoden wie Scrum oder Extreme Programming. Wo beide Welten aufeinander treffen, läuft das meist "nicht ganz so einfach und friktionslos" ab, wie es Kittlaus formuliert.

Auftraggeber wollen jederzeit Anforderungen ändern

Das liegt nicht daran, dass Projektverantwortliche auf der Business-Seite die agilen Ansätze ihrer IT-Kollegen grundsätzlich ablehnen. Hartmut Herde vom Hamburger Software- und Beratungshaus PPI AG, der mit Kittlaus zusammen schon mehrere Projekte betreut hat, beobachtet vielmehr, dass sie sich mit dem Verständnis agiler Methoden schwertun. Nicht selten verträten Auftraggeber die Sichtweise: "Ihr Entwickler seid mit agilen Methoden schneller und besser - und wir können jederzeit die Anforderungen ändern."

Das ist allerdings ein einseitiger Blick. Denn die Flexibilität, die sich Auftraggeber herausnehmen wollen, gilt genauso für den Dienstleister, wie Herde betont. Die Entwickler einer Software könnten im laufenden Projekt ebenfalls entscheiden, ihr Vorgehen zu ändern. "Aber dann finden die Kunden das oft gar nicht mehr attraktiv", berichtet Herde. Flexibilität auf beiden Seiten sei allerdings Voraussetzung für das Funktionieren agiler Methoden.

Dass Missverständnisse um diesen Grundsatz teuer sein können, erlebte Herde unlängst. Ein Auftraggeber wollte in einem nach Wasserfall-Methode geplanten Projekt ein Teilprojekt nach agilen Prinzipien ablaufen lassen. Der Grund: Er hielt es sich auf diese Weise offen, Anforderungen für das Teilprojekt kurzfristig zu ändern. Der Kulturbruch innerhalb des Gesamtprojekts zog erheblichen Abstimmungsaufwand nach sich. "Am Ende entstand dadurch ein Mehraufwand in sechsstelliger Höhe", berichtet Herde.

Rechtsabteilungen gegen agile Methoden

Kittlaus und Herde machen für derartige Probleme häufig ähnliche Ursachen aus: Zum einen sei die für Agilität nötige Offenheit nicht für alle Unternehmen und Konstellationen geeignet. "Ein junger, aufstrebender Manager zum Beispiel kann ja schlecht nach oben verkaufen, er arbeite mit agilen Methoden, weil er die Anforderungen in einem Projekt nicht genau kenne", sagt Herde.

Auch Unternehmen mit starken Einkaufs- oder Rechtsabteilungen täten sich traditionell schwer mit dem Ansatz. Eine Einkaufsabteilung fordere Standardisierung - unter anderem, um Preise zu vergleichen, sagt Herde. Und Rechtsabteilungen wollten beim Gestalten von Verträgen vorab genau wissen, welche Leistungen sie bekämen, ergänzt Kittlaus.

Kommt es zu Reibungen zwischen Vertretern agiler Methoden und denen klassischen Projektmanagements, dann treten sie meist schon früh zutage, sagen die beiden Experten. "Das klassische Projektmanagement will ja möglichst früh viel spezifizieren", sagt Kittlaus. Sorge, dass anfangs alle Ampeln auf Grün stehen und Probleme erst viel später offenbar werden, brauchen Projektverantwortliche also nicht zu haben.

Missverständnisse zwischen beiden Seiten können aber auch in späteren Projektphasen auftreten. Sie zeigen sich dann typischerweise, wenn der Auftragnehmer Inhalte auf spätere Sprints oder Iterationen verschiebt. Im agilen Entwicklungsprojekten ist so etwas normal, doch "mancher Auftraggeber ruft dann gleich die große Krise aus", sagt Kittlaus.

Damit es so weit erst gar nicht kommt, raten Herde und Kittlaus aus Erfahrung dazu, agile Ansätze gleich bei der Vorbereitung eines Projekts bis zum Ende durchzudenken. "Wenn ich auf Entwicklerseite agil sein will, muss ich beim Projektmanagement darauf auch eingehen", sagt Kittlaus.

Agile Methoden erfolgreich in Krisenprojekten

Und Herde mahnt dazu, mit einem Missverständnis auszuräumen: "Agil heißt nicht, einfach loszulegen, sondern bedeutet eigentlich Mikro-Projektmanagement." Agile Methoden fußten auf ständiger Rückkopplung und Ergebniskontrolle und erforderten daher ein hohes Maß an Management.

Ob sich die Partner in einem Projekt auf ein gemeinsames Verständnis vom Projektablauf und der Funktionsweise agiler Methoden einigen könnten, müssten sie ganz zu Anfang prüfen. "Womöglich zeigt sich ja beim Vergleich der Kulturen beider, dass man besser klassisch oder konservativ arbeiten sollte", sagt Herde.

Gut geeignet seien agile Methoden bei Krisenprojekten oder Startup-Situationen. "Gerade wenn die Zeit knapp ist und wenig Budget bereit steht, ist die Offenheit für innovative Ansätze größer", sagt Herde. Diese Erfahrung machte er etwa bei einem Unternehmen aus der als konservativ bekannten Finanzbranche.

Ein Finanzdienstleister plante eine neue Produktfamilie. Schnell musste ein Businessplan erarbeitet werden, gleichzeitig waren strenge gesetzliche Vorgaben zu beachten, und viele Spezifikationen der neuen Produkte waren noch nicht fertig. Das Unternehmen entschied sich für Projektmanagement nach einer agilen Methode. Mit dem Dienstleister vereinbarte man einen gemeinsamen Zielrahmen, legte die wichtigsten Schritte fest und bepreiste diese.

Gleichzeitig einigten sich beide Parteien auf ein Anreizsystem: Von jedem Euro, den der Dienstleister gegenüber dem vereinbarten Preis einsparen würde, bekomme er anteilig einen definierten Zusatzbonus zu dem tatsächlich fälligen Rechnungsbetrag. Trotz anfänglicher interner Widerstände führte der Finanzdienstleister das Projekt so durch - mit Erfolg, wie Herde sagt.

Mancher CIO denkt zu kurz

Ideal sei, wenn eine Organisation die Vorgehensweise je nach Aufgabenstellung und Rahmenbedingungen wählen könne. Doch dazu seien nur wenige in der Lage. Damit so etwas gelinge, brauchen die Projektbeteiligten eine hohe Reife, meint Hans-Bernd Kittlaus. "Viele sind froh, überhaupt CMMI Level 2 erreicht zu haben." Reifegrad 4, der als Grundlage wünschenswert sei, erreichten nicht viele Unternehmen.

Eine weitere Voraussetzung fürs Gelingen eines agilen Projekts - vor allem, wenn ein Unternehmen noch keine oder wenig Erfahrung damit hat - ist nach Ansicht von Herde Rückendeckung des Top-Managements. Und die richtige Einstellung des CIOs: Manch einer entscheide sich vor dem Hintergrund für agile Methoden, dass bei Entwicklungsprojekten nach klassischem Muster die Software immer erst nach dem festgelegten Termin fertig sei und die Anforderungen dann doch nicht erfülle. "Weil agile Methoden diese beiden Probleme adressieren, entscheiden sich CIOs dann gerne dafür und denken, jetzt muss alles klappen", sagt Herde. Das allerdings sei zu kurz gedacht. Denn auch jedes noch so gute Werkzeug müsse auch richtig eingesetzt werden.

Trotz aller Stolpersteine raten die beiden Experten dazu, agile Methoden auszuprobieren. Auf Dauer zeige sich beim erfolgreichen Einsatz zu den schnelleren Entwicklungszyklen meist noch ein positiver Nebeneffekt: Die eigenverantwortliche Arbeitsweise stärke die Motivation der Beteiligten, den Zusammenhalt im Team und die Identifikation mit dem Gesamtprojekt.