Schrödingers Katze im Projektmanagement

Montag, 21. September 2015 von  
unter Fachartikel Scrum

… oder, wie geht es eigentlich meinem Projekt?

Wenn wir ein großes Projekt durchführen wollen, dann wissen wir, dass es zu Abweichungen vom Projektplan kommen kann. Und niemand von uns mag es, erst am Ende des Projektes diese Abweichungen zu entdecken oder festzustellen, dass das Projekt ein Fehlschlag war. Deutlich angenehmer ist es, von diesen Abweichungen früher zu erfahren. Denn dann können wir darauf reagieren und das Projekt immer noch zum Erfolg führen. Diese Erkenntnis ist nun nicht neu im Projektmanagement und Generationen von Projektmanagern haben sich schon mit der Fortschrittskontrolle von Projekten beschäftig und entsprechende Instrumente entwickelt. Und doch scheitern immer wieder Projekte scheinbar überraschend in der Schlussphase. Wie kann das sein?

1935 schlug der Physiker Erwin Schrödinger ein faszinierendes Gedankenexperiment vor. In eine undurchsichtige Stahlkammer wird eine Katze zusammen mit einer winzigen Menge einer radioaktiven Substanz, einem Geigerschen Zählrohr und einem Kolben Blausäure eingesperrt. Bei der radioaktiven Substanz besteht eine 50 prozentige Chance, dass innerhalb einer Stunde eines der Atome zerfällt, was von dem Geigerschen Zählrohr gemessen würde und in diesem Falle das Zertrümmern des Kolbens mit der Blausäure durch einen Hammer auslösen würde. Mit dem Ergebnis, dass die Katze stirbt. Dann wird eine Stunde gewartet.
Da nur eine 50 prozentige Chance besteht, dass eines der Atome zerfällt, existiert die Katze in dieser Stunde gleichzeitig in zwei sich wiedersprechenden Zuständen: Sie ist tot und sie ist lebendig (und vermutlich ziemlich verärgert).
Erst wenn wir nach Ablauf der Stunde die Stahlkammer öffnen und nachsehen, wird einer der beiden Zustände real und der andere verliert seine Bedeutung. In der Quantenphysik sagen wir auch, mit der Messung kollabiert das System der überlagernden Zustände.

Was hat das nun mit Projektmanagement zu tun?

Erfolgreiche Projekte basieren auf sinnvollem Projektcontrolling und erfolgreicher Projektsteuerung. Beides lebt davon, den aktuellen Zustand eines Projektes korrekt messen zu können. Und hier fängt nun oft das Problem an.

Die Wurzel unseres Problems liegt in der Art, wie wir Projekte planen. Bevor wir mit der Umsetzung anfangen:

  • Sammeln wir alle Anforderungen an das zu erstellende Ergebnis
  • Erstellen wir daraus ein detailliertes fachliches Konzept
  • Erzeugen wir basierend auf dem fachlichen Konzept ein detailliertes und vollständiges technisches Konzept
  • Leiten wir aus dem technischen Konzept alle notwendigen Tätigkeiten ab
  • Erstellen wir den Projektplan, der genau festlegt, wer bis wann was tun wird

Das Ergebnis ist quasi die vollständige Beschreibung des Lösungswegs. Die regelmäßige Fortschrittskontrolle findet nun in der Regel als Abgleich zwischen Tätigkeiten, die bis jetzt hätten fertig sein sollen und Tätigkeiten, die bis jetzt tatsächlich geleistet wurden statt. Wir messen den Projektfortschritt also auf der Basis geleisteter Arbeit gegen geplanter Arbeit. Klingt erst mal logisch.

Der Irrtum dieses Verfahrens liegt in der Annahme, dass der Projektplan vollständig und die Umsetzung fehlerfrei ist. Und der Schlussfolgerung, dass damit das Befolgen des Projektplans automatisch zum gewünschten Projektergebnis führt. Herauszufinden, dass dem allerdings oft nicht so ist, das ist nur durch realistisches Testen der Ergebnisse möglich. In der klassischen Projektplanung findet dies zumeist erst zum Ende des Projektes statt und da kann dann das Erwachen schmerzhaft sein. Wir finden eventuell erst in der Schlussphase des Projektes heraus, dass das Produkt nicht fertig ist oder nicht funktioniert, obwohl doch alle geplanten Tätigkeiten durchgeführt wurden. Jetzt noch das Projekt innerhalb von Time & Budget zu retten, ist schier unmöglich.

Der Grund für diese späte Erkenntnis ist: Wir messen das Falsche. Wir messen die Menge an geleisteter Arbeit und vergleichen das mit der Menge an Arbeit, von der wir glauben, dass sie notwendig ist. Was wir nicht messen ist das erzielte Ergebnis. Damit verbleibt unser Projekt trotz einer scheinbaren Messung in einem überlagerten Zustand, es ist gleichzeitig ein voller Erfolg und ein totaler Misserfolg. Im Bild von Schrödingers Katze wäre das so, als würden wir den Zustand der Katze rein durch das Verstreichen der Zeit bestimmen wollen, ohne dabei die Tür der Stahlkammer zu öffnen.

Wenn wir ein Projekt bewerten wollen, dann stellt sich zuerst die Frage nach dem erzielten Ergebnis, also was kann das erzeugte Produkt. Dicht gefolgt von der Frage nach den Kosten. Niemand wird uns aufrichtig für unseren unermüdlichen Arbeitseinsatz und die vielen geleisteten Stunden danken, wenn das Ergebnis nicht stimmt. Oder haben Sie schon Lobeshymnen für die vielen Stunden Arbeit gehört, die in den neuen Berliner Flughafen gesteckt wurden? Nein, was unsere Kunden an erster Stelle interessiert ist, ist das Produkt fertig und funktioniert es!

Wie können wir dieses Problem der falschen Fortschrittsmessung lösen? Nur indem wir in kurzen Abständen die Tür zur Stahlkammer öffnen und uns vom tatsächlichen Zustand der Katze überzeugen. Wir lassen das System der überlagernden Zustände durch die konkrete Messung kollabieren. Im Projektmanagement bedeutet das, dass wir uns in kurzen Abständen die tatsächlichen Ergebnisse ansehen, die bisher erzielt wurden.

Das Projektmanagementframework Scrum zeigt, wie das funktionieren kann. In Scrum werden innerhalb kurzer Iterationen von maximal vier Wochen Länge sogenannte potentiell auslieferfähige Produktinkremente erzeugt. Das bedeutet, es werden immer vollständige Funktionalitäten erstellt und zwar in finaler Marktqualität. Finale Marktqualität bedeutet in diesem Kontext, dass innerhalb der Iteration alle notwendigen Tätigkeiten durchgeführt werden, um diese Funktionalität ausliefern zu können. Bei den meisten Produkten würde das z.B. das vollständige Testen und Dokumentieren bedeutet. Das Ziel ist, dass eine Funktionalität am Ende einer Iteration wirklich fertig ist, es existieren keine versteckten Restaufwände für diese Funktionalität mehr.

Was sind jetzt versteckte Restaufwände? Versteckte Restaufwände sind alle die Tätigkeiten, die Sie ungeplant zu einem späteren Zeitpunkt durchführen müssen, damit die Funktion wirklich funktioniert. Zum Beispiel, dass Sie in der Test- oder Abnahmephase Ihres Projektes feststellen, dass eine Funktionalität nicht ordnungsgemäß funktioniert und Sie diese nun nachbessern müssen. Das ist Aufwand, den Sie höchsten indirekt durch Puffer eingeplant haben. Wobei Sie aber nicht wissen können, wie viel Puffer Sie tatsächlich brauchen werden. Oft ist es das, was Ihnen am Ende Ihres Projektes die Kopfschmerzen bereitet.

In Scrum bewerten wir am Ende jeder Iteration, welche Funktionalitäten wirklich fertig sind und welche nicht. Wir bekommen damit einen realistischen Überblick über den Zustand unseres Projektes und eine realistische Information darüber, wie schnell wir tatsächlich sind.
Auf diese neue Art der Bewertung umsteigen führt in vielen Projekten erst mal zur Ernüchterung. Plötzlich liegt Schwarz auf Weiß der Nachweis vor, dass die ursprünglichen Erwartungen mehr oder weniger zu optimistisch waren. Gerne wird nun die überraschend geringe Entwicklungsgeschwindigkeit erst mal dem Mehraufwand durch das direkte Testen zugeschrieben. Und Sie ahnen schon, welche Maßnahme dann gerne als erstes zur Steigerung der Projektperformance gewählt wird. Doch das ist purer Selbstbetrug, diesen Aufwand zum Testen und Nachbessern müssen Sie so oder so betreiben. Je weiter Sie ihn nach hinten verschieben, desto mehr erhöhen Sie das Risiko eines Projektfehlschlages.

In erfolgreichen Projekten stellen wir uns den Problemen, sobald sie auftreten und reduzieren damit Projektrisiken so gut wie möglich. Meine Lieblingsfrage, die ich Projekt- und Produktmanagern immer wieder gerne stelle ist: „Wann möchten Sie wissen, dass Sie ein Problem in Ihrem Projekt haben?“ Und die einzige sinnvolle Antwort darauf lautet: „So früh wie möglich!“ Je früher im Projekt Sie wissen, dass Sie ein Problem haben, umso mehr Optionen haben Sie noch, dieses Problem zu lösen und das Projekt so erfolgreich zu Ende zu führen.

„Ja, aber bei uns ist es nicht möglich innerhalb von vier Wochen eine ganze Funktionalität zu realisieren“. Wirklich? In der Tat gibt es vereinzelte Themenkomplexe, in denen Kernfunktionalitäten nicht so weit reduzierbar oder sinnvoll zerlegbar sind. Aber das ist bei weitem nicht so oft der Fall, wie es uns viele Projektmanager oder Produktverantwortliche glauben machen wollen. Denken Sie selber mal darüber nach, könnte es genau diese Sichtweise von zu großen Funktionalitäten sein, die die Entwicklung Ihrer Produkte so komplex und herausfordernd macht?

Ein anderer gerne genommener Einwand ist: „Wir können nicht innerhalb von vier Wochen etwas entwickeln und vollständig testen. Unsere Tests sind dafür viel zu Aufwändig.“ Sind diese Tests zu aufwändig, weil sie so gut und umfassend sind? Oder weil sie nicht effizient genug durchgeführt werden? Auch hier gilt die gleiche Antwort wie zuvor. Ja, in einigen Kontexten sind die Tests und anderen Abnahmeverfahren tatsächlich, selbst bei bester Organisation, nicht in einem derart kurzen Zeitraum machbar. Und auch hier ist das deutlich seltener der Fall, wie es zuerst scheint.

Was wir also sehen ist, dass es für die Umstellung von Projekten auf ein realistischen Bewertungs- und Messverfahren in kurzen Intervallen nicht einfach mit dem Beschluss getan ist, sich alle vier Wochen die Ergebnisse ansehen zu wollen. Tatsächlich ist es dazu notwendig, den gesamten Prozess, wie Produkte und Projekte geplant, entwickelt und getestet werden unter die Lupe zu nehmen und auf das Ziel der stückweisen Abnahme in kleinen Inkrementen umzustellen.
Eine Anstrengung die sich jedoch immer lohnt, denn sie führt zu einem Unternehmen, das in der Zukunft in kürzerer Zeit die bessern Produkte in besserer Qualität entwickeln wird. Überlassen wir also Schrödingers Katze den Physikern und arbeiten lieber mit eindeutigen Zuständen.

In der Quantenphysik dient Schrödingers Katze als Parabel, um den quantenmechanischen Effekt der Zustandsüberlagerung zu veranschaulichen und führt dort zu neuen Erklärungsversuchen unserer Welt oder so faszinierenden Ideen wie der Theorie unendlich vieler paralleler Universen.
Im Projektmanagement dahingegen führt Schrödingers Katze zu Kopfschmerzen und zu manchmal scheinbar unendlicher Frustration. Hier lässt sich Schrödingers Katze übrigens auch gut mit einer alten Weisheit der Dakota-Indianer kombinieren: Wenn dein Pferd tot ist, steig ab!
Diese Weisheit wird gerne im Kontext des Projektmanagements zitiert, um klar zu machen, dass gescheiterte Projekte losgelassen werden sollen. Aber wie wir oben schon gesehen haben, scheitern viele an der Frage, ob das Pferd denn wirklich schon tot ist.

So gesehen leiden viele Projekte sogar an Schrödingers Pferd!

Kommentare

Die Kommentare sind geschlossen.