Ein großes Unternehmen des Maschinen- und Anlagenbaus hat ein unternehmensweit einheitliches Projektmanagementsystem etabliert, das auf vier Elementen basiert: Gemeinsame Sprache, Prozesse, Menschen, Werkzeuge. Unter der Überschrift "Menschen" werden die verschiedenen Rollen im Projekt beschrieben (Sponsor, Projektmanager, Team, Lenkungsausschuss, …); im Kapitel "Prozesse" wird ein Vorgehensmodell dargestellt, nach dem ein typisches Projekt abgewickelt wird. Wenn ich bei Projektmanagement-Trainings in diesem Unternehmen die Methodik vorstelle, frage ich die Teilnehmer, welches der Elemente wohl das wichtigste sei. Es überrascht kaum, dass sie an erster Stelle das Element "Menschen" nennen. Aber schon beim zweiten Platz herrscht Uneinigkeit: Viele Teilnehmer sind der Ansicht, dass die Verfügbarkeit geeigneter Werkzeuge die zweitgrößte Rolle spielt, während sie die Bedeutung der Prozesse nicht so groß einschätzen.

In der Diskussion stelle ich dann meine Meinung vor: die gemeinsame Sprache steht als eine conditio sine qua non neben oder über allem. Wenn wir nicht dasselbe Vokabular verwenden, können wir nicht zusammenarbeiten. Allerdings ist diese Bedingung relativ leicht zu erfüllen. Ansonsten ist der Mensch das Wichtigste: Neben den unabdingbaren sozialen Fähigkeiten gilt es, die Rollen sinnvoll zu definieren, die in der Praxis mit Leben erfüllt werden müssen, was sich oft als sehr schwierig erweist. Danach folgen die Prozesse. Die Art und Güte der verwendeten Werkzeuge liefert meiner Meinung nach den geringsten Beitrag zum Gelingen des Projekts. Allerdings wird in den Firmen viel Zeit und Energie in die Auswahl, Gestaltung und Vereinheitlichung von Werkzeugen investiert, während über die Prozesse vergleichsweise wenig gesprochen wird.

Betrachten wir deshalb die Prozesse einmal genauer. Die meisten großen Unternehmen haben über die Jahre ihre Geschäftsprozesse mehr oder weniger sorgfältig ausgearbeitet. In der Regel finden wir auch Vorschriften, wie Projekte abgearbeitet werden sollen. Sie tragen je nach Firma unterschiedliche Namen wie "Gate-Modell", "Phasenmodell", "Stage-Gate-Prozess" o. ä. Wie sehen diese Prozesse aus, woher stammen sie, und was ist ihr Sinn?

Heutige Phasenmodelle regeln die Abwicklung eines Projekts

In vielen Firmen wird die Durchführung eines Projekts aufgeteilt in mehrere Phasen, die chronologisch nacheinander ablaufen. Nehmen wir als Beispiel die Entwicklung eines Produkts oder einer Anlage im Kundenauftrag. Ein Kunde richtet eine Anfrage an einen möglichen Lieferanten. Dieser führt mit dem Kunden Verhandlungen, die schließlich in einen Vertragsabschluss münden. Ein Projektmanager wird ernannt und es wird ein Gesamtplan aufgestellt, der z.B. folgende Phasen umfasst: Konzept, Design (bzw. Engineering), Realisierung, Übergabe an den Kunden, Abschluss. Die Art der Phasen und ihre Benennung richten sich nach der jeweiligen Branche. So wird in der Geräteentwicklung häufig von "Design" gesprochen, während im Anlagenbau von "Engineering" die Rede ist. Zwischen den Phasen liegen Gates: ein Gremium von entscheidungsberechtigten Stakeholdern tritt zusammen, prüft die vom Projektmanager vorbereiteten Dokumente und befindet darüber, ob in der zurückliegenden Phase alle Aufgaben ordnungsgemäß erledigt wurden und die Phase abgeschlossen werden kann. Wichtiger ist aber die Entscheidung darüber, ob die nächste Phase begonnen werden darf. Zu diesem Zweck wird geprüft, ob die dafür notwendigen Pläne, Verträge, Genehmigungen und Bestellungen vorliegen.

In dem zugrundeliegenden Prozessmodell, das den Projektmanagern quasi als Verfahrensanweisung vorgegeben wird, ist geregelt, was in den einzelnen Phasen getan werden muss, wer an den Gate-Meetings teilnimmt, also zu den Entscheidern gehört, und welche Liefergegenstände (Desiderables) deshalb zu den Gates vorzulegen sind. Dazu gehören u.a. Berichte, aktualisierte Termin- und Kostenpläne, sowie Risikolisten. Der Schwerpunkt liegt jedoch meist auf dem Lieferumfang (Scope), d.h. den technisch / fachlichen Einzelheiten des Projekts. Der Nutzen des Projekts, also der Business Case, steht oft nicht mehr zur Debatte, wenn der Projektmanager ins Spiel kommt und mit seiner Arbeit beginnt. Damit wird er zum reinen Projektabwickler.

Woher stammen diese Prozessmodelle?

Ein Großteil des heutigen Projektmanagements wurde ja Mitte des vorigen Jahrhunderts in den USA entwickelt anhand der damals aktuellen Großvorhaben, nämlich dem Apollo- und dem Polaris-Raketenprogramm. Auftraggeber waren die NASA und das Pentagon, beides Organisationen mit einer sehr ausgeprägten Bürokratie. Daher ist es kein Wunder, dass Projektmanagement auf bürokratische Instrumente setzt wie Formulare, Checklisten, Flussdiagramme und Prozessbeschreibungen, die man braucht, um die Schnittstellen innerhalb komplizierter und umfangreicher Geschäftsabläufe zu definieren und zu regeln. Diese Instrumente sind natürlich dann besonders wertvoll und effizient, wenn sie bei sich wiederholenden Geschäftsprozessen eingesetzt werden können, also im Tagesgeschäft. Wir sollten aber im Hinterkopf behalten, dass Projekte, die diesen Namen verdienen, immer etwas Einmaliges sind, auch wenn sie sich in ihrem Ablauf häufig ähneln.

Prozessmodelle haben Stärken und Schwächen

Ein solches Prozessmodell, das den Ablauf eines Projekts beschreibt, hat Stärken und Schwächen, wobei eine Schwäche häufig die Kehrseite einer Stärke ist. Ich beginne mit den Stärken: