Bedürfnisse – Wünsche – Funktionen – Anforderungen

Der Anlass für ein neues System sind immer Wünsche und Bedürfnisse, die jemand hat. Man hat z.B. das Bedürfnis mit jemandem zu sprechen, wo immer man sich befindet. Also kauft man sich ein Mobiltelefon. Wenn man dieses eine Weile gebraucht hat wünscht man sich, man könne die am meisten gebrauchten Nummern speichern. Also kauft man sich ein Mobiltelefon mit Speicher. Nach einer Weile wünscht man sich, die Leute, die einem anrufen, könnten eine Nachricht hinterlassen, wenn man den Ruf nicht beantworten konnte. Also abonniert man eine Voice Mailbox. Dann sieht man jemand, der mit dem Mobiltelefon Musik hört oder ein Spiel macht. Also hat man plötzlich den Wunsch, ebenfalls mit dem Mobiltelefon Musik hören zu können, obwohl man von alleine gar nie auf diesen Wunsch gekommen wäre. Etc., etc.

  • Bedürfnisse sind zunächst diffus und allgemein. Sie haben folgende Eigenschaften:
  • Bedürfnisse können sich sowohl auf operative als auch auf strategische Funktionen beziehen
  • Bedürfnisse können nicht scharf formuliert werden
  • Bedürfnisse sind mehr Gefühl als Wissen und können daher nur eingeschränkt kommuniziert werden
  • Man ist sich zu keinem Zeitpunkt allen Bedürfnissen bewusst
  • Bedürfnisse entstehen während man sich mit dem System beschäftigt

Hat man sich lange genug mit dem System beschäftigt, dann werden einem die Bedürfnisse bewusst und man kann sie als Anforderungen formulieren. Dies geschieht aber meistens erst im Verlauf oder gar gegen Ende des Projekts. Anforderungen werden als Funktionen spezifiziert. Auch Eigenschaften eines Systems können als Funktionen formuliert werden. So sind z.B. die räumlichen Masse eines Autos eine Funktion, wenn es darum geht, das Auto in eine schmale Garage einzuparkieren.
Andreas Ninck et al. unterscheiden in Systemik – Vernetztes Denken in komplexen Situationen1 funktionale von nicht funktionalen Zielen. Nicht funktionale Ziele sind nach Ninck z.B. Wartbarkeits- oder Erweiterbarkeitsanforderungen. Aber auch die Wartbarkeit kann man als Funktionen spezifizieren. Z.B. ist die Forderung nach einer Backup-Funktion eine Wartbarkeitsanforderung. Soll ein System ausbaufähig sein, dann muss es Funktionen geben, um zusätzliches Memory oder eine zweite CPU zu erkennen, etc. Ein systemtheoretisch zentrales Thema ist die Lebensfähigkeit eines Systems. Auch diese lässt sich über autopoietische Funktionen diskutieren. Stafford Beer meint, dass ein System sich an seine sich stetig verändernde Umgebung anpassen können muss, damit von Lebensfähigkeit gesprochen werden kann. Es muss seine Identität bewahren, Erfahrungen aufnehmen und verwerten können, und es muss lernen und sich weiterentwickeln können. Das sind alles Systemfunktionen. Beer definiert in seinem Viable Systems Model fünf Systemlevel. Das sind Funktionskomplexe des Unternehmenssystems2. Man kann sich trefflich streiten, ob es nun noch etwas anderes gibt, als funktionale Ziele. Wir wollen zumindest in diesem Blog davon ausgehen, als seien alle Bedürfnisse und Ziele als Funktionen formulierbar.

Definitionen:

  • Bedürfnisse, Wünsche: (erstes) vages Bild mit diffusen Strukturen
  • Funktionen: möglichst klar strukturierte Bedürfnisse; möglicherweise können sich mehrere Funktionen überlappen
  • Anforderungen: Katalog von priorisierten Funktionen (muss, wenn möglich, kann, nice to have, etc.)

1Andreas Ninck, Leo Bürki, Roland Hungerbühler, Heinrich Mühlemann. Systemik – Vernetztes Denken in komplexen Situationen. Verlag Industrielle Organisation. Zürich 2004.

2Malik Management Zentrum. Das Modell Lebensfähiger Systeme (Stafford Beer). St. Gallen, 2006

Bye, bye Requirements Engineering

Im Zusammenhang mit Anforderungen sind die Funktionen eines Systems zentral. Auch blosse Eigenschaften können Funktionen sein. In Zertifiziert für das Unmögliche: Anforderungen formulieren habe ich gesagt, dass in Migrations- und Integrationsprojekten meistens Standardsysteme zum Einsatz kommen, die allenfalls customized werden. Solche Projekte können nicht vollständig spezifiziert werden, weil niemand in der Lage ist, alle Funktionen eines (Standard-)systems zu kennen. Denken Sie z.B. an ein Automobil, genauer gesagt, einen Personenwagen (PW). Glauben Sie, sie könnten die Funktionen eines PW aufzählen? Wahrscheinlich sind Sie nicht einmal in der Lage, auch nur 10% aller Funktionen eines PW aufzuzählen, und dies nicht nur wegen des Problems unterspezifizierter Initialkonditionen, von dem Fischhoff et al. berichten1. Es gibt immer auch hidden functions. Klaus Pohl berichtet, dass allein die Steuerung einer PW-Elektronik 2’500 Funktionen umfasst2. Jede dieser Funktion ist auch eine Funktion des PW. Natürlich interessieren Sie sich allenfalls für ein halbes Dutzend dieser Elektronikfunktionen, der Rest sind eben hidden functions, mit denen Sie sich gar nicht erst auseinandersetzen wollen. Aber können Sie sicher sein, dass sich nicht eine dieser 2’500 Funktionen für Sie negativ manifestieren wird? Es könnte doch sein, dass sich eine dieser unzähligen Funktionen mit der Zeit für Sie als lästig bemerkbar machen wird. In vollständigen Anforderungen an das System PW hätten Sie diese Funktion ausdrücklich untersagt, wenn Sie sie im Voraus gekannt hätten. Hidden Functions von IT-Systemen, die in komplexe Umgebungen eines informationsintensiven Unternehmens integriert werden müssen, stören oft andere Systeme, weil die Entwickler nicht alle Umgebungen kennen konnten, in welchen ihr System jemals in Einsatz gelangt.

Im übrigen gibt es Funktionen, die eigentlich Funktionenkomplexe sind. Beispielsweise ist doch die wichtigste Funktion eines PW, dass er fahren möge. Meinen Sie “fahren” oder “transportieren”? In jedem Fall verbirgen sich hinter beiden Funktionenkomplexen viele Einzelfunktionen, wie z.B. vorwärts fahren, rückwärts fahren, im Schritttempo vorwärts fahren, sehr schnell vorwärts fahren. Meinten Sie “transportieren”, so sind Einzelfunktionen eine Person transportieren, mehr als eine Person transportieren, im Rahmen des Strassenverkehrsgesetz transportieren, Waren transportieren, mehr als einen Kubikmeter Waren transportieren, usw. Die Unterteilung eines Funktionenkomplexes ist sehr willkürlich. Wann haben Sie hinreichend unterteilt? Wann haben Sie zu sehr fragmentiert? Was ist überhaupt noch eine Funktion? Schliesslich gibt es Sekundärfunktionen. Z.B. kann ein PW auch die Funktion haben, Ihnen gesellschaftliches Ansehen zu verleihen, oder zumindest Ihnen den Eindruck zu geben, dass Sie wegen Ihres PW zu mehr gesellschaftlichem Ansehen gelangen.

Ein System kann auch implizite Funktionen haben. Das sind solche, die niemand spezifiziert und entwickelt hat. Alle die 2500 Funktionen der Elektroniksteuerung mussten einzeln spezifiziert und implementiert werden. Auch die Funktion, gesellschaftliches Ansehen zu verleihen, wurde zumindest teilweise explizit spezifiziert, z.B. durch ein schnittiges Design oder durch entsprechendes Marketing. Ein Porsche kostet nicht nur so viel, weil er wirklich so gut ist, sondern auch, um eben den Namen Porsche als Nobelmarke zu platzieren. Aber ein PW kann auch Funktionen haben, die nicht spezifiziert worden sind.

Wie wir sehen ist es nie möglich, abschliessend zu sagen, wieviele Funktionen ein System hat oder haben kann. Bye, bye Requirements Engineering!

1B. Fischhoff, P. Slovic & S. Lichtenstein. Fault Trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of experimental psychology: Human Perceptions and Perfomance. 4/1978, 330-334

2Klaus Pohl. Leitfaden für modellbasiertes Requirements Engineering und Requirements Management softwareintensiver Eingebetteter Systeme
gefördert durch das BMBF im Rahmen der Forschungsoffensive “Software Engineering 2006″

Zertifiziert für das Unmögliche: Anforderungen formulieren

Wie wir aus dem Artikel Von nichts kommt nichts wissen, lassen sich Anforderungen nie abschliessend formulieren. Das macht die Projektarbeit so schwierig. Neuerdings gibt es schon wieder eine Zertifizierung, nämlich diejenige des Certified Requirements Engineers. Dieses Zertifikat gibt es gleich in drei Stufen, einen Foundation, einen Advanced und einen Expert Level. Und wieder steht eine ganze Industrie dahinter, mit vielen teuren Kursangeboten, Büchern und Instituten. Wieder werden Best Practices vermittelt, aber wenig systemische Erkenntnisse. Als ob Wissen durch pauken zustande käme. Die armen Projektleiter! Sie müssen nicht nur

  • das PM Book of Knowledge vom PMI
  • das CISM Review Technical Information Manual nach COBIT
  • den Spice ISO/IEC TR 15504-6 Standard
  • den CMMI SEI Technical Report CMU/SEI-2006-TR-008
  • das Buch Managing Successful Projects with PRINCE2 und
  • die IT Infrastructure Library, beides vom Office of Government Commerce

auswendig lernen, sondern jetzt auch noch Klaus Pohls Kompendium über Requirements Engineering1, um ihre Projekte genauso erfolglos wie bis anhin durchziehen zu dürfen. Und anstatt wirklich etwas zu lernen, müssen sie die Zertifikate für viel Geld periodisch erneuern lassen.
Das Problem der Anforderungen steht am Anfang eines jeden Projekts. Zu Beginn hat jeder Auftraggeber nur eine vage Vorstellung von dem, was er eigentlich will. Die Vorstellungen verdichten sich zu Bedürfnissen, während er sich mit dem Projektgegenstand befasst. Aus den Bedürfnissen schliesslich kondensieren konkrete Anforderungen. Die Emergenz von Anforderungen ist ein Prozess der Selbstorganisation und kann nicht einfach “engineert” werden. Meist muss das Projekt schon so gut wie fertig sein, wenn die Anforderungen beginnen, sich heraus zu kristallisieren. Ein Auftraggeber wünscht sich nicht nur Funktionen des zu bauenden Systems. Er will mit dem System vielleicht auch noch andere Ziele erreichen, wie z.B. strategische oder marketingbezogene Ziele. Beispielsweise sind die Hauptfunktionen eines Scannerkassensystems sowohl Schnittstelle zum Inventory System, um die Regale stets gefüllt zu halten als auch die Beschleunigung des Inkassovorgangs, um einen grösseren Durchsatz zu erreichen. Aber das Management könnte mit dem Kassensystem auch weitere Ziele verfolgen, wie z.B. Expansion des Marktanteils durch Einführung einer innovativen Technologie vor der Konkurrenz oder – umgekehrt – Schutz des Marktanteils durch Aufrücken zur Konkurrenz, die diese Technologie bereits früher eingeführt hat. Es ist nun denkbar, dass die Konkurrenz Scannerkassensysteme neu bewertet, noch während das Integrationsprojekt läuft. In diesem Fall muss der Auftraggeber seine Anforderung wieder neu definieren. Das geht aber nicht so schnell, wie es Pohl und seine Mannen gerne sehen möchten2. Die Gegebenheiten eines Marktes sind heute derart volatil, dass es unmöglich ist, die Ziele eines Migrations- oder Integrationsprojektes, das mehrere Monate dauert, zu Beginn abschliessend zu formulieren.

Weiter ist zu bedenken, dass softwareintensive Systeme heute immer weniger dediziert entwickelt werden. Im Allgemeinen werden sie in irgend einem Competence Center eines Herstellers entwickelt und dann auf dem Markt angeboten. Siehe z.B. ERP- und Bankenlösungen oder Softswitch Kommunikationslösungen, etc. Solche Systeme werden als Standardsoftware angeboten und in Integrations- und Migrationsprojekten ausgerollt. Kürzlich musste ich für eine Kommunikationsfirma ein Voice Messaging System migrieren. Das neue System wurde irgendwo in der französischen Provinz entwickelt. Das Migrationsprojekt dauerte ein Jahr und kostete (inkl. HW und SW) ungefähr eine Mio Euro. Natürlich hatte der Kunde Anforderungen. Vielleicht wurden diese durch das System unterstützt, vielleicht war die Entwicklung bereit, kleinere Anpassungen zu machen. “Zum Glück” wies das System Fehler auf. So konnte der Kunde beim Fixen der Mängel gleich noch ein paar seiner Wünsche mit einfliessen lassen.

Schliesslich weise ich immer wieder darauf hin, dass ein Auftraggeber erst dann die richtigen Fragen stellen und sie klar formulieren kann, wenn er sich eine Weile mit einem System beschäftigt und genügend Wissen über das System hat. Erst im Verlauf des Projekts ist der Auftraggeber in der Lage zu definieren, was er in bezug auf das System eigentlich gerne hätte. Das ist beim Bau eines Einfamilienhauses so und das ist bei der Integration eines komplexen Systems in die IT- und Prozesslandschaft eines Grossunternehmens so. Sogar noch dann, wenn das System bereits eingeführt ist und produktiv läuft wird der Betreiber immer wieder neue Anforderungen und Ausbauwünsche haben.

Anforderungen und Ziele von komplexen softwareintensiven Systemen lassen sich heute wegen der Volatiliät des Marktes nicht mehr abschliessend formulieren und definieren. Theorien des Projektmanagements und seines Umfeldes, wie Requirement Analysis, werden immer noch konventionell, auf einem linearen Ursache-Wirkungsdenken beruhend und ohne Berücksichtigung elementarster systemtheoretischer Tatsachen konzipiert. “Best Practices” gilt als chic obwohl es reines Frequencey Gambling ist und als das immer wieder zu fehlerhaften Entwicklungen führte3

1Klaus Pohl. Requirements Engineering – Grundlagen, Prinzipien, Techniken. Dpunkt Verlag, Heidelberg 2008 und
Klaus Pohl. Basiswissen Requirements Engineering – Aus- und Weiterbildung zum Certified Professional für Requirements Engineering – Foundation Level nach IREB-Standard.

2Frank Houdek, Klaus Pohl: Analyzing Requirements Engineering Processes: A Case Study. DEXA Workshop 2000: 983-990

3Harald Schaub. Menschliches Versagen. Universität Bamberg. 2000
Beim Frequency Gambling wir diejenige Maßnahme ergriffen, die in den bisherigen (oder ähnlichen) Situationen am erfolgreichsten war. Dies muss nicht notwendigerweise falsch sein, doch kann diese Strategie in neuen, unbekannten Situationen schwerwiegende Konsequenzen mit sich bringen. Innovation und Flexibilität sind dem “frequency-gambler” Fremdwörter, so dass neuartige Systemeigenschaften gar nicht in Rechnung gestellt werden

Wissen Sie, wie man ein Projekt abwickelt oder können Sie es?

Von Zeit zu Zeit erhalte ich per E-Mail ein “Projektmagazin” zugeschickt, das jeweils nur die ersten paar Zeilen seiner Artikel präsentiert. Wer mehr wissen will, muss den Artikel kaufen. Hohe Dynamik in Projekten – Wo Methodenwissen nicht mehr weiter hilft erregte meine Aufmerksamkeit, und ich habe mir den Artikel entgegen meinen Gepflogenheiten erworben1. Endlich mal jemand, der den Methodismus im Projektmanagement hinterfragt. Der Autor spricht Projekte an, die einen hohen Anteil an Dynamik haben, und in denen daher immer wieder Überraschungen auftauchen. Methoden sind Regelwerke und deshalb nicht geeignet, mit Überraschungen umzugehen. Das einzig wirksame Mittel – so der Autor – seien Ideen. Nur der Erfolg im Markt entscheidet, ob aus einer guten Idee eine marktgängige Innovation wird. Offenbar adressiert auch dieser Artikel vor allem Entwicklungsprojekte, denn in Migrations- und Integrationsprojekten sind marktgängige Innovationen weniger zentral. Auch wenn er drei Möglichkeiten der Problemlösung in Unternehmen vorstellt, denkt der Autor dabei wohl kaum an Migrations- und Integrationsprojekte:

  • Die Alltagsorganisation der Linie (das Management transfomiert das Problem in eine Anweisung)
  • Das konventionelle, methodisch durchgeführte Projekt (das Management transfomiert das Problem in einen Projektauftrag)
  • Das dynamikrobuste Projekt (Zerlegung des Problems in einen methodischen und einen dynamischen Teil)

Leider verschweigt der Autor, wer diese Zerlegung macht und behauptet ohne Quellenangabe, dass 95% methodische und 5% dynamische Anteile seien. Der einzige Lietraturhinweis ist ein Werk, das aus seiner eigenen Feder stammt. Schade, stellt er in seinem Artikel immer wieder unreferenzierte Behauptungen auf. So z.B. auch, nachdem er löblicherweise den Unterschied zwischen Aufgaben und Problemen erklärt und dann behauptet, Probleme seien äussere Reize, die ein Unternehmen nicht aussuchen könne. Bei niedriger Dynamik übersetze das Unternehmen Probleme in Aufgaben. Bei hoher Dynamik machen erfolgreiche Unternehmen Probleme sichtbar und suchen intern nach passenden Problemlösern. Ob er das eigenen Untersuchungen oder einem käuflichen Survey entnimmt, vernimmt der Leser nicht.

Das dynamikresistente Projekt steht im Zentrum seines Artikels. Ganz abgesehen davon, dass erfolgreiche Projekte hoffentlich nicht dynamikresistent sind, weil sonst kaum eine neue Struktur daraus erwächst, verstehe ich seine reduktionistische Aufteilung in 95% methodische und 5% dynamische Anteile nicht. In einer späteren Grafik über duale Prozessgestaltung scheint eher der dynamische Anteil 95% auszumachen. Niemand kann ein Problem ein für allemal in einen methodischen und einen dynamischen Teil aufsplitten. Während der methodischen Projektabwicklung entsteht laufend Dynamik. Eine neue Struktur, das Ziel eines jeden Projekts, kommt durch nichtlineare Dynamik zustande. Dynamik ist der wichtigste Bestandteil eines Projekts. Prigogine und Stengers schreiben: “Lange wurde Turbulenz mit Unordnung … gleichgesetzt. Heute wissen wir jedoch, dass das nicht der Fall ist”. So irregulär und chaotisch Turbulenz auch erscheinen mag, sie führt zu makroskopischen Strukturen2. Ein Projekt ist gewissermassen die turbulente Phase, die es braucht, um eine komplexe Struktur aufzubauen.

Der Autor zählt eine Reihe von Fluchtverhalten auf – er nennt sie destruktiven Schutzräume -, die in überforderten Projekten beobachtet werden können. Neben Kommunikationsfehlern nennt er Konsequenzen des Reparaturdienstverhaltens, reduktiver Hypothesenbildung, horizontaler und vertikaler Flucht und Einkapselung sowie dem Parkinsonschen Gesetz, ohne sich jedoch an die in der Fehlerliteratur üblichen Terminologie zu halten3. Sehr gewöhnungsbedürftig ist die Art, wie Wohland die Begriffe Können und Wissen braucht. Er behauptet, dass Ideen nicht aus Wissen abgeleitet werden können. Ideenproduzenten seien Könner, weswegen der Bedarf an Können bei hoher Dynamik steige. Nach Rasmussen und Reason werden Probleme aber gerade auf der wissensbasierten Ebene gelöst, nicht durch Ideen, sondern durch Analyse der abstrakten Beziehungen zwischen Struktur und Funktion des Problemzustandes und durch anschliessende Diagnose3. Das Können läuft auf der fähigkeitsbasierten Ebene weitgehend automatisch ab. Damit kann man höchstens Routineprojekte abwickeln.

1Gerhard Wohland. Hohe Dynamik in Projekten – Wo Methodenwissen nicht mehr weiter hilft. Projektmagazin 24/08. Das Fachmagazin im Internet.
2
Ilya Prigogine, Ingrid Stengers. Dialog mit der Natur – Neue Wege wissenschaftlichen Denkens. Piper Verlag. München 1981
3James Reason. Menschliches Versagen. Spektrum Akademischer Verlag. Heidelberg 1994
sowie
Dietrich Dörner. Die Logik des Misslingens. Strategisches Denken in komplexen Situationen. Rowohlt Taschenbuchverlag. Reinbek b. Hamburg 1992 u. 2002

Die Schwarzen Projektschwäne sind braun

Das Unglück von Tschernobyl basiert auf einer Reihe unglücklicher Umstände, von denen einer ein schwarzer Projektschwan der Unterart “Steckenbleiben” war. Die Operatorcrew war angewiesen, einen Test durchzuführen und dazu den Reaktor auf 20% zu drosseln. Es war für diesen Reaktortyp strikte verboten, eine tiefere Leistung als 20% zu fahren, weil er in diesem niedern Leistungsbereich instabil wurde. Das wusste man sehr gut. Der diensthabende Operator steuerte den Reaktor manuell hinunter und unterschoss die 20%-Marke beträchtlich. Der Versuch, den Reaktor wieder auf 20% hochzufahren scheiterte aus unerklärlichen Gründen1. Das war der “Steckenbleiben”-Schwan. Das Team entschied, den Versuch dennoch durchzuführen, obwohl die Reaktorleistung bei 7% stand. Vielleicht waren alle übermüdet und wollten endlich Feierabend. Der Fehlentscheid wurde vom “Steckenbleiben”-Schwan geboren, aber was danach passierte, wäre prinzipiell vorauszusehen gewesen. Gewisse Parameter verschlechterten sich zusehends, und je schlechter sie waren, desto mehr Fehlmanipulationen machte die Crew. Es war eine schleichende Fehlentwicklung aufgrund der Feedbackschlaufe “Verschlechterung des Systems –> Fehlmanipulationen –> Verschlechterung des Systems, usw.”. Solche Schwäne sind in Projekten viel häufiger als die echten schwarzen Schwäne. Eigentlich sind es gar keine schwarzen Schwäne im Sinne Talebs2, von denen wir hier reden. Nennen wir die “Steckenbleiben”-Schwäne besser braune Schwäne, denn nach dem Auftreten eines braunen Schwanes gibt es immer die Gelegenheit, das Unterfangen sofort abzubrechen. Und manchmal wäre ein Ende mit Schrecken immer noch besser, als ein Schrecken ohne Ende. Aber wer hat schon den Mut abzubrechen, solange nichts passiert ist?
Ich weiss nicht, ob unsere braunen Schwäne, mit den Mandelbrotschen grauen Schwäne identisch sind, die Taleb beschreibt. Vielleicht versteht Taleb unter grauen Schwänen etwas, was in der Literatur auch als deterministisches Chaos bezeichnet wird. Unsere braunen Schwäne, die die Projekte besiedeln, sind nicht plötzliche, mehr oder weniger katastrophale Ereignisse, keine Fulgurationen, sondern gleitende Fehlentwicklungen, die in eine ausweglose Situation führen. Von der Wahrnehmung her sind es Schwäne, weil man während der Fehlentwicklung nur ein “ungutes Gefühl” hat, das Problem aber erst dann effektiv wahrnimmt, wenn die Situation verfahren ist. Wir erwachen quasi aus dem Schlaf. Daher glauben wir, das Problem sei plötzlich eingetreten. Taleb würde Tschernobyl vielleicht als schwarzen Schwan bezeichnen. Aber während der Entwicklung der Katastrophe gab es niemals einen schwarzen Schwan, nur braune. Man hätte zu jeder Zeit – zumindest bis paar Minuten vor der Explosion – abbrechen und das Steuer herum reissen können. Taleb hat als Börsenhändler einen anderen Eindruck von Katastrophen als Projekt- und andere Manager. Ein Kurs kann aus unerklärlichen Gründen plötzlich absacken. In Projekten hingegen befinden wir uns auf mehr oder weniger schiefen Flächen, die in einer Richtung immer steiler abfallen. Wenn es uns gelingt, uns während des ganzen Projekts in Regionen moderater Schiefe zu halten, überleben wir das Projekt heldenhaft. Wenn wir jedoch immer mehr gegen den Abgrund rutschen, kommt einmal der Punkt, wo es kein Halten mehr gibt und wir mitsamt des Projekts in den Abgrund stürzen. Vielleicht will Taleb diesen Punkt als “schwarzer Schwan” bezeichnen, obwohl es mehr eine Region als ein Punkt ist. Wenn wir stürzen, ist das für uns zwar überraschend. Aber wir wussten tatsächlich schon lange, dass wir stürzen werden, wenn wir nichts unternehmen. Ich glaube also nicht, dass es in Projekten tatsächlich echte schwarze Schwäne gibt. Ich glaube nicht einmal, dass schwarze Schwäne tatsächlich existieren.
1Dietrich Dörner. Die Logik des Misslingens – Strategisches Denken in komplexen Situationen. Rowohlt Verlag. Reinbek bei Hamburg 2003.
2Nassim Nicholas Taleb. Der Schwarze Schwan – Die Macht höchst unwahrscheinlicher Ereignisse. Hanser Verlag. München 2008

Wie überlisten Sie Ihr Gehirn?

Vorgestern landete in einem Projekt ein schwarzer Schwan zu meinen Füssen1. Zwar wurde er schon seit längerer Zeit immer wieder in der Gegend gesichtet, wie das bei schwarzen Schwänen so der Fall ist. Aber dass er gerade zu diesem Zeitpunkt und ausgerechnet vor meinen Füssen landet, war dann doch überraschend.

Wahrnehmungsverzögerungen

In vielen Fällen wird der schwarze Schwan von Leuten angelockt, die noch immer in linearen Denkmustern verhaftet sind2 und lokal optimieren3, und sie sind leider immer noch in der Mehrheit. Sogar, wenn Sie auf den schwarzen Schwan aufmerksam machen, der über dem Schauplatz kreist, man wird Ihnen kein Gehör schenken, weil man Sie nicht verstehen kann. In meinem Fall ging es unter vielem Anderem z.B. auch um das Verständnis von Verzögerungen. Man muss die Dynamik einer Veränderungsabsicht abschätzen, die auf ein jährlich stattfindendes Ereignis abzielt. Die Absicht ist eine Funktion der Wahrnehmung und verzögert sich ihrerseits gegenüber der Wahrnehmung. Somit verhält sich die Absicht ähnlich, wie eine Verzögerung höherer Ordnung. Das Ereignis findet nur einmal pro Jahr statt, also muss mit einem entsprechend langen Zeithorizont gerechnet werden, um das Ziel zu erreichen. Das war noch das Einfachste, und es dünkt einem, dass es eine Kinderrechnung ist. Dennoch hat die Rechnung trotz mehrmaligem Hinweisen niemand im Team gemacht. Ich glaube nicht, dass das daher kommt, dass unsere Zeit schnelllebig ist, sondern daher, dass Menschen mit Zeitstrukturen ihre liebe Mühe haben.

Verfügbarkeitsheuristik – oder wenn nur das Heute wichtig ist

Der schwarze Schwan habe ich mitverantwortet, da es mir nicht gelungen ist, den Mitgliedern des Teams die Zusammenhänge nahe genug zu bringen. Aber sollen und können Sie die Mitglieder in einem Projekt laufend in systemischem Denken ausbilden?
Zudem muss ich mir den Vorwurf machen, dass ich wider besseren Wissens zu wenig Gedanken gemacht habe, wo der seit längerem gesichtete schwarze Schwan landen könnte. Mit anderen Worten: zwar habe ich viel Inhaltliches geleistet, aber gegenüber der instabilen Situation den Kopf in den Sand gesteckt. Ich hatte kein Modell, keine Risikolandkarte, keine Analyse der archetypischen Denkmuster, die in jedem Zeitpunkt vorherrschten. Zwar versuchte ich mir im Vorfeld des vorgestrigen Ereignisses vorzustellen, wie sich die Situation entwickeln könnte, aber irgendwie verschleierte mein Gehirn den Weg zu den richtigen Gedanken. Das mag mit der Verfügbarkeitsheuristik zusammen zu hängen5. Es kommen einem die Szenarien in den Sinn, wie man sie in letzter Zeit erlebt hat, nicht aber eines, in welchem der schwarze Schwan zuschlägt. Weil man intuitiv weiss, dass das Gehirn just in dem Moment streikt, wo man sich ein Katastrophenszenario vorzustellen versucht, lässt man es bleiben, bzw. verschiebt es auf “morgen”. Ich glaube aber, dass man mit mehreren Anläufen diese Blockaden beseitigen könnte.

Rückschaufehler: das hätte ich vorher sehen können!

Nachdem die Katastrophe eingetroffen ist, greift sofort der Rückschaufehler(s. Selbstverständlichkeiten müssen doch nicht gefordert werden, oder?). Es ist Ihnen ganz klar, was abgegangen und vorgefallen ist. Ebenfalls klar ist es Ihnen, dass die Entwicklung ja ganz logisch, ja zwingend war und Sie es eigentlich haben sehen kommen. Ich bin überzeugt, dass man etwas gegen den Rückschaufehler unternehmen kann und glaube nicht, dass wir immer und hoffnungslos den schwarzen Schwänen ausgeliefert sind. In einem Projekt fühlen Sie sich vielleicht schon seit längerer Zeit unbequem, weil nicht alles so läuft, wie Sie es sich wünschen. Als CEO einer Unternehmung merken Sie, dass Ihnen die Entwicklung langsam entgleitet. Dann müssen Sie sich hinsetzen und – unter Umständen mit einem Dritten – über die Ursachen Ihrer Bedenken, die Dynamik und Konsequenzen gewisser Entwicklungen sowie über Denkmuster, die in Ihren Kopf und dem der Teammitglieder auftreten, nachdenken. Tun Sie das nicht erst, wenn der schwarze Schwan schon zum Landeanflug ansetzt. Dann bringt Ihr Gehirn erst recht nichts mehr hervor. Denken Sie nicht, dass Sie sich morgen ganz bestimmt darum kümmern werden. Wenn Sie es heute nicht tun, dann werden Sie es auch morgen nicht tun. Versuchen Sie auch nicht mit der Entschuldigung auszuweichen, dass diese “Baustelle” ja gar nicht so wichtig sei und Sie eigentlich viel wichtigere “Baustellen” haben, die aber nicht so instabil sind, dass sie eine Denkpause erfordern.

Stellen Sie laufend Fragen

Womit beschäftigen Sie sich in dieser Zeit, beruflich und privat? Auf dieser Liste wird gewiss auch eine Ihnen nahestehende Bezugsperson auftauchen, mit der Sie sich beschäftigen müssen. Die Beschäftigung mit dieser Person hat ein Umfeld und eine Geschichte. Wissen Sie, wie sich diese Geschichte entwickelt hat, entwickeln kann und entwickeln wird? Welche Parameter können sich ändern? Wovon hängt ihre Änderung ab? Sind es Fluss-, Bestandes- oder Hilfsgrössen? Wie reagieren Sie und wie reagiert die Bezugsperson, wenn sich die Parameter ändern? Wie können Sie und Ihre Bezugsperson die Änderungen wahrnehmen und wie interpretieren Sie sie? Stellen Sie sich diese Fragen für jedes Ihrer Betätigungsfelder. Tun Sie es jetzt und immer wieder.

1Nassim Nicholas Taleb. Der Schwarze Schwan – Die Macht höchst unwahrscheinlicher Ereignisse. Carl Hanser Verlag. München 2008.
2Günther Ossimitz/Christian Lapp. Das Metanoia Prinzip – Eine Einführung in systemgerechtes Denken und Handeln. Franzbecker Verlag. Hildesheim und Berlin 2006.
3Eliyahu Goldratt/Jeff Cox. Das Ziel – Höchstleistungen in der Fertigung. McGraw-Hill Book Company. Maidenhead 1990
4John Sterman. Business Dynamics – System Thinking and Modeling for a Complex World. McGraw-Hill. Boston 2000
5Hanno Beck. Die Logik des Irrtums – Wie uns das Gehirn täglich ein Schnippchen schlägt. Verlag Neue Zürcher Zeitung. Zürich 2008

Lieber ein eleganter schwarzer Schwan als ein hoffärtiger Phönixvogel

Der GDI-Trendradar vom 9. Dezember 2008 meldet unter dem Titel Hoffnung: Von schwarzen Schwänen zum leuchtenden Phönix, dass die Zukunft nicht den Untergangspropheten gehöre1. Zwischen den Zeilen liest man, dass Nassim Taleb2 Hysterie verbreite, anstatt neue Ideen für eine bessere Welt. Natürlich gibt es verschiedene Strategien gegen die Zunahme dessen, was man gemeinhin als Komplexität bezeichnet, also gegen Kontingenz, Fluktuation und Entropieproduktion. Man kann sie einfach schön reden, wie es das GDI vorschlägt. Man kann aber auch danach fragen, was denn eigentlich los ist und feststellen, dass wir verschiedene Handlungs- und Denkweisen aufgeben und uns neu orientieren müssen. Auch das ist eine neue Idee für eine bessere Welt. Aber Gewohnheiten aufzugeben und Neues zu lernen ist schmerzhaft und schwierig. Deshalb ist diese Idee vielleicht nicht so populär, wie es sich das GDI wünscht. Es gibt eben keinen Königsweg in eine bessere Welt. Da kann weder Nassim Taleb noch das GDI etwas dafür. Es ist höchste Zeit, dass wir untersuchen, wie sich die Welt in der menschlichen Wahrnehmung verändert hat, wie der Mensch die Unterschiede wahrnimmt, was diese Wahrnehmungen für ihn bedeuten und wie er darauf reagiert. Die Welt wird in unserer Wahrnehmung immer abstrakter. Für die wirklich wesentlichen Aspekte reicht unsere Wahrnehmung offenbar nicht mehr aus. Dies festzustellen ist höchst interessant und führt in keiner Weise zu einer Hysterie. In unserer Wahrnehmung machen wir Fehler, seit es uns gibt. Das ist nichts neues. Aber durch die Zunahme der Komplexität, die wir selber geschaffen haben, hat eben auch die Sensibilität gegenüber den Anfangsbedingungen zugenommen (sog. Schmetterlingseffekt). Daher haben Ungenauigkeiten oder Verzerrungen in unserer Wahrnehmung heute eine verhehrendere Auswirkung als früher. Auch schwarze Schwäne, die nur in unserer Wahrnehmung extrem unwahrscheinlich sind, haben verherendere Auswikungen auf unser komplexes Menschenwerk als früher, als das Menschenwerk noch ein stabiles und robustes Gebäude war. Die neuen Ideen für eine bessere Welt heissen deshalb:

  • Verstehen, was wir für eine Welt geschaffen haben und was sie mit uns macht
  • Verstehen, was Komplexität ist und wie wir sie wahrnehmen
  • Lernen, systemisch zu denken, wahrzunehmen und zu handeln
  • Lernen, welchen Einfluss unser Denken auf die Welt hat
  • Alte Gewohnheiten zu überwinden und eine neue Sicht der Dinge zu übernehmen

Die alten Gewohnheiten sind insbesondere lineares Denken und ebensolches Handeln sowie die Missachtung von Fern- und Nebenwirkungen. Solange es Leute gibt, die unternehmerische Wissensgenerierung in starre Prozesse pressen wollen oder glauben, komplexe Projekte abschliessend planen zu können, sind allerdings nirgends leuchtende Phönixe zu sehen. Ich weiss nicht, warum das GDI schwarze Schwäne nicht mag. Schwarze Schwäne sind ebenso schön wie leuchtende Phönixe. Diese sind eitel und verblendet, während schwarze Schwäne elegant und anmutig daher fliegen.
Die Zukunft gehört weder den Untergangspropheten, noch den Schönrednern, die einen nichtvorhandenen leuchtenden Phönix beschwören. Die Zukunft gehört denjenigen, die uns den Weg aus dem linearem Denken zeigen.

1GDI-Trendradar. Hoffnung: Von schwarzen Schwänen zum leuchtenden Phönix. persönlich 9.12.2008. Online Marketingnews der publiswiss.
2Nassim Nicholas Taleb. Der schwarze Schwan. Die Macht höchst unwahrscheinlicher Ereignisse. Carl Hanser Verlag, München 2008

Lesssons Learned und Tagebücher gegen Schwarze Schwäne

Letzte Woche habe ich ein Seminar zum Thema “Systemisches Projektmanagement” erteilt. Das ist auch der Grund, weshalb dieser Blog (oder heisst’s das Blog?) eine relativ grosse Lücke erfahren hat. Das bedeutet aber nicht, dass keine Beiträge mehr folgen. Ich habe gerade heute mit meinen Studenten im Fach Mathematik festgestellt, dass auch die Primzahlen ausdünnen, je grösser sie werden und dennoch gibt es keine letzte, also grösste Primzahl. Genau so wenig wird dieses Blog versiegen…. (oder heisst’s der Blog?).
Im Seminar habe ich auch über Learning Stories doziert. Da ich das etwas impovisierte, habe ich keine Unterlagen. Das möchte ich hier nachholen.
Schwierige Projektsituationen zeichnen sich durch hohe Entropieproduktion aus. Die meisten Leute nennen das “Komplexität”. Aber Komplexität ist nicht durch Unsicherheit und Instabilität charakterisiert. Alle sind sich einig, dass das Gehirn wohl das komplexeste System auf der Erde ist. Trotzdem ist das Gehirn relativ stabil und durch grosse Strukturiertheit gekenntzeichnet. Was wir in chaotischen Projektsituationen erleben, ist nicht Komplexität, sondern etwas ganz anderes. Etwas, das auf dem Weg zur Komplexität auftritt. Man nennt es Entropieproduktion. Laufend tauchen Hiobsbotschaften auf. Kleinigkeiten und Details haben grösste Auswirkungen. Es spielt eine Rolle, ob Sie als Projektleiter präzis richtig oder annährend richtig reagieren, wenn man diese Unterscheidung überhaupt machen kann; letzteres kann zur Eskalation führen. Und dann machen Sie sich ein Gewissen, tagelang, wochenlang. Hätte ich doch nur eine Sekunde früher…. oder nicht mit dem rechten Auge gezwinkert, etc. Es ist, wie nach einem Autounfall. Er wäre vermeidbar gewesen, wenn Sie auch nur drei Minuten früher aufgestanden wären. Sie leiden unter jedem Ihrer “Fehler”. In der Therapie lässt man Patienten täglich 15 Minuten lang ihre Geschichten erzählen. Wenn Sie in schwieriger Umgebung arbeiten, wo der Zufall eine grosse Rolle spielt, dann werden Sie ständig das Gefühl haben, sich für Ihre früheren Entscheidungen rechtfertigen zu müssen. Ein Tagebuch zu führen ist das Mindeste, was Sie unter diesen Umständen tun können1. Ein Tagebuch hat nicht nur einen mindernden Einfluss gegenüber Burnout-Effekten, sondern hilft auch bei Lessons Learned Workshops, sich nicht nur an die Ereignisse der letzten Wochen zu erinnern. Lessons Learned Workshops sollen das Projektgeschehen aufarbeiten. Lassen Sie alle Projektmitarbeiter die Ereignisse und den Ablauf aus ihren unterschiedlichen Perspektiven schildern, sowohl das Gute als auch das weniger Gute. Jeder sieht und interpretiert die Wirklichkeit ein wenig anders. Und was für den einen die hinreichende Ursache eines Unglücks, ist für den anderen bloss eine Notwendigkeit, die für sich genommen noch nicht zur Katastrophe hätte führen müssen. Lässt sich denn unter diesen Voraussetzungen überhaupt aus Fehlern lernen. Es gibt Leute, die bezweifeln das. Rückschaufehler führen zu einer übersteigerten Kontrollillusion. Vielleicht war es gar nicht so, wie Sie es wahrgenommen haben. Das Gehirn speichert Erinnerungen wie ein Palimpsest. Jedes Mal, wenn Sie eine Erinnerung abrufen, wird sie neu geschrieben, aber zusammen mit Interpretationen und Verzerrungen. Kausale Ketten werden z.B. umgedreht. Plötzlich geschah A in Ihrer Erinnerung nicht mehr wegen B, sondern B ereignete sich erst, nachdem A schon geschehen war. Wozu also Lessons Learned? Sie könnten uns helfen, unsere Verhaltensmuster zu verstehen. Sie könnten uns auch helfen, Komplexität und Entropieproduktion zu verstehen.
Protokollieren Sie die Geschichten Ihrer Projektmitarbeiter. Interessant sind vor allem die Geschichten ein und derselben Situation. Sammeln Sie solche Episoden. Bringen Sie Muster mit der Unternehmenskultur oder Persönlichkeitsstruktur in Zusammenhang. Verarbeiten Sie die prägnantesten Episoden in Metaphern, Gleichnissen oder gar Fabeln. Auf diese Weise abstrahieren Sie die Ereignisse von den Personen und Organisationen und bringen sie in eine merk-würdige Form. Mit der Zeit werden im Unetrnehmen geflügelte Worte und Geschichten die Runde machen und Wissen konservieren. Das ist Wissensmanagement. Wenn die Geschichten Emotionen wecken, bleiben sie besser im Gedächtnis haften; besser als Präsentationen nüchterner Fakten.

1Nassim Nicholas Taleb. Der schwarze Schwan. Die Macht höchst unwahrscheinlicher Ereignisse. S. 100. Carl Hanser Verlag, München 2008.