4c37bc03-ed63-4898-80cc-616ff7391e08TrueISBN3898643867LargeBooks
© GPM-Magazin PMaktuell - Heft 3/2008, Seite 53- 54. Alle Rechte vorbehalten.
Eines der bislang umfangreichsten Bücher zum agilen Projektmanagement wurde Anfang 2008 von Bernd Oestereich und Christian Weiss gemeinsam mit zwei weiteren Koautoren der oose Innovative Informatik GmbH veröffentlicht. Im Gegensatz zu den meisten anderen Publikationen zum Thema Agilität stellen die Autoren mit ihrem – als APM bezeichneten Ansatz – nicht die softwaretechnische Seite, sondern das Projektmanagement agiler Projekte in den Mittelpunkt. Damit zielen sie auf eine Lücke der bisherigen agilen Ansätze: APM verstehen die Autoren als eine skalierbare Projektmanagementmethode, die Agilität nicht nur für kleine und mittlere Projekte, sondern auch für Großprojekte mit 50, 100 oder 200 Teammitgliedern und zwei oder mehr Jahren Laufzeit ermöglichen soll. Kernelemente dazu sind einerseits ein iterativ-inkrementelles „Timeboxing“ mit relativ kurzen, meilensteinund zeitgesteuerten Iterationen (anstelle längerer, ergebnisgesteuerter Projektphasen) sowie andererseits ein „featurebasiertes“ Planen als speziell auf IT-Großprojekte ausgerichtete Form der Projektstrukturplanung. Diese beiden methodischen Kernelemente werden im APM-Verfahren mit vielen bekannten und bewährten Methoden und Standards des Projektmanagements kombiniert.
Im ersten Kapitel des Buches wird eine ausführliche Einführung in den Verfahrensablauf gegeben. APM verfolgt danach ähnliche Grundwerte wie die anderen agilen Ansätze, das heißt eine flexible, änderungsfreundliche, interaktive und kooperative Vorgehensweise, die sich auf die Bereitstellung funktionierender, kundenfreundlicher Systeme konzentriert. In der Art und Weise, wie diese Grundwerte umgesetzt werden, unterscheidet sich APM jedoch von den anderen agilen Ansätzen. Auf der Mikroprozessebene ist es am ehesten noch mit Scrum vergleichbar (vgl. dazu „Aktuelles Stichwort“ in projektMANAGEMENT aktuell 1/2007). Gegenüber Scrum hat APM allerdings den großen Vorzug, dass es im Projektmanagement bekannte Begriffe benutzt und auf eine proprietäre, Außenstehenden unverständliche Terminologie verzichtet. Die Autoren sehen APM dabei als eine Erweiterung und Ergänzung, die auf traditionellen Projektmanagementverfahren aufbaut und deren Kenntnis voraussetzt. APM ist demzufolge nicht für Anfänger als Einstieg in das Projektmanagement geeignet, sondern eine darauf aufbauende Zusatzqualifikation.
Der Ablauf sowie die Strukturierungs- und Steuerungsinstrumente des APM-Verfahrens werden dann in mehreren Kapiteln vom Projektstart beginnend über Projekt-, Release- und Iterationsplanung bis zum Releaseund Projektabschluss ausführlich beschrieben. Dabei wird neben einer systematischen Darstellung der Arbeitsschritte immer wieder auf ein IT-Großprojekt als Referenzbeispiel zurückgegriffen, was die Ausführungen sehr anschaulich und praxisnah macht. Man merkt den Autoren ihre langjährige Erfahrung mit Softwareprojekten an und sie geben sie im Buch freizügig weiter. In traditionellem Projektmanagement qualifizierte und erfahrene Leser werden in die Lage versetzt, die beschriebenen Vorgehensweisen direkt anzuwenden und damit eine höhere Agilität im Projektmanagement zu erreichen. Hierzu erhalten sie viele nützliche Praxistipps und werden immer wieder auf erfolgskritische Punkte, die zu beachten sind, aufmerksam gemacht.
Die mit dem APM-Verfahren kombinierbaren Projektmanagementpraktiken werden in der zweiten Hälfte des Buches in Form eines Werkzeugkastens aus Techniken, Mustern, Modellen und Standards dargestellt. Dieser Teil orientiert sich fast vollständig an dem Project Management Body of Knowledge (PMBOK) des PMI. Lobenswert ist, dass die Autoren dabei eine Reihe eigener, über den PMBOK hinaus gehender Ansätze und Instrumente einbringen. Besonders interessant sind beispielsweise die agilen Festpreis-Vertragsformen, die von Oestereich entwickelt und erfolgreich eingesetzt wurden, und die Anwendung von Critical-Chain-Prinzipien in agilen Projekten.
Allerdings sind in diesem Teil des Buches neben nützlichen Hinweisen auch Lücken und problematische Empfehlungen zu finden, beispielsweise:
- Gerade in größeren IT-Projekten spielen Teamführungs-, Konfliktmanagement- und Organisationsveränderungsfragen (Change Management) eine maßgebliche Rolle. Im Buch wird darauf aber nur am Rande eingegangen und damit eine Lücke übernommen, die auch das PMBOK aufweist (vgl. dazu projektMANAGEMENT aktuell Heft 1/2003, Seite 34–38).
- Auch der Qualitätsmanagementteil übernimmt das auf veralteten Versionen der internationalen Qualitätsnormen fußende Verständnis des PMBOK. Die Definitionen im Qualitätsmanagement haben sich jedoch bei zentralen Begriffen so substanziell geändert, dass hier eine Harmonisierung dringend angeraten gewesen wäre. So verwenden die Autoren den Begriff der „Qualitätssicherung“ nicht im seit 1994 geltenden Qualitätsnormenverständnis (ISO 8402 bzw. jetzt ISO 9000). Sie bemerken auch nicht, dass seither der Begriff „Qualitätssteuerung“ durch „Qualitätslenkung“ ersetzt wurde und sprechen beim Aufbau des Qualitätsmanagements den wichtigen Teilbereich der Qualitätsverbesserung überhaupt nicht an.
- Im Risikomanagementteil wird als Hauptmethode (auch auf dem Poster zum Buch) ein Risikobewertungsdiagramm empfohlen. Danach werden für Risiken der obersten Prioritätsstufe ausschließlich das Vermeiden (durch Verzicht auf entsprechend anspruchsvolle Ziele) oder das Verlagern der Risiken auf Dritte empfohlen. Unternehmen und Projektleiter, die einseitig so pauschal vorgehen, werden dadurch veranlasst, auf die gezielte Suche nach Risikobekämpfungsmaßnahmen (die erst für Risiken mittlerer Prioritätsstufe empfohlen werden) zu verzichten. Unter den heutigen Wettbewerbsbedingungen könnte dies schnell eine Verminderung der Wettbewerbsfähigkeit des betreffenden Unternehmens zur Folge haben.
- Äußerst problematisch ist auch die Empfehlung der auf Putnam zurückgehenden sogenannten „Softwaregleichung“ als zentrale Aufwandsschätzgleichung, die ebenfalls prominent auf dem beigefügten Poster platziert wurde. Diese Gleichung wurde vor mehr als 20 Jahren entwickelt, als es agile Projekte noch gar nicht gab. Ihre Anwendung fuhrt zu teilweise abenteuerlichen Ergebnissen: Nach dieser Gleichung musste fur das im Buch dargestellte Beispielprojekt bei einer Verkurzung der Projektlaufzeit von 24 auf 19 Monate die Anzahl der Mitarbeiter von 20 auf mehr als 60 erhoht werden. Diese Grosenordnung ist vollkommen unrealistisch und ein Anwender der Formel wurde sich im Betrieb der Lacherlichkeit preisgeben.
Viele (aber nicht alle) der Probleme in diesem Teil des Buches sind auf die Anlehnung an die nicht mehr zeitgemase Grundstruktur des PMBOK zuruckzufuhren. Die Autoren begrunden diese Anlehnung damit, dass es sich beim PMBOK um einen De-fakto-Standard mit der grosten internationalen Verbreitung im Projektmanagement handeln wurde. Nicht berucksichtigt wird dabei allerdings, dass die grose Verbreitung uberwiegend die Vereinigten Staaten betrifft und weniger durch die mit dem PMBOK erreichbaren Projekterfolge als durch die Grosenordnung des amerikanischen Wirtschaftsraums und den riesigen Umfang der dort vergebenen staatlichen Projekte ausgelost ist. Die hohen Misserfolgsraten amerikanischer Softwareprojekte sollten eigentlich vorsichtig machen. Dem dazu von den Autoren zitierten Chaos- Report vergleichbare deutsche Untersuchungen weisen hierzulande auf geringere Fehlschlagsraten hin als in den Vereinigten Staaten, und deutsche Unternehmen, die den PMBOK eingefuhrt haben, sind bisher nur selten durch einen gesteigerten Unternehmenserfolg aufgefallen.
Als Berater und Trainer machen die Autoren leider auch nur in geringem Umfang Angaben zu den zugrunde liegenden Quellen. Beispielsweise findet sich zum kompletten Wissenselement .Risikomanagementg, das auf immerhin 18 Seiten dargestellt ist, als einziger Hinweis auf .Weiterfuhrendesg der Verweis auf die Autobiografie von Helmut Kohl und dessen Praktik des .Aussitzensg. Argerlich ist auch, dass bei den sparlich zitierten Quellen keine Seitenangaben gemacht werden. Soll sich doch der interessierte Leser die betreffenden Textpassagen muhsam selbst heraussuchen, auch wenn es sich dabei um Bucher mit mehreren Hundert Seiten handelt. Eine starkere Beachtung der bei Fachbuchern ublichen und sinnvollen Zitierregeln hatte dem Buch hier gutgetan.
Als Fazit bleibt eine geteilte Empfehlung: Das Buch ist, obwohl auserst informativ und sehr gut verstandlich geschrieben, nichts fur Anfanger oder Studenten, die die aufgefuhrten Schwachpunkte nicht erkennen und dadurch zu unbeabsichtigten Fehlern verleitet werden konnen. Qualifizierte und erfahrene Softwareprojektleiter, die das Buch ja in erster Linie ansprechen will, konnen (die wenigen) Schwachpunkte jedoch in der Regel leicht als solche erkennen und ausblenden. Sie konnen aus der groseren Zahl an interessanten und empfehlenswerten Ansatzen einen vielfaltigen Nutzen ziehen, wenn sie ihren Projekten mehr Agilitat verleihen wollen. Die Konzepte des Timeboxing und des featurebasierten Planens verdienen fur diese Zielgruppe uneingeschrankte Aufmerksamkeit und sind den Kauf des Buches allemal wert.
