Die Grenzen des traditionellen Projektmanagements

Viele Organisationen sind enttäuscht vom Projektmanagement ihrer Entwicklungsprojekte. Es ist ihnen zu starr, zu langsam und zu bürokratisch. Sie wollen ihre Zeit in die Entwicklung marktfähiger Produkte investieren – und nicht in die Ausarbeitung von Projektplänen, die nach einer Woche schon wieder Makulatur sind.

So schaut man interessiert auf die Softwarebranche. Hier haben sich “agile Methoden” für die Produktentwicklung fest etabliert: Projekt-Tools wie Scrum und Kanban. Die Erfolgsquote agiler Softwareprojekte beträgt 300% der Erfolgsquote traditioneller Projekte. Die Entwicklungen werden schneller und mit besseren Ergebnissen abgeschlossen.

Aber funktionieren diese Methoden auch für nicht-IT-Projekte? Bei der Entwicklung von Fahrzeugtechnik, Flugzeugcockpits, Reha-Programmen oder Kartoffelchips? In Branchen wie Automotive, Maschinenbau oder Chemie?

Bemerkung: Sie können die Erklärung der Unterschiede zwischen Agile und Traditionell überspringen. Und hier direkt zur Erklärung von agilem Projektmanagement gehen.

Verschiedene Typen von Projekten

Bei vielen Projekten wird das Projektergebnis zum Projektbeginn festgeschrieben. Dies geschieht in der frühen Projektphase, der Projektdefinition. Der Bau eines Hauses ist ein Beispiel. Zuerst entwickeln Architekt und Fachingenieure den detaillierten Bauplan. Anschließend wird die Ausführung geplant, also welches Gewerk in welchem Zeitraum erstellt werden soll.

Dabei gibt es natürlich eine Reihenfolge, die unbedingt einzuhalten ist: Das Fundament muss fertig sein, bevor der Rohbau beginnen kann – und der fertige Rohbau ist Voraussetzung für den Beginn des Innenausbaus.

Halten wir wichtige Merkmale eines solchen Projektes fest:

  • Das Projektergebnis und seine gesamten Eigenschaften können vor Umsetzungsbeginn genau beschrieben und festgelegt werden.
  • Die Umsetzung der Projektschritte (Gewerke) muss einer festen Reihenfolge folgen.
  • Die Dauer der einzelnen Abschnitte und Aufgaben kann mit Erfahrungswerten geschätzt und geplant werden.
  • Die Projektressourcen (Handwerker) müssen – für ihre Kapazitäts- und Auftragsplanung – Monate vorher wissen, wann ihr Gewerk an der Reihe ist.

Planung im traditionellen Projektmanagement

Umfangreiche Projekte werden mit Hilfe spezieller Software gesteuert – oder versucht zu steuern. Nachdem alle Planungsdaten eingegeben sind, erzeugt die Software einen Ablaufplan. Diese Diagramme – wie Gantt- oder PERT-Charts – visualisieren den geplanten Ablauf des Projektes.

Die Diagramme zeigen den Projektressourcen, von wann bis wann sie welche Projektaufgaben erledigen sollen. Projektmanagern helfen sie, die fristgerechte Erledigung zu überprüfen. Bei Abweichungen – die so gut wie immer negativ sind – sucht der Projektmanager nach Wegen, die Auswirkungen auf die folgenden Aktivitäten und den Gesamtplan zu minimieren. Ansonsten gibt er die Abweichung in die Planungssoftware ein – und diese berechnet dann den “neuen” Plan.

Leider ruft der neue Plan meist Konflikte mit anderen Projektressourcen hervor: Verspätet sich der Elektriker mit der Verlegung der Elektroleitungen, können die Putzer und Maler erst später anfangen. Zu ihrem neu berechneten Termin haben sie aber schon einen anderen Auftrag angenommen. Eine Planabweichung kann so einen regelrechten Dominoeffekt erzeugen.

Wie planbar sind Projekte?

Wir haben am Beispiel der Handwerker beim Hausbau gesehen, dass lineares Projektmanagement von hoher Planbarkeit abhängt. Davon, dass das Projektergebnis bei Umsetzungsbeginn feststeht und genau beschrieben ist. Und dass „das Projekt sich genau an den Plan hält“ – dass es unterwegs keine großen Überraschungen gibt.

Die lineare Planung von Projektanfang bis Projektende wird nötig, wenn die wesentlichen Projektressourcen hoch-spezialisiert sind und Terminverpflichtungen ausserhalb des Projektes haben. Solche Projektressourcen können, bei Bauprojekten, Handwerker und Subunternehmer sein. Bei Entwicklungsprojekten ausserhalb der Softwareentwicklung (non-IT) kann es sich um ein Labor, eine Testanlage, externe Entwicklungsdienstleister oder interne Fachexperten handeln.

Projekte bei denen das Ziel, das Projektergebnis zu Beginn nicht genau festgeschrieben werden kann. Und Projekte, bei denen von Start zum Ziel Überraschungen lauern.

Risikomanagement

Wir Menschen haben ein Bedürfnis nach maximaler Sicherheit und Kontrolle.

Das ist sehr hilfreich, um den Status Quo zu verteidigen – kann jedoch kontra-produktiv sein, wenn es darum geht, die Zukunft zu gestalten.



“Der Bär, den du sieht, ist nicht derjenige, der dich fressen wird,” sagt ein altes französisches Sprichwort. Darwin schrieb: “Nicht die stärksten oder intelligentesten Spezies überleben, sondern diejenigen, die sich am besten an veränderte Bedingungen anpassen können.”

Für das Management bedeutet dies: Wir brauchen zeitnahe Informationen über veränderte Bedingungen und die Flexibilität unsere Pläne anzupassen.

Das kann Sie weiter bringen ...

Seit 15 Jahren profitieren unsere Kunden von unserer Praxis-Kompetenz. Projektteams erlernen die Anwendung von Scrum, Kanban und hybridem Projektmanagement. Und zwar so, dass sie sich auf ihr erstes agiles Projekt freuen.

Bei welcher Art von Projekten sind agile Methoden den traditionellen überlegen? Welche Voraussetzungen müssen erfüllt sein? Und wie führt man Agile sinnvoll ein? Genau darum geht es im Agile-Entscheiderworkshop.

Agiles Projektmanagement ist mächtig – aber kein Selbstläufer. Oft brauchen Projektteams bei ihren ersten agilen Projekten Unterstützung. Sonst heißt es womöglich nach einigen Wochen: “Bei uns funktioniert das nicht!”

Planlos durchs Projekt: Ist Ad-hokratie die Lösung?

ad-hoc

ist lateinisch für “spontan, aus dem Augenblick heraus”.

Der abgeleitete Begriff “Adhokratie” bezeichnet einen Gegenentwurf zur Bürokratie. Also eine Organisationsform maximaler Flexibilität und Spontaneität.

In manchen Entwicklungsorganisationen läßt sich folgender Zyklus feststellen:

  1. Die Organisation ist noch sehr klein. Die Ad-hoc-Vorgehensweise ohne große Planung funktioniert und die Organisation innoviert sehr erfolgreich.
  2. Die Organisation ist stark gewachsen. Die Koordination wird schwieriger. Eine professioneller werdende Unternehmensführung versucht Unsicherheit zu reduzieren und verlangt Pläne, Prognosen und deren Einhaltung.
  3. Als Lösung werden die Entwickler in linearem Projektmanagement geschult, eine Planungssoftware wird angeschafft.
  4. Eine Verbesserung bleibt aus. Die Methoden werden als unzureichend bewertet. Planung und Kontrolle werden verfeinert und intensiviert.
  5. Die Projektmitarbeiter verbringen immer mehr Zeit mit den Projektwerkzeugen statt mit dem Projektgegenstand. Die Frustration wächst, die Projekte werden immer länger und die Erfolgsquote immer geringer.
  6. Aufgabe des planungsbasierten Projektmanagements und Rückkehr zur Adhokratie.
  7. Erneute Erkenntnis, dass sich so keine Ergebnisse erzielen lassen, die den Entwicklungsaufwand rechtfertigen.


Dies betrifft sowohl Industrie- als auch Dienstleistungsfirmen.

Agiles Projektmanagement als dritter Weg

Agiles Projektmanagement überwindet den Widerspruch, das kaum Planbare doch planen zu müssen. Agile Teams suchen während des Projektes nach Erkenntnissen, die helfen, ein besseres Ergebnis zu liefern. 

So setzt die Scrum-Methode auf Iterationen – sich wiederholende Schleifen von Lernen und Umsetzen. 

Statt hierarchisch-zentraler Steuerung und Kontrolle steuern die Teams ihre Arbeit und Zusammenarbeit selbst. Dazu nutzen sie agile Werkzeuge, die für Transparenz und hohes Engagement sorgen.

Die Veränderung ist nicht immer einfach. Aber die Ergebnisse überzeugen und sind die Hürden einmal überwunden, will kaum jemand zurück in die Zeit vor Agile.

Agile Produktentwicklung ist iterativ-inkrementell. Was bedeutet das?

Bei einer inkrementellen (oder inkrementalen) Vorgehensweise wird das Produkt zerlegt und stückweise entwickelt. Wunderbar illustriert wird das durch Jeff Pattons’ Beispiel der Mona Lisa.

Die Zerlegung von Aufgaben in Teilaufgaben ist natürlich auch im linearen Projektmanagement üblich. Bei SCRUM haben wir aber zwei Besonderheiten:

Wir arbeiten nicht mit Aufgaben- sondern mit test-fähigen Produktinkrementen.
Die Inkremente werden den Projektkunden präsentiert – und diese geben ihr Feedback dazu.

Mit inkrementeller Vorgehensweise hätte da Vinci also seinem Auftraggeber den fertig gemalten Kopf der Mona Lisa gezeigt. Dieser hätte für sich damit eine genauere Vorstellung des Gesamtgemäldes entwickeln können. 

Eventuell hätte er festgestellt, dass der Maler seine Erwartungen nicht richtig verstanden hat – oder dass seine Vorstellung sich geändert hat. So hätte da Vinci den oberen Teil entweder überarbeitet – oder er hätte noch einmal ganz von vorne angefangen, bevor er mit dem Malen des Oberkörpers begonnen hätte. In jedem Fall wäre eine weitere Verschwendung von Zeit und Material vermieden worden.

Inkrementell hätten wir also. Aber wie geht iterativ?

Bei einer iterativen Vorgehensweise erledigen wir eine Aufgabe in mehreren Schleifen. Dabei nimmt die “Auflösung” oder die Perfektion mit jeder Schleife zu. Wie oben beschrieben: ein wichtiger Aspekt ist, dass jede Iteration ein eingeschränkt nutzbares Produkt darstellt. Am Beispiel unseres Kunstwerks: Bereits die Skizze (Stufe 1) könnte ein marktfähiges Produkt sein.

Jetzt fehlt aber noch "iterativ-inkrementell"!

Keine Überraschung hier: Iterativ-inkrementell kombiniert die beiden vorherigen Ansätze. Teile des Gesamtvorhabens werden in aufeinander folgenden Qualitätsstufen entwickelt. Bis das Gesamtpaket in der gewünschten Qualität umgesetzt ist. Besonders in Scrum-Projekten ermöglicht das Vorgehen, am Ende eines Sprints ein nutzbares Ergebnis abzuliefern. Oder zumindest eins, das dem Team und den Projektkunden hilft, Lösungen und Antworten zu finden.

Das Prinzip Anforderungen in sinnvolle Teile und Qualitätsstufen zu zerlegen ist nicht schwierig zu verstehen. Es in verschiedenen Feldern elegant umzusetzen, ist eine Fähigkeit, die Product Owner und Scrum Master mit der Zeit und „on-the-job“ entwickeln.

Was ist der Vorteil eines iterativ-inkrementellen Vorgehens?

Beim rein inkrementellen Projektablauf muss das Endprodukt schon zu Beginn definiert sein. 

Beim iterativen Ablauf können wir auf Grundlage einer relativ vagen Idee beginnen zu arbeiten. Wir machen etwas und holen Feedback dazu ein. Wir überlegen dann, ob wir darauf aufbauend weiter machen – oder das Gelernte nutzen, um den vorhandenen Teil noch einmal anders neu zu machen oder ihn zu verändern. 

Ein großer Vorteil: Da wir nicht gleich den gesamten Entwicklungsaufwand betreiben, können wir alternative Varianten entwickeln und testen.

Was ist ein Sprint, eine User Story? Was macht ein Product Owner? Die 50 wichtigsten Begriffe, die Sie kennen sollten – als PDF zum Herunterladen.

Für geschichtsinteressierte Leser ...

Die agile Produktentwicklung wurde nicht am grünen Tisch entwickelt. Sie ist die Formalisierung von Praktiken, die in den achtziger Jahren bei sich selbst organisierenden Teams beobachtet wurde. 

Pascal Jarry ist einer der Pioniere, die das Potential der agilen Methoden für die industrielle Produktentwicklung entdeckte. Zuvor leitete er zwanzig Jahre lang auf drei Kontinenten die Entwicklung von Videospielen. 

Er erinnert sich: “Auf internationalen Konferenzen der Videospieleindustrie tauschten wir Entwicklungsleiter uns aus. Alle hatten dasselbe Problem: unsere Entwicklungsteams waren immer größer geworden. Wir versuchten, die Methoden zu professionalisieren und die Teams verloren dabei ihre Kreativität, ihre Motivation und ihre Effektivität.

Die gängigen Methoden verlangten nach mehr Disziplin und Kontrolle. Leider an den falschen Stellen. Wir waren dabei, das System bürokratisch gegen die Wand zu fahren. Wir tauschten unsere Erfahrungen und “best practices” aus. Dann experimentierten wir mit den Methoden und trafen uns wieder zum Abgleich. Es wurden Veröffentlichungen geschrieben, dann Bücher. Wir probierten aus, und wir passten an. Wir waren ohnehin agil – aber in diesem Prozess wurden wir “Agile”.

Die Prinzipien und Werkzeuge der Agilität etablierten sich also in der Softwareentwicklung. Ab 2004, mit meinem eigenen Unternehmen, machte ich diese Werkzeuge allen entwickelnden und innovierenden Organisationen zugänglich, mit dem Fokus auf non-IT Projekte.”

Erforderliche Anpassungen

Die stetige Verbreitung des agilen Projektmanagements außerhalb der Softwareentwicklung zeigt, daß Agilität und auch Scrum auch dort funktionieren. Als dritter Weg zwischen linearer top-down Planung und der Adhokratie löst Agilität die jeweiligen Probleme der beiden anderen Wege.

Allerdings kann die Einführung von agilem Projektmanagement auch scheitern. Dies geschieht regelmäßig, wenn agile Methoden oder Prinzipien per Gebrauchsanleitung implementiert werden. 

Zum Beispiel wurde in der Entwicklungsabteilung eines Automotive-Zulieferers SCRUM eingeführt. Die Mitarbeiter (m/w) wurden trainiert. Scrum-Master und Product-Owner wurden ausgewählt und in ihre Rollen eingewiesen. Bei der Erstellung des Product-Backlogs wurde es schon schwierig … und mit Beginn der Sprints setzte komplette Konfusion ein.

Später stellte sich heraus, dass ein Product-Backlog in Form von User-Stories und die Entwicklung in Iterationen für die Projektaufgabe absolut unpassend waren. 

Ein neuer Berater erkannte das Problem. Er half dem Entwicklungsteam, es zu verstehen und einzuordnen. Gemeinsam wurden die agilen Werkzeuge angepasst – worauf sich die erhofften Resultate endlich einstellten.

Agiles Projektmanagement liefert unter anderem in diesen Branchen

  • Automobilindustrie
  • Automobilzulieferer
  • Dienstleistungen
  • Finanzen und Versicherungen
  • Einzelhandel
  • Maschinenbau
  • Chemieindustrie
  • Lebensmittelindustrie
  • Medizintechnik
  • Kunststoffverarbeitung
  • Metallverarbeitung
  • Spielwaren
  • Pharmazie

Um Agile erfolgreich zu nutzen ...

  • empfiehlt es sich zu prüfen, ob die Arbeitsmethodik (agil oder traditionell) wirklich der Engpass zu besser Projekt-Performance ist. Manchmal sind es ganz andere Probleme, die gelöst werden müssen. Oft sind solche Probleme komplex und benötigen einen asymmetrischen Lösungsansatz.
  • sollten wir Agile gut kennen – aber nicht dogmatisch sein. Wichtige Aspekte sollten wir nutzen und den Rest an die Situation anpassen.
  • passen wir die Sprache der Agilität an die Sprache der Organisation an.
    ist es unerläßlich, die Anwender gründlich in den relevanten agilen Methoden zu schulen.
  • müssen die Anwender wissen, dass Agilität nicht nur Scrum ist. Der Organisation sollte ein echter agiler Ansatz vorgestellt werden – und nicht nur die einzelnen Werkzeuge.

Die agilen Methoden setzen sich durch

Das bestätigt eine Forrester-Studie schon 2013:

„Agilität […] setzt sich außerhalb der Software-Entwicklung durch. Manche Unternehmen setzen Agile in Bereichen ein, wie:

  • Portfolio-Management
  • Projektmanagement
  • Lieferanten-Management
  • Beschaffung […]“
 

Für agil durchgeführte Projekte sind zahlreiche Vorteile belegt. Dazu gehören Geschwindigkeit, Kosteneinsparungen, Produktivität, stärkere Anwender-/Kundenorientierung.

Phasenmodelle und Agilität

In vielen nicht-Software Organisationen werden Entwicklungsprojekte mit einem Phasenmodell, wie Stagegate®, organisiert.

Dabei wird der Prozess von der Produktidee zur Markteinführung in mehrere Phasen unterteilt. An “Gates”, also virtuellen Toren überprüft ein Entscheidungsgremium, ob das Projekt die Voraussetzungen für die nächste Phase erfüllt. Von dieser Überprüfung hängt die Allokation weiterer Ressourcen ab.

Die Gate-Entscheidungen legen fest, ob das Projekt weiter verfolgt oder vorzeitig beendet wird.

Dr. Robert G. Cooper, der Stagegate®-Entwickler, veröffentlichte 2014 im Magazin “Research-Technology Management” den Artikel “What’s next?: After Stage-Gate”.

Er erkennt darin an, dass sein Prozess heute um agile Instrumente ergänzt werden sollte. Zwischen den Gates, innerhalb der Entwicklungsphasen, empfiehlt er die Verwendung agil-adaptiver Methoden.

Das ist sicherlich eine Möglichkeit. Allerdings gibt es wesentlich mehr Punkte zu berücksichtigen. Beispielsweise:

Wie werden Aufgaben und Kompetenzen zwischen Gatekeepern und Product-Owner koordiniert?

Oft läßt sich beobachten, dass nominierte Gatekeeper wenig involviert und risiko-avers sind. Ein agiles Team dagegen hat einen starken Vorwärtsdrang. Wie wird damit umgegangen?

Ein typisches Entwicklungsprojekt besteht aus diversen Schichten (technische Produktentwicklung, Produktionstechnologie, Supply Chain, Marketing, Serviceplan …). Wie läuft die Synchronisierung, wenn es gleichzeitig agile Sprints und Gate Reviews gibt?

Die Antwort fällt leichter, wenn das zu integrierende Stage-Gate®-Modell eine der “leichteren” Varianten ist.

Schauen Sie sich auch Ihr Entscheidungsmanagement an!

Agiles Projektmanagement, oder irgendeine PM-Methodik, kann nicht alle Probleme lösen. Wenn Sie zum Beispiel ein Projekt-Portfolio nach dem Kanban-Prinzip steuern, sollten die Projektteams in kürzeren Abständen abgeschlossene Projekte liefern.

Wenn aber die verbreiteten Entscheidungsfehler bei Entscheidungen unter Unsicherheit ab morgen nach dem Kanban-Prinzip gemacht werden, ersetzen Sie lediglich die bisherigen Probleme durch andere. 

Software-Projekte vs. Nicht-Software-Projekte

Bei den meisten Software-Entwicklungen besteht das Endresultat aus zwei Schichten: Programmcode und Datenbanken. Mit der Erstellung des Codes und der Datenbanken ist das Produkt gleichzeitig entwickelt und produziert. 

Industrielle Entwicklung ist meist vielschichter. Das Ergebnis eines Entwicklungsprojektes kann aus diversen “Modulen” bestehen. Die Module interagieren sowohl im fertigen Produkt als auch während der Entwicklung miteinander.

Dadurch ist der Koordinationsbedarf zwischen den verschiedenen “Entwicklungssträngen” oft viel größer als bei Softwareprodukten. Solche Schichten, oder Entwicklungsstränge können sein:

  • das technisch-physische Produkt,
  • ein funktional-ästhetischen Produktdesign,
  • ein Verpackungsdesign,
  • gekoppelte Dienstleistungen,
  • das Marketing-Konzept,
  • das Supply-Chain-Konzept (Materialflüsse in-bound und out-bound) oder
  • die benötigten Produktionstechnologie und -technik.


Wenn aber die verbreiteten Fehler bei Entscheidungen unter Unsicherheit ab morgen nach dem Kanban-Prinzip gemacht werden, ersetzen Sie lediglich die bisherigen Probleme durch andere. 

Mit der Anzahl der Produktschichten und Entwicklungsstränge steigt der Abstimmungsbedarf. Oft macht es Sinn, in verschiedenen Entwicklungssträngen verschiedene Projektmanagement-Werkzeuge einzusetzen: Die technische Entwicklung setzt Scrum ein, Supply-Chain und Marketing-Entwicklung profitieren von Kanban, die Designentwicklung funktioniert organisationsbedingt nur mit Adhoc-kratie – als Beispiel.

Dabei ist zu klären, wie und wann Koordination und Integration stattfinden: z. B. in festen Zyklen, wenn ein Projektstrang einen Meilenstein erreicht hat, wenn alle betroffenen Stränge fertig sind … . Alles Fragen, die sich bei Softwareprojekten kaum stellen.

Es handelt sich dabei nicht um Argumente, nicht auf Agilität zu setzen. Ganz im Gegenteil: je komplexer das Projekt, umso mehr kann es durch agile bottom-up Koordination profitieren. Es geht nur darum, dass agile Werkzeuge differenzierter und “stärker adaptiert” zum Einsatz kommen sollten, als im Standard-Softwareprojekt.