Menschen machen Projekte. Viel länger schon als Projektmanagement standardisiert und zertifiziert wird. Weder für die Pyramiden noch für die chinesische Mauer waren ein PMBOK oder eine ICB notwendig. Über die letzten Jahrzehnte hinweg sammelten verschiedene Institutionen das vorhandene angewandte Wissen im Projektmanagement und verdichteten es zu dicken Büchern. Das alles unter dem Einfluss der aus heutiger Sicht fragwürdigen und teilweise unpassenden Paradigmen von Frederick Winslow Taylor. Peter F. Drucker erkannte bereits, dass im Zeitalter der Wissensarbeit die Zusammenarbeit von Wissensarbeitern neu zu organisieren sein wird. Entsprechend erleben wir derzeit neue Formen und Experimente der Unternehmensführung (Semco, Gore, WholeFoods, etc.) und ebenso alternative Formen der Projektdurchführung (Scrum und andere agile Modelle). Anstatt nun vergeblich über die eine richtige Methode zu streiten, sollten wir einige Schritte zurück treten und sauber zwischen Anforderung und Umsetzung unterscheiden.
Eine Anforderung könnte zum Beispiel sein: „Ich will jederzeit über den Fortschritt des Projekts informiert sein.“ Umsetzen lässt sich das mit Projektstrukturplan, Ablaufplan und das Verfolgen der Abarbeitung des Plans. Oder über Product-Backlog und Burndown-Chart. Oder nach einer Methode die wir noch nicht kennen und versucht haben.
Eine andere Anforderung wäre: „Die Arbeitskraft und Kreativität der Mitarbeiter soll bestmöglich genutzt werden.“ Wiederrum kann man das durch einen detaillierten Ressourcenplan (ein schreckliches Wort) machen. Oder auf die Selbstorganisation von Teams vertrauen.
Ähnlich ließen sich meiner Meinung nach alle Methoden und Prozesse im Projektmanagement auf ihre eigentliche Anforderung zurückführen. Die bekannten, standardisierten und zertifizierbaren Methoden wären dann nur eine Ausprägung im Lösungsraum möglicher Umsetzungen.
Anstatt über die eine beste Lösung zu diskutieren oder diese sogar zu standardisieren (ein durch und durch tayloristisches Ansinnen), würde ich lieber einen Schritt zurück treten und in Anforderungen denken wollen. Zu diesem Fächer an Anforderungen gäbe es dann verschiedene Umsetzungen mit jeweils spezifischen Bedingungen zum Einsatz, mit Wechselwirkungen (positiv oder negativ) und mit Erfahrungsberichten. Jedes neue Experiment in der Umsetzung einer Anforderung, jede Variation wäre dann keine Abweichung von der Norm, sondern eine willkommene Bereicherung des Lösungsraums.
Genau dafür könnten wir openPM nutzen.
Was wir brauchen, sind ein paar verrückte Leute; seht euch an, wohin uns die Normalen gebracht haben.
George Bernard Shaw (via @lazyNadja)
Weiterlesen
- Projekt-Management: Ein Widerspruch?
- Der Projektleiter: Vom Aussterben bedroht
- Postindustrielles Projektmanagement
Artikelbild: Christoph Michels auf Wikimedia (CC BY-SA 2.5).
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
13 Kommentare
Hallo Marcus,
deine Anforderungsbeispiele finde ich unglücklich, weil sie sich auf der Metaebene befinden. Vermutlich müssen wir neben Anforderung und Umsetzung noch die Sachebene und eine Metaebene unterscheiden. Unter Sachebene verstehe ich die konkrete Problemstellung/den Projektauftrag. Das Problem mit der Metaebene ist, dass sie schnell zum Selbstzweck wird. Wollen wir unsere Mitarbeiter auslasten, den Fortschritt tracken oder das Problem lösen?
Gruß
Bernhard
Die Beispiele befinden sich ganz bewusst auf der Metaebene. Denn dorthin möchte ich zurück. Nicht zum Selbstzweck, sondern als Fundament und Rahmen. Natürlich will jedes Projekt ein konkretes Ziel erreichen oder ein konkretes Problem lösen. Ich glaube aber, dass das es dafür allgemein gültige Anforderungen gibt, z.B. eben die Festlegung des Umfang, Planung, Verfolgung der Abarbeitung. Und die würde ich gerne von der konkreten Umsetzung und Ausprägung trennen wollen. Nicht um dann auf der Metaebene ein Glasperlenspiel zu betreiben, sondern um im zweiten Schritt sauber über verschiedene Umsetzungen reden zu können, über deren Eignung für bestimmte Probleme und über Abhängigkeiten und Ausschlüsse.
Ich finde die Idee sehr erfrischend und mir kürzlich in puncto Standards einen ähnlichen Blog-Post vorgenommen, der allerdings noch in der Schublade schlummert.
Deine Ausführungen haben aber schon mal viel interessanten Zündstoff in sich ;)
Zunächst passt sicher wie immer der Spruch von G. Box: „„Alle Modelle sind falsch, manche sind nützlich“. Also, wie immer wir die (sogenannte) „Realität“ – ich bin Konstruktivist – zu fassen versuchen – es kann ggf. immer nur in sehr eingeschränkter Form hilfreich sein.
Ich glaube auch, dass die Formierung von PM als Disziplin, erst eine Errungenschaft des letzten Jahrhunderts war, als zahlreiche Ingenieure daran scheiterten ihre Engineering-Projekte (vorrangig militärischer Natur) geordnet und vor allem in Erwartung der Sponsoren ins Ziel zu bringen. Dies ist – wie Du es andeutest – aber leider recht spät erfolgt. In einem Zeitalter, wo Command-und-Control immer weniger funktioniert, mechanistisches Denken kaum mehr in Abgleich mit den Innovationen und Dienstleistungen der Zukunft zu bringen sind. Wenn Wettbewerbsvorteile durch selbstorganisierte Teams, durch Co-Creation, durch emergente Prozesse und Produkte entstehen, dann sind allzu starre Modelle schnell im Weg.
Unter diesem Licht wären Anforderungen ein hilfreicher Ansatz, die Unterschiede im Bedarf der Welt von heute und morgen gegenüber dem zu verstehen, was uns noch vor Jahrzehnten getrieben hat, dicke Standards zu verfassen. Deine angeführten Beispiele liefern dazu bereits sehr gute Anregungen. Wie kann mich der Projekttforschritt entlang eines Plans interessieren, wo der Plan – in Unkenntnis der künftigen Optionen – ein bereits überholtes Konstrukt darstellt? Wie könnte ich anhand von Plänen die Kreativität fördern oder gar zu erzwingen versuchen (obwohl ich glaube, manche haben es versucht und sind heute „out of business“)?
Es drängt sich die Hoffnung auf, dass ein derartiger Versuch nicht dort endet, dass die Anforderungen an das Unterfangen komplexer werden, als das Unterfangen selbst (wäre das eine Rechtfertigung der Taylor’schen Idee oder gar der PM-Abteilungen=). Und es liegt die Vermutung nahe, dass man so zu situativen Konstellationen gelangt, wo umfangreichere Prozesse und Methoden möglicherweise bei eher repetitiven „Projekten“ zumindest zu Aussagen gelangen. Ja, und dann könnte noch die Frage aufkommen, ob denn diese repetitiven Aufgaben überhaupt den Kerngedanken des PM genügen: Einzigartigkeit, Einmaligkeit, Neuartigkeit … Ich glaube z.B., dass sich viele Organisationen im Projektgeschäft wähnen, obwohl ihre „Projekte“ immer wieder dasselbe Geschäft mit gewissen Abwandlungen bringen.
Die Frage wäre nur: wenn auf Grund der Wiederholung die Vorhersagbarkeit wesentlich höher ist, wozu brauchen wir dann den ganzen Overhead? Gut, vielleicht kann man dann endlich guten Gewissens eine EVA einsetzen ☺
Und das bringt mich wieder zu meinem Ausgangsgedanken über die „Konstruktion“ von Modellen zurück. Nämlich mit der Frage, ob es bloss um den Einsatz der passenden Methode in der geeigneten Situation geht, oder ob da noch mehr dahinter steckt? Ich glaube an Letzeres – wie wir es in den Scrum Trainings vermitteln … es geht eben nicht um den Scrum-Prozess, um die Artefakte, die Zeremonien … es geht um das Mindset … das Mindset als Grundlage für Lernen, für Veränderung, für Emergenz. Und in diesem Licht wird es mit grosser Wahrscheinlichkeit auch in einem Scrum-Team geschehen, dass der ursprüngliche Prozess verändert wird, dass Artefakte über Bord geworfen werden, dass dem „Wunderbaren“, dem Potential der Teams, der Co-Creation, dem Produkt der Weg geebnet wird. Ein breiter Spruch aus der Community lautet: es geht nicht um „Doing Agile“, sondern um „Being Agile“. Aber das ist eine andere Geschichte.
Interessante Gedanken! Ich picke mir Mal zwei raus.
Ich glaube, dass Anforderungen an das Management von Projekten zeitlos sein können und sollten. Jedes Projekt braucht ein gewisses Maß an Planung und Verfolgung beispielsweise. Wie das umgesetzt wird, in welchem Kontext sich die spezifische Umsetzung eignet und in welchem nicht, das wäre zu untersuchen. Da kann es dann auch historische Artefakte geben, also Umsetzungen die zwar früher funktionierten, aber heute nur in Ausnahmefällen anwendbar sind.
Dem stimme ich zu. Es geht sicherlich um mehr als bloß einen möglichst vollen Werkzeugkasten bereitzustellen. Dennoch könnte ich mir vorstellen, dass ein Cross-over einen gewissen Charme hätte: wenn die verschiedenen Umsetzungen und Methoden nebeneinander stünden, könnten eigentlich agile Methoden in klassischen Projekten Anwendung finden und umgekehrt. Wir könnten ja für jede Umsetzung einer Anforderung definieren / erforschen, welche Paradigmen im Unternehmen bzw. im Umfeld gegeben sein müssen, damit eine Anwendung möglich ist.
Moin Marcus,
Endlich kommt man scheinbar doch auf des Pudels Kern :-)
Methodiken sind Leitfäden und keine Paradigmen. Das wird zu oft außer Acht gelassen. Interessante Sammlungen von Erfahrungen. Aber Ihr Einsatz muss angepasst werden an das Umfeld, die Aufgabe, das Team.
Aber das Problem in der „Wirtschaft“ ist, dass man derartiger kreativer Arbeitsweise nicht traut und lieber dem „Standard“ sehen will. Ich mag das PMBOK, einfach weil es gute Ideen enthält. Anwenden kann man es aber nur unter starkem Tailoring. Ich mag auch agiles vorgehen, aber SCRUM ist zu statisch in der Methodik, lässt also die oben genannten nötigen Anpassungen nicht zu.
Hinfort mit Methoden ist genauso falsch wie bedingungsloses daran festhalten. An sich ist es die Aufgabe eines jeden Projekts sich an sein Umfeld anzupassen (steht auch im PMBOK, wenn auch verklausuliert).
openPM ist ein toller Ansatz, droht aber in der Agilitätsaffinität unterzugehen. Denn so wie PM Verfechter in den 90er sind heute die Agilos am Werk.
„Open your (PM) mind“ würde ich allen Methoden-Freaks gerne zurufen … aber ich weiss nicht, ob das ankommt :-)
Jens
Du hast vollkommen recht: jeder Standard, jedes Modell muss angepasst werden. Stur nach Vorschrift angewendet, ist alles gleich schlecht geeignet.
Doch das kommt an. Im Mission-Statement von openPM gibt es ein ganz wichtiges Wort: Vielfalt. Im Moment fehlt uns allerdings noch ein wenig Struktur, um diese Vielfalt abzubilden. Dazu möchte ich gerne zurück zu abstrakten, allgemein gültigen Anforderungen, um dann über Umsetzungen der Anforderungen mit spezifischen Voraussetzungen, Paradigmen und Rahmenbedingungen.
Gerade bei Scrum kommt dann aber nichts mehr Vernünftiges dabei raus. Scrum ist bereits auf das Wesentliche zusammengedampft worden, so daß man nichts mehr weglassen kann vom Framework. Dazwischen bietet es allerdings eine Menge Raum für kreative Ausgestaltung ;-).
Scrum ist eine Möglichkeit Projekte durchzuführen. Ich will nicht Scrum abstrahieren, sondern den gemeinsamen Nenner aller Möglichkeiten Projekte durchzuführen finden. Es gibt Dinge (ich habe sie Anforderungen genannt) die in jedem Projekt so oder eben anders gemacht werden müssen. Diese Anforderungen bilden den Rahmen in den sich die konkreten Methoden, wie z.B. ein Product Backlog zur Verwaltung des Umfangs eines Projekts, einsortieren lassen müssten.
Ich bin mal ganz ketzerisch und drücke mal alles bisher geäußerte platt:
Ein Unternehmen im 21 Jahrhundert, das erfolgreich ist, hat erfolgreiche Mitarbeiter (und damit meine ich alle Mitarbeiter), die sich die Methoden, die am besten zu ihnen passen, selbst aussuchen und sich ihren eigenen erfolgreichen Rahmen schaffen. Sie suchen sich, was sie benötigen, um erfolgreich zu sein, egal welches Etikett drauf steht.
Alles andere spielt aus meiner Sicht keine Rolle.
Nur ist diese Suche nach den geeigneten Methoden derzeit mühsam. Es gibt zu viele Methoden, die als „silver-bullet“ gepriesen werden ohne je darüber nachgedacht zu haben, welche Anforderung sie lösen, unter welchen Umständen sie anwendbar sind und welche Wechselwirkungen sie mit anderen Methoden haben. Eigentlich müsste jede konkrete Umsetzung einer Anforderung wie ein Medikament einen Beipackzettel bekommen.
Ist tatsächlich etwas ketzerisch, aber im Kern auch wahr. Ich würde sogar soweit gehen, wenn die Mitarbeiter Spaß an dem haben, was Sie arbeiten, stellt sich Erfolg auch ein. Ich ziehe einen Vergleich mit der Realisierung von openPM. Es gab kein detailliertes Anforderungspapier, keinen CEO/kein Mgmt. Board, geschweige denn Budgets. Trotzdem gibt es die Plattform jetzt. Und alle hatten Spaß daran, das Projekt openPM zu realisieren.
Wobei wir vielleicht in der Diskussion etwas differenzieren müssen, von welchen Arbeiten/Unternehmen/Märkten wir sprechen. Ich denke bei Projekten und Projektmgmt. z.B. immer gleich an IT Projekte :)
Am meisten zu einem Kommentar provoziert hat mich die Replik von Jens von Gersdorff. Auf der einen Seite schreibt er, er möge das PMBOK, weil es gute Ideen enthalte. Dabei ist das PMBOK die Bibel der PM Verfechter nicht nur der 90ern, sondern eher der 70er Jahre mit ihren unreflektierten Begriffen wie Earned Value Analysis, Critical Path, work Breakdown structure, etc. Auf der anderen Seite sieht er in der Agilitätsaffinität eine Gefahr für openPM (der eigentliche Grund, weshalb ich mich von openPM fernhalte). Für den Hinweis auf dieses Risiko danke ich ihm sehr.
Die Methode interessiert mich wirklich erst in zweiter Linie und hängt sehr von der Projektart ab. Mich nervt die Forderung nach Standardisierung mit dem Hinweis, dass jede (Dienst)Leistung immer gleich sein müsse. Ich will gar nicht gleichgeschaltete und standardisierte Projektmanager.
Vielmehr müsste man sich endlich überlegen, zu was ein Projektmanager überhaupt fähig ist. Wolf Singer sagt: „Wir sind unfähig, nichtlineare Phänomene zu erfassen. Das klingt zwar abstrakt, erklärt sich aber aus der Evolution: Im Kleinen, und nur darauf ist unser Gehirn eingestellt und nur daran ist es angepasst, verhält sich die Welt linear. Diese Unfähigkeit sei auch kein Wunder, denn nichtlineare Vorgänge sind nicht vorhersagbar, das Hirn als prädiktives System wäre also überfordert“.
Anstatt (unrealistische) Praktiken zu diskutieren, wäre es wichtiger, ein paar Schritte zurückzutreten. Aber über Methoden und agilem Vorgehen zu diskutieren geht mit kognitiver Leichtigkeit einher. Das erklärt vielleicht auch, warum die Forschungswerkstatt der GPM über Theorien des Projektmanagements, die im November in Berlin stattfindet, so wenig Beachtung findet.
Danke für Deinen Kommentar! Die Gefahr der Vereinnahmung von openPM in eine Glaubensrichtung ist mir bewusst.
Da stimme ich Dir voll und ganz zu: Standardisierung an sich ist ein durch und durch tayloristisches Ansinnen und macht für anspruchsvolle Führungsaufgaben in Projekten keinen Sinn.
Auch das finde ich eine lohnende Denkrichtung. Um zu verstehen zu was ein Projektmanager fähig sein müsste, wäre es meiner Meinung nach sinnvoll erst Mal die paar Schritte von der konkreten Methodik zurückzutreten und zu verstehen was ein Projekt ausmacht, welche Anforderungen man dort findet und wie diese zusammenhängen.