Es dürfte mittlerweile außer Zweifel stehen, dass die Welt in den letzten 20-30 Jahren komplexer und schneller geworden ist. Dramatisch komplexer und schneller.
Die eigentliche Ursache hierfür liegt in den neuen Informations- und Kommunikationstechnologien (Mobile, Internet, Web 2.0…), welche globale Informations-, Waren- und Finanzströme erst in dieser Form möglich gemacht haben.
Fluch oder Segen? Wahrscheinlich von beidem ein bisschen. Klar sollte uns aber sein: Die Entwicklung hin zur „vernetzten Gesellschaft“ (vgl. IBM CEO Study 2010 / Prof. Dirk Baecker) wird weiter gehen. Was aber bedeutet das für Unternehmen? Was für das Projektmanagement?
Ende der Planbarkeit?
Mit hoher Wahrscheinlichkeit wird die Planbarkeit in Organisationen weiter abnehmen. Bedeutet dies auch automatisch, dass Planung obsolet wird? Steuern wir auf das „Ende der Planbarkeit“ zu?
Ich denke nicht. Es wird in Organisationen immer stabile Strategien, Prozesse und Strukturen geben (vgl. hierzu z.B. diesen und diesen Blogbeitrag). Aber sehr wohl wird es vermehrt Arbeits- und Organisationsformen brauchen, die den professionellen Umgang mit Komplexität, der damit verbundenen Unsicherheit und den omnipräsenten Widersprüchen im Fokus haben.
Beyond Project Management
Folgende Erkenntnis setzt sich immer mehr durch:
(Klassisches) Projektmanagement ist noch nicht der Weisheit letzter Schluss, um in einer „komplexen, vernetzten Welt“ Probleme zu lösen.
Den Gedanken möchte ich mit dieser Skizze kurz illustrieren:
Ich habe die Grafik schon neulich verwendet. Ein paar Gedanken dazu:
- Projektmanagement, wie wir es kennen und gelernt haben, stammt ursprünglich aus einer Zeit, in der von der Planbarkeit von Vorhaben ausgegangen werden konnte. Sehr wohl waren die Inhalte von Projekten neuartig und kompliziert. Jedoch war das Umfeld, in dem sich Projekte und Organisationen bewegten, relativ stabil.
- Auch heute noch wird (klassisches) Projektmanagement sinnvollerweise für jene Vorhaben eingesetzt, bei denen von grundsätzlicher Planbarkeit ausgegangen werden kann (z.B. Bauwirtschaft, Anlagenbau, meistens auch Produktentwicklung). Denn sonst würden Kernmodelle des (klassischen) Projektmanagements wie das PM Dreieck (= Qualität, Kosten, Zeit), der Projektstrukturplan (PSP) oder Balkenpläne (Gantt Charts) ja gar keinen Sinn mehr ergeben.
- Das, was wir als „Agiles Projektmanagement“ bezeichnen, sehe ich mittlerweile außerhalb des eigentlichen Projektmanagements (vgl. z.B. diesen Beitrag). Denn „Agile“ ist für mich der Beginn einer NEUEN ARBEITSWEISE und eines neuen PARADIGMAS (vgl. Agiles Manifest) im Umgang mit komplexen, neuartigen Problemstellungen. Bei agil geführten Projekten gehen wir nämlich zumindest in Teilen von UNPLANBARKEIT aus.
Nur mal laut gedacht. Was wäre, wenn…
- … wir Agile (= agile Frameworks wie Scrum) AUSSERHALB der Projektmanagement-Disziplin, wie wir sie kennen, ansiedeln würden?
- … wir Agile in die Kategorie der „Pionierarbeit“ einordnen würden? Außerhalb der Illusion von Planbarkeit, Kontrolle und Fremdorganisation?
- … wir (klassisches) Projektmanagement relativ unabhängig davon weiter entwickeln?
Damit spreche ich mich übrigens dezidiert NICHT für eine Trennung von Routine-, Projekt- und Pionierarbeit aus. Vielmehr bin ich der Überzeugung, dass wir die Themen und die damit verbundenen Arbeits- und Organisationsformen wieder klarer auseinander halben müssen, um sie dann auf einer höheren Systemebene sinnvoll zu integrieren (vgl. hierzu z.B. diesen Blogbeitrag).
Eine sinnvolle Integration von „klassisch“ und „agil“ kann es nur geben, wenn wir die Disziplinen vorher sauber differenzieren.
„Unterscheide, ohne zu trennen.“ (Prof. Pietschmann)
Worum geht es eigentlich?
Geht es am Ende nicht um die Frage, wie Organisationen unter den neuen Bedingungen erfolgreich und überlebensfähig bleiben können?
Hierzu werden nach meiner Überzeugung mindestens drei „Meta-Kompetenzen“ in Organisationen vorhanden sein müssen:
- Routinearbeit (Verwerten des Bekannten / Management von Stabilität): Produkte und Dienstleistungen, die für Menschen von Wert sind, erfolgreich und effizient herstellen und vermarkten.
- Projektarbeit: Produkte und Dienstleistungen entwickeln und zur Marktreife bringen, die aktuelle und entstehende Bedürfnisse (intern / extern) befriedigen.
- Pionierarbeit (Erlernen des Neuen / Management von Instabilität): Erfolgreicher und professioneller Umgang mit Veränderung, mit Komplexität und mit Herausforderungen, die teilweise noch völlig unklar, nebulös und folglich auch rational nicht verstehbar sind.
Ich freue mich – wie immer – über Kommentare zu diesem Blogbeitrag!
Sehr wichtiger Beitrag, Stefan, und eine gute Einstimmung auf das diesjährige PM Camp in Dornbirn 😉
Eines möchte ich aber doch in Frage stellen. Ich bin mir nicht sicher, ob heute noch viel Planbarkeit in Projekten übrig bleibt. In meiner (IT-lastigen und damit recht schnelllebigen) Projektwelt verändert sich das Umfeld und die Anforderungen oft so schnell, dass eine langfristige Planung – und damit meine ich alles größer ein halbes Jahr – meist sinnlos ist. Sicherlich kann man einwenden, dass das Management von Änderungen schon immer zum Projektmanagement gehörte, aber eben unter der Annahme, dass die Änderungen die Ausnahme sind und nicht zur Regel werden. Bei mir sind die Änderungen mittlerweile fast die Regel. Daher ist modernes Projektmanagement für mich in erster Linie auch eine Frage der Flexibilität. Daher sehe ich agiles Vorgehen definitiv im Bereich Projektarbeit.
Danke, Marcus.
Mir gehen diesbezüglich diverse Punkte durch den Kopf. Ich werde mir diese aber bis zum PM Camp aufsparen. Freue mich schon auf rege und konstruktive Diskussionen zu „Beyond Project Management“ 😉
Moin,
ich habe auch ein paar Anmerkungen. Ich war früher Bergmann. Eine der Hauptmetaphern war: „Hinter der Hacke ist es duster?“ Was heißt das? Zum einden bedeutet es, dass der nächste Schlag mit der Hacke dein letzter sein kann, weil Wasser einbricht, dass Gebirge über Dir zusammenstürzt oder Du einen Methan-Bläser anpickst, der Dich mit einer Explosion schnell zu den Jungfrauen schickt. Trotz dieser Widrigkeit plant man Bergwerke so weit es geht, zumal es auch immer Milliardenprojekte sind. Man bohrt (wie in Gorleben), macht Seismographie, um Flöze und deren Verlauf zu suchen, usw.. Aber dann kann es Dir dennoch passieren, dass Du freitags abends entscheidest, dass das Flöz plötzlich zu steil abgeht, als dass Du mit deinen Maschinen durchkommst. Dann lässt Du halt den Teil eines Baufeldes stehen, was Dich vielleicht 200 Mio. € weniger Einnahmen kostet. Ist da das Weglassen von Planung dann der richtige Weg im Gottvertrauen, dass Dir Deine Hacke agil den richtigen Weg zeigt? Ich glaube nicht.
Ich glaube, dass oben in der Zeichnung zwei statt drei Bereiche ausreichen: einer für Business As Usual (BAU) und der andere die Änderung des BAU durch neue Portfolios, Programme und Projekte.
Die Briten haben dafür ein schönes Bild gemacht: siehe Abbildung Governance Triangle: Business As Usual (BAU) vs. Change
In der Sicht von Axelos (PPP mit der britischen Regierung) ist enthalten, dass der Output von Projekten die Organisation ändert. Siehe zum Beispiel „Managing Successful Programmes“. Da ist auch beschrieben, wie man erfolgreich das OE und PE managet, z.B. durch einen Change Manager neben dem Programm-/Projektmanager.
In der Sichtweise ist auch Scrum tatsächlich nicht im Projektmanagement angesiedelt, sondern es ist hocheffiziente, hochstrukturierte Produktionsmethode mit klaren Rollen und Prozessen, mit der man aber nicht mit einer Bank sprechen kann, wenn man vier Mio € für die Finanzierung eines Projektes braucht. Die Aussage „Ich kann bei Scrum nicht planen“ kommt bei Bankern nicht so doll und in Folge da Geld auch nicht 🙂
Dass Scrum wirklich zur Pionierarbeit außerhalb der Softwareentwciklung beitragen, glaube ich nicht. Eine Entwicklung einer Vision ist etwas anderes als die Frage wie ich in kleinen Häppchen das nächste freigebbare Stückchen Software entwickle. Beim SPIEGEL wird nicht in Daily Scrums im Vieererteam entscheiden, ob Print und Online zusammengehen, der Tagebau Garzweiler wird nicht von einem agilen 10er Team in der RWE-Hauptverwaltung ins Leben gebracht. Da sind viele Stakeholder in vielen Organisationseinheiten mit vielen Änderungen unterwegs. Vor 40 Jahren war CO2 kein Problem, aber der Tagebau Hambach ist für 50 Jahre geplant. Das kann man nicht mit einem Product Owner, einem Scrummaster und einem schlanken, leanen Team covern. Die Pipeline Vision-Strategie-Portfolio-Programm-Projekt ist mühselig und involviert Stakeholder für die Scrum keine Hilfe ist. Und agil muss man auch hin hochtraditionellen Umgebungen sein (siehe Bergbau oben).
Zu Dirk Baecker noch: Er sit einer der wichtigsten Adepten von Niklas Luhmanns Systemtheorie. Aber er kommt nicht wirklich weiter. Luhmann war mit der 30-jährigen Arbeit an seiner Systemtheorie planmäßig (!) Ende der 1990 fertig. Zwei wesentlich Aspekte. Soziale Systeme können sich nur selbst steuern und von außen maximal irritiert werden. Passt zu Scrum, darf aber nicht Autismus verdecken 🙂 Soziale Systeme basieren auf Kommunikation (nicht auf Individuen). Wenn sich die Kommunikation von oralem zu Papier und zu Internet ändern, ändern sich auch die sozialen Systeme. Michael Porter hat auch in den 1990er die betriebswirtschaftliche Bedeutung von Netzwerkökonomien herausgearbeitet. Aber Becker hat dem noch nichts Neues hinzugefügt. Obwohl die Veränderung durch das Internet dramatisch ist.
Zu dem laut gedachten also:
– Agiles außerhalb des Projektmanagements ja, aber PRINCE2 zum Beispiel kann es auf der „Lieferebene“ einbetten. Das wird methodisch auch gerade standardisiert
– die Kategorie Pionierarbeit halte ich nicht für notwendig. Jeder macht Pionierarbeit („Hinter der Hacke ist es duster!“). Das ist der Standardlastfall beim Change in der OE. VW/Toyota kann nicht planen, ob das nächste Modell ein Erfolg wird (aber Du musst ein Projekt machen, damit ein neues Modell auf dem Band ist, wenn die Werker aus den Sommerferien kommen); die Banken konnten nicht planen, dass ihre gebundelten Produkte in den Meltdown des Finanzystems 2008 führten, usw.
– wir sollten unseren Begriff von Planbarkeit durchdenken. Carl Friedrich von Weizsäcker hat in den 1940er als Physiker gezeigt (als Reaktion auf Heisenberg), dass Zukunft nicht voraussagbar ist (wie der Aufententhaltsort des Elektrons nicht messbar ist). Moderne Projektmanagementmethoden planen daher nicht mehr ganze Projekte fein, sondern nur die nächste Phase und die übernächste anhand des Ergebnisses der dann vorigen. Man gibt sich Toleranzen auf mehreren Ebenen, um Änderungen zu bewältigen. Das ist alles auch klassisch einbaubar. Aber man sollte nicht glauben, dass man mit einfachen Prozesse wie Scrum Komplexität reduzieren würde. Spätestens, wenn man auf Grund der Größe eine Projektes Scrums of Scrums einführen muss, ist man wieder am Anfang (z.B. wenn man 70-80 Entwickler zum Coden hat 🙂 Luhmann sagt, dass man komplexe Probleme nur mit komplexen Methoden lösen kann.
Ich finde aber gut, dass die Thematik aufgeworfen wird. Wir müssen ja vorwärts kommen. Der Wasserfall ist weg, das V-Modell ist Scheisse und Scrum-Hacker können nicht mit Bankern sprechen. Da braucht man dann einen passenden neuen Rahmen 🙂 Sorry für die Länge, aber ich kann nicht kurz. 🙂
Schon mal Scrum selbst gemacht? Hört sich nicht so an.
Danke der Nachfrage. Scrum habe ich auch schon selbst gemacht 🙂
Das Thema hat was. Ich möchte da gerne aus dem Blinkwinkel IT-Service Management hinschauen und versuchen die Unterschiede zu beschreiben die mir dabei auffallen.
Üblicherweise wird im ITSM von Changes gesprochen, die sowohl im Prozess selbst oder eben auch in dedizierten Projekten ablaufen.
Auf der stabilen Seite haben wir die Standard Changes. Das ist das was wir jeden Tag x-mal machen. Das ist Prozess. Manchmal, wenn z.B. Umzüge anstehen fassen wir das auch in einem Projekt zusammen.
Dann haben wir so etwas wie „planbare Changes“ Das machen wir nicht jeden Tag, ist aber weitestgehend überschaubar weil aus ähnlichen Änderungen bereits Erfahrungen vorliegen.
Das läuft je nach Umfang im Prozess oder mittels Projekt.
Die nächste Stufe sind dann große Changes (z.B. ein Rollout), der wegen seines Umfangs auf keinen Fall mehr von der Linienorganisation durchgeführt werden kann. Z.B die Umstellung einer ITK Infrastruktur auf einen anderen Hersteller. Solche Themen können eine enorme Dynamik entwickeln, für echte Pionierarbeit halte ich es jedoch noch nicht.
Als Pionierarbeit sehe ich das was wir als Produktentwicklung bezeichnen. Das läuft aber in den Labors der Hersteller oder auch in internen Entwicklungsbereichen. Zumindest war das eine ganze Zeitlang so.
Inzwischen ist es immer häufiger so, dass diese Entwicklungen die Labors verlassen, ohne dass für alle Einsatzzwecke ausreichende Tests gemacht werden können. Umgangssprachlich ist das dann „Bananentechnik“ und reift beim Kunden. Das geht solange gut wie die entstehenden Problem keiner besonderen Dynamik ausgesetzt sind.
Andernfalls ist es doch so, dass plötzlich zwei völlig unabhängige Projekte. (Roll Out und Produktentwicklung) gezwungen sind sehr eng zusammenzuarbeiten. Möglicherweise sogar zu einem Projekt verschmelzen. Oder anders beschrieben „planbares“ und „nicht planbares“ müssen eine Einheit bilden um am Ende doch noch erfolgreich zu sein.
Selbstverständlich ist es trotz einer Verschmelzung beider immer noch wichtig zu unterscheiden in welcher Umgebung gerade gearbeitet wird.
das ist ein Unterschied, der einen Unterschied macht!
Mir gefällt besonders gut, dass Du durch den Unterschied einen verständlichen Gegenentwurf zu dem langweiligen Streit „Ich hab das beste Modell“ lieferst. Daran sollten wir weiter arbeiten, in Dornbirn, Wiesbaden, Hamburg oder dazwischen…
Danke, Olaf. Freue mich schon auf spannende Diskussionen beim PM Camp in Dornbirn (20. – 22.11.2014).
Lieber Stefan,
1. ich denke, es reichen zwei Bereiche: Prozessarbeit und Projektarbeit. (In unserer Firma sprechen wir oft von stark und von schwach strukturierten Prozessen. Rob England unterscheidet Standard-Prozesse und Case-Arbeit.)
2. Zudem glaube ich, dass es im Bereich Planbarkeit in den letzten 50 Jahren keine großen Änderungen gab. Viele Projektmanagementtechniken wurden zum Beispiel bei der NASA und den Vorläuferorganisationen entwickelt. Eine Mondlandfähre zu entwickeln und die Astronauten lebend wieder zurück zu bringen war damals nicht planbar. Die Erfahrungen mit dem Space Shuttle Projekt zeigte auch, dass es mit der Planbarkeit so eine Sache ist. Das Umfeld war damals übrigens auch nicht stabil. Ständig gab es zum Beispiel Querelen zwischen Navy und Airforce.
3. Pionierarbeit sind für mich Projekte mit höherer Unsicherheit. Die unterschiedlichen Grade von Unsicherheit haben Shenhar und Dvir definiert. Dem ist nichts mehr hinzuzufügen.
4. Zum Thema Scrum und Planbarkeit hat die agile Szene sicherlich zwei Meinungen, wie die Diskussion um #NoEstimates gerade zeigt. Ich denke, dass Scrum viel besser plant, als manche Projektmanagementmethode in der Praxis. Da auch in Zukunft das Geld nicht vom Himmel fällt, wird jeder, der ein Projekt machen will, sich irgendwie Geld und Mitarbeiter besorgen müssen. Die gibt es nur, wenn man nachweisen kann, dass sich die Investition lohnt.
5. Interessant finde ich Deine Frage nach dem Weiterentwickeln des sog. klassischen Projektmanagement. Ich hatte bisher immer gedacht, dass es eigentlich genug Methoden und Tools gibt. Aber das Wissen darüber ist einfach zu wenig verbreitet (wie verschiedene KPMG-Studien zeigen). Vieles wird noch zu kompliziert dargestellt und müsste vereinfacht werden. Beispiel: Earned-Value-Management ist ein super praktisches Hilfsmittel aber kaum verbreitet. Aber ein einfaches Burndown-Chart wird fast in jedem Scrum-Projekt verwendet und zeigt die gleichen Informationen. Also, in welche Richtung würdest Du das klassische Projektmanagement weiterentwickeln wollen?
BG, Jan
Jan, vielen Dank für Deine Gedanken! Ich mach’s kurz:
Ich freue mich auf einen weiteren, spannenden Gedankenaustausch! Und abschließend möchte ich noch betonen: Ich habe in diesem wie in allen anderen Themen nicht den Anspruch, „richtig“ zu liegen. Vielmehr geht es mir um den Austausch unterschiedlicher Positionen und Perspektiven. Aber ich gebe auch zu: Zu diesem Thema habe ich in den letzten Jahren eine Position entwickelt, die ich hier gerne dem kritischen Diskurs preisgebe.
Angenommen, wir hätten die Möglichkeit, das alte hinter uns zu lassen, würdest Du, lieber Stefan, dann auch noch dieses Modell aufstellen? Derzeit scheint die Projektarbeit stetig zuzunehmen. Was bleibt dann noch von der Prozessarbeit über? Kann ich die nicht gleich über die Projektarbeit/-organisation mit abwickeln (und verzichte darauf, daß es immer ein Anfang-Ende-Szenario geben muß). Wenn ich Projektarbeit auch agil abbilden kann bzw. diese immer häufiger agil abgebildet wird, warum sollte ich dann noch unterscheiden zwischen Pionier- und Projektarbeit. Ich stell mir schon länger die Frage, ob Nils Pfläging mit seiner Organisation für Komplexität nicht den besseren Ansatz verfolgt. Sicher bleibt abzuwarten, wie disruptiv die Märkte in Zukunft agieren. Aber im Worst-Case scheint mir sein Modell tragfähiger ;-).
Zwei kurze Gedanken dazu:
Ein wirklich sehr interessanter Artikel. Der Managementbegriff ist sehr vielfältig. Als Oberbegriff bezeichnet dieser die Funktion der Unternehmensleitung. Aus diesem Grund ist hierfür oftmals auch der Begriff der Unternehmenssteuerung anzutreffen. Auf der anderen Seite kann die Unternehmensführung in einzelne Teilbereiche untergliedert werden. Hier gibt es eine ganze Reihe von möglichen Untergliederungen. Die Managementbereiche sind von der Größe sowie der Organisation eines Unternehmens abhängig, wobei sich die Organisation bereits aus dem Bereich des Organisationsmanagements / Unternehmensführung ergibt. Eine gezielte Einteilung und Steuerung der Managementbereiche ist maßgeblich für den Erfolg einer Unternehmung. Das Managementverständnis stellt den Grundbaustein einer erfolgreichen Unternehmenszukunft, dar.