Als verantwortungsvoller Projektmanager ist man immer bemüht um das richtige Maß an Spannung und Anforderung im Projektteam. Nicht zu viel, jedenfalls nicht zu lange zu viel, aber auch nicht zu wenig. Ein Zustand des Fließens, in dem konzentriert und ruhig gearbeitet werden kann. Das Gefühl im Team alles schaffen zu können. Gelingt natürlich nicht immer und wenn es gelingt, ist dieser Gleichgewichtszustand ständig bedroht. Auch und gerade durch die umgebende Multiprojekt-Organisation, die stabil laufende Projekte als Ressourcenpuffer für weniger gut aufgestellte Projekte betrachtet.
Multiprojekt-Organisationen führen mit einer gemeinsamen Menge an Mitarbeitern gleichzeitig voneinander unabhängige Projekte durch. Das hat ohne Frage Vorteile. Hochspezialisierte Experten, die jedes Projekt braucht, aber eben nur zu einem Bruchteil, können ihre Kapazität mehreren Projekten zur Verfügung stellen und so effizient eingesetzt werden. Außerdem erreicht man durch die gleichzeitige Bearbeitung von mehreren Projekten in der Regel eine höhere Auslastung der Mitarbeiter wie bei rein sequentieller Bearbeitung der Projekte, weil Schwankungen der Teamstärke besser kompensiert werden können.
In einer solchen Multiprojekt-Organisation ist es also nicht ungewöhnlich, sondern sogar prinzipiell gewünscht, dass Mitarbeiter zwischen den Projekten während der Projektlaufzeit wechseln. Wenn beispielsweise in Projekt A die wesentlichen Weichen schon gestellt sind und der Weg bis zur Abnahme eigentlich klar erscheint, kann es gut sein, dass der erfahrene Systemarchitekt schon in Projekt B wechselt, das gerade in der Konzeptionsphase die Architektur festlegt und diese Weichen erst stellen muss. Klingt gut. Jedenfalls so lange es in Projekt A nicht zu einer größeren Änderung oder Katastrophe kommt. Dann geht der Kampf um die Kapazität dieses einen Systemarchitekten los.
In diesem Kampf kommt es in erster Linie darauf an, welcher Projektmanager die schlimmeren Folgen eines Abzugs des umkämpften Mitarbeiters darstellen kann. Wenn ich nun mein Projekt in den eingangs beschriebenen Gleichgewichtszustand gebracht habe, dann habe ich in der Regel in diesem Kampf die schlechteren Karten. Charakteristisch für diesen Zustand ist ja gerade eine vernünftige Auslastung und damit ein gewisser Puffer um Unvorhergesehenes abzufedern. Insofern kann man den Abzug eines woanders dringender benötigten Mitarbeiters schon kompensieren.
In einer Multiprojekt-Organisation gewinnen also diese Ressourcenkonflikte tendenziell diejenigen Projekte die weniger gut aufgestellt sind. Solange bis es keine Projekte in einem gesunden Gleichgewichtszustand mehr gibt und alle hektisch und überlastet arbeiten, weil jegliche Puffer zur Kompensation umverteilt wurden. Die Multiprojekt-Eskalationsspirale hat ihren oberen Endpunkt erreicht. Folglich tendieren aufgrund dieser Umverteilungspraxis alle Projekte einer Multiprojekt-Organisation Richtung Mittelmaß und alle Teams Richtung Überlast.
(Bildnachweis: Das Artikelbild wurde von ZeroOne unter dem Titel „Spiral staircase“ auf Flickr unter einer Creative Commons Lizenz (CC BY-SA 2.0) veröffentlicht.)
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.
27 Kommentare
Hallo Marcus,
deine systemische Beschreibung der Eskalationsspirale ist sehr gut getroffen – diese Situation sehen wir (als Berater) in fast jedem Unternehmen zu dem wir gerufen werden. Und irgendwie fehlt in deinem Blog-Artikel die Lösung für die Eskalationsspirale…
Aber wenn man ein systemisches Problem lösen will muss man an die grundlegenden Glaubenssätze ran. Hier mal ein paar Beispiele, wie man die Multiprojektsteuerung noch denken kann – nämlich nicht als lokale Optimierung von drei Rollen – sondern als abgestimmtes Konzert aller drei Beteiligten:
#1 man könnte die Rolle des Projektmanager auch anders definieren. Der Projektmanager als derjenige, der einen guten steuerbaren Projektplan verantwortet – also gute Auftragsklärung, gute Strukturierung und Klärung der Verantwortlichkeiten. Nix mit Kampf um Ressourcen.
#2 man könnte (oder ist er das nicht schon) den Teamleiter für den ungestörten Fluss verantwortlich machen? Er wäre dann verantwortlich, dass seine Leute top befähigt sind und ungestört arbeiten dürfen! Er würde seine Ressourcen immer dem Projekt geben, das es am nötigsten hat.
#3 das obere Management ist dafür verantwortlich, dass kein Team (z.B. gerade die Experten) überlastet ist. So dass alle im Fluss arbeiten können und der beste Output (Durchsatz) entsteht.
Wenn man dann das Prinzip einführt, dass das Projekt mit der größten Schieflage – alle notwendige Aufmerksamkeit bekommt – was übrigens super sinnvoll ist, da ja am Schluss nur der Erfolg des ganzen Portfolio zählt – funktioniert das ganze ohne Eskalationsspirale.
Die Knackpunkt sind a) wie macht man das, dass kein Team überlastet ist? und b) woran erkennt ich die operative Schieflage eines Projektes?
a) ist einfach wenn man am Engpass (z.B. den Experten) die Projekte wie auf einer Perlenschnur aufreiht (staffelt). Das obere Management sieht ob sie die Aufgabe richtig gemacht haben, wenn weniger als 10% der Projekte „rot“ (in Schieflage) sind.
b) ist auch einfach, wenn man die ganzen versteckten Puffer aus den Arbeitspaketen nach hinten packt, kann man die Schieflage über das Verhältnis von Fortschritt (auf der kritischen Kette) zu Pufferverbrauch jeden Tag ermitteln. Mehr Pufferverbrauch als Fortschritt = rot.
… das hört sich jetzt alles vielleicht verrückt an – ist aber seit ca. 20 Jahren als Critical Chain bekannt (auf Open-PM gibt es einen entsprechenden Artikel https://www.openpm.info/display/openPM/Critical+Chain ). Es gibt immer mehr Unternehmen, die darauf umstellen – einfach weil der Kampf zu viel Energie kostet und die Menschen beschädigt. Der letzte Erfolgsbericht für Critical Chain ist Mazda – die haben durch die Umstellung 50% Projektlaufzeit und 30 – 40% Aufwand im Projekt gespart.
Cu Wolfram
p.s.: die Einführung von Critical Chain ist dann nicht ganz so einfach – hier gilt es die alten „Kämpfer“-Glaubenssätze aus den Köpfen des mittleren Managements zu entlernen und die neue zu etablieren. Aber das ist ja unser Geschäft!
Wie Du schon richtig feststellst, ging es mir weniger um eine Lösungsfindung und mehr um die Beschreibung des Problems. Danke, dass Du auf Critical Chain als eine mögliche Lösung hinweist. Ich kann nicht beurteilen, inwieweit das tatsächlich hilfreich ist, will Dir das aber gerne glauben. Aber nicht als Patentrezept, sondern als eine Lösung in einem großen Lösungsraum. Deinen Enthusiasmus für Critical Chain in Ehren, aber Deine Kommentare und Artikel haben für mich immer ein klein wenig zu sehr den Ton eines Sales-Pitch. Das macht es mir (und vermutlich auch einigen anderen) schwierig sich auf eine Diskussion einzulassen.
ooops ich wollte sicher nichts verkaufen …
… nur einladen mal über den Tellerrand hinauszuschauen. Die meisten Probleme, die wir im Multiprojektmanagement sehen (z.B. die Eskalationsspirale) hängen mit unserer Idee wie die Rolle des Projektmanager gestaltet ist zusammen – lokale Optimierung – mein Sohn würde „Over Powered“ dazu sagen. Die meisten Lösungen, die ich sehe (u.a. agile Methoden) sind leider nur Symptombehandlungen.
@Marcus – hast du eine Idee wie wir das mal diskutieren könnten – ohne, dass ich jemand auf die Füße trete? Aufrütteln ohne vor den Kopf zu stoßen?
Ich bin hier sehr interessiert – einfach wegen meinem Enthusiasmus, der dadurch genährt ist, dass ich das halt schon bei einer ganzen Reihe Firmen gesehen habe wie es funktioniert und das Leuchten in die Augen der Mitarbeiter zurück kommt …
Es klingt bei Dir leider meist so als wolltest Du etwas verkaufen. Für den Blick über den Tellerrand und den Link zu Critical Chain, das ja wirklich eine Lösung für das Problem sein könnte. Wenn Du aber so leidenschaftlich mit nur diesem einen Thema argumentierst, dann fühle ich mich immer an das Sprichwort erinnert, dass alles wie ein Nagel aussieht, wenn man nur einen Hammer als Werkzeug hat. Ist nicht böse gemeint, sondern als Feedback, wie das bei mir (und anderen vermutlich auch) ankommt. Wir können diese Thematik (also die Multiprojektthematik) gerne auf openPM oder noch besser in einer Session auf dem PM Camp in Dornbirn diskutieren.
Ich glaube, es greift zu kurz, nur auf den Ressourcenkonflikt abzuzielen. Das einzelne Projekt im Kontext eines Projektportfolios ist vollkommen anders zu bewerten, als aus Portfolio Sicht: Das Scheitern eines einzelnen Projekts ist aus Sicht des Projekts eine Katastrophe, aus Sicht des Portfolios aber vielleicht ein Schritt auf einer Lernkurve.
Nachdem wir nicht in einer idealen Welt leben, müssen wir auch lernen Widersprüche und Konflikte zu akzeptieren.
@Wolfram: Optimierungslösungen, wie Critical Chain suggerieren ein komplett anderes Weltbild und können aufgrund ihrer Effizienz mitunter gravierende Schäden anrichten. Wer Optimierungslösungen anpreist, gibt vor, zu wissen, was das Beste ist. In unserer komplexen Welt würde ich mir solch ein Wissen nicht anmaßen.
@Bernhard – das musst du mir mal erklären, warum man in einer nicht so idealen Welt mit Widersprüchen oder Konflikten leben muss – Suboptima wegen mir aber gleich Widersprüche und Konflikte … bald ist ja wieder PM-Camp in Dornbirn :-)
Und ja du hast Recht – Critical Chain Einführungen können „aufgrund ihrer Effizienz mitunter gravierende Schäden anrichten“. Daher bitte Achtung – nicht selbst versuchen! Systemische Veränderungen setzen ganz schön Energie frei – da muss man wissen was passiert …
… um Schäden zu vermeiden ist eben ein gewissen Menge Vorbereitung notwendig. Als erstes wird gecheckt ob Critical Chain überhaupt das Problem löst – ja wir wissen auch, dass es nicht immer und überall passt. Dann muss man checken, ob man die Effizienz überhaupt verkaufen kann – ohne Markt – Finger weg! Des weiteren Muss man die Manager abholen – erst die oberen, dann die Projektleiter und Teamleiter. Jeder muss verstehen, was in welcher Reihenfolge passiert und wie er sich in den neuen Rollen wieder findet. Last but not least – wird konsequent schrittweise vorgegangen – bei jedem Schritt wird gecheckt ob der Erfolg da ist und dann erst kommt der nächste.
Aber wenn man Problem im Multiprojektmanagement hat (und wer hat das nicht) – dann sind massiv kürzer Projektlaufzeiten (25%-50%), hohe Zuverlässigkeit (>90%) und mehr Durchsatz (+50.…%) ohne neue Kosten einfach nicht von der Hand zu weisen – dafür kann man dann auch mal einen anspruchsvolleren Change wagen :-)
cu Wolfram
p.s.: die Systemtheorie besagt, dass komplexe Systeme dadurch beherrschbar werden, dass wir sie in ihren Freiheitsgraden beschränken – sprich ein „Constraint aufprägen“ … das Multiprojektmanagement erscheint uns aktuell so komplex, weil es zu viele Freiheitsgrade hat (die frei rumrennenden Projektmanager) – sobald man diese Freiheit begrenzt entsteht Stabilität und nebenbei noch neue emergente Eigenschaften – wie Flow :-) und Kompatibilität zu agilen Methoden …
Der Ressourcenkonflikt ist natürlich nur einer von mehreren möglichen in einer komplexen Multiprojektlandschaft, wenngleich der prominenteste. Mir ist objektiv vollkommen klar, dass das Projekt im Projektportfolio anders zu bewerten ist und dennoch fühle ich mich als Projektleiter „bestraft“, wenn ich mein Projekt sauber aufstelle und dann von Außen durch andere Projekte in Bedrängnis gebracht werde. Ich habe oft das Gefühl, dass einfach die Projekte die am schlechtesten dastehen die meiste Aufmerksamkeit bekommen und tendenziell auch die Ressourcen. In letzter Konsequenz führt das meiner Meinung nach zu einer Verschlechterung für alle Projekte des Portfolios.
Das „Basisübel“ von all dem ist auch, dass alles als „Projekts“ betrieben wird. Wir sollten mal darüber nachdenken, die Menge an Projekten radikal zu beschränken. Mehr dazu im Kapitel „Kontinuierliche statt projektspezifsch fragmentierte Lieferungen von Produkt- und Serviceinkrementen“ in http://www.symposion.de/kapitel40600101_WERK0003442.html
Die Projektinflation ist sicherlich eine Ursache die hier mit hinein spielt. Siehe auch Und hinter tausend Projekten keine Welt
Hallo Marcus und alle Kommentatoren,
die Spirale ist präzise und zutreffend beschrieben, ich habe sie leider häufiger als mir lieb war erleben „dürfen“.
Leider habe auch ich kein Patentrezept, nach dem Motto „ man nehme … und dann wird es schon“. Aber es gibt einige Ansätze, mit deren Hilfe das Leben leichter wird.
1. „Viel hilft viel“.
Häufig handeln Führungskräfte nach dem Motto: „Ein Projekt geht immer noch rein“. Damit haben sie sogar recht, aber Effizienz und Motivation der Projektmitarbeiter sinken regelmäßig und die Ergebnisse verschlechtern sich häufig auch.
2. „Bei uns sind alle Projekte gleich wichtig.“
Diesen Sager höre ich oft von verantwortlichen Führungskräften, die bei ihren Projekten keine Prioritäten setzen können oder wollen.
Durch beide Punkte wird die Eskalationsspirale sicher und zuverlässig gestartet. Meist geht es sogar einige Zeit gut, bis dann die ersten Projekte anfangen zu rauchen und zu brennen und plötzlich und unerwartet gibt es eine Form der Projekt-Priorisierung – wenn auch nicht immer die eigentlich sinnvolle und erwünschte. Und dann beginnen die Feuerwehraktionen für diese Projekte und die Kollateralschäden treffen die anderen Projekte.
Dabei ist die Priorisierung von Projekten ist gar nicht so schwierig – sogar ohne komplexe Tools. Eine Mischung aus systemischen Denken und gesundem Menschenverstand reicht aus. Wenn alle Projekte regelmäßig unter dem Gesichtspunkt der Dringlichkeit, der Wichtigkeit, des finanziellen und personellen Aufwands und des (realistisch) zu erwartenden Nutzen betrachtet werden, ergibt sich leicht eine sinnvolle Reihung.
Und nach dem Motto „weniger ist mehr“ sollten dann nur die Projekte mit der höchsten Priorität gestartet und umgesetzt werden, die Zahl ergbt sich dann aus den verfügbaren Ressourcen. Dabei setze ich natürlich eine einigermaßen ehrliche und realistische Planung der Projekt voraus, sonst wird das nichts.
Meine Erfahrung: die Konzentration auf einige wenige Projekte ist auf Dauer immer erfolgreicher als zu viele Projekte gleichzeitig.
JA!!! Und bei der Konzentration auf WENIGE Projekte als „Projekte“ nur das bearbeiten, was TATSÄCHLICH eine zeitlich befristete, relativ innovative und risikobehaftete Aufgabe von erheblicher Komplexität mit beachtlicher Schwierigkeit und Bedeutung darstellt.
Sehr viele „Kundenprojekte“ etwa sind dann gar keine solchen „Projekte“ sondern „Auftragsabwicklungen“, deren Management (auch der Ressourcen) – weil sie überraschungsfreier sind – weitaus mehr standardisierbar als jenes von Projekten ist.
Ja, da stimme ich sofort zu. Wenn im Unternehmen bzw. in der Organisation niemand wissen kann oder wissen will, welche Aufgaben Projekte sind und welche nicht, dann gibt es große Probleme. Das reicht von „hurra, bei uns gibt es nur noch Projekte“ bis hin zu “ wir brauchen keine Projekte, eine Arbeitsgruppe oder eine Task Force reichen doch aus“ – beide Ansätze sind weder zielführend und noch erfolreich. Hier sehe ich, wie auch Wolfram Müller in seinem #3, das obere Management in der Pflicht und Verantwortung die Projekte von den „Nicht-Projekten“ abzugrenzen, möglichst einfach und verständlich. Dabei geht es primär nicht um die wissentschaftliche richtige, sondern eine für das Unternehmen bzw. die Organisation erfolgversprechende Lösung.
Hallo Klaus, vielen Dank für Deinen Kommentar. Das glaube ich Dir gerne, dass Du diese Situation schon viel zu oft erleben musstest. Mit der entsprechenden Auswirkung auf die Motivation der betroffenen „Ressourcen“ …
Die beiden von Dir ausgemachten Indikatoren, „Viel hilft viel“ und „Bei uns sind alle Projekte gleich wichtig“, halte ich auch für maßgeblich beteiligt am Entstehen der Eskalationsspirale. Die Kunst bei der Priorisierung der Projekte liegt tatsächlich in der Konzentration auf eine beherrschbare Menge. Wenn wir nun aber, wie bei vielen IT-Dienstleistern üblich, das Management hauptsächlich an der Auslastung ihrer Mannschaft messen und vielleicht noch – es lebe das Management by Objectives – entsprechend dieses Ziels entlohnen, dann nimmt das Unheil seinen Lauf …
Danke für dieses spannende Thema, Marcus.
Ich denke, die Problematik ist so vielfältig, dass wir hier keine Lösung finden werden. Denn es wurde schon mehrfach angesprochen: In komplexen sozialen Systemen gibt es keine Patentrezepte, die zum Gelingen beitragen.
Sehr wohl aber gibt es PRINZIPIEN, die man einhalten sollte. Wenn wir beispielsweise TOC nicht nur als Methode und Ansatz verstehen, sondern die Prinzipien dahinter verstanden haben, stimme ich Wolfram zu, dass dies ein Weg sein kann.
Grundsätzlich aber unterstütze ich Marcus Herangehensweise, nicht sofort in Lösungen zu denken, sondern zuerst mal das Problem gemeinsam zu elaborieren. Einstein hat es damals sehr treffend formuliert:
„Die reine Formulierung eines Problems ist oftmals weit wichtiger als seine Lösung. Neue Fragen aufzuwerfen, neue Möglichkeiten zu finden, alte Probleme aus einem neuen Blickwinkel zu betrachten, erfordert schöpferische Vorstellungskraft und macht die wirklichen Fortschritte in der Wissenschaft aus.“
Denn wenn Wolfram schon mehrfach den Begriff „systemisch“ verwendet, so bin ich der Ansicht, dass ein systemisches Herangehen zuerst erfordert, das Problem und die damit verbundenen Fragestellungen richtig zu verstehen. Hier sollten wir aus meiner Sicht in jeder Diskussion beginnen, wenn es um komplexe Zusammenhänge und Phänomene geht.
Kann ich alles nur unterschreiben :-)
Komplexe Systeme haben einen ganz besonderen Reiz – man kann mit wenigen Maßnahmen drastische Veränderungen (Verbesserungen) erzielen. Das ist das, was ich manchmal etwas zu stark hervorhebe – die super Erfolge!
Gleichzeitig steigt aber der Anspruch/Aufwand, das System zuvor zu verstehen „das Problem zu formulieren“. Also genau die ein/zwei Maßnahmen zu identifizieren, die dann die gewünschte neue Systemeigenschaft hervorbringen.
Ganz wichtig ist auch, dass hier ein Berater gar nicht richtig helfen kann – die Erkenntnisse müssen aus den Leuten selbst herauskommen – „sie müssen die Lösung sehen“. Daher gilt es die Prinzipien (system thinking u.a.) zuvor zu transportieren/übergeben. Aber genau hierzu müssen wir „Berater“ ebene eine ganze Fülle von Wissen um Systeme und auch über Lösungen mitbringen.
Ich finde es schön, dass hier die TOC angesprochen wird – hier sind ganz viele hilfreiche systemisch Ideen zu finden, die „manchmal“ ganz erstaunliche Vereinfachungen ermöglichen :-)
p.s.: die Idee von Stefan über die komplexen Zusammenhänge und Phänomene zu diskutieren halte ich für super spannend … das sind übrigens die Current-Reality-Trees der TOC
cu Wolfram
Danke für Deinen Kommentar, Stefan. Allein die Anzahl und Vielfalt der Kommentare zeigt mir, dass es einerseits ein wichtiges Problem ist, es aber andererseits kein Patentrezept geben kann. Insofern bin ich Deiner Meinung, dass wir erst Mal das Problem verstehen sollten bevor wir in Lösungen denken. Ich merke mir das Thema auf jeden Fall Mal vor für das PM Camp 13 im November.
Das möchte ich hinterfragen:
„nicht sofort in Lösungen zu denken, sondern zuerst mal das Problem gemeinsam zu elaborieren .… Die reine Formulierung eines Problems ist oftmals weit wichtiger als seine Lösung … dass ein systemisches Herangehen zuerst erfordert, das Problem und die damit verbundenen Fragestellungen richtig zu verstehen“
Die Idee, zuerst das Problem verstehen zu müssen ehe man Lösungen entwickeln kann, passt nicht zu jeder Art von Problemstellungen. Ich gehe mal (gemäss C. Kurtz, D. Snowden: The New Dynamics of Strategy: Sense-making in a Complex-Complicated World. In: IBM Systems Journal. vol. 42, no. 3 2003, S. 462 – 83) davon aus, dass es diese Sichtweisen von Problemstellungen gibt:
„“
Das Cynefin-Framework hat fünf Domänen. Die ersten vier davon sind:
o Simple, in der die Beziehung zwischen Ursache und Wirkung für alle offensichtlich ist. Die Heransgehensweise ist hier Sense – Categorise – Respond, und wir können bewährte Praktiken (best practice) anwenden.
o Complicated, in der die Beziehung zwischen Ursache und Wirkung Analyse oder eine andere Form der Prüfung erfordert und/oder die Anwendung von Fachwissen. Hier geht man mittels Sense – Analyze – Respond heran, und man kann gute Praktiken (good practice) anwenden.
o Complex, in der die Beziehung zwischen Ursache und Wirkung nur im Nachhinein wahrgenommen werden kann, aber nicht im Voraus. Hier ist der Ansatz Probe – Sense – Respond, und wir können emergente Praktiken (emergent practice) feststellen.
o Chaotic, in der es keine Beziehung zwischen Ursache und Wirkung auf Systemebene gibt. Hier ist der Ansatz Act – Sense – Respond, und wir können innovative Praktiken entdecken.
Die fünfte Domäne ist Disorder, der Zustand des Nicht-Wissens, welche Art von Kausalität besteht. In diesem Zustand gehen die Leute in ihre eigene Komfort-Zone zurück, wenn sie eine Entscheidung fällen.
„“
Vor diesem Hintergrund macht eine ausgiebige Problemanalyse nur bei als simpel oder kompliziert erscheinenden Fragestellungen Sinn. Das sind u.a. Fragestellungen im technisch-naturwissenschaftlichen Bereich (und darauf bezog sich Einstein). Bei „komplex-adaptiven“ Systemen jedoch, so etwa sozialen Handlungssystemen (und dazu gehören auch Projekte), ist die ausgiebige Problemanalyse nicht angemessen. Im Gegenteil: Sie führt vom Hundertsten ins Tausendste .… und schlussendlich zu einer alles weitere Denken blockierenden „Problemtrance“. Im Projektkontext sind das z.B. jene Meetings, die monatelang alle möglichen „wenn und aber“ produzieren … aber keinerlei Fortschritt.
Bei komplex erscheinenden Situationen ist es besser, statt das Problem „wirklich“ verstehen zu wollen so rasch als möglich mit einem ersten Lösungsschritt zu beginnen, also „inkrementell-adaptiv“ vorzugehen.
Von Steve de Shazer stammen dazu diese „irritierenden“ Aussagen:
„Problem talk creates problems, solution talk creates solution.“
„Die detaillierte Untersuchung und Analyse des Problems hat auf die Lösungsfindung keinen Einfluss“
„Probleme sind Probleme weil wir sie „Probleme“ nennen“
Mehr dazu hier:
http://www.solworld.org/notes/Jumpstart_into_Solution_Focus
Hi, der Thread wird ja immer besser … das Cynefin-Framework is IMHO sehr interessant und hebt sich wohltuend von den anderen Komplexität-Chaos-Abgrenzungen ab, in dem es 5 Felder definiert und somit die Welt, wie ich sie wahrnehme, besser abbildet.
Auf der TOCICO 2013 in Bad Nauheim wurde noch eine weitere Möglichkeiten diskutiert den komplexen Bereich zu adressieren. In der Tat ist der Versuch das komplexe System in all seinen Übertragungsfunktionen vorherzusehen fruchtlos (das ist wie Wettervorhersage). Was aber auch in komplexen Systemen geht ist – die Charakteristik und die Wirkzusammen hänge zu verstehen – ohne dieses Verstehen kann man keine Eingriffe in das System vornehmen ohne es zu gefähren und ins Choas zu treiben. Die TOCler reden daher nicht von Problem-Talks – sondern von Current-Reality-Tree. Also wie sieht unsere Wirklichkeit gerade aus – wobei nur die Wirkzusammenhänge von Relevanz sind.
Steve Holt (Associate Technical Fellow Boeing und Board Member Theory of Constraints International Certification Organization (TOCICO)) hat auf der TOCICO einen super Vortrag gehalten wie die alternative zu „rumprobieren – alias inspect and adapt“ bei komplexen systemen aussehen kann. Die Systeme erscheinen uns so komplex weil sie zu viele Freiheitsgrade haben – der Trick ist also – die Freiheitsgrade zu begrenzen (ein „Constraint“ aufzuprägen) – an dem kann sich dann wieder allses ausrichten – der Constraint liefert das Steuersignal und ermöglich strategische Entscheidungen.
z.B. ein Flughafen ist definitiv ein komplexes System – die Landebahn ist der aufgeprägte Constraint … oder im Automobilbau – die „Hochzeit“ ist der Constraint nach dem sich alles richtet … oder im Anlagenbau ist es die Inbetriebnahme … oder in „normalen“ Unternehmen die Produkte entwicklen und produzieren ist es der Übergang in die Produktion …
alle großen komplexe Systeme haben einen Constraint um die Freiheitsgrade zu reduzieren – ansonsten wären sie Chaos und damit auf Dauer nicht lebensfähig.
Emergente Systemeigenschaften entstehen übrigends nur und genau in dem Moment in dem das System in den Freiheitsgraden begrenzt wird – von alleine emergiert tatsächlich auch nichts. Diese Erkenntnis kommt aus der Thermodynamik und ist noch älter als TOC. In dem Moment in dem man nicht mehr die Bewegung aller Atome berechnen will – hat man Thermodynamische Gleichungen auf eine höheren Abstraktionsebene eingeführt (Temperatur) – damit das Ganze aber wieder stimmig wird musste man die Entropie einführen. Sprich nur durch die Begrenzung der Komplexität ist die neue Eigenschaft entstanden.
cu Wolfram
p.s.: ich darf kein Link auf die Präsentation rausgeben – auf Anfrage eine rausschicken ist ok Steve hat da nichts dagegen …
Hans-Peter,
danke für Deinen tollen Input. Du hast vollkommen recht – ich war in der Wahl der Sprache zu unpräzise.
„…das Problem und die damit verbundenen Fragestellungen richtig zu verstehen…“ ist für komplexe Systeme nicht korrekt. Denn komplexe Systeme / Probleme kann man nicht verstehen.
Ebenfalls stimme ich Dir zu, dass für komplexe Probleme nach dem Cynefin Modell der Lösungsfokus angewendet werden sollte (siehe hierzu z.B. die Beschreibung von Paul Bayer: http://www.wandelweb.de/blog/?p=1110)
Allerdings gibt es auch andere Ansätze, Modelle und Theorien, die meines Erachtens nicht weniger relevant sind. Aber wir sollten tatsächlich beim PM Camp eine oder zwei Sessions dazu machen ;-)
Viele Grüße, Stefan
Das Problem ist doch, was ist eine angemessene Auseinandersetzung mit der Problemstellung: Auch bei komplexen Situationen sollte ein Problembewusstsein vorhanden sein, sonst mutiert die Lösungsfindung zum reinen Aktionismus. Also zumindest um eine rudimentäre Auseinandersetzung mit der Problemstellung wird man in keinem Fall umhin kommen.
Was bringt eine Auseinandersetzung mit der Problemstellung vor diesem Hintergrund:
Complex, in der die Beziehung zwischen Ursache und Wirkung nur im Nachhinein wahrgenommen werden kann, aber nicht im Voraus. Hier ist der Ansatz Probe – Sense – Respond, und wir können emergente Praktiken (emergent practice) feststellen.
UND:
“Problem talk creates problems, solution talk creates solution.”
“Probleme sind Probleme weil wir sie “Probleme” nennen”
??
Das Übertragen von problemorientierten Lösungsstrategien, die im technisch-naturwissenschaftflichen (= komplizierten) Bereich angemessen sind auf komplexe Situationen ist eine „schlechte Gewohnheit“!
Hi,
WENN: Complex, in der die Beziehung zwischen Ursache und Wirkung nur im Nachhinein wahrgenommen werden kann, aber nicht im Voraus.
Dann hat man zwei Möglichkeiten (nicht nur eine)
a) Hier ist der Ansatz Probe – Sense – Respond, und wir können emergente Praktiken (emergent practice) feststellen.
b) man verändert das komplexe System so dass es wieder beherrschbar wird
Ich wollte nur ein bisschen den Tellerrand öffnen, dass es noch mehr Möglichkeiten gibt – als sich der Komplexität ergeben. By-the-way Scrum, Kanban nutzen diesen Mechanismus massiv in dem sie das System Begrenzen (Timeboxes oder WIP-Limits)
Ach so man hat auch noch eine dritte – in Hochinnovationssystemen (tendieren zum Chaos) macht weder a) noch b) Sinn … hier können c) hochitterative Design Thinking o.a. Innovationstechniken zum Zug kommen
cu Wolfram
p.s.: dein Statement find ich sympathisch „Das Übertragen von problemorientierten Lösungsstrategien, die im technisch-naturwissenschaftflichen (= komplizierten) Bereich angemessen sind auf komplexe Situationen ist eine “schlechte Gewohnheit”!“ … würde es aber trotz dem als persönliches Statement von dir stehen lassen – es enthält keine systemisch Begründeten Argumente, Annahmen und persönliche Wertungen ;-)
Zu dem:
„man verändert das komplexe System so dass es wieder beherrschbar wird“
1)
Ein System kann kann ich nur dann verändern, wenn es von mir in der von mir gewünschten Weise veränderbar ist. Bei von mir als komplex gesehenen Systemen ist das leider nicht der Fall .… sonst wären sie ja nicht komplex sondern kompliziert.
2)
Weder „Systeme“ noch deren deren Merkmale (kompliziert, komplex, …) sind „objektive Tatsachen“ sondern meine / unsere Konstruktionen und Zuschreibungen auf Basis dessen, war wir wahrnehmen (oder, besser, „wahrgeben“) und denken können.
3)
Möglich ist es, ein zunächst als „komplex“ betrachtetes „System“ anders zu betrachten, nämlich so, dass ich das, was ich als „System“ betrachte (z.B. seinen Grenzen anders setze) oder mich entscheide, den Ansatz Probe – Sense – Respond und die emergenten Praktiken aufzugeben und mich statt dessen dafür entscheide, mit Sense – Analyze – Respond heranzugehen, also gute Praktiken (good practice) anzuwenden.
ALSO:
Es liegt an mir/uns, was wir als „System“ betrachten und welche Charakteristik wir ihm zuschreiben und mit ihm dementsprechend umgehen.
Es gibt keine „objektiven“ Kriterien für „kompliziert“ oder „komplex“. Ob etwas kompliziert oder komplex ist, ist eine „unentscheidbare Frage“, siehe Heinz von Förster. Und nur die „unentscheidbare Fragen“ sind – nach ihm – „echte“ Fragen. So etwa die Frage: „Gibt es eine Leben nach dem Tod?“
Die Antworten können wir nicht „wissenschaftlich entscheiden“, aber wir müssen uns für eine Antwort entscheiden – und Verantwortung gegenüber uns und der Welt für unsere Entscheidung übernehmen.
Wenn wir und also entscheiden, etwas „kompliziert“ zu sehen und es mittels Sense – Analyze – Respond behandeln, dann tragen wir auch die Verantwortung die daraus entstehenden Folgen.
Bei Projekten etwa die Verantwortung dafür, dass es klappt – oder in die Hosen geht.…
Zu dem:
„es enthält keine systemisch Begründeten Argumente“
Was, bitte, sind „systemisch begründete Argumente“? Insbesondere im Unterschied zu „nicht systemisch begründete“?
Was genau meinst du mit „systemisch“?
(Ich frage das vor dem Hintergund meines vor vielen Jahren absolvierten postgraduate Studiums zu „systemisches Managment komplexer Projekte“ an der Uni Zürich… dank dessen ich immer noch nicht genau weiss, was „systemisch“ bedeutet…)
Danke Hans-Peter für die letzte Ausführung – ich hab nichts mehr hinzuzufügen – ich hab gerade vie gelernt :-)
a) z.B. ich bevorzuge wohl Systeme, die ich verändern kann (ist wohl in meiner Persönlichkeit – ich bin Macher) – daher sehe ich Systeme of als kompliziert – entscheide mich für ensprechende Methoden und ernte dann die entsprechenden Erfolge :-)
b) „Am Schluss geht es darum sich für eine Antwort zu entscheiden und die Verantwortung zu übernehmen …“ das ist zitierfähig – darf ich das verwenden?
Wolfram
p.s.: das mit dem „nicht systemisch begründet“ war nicht sonderlich ernst gemeint – aber deine Antwort ist klasse „… dank dessen [Studium] ich immer noch nicht genau weiss, was “systemisch” bedeutet …“ – das trifft es gut – je tiefer man sich mit etwas befasst desto mehrschichtiger stellt sich oft die Situation dar :-)
Zu dem:
“ “Am Schluss geht es darum sich für eine Antwort zu entscheiden und die Verantwortung zu übernehmen …” das ist zitierfähig – darf ich das verwenden?“
Du kannst das Original zitieren:
„“
H.F. Eine entscheidbare Frage wird immer innerhalb eines Rahmens entschieden, der die mögliche und jeweils richtige Antwort bereits vorgibt.
B. P. Was sind unentscheidbare Fragen?
H.F. Das sind Fragen, die etwa von der Existenz höherer Wesenheiten, dem Sinn des Lebens, der Entstehung der Welt und dem Weiterleben nach dem Tod handeln. … Ich würde sogar sagen, daß die Frage unentscheidbar ist, ob sich ein Experiment finden läßt, das eindeutig erweist, ob es sich um eine unentscheid-bare Frage handelt. … Und in dem Moment, in dem ich eine unentscheidbare Frage entschieden habe, kommt die Verantwortung ins Spiel. Man entschließt sich, die Dinge, die Welt und seine Mitmenschen auf eine besondere Weise zu betrachten und entsprechend zu handeln. Man wird verantwortlich für die Entscheidung, die man getroffen hat und die einem niemand abnehmen kann.
„“
Quelle: Wahrheit ist die Erfindung eines Lügners
Heinz von Foerster (H.F.) /Bernhard Pörksen (B.P.)
Gespräche für Skeptiker
Carl-Auer-Systeme Verlag
Sehr unterhaltsam zu lesen !!!!! Und ein nur dünnes Buch .…
Vielen Dank für die rege und unglaublich anregende Diskussion. Ich schließe mich Wolfram an: Ich habe viel gelernt! Insbesondere erhellend war die Erinnerung, dass es keine objektiven Maßstäbe gibt sondern letztlich alles meine Konstruktion ist. Auf Basis dessen entscheiden wir und dafür müssen wir die Verantwortung tragen.
Ich habe mir erlaubt dieses Thema zur Diskussion nach openPM zu übertragen. Eure Kommentare sind zu wichtig, so dass ich es schade fände, wenn sie hier im Blog blieben. Vielleicht findet ja der eine oder andere die Zeit und Muße einen Extrakt seiner Beiträge hier in den entsprechenden Artikel auf openPM einzuarbeiten (Kommentare gehen auch, aber einarbeiten in einen Artikel wäre schöner).