Value Driven Metriken: Output und Outcome-Unterscheidung als Erfolgsgaranten (letzter Teil III)

Drei Scrumsäulen
Vaulue Driven Businessnutzen, Kobald Agile Expert & IT-Projects, 2016

In den beiden ersten Teilen habe ich das Thema Value-Driven-Metriken entlang unterschiedlicher Perspektiven diskutiert. In fachlichen Gesprächen mit Kolleginnen und Kollegen wird immer wieder über hohe Aufwände für die Administration der Überprüfungsmetriken diskutiert. Das kann natürlich stimmen und mitunter ist der Administrationsaufwand durchaus nicht zu unterschätzen. Daher ist es mein Credo, so viel Aufwand wie nötig, aber so wenig Aufwand wie möglich mit der Erstellung und Dokumentation von Metriken zu betreiben. Weiter ist es mir wichtig die jweiligen Modelle multiplizieren zu können, um nicht ständig das Rad neu erfinden zu müssen. Ich fahre sehr gut damit, Schätzen, Metriken und Cost Center (od. Capability Center) in einem Kausalzusammenhang zu betrachten. Weiter meine ich, dass die Projektmetriken den Business-Nutzen-Metriken anzupassen sind. Controlling-Metriken mit denen man in Echtzeit und punktgenau reporten kann, sind in dynamischen IT-Projekten – und wann ist ein IT-Projekt nicht dynamisch? – das Um und Auf für den Projekterfolg. Empirische Analysen zeigen eindeutig, dass von 100% gescheiterter IT-Projekte um die 80% an einer unzureichenden IT-Projekt Setup-Phase scheitern. Eine andere internationale Studie zeigt, dass 70% der gescheiterten Projekte wegen Planungsfehlern scheitern. Hier liegt der Schlüssel zum Projekterfolg und somit auch zu den Projekt-Metriken. Entscheidend ist und bleibt die erste Phase. Im weiteren orientiere ich mich auf Relaeases. Diese Herangehensweise eignet sich im agilen genauso, wie im klassischen Umfeld.

Output und Outcome spannen den valaue driven Metrikenraum von iterativen Metriken

Aus der agilen Welt habe ich die Idee mich an Capabillities und deren Impact auf das Business übernommen. Gerne stelle ich die Kostenentwicklung der Optimierung des Businessnutzen gegenüber. Das Delta entscheidet beispielsweise bei einem Krisenprojekt, oder einem Projekt mit angespannter Budgetsituation über die weiteren Optionen der Steuerung. Der Vorteil liegt für mich darin, dass die Capabilities zumeist recht genau mit der Business Strategy korreliert werden können. Weiter ist meine Erfahrung, dass die Velocity immer wichtiger wurde und wird. Wie schnell, also in welchen realistischen Zeitintervallen kann ich Businessnutzen mit einer Capability stiften, und stimmen die Kosten für diese mit dem erwarteten, oder neuberechneten Business Value überein. Wie entwickelt sich ein mögliches Delta (Gap)? Das ist ein zentrales Richtmaß für mich, um nicht an den Kosten oder der Zeit drehen zu müssen. Steve McConnell meint dazu sehr treffend:

If you don’t have time to do the job right,“ the old chestnut goes, „where will you find the time to do it over?

Passende Ressourcenberechnung

Übrigens ist die Teamgröße und das Problem mit Ressourcenaufstockungen in einem laufenden Projekt ebenfalls eine wichtige Kenngröße für mich. Mit Ressourcenaufstockungen ist zuallermeist das Vaterland verloren, weil die Onboarding-Costs und die mögliche Velocity-Verzögerung den möglichen Value der Mehr-Ressourcen auffressen. Das ist allseits bekannt, aber dennoch wird an dieser Praxis paradoxerweise sehr oft festgehalten. Es ist mir zumeist gelungen, selbst in nicht agilen Projekten, mit der Einführung von Iterationen, die ich ja unabhängig von Releases mit Orientierung auf den PSP sehr gut aufsetzten kann, die Velocity zu halten.

Mir scheint es auch fatal die notwendige Teamgröße nicht bereits vor dem Projektstage 1 zu berechnen. Jeder Requirementsengineer, jeder Softwareentwicklungsanbieter berechnet bei Angebotslegungen die notwendigen Ressourcen. Ressourcen sind Kosten. Daher ist es ratsam bereits sehr früh halbwegs genau über die benötigten Ressourcen-Aufwände bescheid zu wissen. Leider wird diesen Berechnungen häufig nicht geglaubt und die benötigten Ressourcenaufwände werden einfach um xy gekürzt. Dies in der Annahme damit Geld zu sparen. So sicher wie das Amen in der Kirche kommt jedoch der Tag, wo man vor dem Problem des Ressourcengebirges steht. Je später der Zeitpunt des Ressourcenproblem-Eintritts, desto geringer die Chance tatsächlich noch skalieren zu können, denn der kritische Pfad wurde viel zu spät wahrgenommen oder beachtet. Aber auch die umgekehrte Konsequenz kann eintreten. Der so genannte Halo-Effekt sagt aus, dass ein Mitarbeiter immer bussy aussieht, obwohl das Arbeitspaket schon vielleicht seit zwei Wochen fertig sein könnte, aber die Deadline dafür, aufgrund der ungenauen Ressourcenaufwands-Berechnung, exakt vom Mitarbeiter eingehalten wird. Auch das ist ganz schön blöd für eine annähernd optimale Steuerung einer Softwareentwicklung.

Arbeit dehnt sich aus, bis sie die Zeit, die ihr zur Verfügung steht, vollständig ausfüllt. Cyril N. Parkinson

Seit zwei, drei Jahren versuche ich das Thema Kommunikationsaufwand so weit als möglich in meine Berechnungen miteinfließen zu lassen. So besitzt ein Team mit 10 Teammembern bereits 45  Kommunikationspfade. Das ist bereits 4,5-mal so viel Kommunikationsaufwand,  wie bei einer Teamgröße von 5 Teammembern. Jeder von uns weiß, wie schwierig es ist eine brauchbare Kommunikationsstruktur aufzubauen. Kommunikation kostet Zeit und Geld. Daher ist mir direkte Kommunikation mit meinen Kollegen lieber, als xy Mails, Chats und SMS am Tag. Plant man eine gute Meetingstruktur, so kann unnötiger Kommunikationsaufwand deutlich reduziert werden.

Wie bereits erwähnt unterscheide ich immer Output und Outcome. Mit Output ist das Werk der Entwicklung bezeichnet. Mit Outcome ist die weitere Wirkung der Anwendung auf den Geschäftsnutzen gemeint. Soweit ich sehe, ist diese Unterteilung essentiell, um Value-Driven-Metrics zur Steuerung festzulegen. Dabei gilt für mich die aus dem agilen Umfeld stammende Aufforderung: AVOID WASTE! Anders ausgedrückt reden wir dabei vom altbekannten Pareto-Prinzip. Oft wird für 20% ungenauer Lösungen unverhältnismäßig hoher Aufwand betrieben, um eine schöne Lösung für die nächsten 200 Jahre zu haben. Recht eigentlich können bestimmte Capabilities häufig über Operations gelöst werden – vorausgesetzt man hat einen brauchbaren PSP und Operations ist integriert. Gleichzeitig sollte man mit den Metriken flexibel sein und nicht auf zu Beginn generierten Berechnungen, die ganze Projektlaufzeit hindurch festhalten. Meines Erachtens ist hier Agilität on its best gefragt. Weiter ist für mich das, ebenfalls aus der agilen Welt kommende, Prinzip der lightweight documentation wesentlich. Der Trigger hierzu ist die Frage, welcher Report wird wann on demand benötigt, um den unterschiedlichen Stakeholdern (etwa Projektteam, Steering, Entwicklungsteam, etc.) die aktuellen Zahlen liefern zu können? Da ich von Teamschätzungen mit Delphi, Planning Pokers und T-Shirt-Sizing überzeugt bin, wende ich diese Methoden auch immer an. Diese sind um nichts ungenauer wie high sophisticated Excellmodelle oder irgendeine passende Software dazu.

Die Einwirkung theoretischer Wahrheiten auf das praktische Leben geschieht immer mehr durch die Kritik, als durch Lehre. (Carl Philipp Gottfried von Clausewitz)

outcome
Outcome-Flow-Chart, Kobald Agile Expert & IT-Projects, 2016

Mir ist es wichtig noch einmal darauf hinzuweisen, dass meiner Erfahrung nach das Project Controlling den Geschäftsnutzen-Metriken anzupassen ist. Meine Diskussionshypothese lautet, dass ein Projekt nur erfolgreich ist, wenn projektinterne Metriken den geschäftsnutzenbringenden Metriken angepasst werden. Dafür spricht auch meine positive Erfahrung über die Jahre hinweg. Damit spanne ich den für mich notwendigen Raum zwischen Output und Outcome auf. Sowohl der Projektoutput als auch der Geschäftsoutcome sind genau zu betrachten. Änderst sich der eine Vektor so ändert sich auch der andere Vektor. Entscheidend für den Markterfolg ist immer der Outcome einer Softwareentwicklung. 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.

Wer dauerhaften Erfolg haben will,
 muß sein Vorgehen ständig ändern. (Niccoló Machiavelli)

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.“ Nur die praktische, mehrwertorientierte Steuerung kann zählen. Jeder Value Driven Ansatz ermöglicht die Entwicklung von passenden Cost Center, die metrisch messbar gemacht werden. Aber dazu sollte man eine wesentliche Fähigkeit mitbringen und zwar optionsoffenes Denken. Meines Erachtens sind vier Prämissen gleichzeitig wichtige Trigger für dynamische Projektsteuerung, mit denen die Realität des Gesamtzustandes recht genau dargestellt werden kann.

  • Demand on Need (bedarfsorientierte Lieferung)
  • Real Time Scaling (Echtzeit-Skalierung)
  • Cost Controlling der Projekt Cost Center
  • Real Time Return of Investment (Echtzeit-Nutzen)

Not everythink that counts can be counted and not everythink that can be counted counts. (Albert Einstein)

Welche Zahlen zählen?

70-30-chart-social-vs-kpi-2016-v1
Pareto Steuerung, Kobald Agile Expert & IT-Projects, 2016

Vor allem sollten wir daran denken, dass Metriken eine Ergänzung sind und keinesfalls die einzig zählende Säule. Nicht Metriken bestimmen etwa eine Appllikationsentwicklung sondern die Menschen. Häufig stelle ich in Gesprächen mit Kollegen und Kolleginnen fest, dass sie meinen, nur mehr Zahlen und Reports hin und her zu schupfen, aber dadurch kaum mehr Zeit für kollaboratives Team Work zu haben. Diese Erfahrung teile ich teilweise. Ich stellte mir jedoch immer häufiger die Frage: Was ist mir außer dem Geschäftserfolg in IT-Projekten wichtig? Dazu gesellte sich eine eher gozentrische Frage: Wie steige ich mit meiner Energie dabei am besten aus? Lange bevor Agilität hinauf und hinunter diskutiert wurde, war für mich klar, dass mir die an der Software arbeitenden Kolleginnen und Kollegen extrem wichtig sind. Diese innere Entscheidung bedeutete jedoch, dass ich meine Ressourcenaufwände priorisieren muss. Für mich ist die anzustrebende Größe zwischen Metriken und kollaborativem Team Work, so wie in der Grafik dargestellt,  am wertvollsten in allen Belangen. Damit fahre ich seit gut 6 Jahren hervorragend.

Um annähernd diesen Wert zu erreichen, habe ich zuersteinmal damit begonnen, mein Selbstmanagement zu optimieren. Sie werden vielleicht fragen was das Geschwätz über meine innere Befindlichkeit und meine persönliche Planung mit Projekt-Metriken zu tun hat? Für mich jedenfalls fast alles, denn damit sehe ich den passende Echtzeit-Metriken, gepaart mit guten Schätzungen und der ungeschminkten Wahrheit ins Auge. Wie ich bereits im Vorgänger-Artikel anmerkte wäre alles andere für mich Kaffeesudleserei.

Seit ca. 5 Jahren habe ich in meinen Terminkalendern prinzipiell alle privaten und beruflichen Termine und Verpflichtungen eingetragen. Weiter kalkuliere ich bei jedem Termin eine Vor,- u. Nachbearbeitungszeit ein. Und ich setze mir jeden Tag fixe Timeslots als Blocker. Diese nütze ich gerne, um dort und da auf ein Plauscherl zu gehen. Jedenfalls hat mich meine Selbstmanagement-Methode dazu gebracht, darüber nachzudenken, wie ich effektiv und effizient KPI’s generieren sowie pflegen kann, um die Zeit mit den Kollegen zu haben, die mir wichtig ist. Außerdem gestalte ich Metriken dynamisch. Unterm Strich ist es mir völlig egal, ob dann mehr von agilen Schätzmethoden dabei ist, oder mehr vom Earned Value Management. In Wirklichkeit müssen wir Freelancer uns während eines Auftrags zumeist an unternehmensspezifische KPI’s sowie spezifischen KPI-Anforderungen unterschiedlichster Stakeholder halten. That’s part of the game.

Orientierung am Hier und Jetzt

Was ich  im letzten Abschnitt anmerken möchte mag bei manchen von Ihnen trivial klingen. Nur ist mein Best Practice Ansatz von Konsequenz geprägt und daher weit entfernt von Trivialmustern. Eine Kernfrage vor jedem IT-Projekt ist die sehr einfache nach dem Sinn des Projekts: Was wollen wir mit dem IT-Projekt erreichen? Und die ehrliche Antwort darauf muss lauten: Natürlich wollen wir Geld verdienen! Also bestimmen unseren Metrikraum bereits mehrere zu erstellende Messungen: Output vs. Outcome, KPI’s, Deltas, Aufwände und Kosten sowie Budget.

Wenn wir an das Kano-Modell denken, dann muss eine Softwareentwicklungen die Leistungs,- u. Basisfaktoren liefern, um zumindest die Erwartungen unserer Kunden zu erfüllen. Denn selbstverständlich möchten unsere Kunden mit dem zu liefernden Produkt ebenfalls Geld verdienen. Mir ist bewusst, dass es IT-Projekte gibt die auf die Erfüllung von z. B. gesetzlichen Rahmenbedingungen abzielen. Hier könnten wir auch wirklich Begeisterungsfaktoren entwickeln, etwa wenn durch unsere Softwarlösung ein paar Prozesschritte zusätzlich automatisiert werden. Meiner Erfahrung nach ist das eher erreichbar, wenn man ein IT-Projekt im Hier und Jetzt misst und nicht zu sehr in die Prognose geht. Ich persönlich kann mit Prognosen kaum etwas anfangen. Gerne berechne ich Trends in Intervallen einer Größe ausgedrückt. Prognosen aber sind für mich Kaffeesudleserei.