Mitte der 90er Jahre erblickte der erste PMBOK® (sprich "PIMMBOCK") als ANSI-Standard die Welt. Seither erschien alle vier Jahre eine neue Auflage; insgesamt wurden bisher über 2 Millionen Exemplare verkauft. Eigentlich ist sein korrekter Titel "A Guide to the Project Management Body of Knowledge", abgekürzt "PMBOK® Guide" oder umgangssprachlich eben nur "PMBOK". Herausgegeben wird der PMBOK Guide vom Project Management Institute, kurz PMI®. Autoren sind die Mitglieder des PMI, die in globalen virtuellen Projekten an der Weiterentwicklung des PMBOKs arbeiteten. Das PMI ist eine US-amerikanische Not-for-Profit-Organisation mit Hauptsitz in Newton Square, Pennsylvania und bietet eine Reihe von Zertifizierungen an, die in unterschiedlichem Umfang auf dem PMBOK Guide basieren. Die bekannteste Zertifizierung mit weltweit mehr als 300.000 Personen ist der "Project Management Professional", abgekürzt PMP®.

Viele Projektmanager betrachten "den PMBOK" als eine Werkzeugkiste: Sie greifen die ihnen als geeignet erscheinenden Prozesse oder Methoden heraus, ohne sich um die jeweiligen Verflechtungen mit den anderen Inhalten zu kümmern. Sie können damit mehr Schaden als Nutzen anrichten, da sie wichtige Zusammenhänge nicht berücksichtigen oder sogar die falschen Werkzeuge für ihre spezifischen Aufgaben einsetzen. Unglücklicherweise unterstützt der PMBOK Guide diese Vorgehensweise sogar noch, indem er nicht darlegt, wie mit seiner Hilfe ein branchen- oder unternehmensspezifisches Projektmanagementsystem definiert werden soll. Im Folgenden erkläre ich, wie man Projektmanagement gemäß PMBOK Guide sachgerecht aufsetzt und versuche im Sinne einer konstruktiven Kritik darzulegen, wie der PMBOK Guide dieses Vorgehen seinen Lesern besser vermitteln könnte.

PMBOK Guide: Kein Projektablauf, sondern Prozessrahmenwerk

Auf den ersten Blick handelt es sich beim PMBOK Guide um eine Sammlung von derzeit 42 Prozessen, die einen so genannten Projektmanagement-Lebenszyklus ergeben. Ein Projektmanagement-Lebenszyklus beschreibt alle Projektmanagementaufgaben, die im Lauf eines Projekts zu erledigen sind; dabei geht er jedoch nicht auf das zu erstellende Projektprodukt oder die Projektart ein. Und genau darin liegt die Tücke: Ein Projektmanagement-Lebenszyklus lässt sich auf die Erstellung jedes beliebigen "Projektprodukts" bzw. auf das für die jeweilige Projektart spezifische Phasenmodell anwenden (z.B. Hausbau, Softwareentwicklung, Entwicklung eines Einspritzsystems, Bau einer Windparkanlage) und ergänzt dieses, ist aber nicht mit ihm identisch.

Die 42 im PMBOK Guide definierten Projektmanagementprozesse könnten theoretisch in jeder Projektphase vorkommen. Diese Variabilität ist zugleich Fluch und Segen. Einerseits erlaubt dieses Prinzip die Anwendung der PMBOK Guide-Prozesse in jedem Projekt - unabhängig davon, wie das Ergebnis (also das Projektprodukt) aussehen soll. Andererseits finden sich an vielen Stellen wegen dieser Variabilität wenig konkrete oder sogar widersprüchliche Handlungsanweisungen. Der Anwender findet im PMBOK Guide auch weder Vorlagen noch andere Hilfsmittel. Warum? Der PMBOK Guide ist eben keine definierte Methode, die einen Projektablauf beschreibt, sondern ein Prozessrahmenwerk.

Eine solche Methode, wie sie der Projektmanager zur Bewältigung seines Alltags benötigt, entsteht erst dann, wenn die für eine Branche oder Projektart spezifischen "Projektprodukt-Erstellungsprozesse" mit den 42 "Projektmanagementprozessen" des PMBOK Guides in einem Phasenmodell konkretisiert werden. Ein solches Phasenmodell enthält dann klare Vorgaben, wie diese Prozesse anzuwenden sind.

Deshalb ist der PMBOK Guide keine Methode, und er hat auch nicht den Anspruch eine zu sein - schließlich werden die betrieblichen und produktspezifischen Elemente immer fehlen. Er ist vielmehr der "Guide", der zum "Body of Knowledge" führt, d.h. zum Wissen, was in einer vorliegenden Situation eine günstige Vorgehensweise ist. Es ist für den Anwender von entscheidender Bedeutung, diesen Unterschied zwischen Prozessrahmenwerk und Methode zu verstehen. Ansonsten läuft er Gefahr, mit unpassenden, falsch dimensionierten und in sich widersprüchlichen Vorgehensweisen zu arbeiten. Es handelt sich dabei also keineswegs um eine akademische Diskussion, denn dieser Unterschied hat einen gravierenden Einfluss auf die Verwendung in der Praxis (siehe unten).

Flexibel, aber nicht beliebig!

Genau diese Variabilität begründet die Erfolgsgeschichte des PMBOK Guides und seine weltweite Verbreitung. Weil das Prozessrahmenwerk auf jedes Projektprodukt passt, kann es auch überall eingesetzt werden. Dafür muss es jedoch die Beschreibungen in Teilen allgemein halten. Viele Kritiker ignorieren diese Zusammenhänge anscheinend und werfen dem PMBOK Guide Beliebigkeit vor. Bei genauer Betrachtung löst sich das Problem der scheinbaren Beliebigkeit auf, allerdings muss man sich wirklich im Detail mit der Logik und der Struktur der Prozesse beschäftigen, wenn man mit dem Werk in der Praxis arbeiten möchte.

Beispiel Risikomanagement

Die Beschreibung des Prozesses Risikoidentifikation (11.2 Identify Risks, PMBOK Guide 2008, p. 282 ff) zählt eine Fülle von Möglichkeiten auf, wie man Risiken identifizieren kann: von Brainstorming über Delphi Techniken zu Checklisten und der Analyse von Annahmen. Die Ergebnisse dieses Prozesses sind dann in einem Risikoregister zu dokumentieren.