29
Jan 2016
Meilenstein – Der Projektmanagement-Blog

Dem Projektmanager den Prozess machen

Voltaire, erklärter Ungläubiger, hatte auf seinem Schreibtisch immer eine Bibel liegen. "Wenn man einen Prozess führt," sagte er, "muss man den Schriftsatz der Gegenpartei stets zur Hand haben!" (Friedrich Wendel)

Anzeige

Zwei Dinge finde ich hier bemerkenswert. Erstens die Sache mit der Gegnerschaft (die man, wenn’s nach mir geht, nicht mit Feindschaft gleichsetzen sollte). Zweitens ein potentielles Kommunikationsproblem; würde man einem Prozessmanager - also einem Arbeitsmethodiker – dieses Statement vorlegen, dann wäre seine Stellungnahme wohl: 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!

Bisher gibt es 2 Kommentare
Herr Plagge, als Berater kennen Sie sicher mehr Berichtsvorlagen und -gepflogenheiten als ich in meiner Firma. Ich kann aus Projektleiter-Sicht nachvollziehen, dass Sie schreiben:
"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."
Wenn bei uns in einem Bereich 40+x Projekte pro Jahr mehr oder minder parallel laufen, dann verstehe ich aber auch, dass Kommunikationskosten von der Leser-Seite auf die Ersteller-Seite verlagert werden, indem man eine Berichtsvorlage festlegt. In der Summe sollte es natürlich sparen, aber der einzelne Projektleiter muss die extra Meile gehen. Was nützt es mir, wenn mein super effizienter und projektspezifischer Bericht vom Sponsor oder Chef falsch verstanden wird oder ausführlich erläutert werden muss?
Parallel dazu ist Lernen aus Erfahrung und Anpassung inklusive Vereinfachung eine wichtige Forderung, die in die Kostenplanung der Prozess-Hüter einfließen sollte.
Aber vielleicht habe ich als Leser Ihre Hauptintension des Artikels missverstanden?
vor 41 Wochen 2 Tagen Gunnar H. Krause
Danke für Ihren Kommentar, Herr Krause.
Sie greifen einen kleinen Teil auf, das Reporting, und natürlich verstehe ich Ihre Argumente vollkommen. Aber ich sehe das ganze aus Sicht des Gesamtunternehmens, und Effizienz in den Prozessen sollte in Summe für das Gesamtunternehmen gelten. Das heißt, das die Summe aller Arbeiten für den Manager und die 40 PMs den minimalen Gesamtaufwand erfordern sollte. Und da ist zweifelhaft, ob es sinnvoll ist, dass "die 40 PMs die 40 Extrameilen gehen sollten".
Das Reporting ist generell ein heikles Thema. Ich möchte mich zahlenmäßig nicht festlegen, aber mein Eindruck ist, dass in mittleren und großen Unternehmen über 90% des Reportings reiner Selbstzweck sind. "Ich muss doch informiert sein, was läuft!" Nein: Reporting hat den einzigen Zweck, Manager zu befähigen, bewusste Entscheidungen zu treffen (natürlich auch einmal die Entscheidung, nicht einzugreifen). Was häufig der Fall ist (und gerade in den letzten Wochen habe ich es wieder beispielhaft erlebt), dass PMs nicht darüber informiert werden, w a r u m ein Report ein bestimmtes Format und bestimmte Inhalte haben soll, und dass Sie für ihren Bericht kein Feedback bekommen. Und dann zweifeln sie zu Recht am Sinn des Ganzen.
Ich stehe übrigens nicht generell auf der Seite der PMs: die üblichen Jour fixes, zu denen der PM das ganze Team zusammenholt und nach den Tagesordnungspunkten die Probleme jedes Teammitglieds abfragt und diskutiert, sehe ich als große Zeitverschwendung für die Firma: sehr effizient für den PM, aber es reden immer nur zwei, und zehn hören sich etwas an, was sie zu Recht wenig interessiert.
Meine Intention zu diesem Beitrag war insgesamt die Aufforderung, Prozesse, die Gefahr laufen, mit ihrer Verabschiedung zu "Leichen zu erstarren", in jedem Einzelfall mit Leben zu erfüllen zum Wohle des gesamten Unternehmens. Und wo ich das in der Praxis beobachte, gewinne ich den Eindruck einer gelebten Projektkultur.
Freundliche Grüße
WP
vor 41 Wochen 1 Tag Walter Plagge
Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare aus und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.
Kommentar verfassen
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bitte geben Sie Ihren Namen an: *
Tech Link