Das Ergebnis ist quasi die vollständige Beschreibung des Lösungswegs. Die Fortschrittskontrolle findet dann oft 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 verglichen mit geplanter Arbeit. Klingt erst mal logisch.

Der Irrtum dieses Verfahrens liegt in der Annahme, dass der Projektplan vollständig und seine Umsetzung fehlerfrei ist. Und wird damit daraus geschlussfolgert, dass das Befolgen des Projektplans automatisch zum gewünschten Projektergebnis führen muss.

Um herauszufinden, ob der Projektplan tatsächlich vollständig war und wir mit ihm damit auch das vollständige und Funktionierende Ergebnis erzeugt haben, dass gewünscht war, ist jedoch nur durch eine realistische Überprüfung genau dieser Ergebnisse möglich. In der klassischen Projektplanung findet dies zumeist erst zum Ende des Projektes statt und da kann das Erwachen dann sehr schmerzhaft sein. Wir finden dann erst in der Schlussphase des Projektes heraus, dass das Produkt eventuell nicht fertig ist oder nicht funktioniert. Und das, obwohl doch alle geplanten Tätigkeiten durchgeführt wurden. Jetzt noch das Projekt innerhalb von Time und Budget zu retten, ist schier unmöglich.

Der Grund für diese späte Erkenntnis ist, dass wir das Falsche messen. 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. Und mit Ergebnis meine ich das, was uns wirklich interessiert: Das fertige, funktionsfähige und benutzbare Produkt[JH9]. Dadurch, dass wir in diesem Szenario nur die Ausführung der Aufgaben, aber nicht den Zustand des Ergebnisses überprüfen, verbleibt unser Projekt während seiner Laufzeit trotz einer regelmäßigen scheinbaren Messung in einem überlagerten Zustand: Es ist gleichzeitig ein voller Erfolg (wir führen erfolgreich die geplanten Aufgaben durch) und ein totaler Misserfolg (wir wissen nicht, ob am Ende des gewünschte Ergebnis herauskommen wird). 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 realistisch 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. Was unsere Kunden an erster Stelle interessiert ist, ob das Produkt fertig ist, wie gewünscht funktioniert und was es gekostet hat!

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ächlich erzielten Ergebnisse ansehen.

Das agile Framework Scrum zeigt, wie das funktionieren kann. In Scrum werden innerhalb kurzer Iterationen von maximal vier Wochen Länge sogenannte benutzbare Produktinkremente erzeugt. Das bedeutet, es werden immer vollständige Funktionalitäten erstellt, und zwar in finaler Marktqualität. Finale Marktqualität meint 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 Softwareprodukten würde das z.B. das vollständige Testen, Vorbereitung von Build und Deployment und die Erstellung von Dokumentation mit einschließen. Das Ziel ist, dass eine Funktionalität am Ende einer Iteration wirklich fertig ist und keine versteckten Restaufwände mehr für diese Funktionalität existieren. Welche Ansprüche genau ein Produktinkrement erfüllen muss, damit es als benutzbar gilt, definieren wir in einer sogenannten Definition of Done.

Was sind jetzt versteckte Restaufwände? Versteckte Restaufwände sind alle die Tätigkeiten, die wir ungeplant zu einem späteren Zeitpunkt durchführen müssen, damit die Funktion wirklich produktiv funktioniert. Wir stellen zum Beispiel in der Test- oder Abnahmephase unseres Projektes fest, das eine Funktionalität nicht ordnungsgemäß funktioniert. Oder in unseren Entwicklungs- und Testumgebungen hat sie funktioniert, aber nach dem Deployment in der produktiven Endumgebung tut sie es nicht mehr. Und jetzt müssen wir das natürlich nachbessern. Für Nachbesserungen in der Test- oder Abnahmephase hatten wir initial vielleicht noch genügend Puffer eingeplant, sodass es noch passt. Vielleicht aber auch nicht. Bei Nachbesserungen in der produktiven Endumgebung liegen wir eindeutig außerhalb des Plans. Diese zusätzlichen Aufwände, die so nicht geplant waren sind es, was uns am Ende eines Projektes die Kopfschmerzen bereiten.

Wenn wir mit Scrum arbeiten. dann 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 umzusteigen führt in vielen Projekten jedoch 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. Dieses Phänomen ist so normal, dass es sogar in der Psychologie Beachtung gefunden hat und dort als planning fallacy beschrieben wird. Gerne wird nun die überraschend geringe Entwicklungsgeschwindigkeit erst Mal dem Mehraufwand durch das direkte Testen zugeschrieben. Ich habe dann leider schon mehrmals erlebt, dass dann als Reaktion darauf das direkte Testen gestrichen und die Überprüfung wieder auf eine spätere Testphase verschoben wird. Denn gefühlt scheint es wichtiger zu sein, erst Mal möglichst viele Funktionalitäten zu erstellen und das gebündelte Testen und Korrigieren in dieser Phase wäre dann effizienter. Doch das ist purer Selbstbetrug. Den Aufwand zum Testen und Nachbessern müssen Sie so oder so betreiben. Je weiter Sie ihn aber nach hinten verschieben, desto mehr erhöhen Sie das Risiko eines Projektfehlschlages, da Sie nicht abschätzen können, wieviel Aufwand Testen und Korrigieren bedeuten wird und Ihnen damit möglicherweise am Ende die Zeit davonläuft, ein funktionierendes Produkt vorweisen zu können. Im schlimmsten Fall haben Sie am Ende ihres Budgets zwar viele Funktionalitäten erstellt, aber keine davon funktioniert wie gewünscht.

Wenn wir das Risiko in Projekten reduzieren wollen, dann müssen wir uns auftretenden Problemen stellen, sobald sie auftreten. 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 für mich einzige sinnvolle Antwort darauf lautet: „So früh wie möglich!“ 

Je früher wir im Projekt wissen, dass wir ein Problem haben, umso mehr Optionen haben wir 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“. Ist das wirklich so? In der Tat gibt es sehr vereinzelte Themenkomplexe, in denen Kernfunktionalitäten nicht so weit reduzierbar oder sinnvoll zerlegbar sind, dass sie innerhalb von vier Wochen umgesetzt werden können. Aber das ist bei weitem nicht so oft der Fall, wie es uns viele Projektmanager oder Produktverantwortliche glauben machen wollen. Denken Sie selbst 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 aufwendig.“ 

Hier müssen wir genau hinsehen, worin das Problem besteht. Ja, in einigen Kontexten sind die Tests und anderen Abnahmeverfahren aufgrund der Thematik ans sich tatsächlich, selbst bei bester Organisation, nicht in einem derart kurzen Zeitraum machbar. In den meisten Fällen liegt die Ursache für das Problem jedoch in der Struktur und Arbeitsweise der Organisation und nicht in der Thematik an sich. Vor allem in der Softwareentwicklung gibt es inzwischen eine Reihe von Ansätzen, über die das Testen deutlich leichtgewichtiger wird. Diese Ansätze setzen jedoch entsprechende Schulungen und oft auch Investitionen in Infrastruktur voraus und haben meistens auch Einfluss auf das Design der Lösungen, die in den Projekten entwickelt werden. In späteren Artikeln werden wir auf ein paar dieser Ansätze eingehen.

Es ist also in der Regel schon machbar, allerdings bedeutet es in vielen Fällen Investitionen in Knowhow und Infrastruktur und die Bereitschaft, alte Sichtweisen über Bord zu werfen.

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 zukünftig in kürzerer Zeit die besseren 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 klarzumachen, 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!