Der Cone of Uncertainty ist ein nützliches Instrument, wenn es darum geht, Schätzungen oder Prognosen in einer agilen Welt zu erstellen. Denn wer schon länger mit Agile arbeitet und weiß, wie man die Philosophie an der Front gut umsetzt (sprich: Kundennutzen liefert), stellt oft fest, dass am Backend alle möglichen Probleme auftreten (sprich: Ressourcen wie Budgetierung, Kapazität, Zeit). Denn wie kann man eine Veränderung vollständig umsetzen, wenn das Backend noch auf die alte Weise eingerichtet ist? Dies beginnt mit der Erkenntnis, dass auch das Backend eine agile Philosophie erwartet. Deshalb erzählen wir Ihnen in diesem Beitrag alles, was Sie über den Cone of Uncertainty wissen müssen.
Was ist der Cone of Uncertainty?
Der Cone of Uncertainty, wörtlich übersetzt der „Kegel der Ungewissheit“, bezieht sich auf das Projektmanagement und zeigt die Entwicklung des Grades der (Un-)Gewissheit eines Projekts über einen bestimmten Zeitraum. Visuell wird dies in einem Diagramm über zwei Achsen dargestellt. Die vertikale Achse enthält die Variable „Schätzung vs. Variabilität“, oder: den Grad der Unsicherheit. Die horizontale Achse zeigt die Variable „Zeit“. Im Wesentlichen gilt der Grundsatz: Je früher im Projekt, desto größer ist die Unsicherheit und desto schwieriger sind die Schätzungen.
Die Gewissheit nimmt im Laufe eines Projekts zu
Zu Beginn eines Projekts ist oft wenig bekannt. Alle Schätzungen, die zu diesem Zeitpunkt gemacht werden, sind mit einem hohen Maß an Unsicherheit behaftet. Umso mehr Fragezeichen sollten daher zu dem Zeitpunkt gesetzt werden, an dem die Organisation zu Beginn eines Projekts große Vorhersagen erwartet. Gerade indem man zunächst mehr Forschung und Erfahrung sammelt, hilft man sich selbst, die relevanten Informationen zu sammeln, die es einem ermöglichen, bessere Schätzungen vorzunehmen.
Mit fortschreitendem Lernen im Laufe des Projekts sinkt der Grad der Unsicherheit, bis schließlich kein Risiko mehr bei der Erstellung von Schätzungen besteht. In diesem letzten Fall läuft das Projekt logischerweise auf sein Ende (Lieferung) zu. Alles, was dafür benötigt wird, ist die Variable „Zeit“ (die x-Achse).
Das Paradoxon Lernen vs. Leistung
Lassen Sie den Zeitfaktor genau das sein, was beim agilen Arbeiten und Verändern noch unzureichend verstanden wird. Das hat alles mit dem Wunsch zu tun, schnell Ergebnisse zu erzielen. Das Paradoxon Lernen vs. Leistung muss erst besser verstanden und angenommen werden. Nur wenn anerkannt wird, dass Lernen, Veränderung und Innovation Zeit brauchen, kann dieser Ansatz sein volles Potenzial entfalten. Der Glaube, dass „Zeit“ Geld kostet, ist eine angstgetriebene Denkweise. Wenn man die Zeit richtig verbringt, lernt und wertvolle Informationen sammelt, kann man die richtigen Entscheidungen und Einschätzungen treffen, die einem später viel Zeit sparen.
Wo ist der Cone of Uncertainty zu finden?
Der Cone of Uncertainty wird im Projektmanagement eingesetzt und dient ursprünglich dazu, Erkenntnisse über die Entwicklung des Projektumfangs zu gewinnen. In einem sich schnell verändernden Umfeld ist es undenkbar, einen statischen Umfang zu versprechen. Im Laufe des Projekts werden alle möglichen Informationen gesammelt, die es dem Team ermöglichen, die Variabilität des Umfangs zu verringern und ihn immer schärfer zu gestalten. Hier stellt sich die Frage: Was ist Teil des Umfangs und was ist nicht Teil des Umfangs?
Neben dem Umfang gibt es noch weitere Variablen, die für bessere Schätzungen relevant sind:
- Budget
- Zeit
- Kapazität
Lesen Sie hier mehr über die Variablen und ihren Einfluss auf das agile Projektmanagement.
Das lernt man, indem man sich in der Anfangsphase (im agilen Sinne die ersten 2-3 Sprints) die richtigen Informationen beschafft, um Aussagen über die betreffende Ressource zu treffen. Bei den Informationen handelt es sich zunächst oft um Kenntnisse über die Zielgruppe, die Bedürfnisse, die Wünsche und die zu erstellenden Produktkomponenten. Sie machen dann Schätzungen nur auf der Basis der Informationen, die Sie haben. Dadurch lernt man automatisch, „klein“ zu denken.
Der iterative Prozess der Produktentwicklung am Backend (Ressourcen) läuft genau so ab. Sie machen zum Beispiel Budgetschätzungen pro Periode. Auf diese Weise sind Sie viel präziser, als wenn Sie im Voraus ein Jahresbudget („groß“) festlegen, das die tatsächlichen Ausgaben überhaupt nicht widerspiegelt.
Fazit
Die Frage, die Sie sich als Organisation stellen sollten, lautet: Wollen wir eine Zahl/Schätzung zu einem bestimmten Zeitpunkt haben, weil das Geschäftsjahr es erfordert, oder wollen wir genaue Schätzungen zu einem Zeitpunkt haben, an dem sie auf die bestmögliche Weise ausgegeben werden können? Im letzteren Fall bauen Sie einen iterativen Prozess von Schätzungen auf, die sich auf die jeweiligen Ergebnisse beziehen. Auf diese Weise liegen Kosten und Nutzen eng beieinander, und Sie sind äußerst agil, um Risiken kontinuierlich zu mindern, indem Sie bei Bedarf Anpassungen vornehmen. Mit diesem Prozess macht es nicht nur Ihren Mitarbeitern mehr Spaß, sondern Sie erzielen auch einen effizienteren und wertvolleren Informationsfluss, um die richtigen Entscheidungen zu treffen.
