Schlagwort-Archive: best practices

Für die wirklich interessanten Managementsituationen haben wir keine Erfahrungen und gibt es keine Best Parctices!

In „und täglich grüsst das Murmeltier“ habe ich den Bereich, in welchem Erfahrungen und damit Best Practices möglich sind, gegenüber dem Bereich abgegrenzt, in welchem Situationen so selten sind, dass keine Erfahrungen gesammelt werden können. Insbesondere habe ich behauptet, dass die erlebbaren Projektsituationen paretoverteilt seien. Ich möchte diese Vorstellung noch etwas vertiefen.

Jeder Situation ist einbestimmtes Mass an Ungewissheit assoziiert

Als Variable habe ich in dem Artikel die Beschaffenheit eines Waldbodens vorgeschlagen und dies als Metapher für eine bestimmte Projektsituation verwendet. Die Bodenbeschaffenheit ist direkt verantwortlich für unsere Trittsicherheit. Je unebener der Boden, desto unsicherer sind wir in unseren Bewegungen. Auch in Projekten ist Unsicherheit, oder besser gesagt Ungewissheit, ein wesentlicher Faktor, der für das Gelingen des Projekts direkt verantwortlich ist. Beispielsweise ist es ungewiss, ob eine bestimmte Tätigkeit in der geplanten Zeit abgeschlossen werden kann. Es ist ungewiss, ob bekannte Risiken eintreten werden, z.B. ob in einem Bauprojekt das trockene Wetter anhält oder ob es ein früher Wintereinbruch geben wird. Es ist aber auch ungewiss, ob das Projekt unerwartete Ereignisse antreffen wird. Ereignisse, die das Projekt unerwartet treffen, sind nicht vorhersehbar. Ihnen kann auch keine Wahrscheinlichkeit zugeordnet werden, weil man sie nicht kennt. Sobald man sich ein mögliches Ereignis vorstellen kann, ist es nicht mehr unvorhergesehen. Daher kann ich auch kein Beispiel eines unvorhergesehenen Ereignisses gebe. Sobald ich ein Beispiel ausdenke, ist es nicht mehr unvorhergesehen.

Es ist ziemlich sicher, dass unser Zug fahrplanmässig ankommt, wenn es keine Baustellen gibt. Die Ungewissheit über die Ankunftszeit ist mässig. Zwar kann die Lok eine Panne haben oder die Strecke kann unerwarteterweise blockiert sein. Diese Ungewissheit besteht zwar, aber sie ist relativ klein, weil diese Ereignisse selten vorkommen. Existieren auf der Strecke eine Baustelle oder ist die Lok alt und ungewartet, dann ist die Ungewissheit, ob der Fahrplan eingehalten werden kann, schon grösser. Je mehr Baustellen auf der Strecke existieren, desto grösser die Ungewissheit.

Für Situationen sehr hoher Ungewissheit können wir keine Erfahrung sammeln, keine Intuition aufbauen und keine Best Practices angeben

Mässige Ungewissheit haben wir schon oft erlebt und uns eine gewisse Erfahrung dafür angeeignet. Hingegen sind wir auf grosse Ungewissheit, wie sie in wirklich komplexen Projekten anzutreffen ist, schlecht vorbereitet. Das bedeutet, dass wir für Projektsituationen mit grosser Unsicherheit keine Erfahrungen aneignen können. Und deshalb fehlt uns dafür auch jegliche Intuition, denn Intuition ist nach Herbert Simon einfach nur Wiedererkennen.

Situationen gänzlich ohne oder mit sehr geringer Ungewissheit gibt es nicht. Daher ist die Häufigkeit dort auch Null. Die Häufigkeit hat ein Maximum aber einer gewissen minimalen Ungewissheit. Das sind die alltäglichen Situationen. Wir haben dafür viel Erfahrung gesammelt und sind uns diese Ungewissheit gewohnt.Situationen mit mehr Ungewissheit werden immer seltener. Viele erleben Situationen mit sehr, sehr hoher Ungewissheit nur ein oder zwei Mal im Leben. Daher können sie dafür auch kein Gefühl entwickeln und keine Erfahrungen sammeln. Die Häufigkeit der Situationen mit hoher Ungewissheit nimmt aber nicht so stark ab, wie bei einer Normal- oder Exponentialverteilung. Situationen mit hoher Ungewissheit sind häufiger, als man denkt.

Die Paretoverteilung kennen wir auch bei der Verteilung der Grösse von Städten. Eine Ansiedlung ist erst eine Stadt, wenn sie eine bestimmte Einwohnerzahl hat. Darunter ist die Häufigkeit Null. Kleine Städte gibt es viele, grosse Städte weniger und Riesenstädte kommen selten vor, aber nicht so selten, dass man sich nicht noch grössere Städte vorstellen kann. Es ist gut denkbar, dass die grössten Städte an Einwohnerzahl in ein paar Jahren überholt werden.

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

Wo ist denn nun die Katze hingekommen?

In Wie man Kosten, Zeit und Ärger spart habe ich einige typische Denk- und Handlungsfallen aufgezählt, wie sie im Unternehmens- und Projektmanagement häufig auftauchen. Einer nennt sich Rückschaufehler und führt schnell zu der Illusion, die Kontrolle über das Geschehen zu besitzen. Wenn wir nach gehabtem Schaden die Ereignisse Revue passieren lassen, dann haben wir oft das Gefühl, dass „es uns wie Schuppen von den Augen fällt“ und es eigentlich ganz einfach gewesen wäre, hätten wir nur dann und dann auf das und das Signal geachtet. Erfahrene Regeln verallgemeinern wir gerne und erzeugen so eine Kontrollillusion. Aber wenn wir uns mitten im Schlamassel befinden, dann ist nichts einfach oder klar. Alles stürtzt auf uns ein und wir wissen nicht, worauf achten und wo wehren.

Der Artikel Hinten und Vorne nicht drauskommen… der Mathematikpädagogin und -therapeutin, Margret Schmassmann enthält eine einfache Geschichte, die zeigt, was ein Rückschaufehler ist. Erfahren hat ihn ein fünfjähriger Stefan, über den wir uns hier amüsieren können, weil wir seine Unbeholfenheit als „süss“ empfinden. Schmassmann schreibt: Stefan zog sein Lieblings-T-Shirt an, das mit der Katze vorne drauf und stellt sich erwartungsvoll vor den Spiegel. Aber die Katze ist nirgends zu sehen….Er dreht und wendet sich …. und entdeckt [die Katze] plötzlich [am Rücken]. Da er sie ja vorne haben will, zieht er … das Leibchen wieder aus, legt es mit dem Katzenbild nach oben vor sich auf den Boden und schlüpft hinein. Aber die Katze ist wieder nicht da… Er geht nun systematisch vor: Er zieht das Leichen aus, hält es … an seinen Oberkörper, legt es dann umständlich und sorgfältig auf den Boden und schlüpft schnell hinein…. Der Aufwand hat sich gelohnt…. Er hat sich ein Stück Raum-Vorstellung erarbeitet und erwartet, dass sich diese nun bei ähnlicher Gelegenheit anwenden lässt…. Diese Angelegenheit kam gleich darauf in Form einer Strumpfhose, bei der es sehr störend im Schuh ist, wenn die Fersen, statt hinten an ihrem Platz zu sein, verwurstelt vorne in Falten liegen und drücken. Er legt also die Strumpfhose so vor sich auf den Boden, dass die Rückseite sichtbar ist und die Öffnung zu ihm zeigt. Er schlüpft hinein. Die Verwirrung ist gross! Denn was für’s T-Shirt galt, gilt für die Strupfhose nicht mehr.

Da können wir schmunzeln. Klar ist es nicht dasselbe, schliesslich schlüpft man von unten in’s T-Shirt, in die Strupfhose aber von oben. Was man mit fünf doch nicht alles lernen muss! Dabei hat Stefan bloss eine „best practice“ angewendet, wie wir das auch oft tun. Sind wir zuweilen nicht gleich „süss“ wie Stefan, wenn wir in einer viel komplexeren Situation Tatsachen antreffen, die für uns genau so verwirrend sind, wie die Raumvorstellung für Stefan? Im Nachhinein sind wir immer klüger und erleichtert, dass wir beim nächsten Mal wissen, wie wir vorzugehen haben. Aber das ist eine Illusion. Beim nächsten Mal erkennen wir nicht einmal, dass sich die Regel hier nicht anwenden lässt, weil es sich um eine andere Situation handelt und handeln völlig unbeholfen. Schmassmann schreibt, dass viele Dinge nicht gelernt, sondern erfahren werden. In den meisten Situationen, die der Mensch in den letzten paar Millionen Jahren angetroffen hat, hat er durch Erfahrung gelernt. Wir haben uns durch Erfahrung Regeln zurecht gelegt und sie im Langzeitgedächtnis gespeichert. Befinden wir uns auf der regelbasierenden Ebene, können wir auf die Regeln zurück greifen. Aber für die heutigen komplexen Situationen funktioniert das nicht mehr auf diese Weise. Um diese zu meistern ist es unumgänglich auf die wissensbasierte Ebene zu gehen, die Situation zu analysieren und Lösungen neu zu erfinden, ohne im Langzeitgedächtnis zu kramen. Natürlich kann die neue Lösung Komponenten gespeicherten Wissens enthalten, ist aber niemals vorgefertigt. Weil wir immer wieder versuchen, „best practices“ anzuwenden, die in der Vergangenheit erfolgreich waren, nehmen Denklücken und mit ihnen auch Zusammenbrüche und Misserfolge in Projekten zu.

Erfahrungen, die wir in komplexen Situationen gemacht haben, müssen zuerst aufbereitet werden, bevor wir sagen können, dass wir sie gelernt haben. Die Aufbereitung ist wissensbasiert und bewusst und kann mit Hilfe von Modellen geschehen, wie z.B. Senges Archetypen1.

1z.B. William Braun. The System Archetypes. 2002