Mehr Erfolg mit situativem Projektmanagement

Seit langem bin ich leidenschaftlicher Blogleser beim Projekt Magazin, und ganz besonders hat mich ein Beitrag von Dr. Andreas Tremel zu dem Thema angesprochen: "Best Practices – oder: Der unstillbare Wunsch nach Schema F". Wie Dr. Tremel bin nun auch ich der Meinung, dass es dieses Konzept im Projektmanagement auf-grund der Natur von Projekten als einmalige Unterfangen nicht geben kann. Da ich hierzu selbst in den letzten Jahren einiges an Forschung betrieben habe, möchte ich zu dem Thema etwas aus meiner Sicht beitragen.

 

Mehr Erfolg mit situativem Projektmanagement

Seit langem bin ich leidenschaftlicher Blogleser beim Projekt Magazin, und ganz besonders hat mich ein Beitrag von Dr. Andreas Tremel zu dem Thema angesprochen: "Best Practices – oder: Der unstillbare Wunsch nach Schema F". Wie Dr. Tremel bin nun auch ich der Meinung, dass es dieses Konzept im Projektmanagement auf-grund der Natur von Projekten als einmalige Unterfangen nicht geben kann. Da ich hierzu selbst in den letzten Jahren einiges an Forschung betrieben habe, möchte ich zu dem Thema etwas aus meiner Sicht beitragen.

 

Seit langem bin ich leidenschaftlicher Blogleser beim Projekt Magazin, und ganz besonders hat mich ein Beitrag von Dr. Andreas Tremel zu dem Thema angesprochen: "Best Practices – oder: Der unstillbare Wunsch nach Schema F". Wie Dr. Tremel bin nun auch ich der Meinung, dass es dieses Konzept im Projektmanagement aufgrund der Natur von Projekten als einmalige Unterfangen nicht geben kann. Da ich hierzu selbst in den letzten Jahren einiges an Forschung betrieben habe, möchte ich zu dem Thema etwas aus meiner Sicht beitragen.

Kurz zur Erläuterung: Unter dem Begriff "Best Practice" versteht man meiner Erfahrung nach eine Methode, die allen Alternativen gegenüber als überlegen angesehen wird. Dies deshalb, weil man der Ansicht ist, mit ihr die besten Ergebnisse erzielen zu können, oder weil sie mit der Zeit zum Standard geworden ist – ungeachtet dessen, wie angemessen sie einer bestimmten Situation wirklich ist.

Gibt es Best Practices?

Meine Ausführungen basieren auf Daten, die ich im Rahmen einer Forschungsarbeit zwischen April und August 2015 gesammelt habe. In diesem Rahmen habe ich u.a. 189 Projektmanager aus aller Welt gefragt: "Gibt es Best Practices?" Das Ergebnis: Fast zwei Drittel der Befragten glaubten an die Existenz von Best Practices im Projektmanagement. Weniger als ein Viertel hat das Konzept als solches für diese Disziplin abgelehnt. Die beiden kleineren Gruppen, die sich keiner Meinung direkt angeschlossen haben, haben in zusätzlichen Kommentaren erkennen lassen, dass sie es im Prinzip eher befürworten. (siehe auch Bild 1)

Gibt es Best Practices im Projektmanagement?

Bild 1: Antworten auf die Frage, ob es "Best Practices" im Projektmanagement gibt. Die drei Antwortmöglichkeiten waren vorgegeben.
Bild vergrößern

Skeptisches Europa

Es scheint also durchaus viele Menschen zu geben, die sich auf bewährte Methoden im Projektmanagement verlassen (möchten). Als nächstes interessierte mich, ob das Vertrauen in die Existenz von "Best Practices" in den verschiedenen Erdteilen unterschiedlich stark verbreitet ist. Tatsächlich zeigten sich deutliche kulturelle Unterschiede: Am skeptischsten sind wir Europäer (siehe Bild 2).

Regionale Verteilung

Bild 2: Regionale Verteilung der Akzeptanz des Konzepts von Best Practices.
Bild vergrößern

Zugegeben – der Gedanke an "Best Practices" im Projektmanagement ist verlockend. Die Mehrheit weltweit scheint daran zu glauben, auch weil viele das Konzept vehement vertreten. Man könnte sie als "Spin Doctors" bezeichnen: In einem Wahlkampf haben diese die Aufgabe, den Blick der Wähler auf die Stärken eines Kandidaten oder einer Kandidatin zu verengen, um von dessen oder deren Schwächen abzulenken. Beim Konkurrenten/der Konkurrentin sollen sie natürlich das Gegenteil bewirken. Da ein Wahlkampf ein "zeitlich temporäres Unterfangen, um ein einmaliges Ergebnis hervorzubringen" ist (nach PMBOK® Guide, 5. Ausgabe), ist er immer auch ein Projekt.

"One Size Fits all"?

Im Projektmanagement erzählen uns die Spin Doctors für Best Practices nun, wir müssten eine "Best Practice" erlernen und dann für alle Projekte in der Organisation anwenden. Über eine Projekttypologie verfügen sie nicht. Dabei gehören "Schema F"-Ansätze definitiv zu den häufigen Gründen, warum Projekte in Schwierigkeiten geraten. Immer wieder hört man so heute in Unternehmen Aussagen wie "Wir machen jetzt alle Projekte nach Methodik XYZ", oder "Unser PMO hat jetzt unser ganzes Projektmanagement auf agile Praktiken umgestellt."

Schnell stellt sich heraus, dass einige Projekte von solchen Standardisierungen profitieren – andere jedoch darunter leiden und zum Scheitern verdammt sind. Letzteres trifft auf die Mehrheit zu, unabhängig von der gewählten Methodik. Das ist der Preis der Einmaligkeit jedes Projekts, mit der sich viele Organisationen immer wieder schwertun.

Projektmanager machen also in ihrem Alltag immer wieder die Erfahrung, dass sich konkrete Projektsituationen sehr voneinander unterscheiden und spüren manchmal instinktiv, dass ein vorgegebener Ansatz nicht passen könnte. Daher empfehle ich, dem Konzept der unhinterfragten Übernahme bewährter Methoden den Ansatz von situativem Projektmanagement ("SitPM") entgegenzustellen (dessen Bedeutung scheint besonders in Europa erkannt zu werden, siehe Bild 2).

Situatives Projektmanagement ist lernbar

Wenn wir diesem Gedanken folgen und uns von Best Practices ein Stück weit distanzieren wollen, brauchen wir unbedingt eine Typologie und außerdem konkrete Hilfestellungen, welche Vorgehensweisen sich für welche Projekttypen empfehlen und was es dabei zu beachten gilt. Im Hinblick auf Projekttypologien ergeben sich aus meiner Sicht einige Möglichkeiten zur Einordnung. Folgende (unvollständige) Lite soll Ihnen einen Eindruck vermitteln:

  • Kundenprojekte <-> interne Projekte
  • Projekte mit langfristigem Planungshorizont <-> Projekte mit kurzfristigem Planungshorizont (agile Projekte)
  • Mark-1-Projekte <-> Mark-n-Projekte
  • Greenfield-Projekte <-> Brownfield-Projekte
  • Silo-Projekte <-> eingebundene Projekte
  • Projekte mit großen Auswirkungen <-> Projekte mit geringen Auswirkungen

Nach der Zuordnung eines Projekts zu einem Typus sollte ein Projektmanager in der Lage sein, jederzeit die nicht nur dazu, sondern auch zu konkreten, unterschiedlichen Situationen im Projekt am besten passenden Projektmanagement-Methoden zu wählen.

Die dafür notwendige situative Intelligenz lässt sich in kontinuierlicher Lernarbeit entwickeln, in Anlehnung unter anderem an Ansätze aus Theorien zur situativen Führung und nach deren Anpassung an die täglichen Gegebenheiten im Projektmanagement – und zusätzlich zur Theorie natürlich mit dem Sammeln von Erfahrung in der Praxis. Ein so geschulter Projektmanager verfügt über das Wissen und das Selbstvertrauen, um das angeblich Bewährte in Frage zu stellen, um mehr Projekten zum Erfolg zu verhelfen.

Unsere Abos: für jeden Bedarf das passende Abonnement

 

Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle,
die in Projekten arbeiten. Ihre Vorteile auf einen Blick

Image
Wissensplattform

Zugriff auf die größte deutschsprachige Wissensplattform
für Projektmanagement  (>1.800 Artikeln und Tipps)

Image
Praxisbezogene Beiträge

Praxisbezogene Beiträge
Fachautoren schreiben aus der Praxis für die Praxis.

Image
Tools

Werkzeuge (Tools)
z.B. Checklisten und Vorlagen, Methoden mit Schritt-für-Schritt-Anleitung.

Image
Glossar

Umfangreiches Projektmanagement-Glossar
über 1.000 Fachbegriffen (deutsch/englisch)

Image
Blogbeiträge

Blogbeiträge, Themenspecials, Bücher, Stellenangebote etc.
rund um das Thema Projektmanagement

Alle Kommentare (5)

Georg
Angermeier
Dr.

Hallo Herr Lehmann, als ich Ihren pointierten Beitrag las, dachte ich als erstes: Wer um Gottes Willen behauptet denn, dass eine "Best Practice" ein starrer, nicht anpassbarer Prozess sei? Nachdem ich zusätzlich den von Ihnen zitierten Beitrag von Dr. Andreas Tremel gelesen hatte, formte sich langsam ein Bild: Es geht nicht um die echten Best Practices, die es selbstverständlich gibt (dazu unten mehr), sondern um einen uralten Traum, den vor allem Top-Manager haben: Projektmanagement als "Wunderpille", die einmal geschluckt (bzw. in drei Tagen mal schnell geschult) wird und dann alles perfekt läuft. Aber der Reihe nach. "Best Practice" heißt ganz einfach "empirisch", also "aus der Erfahrung" heraus. In Ermangelung einer perfekten, theoretischen Lösung also die evolutionäre Herangehensweise nach Trial and Error: Was ist besser – einfach draufloslegen oder zuerst planen? Auf diese Weise kommt die allgemein anerkannte Best Practice "Zuerst planen, dann handeln!" zustande. Dies ist ein Erfahrungswert, der ausnahmslos und immer stimmt. Dennoch wollen ihn viele nicht wahrhaben, was ich täglich erlebe. Keinesfalls Best Practice hingegen ist: "One size fits all". Kein einziger mir bekannter, vernünftiger Mensch und keine einzige Richtlinie oder Norm sagt das. Ganz explizit ist hier z.B. PRINCE2®, das es explizit verbietet(!), das Manual wörtlich anzuwenden. Das Anpassen an das Projekt und seine Umgebung wird dort sogar zum unverzichtbaren Prinzip erhoben. Die Gefahr, die Sie und Tremel beschreiben, ist natürlich real – und ich möchte behaupten, typisch deutsch. Diese Gefahr kommt aus der Eigenschaft, für die wir international berühmt und berüchtigt sind: Unsere Gründlichkeit. Auf meinen Trainings werde ich einerseits beständig gefragt: Gibt es dafür eine Vorlage? Und andererseits kommt das Feedback: Das ist doch ein viel zu großer Verwaltungsaufwand! Dass man in ein "Formular" nur das reinschreibt, was in der konkreten Situation tatsächlich sinnvoll und notwendig ist, scheint der deutschen Denkweise kaum zu vermitteln sein. Ist nun "situatives Projektmanagement", wie Sie es nennen, ein besserer Ansatz? Ich sehe in Ihrer Argumentation eine große Gefahr. Einerseits schreiben Sie nämlich, dass Sie sich "von Best Practices ein Stück weit distanzieren wollen" und andererseits fordern Sie, dass Projektmanager in einem Mix aus "Theorien zur situativen Führung" und "dem Sammeln von Erfahrung in der Praxis" erlernen, welche Methoden sie wie für ihr Projekt einsetzen. Wer dies so liest, könnte meinen, dass Projektmanager eine gute theoretische Ausbildung benötigen und anschließend ihre ganz individuellen Erfahrungen sammeln sollen. Auch dies halte ich für einen typisch deutschen Ansatz, für den wir ebenfalls international berühmt und berüchtigt sind: Den Drang zum Philosophischen und Theoretischen. Sowohl die Gründlichkeit also auch die Grundsätzlichkeit haben ihre Stärken. Aber wir sollten das Rad nicht immer neu erfinden, zumindest nicht bei einer unterstützenden Disziplin wie dem Projektmanagement. Wir sollten die Erfahrungen vieler tausender Projektmanager nicht einfach in den Wind schlagen. Aber auch wirklich genau wahrnehmen: Best Practice ist es eindeutig, Methoden, Nomenklatur, Vorlagen usw. auf Projekt, Branche und Umfeld anzupassen. Ausnahmslos. Immer. In jedem Projekt. Meine Literaturempfehlung: "Integrating PRINCE2®" von Alan Ferguson. Die dort beschriebenen Vorgehensweisen zum Anpassen und Integrieren von PRINCE2 lassen sich genauso auf den PMBOK® Guide oder den PM3 anwenden. Herzliche Grüße Georg Angermeier

 

Guest

MANGOLD oder SPINAT? KUNDENPROJEKT ODER INTERNES PROJEKT? Hallo Herr Dr. Angermeier, ich weiß ja, dass Sie des Englischen sehr mächtig sind, und "Best practice" heißt halt nun mal "Beste Praktik". Man kommt nicht darum, dass der Begriff einfach für sich spricht. Sie dürfen gerne etwas hineininterpretieren, aber der Begriff ist erstmal so da, wie er ist: Wer den Best Practice hat, muss nicht mehr lernen, und wer ihn übrigens auch als Trainer vertritt, muss die Richtigkeit seiner Aussagen nicht immer wieder aufs Neue überprüfen. Besser als Best gibt es ja nicht. Ich höre öfters Aussagen wie: "Unser PMO hat agile Methoden als Best practice identifiziert und stellt gerade alle Projekte im Unternehmen darauf um." Nach Untersuchungen, die ich dazu vor einer Weile gemacht habe, ist das wohl eine gute Entscheidung für 1/3 der Projekte. Das heißt dann aber auch, dass das eine schlechte Entscheidung für viele andere ist. Oder eine Vertreterin einer britischen Trainingsfirma aus dem engeren Prince2-Umfeld, für die ich einst gearbeitet habe, und die ich auf falsche Aussagen in deren Trainingsmaterialien hingewiesen habe: "Oliver, don't touch it. This is a Best Practice. It is proven and it works, don't change anything". Es gibt übrigens viele Übereinstimmungen in den Mindsets von Brexit und Prince2 bis hin zur Frage, wem die beiden eigentlich gehören. Ich habe dazu auch eine Buchempfehlung für Sie: "The Halo Effect: ... and the Eight Other Business Delusions That Deceive Managers" von Phil Rosenzweig, der vor der leichtfertigen Übertragung von Erfolgsrezepten warnt. Was an einer Stelle zum Erfolg führt kann an einer anderen Stelle scheitern. Ein starkes Buch eines messerscharfen Denkers. Und wenn sie das dann ins Projektmanagement übersetzt haben möchten, das finden Sie dann in meinem Buch "Situational Project Management: The Dynamics of Success and Failure". Anpassung ist nicht dasselbe wie auswählen. Klar kann ich beim Nachkochen eines Rezepts, das Mangold verlangt, wenn mir der fehlt, Spinat oder Grünkohl verwenden. Wenn ich aber für Kinder kochen, die das alles nicht essen, dann ist das halt nicht wirklich situativ. Situatives Projektmanagement (SitPM) erschöpft sich nicht im Anpassen vorgefertigter Methoden. Es lehnt diese Methoden übrigens auch nicht grundsätzlich ab, sondern fordert auf zu hinterfragen, ob die Methode in der gegebenen Situation passt oder nicht, gerne auch mit Anpassungen. SitPM sagt, man soll sich sein Projekt und insbesondere auch seine Projektsituation genau anschauen und dann überlegen, wie man damit umgeht. Eigentlich ist das etwas ganz Triviales und Selbstverständliches, und ich verstehe gar nicht, warum ich mich damit in den Widerspruch zu Literatur, Universitäten, Trainerkollegen etc. stelle. Praktiker geben mir im Allgemeinen sofort recht. SitPM ist nicht einfach, weil einen das auch zwingt, sich methodisch breit aufzustellen und zu verstehen, welche Methodik im gegebenen Moment erfolgversprechend ist, und welche man besser nicht verwendet. Man muss also viel dazulernen. Schmalspur-Projektmanager werden die zunehmend steigenden Anforderungen nicht bewältigen. Ich erlebe im Moment auch selbst, wie das Strukturieren von Projekten und die Erfassung dieser Struktur in einer Typologie zu völlig neuen Erkenntnissen führt: Es gibt viel Literatur zu Projektmanagement, aber nichts speziell zu Kundenprojekten (im Gegensatz zu internen Projekten), zumindest habe ich weltweit kein einziges Buch dazu gefunden. Also mache ich das nun selbst: "Bringing Money Home With Projects". Der fokussierte Blick, den mir SitPM ermöglicht, führt mich dabei zu einer ganzen Menge neuer und ganz spezifischer Beobachtungen. Wie funktionieren Pricing und Costing im Kundenprojekt? Wie funktionieren komplexe und dynamische Lieferantennetzwerke? Die beobachteten Dinge sind schon immer da, nur keiner hat sich bisher systematisch mit ihnen befasst. Wenn Sie überlegen, dass Kundenprojekte etwa die Hälfte aller Projekte ausmachen und dass wir über einen riesigen Markt sprechen, wenn wir zusätzlich noch betrachten, welche enormen Risiken darin für alle Beteiligten lauern, dann ist diese Vernachlässigung dieses großen Zweigs unserer Disziplin erstaunlich. Es gibt dazu bisher auch keine Seminare, die Unversitäten ignorieren das Thema, naja und in den Fachmedien (sorry) habe ich es bisher auch nicht herausgearbeitet gesehen. Und in Prince2 taucht die Frage auch nicht auf, wie man mit Projekten Geld verdient. Erklärbar wird das für mich nur dadurch, dass der Ruf nach möglichst universellen Best Practices mit der präzisen Fragestellung eines fokussierten Experten schwer vereinbar ist, und der erstere war bisher der Lautere. Liebe Grüße, Oliver F. Lehmann PS: Der PMBOK Guide spricht mehrfach von "Good practice for most projects most of the time." Damit kann ich mich anfreunden.

 

Georg
Angermeier
Dr.

Hallo Herr Lehmann, danke für Ihre so ausführliche und leidenschaftliche Antwort auf meinen Kommentar! In ganz vielen Punkten gebe ich Ihnen vollumfänglich Recht! Ja, klar, jedes Projekt ist unterschiedlich und für jedes Projekt und jede spezifische Situation muss der Projektmanager entscheiden, welches Vorgehen angemessen ist. In anderen zentralen Punkten bin ich aber überaus erstaunt: PRINCE2® betrachtet primär Kundenprojekte. Es ist sogar das einzige PM-System, das einen expliziten Business Case obligatorisch einfordert. Mit anderen Worten: Das PRINCE2-Manual ist kümmert sich eigentlich nur darum, wie man mit Projekten möglichst viel Geld macht. Diese gnadenlose Orientierung am Business Case ist ja sogar ein häufig gehörter Kritikpunkt. Wo sonst gibt es einen Nutzenrevisionsplan? Dagegen bietet PRINCE2 so gut wie keine Methoden an (lediglich die produktbasierte Planung und die Qualitätsprüfungstechnik). Es verweist beständig auf die großen Methodensammlungen, die es bereits gibt und zu denen z.B. der PMBOK® Guide zählt. Und fordert den Projektmanager auf, die angemessenen und situativ richtigen Methoden auszuwählen und für sein Projekt einzusetzen. Es mag für Sie jetzt erstaunlich klingen, aber das, was Sie über SitPM schreiben und wie Sie es beschreiben, könnte wortwörtlich im PRINCE2-Manual stehen, z.T. tut es dies sogar! Das von Ihnen geschilderte Erlebnis kann ich natürlich jetzt nicht analysieren. Aber so wie es deutsche Eigenheiten gibt, gibt es natürlich auch britische. Und zu denen zählt eine unwahrscheinlich große Gläubigkeit an Standardverfahren, die man niemals auch nur in Frage stellt. Wer schon mal in einem englischen Lokal versucht hat, an einem Standardgericht etwas zu ändern, kennt dies. Das hat aber weder mit PRINCE2 zu tun, das nicht umsonst so großen Wert auf das Tailoring und das Integrating legt. Noch hat es mit Best Practice zu tun. Denn das englische Wort "Practice" bedeutet genauso wie "Praktik" auch "Übung" – eine gänzlich andere Konnotation als im Deutschen. Und mit der beständigen Übung ist untrennbar das PRINCE2-Prinzip des Lernens aus Erfahrung verbunden. "Best Practice" darf nur verstanden werden als der kontinuierliche, empirische Verbesserungsprozess für Management! Das ist nun nicht meine Erfindung oder Interpretation, sondern die Herkunft des Begriffs "Best Practice" aus dem Benchmarking: Sobald jemand den Beweis einer höheren Leistungsfähigkeit erbringt, ist sein Vorgehen eben die neue "Best Practice". "Best Practice" ist dabei keinesfalls "Best Solution" oder "State of the Art" – das wäre eine üble Fehlinterpretation, die, wie Sie eindrucksvoll schildern, leider weit verbreitet ist. Aber dagegen gehen wir ja gemeinsam vor – ich bei meinen Trainings und Sie mit dem Hinterfragen von Best Practices und der Präsentation von SitPM! Herzliche Grüße Georg Angermeier

 

Guest

Hallo Herr Dr. Angermeier, vielen Dank zurück für die ebenfalls lange Antwort. Ich mache mal so weiter. Das Thema ist ja spannend. Mein Ziel ist natürlich nicht Prince2 niederzumachen, auch wenn ich es gerne als Beispiel für die Verwendung der Idee der "Best Practices" verwende. Einfach, weil sonst niemand den Begriff so notorisch verwendet. Mir geht es darum, den situativen Aspekt unserer Disziplin Projektmanagement besser herauszuarbeiten und Verständnis zu entwickeln, wie Projektmanager(innen) damit umgehen müssen. Ich bin ja vorrangig Trainer und kein Forscher, ich beklage aber einen massiven Mangel an relevanter Forschung, und deswegen mache ich das selbst. Übrigens bin ich auch Lernender, und ich hoffe, dass das Lernen nie aufhören wird. Im Kontext von Projektmanagement wird "Best Practice" definitiv nicht als beste Übung verstanden, so wie meine kleine Tochter an der Gitarre übt, damit wir einmal am Lagerfeuer „Hey Jude“ zusammen singen können. Der Begriff steht für eine beste Praktik, eine vorschreibende Norm, die vor allem Arbeitsabläufe als universell überlegen definiert. Ein Kochbuch. Ein Anfänger als Koch braucht ein Kochbuch, das ihm den Einstieg erleichtert. Ein Vollprofi schreibt eher selbst sein eigenes für sich und vielleicht auch für andere. Das gleiche gilt für Projektmanager. Bleiben wir dennoch kurz bei Prince2: Axelos, der Eigentümer der Methodik, verspricht, dass Prince2 erfolgreich für „alle Projekttypen“ angewandt werden kann*. Entgegen Ihrer Aussage gibt es für diese Behauptung keinerlei empirischen Beleg, und schlimmer noch, Axelos verfügt nicht mal über eine Typologie von Projekten. Die Frage „welche Projekttypen gibt es denn?“ bleibt unbeantwortet. Die Aussage ist damit inhaltslos. „Best practice“ zu versprechen würde weiter voraussetzen, dass man einmal Vergleiche mit anderen Praktiken angestellt und kommuniziert hat, so wie man das schnellste Auto, das profitabelste Unternehmen etc. durch einen Vergleichsprozess findet. Das hat man nicht gemacht. Es setzt auch voraus, dass man Belege vorlegt, die den Erfolg einer großen Anzahl nach Best Practice geführter Projekte kausal auf diesen Best Practice zurückführen. Hat man auch nicht gemacht. In welchem Sinne „Best“ dann als das Beste zu verstehen ist, bleibt weiter offen. Schafft man damit die zufriedensten Benutzer, die billigsten Betriebsprozesse, den spannungsärmsten Kompromiss zwischen widersprüchlichen Anforderungen oder den glücklichsten Chef? Keine Ahnung, es wird einem nicht gesagt. Ich denke, es gibt im Projektmanagement viel heiße Luft. „Best Practices“ gehören dazu. Zu Ihrem Hinweis Benchmarking: Benchmarking lebt davon, das Nicht-situative zu betrachten. Projekte oder Projektportfolios miteinander gegen Kriterien zu vergleichen, die nicht aus spezifischen Situationen heraus entstehen, sondern schon vorher festgelegt sind, und dann den jeweils „Klassenbesten“ zu jedem Kriterium zu finden. Benchmarking ist per Definition nicht situativ. Es passt hervorragend in ein operatives Umfeld, aber nur bedingt zu Projekten**. Zu Ihrem Hinweis zu Business Cases: Ein Business Case ist ein typisches Element interner Projekte. Der Business Case ist eine Entscheidungsvorlage für die Projektauswahl bei internen Projekten, die ja erstmal nur Cost-Center sind, ob sich die anstehende Investition in der Zukunft rechnen wird. Übrigens gibt es viele Pflichtprojekte im internen Bereich, die keinen Business Case haben, sondern aufgrund eines Gesetzes oder sonst einer Verpflichtung, die man erfüllen muss, durchgeführt werden. Denken Sie an Projekte zum Emissionsschutz oder zu Basel 2. Dann gibt es Projekte im Bereich Grundlagenforschung, die per Definition erstmal nur der reinen Neugier dienen. Sobald sie einen Business Case haben, werden sie Anwendungsforschung. Kundenprojekte haben selten einen Business Case, sie sind Profit-Center und haben eine Profitabilitätsrechnung. Es gibt gelegentlich Kundenprojekte, die kein Geld verdienen müssen, bekannt als „strategische Projekte“, z.B. um einen Kunden zu binden. Gutgehende Unternehmen, die Kundenprojekte durchführen, können sich maximal zehn Prozent solcher Projekte leisten. Schlecht gehende Unternehmen können sich das gar nicht leisten. Diese „strategischen“ Kundenprojekte, selten wie sie sind, haben tatsächlich einen Business Case, aber sie sind die Ausnahme, nicht die Regel. Ist es denn schlimm, wenn mit dem Begriff „Best Practice“ ein Versprechen abgegeben wird, das gar nicht einlösbar ist? Ich denke ja. Projektmanager brauchen situative Intelligenz: Die Praktik, die in einer Projektsituation richtig war, mag in einer anderen scheitern, und Projektmanager müssen sich eine Palette verschiedener Methoden, Herangehensweisen, Verhaltensformen etc. zulegen um den sich laufenden Änderungen der Anforderungen zu begegnen. Der Begriff „Best Practice“ suggeriert, man könne ein Projekt stattdessen mit einem Auge im Kochbuch und dem zweiten am Herd leiten. Damit werden Schmalspur-Erwartungen an Projektmanager erzeugt, die diese nicht erfüllen können, und besser auch nicht erfüllen sollen. Ein(e) Projektmanager(in) muss sein/ihr Handeln immer wieder aufs Neue im Lichte der jeweiligen Situation prüfen und eventuell ändern. Oder Unterstützung durch Menschen suchen, die eine jeweils passende Praktik besser beherrschen, und die Aufgabe mit diesen Personen gemeinsam erledigen oder an sie delegieren. Das bringt uns am Ende erfolgreichere Projekte. Liebe Grüße, Oliver F. Lehmann ________ *: Z.B. in https://www.axelos.com/Corporate/media/Files/Brochures/PRINCE2_Product_Brochure_Conference_Version_v1.pdf#page=3, Seite 3 **: Ich empfehle dazu auch den Artikel „‘Benchmarking‘...Good In Boot-making and Not So Good in a Competitive Business Environment“ (http://www.armg-usa.com/Benchmarking-Article.html) von Abe Walking-Bear Sanchez und Eugenè Jouber.

 

Georg
Angermeier
Dr.

Lieber Herr Lehmann, wie wir gerade beide feststellen, ist es eine sehr umfangreiche Thematik, die wir hier diskutieren und die in diesem Rahmen wohl nur schwer zu einer Synthese gelangen kann. Beständig pendele ich beim Lesen Ihrer Ausführungen zwischen „Vollkommen richtig!“ und „Sorry, da liegt ein Missverständnis vor!“. So empfinde auch ich nur wenig Begeisterung für die Marketing-Aussagen von AXELOS – das von Ihnen zitierte Dokument ist eine Werbebroschüre und nichts weiter. Das betrifft aber nicht nur AXELOS, sondern alle Anbieter von Produkten und Dienstleistungen im PM-Markt. Der Grund dahinter ist sehr einfach: Die Kunden wollen unbedingt die einfache, sofort umsetzbare und problemlos funktionierende Lösung. Nur wer als Anbieter diese Klaviatur bedient, hat eine Chance, die notwendigen Umsatzzahlen zu generieren. Auf diese Weise entsteht dann auch der fatale Fehleindruck, dass "Best Practices" vom Himmel gefallene, unveränderliche Gesetze seien. Hiermit erlaube ich mir die Aussage, die ich auch in meinen Seminaren gerne verwende, um die Teilnehmer zum eigenständigen Denken zu motivieren: "Best Practices can still be sh..!" Gerne dürfen Sie mich mit dieser Aussage zitieren. Die Frage ist nun, wie diese "Best Practices" zustande kommen. Für PRINCE2 (und die damit verbundenen Richtlinien) gibt es weltweit die Best Practice User Groups, die es sich unter anderem zur Aufgabe gemacht haben, eben diese Best Practices auf den Prüfstand zu stellen und zu einem kontinuierlichen Verbesserungsprozess beizutragen. In der Tat: Jeder kann einen Änderungsantrag bei AXELOS stellen. Das ist kein klassisches Benchmarking, kommt aber der Idee doch recht nahe. Wie ist es nun mit der Aussage, ob "Best Practices" für alles und jedes funktionieren? Selbstverständlich tun sie das nicht! Eine Best Practice muss immer auf den Anwendungsfall spezifiziert sein. Und im Fall von PRINCE2 ist es das projektorientierte Arbeiten. Nehmen wir nun an – rein hypothetisch natürlich – dass die Aussage "PRINCE2 passt für alle Projekte" korrekt ist. Die einzig mögliche Schlussfolgerung ist dann: PRINCE2 ist sehr allgemein und liefert keine Kochrezepte für spezielle Situationen! Und genau so ist es: Wer Projektmanagement nach PRINCE2 lernt, hat einen hervorragenden, allgemeingültigen Rahmen – aber er muss ihn noch situativ mit Methoden, "Rezepten" und wer will – branchenspezifischen Best Practices auffüllen. Nein, der Vergleich mit einem Kochbuch passt hier kein bisschen! Ergänzend zwei kleine Anmerkungen: 1. Als Basis sollten wir das PRINCE2-Manual verwenden und nicht Werbematerial. Im Manual lesen wir u.a. explizit die Differenzierung zwischen internen und externen Projekten – nicht in wünschenswerter Ausführlichkeit, aber doch klar und eindeutig. 2. Beim Business Case (BC) sind wir doch recht unterschiedlicher Meinung. Nachdem PRINCE2 das einzige PM-System ist, das einen BC fordert, denke ich, dass man auch dessen Definition anwenden sollte: Ein Business Case ist die geschäftliche Rechtfertigung eines Projekts. Und dies trifft ausnahmslos auf alle Projekte zu, z.B.: "Wenn wir Basel II nicht erfüllen, bedeutet dies das Ende des Unternehmens." Oder: "Die angestrebte Innovation unterstützt die Strategie als Technologieführer." Herzliche Grüße Georg Angermeier