Der vom amerikanischen Project Management Institute (PMI®) herausgegebene "Project Management Body of Knowledge" (PMBOK® Guide) bildet die Basis für die Vorbereitung auf das weltweit am häufigsten vergebene Projektmanagement-Zertifikat, den "Project Management Professional" (PMP). Durch die weite Verbreitung hat sich der Guide zu einem De-facto-Standard in der systematischen Aufbereitung von Projektmanagement-Methoden entwickelt.

Dieser Artikel erläutert, warum für jedes Projekt eine individuelle Anpassung des PMBOK® Guide erforderlich ist, wie diese Anpassung aussehen kann, um IT-Projektmanagement pragmatisch zu betreiben, und welche Vorteile ein maßvoller Zuschnitt dieses Standards auf die Bedürfnisse des Projektmanagements im eigenen Unternehmen bringen kann.

Auf den ersten Blick sieht es ganz einfach aus: Da haben sich über Jahrzehnte weltweit Hunderte kluger Köpfe über Projektmanagement-Methoden Gedanken gemacht und ihre Ideen, Vorgehensweisen und Werkzeuge in einem Buch zusammengetragen. Dieses gilt heute als Standardwerk und präsentiert auf aktuell 459 Seiten Wissen, das Projektmanager aus aller Welt aus ihrer Praxis herausdestilliert haben. Aus erfolgreichen wie gescheiterten Projekten haben sie ihre Lehren gezogen und sich bemüht, ihre Erkenntnisse für andere allgemein verständlich aufzubereiten. In einem letzten großen Schritt hat ein internationales Redaktionsteam dann aus all diesen Best Practices den PMBOK® Guide geformt. Da der PMBOK® Guide ISO- und ANSI-zertifiziert wird, muss alle vier Jahre eine aktualisierte Fassung vorgelegt werden. Ende 2012 ist es wieder so weit.

Was auf den ersten Blick so einfach aussieht, stellt sich auf den zweiten, genaueren Blick etwas anders da: Für jemanden, der keine Vorbildung oder Praxiserfahrung im Projektmanagement hat, sind die Inhalte des PMBOK® Guide nur schwer verständlich. Selbst erfahrenen Projektleitern kann man den Guide nicht einfach in die Hand drücken und sagen: "So machen wir's ab jetzt." Zu komplex sind die dargestellten Zusammenhänge, zu abstrakt die Beschreibungen.

Was vorher "bottom-up" in Best Practices aggregiert wurde, muss erst einmal "top-down" auf das Projektmanagement im eigenen Unternehmen heruntergebrochen werden. Diese Anpassung der Inhalte des PMBOK® Guide an die projektspezifischen Bedürfnisse fordern auch seine Autoren von den Lesern. Dies ist jedoch nichts, was man als Projektleiter mal eben zwischen Frühstück und Zähneputzen macht.

Dass sich der Aufwand lohnt, zeigen Unternehmen wie IBM oder Siemens, die ein maßgeschneidertes Projektmanagement aus Modulen des PMBOK® Guide entwickelt haben und es in ihren Projekten konsequent einsetzen. Ein einheitliches Vorgehen im Projektmanagement hilft dem Management, Projekte besser zu steuern und projektübergreifend zu bewerten, und liefert letztendlich bessere Projektergebnisse. Zugegeben: Es gibt nur wenige verlässliche Studien, welche diese These wissenschaftlich und mit Zahlen untermauern. So haben Janice Thomas und Mark Mullaly in einer umfangreich angelegten Untersuchung nachgewiesen, dass der Einsatz einer Projektmanagement-Methode mittelfristig tatsächlich einen finanziellen Vorteil verschafft (Thomas; Mullaly, 2009). Die Projektbeteiligten nehmen aber die qualitative Verbesserung der Projektprozesse, etwa durch die Bereitstellung von Vorlagen, die einfach zu handhaben sind, in jedem Fall wahr.

Bedarfsgerechter Zuschnitt des PMBOK® Guide

Auch die adesso AG hat in den letzten Jahren auf Basis des PMBOK® Guide ein eigenes Vorgehensmodell zur Durchführung von Softwareprojekten entwickelt und setzt es sehr erfolgreich in Projekten ein. Im Folgenden zeige ich, wie sich das PM-Standardwerk in einer speziellen Branche (hier die IT) und letztlich in einer bestimmten Art von Projekten (hier Softwareprojekten) anwenden lässt.

Das Unternehmen betreibt das Modell unter dem Namen PITPM (für Pragmatisches IT-Projektmanagement) und setzt es in internen wie externen Projekten ein. Ausgangspunkt für diese Entwicklung war, dass der Vorstand forderte, ein Vorgehen zu schaffen, dass sowohl bei klassisch-phasenorientierten als auch bei agilen Softwareprojekten greift.

Ein Großteil der Projekte, an denen in einigen Fällen auch die Auftraggeber mitarbeiten, wird immer noch nach Zeit und Aufwand abgerechnet. Neben diesen Projekten werden immer mehr Aufträge im Rahmen einer Festpreisvereinbarung durchgeführt, bei denen der Auftraggeber meist nur für die Definition der Anforderungen verantwortlich ist. In einem Festpreisprojekt lautet eine zwingende Voraussetzung, dass der Auftraggeber alle umzusetzenden Inhalte zuvor genau spezifiziert hat. Andernfalls läuft er Gefahr, eine für den geplanten Verwendungszweck nicht einsetzbare Software geliefert zu bekommen.

Parallel entwickelt sich eine rasant steigende Nachfrage nach agil durchgeführten Projekten bei gleichzeitiger Budgetdeckelung, denn beim agilen Vorgehen sehen die Kunden ohne lange Spezifikationsphasen greifbare Zwischenergebnisse.