Klassisch oder agil – zwei Methodiken im Projektmanagement, wie sie unterschiedlicher nicht sein könnten: Sicher, jeder Projektleiter möchte sein Projekt zum Erfolg führen, doch die Grundideen und das Vorgehen der beiden Ansätze scheinen komplett gegensätzlich. Das äußert sich nicht zuletzt in hitzigen Debatten darüber, welche Methodik denn nun die „bessere“ sei. Doch gibt es dieses pauschale „besser“? Wohl kaum! Werkzeuge funktionieren bekanntermaßen nur dann, wenn sie passend für den Einsatzzweck ausgewählt werden. Im Artikel „Agil, klassisch & Co: Wann eignet sich welche Projektmanagement-Methodik?“ erfährst du mehr über die richtige Auswahl der Methodik.
Dieser Artikel ist Teil 1 der Serie über die Unterschiede im klassischen und agilen Projektmanagement. Du willst mehr erfahren? Dann schau gern in die anderen Teile rein:
Teil 1: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 1)
Teil 2: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 2)
Teil 3: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 3)
Teil 4: Unterschiede zwischen klassischem und agilem Projektmanagement (Teil 4)
Wie also entscheidest du dich für den einen oder anderen Ansatz? Zunächst musst du wissen, worauf du dich mit der jeweiligen Methodik einlässt. Das heißt konkret: Was bedeutet der Einsatz für dein Projekt und wie unterscheiden sich die beiden Vorgehen. Um es dir leichter zu machen, ist der folgende Artikel der erste einer Serie von insgesamt 4 Artikeln, in denen wir den Unterschieden zwischen klassisch und agil auf den Grund gehen.
Zum Auftakt der Serie beginnen wir mit drei sehr grundlegenden Unterschieden:
- Spätes Feedback vs. frühes Feedback
- Definierte Prozesse vs. Innovation
- Sequenzielle Entwicklung vs. iterative Entwicklung
Spätes Feedback vs. frühes Feedback
Aus Sicht des Auftraggebers werden die Unterschiede zwischen klassischem und agilem Vorgehen besonders deutlich, wenn Zeitpunkt und Häufigkeit des Feedbacks betrachtet werden: Wann kann oder muss (oder darf) der Auftraggeber (Kunde, Endnutzer, …) jeweils sein Feedback zum Projektergebnis/Produkt abgeben?
Klassisches Projektmanagement:
Häufig wird dem Kunden erst am Ende des Projektes das Ergebnis vorgestellt. Das kann z. B. ein im Projekt entwickeltes Produkt sein. Damit das nicht gnadenlos schiefgeht und dieses Produkt auch tatsächlich den Vorstellungen des Kunden entspricht, muss bei solch einem Vorgehen zu Beginn des Projektes große Sorgfalt auf die Definition der Anforderungen gelegt werden. Meist wird ein Lasten-/Pflichtenheft erstellt, das am Ende des Projektes die Grundlage für die Abnahme durch den Kunden bildet. Das Feedback erfolgt also erst ganz zum Schluss.
Beispiele:
- Spezialanfertigung einer Pumpe für ein Klärwerk mit klaren technischen Anforderungen und Spezifikationen
- Durchführung eines Marketingevents zur Einführung eines neuen Smartphones
- Schulung der Mitarbeiter einer Behörde zum Thema „Neue Datenschutzregeln“
Achtung: Im klassischen Projektmanagement gibt es selbstverständlich auch die Möglichkeit, dem Auftraggeber schon während der Projektdurchführung Möglichkeiten zum Feedback zu geben. Beispiele gefällig?
- Im oben gezeigten Entwicklungsprojekt könnte nach dem Ende der Designphase mit dem Auftraggeber Rücksprache gehalten werden.
- Im Beispiel der Mitarbeiterschulung könnte das erarbeitete Schulungskonzept der Behördenleitung zur Freigabe vorgelegt werden.
Solche Feedbackpunkte dienen im klassischen Projektmanagement vor allem der Kontrolle, ob das Projekt noch auf Kurs ist, um Schlimmeres zu verhindern. Sollte an einem solchen Punkt eine Kurskorrektur notwendig sein, bringt dies meist einen erheblichen Umplanungsaufwand mit sich – oft verteuert und verzögert sich das Projekt.
Agiles Projektmanagement:
Der Kunde erhält in regelmäßigen Zyklen Teilfunktionen oder Produktinkremente zur Begutachtung zur Verfügung gestellt – Feedback und Kritik sind ausdrücklich erwünscht. Dies funktioniert nur dann, wenn ein Projektergebnis gut in Inkremente heruntergebrochen werden kann, die nacheinander erzeugt und anschließend begutachtet/beurteilt werden können. Das Paradebeispiel ist die Entwicklung von Software – der Bereich, in dem die agile Idee ihren Ursprung hat.
Die Abbildung zeigt das Vorgehen am Beispiel des Scrum-Frameworks im agilen Projektmanagement:
In unsicheren Umgebungen mit wechselnden Anforderungen liegt der Vorteil auf der Hand: Statt über lange Zeiträume ein vollständiges Produkt zu entwickeln, erhalten alle Beteiligten regelmäßigen Einblick in den Projektfortschritt. Anforderungen können angepasst und nächste Schritte definiert werden. Umfangreiche nachträgliche Anpassungen entfallen auf diese Weise automatisch. Anders als im klassischen Projektmanagement besteht so nicht die Gefahr, dass Anforderungsänderungen unentdeckt bleiben, oder ein Produkt im schlimmsten Fall am Markt vorbeieinwickelt wird.
Beispiele:
- Entwicklung einer Webseite mit Online-Shop und zahlreichen weiteren Detailfunktionalitäten
- Entwicklung einer Steuersoftware für ein neues Motorendesign
- Planung eines Einfamilienhauses durch ein Architekturbüro
Definierte Prozesse vs. Innovation
Der Bau des dreizehnten Fertigteilhauses „von der Stange“ unterscheidet sich trotz aller Konfigurationsmöglichkeiten enorm von der Entwicklung einer innovativen App – und deshalb wird sich auch das Vorgehen deutlich unterscheiden:
Klassisches Projektmanagement:
Klassisch geplante und durchgeführte Projekte eignen sich besonders für Vorhaben, die definierten Prozessen folgen, in denen gut verstandene Detaillösungen/Komponenten zum Einsatz kommen und aus denen ein vorhersehbares Ergebnis hervorgehen soll. Bewährte und definierte Schritte führen zu einem zuvor festgelegten Ergebnis.
Beispiele:
- Bau eines Einfamilienhaues „von der Stange“
- Upgrade der Server-Landschaft in einem Unternehmen
Agiles Projektmanagement:
Agiles Projektmanagement wird häufig in dynamischen Umgebungen eingesetzt: in Produktentwicklung, Forschung und Software-Entwicklungen. Oft kann nicht klar vorausgesagt werden, wie das Ergebnis im Detail aussehen soll und welche Ansätze die beste Lösung bringen werden – zu Beginn weiß es schlichtweg noch niemand. Ein vorgegebener Plan oder Prozess ist wenig sinnvoll, schließlich soll etwas Neues entstehen. Sollen bahnbrechende Innovationen geschaffen werden, gibt es kein Standardrezept, das direkt angewendet werden kann.
Beispiele:
- Optimierung eines Laptop-Displays mit neuer Technologie, die noch nicht vollständig verstanden ist
- Entwicklung einer innovativen App zur Gewichtsreduktion
Sequenzielle Entwicklung vs. iterative Entwicklung
In vorgegebenen, aufeinander folgenden Schritten zum Ziel – oder aber in kurzen Zyklen? Hier unterscheiden sich die Projektmanagement-Methodiken erheblich. Dieser Punkt ist eng mit der Feedbackhäufigkeit (siehe oben) verknüpft:
Klassisches Projektmanagement:
In traditionell durchgeführten Projekten werden zu Beginn definierte Phasen nacheinander abgearbeitet. Wenn eine Phase bzw. ein Aufgabenblock erledigt ist, beginnt der nächste. Zwar können Phasen prinzipiell auch überlappen, aber sie werden zumindest innerhalb eines Teilprojektes nie annähernd parallel abgearbeitet, sondern im Wesentlichen nacheinander.
Dieser Ansatz folgt der Annahme, dass zu Beginn des Projektes alle Informationen vorliegen. Diese werden in Anforderungen und Designs gepackt, anschließend wird mit der Umsetzung begonnen.
Beispiel: Erst wenn das Design der Website vollständig abgeschlossen ist, wird mit der Programmierung begonnen.
Agiles Projektmanagement:
Im agilen Projektmanagement wird zu Beginn nicht alles im Detail festgelegt. Der Grundgedanke: Menschen können im Voraus nicht alle Details überschauen und selbst Auftraggeber wissen zu Beginn noch nicht im Detail, was sie genau wollen und welche Möglichkeiten bestehen. Aus diesem Grund werden kleine Einheiten umgesetzt, diese überprüft und wenn nötig verbessert.
Iterativ:
Das iterative Vorgehen folgt der Prämisse, dass oft im ersten Schritt vieles falsch oder nicht ideal gelöst wird, bevor Fehler im nächsten Schritt korrigiert werden. Überspitzt ausgedrückt: Der erste Wurf ist für die Tonne, aber wir können daraus lernen und darauf aufbauen. Oder aber: Der erste Wurf ist ein Vorschlag an den Auftraggeber. Mehrere Anläufe werden also nicht als Fehler betrachtet, sondern als Teil des Vorgehens von vornherein eingeplant.
Beispiel: Statt direkt einen detaillierten Entwurf einer neuen Website in allen Feinheiten vorzulegen, werden grobe Skizzen erstellt, Vorversionen erzeugt und diese nach und nach in Rücksprache mit dem Kunden verfeinert.
Inkrementell:
Beim inkrementellen Ansatz werden große Brocken in Teilaufgaben zerlegt und diese nacheinander erledigt. Der Hintergrund: Wird ein kleiner Teil gebaut, können daraus Erkenntnisse gewonnen und auf weitere Funktionen angewendet werden.
Beispiel: Statt alle Unterseiten einer neuen Firmenpräsenz zu gestalten, wird zunächst nur die Startseite erstellt.
Fazit
Für jeden Einsatz das richtige Werkzeug auszuwählen, darin besteht oft die Kunst! In diesem Artikel hast du die ersten drei Unterschiede zwischen klassischem und agilem Projektmanagement kennengelernt. Neugierig auf mehr? In Teil 2 geht’s weiter!
