Man hat leicht den Eindruck, dass Wasserfall-oder agile Projekte etwas völlig unterschiedliches darstellen und nicht aus demselben Portfolio geführt werden können.
Dies ist nicht unbedingt der Fall. Der Hauptunterschied aus Portfolioperspektive zwischen den beiden besteht darin, dass in einer Wasserfallumgebung der Projekt Umfang mehr oder weniger festgelegt ist, während die Zeitpläne und Kosten bis zu einem gewissen Grad flexibel sind. Auf der anderen Seite haben agile Projekte Kosten- und Zeitvorgaben, die gegeben sind, aber der Umfang ist nicht zu 100% festgelegt. Die Qualitätsaspekte für beide Ansätze ist jedoch nie eine Frage und muss vor allem in regulierten Umgebungen vollumfänglich berücksichtigt werden.
Andere Attribute sind ebenfalls gemeinsam, z.B. haben beide einen Anfang und ein Ende, genannt Projektinitiierung und Projektabschluss, bei denen die Aktivitäten für beide gleich sind.
Wenn wir nur die Projektphasen und nicht das Projektteam betrachten, dann kann ein Wasserfallprojekt als agil betrachtet werden, aber mit nur einer Iteration oder einem Sprint. Der folgende Prozess gibt einen Überblick. Die agilen Aktivitäten sind rot markiert, die anderen Aktivitäten gelten für beide Projekttypen.

agile and waterfall projects unification de

Der obige Prozess zeigt auch, dass wir mehr Aktivitäten und Aufgaben im agilen Prozess haben, was bedeutet, dass wir sorgfältig abschätzen müssen, in welche Richtung wir gehen wollen und ob ein Wasserfallprojekt nicht die bessere (und schlankere) Option wäre.
In einem Wasserfallprojekt wird ein großes Release geplant und entwickelt. Alles endet in einem letzten Schritt, in dem die Ergebnisse in dem Unternehmen umgesetzt werden und der Projektsponsor den Abnahmebericht unterzeichnet.
Wenn der Projektumfang zu Beginn nicht definiert werden konnte oder es sinnvoll ist, die Leistungen in kürzerer Zeit zu veröffentlichen, dann ist ein agiles Projekt ein sehr guter Ansatz.
Ein guter Ansatz, um zu beurteilen, ob man agil werden soll oder nicht, ist die sogenannte Stacey-Matrix, die auf zwei Parametern basiert: dem Projekt-Umfang und der Technologie.stacey matrix de

Wenn die zu verwendende Technologie bekannt ist und für eine gewisse Zeit auf dem Markt ist, dann können wir das notwendige Wissen für unser Projekt entweder innerhalb der Organisation oder auf dem Markt verfügbar machen. Auch die Qualität der zugrunde liegenden Technologie hat sich im Laufe der Jahre verbessert. Das Ergebnis ist eine stabilere Umgebung, in der wir das notwendige Know-How haben, um sie gut zu beherrschen. Dies erhöht die Vorhersagbarkeit des Projekts. Auf der anderen Seite, wenn die Technologie brandneu ist, fehlen uns diese Aspekte des Anwendungswissens und auch die Qualität ist eher schlechter als bei einem gut etablierten Produkt.
Der zweite Parameter ist der Projektumfang. Hier ist es offensichtlich, dass, wenn es gut definiert und mit den Interessengruppen abgestimmt ist, die Anzahl der Änderungswünsche geringer sein wird, was die Vorhersagbarkeit des Projekts erhöht. Tatsächlich sind Umfangsänderungen die größte Bedrohung eines Projekts, und je mehr Sie diese Änderungen reduzieren können, desto reibungsloser wird das Projekt ausgeführt. Wenn diese Abstimmung fehlt, dann ist es am besten, agil zu werden (wenn Sie nicht die Möglichkeit haben, das Projekt nicht zu starten). Meiner Meinung nach ist der Projektumfang sogar höher zu bewerten als die Technologie. Das fehlende Wissen kann überwunden werden, indem man lernt, wie man die Werkzeuge oder Technologien richtig anwendet. Die fehlende Ausrichtung des Projektumfangs kann nur durch Verhandlungen mit den Stakeholdern wiederhergestellt werden und ist nach meiner Erfahrung viel schwieriger als die Einarbeitung in neue Technologien.
Aus diesem Grund ist die Phase der Projektinitiierung im Projektlebenszyklus so wichtig. Das Verständnis des Ist-Zustandes, die Identifizierung der relevanten Kunden (wenn nicht korrekt durchgeführt, haben Sie Schwierigkeiten bei der Abstimmung des Umfangs), die Definition der Nutzeffekte und der entsprechenden KPIs ist entscheidend für die Erstellung der Projektcharta und die Entscheidung, agil zu werden oder nicht.
Aus Portfolio-Sicht sind Wasserfall und agile Projekte kein Widerspruch. Sie sind nur ein anderer Ansatz, um mit Risiken und Unsicherheiten umzugehen.

Don't have an account yet? Register Now!

Sign in to your account