Projektmanagement = Management

Ich vertrete schon seit längerer Zeit folgender These:

„Richtiges und gutes Projektmanagement unterscheidet sich im Kern nicht von richtigem und gutem Management.“

Diese Aussage möchte ich folgendermaßen erläutern:

  • Projekt = soziales System: Projekte bestehen aus Menschen, die ein gemeinsames Ziel verfolgen. (Projekt = soziales System)
  • Projektmanagement = Versuch eines funktionierenden sozialen Systems: Die Aufgabe eines Projektleiters ist es, den Rahmen für eine möglichst gelingende Zusammenarbeit des Teams zu schaffen.
  • Projektmanagement = Management: Es geht also um die Gestaltung, Steuerung und Lenkung eines sozialen Systems. Darum geht es auch bei der Erfüllung genereller Führungs- und Managementaufgaben.

Projekt- vs. Linienaufgaben

Betrachten wir das Thema noch anhand der Projektkriterien. Denn projektwürdig ist eine Aufgabenstellung dann, wenn sie komplex und neuartig ist und nur in Teamarbeit gelöst werden kann. Zudem sollten für Projekte klare inhaltliche, budgetäre und zeitliche Ziele formuliert werden. Wo könnten wesentliche Unterschiede zwischen dem Management von Projektaufgaben und dem Management von Prozessen, Routine- oder Linienaufgaben liegen?

  • Komplexität: Ich behaupte, dass die Fähigkeiten im Umgang mit Komplexität im Projektmanagement und im Management gleichermaßen hoch sein müssen.
  • Neuartigkeit: Hier könnte ein wesentliches Unterscheidungsmerkmal liegen, denn Routine- und Linienaufgaben sind in der Tat eher stabil bzw. ähnlich.
  • Teamarbeit: Zusammenarbeit und Kollaboration von Menschen ist ebenfalls „in beiden Welten“ nötig. Hier könnte ein relevanter Unterschied in der Tatsache bestehen, dass sich Projektorganisationen und -teams häufig völlig neu zusammen setzen bzw. deren Zusammensetzung häufig wechselt.
  • Inhaltliche, budgetäre und zeitliche Ziele:  Durch die Vorgaben und Restriktionen in Projekten können sich besondere Drucksituationen ergeben. Einen wirklich wesentlichen Unterschied zu „Nicht-Projektaufgaben“ sehe ich hier aber nicht.

Zwischenfazit: Projektmanagement erfordert eventuell ein höheres Maß an Fähigkeiten im Umgang mit Instabilität. Generelle Führungs- und Managementaufgaben hingegen erfolgen in Umwelten, die stärker von Stabilität geprägt sind. Klar ist aber: Auch in diesem Punkt gibt es keine ganz klare Abgrenzung.

Management von Stabilität und Instabilität

Nun komme ich langsam zum Kern meiner Argumentation. Menschen, die heutzutage Führungs- und Managementaufgaben zu erfüllen haben, benötigen Fähigkeiten im Umgang mit Instabilität (= Wandel, Innovation, Veränderung, Neuartigkeit…) wie auch im Umgang mit Stabilität (= Wertschöpfung, Leistung, Effizienz, Aufgabenerfüllung…). BEIDES ist sowohl im Projektmanagement als auch im Management notwendig.

Niemand könnte diesen Aspekt treffender auf den Punkt bringen als der geniale Peter Kruse:

Fazit

Der Grund, warum ich dieses Thema immer und immer wieder „aufwärme“ (im Blog und auch anderswo), ist, dass ich im Projektmanagement viel zu viel Methodengläubigkeit orte und viel zu wenig gesunde Auseinandersetzung mit grundlegenden Prinzipien, Herausforderungen und Erkenntnissen in der Zusammenarbeit mit und der Führung von Menschen und Teams. Wir brauchen im Projektgeschäft mehr gute Manager/innen und weniger schlechte Projektmanager/innen 🙂

Kritik

Abschließend möchte ich noch auf einen Kommentar von Bernhard M. Scheurer (Autor von „Projektherz„) hinweisen, in dem er meiner These entschieden widerspricht. Auch in seinem Buch schreibt er auf S 17: „In der wirtschaftswissenschaftlichen Fachliteratur und auf den entsprechenden Internetplattformen wird fast durchgängig der Eindruck vermittelt, Projektmanagement sei ein Teilgebiet des Managements. Das klingt durchaus schlüssig, aber es ist genau umgekehrt.“ Die Argumentation, die auf diese Aussage folgt, ist für mich aber ehrlich gesagt (noch) nicht schlüssig. Insofern freue ich mich schon auf spannende Diskussionen! Denn ich lasse mich von den Leser/innen des PM Blogs sehr gerne eines besseren belehren.

Nachtrag

Es wird Ihnen vielleicht aufgefallen sein, dass ich mich an Fredmund Maliks Formulierung „richtiges und gutes Management“ angelehnt habe. Buchtipp: Malik, Fredmund (2006): Führen, Leisten, Leben: Wirksames Management für eine neue Zeit. Campus Verlag.

Wann ist ein Projekt ein Projekt?

Update vom 18.3.2010:

Heute widme ich mich mal einer verhältnismäßig trivialen Frage, nämlich: „Wann ist ein Projekt ein Projekt?“ –> Sprich: Wann ist eine Aufgabe PROJEKTWÜRDIG?

Nach DIN 69901 wird ein Projekt wie folgt definiert:

„Ein Projekt ist ein Vorhaben, das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.: Zielvorgabe, zeitliche, finanzielle, personelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation.“ (siehe hierzu auch: Projektdefinition auf Wikipedia bzw. im PM Glossar)

Das ist auch jene Definition, die man in den meisten Lehr- und Fachbüchern wieder findet. Allerdings halte ich persönlich diese Definition NUR FÜR BEDINGT TAUGLICH, wenn es darum geht, Projekte von anderen Aufgaben zu unterscheiden. Denn in der Praxis erlebt man häufig folgende zwei Extreme:

  • So gut wie alles ist ein Projekt. („Projektitis„)
  • So gut wie nichts ist ein Projekt.

HYPOTHESE: Der Projektbegriff wird in der Praxis unscharf und vielfach falsch verwendet. Aufgaben, die nicht wirklich projektwürdig sind, werden als „Projekte“ bezeichnet und bearbeitet.

LÖSUNGSANSATZ: Wir sollten uns auf die drei ZENTRALEN KRITERIEN konzentrieren, um Projektaufgaben von Routine-/Linien-/Prozessaufgaben zu unterscheiden (= Projektwürdigkeit). Diese sind:

Denn sobald eine Aufgaben komplex und neuartig ist und nicht in Einzelarbeit gelöst werden kann, ist die Bearbeitung als Projekt in der Regel sinnvoll und notwendig. In diesen Fällen ist eine Projektorganisation zu etablieren. In allen anderen Fällen sind die Aufgaben in der Linien- oder Stammorganisation zu lösen.

Nun kann man die berechtigte Frage stellen: Kann eine Aufgabe auch komplex und NICHT neuartig sein? Ja, es gibt in Organisationen natürlich auch so etwas wie „Routineprojekte“, die bis zu einem gewissen Maß standardisierbar sind. Beispiele:

  • Produktentwicklungsprojekte / Innvoationsprojekte –> stardardisierbar über Innovationsprozesse / Stage-Gate-Modelle
  • IT-Projekte –> standardisierbar über Vorgehensmodelle / Projektprozesse
  • Kundenprojekte / kundenspezifische Lösungen –> standardisierbar über Vorgehensmodelle / Projektprozesse

ABER: Auch Projektarten, die in Unternehmen regelmäßig durchgeführt werden, können niemals vollständig standardisiert werden, da sie IMMER auch neuartige Elemente enthalten. Ist dies nicht der Fall, handelt es sich nicht um Projekte, sondern um standardisierbare (Geschäfts)Prozesse.

FAZIT: Sobald Aufgaben in Organisationen KOMPLEX und NEUARTIG sind und nur in TEAMARBEIT gelöst werden können, sollten sie als Projekte bearbeitet werden. Für diese Projekte sollten dann die Projektkriterien zeitliche Befristung, messbare Ziele/Zielvorgaben, definierte Ressourcen, projektspezifische Organisation etc. gelten.

Projekt: Ja oder nein?

In vielen Unternehmen ist nicht klar geregelt, was als Projekt zu bearbeiten ist und was nicht. Das ist ein Problem, denn wenn dies nicht geklärt ist, können grob 3 Szenarien eintreten:

  • Aufgaben, die eigentlich projektwürdig wären, werden in der Linie oder in Routineprozessen abgewickelt.
  • Aufgaben, die eigentlich NICHT projektwürdig wären, werden als Projekte abgewickelt („Projektitis„).
  • Aufgaben, die projektwürdig sind, werden als Projekte abgewickelt. (also der Idealfall, der aber sehr selten bis fast ausgeschlossen ist, wenn die Projektkriterien nicht klar sind)

Die Herausforderung besteht also darin, nur für wirklich projektwürdige Themen das Projektmanagement-Konzept anzuwenden. Dies wiederum hat wesentlich mit der Projektentscheidung und Projektbeauftragung zu tun, die idR den funktionalen Führungskräften im Unternehmen obliegt.

Was können wir also tun, um hier mehr Klarheit und Systematik hinein zu bringen?

Grundsätzlich orientieren sich viele Unternehmen und auch Fachbücher an der DIN-Definition des Projektbegriffs. Dies ist meines Erachtens nicht ganz optimal, da die DIN-Definition entscheidende Lücken hat (und zudem auch nicht sonderlich verständlich ist. Zuerst aber zur Definition nach DIN 69 901:

Ein Projekt ist „ein Vorhaben, das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B.

  • Zielvorgabe
  • zeitliche, finanzielle, personelle oder andere Bedingungen
  • Abgrenzung gegenüber anderen Vorhaben
  • projektspezifische Organisation.“

Alles (un)klar? Ich finde, bei der unmittelbaren Projektentscheidung hilft uns diese Definition nicht wirklich weiter.

Ich stehe auf dem Standpunkt, dass es insbesondere zwei Kriterien gibt, um projektwürdige von weniger projektwürdigen Aufgaben, Problemstellungen oder Herausforderungen zu trennen, nämlich

1) Komplexität und
2) Neuartigkeitsgrad.
(siehe obige Darstellung)

Oder anders ausgedrückt: Je komplexer und/oder neuartiger ein Thema ist, umso größer die Wahrscheinlichkeit, dass die Bearbeitung als Projekt Sinn macht. Das klingt verhältnismäßig trivial, genau darum geht’s aber im Kern.

Denn:

Komplex aber nicht sehr neuartig: Es gibt Themen, die zwar komplex sind, die aber in der Organisation regelmäßig gemacht werden –> z.B. komplexe Kundenaufträge, Innovationsprojekte. Hier macht die Bearbeitung als Projekt Sinn, obwohl die Prinzipien des Prozessmanagements auch zu berücksichtigen sind. Drum durchlaufen diese Projekte auch sogenannte Projektprozesse, die den Charakter von Vorgehensmodellen haben (Stage-Gate, Auftragsabwicklungsprozesse etc.).

Komplex und neuartig: Dann gibt es Aufgaben, die sowohl komplexe als auch neuartig sind. Hier ist’s in der Regel recht eindeutig, dass ein Projekt die richtige Arbeits- und Organisationsform darstellt.

Neuartig und (vermeintlich) wenig komplex: Und schlussendlich häufen sich in Unternehmen sehr neuartige und innovative Problemstellungen, die vielleicht auf den ersten Blick nicht sehr komplex sind, die aber auf jeden Fall (gänzlich) neu sind. hier bieten sich idR Kleinprojekte, Machbarkeitsstudien oder Vorprojekte an, um die Situation weiter zu konkretisieren, Konzepte auszuarbeiten, Marktstudien zu erstellen etc. Danach entscheiden Sie, ob aus dem Thema ein Projekt werden soll, ob es in der Linie weiter bearbeitet wird oder ob Sie es wieder fallen lassen.

Wenn die Projektentscheidung dann grundsätzlich positiv ausgefallen ist, gilt es natürlich, zwischen verschiedenen Projektklassen (= Größenordnungen) und Projektkategorien (= inhaltliche Ausprägung) zu differenzieren und das Projektmanagement entsprechend zu skalieren und anzupassen. Beispiel Projektklassen:

Fazit:

  • Für den Erfolg des Projektmanagements ist es von entscheidender Bedeutung, dass Sie PM nur dort anwenden, wo’s auch tatsächlich Sinn macht.
  • Zwei Zentrale Entscheidungskriterien (Projekt oder Prozess/Linie?) sind der Grad an Komplexität und/oder Neuartigkeit einer Aufgabe.
  • Je komplexer und/oder je neuartiger eine Aufgabenstellung ist, umso größer ist die Wahrscheinlichkeit, dass die Bearbeitung als Projekt Sinn macht.
  • Diese sehr grundlegende Differenzierung sollte im jeweiligen Unternehmen mit möglichst klaren Faktoren messbar gemacht werden (–> klare Projektkriterien). Trotzdem sind die Grenzen häufig fließend.