Die Gegnerschaft sollte man, wenn’s nach mir geht, nicht mit Feindschaft gleichsetzen. Zum potentiellen Kommunikationsproblem möchte ich anmerken, dass ein Prozessmanager – also ein Arbeitsmethodiker – zu diesem Statement wohl sagen würde: "Meine Prozesse kennen keine Gegner!" (weil sie nicht juristisch definiert sind)

In der letzten Zeit bin ich öfters mit verschiedenen Lagern in Berührung gekommen. So etwa beim Augsburger PM-Methodentag, der gemeinsam veranstaltet wird von der DGQ und dem PM-Forum, getragen unter anderem von der GPM. Eine gemeinsame Arbeitsgruppe von GPM und DGQ setzte dort den löblichen Versuch fort, die komplizierte Beziehung zwischen zwei sehr unterschiedlichen Brüdern innerhalb der großen Wirtschaftsfamilie, QM und PM, zu harmonisieren. Etwas später habe ich aus gegebenem Anlass eine Veranstaltung der XING-Gruppe "BPM Business Process Management" besucht. Und in beiden Fällen konnte ich mich des Eindrucks nicht erwehren – und ich übertreibe jetzt trotz absolutem Wohlwollen und großer Sympathie -, dass in den Augen von Prozesslern und Qualitätlern die Welt erst dann halbwegs funktionieren kann, wenn man sie in einen guten Prozess gepresst hat. Und mir ist wieder einmal ganz deutlich geworden, was ich schon lange weiß:

Projektmanagement ist kein Prozessmanagement!

---

Da bin ich wieder. Ich musste nur kurz in meinen Unterstand, um die Einschläge abzuwarten.

Zum ersten Mal wurde ich mit diesem Thema konfrontiert, als mir in der Feedbackrunde nach einem PM-Grundlagenseminar eine Teilnehmerin sagte, ich hätte zu wenig über Prozessmanagement erzählt. Dabei war eines meiner Themen Sinn und Zweck eines Stage-Gate-Prozesses gewesen, und da eine meiner Vorgaben für die Tätigkeit als Trainer der PMBoK Guide ist, sehe ich ohnehin alles prozessorientiert. Das ändert aber nichts daran – und so habe ich es der Teilnehmerin erklärt –, dass ich unter einem guten Projektmanager jemanden verstehe, der fähig ist, ein anspruchsvolles und einmaliges Vorhaben zu "managen", von mir aus auch auf eine einmalige Art und Weise, auf jeden Fall aber in einer weitgehend selbstbestimmten und mündigen Form, so wie auch der Chef eines kleinen Unternehmens seinen eigenen Weg finden muss. Dass man dabei auf die Hilfe bewährter Methoden, Werkzeuge und Prozesse zurückgreifen kann, wenn es einem sinnvoll erscheint, versteht sich von selbst.

Ich habe mal in einem Unternehmen einen sehr detailliert ausgearbeiteten Projektprozess kennengelernt, der auf Grund seines Umfangs auf Anhieb nicht gerade zum Studium einlud, aber sehr sinnvoll gestaltet war. Das Beste an ihm war aber die Anwendungsregel Nummer 1: Prüfe, was von diesem Prozess Du in Deinem aktuellen Projekt wirklich brauchst!

In einem anderen Unternehmen gab es ein Projektmanagementhandbuch, auf dessen Deckblatt ein großer Kreis mit der Inschrift "Language" zu sehen war, der drei kleinere, aber ähnliche Kreise mit "People", "Processes" und "Tools" überlappte. Wir haben die Graphik diskutiert und kamen zu dem Ergebnis, dass ohne eine gemeinsame Sprache Projektarbeit nicht möglich ist, die kleineren Kreise sich aber in ihrer Größe durchaus unterscheiden sollten; für alle Projektteams war klar, dass "Menschen" die höchste Priorität haben, dann kommen "Prozesse", und erst am Schluss folgen die Werkzeuge.

Warum wird immer wieder versucht, das Projektmanagement unter die Knute eines Prozesses zu zwingen? Projektmanager lehnen das eher ab: "Die Firma ist schuld; die Manager verlangen das von uns." Aber wie kam es dazu?

Never change a running process!

Der Grund ist in der Geschichte des Qualitätsmanagements zu finden. Als in der zweiten Hälfte des vorigen Jahrhunderts der Verkäufermarkt von einem Käufermarkt abgelöst wurde, kam man zwangsläufig aus Wettbewerbsgründen auf die sinnvolle Idee, Qualität in die Produkte nicht "hinein zu prüfen" (und den Ausschuss dann wegzuwerfen), sondern von vornherein nur Produkte mit ausreichender Qualität zu produzieren: "right first time". Und die Produkte wurden immer anspruchsvoller. Während es zu den Zeiten von Henry Ford I. noch genügend Menschen gab, die in der Lage waren, die Qualität eines Teilprodukts schon während der Herstellung zu beurteilen, hat sich in der Folge die Technologie weiterentwickelt, und in der "Tin Lizzy" von heute, nämlich dem Handy als dem Massenprodukt schlechthin, sind elektronische Bauteile enthalten, deren Qualität und Zuverlässigkeit während der Herstellung kein Beteiligter mehr beurteilen kann. Das hat zur Folge: wenn man einmal einen Herstellungsprozess entwickelt hat, der zu einem Produkt gewünschter Qualität führt, dann schreibt man ihn ehern fest und ändert ihn nie mehr ohne Not; denn jede Änderung eines teilweise unverstandenen Prozesses birgt das Risiko nachlassender Qualität.

Das scheint mir im Lauf der Zeit ein Dogma geworden zu sein, und deshalb wird es ja auch gern auf Englisch formuliert: "Never change a running process!"

Heute werden im Rahmen des Business Process Managements alle Prozesse in einem Unternehmen sinnvoll gestaltet, und das ist gut so. Nur wird leider das Dogma auf alle diese Prozesse ausgeweitet, teilweise auch bedingt durch die IT-Werkzeuge, die eine Abweichung oft nicht tolerieren können und ihre Mitarbeit einstellen. Und einer Unternehmensbürokratie kommt das ohnehin entgegen, denn das Kennzeichen einer richtigen Bürokratie ist ihre Abneigung gegen Änderungen.

Nun ist es aber so, dass ein vernünftiger Mensch, und also auch ein guter Projektmanager, die Sinnhaftigkeit eines Prozesses, und also auch die von PM-Prozessen, im Detail durchaus verstehen kann und das auch tun sollte. Und was man verstanden hat, kann man auch zum Guten ändern. Man darf nie vergessen: Viele Projekte sind einander ähnlich, aber letztlich zumindest in einem Aspekt immer Unikate: So ist ja der Begriff "Projekt" schon definiert. Und die Zwänge des magischen Dreiecks erfordern oft eine rationelle und rationale Anpassung der Arbeitsprozesse. Wenn man deren Sinn verstanden hat, ist das auch möglich, denn im Gegensatz zu technologischen Prozessen ist schiere Wiederholbarkeit kein Erfolgsfaktor!

Man stelle sich einmal vor, die individuelle Tätigkeit eines CEO würde in wiederkehrende Prozesse gezwängt! Selbstverständlich muss sich der Chef bestimmten von außen vorgegebenen Regularien, wie z.B. KonTrag oder Sarbanes-Oxley, unterwerfen, aber ebenso natürlich bleibt ein großer individueller Spielraum für die Gestaltung der eigenen Arbeit. Anders wäre unternehmerisches Handeln gar nicht möglich. Und wenn man gutes Projektmanagement als Unternehmertum auf Zeit versteht, dann gilt dasselbe für einen Projektmanager.

Interessanterweise forcieren gerade Manager gleichartige und wiederholbare Prozesse im Projektmanagement ohne Berücksichtigung der Einmaligkeit eines Projekts. Das sieht man besonders im Reporting. Das erleichtert den Managern ihre Arbeit, leistet aber leider keinen Beitrag zur Effizienz in den einzelnen Projekten. Und außerdem trägt es ein wenig bei zur Entmündigung oder besser zur Unmündig-Haltung der Projektmanager, die ihre Handlungsspielräume stärker eingeschränkt sehen, als es mit ihrer Gesamtverantwortung für den Projekterfolg vereinbar wäre.

Und damit sind wir wieder beim Business Process Management: ein "Workflow" wurde erfunden, damit Menschen, die keinen Überblick über das große Ganze haben, gezwungen sind, zum richtigen Zeitpunkt die richtigen Tätigkeiten richtig durchzuführen. Das sollte ein guter Projektmanager nicht benötigen; was ihm hilft, sind Prozesse als "Framework", nämlich Leitplanken, innerhalb derer er seine Arbeit selbstbestimmt und dem Projekt angemessen gestalten kann.

Also, hoffentlich in tiefer Übereinstimmung mit einsichtsvollen Qualitätlern, Prozesslern und Projektlern:

Nieder mit den Zwängen eines PM-Workflow, es lebe die Freiheit des (guten) Frameworks!