Der Wettbewerb in der freien Wirtschaft zwingt Unternehmen weltweit zur ständigen Verkürzung der Time-to-Market ihrer Produkte und der Produktzyklen, um sich so einen höheren Marktanteil zu sichern. Dies erhöht auch den Druck auf die IT-Projekte in den Unternehmen. Dieser Anstieg des Drucks führt zu einer hohen Quote an gescheiterten Projekten. So geht aus einer Studie der Beratungsfirma Steria Mummert Consulting und der Fachzeitung InformationWeek aus dem Jahre 2009 [http://www.steria-mummert.de/presse/pressearchiv/1.-quartal-2009/projektbilanzen-2008-it-abteilungen-steigern-effizienz, 18.02.2011] hervor dass 24% der IT-Projekte ergebnislos abgebrochen wurden. Die Untersuchung der Ursachen für Projektabbrüche ist ein zentrales Thema in weiteren Studien, wie der häufig zitierte aber in die Kritik geratene „CHAOS Report” [Standish Group 2006] der Standish Group untermauert. Die Standish Group identifiziert fünf Hauptgründe für das Scheitern von Projekten unvollständige Anforderungen, mangelndes Einbinden der Endnutzer, mangelnde Ressourcen, unrealistische Erwartungen und mangelnde Unterstützung des Managements an.
Die Firma oose Innovative Informatik GmbH aus Hamburg erstellte im Jahr 2008 eine Studie mit über 200 [http://www.oose.de/pm/pm-studie.html, Abrufzeitpunkt 18.02.2011] Teilnehmern mit folgenden Zielsetzungen:
- Gibt es signifikante Unterschiede darin, wie klassische und agile Projekte arbeiten?
- Was können agile und klassische Projekte voneinander lernen?
- Welche Verfahren tragen zum Projekterfolg bei?
Das Ergebnis der Studie zeigte das agil geführte Projekte eine deutlich geringere Abbruchquote als klassisch geführte Projekte aufwiesen.
Wirkliche Verbesserung der Projektqualität?
Prozessqualität steht im direkten Zusammenhang zu der Produktqualität [Bartsch-Beuerlein, Frerichs: Kompetenzbasiertes Projektmanagement (PM3), Kapitel 1.05, S. 163]. Die Prozessqualität lässt sich anhand von Qualitätsmerkmalen messen. Für den Vergleich wurden folgende Prozessqualitätsmerkmale ausgewählt und wie folgt definiert:
- Time-to-Market (TOM)
- Zeit bis zur Markteinführung eines Produktes.
- Je kürzer, desto besser.
- Sicherung der Zuverlässigkeit
- Anzahl der Fehler
- Stabilität
- Termintreue
- Lieferung in einem abgesteckten Zeitrahmen mit einer definierten Anzahl an Ressourcen
- Anforderungsstabilität
- Anzahl der Change Requests
- Zeitverlust durch die Umsetzung von Changes
- Integrierte Projektsteuerung
- Anzahl an notwendigen Dokumenten zur Steuerung
- Ressourcenaufwand für das Projektcontrolling
- Mitarbeitermotivation
- Selbstverwirklichungsmöglichkeiten
- Eigenverantwortung
- Spielraum der Mitarbeiter
Die folgende Tabelle ist ein Ergebnis von Erfahrungswerten und Interviews mit Projektmanagern sowohl aus dem klassischen als auch dem agilen Umfeld.
| Agil nach Scrum | Klassisch nach Wasserfall oder V-Modell | |
| Time-to-Market |
|
|
| Zuverlässigkeit |
|
|
| Termintreue |
|
|
| Anforderungs-stabilität |
|
|
| Projektsteuerung |
|
|
| Mitarbeiter-motivation |
|
|
Scrum einführen und dann läuft‘s …
Agile Projektmanagement-Ansätze liegen bei IT-Projekten in Deutschland im Trend. Doch längst nicht allen Unternehmen gelingt der reibungslose Umstieg. Ein Drittel der agilen Projekte scheitern, weil die notwendigen Rahmenbedingungen nicht geschaffen werden. (Nielsen + Partner 31.10.2011) Häufig stoßen agile Verfahren auf klassische Projektmanagementmethoden mit einer starren Planung. Konflikte sind damit vorprogrammiert.
„SCRUM-Projekte scheitern häufig daran, dass beispielsweise der interne oder externe Auftraggeber seine erforderlichen Mitwirkungsleistungen nicht erbringen kann.“
Zentraler Erfolgsfaktor für agile Projekte ist die Einbettung in das Gesamtunternehmen sowie die Unterstützung des Top-Managements und internes Eigenmarketing. Eine weitere zwingende Voraussetzungen sind zudem die permanente intensive Mitarbeit des Auftraggebers im Projekt, ein äußerst konsequentes Projektmanagement, die Übernahme von Verantwortung durch alle Projektmitarbeiter sowie die Fähigkeit, Anforderungen immer wieder neu zu priorisieren. Generell ist ein Umdenken aller Beteiligten von Nöten. Klassische Muster müssen ab- oder zumindest bei Seite gelegt werden.
Ein Gastbeitrag von Stefan Conrad, Inhaber der DDS-Consulting GbR, zertifizierter Scrum Master (CSM) und Scrum Professional (CSP).
Sehr gute Zusammenfassung der Situation! Aber eine echte Lösung steht hier nicht.
Auf openPM.info finden sich zwei Artikel einer zu „reliable-scrum“ und „projektmanagement 3.0“. Da ist beschrieben wie man Scrum um Elemente von Critical Chain ergänzt und es so zuverlässig und kompatibel zu klassischen Unternehmen/Projekten wird. Projektmanagement 3.0 beschreibt dann wie Scrum, Critical-Chain und Kanban in einem Projekt zusammen spielt.
Ich kann auch jedem nur empfehlen sich mal Critical Chain anzuschauen das ist das Scrum für Projekte 😉
Hallo Herr Müller,
ich glaube wenn die Lösung so einfach wäre das ich Sie in einem Blog Eintrag verfassen könnte, dann wäre ich bereits ein reicher Mann. Auch Ihr Projektmanagement 3.0 Ansatz ist meines Erachtens nur ein möglicher Lösungsansatz, aber die Schwächen einer Methode durch eine weitere zu Methode auszugleichen halte ich nicht für den richtigen Ansatz. Des weiteren halte ich Sätze wie „Es gibt unzähliche Erfolgsberichte External Link mit z.T. unglaublichen Effekten (nicht wundern! staunen).“ für bedenklich. Im Kern werden Projekte immer noch von Menschen durchgeführt und wenn diese nicht miteinander Arbeiten dann hilft die beste Methode nicht. Verstehen Sie mich nicht falsch, ich mag den Critical Chain Ansatz und sehe durchaus Potential, aber ihn als das Heilmittel für alle Projekte in Schieflage zu bezeichnen sehe ich leider nicht.
Insofern kann ich nur empfehlen sich mit Menschen auseinanderzusetzen (Sowohl Teammitglieder als auch Stakeholder, so wie das Management) und hier versuchen die Potentiale auszuschöpfen.
In einen Kommentar kann man dummerweise nicht alles reinpacken. Der Mensch ist im Projektmanagement auf jeden Fall der wichtigste Faktor und jede Auseinandersetzung hier ist lohnenswert.
Ich möchte hier nur den Blick öffnen. Ich hab mit meiner Mannschaft ca. 500 Projekte verantwortet und dabei eine Erfahrung gemacht. Manchmal sind es die kleine Dinge (Methoden) wenn man die ändert verändert sich das ganze System drum herum.
Was ich immer wieder erlebe sind hoch motivierte Menschen die die Welt verändern können/wollen. Diese kommen in ein System (Unternehmen), das der Meinung ist, dass mehr Druck/mehr Arbeit bessere Ergebnisse liefert (weit verbreitet). Das führt in kürzester Zeit dazu, dass die Mitarbeiter frustriert sind. Je mehr man diese dann versucht zu fördern desto schlimmer wird es.
Das heißt an dieser Stelle sollte man eingreifen. Critical Chain und Reliable Scrum machen genau das. Sie stellen sicher, dass nicht zu viel Arbeit (Work-In-Progress) im System ist und damit ermöglichen sie erst, dass die Menschen „frei aufspielen“ können. Damit sind sie wie ein Katalysator, der die ganzen anderen Bemühungen plötzlich wirksam werden lässt.
Daher gebe ich ihnen vollständig recht und biete an sich Critical Chain / Reliable Scrum unter dem Aspekt zu betrachten, was sie den Menschen im Unternehmen ermöglichen.