Schlagwort-Archive: wissensbasierte Ebene

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

Wo kann in Projekten und Unternehmen etwas schief gehen?

Ich weiss schon, es mag seltsam klingen, wenn ich sage, dass wir für das Projektmanagement Skills und Regeln/Tools haben, nur das Wissen noch fehle. Dabei ist doch das PMBOK des PMI in neun Wissensgebiete aufgeteilt. Bitte lassen Sie mich ganz kurz ein wenig ausholen.

Etwa Mitte der 1960er Jahre rückte die Aufmerksamkeit ins Rampenlicht der Psychologie. In den 70er Jahren wurden diese ersten Ergebnisse mit verschiedenen Theorien angereichert, so der Ressourcentheorie, die die Aufmerksamkeit als ein einziges Reservoir an Informationsverarbeitungsressourcen betrachtet oder die Mehrkanalprozessoren-Theorie, die annimmt, dass jede komplexe Aufgabe von einer Reihe unabhängiger Prozessoren bearbeitet wird. 1972 stellten Newell&Simon den General Problem Solver vor, eine Theorie, die wesentlich zum Verständnis der Art und Weise menschlichen Problemlösens beitrug. Dann kamen Konzepte wie das Arbeitsgedächtnis oder Skripts hinzu, die anfangs der 80er Jahren zu brauchbaren Aufmerksamkeits-Handlungs-Theorien führten. 1982 stellte Rasmussen ein Modell der kognitiven Kontrollmechanismen vor, das auf drei Ebenen beruht: Skill- oder fähigkeitsbasierte Ebene, regelbasierte Ebene und wissensbasierte Ebene1. Rasmussens Modell war deutlich von Newells und Simons General Problem Solver beeinflusst und zielte auf Fehler, die während Notfällen in riskanten Industrie- und Prozessanlagen begangen werden. 1986 erhielt Rasmussens Modell in Tschernobly tragische Bestätigung. 1990 stellte James Reason im Buch Human Error, aus dem übrigens der obige Abriss der geschichtlichen Zusammenhänge stammt, sein Generic Error Modelling System vor1. Der Name des „Systems“ ist ziemlich ungeschickt gewählt. Eigentlich ist es gar kein Fehlermodellierungssystem, sondern eine geraffte Darstellung von Rasmussens Modell menschlichen Verhaltens.

Sie können das Bild vergrössern, indem Sie es anklicken. Ich schlage vor, das Modell auch im Projektmanagement anzuwenden. Auf der untersten, fähigkeitsbasierten Ebene laufen die Tätigkeiten fast automatisch ab. Möglichst viel wird durch das Langzeitgedächtnis gesteuert, das schnell, energieeffizient und ohne Inanspruchnahme des Bewusstseins arbeitet. Dafür enthält das Langzeitgedächtnis einige archetypische Beurteilungs- und Handlungsmuster, die in einer komplexen Welt vielleicht nicht mehr immer opportun sind. Normalerweise sollte während den fähigkeitsbasierten Handlungen von Zeit zu Zeit ein Aufmerksamkeitscheck durchgeführt werden. Auch das ist einprogrammiert und läuft automatisch ab, kann aber mal versagen. Passiert etwas aussergewöhnliches, schaltet das Gehirn auf die regelbasierte Ebene und grabscht in möglicherweise vorhanden Regeln und Vorschriften, die in ähnlichen Fällen wie dem vorliegenden, das Problem erfahrungsgemäss schon mal gelöst haben. Erst wenn auch das nichts hilft, muss der Problemlöser wohl oder übel im obersten Stock seines Gehirns die Lösung suchen. Die oberste, wissensbasierte Ebene ist etwas wackelig: langsam, teuer, weil sehr energieintensiv und selten gebraucht, also muss mit Stillstandsschäden gerechnet werden. Es ist unser Grosshirn, das Organ, das den Mensch von allen anderen Säugetieren unterscheidet. Ich will damit nicht in den Zynismus Russells einstimmen, der einmal sagte: „Manche Menschen würden lieber sterben, als denken und sie tun’s dann auch“. Dass wir die wissensbasierte Ebene so selten benutzen war ein überlebensnotwendiger Schutzmechanismus, den wir von der Natur mitbekommen haben. Heute stört er leider ziemlich massiv. Die regelbasierte Ebene findet immer etwas, und wenn’s eine falsche Regel ist. Dann gibt es mächtige kognitive und affektive Kräfte, die sich zusammentun, um den Problemlöser glauben zu machen, er solle unangemessene oder unvollständige Lösungen an dieser Stelle als zufriedenstellend akzeptieren3. W. B. Rouse formuliert das so: Menschen, wenn sie die Wahl haben, verhalten sich bevorzugt wie kontextspezifische Mustererkenner, statt dass sie versuchen hochzurechnen oder zu optimieren4. Das heisst, dass Menschen die Probleme lieber auf der regelbasierten Ebene lösen als in die wissensbasierte Ebenen hinauf zu gehen.

Ich denke, dass das Modell auch für Projekt- und andere Manager brauchbar ist. Wir beobachten doch Tag für Tag, dass wir viele Arbeiten völlig routinemässig durchführen und auch durchführen können. Wenn etwas unsere Aufmerksamkeit in Anspruch nimmt, dann reagieren wir mit Regeln und nach Vorschriften, die wir aus Erfahrung kennen. Zum wirklichen Denken – zum Kopfzerbrechen, wie man sagt – haben wir wenig Zeit. Das meinte ich, als ich schrieb, dass wir für das Projektmanagement Skills und Regeln haben, aber zu wenig Wissen. Wir haben zu wenig Wissen, das wir durch Nachdenken selber generiert und nicht aus einem PMBOK entnommen haben.

1J. Rasmussen. Human errors: A taxonomy for describing human malfunction in industrial installation. Journal of Occupational Accidents, 1982, 4, 311-335
2James Reason. Human Error. Cambridge University Press, 1990
3James Reason. Menschliches Versagen – Psychologische Risikofaktoren und moderne Technologien. S. 97. Spektrum Akademischer Verlag. Hedielberg 1994
4W. B. Rouse. Models of human problem solving: detection, diagnosis and compensation for system failures. Vorabdruck für Proceedings of IFAC Conference on Analysis, Design and Evaluation of Man-Machine Systems. Baden-Baden 1981.