Agil vs Wasserfall

Projekte der zwei Geschwindigkeiten managen

28.07.2016 von Christoph Lixenfeld
Gartner rät, lieber Ziele statt Pflichtenhefte zu formulieren. Danach sollen CIOs den Mut haben, Projekte jenseits des klassischen Wasserfallmodels zu starten.
  • Eine Bimodal-IT nach Gartner steuert Projekte agil und klassisch
  • Die Wasserfall-Methode lässt sich nicht "agilisieren"
  • Wer Budget und Inhalt eines Projekts gleichzeitig verantwortet, trifft oft falsche Entscheidungen
  • Gartner rät CIOs zu mehr Mut bei der Wahl der Methodik

Der Trick funktioniert immer: Wer in der IT Lösungen verkaufen oder auch nur überzeugend propagieren will, muss der Zielgruppe zunächst ein Problem bescheinigen. In diesem Sinne schrieb Gartner in seinem Paper "Effective Governance of Bimodal IT Projects": "Projektmanagern und andere IT-Verantwortlichen fällt es schwer, Prozesse aufzusetzen, mit denen sich agile Methoden und traditionellesProjektmanagement unter einen Hut bringen lassen."

Kein Projektmanagement kommt ohne Planung aus. Zu viel davon kann allerdings das Doing behindern.
Foto: Rawpixel - Fotolia.com

Die Analysten aus Stamford beziehen sich auf die "Bimodal IT", ein Begriff, den Gartner aus der Mathematik entlehnt und für die eigenen Zwecke umgedeutet hat. Gemeint ist eine IT-Organisation, in der Projekte sowohl nach dem klassischen Wasserfallmodell gemanaged als auch - teilweile gleichzeitig - agil gesteuert und abgewickelt werden.

Die Kernfrage der Gartners lautet: Wie kriegt man beides zusammen? Wie nutzt man die Vorteile beider Ansätze, obwohl die Abläufe höchst unterschiedlich sind?

Mode 2 verzichtet auf Routinen

Die klassische Vorgehensweise, von Gartner als "Mode 1" bezeichnet, ist hierarchisch und sequenziell, will sagen das Projekt entsteht wie ein Haus: Erst wenn der Keller fertig ist, fängt man mit dem Bau des Erdgeschosses an. "Mode 2" dagegen verläuft mehr experimentell, mit möglichst wenig festgelegten Routinen, Projektteile entstehen parallel zueinander, werden durch Feedbackschleifen laufend nachjustiert.

Dabei will und kann sich das Gros der Unternehmen nicht über Nacht von der klassischen Methode trennen, sucht aber nach Möglichkeiten, die Entwicklungszeiten für neue Produkte und Services zu verkürzen und ihre Qualität verbessern.

Zeitgemäßes Projektmanagement sollte die Verantwortlichkeiten für Inhalte und für Budgets voneinander trennen.
Foto: violetkaipa - Fotolia.com

Was allerdings nicht funktioniert, ist laut Gartner, Methode 1 durch Optimierung von Abläufen und Strukturen zu 'agilisieren'. Stattdessen gelte es, zu entscheiden, wann welcher Ansatz der Richtige ist.

Der Vertrieb definiert die Anforderungen

Bei der klassischen Methode würden die Verantwortlichen zunächst eine "Business Capability Road Map", also eine Roadmap der Business-Anforderungen, entwerfen. Am Beispiel der Entwicklung einer CRM-Software verdeutlicht: Basis der Roadmap sind die Wünsche der Vertriebsorganisation, also die Frage: "Was will der Kunde?"

Anschließend werden diese Ansprüche Schritt für Schritt abgearbeitet. Nachteil: Das sequenztielle Vorgehen lässt vergleichsweise wenig Feedback zu. Und: Gerade Softwareentwicklung dauert oft so lange, dass sich die zu Beginn definierten Anforderungen des Marktes schon wieder drastisch geändert haben, wenn das Produkt fertig ist. Außerdem lässt sich anhand einer Liste von Kundenwünschen nicht agil entwickeln.

Agiles Projektmanagement
Prüfen von Anforderungen in agilen Projekten
Ohne die Priorisierung der Anforderungen des IT-Projekts drohen hohe Folgekosten in einzelnen Sprintphasen.
Verzögerungen durch exportierte Probleme
Neben dem Totalausfall eines Sprints gehören Verzögerungen zur Tagesordnung. Diese entstehen etwa bei unklar definierten Anforderungen, die eventuell im falschen Detaillierungsgrad vorliegen oder durch Überlastung des Product Owners verspätet priorisiert werden.
Zeitverluste durch fehlende Aufgabenzuordnung
Zunächst lassen sich nicht ausreichend gut definierte Anforderungen durch ohnehin erforderliche Routinearbeiten wie der Spezifikation technischer Anforderungen kompensieren. Später droht dagegen der Totalverlust ganzer Sprints.
Anforderungen treffen ungesteuert auf das Projektteam
Bei agilem Projektmanagement stehen viele Unternehmen noch immer auf der Bremse. Der Grund: Viele Projektverantwortliche müssen zusätzlich zu den Projektanforderungen weiterhin Aufgaben im Tagesgeschäft übernehmen.
Anforderungen laufen beim Product-Owner-Team zusammen
In einem Projektteam aus typischerweise sechs bis acht Mitarbeitern laufen alle Fäden beim Product Owner zusammen. Das Product-Owner-Team besteht aus maximal drei Personen. Der Product Owner managed alle an das Team herangetragenen Anforderungen. Das gilt sowohl vonseiten der Auftraggeber als auch der beteiligten Fach- und IT-Abteilungen sowie der Revision. Viele Unternehmen machen dabei den Fehler, Product Owner nicht ausreichend vom Tagesgeschäft freizuhalten.

Das funktioniert besser durch das Formulieren von Zielen. Ein solches Ziel könnte für die neue CRM-Lösung lauten: 'Steigere die Verkäufe um X Prozent durch eine bessere Segmentierung des Marketings'.

Diese Fragestellung legt die Entwicklungsmethode nicht fest. Deren Auswahl, so Gartner, hat oft vor allem etwas mit der Unternehmenskultur zu tun. Und mit der Frage, wie viel Unsicherheit diese Kultur verträgt.

Schauen wir mal, wie weit wir damit kommen

Ist die Toleranz dafür groß, sollten sich Unternehmen bei wichtigen Innovationen für "Mode 2", also für ein agiles Vorgehen entscheiden, obwohl sich dabei im Vorfeld die Details nicht haarklein planen lassen. Beschränkungen entstehen hier weniger durch das Konzept und mehr durch die Höhe der Investitionen in das Projekt. Das Ansatz kann lauten: Wir geben uns drei Monate und 300.000 Euro und schauen mal, wie weit wir damit kommen.

Kein Unternehmen kann sich einfach so vom klassischen Plan-Build-Run lösen. Allerdings rät Gartner zu mehr Mut bei der Wahl der Methodik.
Foto: Brian A. Jackson - shutterstock.com

Gartner vergleicht die Methode mit dem Lebenszyklus von Venture Capital-Finanzierten Start-ups. Geht es schief, wird die Idee schnell beerdigt und als wertvolle Erfahrung verbucht. Google zum Beispiel geht seit jeher bei seinen Entwicklungen so vor.

Natürlich eignet sich dieses Vorgehen nicht für jede Art von Projekt, und Unternehmen sollten auch kurzfristig entscheiden können, welche Methode sie wählen.

Mehr Mut zu agilen Teams

Erleichtert wird diese Flexibilität dadurch, dass Budget- und inhaltliche Verantwortlichkeit voneinander getrennt werden. Wer in Personalunion über Methodik und Budget befinden muss, trifft oft die falschen Entscheidungen.

Zusammenfassend wollen die Gartner-Autoren IT-Verantwortliche motivieren, den klassischen Ablauf von IT-Projektennicht zu vergessen, zugleich aber den Mut aufzubringen,agile IT-Teams aufzustellen und ihnen wichtige Aufgaben zu übertragen.

Um zu entscheiden, welche Aufgaben mit Hilfe welcher Methode durchgeführt werden, empfiehlt Gartner, zunächst (vergleichsweise) abstrakte Ziele statt komplexer Pflichtenhefte zu formulieren. In diesem Sinne sollten CIOs auch den Mut haben, Entwicklungen jenseits eines klar definierten Plan-Build-Run anzustoßen.

Erfolgsfaktoren im Projektmanagement
Erfolgsfaktoren im Projektmanagement
Gibt es Muster und Faktoren, die verschiedenste erfolgreiche Projekte gemein haben – diese Frage zieht sich durch die Studie "Erfolgsfaktoren im Projektmanagement". Die Studie ist eine Gemeinschaftsarbeit des BPM-Labors (Business Process Management) an der Hochschule Koblenz mit der Deutschen Gesellschaft für Projektmanagement (GPM) und Heupel Consultants.
Unterscheidungskriterien
Die Studienautoren wollten wissen, nach welchen Kriterien die rund 200 befragten Manager den Erfolg eines Vorhabens beurteilen. Das hängt vor allem davon ab, ob die gewünschte Qualität erreicht wurde.
Erfolgsfaktoren
Faktor Nummer Eins ist das Teamwork. Das bestätigen 83 Prozent. Gute Teamarbeit heißt: Rollen und Kompetenzen sind klar definiert. Das Projekt basiert auf einem fachlichen Konzept, das jeder Beteiligte verstanden hat. Kundenanforderungen werden "kritisch und konstruktiv" behandelt.
Misserfolgsfaktoren
Scheitert ein Projekt, liegt das vor allem an schlechter Steuerung und Entscheidungsschwäche. Am wenigsten liegt es an der Projektinfrastruktur.
Die Top Ten der Erfolgskriterien
Die Teilnehmer haben einzelne Aussagen zum Projekterfolg in ein Ranking gebracht. Hier sind die Top Ten von insgesamt 30 Aussagen. Weitere Statements folgen auf den kommenden zwei Seiten.
Plätze 11 bis 20
Teil Zwei des Rankings der wichtigsten Erfolgskriterien
Plätze 21 bis 30
Plätze 21 bis 30 der wichtigsten Aussagen über den Erfolg eines Projektes