Wenn wir schon so schön am kritisieren sind, möchte ich gleich noch einen nachlegen.
Seit einigen Jahren bin ich externer Dozent für Projektmanagement an der Fachhochschule Vorarlberg. Die Lehre setzt in diesem Fach auf dem Standardwerk des österreichischen IPMA-Pendants „pma – Projekt Management Austria“ auf, der „pm baseline“ (Download). Das macht grundsätzlich Sinn, denn die pma Standards und Zertifizierungen sind bei uns am weitesten verbreitet.
Seit Jahren „stolpere“ ich aber über dieselben Punkte drüber, die mir einfach nicht in den Kopf gehen möchten.
1) Ist der Projektmanagement-Prozess nach pma noch zeitgemäß?
Der PM Prozess nach pma gestaltet sich wie folgt (Quelle: pm baseline 3.0, S. 13):
Schon die Definition ist aus meiner Sicht falsch (pm baseline, S. 11): „Projektmanagement ist ein Geschäftsprozess der projektorientierten Organisation.“ Sorry, aber das stimmt doch so wohl nicht! Der Terminus „Geschäftsprozess“ leitet sich wohl aus dem Geschäftsprozessmanagement ab. Hier wird in der Regel zwischen Management-/Führungsprozessen, Geschäfts-/Hauptprozessen und Unterstützungsprozessen differenziert. Wenn, dann kann doch die Managementaufgabe in Projekten nur ein Management-/Führungsprozess sein. Denn Geschäfts-/Hauptprozesse sind im Geschäftsprozessmanagement (und auch im Qualitätsmanagement) nur die wertschöpfenden Prozesse. Projekte können direkt wertschöpfend sein (z.B. Kundenprojekte), häufig sind sie es aber auch „nur“ indirekt (z.B. Implementierung eines neuen IT Systems).
Weiters stelle ich auch diesen Satz in Frage: „Der Projektmanagement-Prozess starten mit der Erteilung des Projektauftrages und endet mit der Projektabnahme.“ Sorry, aber wie kommt man in einem komplexen Projekt bitte zum Projektauftrag? Fällt der vom Himmel? Häufig muss doch eine intensive Initiierungs- oder Grobplanungsphase vorangestellt werden, um einen aussagekräftigen Projektauftrag zu erhalten. Entsprechend muss meines Erachtens ein „moderner“ PM Prozess auch mit diesem Teilprozess beginnen (wie bei PMI: Initiating Processes).
Und drittens habe ich nirgends eine Aussage dazu gefunden, dass die einzelnen Teilprozesse einen iterativen, sprich sich wiederholenden, Charakter haben. Offensichtlich sieht pma die PM Teilprozesse nach wie vor als „Phasen“? Oder wie soll ich das sonst interpretieren?
2) Ist die Methodik der pm baseline noch zeitgemäß?
Beispielhaft möchte ich diese Frage anhand folgender Darstellung behandeln:
Die Zusammenhänge der Projektpläne nach pma reflektiert für mich persönlich ein stark „deduktives“ Projektmanagementverständnis (= „klassisches Projektmanagement“). Ohne auf Details eingehen zu wollen: Kann man Projekte heutzutage wirklich noch so führen und managen?
Im Detail hätte ich etliche (nennen wir es mal) „Fragen“ zu den einzelnen Methoden und den Beschreibungen derselben.
3) Ist das Projekthandbuch nach pma noch zeitgemäß?
Als abschließendes Beispiel möchte ich das Instrument „Projekthandbuch“ in Frage stellen (Download). pma Definition (pm baseline, S. 16) „Das Projekthandbuch dient zur Dokumentation aller aktuellen projektmanagement- und projektergebnisbezogenen Inhalte eines Projekts.“
Grundsätzlich sind wir uns einig, dass Projekthandbüchern IN MANCHEN PROJEKTEN absolut Sinn machen können. Wir sind uns auch einig, dass eine saubere, mehr oder weniger standardisierte und auch laufend aktualisierte Projektdokumentation wichtig und notwendig ist. Aber ist ein Projekthandbuch auf Word-Basis hierzu das richtige Instrument? Denn ich kenne eingefleischte „pma’ler“, die diese Frage mit einem klaren und eindeutigen „JA!“ beantworten würden. „Ein Projekthandbuch ist für jedes Projekt zu führen.“ Diese Aussage halte ich für lächerlich und falsch.
Fazit
Ich kenne mich – ehrlich gesagt – in der österreichischen „Projektmanagement-Szene“ nicht sonderlich gut aus. Erstens lebe ich nicht in Wien sondern am anderen Ende von Österreich. Zweitens war ich nie Teil dieser Szene oder habe mich aktiv bei pma eingebracht. Drittens kenne ich die Rolle von Prof. Dr. Gareis und seinen „Schülerinnen und Schülern“ nur vom Hören sagen.
Mein persönlicher Entschluss steht aber fest: Ich werde die PM Ausbildung an der Fachhochschule weiterhin auf der Basis der pm baseline nach pma konzipieren. Ich werde aber zukünftig noch wesentlich stärker andere (aus meiner Sicht modernere) Konzepte und Modelle in die Lehre einfließen lassen. Denn ich lege mich fest: „DIE PM BASELINE IST NICHT MEHR ZEITGEMÄß.“
Hallo Stefan,
da steckt viel konstruktive(!) Kritik drin. Wenn wir jetzt schon unseren eigenen Wissenspool hätten, könnten wir dort gleich die nötigen Ergänzungen machen 😉
Meine Meinung zu den Punkten (von ganz weit weg, da ich pma gar nicht kenne):
zu 1) ehrlich gesagt geht das ganze hochtrabende Geschwätz über Prozess hier und Prozess dort bei mir sowieso bei einem Ohr rein und beim anderen raus. Natürlich wenn Du im Hörsaal stehst und es erklären sollst, dann musst Du Dich damit beschäftigen. Für mich klingt es immer genau so hilfreich wie die Definition eines Betriebssystems: „Ein Betriebssystem ist ein 17-Tupel …“ In dem Punkt iteratives Vorgehen gebe ich Dir uneingeschränkt recht: Projekte laufen so linear nicht ab. Und wenn doch sind sie so klein uns unwichtig, dass wir uns über Prozesse keine Gedanken machen müssen: eine Liste offener Punkte reicht dafür dann auch.
zu 2) Die prinzipiellen Zusammenhänge zwischen den Artefakten der Projektplanung finde ich schon wichtig. Als theoretischen Hintergrund. Mich stört daran, dass auch hier das iterativ-verfeinernde fehlt. Das wesentliche an den Plänen ist ja nicht dass ich sie im stillen Kämmerchen mache, sondern dass sie mir als Kommunikationsmittel dienen.
zu 3) Bitte mal die Hand heben, wer ausser in den ersten paar Wochen vielleicht noch Monaten ein aktuelles Projekthandbuch in Word gesehen hat. Vielleicht gelingt es ja nur mir nicht. Mal losgelöst von der konkreten Implementierung finde ich das Thema Projektdokumentation und Projektinformation sehr wichtig. Aber statt Word verwende ich gerne was Lebendiges wie Wikis.
Gruß,
Marcus
Also ich habe die IPMA/PMA immer nur als nette Ideensammlung betrachtet. Von der Zertifizierung habe ich nur in so fern etwas gehalten, als das diese mittlerweile von Firmen gut akzeptiert wird. Im täglichen Projektmanagement bringt eine Zertifizierung in so fern nichts, als dass diese einen Projektmanager nicht plötzlich zu einem guten Projektmanager macht. Das ist aus meiner Sicht ein bisschen wie beim Autofahren: Die theoretische Prüfung bedeutet noch lange nicht, dass man Auto fahren kann.
Zu Punkt 1.) : Der Punkt Auftragsbeschreibung/-konkretisierung ist aus meiner Sicht kritisch und sollte zu einem Projekt gehören (wer würde das sonst tun, wenn nicht das Projektteam?). In unserem Unternehmen ist das ein ständiger Reibungspunkt zwischen Linien- und Projektorganisation.
Zu Punkt 2.) : Ich meine, dass man Projekte heute nicht so führen kann.
Zu Punkt 3.) : Das führen eines Projekthandbuches ist m.E. von den individuellen Vorlieben und Arbeitsweisen des Projektleiters und Projektteams abhängig. Wenn es zum Stil passt ein umfangreiches Worddokument zu führen – von mir aus gerne. Ich habe in 15 Jahren Projektmanagement noch nie ein Projekthandbuch geführt. Das vorzuschreiben oder auch nur zu empfehlen halte ich daher (auch) für nicht hilfreich.
Hallo Herr Hagen,
Sie sind nicht der einzige Kritiker! Ich finde auch, dass IPMA und PMI mit ihren Ansätze zu Grenzen stossen. Für mich ist weniger die Frage „zeitgemäss oder nicht“, als das falsche Verständnis der Natur der Projekte. Es wird davon ausgegegangen, dass alle Projekte kompliziert sind. In der Wirklichkeit ist es zu differenzieren: es gibt komplizierte und komplexe Projekte, mit jeweils anderen Merkmalen. Und man kann nicht komplexe Projekte mit den Prozessen und Instrumente, die für komplizierte Projekte geeignet sind, planen und führen. d.h man soll zugestehen, dass IPMA/PMI und andere PM-Standards nicht universal anwendbar sind, sondern ausschliesslich für einfache und komplizierte Projekte. Zum Thema „komplexe Projekte“ habe ich ein Blog lanciert (http://komplexeprojekte.blogspot.com/). Ich freue mich auf Kommentare und Diskussionen!
Freundliche Grüsse.
Ph. Vallat
Was mich bei diesen Standards, wie der „pm baseline“, stets verwirrt ist die Tatsache, dass sie das Augenmerk auf eher zweitrangige Problemkreise legen, anstatt einzugestehen, dass das Problem des Projektmanagements viel tiefer liegt. Sie generieren dann viel Lehr- und Lernaufwand für (fast) nichts. Ganz abgesehen vom Hinz’schen Verdosungseffekt….
Das Problem der Projektmanagement Standards ist, dass Sie Konsens basiert sind. Es steht immer eine große Interessengruppe mit verschiedensten Anforderungen dahinter. Alle Interessen zu berücksichtigen halte ich daher für ausgesprochen schwierig. Entsprechend gering ist das Bedürfnis grundlegende Strukturen zu überarbeiten hinter denen ein mühevoller Schaffensprozess steht. Ich habe die Werke von GPM, PMI, DIN etc. daher immer als ein Rahmenwerk verstanden aus dem Teile nach Bedarf verwendet werden können. Jedes Unternehmen/Projekt hat schließlich seine Eigenarten die berücksichtigt werden wollen.
@Hr. Holz: Ich denke, das Problem geht schon etwas tiefer. Natürlich muss ein Standard immer irgendwie „den kleinsten gemeinsamen Nenner“ darstellen. Ich stimme hier aber mit Peter Addor überein: Das, was hier beschrieben ist, geht am eigentlichen Problem zu einem erheblichen Teil vorbei.
Kleinster gemeinsamer Nenner ist gut und recht, aber dann sollten die zentralen Prinzipien erfolgreichen (Projekt)Managements beschrieben und hervorgehoben werden.
Ich wollte mit dem Post den Inhalt nicht als Zeitgemäß darstellen. Ein starres Phasenmodell halte ich ebenfalls für nicht tragbar.Vielmehr wollte ich eine der Ursachen aufzeigen warum dies so ist. Es gibt häufig kein Bedürfnis Dinge zu überdenken und zu verändern. Es ist daher wie im Artikel beschrieben notwendig die Standards mit einem kritischen Blick zu betrachten. Die meines Erachtens entscheidenden Sozialkompetenzen können nicht in ein Rahmenwerk gegossen werden. Dazu zähle ich an dieser Stelle nicht nur den Projektleiter sondern das gesamte soziale Gefüge der beteiligten Personen.
Hallo Stephan,
auch wenn ich dir bei deinem Fazit zustimme, so sehe ich doch einzelne Kritikpunkte an der PM-Baseline bzw. ICB anders.
ad 1)
„Der Terminus “Geschäftsprozess” leitet sich wohl aus dem Geschäftsprozessmanagement ab.“
Im Kontext der projektorientierten Organisation stellt PM doch sehr wohl einen Wertschöpfungsprozess dar. Falls nicht würde dies ja bedeuten, PM kostet Geld, ohne Gegenwert zu erzeugen.
Mir scheint eher die Unterscheidung des Prozessmanagement an dieser Stelle nicht transferierbar. Wieso soll ein Hauptprozess kein Führungsprozess sein können?
Ich stimme mit dir überein, dass PM unbedingt als Führungsprozess zu betrachten ist.
„Projekte können direkt wertschöpfend sein[…]“ Die Definition der PM-Baseline sagt nicht, dass Projekte Geschäftsprozesse sind, sondern das PM ein Geschäftsprozess ist. Was die Wertschöpfung von PM angeht – s.o.
„Der Projektmanagement-Prozess starten mit der Erteilung des Projektauftrages und endet mit der Projektabnahme.“
Der Weg zum Projektauftrag ist aus meiner Sicht keine Aufgabe des PM-Prozesses, sondern des Multiprojektmanagementprozesses eines projektorientierten Unternehmens. In dessen Aufgabenbereich fällt nämlich auch die Verantwortung, die Projektwürdigkeit sicherzustellen.
Dass der Projektleiter hierbei schon bei der Projektierung, d.h. Ausarbeitung des P-Auftrags, dabei sein sollte ist mMn empfehlenswert, aber nicht mandatorisch.
„Und drittens habe ich nirgends eine Aussage dazu gefunden, dass die einzelnen Teilprozesse einen iterativen, sprich sich wiederholenden, Charakter haben. “
Du hast aber auch keine Aussage gefunden, dass die Teilprozesse einmalig sind, oder? 🙂
Den Grund sehe ich in einer der zentralen Unterschiede zwischen IPMA und PMI – IPMA fokussiert Methoden (und Erfahrung), während bei PMI Prozesse (und Wissen) stärker im Vordergrund stehen.
ad 2)
Meiner Erfahrung nach hat auch das klassische PM (noch) seine Daseinsberechtigung. Auch sollte man sich vielleicht von den konkreten Methoden lösen und überlegen, welche FRagestellungen mithilfe der Methoden angegangen werden sollen. Und diese Fragestellungen – wie steht das Projekt im zeitlichen, inhaltlichen und sozialen Kontext da – sind doch auch bei agilem PM von Bedeutung, oder nicht?
ad 3)
Auch hier stimme ich mit dir überein, dass die Methode bzw. das Instrument schon mittlerweile etwas merkwürdig riecht. Allerdings der Grundgedanke, dass auch Führungstätigkeiten & Entscheidungen dokumentiert werden sollten, nicht. Hier wird mir vermutlich jeder zustimmen, der schonmal ein laufendes Projekt übernehmen durfte und erstmal feststellte, dass es nicht einen einzigen Zettel an Doku gibt. 🙂
ad Fazit)
Ich vergleiche klassisches, Wasserfall-PM mit Assembler oder meinetwegen auch Basic – beide Programmiersprachen hatten und haben ihre Daseinsberechtigung und Anwendungsräume, nehmen aber kontinuierlich an Bedeutung ab zugunsten der nächsten Generation von Programmiersprachen resp. PM-Ansätzen.
Ich hoffe der Kommentar ist nicht zu episch ausgefallen.
viele Grüße,
Docolero
Hallo Stefan, ich habe seit längerem das Bedürfnis (vielleicht schon seit 2011) diesem Blog Artikel noch einen Post hinzuzufügen:
zu Punkt 2.) Wie dann?
Ich habe viele gute Antworten gefunden (Management 3.0, oose’s APM, …) – aber keine die mich wirklich befriedigt. Ich habe festgestellt, dass dem iterative Management – was mache als Synonym für agiles Management verstehen – das „continuous Management“ folgt: ein Zustand in dem durch ständige Informations-Updated aus Dailys und AdHoc Meetings kein Regel/Management-Zyklus (sind die Iterationen auch noch so kurz) mehr angewendet werden kann. Agile Methoden wie Scrum, verlagern viele Regel-Funktionen in die Struktur der (Team-)Organisation. Und wenn diese nicht für „ein“ Projekt geändert werden kann? Was dann? Doch wieder der alte Regel-Kreis wie Du ihn in Punkt zwei gezeichnet hast, nur schneller? Sicher nicht. Aber wie dann?
Hast Du die Antwort?
Hallo Tobias,
danke für Deinen Input.
Mir fallen dazu folgende Themen ein:
a) Methodisches Vorgehen in Projekten ist wichtig. Allerdings gibt es niemals „die richtige Methodik“, sondern vielmehr ein Vorgehen, das zum Projekt passt oder eben nicht.
b) Entsprechend ist es auch nicht verwunderlich, dass Du in den genannten Quellen keine „Patentrezepte“ gefunden hast. Denn die kann es meines Erachtens gar nicht geben.
c) Ich bleibe dabei: Ich halte die Beschreibungen in der österreichischen PM Baseline für nicht mehr zeitgemäß und eigentlich für unwürdig, dass sie den Titel „Standard“ tragen.
d) Abschließend möchte ich Roger Dannenhauer zitieren: „Die beste Methode ist wirkungslos, wenn sie auf einen destruktiven Geist trifft!“
LG, Stefan
Hallo Stefan,
vielen Dank für Deine Antwort. (Ich hab erst jetzt im Urlaub gesehen, dass Du geantwortet hast.) Es bestätigt mich meine Antworten jenseits von allen PM Standards, Frameworks und Vorgehensweisen zu suchen – und gleichzeitig auch die Grenzen klar zu sehen, in denen diese Standards und Frameworks gut funktionieren und diese dafür zu schätzen.
Du führst die Diskussion mittlerweile ja auch weiter: beyond project management (standards)… Besten Dank dafür!
Beste Grüße,
Tobias