Value Driven Metriken (I)

outcome
Value Modell: Kobald Agile Expert & IT-Projects, 2016

Die Frage nach den Metriken im Projekt, die zeigen, ob das Projekt den angestrebten Geschäftsnutzen bringt oder nicht, sind meines Erachtens den projektinternen Metriken, ob das Projekt „gut läuft oder nicht“,  vorzuziehen. Was nicht heißt, dass Project Controlling außen vor zu lassen ist – im Gegenteil. Nur zeigt mir die Erfahrung, dass sich das Project Controlling den Geschäftsnutzen-Metriken anzupassen hat. Meine Diskussionshypothese lautet, dass ein Projekt nur erfolgreich ist, wenn projektinterne Metriken den geschäftsnutzenbringenden Metriken angepasst werden. Der Bedarf unserer Auftraggeber nach exakten Metriken zur Messung des Erfolgs eines Projektes ist ja immer dagewesen und noch immer da. Heute haben sich allerdings die Schwerpunkte deutlich verlagert. Deswegen kommt Expertenfunktionen wie etwa Business Analyse (BA), Requirements Engineering (RE), Projektmanagement (PM) oder IT-Service Governance seit einiger Zeit immer höhere Bedeutung zu. Natürlich beruhen diese Entwicklungen auf der Tatsache, dass nicht mehr allein „Zeit Geld ist“, sondern Output und Outcome über den Projekt – ergo – Markterfolg entscheiden und nicht methodologische Schwachsinnigkeiten wie das „magische Projektmanagementdreieck“.

Warum die Orientierung am magischen Projektmanagementdreieck Kafeesudlererei ist

Unleugbar war das so genannte magische Projektmanagmentdreieck im deutschen Sprachraum viele Jahre hindurch ein recht erfolgreicher Strukturierungsvorschlag für Projekte, Business Analysen oder Business Cases. Im angelsächsischen Raum hingegen ist dieses Modell unbekannt.

Durch den Einsatz des magischen Dreiecks konnte sehr gut aufgezeigt werden, dass, wenn sich eine Steuerungsgröße ändert sich auch die beiden anderen ändern. Nur ist es mit diesem Modell rational unmöglich gleichzeitig die Durchlaufzeit zu ändern, die Anforderung an die Qualität des Vorhabens anzuheben und das Budget des Projektes zu reduzieren. Anders ausgedrückt finden wir hier ein klassisches Pareto-Optimum vor: Kein Faktor kann besser gestellt werden, ohne dass der andere Faktor schlechter gestellt wird. Überhaupt wurde der Gedanke, dass man Durchlaufzeit verkürzen könnte, erst über diese „Magie“ in den Köpfen verankert. Allenthalben ist es genau dieser Strukturierung zu verdanken, dass es vielen Experten schwerfällt über (Projekt-) grenzen hinauszublicken. Das übliche Beispiel aus der Praxis lautet: „Wenn man für Projekt X zuständig ist, macht man seine Projektumweltanalyse, organisiert sich den BC von der Linie und dann zählt nur mehr der Projekterfolg per se“. Um diesen Projekterfolg sicherzustellen ist es noch immer gelebte Praxis über informelle und formale Netzwerke zu versuchen, sein Projekt als besonders nutzenbringend darzustellen – besonders, wenn die Budgettöpfe zu Jahresende gekürzt werden. Die Entscheidungen darüber was denn nun nutzenstiftend sei ist in diesen Zirkeln tatsächlich oft sehr magisch.

pareto-optimum
Pareto Optimum, Springer Wissenschaftsmedien, 2016

Leider wird das Projektdreieck-Modell, welches sich aus Leistung, Zeit, Kosten und einem schwammigen Qualitätsbegriff zusammensetzt, im daily business noch immer bis zum Abwinken angewandt. Ich weiß nicht, in wie vielen Präsenationen ich mir diesen antiquierten Mist schon ansehen musste.  Persönlich hat mich dieses Modell mit seiner metaphysischen Ausdrucksweise schon immer aufgeregt, denn als Rationalist kann ich auf „Magie“ gänzlich verzichten. Schlechterdings kommt der Begriff „Magie“ aus dem Altriechischen und bedeutet u. a. „Blendwerk“. Das Wort „Mager“ aus dem Altiranischen bezeichnet die metaphysische Zuordnung von bestimmten Kräften an Ereignisse oder Zustände. Eng damit verbunden ist die „Mantik“ – die Kunst der Zukunftsdeutung. Der Biologe und Pionier der kognitiven Entwicklungspsychologie, Jean Piaget, wies magisches Denken empirisch als eine Vorstufe des rationalen Denkens bei Kleinkindern zwischen zwei und fünf aus. Bedeutet der Umkehrschluss also, dass wir mit dem magischen Dreieck auf Kleinkinderniveau analysieren? Wenn nun ein Begriff als Standard in jedem Lehrbuch hinauf und hinunter zitiert wird, der letztendlich auf Magie – also Kaffeesudleserei – beruht, weiß ich was ich davon zu halten habe. Selbst wurde es mir immer wichtiger, Zeit, Budget, Costs, Business Case, E2E-Analyse, Human Resource und Technical Resource in ein jeweils dem Projektauftrag entsprechendes Controlling zu gießen, um darauf basierend das Projekt a) prinzipiell zielorientiert steuern zu können und um b) das Projekt dem erwünschten Geschäftsnutzen anpassen zu können.

Natürlich ist mir bewusst, dass wir IT-Spezialisten keine erkenntnistheoretischen Experten sein können. Dennoch bleibt für mich die spannende Frage offen, warum gerade metaphysische Magie als Modellbegriff verwendet wird. In Europa hätten wir ja die Denkstruktur des metrischen Erkennens seit der Antike in unseren Alltagsköpfen verankert. Sieht man auf seine Uhr gewinnt man blitzschnell die Erkenntnis, welche Uhrzeit es gerade ist. Das Gleiche gilt beispielsweise beim Ablesen der Geschwindigkeit auf unseren Tachos. Mit beidem verbinden wir das Ziel aus der Erkenntnis, Konsequenzen für uns abzuleiten. Diese neuronale Software wurde von uns durch Trial and Error in einem agilen Entwicklungsprozess programmiert. Zuerst mussten wir die Zahlen lernen, dann mussten wir lernen was dynamische Veränderung bedeutet, dann mussten wir lernen diese beiden Metriken zu kombinieren, um die die Uhrzeit ablesen zu können. Dann mussten wir für Zielmetrik 3 lernen, die 1. Metrik mit der 2. Metrik zu kombinieren, um aus diesem metrischen System „Uhrzeit“ Konsequenzen ableiten zu können. Erst die logische Kombination aus M1+M2+M3 ermöglicht uns die Einteilung der Uhrzeit, um mit M4 den gewünschten Zielzustand zu erreichen. Warum also, Magie anstatt Ratio? Bereits Aristotles war darum bemüht eine Methodologie des Erkennens über die Begriffe Logik und Ratio als differenzielle Unterscheidungsmerkmale darzulegen. Insbesondere Platon formulierte die epistemische Priorität des objektiven Bewussteins – der Kognition. Erkenntnis über Gegenstände könne man nur über eine Systematisierung und Mathematisierung der Erkenntnisbedingungen erhalten. Der große Immanuel Kant postuliert als Strukturelemente der gegenstände den Raum und die Zeit. Auf diesen Modellen beruhen heute noch bestimmte Theorien der Physik oder der Informationstechnologie. Und selbst die von mir hochgeschätzten Tom DeMarco, Kent Beck und Harry M. Sneed entwickelten Ihre Modelle auf den Grundlagen der logischen Analyse. Dass sie auf einem magischen Dreieck aufbauten, wäre mir neu. Übrigens wird die Erkenntnistheorie (einer der Vertreter ist Jean Piaget) im Divide et impera Algorithmus  Paradigma der Softwareentwicklung genauso angewandt, wie im modernen Requirements Engineering. Eine renommierte und wichtige Vertreterin des Requirements Engineering, Chris Rupp, hat gemeinsam mit Alfred Holl etwa im komprimierten Artikel „Erkenntnistheorie, (Wirtschafts-)Informatik und Requirements-Engineering by SOPHIST GmbH 2014“ diese Sichtweise veranschaulicht.

Der Bedarf an adäquaten Metriken 

Der Begriff „Kundenorientierung“ ist heutzutage wohl in jeder IT-Entwicklung die tragende Säule. Gleichviel ob wir Kundenorientierung über die Produktbetrachtung von Prince2, ITIL Services oder die Real Time return of Investment-Brille agiler Methoden interpretieren. Unsere Kunden haben eine ganz klare Erwartungshaltung an Effizienzsteigerungen. Die Logik des Kunden lautet: „Ich habe Zustand A und ich möchte Zustand B, der um den Faktor x mehr Nutzen, ausgedrückt in Euro, in mein Unternehmen bringt.“ Gleichzeitig gilt für mich die Regel, dass IT-Projekte immer ein Multiprojektmanagement erfordern, da sie immer mit Business Cases, Organisationonsunits, Software und Information Engeneering zusammenhängen. Die gr0ße Lehre aus den agilen Methoden für uns ist, dass wir in einem klassischen Projektlebenszyklus nicht nur von relativ statischen Phasen mit Arbeitspaketen, die in Time, Resource und Budget abzuwickeln sind ausgehen können. Vielmehr spiegelt die Realität den Bedarf wider einzelne Streams mit ihren Arbeitspaketen zuerst einmal als Costcender aufzufassen, um daraus das jeweilige Benefitcenter ableiten zu können. In Summe ergeben sich dann n Costcenter und n Benefitcenters (1:1 Verhältnis). Einen Business Case vorwiegend als Steuerungsinstrument zu verstehen, bei dem die Ableitung aus Budget und Costs mittels Ist-Soll-Gap einen wichtigen Indikator für das PM darstellt, ist in den heutigen komplexen und dynamischen Umfeldern antiquiert.

Meiner Erfahrung nach lässt sich mit der Kausalkette „Problem – Ursache – Lösung“ nicht nur inhaltlich arbeiten, sondern auch der Kundennutzen ableiten. Wie sieht die Realität aus? Egal in welcher Position man ein Mandat inne hat, zuerst einmal geht es darum einen inhaltlichen Scope zu erfüllen. Wir benötigen als Projektleiter, Requirements Engineers, Business Analysten oder agile Experten laufend Analysen, um einen Ist – Soll – Vergleich zu entwickeln mit dem wir wiederum steuern möchten. Was jedoch hindert uns daran, aufgrund dieser Analysen darüber nachzudenken, wie wir die klassische Soll-Ist-Analyse erweitern? Nur die praktische, mehrwertorientierte Steuerung kann zählen. Der bedarfsbezogene Abruf on demand, bedeutet auch bedarfsbezogene Benefitcenter-Analyse, um Rentabilität und Profitabilität sicherzustellen und zu optimiern. Das gelingt nur, wenn man über den Tellerrand blickt. Mut ist insofern nötig, als das mann neue Wege gehen muss. In einem Softwareprojekt hilft es im Gesamtzusammenhang nichts, wenn man das perfekte Testmanagement oder die perfekte Entwicklung über ein perfektes Cost Controlling abwickelt, um diese Daten dann in eine Matrix des magischen Dreiecks zu gießen, damit man bei Änderungen die Milchmariandel Erkenntis bekommt, dass das nicht geht, weil sich bei Änderungen der Durchlaufzeit, auch die Kosten verändern. Man kann zu agilen Methoden oder zu Software Engineering Methoden aus dem angelsächsischen Raum, etwa wie sie Kent Beck vertritt, stehen wie man will, aber eines ist sicher: Auch wenn diese Methoden durchaus andere schwerwiegende Methoden Probleme verursachen können, sind sie mir allemal lieber, als tautologische Projektmagie. Meines Erachtens sind vier Prämissen dieser Ansätze gleichzeitig wichtige Trigger für dynamische Projektsteuerung, mit denen die Realität des Gesamtzustandes recht genau dargestellt werden kann.

  1. Demand on Need (bedarfsorientierte Lieferung)
  2. Real Time Scaling (Echtzeit-Skalierung)
  3. Cost Controlling
  4. Real Time Return of Investment (Echtzeit-Nutzen)