Grundsätzlich
In der Betrachtung von temporären Aufgabenstellungen unterscheiden wir im traditionellen Projektmanagement grundsätzlich:
- Einzelaufgaben - geringe Komplexität, Dauer bis max. 3 Monaten.
- Kleinprojekte - geringe bis mittlere Komplexität, Dauer bis max. 6 Monaten .
- Projekte - mittlere bis grosse Komplexität, Dauer bis zu 12 Monaten.
- Programme - sehr grosse Komplexität, bestehend aus verschiedenen Projekten mit gemeinsamer Zielsetzung, Dauer bis zu mehreren Jahren.
Unabhängig von den neuen agilen Managementmethoden in der Planung und Umsetzung von temporären Aufgaben, hat die oben beschriebene Aufstellung nach wie vor ihre Berechtigung. Denn die Methoden rund um Scrum & Co. sind nicht die „Eier-legenden-Woll-und-Milch-Schweine“ die für jede temporäre Aufgabenstellung geeignet sind.
Mit dem Aufkommen von agilen Organisationsmethoden sind aber eben auch neue Betrachtungsweisen dazugekommen. Diese werde ich nachfolgend kurz ausformulieren.
Software Entwicklung
In der Software Entwicklung unterscheiden wir mittlerweile unterschiedliche Szenarien:
Szenario A - Software-Entwicklung mit eindeutig definierten Anforderungen, einem stabilen Projektumfeld und geringer Änderungsrate (Änderungsrate von unter 30%). Dabei sind traditionelle Projekt Mgmt. Methoden, kombiniert mit Software-Engineering Methoden wie zB Wasserfall- oder V-Modell und auch Prototyping passend.
Szenario B1 - Software-Entwicklung mit unklar formulierten Anforderungen, einem volatilen Projektumfeld und einer hohen Änderungsrate (Änderungsrate von über 30%). Scrum hat sich hierfür als die ideale Methode in den letzten 7 Jahren etabliert. Voraussetzung dabei ist jedoch, dass die Teammitglieder nur in diesem einem Projekt, jedoch nur in geringem Ausmass (max. 20% ihrer Arbeitszeit) andere Tätigkeiten (zB Software Wartungsarbeiten) durchführen.
Szenario B2 - Der Unterschied liegt darin, dass Mitarbeiter in verschiedenen Projektteams mitarbeiten und/oder Software Wartungsarbeiten bzw. Hotline-Dienste durchführen müssen. Hierbei stösst Scrum vom Koordinierungsaufwand her betrachtet, an seine Grenzen. Für diese Art hat sich in den letzten Jahren eine neue agile Methode, mit der Bezeichnung Kanban, etabliert. Dabei werden die Aufgaben, User Stories, oder Tasks ebenfalls auf Pinwänden angebracht um damit die aktuelle Arbeitsleistung und –belastung der Mitarbeiter zu visualisieren. Angelehnt an Kanban-Boards in der Industrie, werden neben dem aktuellen Status von Aktivitäten, Engpässe sichtbar und daher besser steuerbar.
Hardware Entwicklung
In diesem Entwicklungsbereich sind die Ergebnisziele zumeist eindeutig definierbar. Daher ist das traditionelle Projektmanagement in diesem Entwicklungsbereich die bessere Methode für Planung und Umsetzungssteuerung. Einfache und wenige Änderungsanforderungen können in dieser Methode mittels Change Request Mgmt. gut bewältigt werden.
In der Hardware Entwicklung (HW-Entwicklung) ist das vom agilen Projektmanagement bekannte „iterative“ Ausliefern von Teilergebnissen (Produktinkrementen) nur schwierig machbar. Ebenso verursacht oftmals das Zuliefern von Bauteilen Verzögerung, die über die maximale Sprintdauer von 20 Tagen hinausgeht. Damit können fundamentale Anforderung von Scrum nicht erfüllt werden.
Bei einer hohen Wahrscheinlichkeit von Änderungen während des HW-Entwicklung ist auch eine Kombination von traditionellem Projektmanagement und Scrum (zB Daily Scrum, Verwendung von Reviews und Retrospectives bei Meilensteinabnahmen) gut kombinierbar.
Service Aufträge, Hotline-Aktivitäten
Für Produktwartung oder Aktivitäten an Service- oder Hotlines, sind Visualisierungs Boards, wie zB Kanban Boards sehr gut geeignet. Damit ist es mit einfachen Mitteln möglich, einen Überblick des aktuellen Prozesses zu haben, für jeden Prozessschritt das „Work-in-Progresss Limit“ festzuhalten um damit eventuelle Engpässe besser identifizieren und beheben zu können.
Forschung
In der Forschung - schwerpunktmässig in der Grundlagenforschung - sind die Ergebnisziele am Projektbeginn zumeist nicht eindeutig definierbar. Es ist schwierig, an dieser Stelle ein passendes Werkzeug (Methode) zur Planung und Umsetzungssteuerung zu definieren. Ich persönlich habe gute Erfahrung in F&E-Projekten (Pharma und Nahrungsmittelindustrie) mit „meilensteingesteuerten Scrumprojekten“ gemacht. Dabei wird ein F&E Projekt in der Kombination aus traditionellem Projektmanagement und Scrum geplant und durchgeführt. Kanban Boards können in einer „gemischten Umgebung“ neben den Sprint Backlog Boards helfen, die aktuellen Aktivitäten zu visualisieren.
Produktentwicklung
Szenario A - In der Produktentwicklung ist zumeist ein definiertes Ergebnisziel am Projektbeginn vorhanden. Daher ist - ähnlich wie in der Vorgehensweise bei der HW-Entwicklung - die Verwendung der traditionellen Projektmanagement Methode mit möglicher Kombination zu agilen Methoden sinnvoll.
Szenario B - Bei Produktentwicklungsprojekten, mit einem hohen Problemlösungsanteil, also in Projekten wo im Vorfeld der Produktentwicklung, erst einmal das Problem eindeutig identifiziert werden muss, Lösungsvarianten ausgearbeitet werden, Prototypen entwickelt und getestet werden, sind iterative Methoden, wie zB Design Thinking sinnvoll. Vor der eigentlichen Produktentwicklung wird für dieses Teilprojekt einer Prototypenentwicklung und –testphase immer öfters ein Problemlösungsprojekt vorgeschalten und mittels der Methode Design Thinking iterativ umgesetzt.
Abb. 1: Übersicht der Methoden zur Planung und Umsetzungssteuerung von temporären Aufgaben |
Details zu den einzelnen beschriebenen agilen Methoden neben Scrum werden in den weiteren Weblogs noch ausführlich beschrieben werden.
Für weiterführende Fragen stehe ich Ihnen gerne zur Verfügung und freue mich über Ihre Kommentare zu diesem Artikel.
Weiterführende Literatur
Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.
Design Thinking-HPI: http://www.hpi.uni-potsdam.de/d-school/home.html (Abgefragt: 16. Mai 2013)
Deign Thinking-IDEO: http://www.ideo.com/about (Abgefragt: 16. Mai 2013)
Leopold, K./Kaltenegger, S. (2012) Kanban in der IT. Eine Kultur der kontinuierlichen Verbesserung schaffen, München.
Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.
Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.
Preissing, W. (2008): Visual Thinking. Probleme lösen mit der Faktorenfeldmethode, München.
Project Management Institute (2004): A Guide of the Project Management Body of Knowledge, 3. Aufl., Washington.
Keine Kommentare:
Kommentar veröffentlichen