Eins nach dem anderen

Richtig priorisieren in Softwareprojekten

Jürgen Lampe

©  Shutterstock / DRogatnev

Angesichts beschränkter Ressourcen ergibt sich in jedem Projekt die wiederkehrende Notwendigkeit, unter den anstehenden Aufgaben diejenigen auszuwählen, die als nächste bearbeitet werden müssen. In der Praxis wird die Entscheidung meist dadurch erschwert, dass nur ein Teil der benötigten Informationen verfügbar ist. Obwohl es einige methodische Ansätze gibt, die in dieser Situation helfen sollen, wird im Projektalltag oft nach persönlicher Erfahrung entschieden, zuweilen beeinflusst durch aktuelle, zufällige Befindlichkeiten wichtiger Stakeholder. Die Ergebnisse sind selten optimal.

Jeder Projektbeteiligte kennt diese Situation: Termine drücken, es ist noch viel zu viel zu tun, aber keiner weiß, was jetzt das Wichtigste ist. Es muss priorisiert werden. Obwohl allen die Relevanz dieses Schritts bewusst ist, wird dabei viel zu oft wertvolle Zeit vergeudet. Häufig fehlen irgendwelche Daten, die für einen sachlich umfassend begründeten Entschluss notwendig wären. Entscheider, denen die Wichtigkeit und Konsequenzen ihrer Anweisungen bewusst sind, vermeiden schnelle Entschlüsse. Wenn anstehende Entscheidungen aber hinausgeschoben werden, führt das nicht nur zu vermeidbaren Verzögerungen. Während der Wartezeit steht die Welt nicht still und Einflussfaktoren können sich verändern. Man läuft Gefahr, dass die letztlich getroffene Auswahl auf zu diesem Zeitpunkt schon veralteten Daten beruht, oder dass zusätzliche Arbeit erforderlich ist, um die Vorlagen zu aktualisieren. Je größer und hierarchischer ein Unternehmen aufgebaut ist, desto verheerender können die Folgen solcher verschleppter Prozesse sein. In einem Erfahrungsbericht wird als Beispiel aufgeführt, dass die Realisierung eines Features, dessen Implementierung gut zwei Wochen erforderte, insgesamt 46 Wochen gebraucht hat. Davon waren 38 Wochen Wartezeit auf Entscheidungen. Die Relation ist sicher schon außergewöhnlich, aber Wartezeiten, die sich zu verblüffenden Größen addieren, finden sich fast überall.

Und dieses Problem besteht nicht nur im Großen. Beim agilen Vorgehen müssen für jeden Sprint die anstehenden Backlog Items priorisiert werden. Dabei ist der kritische Punkt weniger die Wartezeit, als der Fakt, dass auch dabei falsche oder ungünstige Priorisierungen erfolgen können.

Decision Fatique

Die Bezeichnung Decision Fatique geht auf einen bereits 2011 erschienen Beitrag zurück. Er beschreibt die Erkenntnis, dass sich auf wissenschaftlicher Basis auch bei der rein intellektuellen Tätigkeit des Entscheidens etwas beobachten lässt, das der Ermüdung bei physischer Bewegung vergleichbar ist. Es scheint, als ob jeder Mensch pro Tag nur über eine begrenzte Menge Entschlusskraft für fundierte Entscheidungen verfügt. Alles, was er sich selbst oder andere ihm darüber hinaus abverlangen, ist im Ergebnis messbar schlechter und bisweilen sogar seinen eigenen Interessen zuwiderlaufend. Diese wichtige Erkenntnis hat im deutschsprachigen Raum bisher leider wenig Beachtung gefunden. Das sieht man auch daran, dass bisher keine griffige Übersetzung des Begriffs existiert. Dabei könnten naheliegende Konsequenzen für wichtige Entscheidungen sein:

  • Entscheidungen möglichst früh am Tag zu treffen und somit an vielen Stellen die Qualität zu verbessern, nicht nur bei den schon so genannten Entscheidern, sondern auch beim Entwickeln und Programmieren von IT-Lösungen.
  • Wirklich schwere Entscheidungen durch gute Vorbereitung sowie mithilfe von geeigneten Regeln und Methoden vermindern.
  • Entscheidungen sollten delegiert und an der dezentralen Stelle erfolgen, wo die aktuell beschaffbaren Informationen zur Verfügung stehen.

Eine Entscheidung, die auf Basis unsicherer oder fehlender Daten getroffen werden muss, wird nicht dadurch besser, dass die Verantwortung an eine höhere Ebene verlagert wird. Ganz im Gegenteil ist zu erwarten, dass an solchen Schlüsselpositionen durch Überforderung die (Entscheidungs-)Qualität leidet. Was dieser Exkurs zeigen soll, ist, dass sich die durch das Warten auf Priorisierung entstehenden Verzögerungen nicht oder nur sehr beschränkt durch administrative oder organisatorische Maßnahmen verringern lassen. Durch Zwang, mehr in kürzerer Zeit zu bewältigen, sind eher nachteilige Auswirkungen zu erwarten. Der Weg zur Beschleunigung führt vor allem über bessere Verfahren für das Unterstützen von Entscheidungen.

Das Ziel im Auge behalten

Jedes sinnvolle Auswahlverfahren braucht eine Zielstellung. Das scheint trivial, ist es in der Umsetzung aber oft nicht. Das liegt daran, dass für die Messung des Unternehmenserfolgs recht unterschiedliche Verfahren üblich sind. Wirtschaftswissenschaftler haben in den letzten zwanzig Jahren eine Vielzahl von Koeffizienten entwickelt, mit dem Ziel, Managemententscheidungen messbar und damit vergleichbar zu machen. Solche Zahlen erfreuen sich großer Beliebtheit, weil sie den Einfluss des Controllings erhöhen und die Verantwortlichen von der Bürde des Entscheidens nach qualitativen Gesichtspunkten befreien. Das ist verständlich, hat aber durch die einseitige Orientierung auf Kostenfaktoren zur Vernachlässigung der Innovationen und damit des Wachstums geführt. Deshalb ist es wichtig, sich an eine einfache Wahrheit zu erinnern: „The purpose of business is to create and keep a customer“ (Peter Drucker). Der Begriff Kunde impliziert, dass dabei ein Gewinn abfällt. Wäre dies nicht so, wäre es kein Geschäft, sondern eine karitative Handlung. Kostensenkung ist dabei kein Selbstzweck, vielmehr dient sie der Beschaffung freier Mittel für Innovationen und damit der Gewinnung neuer Kunden.

Eine solche ganzheitliche Sicht auf alle Unternehmensprozesse wirft ein anderes Licht auf untergeordnete Fragen, wie die hier betrachtete Priorisierung. Sie eröffnet Chancen für alternative Lösungswege. Was gern übersehen wird, ist, dass im Unterschied zu einfachen Massenprodukten, wo die Kostenminimierung pro Teilerzeugnis zu einem insgesamt optimalen Ergebnis führt, dies bei komplexen Prozessen mit vielen Abhängigkeiten nicht gilt.

Eine interessante Möglichkeit, diesem Dilemma zu entkommen, besteht darin, für jede Aufgabe zu schätzen, welche Kosten für das Unternehmen durch eine verspätete Lieferung entstehen würden. Eine konkrete Ausformung dieser Methode unter dem Namen Cost of Delay Devided by Duration, kurz CD3, und ihre Anwendung wird hier beschrieben. Tatsächlich handelt es sich dabei um die Spezialisierung einer Planungsstrategie, die unter dem Namen Weighted Shortest Job First (WSJF) bereits länger bekannt ist [1].

Verzögerungskosten schärfen den Fokus

Warum sind die Verzögerungskosten ein geeigneter Maßstab, um den Wert einer Aufgabe zu beziffern? Für die Beantwortung dieser Frage sollte man sich einige Tatsachen, die die gegenwärtige wirtschaftliche Entwicklung prägen, in Erinnerung rufen. Die Marktsituation verändert sich mit hohem Tempo. Entsprechend schnell müssen Anpassungen erfolgen (Volatilität). Bei neuen Produkten entscheidet häufig der Einführungszeitpunkt über den Erfolg (Time to Market). Kapital ist in der Regel ausreichend verfügbar. Begrenzende Faktoren sind dagegen Entwicklungskapazitäten und die verfügbare Zeit.

Bei dem häufig anzutreffenden Vorgehen, anhand des prognostizierten Return on Investment (ROI) zu entscheiden, bleibt der wichtige Faktor Zeit unberücksichtigt: Der ROI wird unabhängig vom Realisierungszeitpunkt gesehen. Diese verengte Betrachtung vernachlässigt die Dringlichkeit, fördert das Entstehen von Stapeln offener Beschlussvorlagen und damit unnötig lange Durchlaufzeiten. Wenn auf jeder Vorlage ein Betrag steht, den die Verschiebung der Entscheidung auf die nächste Woche kostet, entsteht ganz automatisch ein besseres Verständnis für die ökonomische Bedeutung zügiger Bearbeitung.

Ein positiver Nebeneffekt der Orientierung auf die Verzögerungskosten, die ja nichts anderes als entgangener Nutzen sind, ist die Schärfung des Blicks für die eigentlich zu lösenden Probleme. Denn um ein Problem in seinen Konsequenzen quantifizieren zu können, muss es analysiert werden. An dieser Fokussierung fehlt es häufig. In realen Aufgabenlisten finden sich fast immer Einträge, die eher Lösungsvorschläge als Problembeschreibungen sind. Das muss nicht grundsätzlich schlecht sein, birgt aber die Gefahr, dass nur ein Symptom eines unerkannten größeren Problems behandelt wird. Sehr wahrscheinlich gibt es weitere Symptome, die zusätzliche Arbeitspakete, und damit eigentlich überflüssigen Aufwand, zur Folge haben.

Ein weiterer Nachteil, den von Anwenderseite vorgeschlagene Lösungen häufig haben: Sie beruhen auf falschen Annahmen. Um mit einer Software arbeiten zu können, benötigt jeder Nutzer eine gewisse Vorstellung davon, wie diese funktioniert. Er entwickelt ein inneres Modell. Es ist aber extrem unwahrscheinlich, bei komplexen Systemen sogar ausgeschlossen, dass dieses innere Modell dem tatsächlich implementierten Modell so ähnlich ist, dass sich auf dieser Basis wirklich gute Vorschläge zum Beheben eines erkannten Defizits entwickeln lassen. Deshalb ist es insgesamt viel effektiver, das Problem genau zu beschreiben, einschließlich der Eigenschaften der erwarteten Lösung, und das Design der Umsetzung denjenigen zu überlassen, die das tatsächliche technische Modell kennen.

Weil der Nutzen nicht allein dadurch entsteht, dass ein bestimmter Ablauf oder eine Datenstruktur geändert wird, lässt es sich bei der Quantifizierung gar nicht vermeiden, den Blick auf das eigentliche Problem zu richten. Ein Problem zu lösen ist zwar eine anspruchsvollere Aufgabe als nur eine Lösung zu implementieren. Der Vorteil besteht aber darin, dass der Lösungsraum, d. h. die Anzahl möglicher Varianten, größer ist, und damit die Chance steigt, eine besonders gute Lösung zu finden.

Sehen Sie auch im JAX TV: Gernot Starke: Raten, Schätzen, Zählen, Rechnen: Praktische Tipps zum Umgang mit Unbekanntem

Verzögerungskosten ermitteln

Wie alle Aussagen, die sich auf die Zukunft beziehen, umfasst auch die Ermittlung der Verzögerungskosten einiges an Spekulation. Aber darin unterscheidet sich dieses Verfahren nicht von anderen. Im Fokus sollte nicht die Präzision der Zahlen, sondern deren prinzipielle Richtigkeit sein. In der Textilindustrie wird diese gewissermaßen qualitative Sicht auf Zahlenwerte dadurch erreicht, dass Kleidungsgrößen wie S, L oder M verwendet werden. Im Unternehmensmaßstab ist das jedoch unangemessen, weil die Unterschiede für solch eine simple Messlatte einfach viel zu groß sind. Ein Geldbetrag allerdings ist eine Größe, mit der jeder umgehen kann.

Ausgangspunkt für die Bestimmung der Verzögerungskosten ist die übliche Kosten-Nutzen-Analyse. In deren Rahmen sollten auch solche nicht direkt messbaren Größen wie ein erwarteter Reputationszuwachs bereits wertmäßig berücksichtigt sein. Ganz unabhängig von dem hier Beschriebenen, sollte ebenso immer eine Betrachtung enthalten sein, welchen Einfluss der Einführungszeitpunkt auf den prognostizierten Nutzen hat. Der Erste am Markt kann beispielsweise meist höhere Margen durchsetzen. Gegebenenfalls müssen diese Kosten noch ergänzt werden. Neben dem unmittelbar erkennbaren und im Nachhinein auch messbaren Wert entstehen bei der Projektdurchführung auch mittelbare Werte. Das ist einmal der Erfahrungszuwachs bei den Durchführenden, der sie beispielsweise Folgeaufgaben schneller lösen lässt. Und das ist der Erkenntnisgewinn über die eigenen Prozesse, aus dem neue Aufgaben oder Geschäftsideen entstehen können. Allein schon die Auseinandersetzung mit den letztgenannten beiden Punkten kann nützlich sein. Natürlich bedarf es einiger Übung, bis solche Schätzungen wirklich gut ausfallen.

Schätzungen schätzen lernen

Schätzungen sollen ein Gefühl für die Größenordnung liefern. Sie sind mit Unsicherheiten behaftet und basieren auf Annahmen. Um ihre Genauigkeit im Laufe der Entwicklung verbessern zu können, ist es essenziell, alle Annahmen einschließlich der unmittelbaren Ableitungen explizit zu machen. Jeder Arbeitsfortschritt vermehrt die Erfahrungen und Kenntnisse. Dieser Wissensgewinn kann für die Schätzungen aber nur erschlossen werden, wenn er an den richtigen Stellen einfließt, d. h. wenn die ursprünglichen Annahmen angepasst oder korrigiert werden. Deshalb sollte es selbstverständlich sein, Schätzungen kontinuierlich zu pflegen und auf der Basis der jeweils vorliegenden Erkenntnisse zu aktualisieren.

Nach Möglichkeit sollten Schätzungen im Team erarbeitet oder zumindest besprochen werden. Wichtig ist dabei, dass die einzelnen Teammitglieder unterschiedliche Sichten auf den Objektbereich repräsentieren. Hier wird berichtet, dass besonders erfahrene Manager zwar insgesamt gute Ergebnisse zuwege bringen, aber in einer nicht zu vernachlässigenden Zahl von Fällen ihre Ansicht nach gründlicher Diskussion revidieren mussten.

Es gibt keinen Grund, Schätzungen mit dem Hinweis auf fehlende Daten zu unterlassen. Schließlich schätzt man ja gerade deshalb, weil es nicht genau berechnet werden kann. Vergleichbar einem iterativen Näherungsverfahren kommt man dann – bei richtigem Vorgehen – der korrekten Lösung immer näher. Wenn der Startpunkt mangels Erfahrung ungünstig gewählt wird, braucht man eben ein paar Zyklen mehr.

Zu guter Letzt noch eine elementare Voraussetzung, die leicht in Gefahr gerät, übergangen zu werden: Schätzungen dürfen nicht unter administrativem Druck erfolgen. Wenn Grenzen vorgegeben werden, kann man sie auch gleich verwenden. Noch schlimmer ist es, wenn eine unzutreffende Schätzung mit Sanktionen geahndet wird, weil dadurch der Fokus vom eigentlichen Ziel auf die Vermeidung persönlicher Nachteile verschoben wird. Trotzdem ist es natürlich richtig und wichtig, nachträglich die erreichte Güte auszuwerten – aber ausschließlich mit dem Ziel, daraus zu lernen.

Innerhalb von Projekten arbeiten

Die bisher vorgestellten Überlegungen eignen sich vor allem für die Managementebene, wo es darum geht, bestimmte Vorhaben zu starten, aufzuschieben oder aufzugeben. Der Gedanke kann jedoch einfach auf kleinere Teilaufgaben, insbesondere IT-Projekte, übertragen werden. Optimal wäre es, die Verzögerungskosten direkt auf die einzelnen Implementierungsaufgaben herunterzubrechen. In solch einem Szenario hat jede Aufgabe ihren klar bezifferten Wert. Das ändert die Sicht der Entwickler auf ihre Arbeit, indem es den Wert der individuellen Leistung sichtbar macht und gleichzeitig die Wahrnehmung für die geschäftlichen Erfordernisse schärft. Daraus lässt sich unter Umständen ein Motivationsschub generieren.

In vielen Fällen wird diese direkte Übertragung der Verzögerungskosten nicht möglich sein, z. B. weil Fachbereiche nicht ausreichend kooperieren oder die Abhängigkeiten zwischen den Teilaufgaben zu vielfältig sind. Dann bleibt immer noch die Möglichkeit, nur die Verzögerung zu betrachten. Das bedeutet, die Verzögerungskosten für ein Feature ergeben sich aus der resultierenden Verzögerung für das Gesamtprojekt. Diese Betrachtung liefert ebenso eine valide Basis für die Bewertung von Anforderungen zwischen den Teilprojekten oder Teams. In so einer Situation besteht immer die Gefahr, dass die eigenen Aufgaben gegenüber den extern herangetragenen bevorzugt werden.

Die Dauer ist ein wichtiger Faktor

Die weitere Aufbereitung der Aufgaben ist nur dann sinnvoll, wenn überhaupt ein bemerkenswerter Effekt zu erwarten ist. Insofern erhält man mit den Verzögerungskosten einen aussagekräftigen Filter, der alle die Vorhaben aussondert, die vielleicht auch ganz nett wären, aber letztlich keinen Gewinn für das Geschäft bringen. Bisher wurden nur die Kosten von Verzögerungen betrachtet. Das Verfahren heißt aber CD3 und nicht CD2, weil in die Gewichtung auch die geplante Dauer einer Aufgabe eingeht, und zwar im Nenner. Der Hintergrund ist ganz einfach: Ohne Berücksichtigung des Umsetzungsaufwands würden in der Tendenz große Aufgaben bevorzugt, weil bei ihnen – hoffentlich – auch der größere Nutzen zu erwarten ist. Eine solche Bevorzugung wäre aus zwei Gründen nachteilig: Erstens würden kleine Aufgaben überproportional häufig verzögert und zweitens sind große Aufgaben naturgemäß mit größeren Unsicherheiten behaftet, sodass unnötige Risiken geschaffen würden

Beide Effekte könnten auch dadurch ausgeschlossen werden, wenn statt der Dauer die Kosten der Umsetzung einfließen, wie es an den meisten Stellen durchgeführt wird. Tatsächlich ist die Dauer weitgehend proportional zu den Kosten. Die Dauer hat jedoch den Vorteil, dass durch sie eine anstehende Aufgabe umfassender gekennzeichnet wird als nur durch die Kosten. Denn trotz aller Budgetzwänge ist Kapital am leichtesten zu beschaffen. Die verfügbaren Entwicklungskapazitäten sind demgegenüber immer begrenzt. Während die Kapazität eine obere Grenze bestimmt, gibt es für die notwendige Dauer eine Untergrenze. Diese ergibt sich einerseits aus der verfügbaren Kapazität und andererseits aus der Art der Aufgabe. Es ist ein oft widerlegter Irrglaube, Entwicklungen in der IT durch Bereitstellung von Ressourcen beliebig beschleunigen zu können. Für jede Aufgabe gibt es eine von vielen lokalen Bedingungen abhängige optimale Teamgröße. Wenn diese überschritten wird, führen die zusätzlich notwendigen Interaktionen nur zum Absinken der Gesamtleistung.

Die Dauer ermöglicht es, die besprochenen Gesichtspunkte ohne großen Aufwand einzubeziehen und eröffnet darüber hinaus noch die Möglichkeit, dynamische Verzögerungskosten genauer zu berücksichtigen. Durch die Dauer wird der frühestmögliche Einsatzzeitpunkt bestimmt und damit die Basis für das Berechnen möglicher Verluste. Das erleichtert es beispielsweise, rechtzeitig zu erkennen, dass ein langwierig zu realisierendes Feature zum Einsatzzeitpunkt keinen nennenswerten Nutzen mehr bringen wird. Schließlich ist die Dauer in der Regel auch ein gutes Maß für die Komplexität einer Aufgabe.

Die CD3-Methode anwenden

Damit sind alle Bestandteile der CD3-Methode versammelt. Es kommt nun darauf an, sie richtig einzusetzen. Bevor das an einem kleinen Beispiel illustriert werden soll, noch ein wichtiger Hinweis: Es ist nicht die Aufgabe von Hilfsmitteln wie der hier dargestellten Methode, den Menschen das Denken abzunehmen. Es geht darum, die ermüdenden und wenig kreativen Teile zu vereinfachen und den Kopf für das Wesentliche freizubekommen. In die Bewertung müssen nach wie vor alle wichtigen Aspekte der konkreten Situation einbezogen werden. Das folgende Beispiel findet sich hier. Es zeigt für drei Features jeweils die Verzögerungskosten und die Dauer sowie den daraus berechneten CD3-Wert (Verzögerungskosten durch Dauer) (Tabelle 1).

Feature Verzögerungskosten pro Woche in US-Dollar Dauer in Wochen CD3
A 1 5 0,2
B 4 1 4
C 5 2 2,5

Tabelle 1: Features mit unterschiedlichen Verzögerungskosten und Dauern

Wie man sieht, taucht die Zeiteinheit Woche sowohl im Zähler (Verzögerungskosten pro Woche in US-Dollar) als auch im Nenner (Dauer in Wochen) auf, ist also für den CD3-Wert unerheblich. Man kann somit problemlos auf einen der Aufgabe angepassten Zeithorizont skalieren, bei großen Vorhaben beispielsweise auf Monate, in agilen Teams auf Wochen oder Tage. Priorisiert wird nach dem höchsten CD3-Wert, d. h. den höchsten Verzögerungskosten per Dauer.

Tabelle 2 stellt die resultierenden Gesamtverzögerungskosten für drei mögliche Priorisierungen dar. Die Berechnung erfolgt zunächst nach dem Originalverfahren, bei dem auch die Dauer der Umsetzung als Verzögerungszeit betrachtet wird. In der Spalte „Verzögerungskosten alternativ“ wird der Gesamtwert ohne die Dauer ausgewiesen. Da die Differenz konstant ist, verändert das nichts an der Rangfolge. Es ist aber ehrlicher, weil die Kosten, die während der Umsetzung eines Features anfallen, gar nicht vermieden werden können und damit durch die Priorisierung nicht beeinflussbar sind.

Reihenfolge der Umsetzung Berechnung (je Feature Verzögerung*Kosten) Verzögerungskosten insgesamt Verzögerungskosten alternativ
B, C, A (CD3-Prio) 1*4 + (1+2)*5 + (1+2+5)*1 27 8
A, B, C (FIFO) 5*1 + (5+1)*4 + (5+1+2)*5 69 50
C, B, A (Kosten) 2*5 + (2+1)*4 + (2+1+5)*1 30 11

Tabelle 2: Vergleich der kumulierten Verzögerungskosten

Die drei miteinander verglichenen Auswahlmethoden sind: CD3-Prio, Auswahl in der Reihenfolge der CD3-Werte (höchster zuerst), FIFO, Auswahl in der Reihenfolge des Eingangs, und Kosten, Auswahl nur nach den Verzögerungskosten pro Zeiteinheit, ohne Berücksichtigung der Dauer. Es ist wenig überraschend, dass die CD3-Methode die geringsten Verzögerungskosten liefert, weil sie genau auf die gewählten Kriterien zugeschnitten ist.

DDD Summit 2018
Nicole Rauch

Domain-Driven Design für Einsteiger

mit Nicole Rauch (Softwareentwicklung und Entwicklungscoaching)

In der Praxis

Leider ist das reale Leben selten so einfach, wie in solch eindrucksvollen Beispielen demonstriert. Ein Problem mit derartig auf Arbeitspakete fokussierten Verfahren liegt in der Vernachlässigung strategischer Gesichtspunkte. Optimiert wird hauptsächlich das taktische Agieren. Um längerfristigen Zielen, wie einer bestimmten IT-Strategie, Ausdruck zu verleihen, müssen die ermittelten Kennzahlen nachjustiert werden. So könnte man für Vorhaben, die zur Umsetzung der Strategie wichtig sind, die Verzögerungskosten erhöhen.

Eine andere Schwierigkeit, die in der Praxis häufig auftritt, ist die, dass Aufgaben nicht nur nacheinander, sondern parallel gelöst werden. Das schafft zusätzliche Einschränkungen, wenn Kapazitäten den Entwicklungssträngen nur exklusiv oder eingeschränkt verfügbar sind. Daraus ergibt sich dann ein Einfluss auf die Dauer. Grundsätzlich ändert das nichts an der Anwendbarkeit des Verfahrens. Es wird allerdings etwas aufwendiger, weil sich die günstigste Variante nicht mehr einfach aus den CD3-Werten herauslesen lässt. Stattdessen müssen zunächst realisierbare Kombinationen aufgestellt und unter diesen dann die optimalen gesucht werden.

Vielfach lassen sich Arbeitsaufgaben nicht wirklich unabhängig realisieren. Wenn es funktionale Abhängigkeiten gibt, kann man versuchen, die Verzögerungskosten entsprechend weiterzureichen. Mit Hinblick auf den globalen Nutzen sollte man darüber hinaus versuchen, diese Abhängigkeiten zu bewerten und ebenfalls zu priorisieren. Auf sehr niedrig bewerteten Beziehungen kann eventuell ganz verzichtet werden, oder es wird nach angemessenem Ersatz gesucht.

Der Bericht über die Einführung der CD3-Methode bei der Maersk-Line-Reederei enthält einige aufschlussreiche Beobachtungen. Auch wenn man nicht erwarten kann, dass sich diese bei jeder Anwendung so wiederholen, zeigen sie, entlang welcher Dimensionen die Weiterentwicklung von geschäftsrelevanter IT verbessert werden kann. Das erste und inzwischen wohl auch am häufigsten zitierte Resultat ist die in Abbildung 1 gezeigte Verteilung der Verzögerungskosten auf die Anforderungen. Kurz gesagt, ein kleiner Anteil der Anforderungen steht für fast den gesamten erreichbaren Gewinn.

So eindrucksvoll diese Kurve auch ist, letztlich bestätigt sie nur eine unter dem Namen Pareto-Prinzip oder 80/20-Regel  bekannte Erfahrung, dass sich der größte Teil eines Resultats (vermeintlich 80 Prozent) bereits mit geringem Aufwand (20 Prozent) erreichen lässt. Der Nutzen besteht also vor allem darin, dass die Verzögerungskosten dabei helfen, die wirklich wertschöpfenden Anforderungen zu erkennen. Außerdem muss man bei der Bewertung dieses Ergebnisses beachten, dass es aus der Einführungsphase der neuen Methodik stammt. Es ist ganz natürlich, dass dabei positive Effekte überzeichnet werden. Interessant wird es, die Veränderungen dieser Kurve über längere Zeit zu betrachten. Sollte sie sich zusehend abflachen, kann das, positiv gesehen, ein Zeichen für einen wachsenden Reifegrad oder, negativ, für schwindende Innovationskraft sein.

Positiv bewertet wird die Tendenz statt auf große Projekte stärker auf kleinere Aufgabenpakete zu setzen. Das trägt der Erkenntnis Rechnung, dass mit der Projektgröße die Wahrscheinlichkeit des Scheiterns zunimmt. Eine einfache Wahrheit, der man durch keine Methode entkommen kann, ist: Jede Neuerung kann scheitern. In dieser Lage bergen kleinere Aufgabenpakete schon aufgrund des geringeren Umfangs geringere Risiken, beschleunigen den Rückfluss von Erfahrungen und sind leichter zu schätzen und zu bewerten. Andererseits verlagern sie einigen Aufwand aus den Projekten zurück ins Management. Das kann insgesamt jedoch positiv sein, weil darunter viele Dinge sind, die andernfalls als Anfragen an den Produkteigentümer (Product Owner) zu Quellen möglicher Projektverzögerungen werden könnten.

Die beschriebene Priorisierung erlaubt es, das direkte Ablehnen von Anforderungen zu vermeiden. Üblicherweise wird in so einem Fall eine stichhaltige Begründung erwartet. Deren Zusammenstellung verursacht jedoch nur Aufwand ohne jeden Nutzen – Zeit und Energie, die besser für das Erkennen gewinnträchtiger Vorschläge verwendet werden können. Quasi nebenbei wird die aus einer Zurückweisung entstehende Frustration vermieden und es werden Chancen erhalten. Manche Anforderung kommt einfach zum falschen Zeitpunkt, d. h. zu früh.

Bei allen geschilderten Vorteilen sollte man nie dogmatisch vorgehen. Aus der Optimierungstheorie ist bekannt, dass bei vielen deterministischen Verfahren die Gefahr besteht, mit einem lokalen Optimum zu enden, obwohl es global noch bessere Ergebnisse gibt. Eine Strategie gegen diese Gefahr besteht darin, zufällige Störungen in den Ablauf einzubauen. Diese könnten darin bestehen, neben den wichtigen Aufgaben immer noch einen kleinen Teil von zufällig ausgewählten, niedrig priorisierten Anforderungen umzusetzen. Unverhofft kommt oft. Hin und wieder wird sich darunter eine falsch eingeschätzte Chance finden. Fast alle wirklich großen Innovationen sind mehr oder weniger per Zufall entstanden.

Lesen Sie auch: Der Product Owner im Casino: Backlogs priorisieren mit Costs of Delay und Monte-Carlo-Simulationen

Fazit

Es ist überraschend, wie wenig der Faktor Zeit in den meisten Methoden zur Priorisierung von Aufgaben berücksichtigt wird. Das steht im krassen Gegensatz zu der Häufigkeit, mit der das Schlagwort Time to Market gebraucht wird. Aber „Zeit ist Geld“ gilt nicht nur für die Umsetzungsphase, sondern im gleichen Maße für die vor- und zwischengelagerten Entscheidungsprozesse. Die hier präsentierte CD3-Methode [2] ist ein Ansatz, der Zeit nicht nur verbal Bedeutung zuzumessen, sondern sie explizit in den Auswahlprozess einfließen zu lassen. Das Preisschild, das damit auf jeder Entscheidungsvorlage klebt, benennt ja nicht nur die Kosten für die Verschiebung der Realisierung. Es zeigt ebenso die Kosten, die durch die Verschiebung der Entscheidung entstehen können. Damit wird die Aufmerksamkeit der Verantwortlichen quasi beiläufig auf die wirklich relevanten Vorhaben gelenkt. Und ganz nebenbei ist es noch ein Hinweis, welcher Aufwand für die Vorbereitung und das Fassen der Entscheidung höchstens gerechtfertigt ist. Wenn man dann noch in der Einladung zur abschließenden Besprechung den Wert von zehn Minuten Diskussionszeit (als Summe der Arbeitszeitkosten) aufführt, lässt sich wohl manche Verzögerung vermeiden.

Ein weiterer zentraler Punkt dieses Vorgehens ist, dass die Verzögerungskosten den Blick auf das lenken, was wirklich zählt: die Stellung am Markt, und zwar in absoluten Zahlen. Um das Potenzial der IT für die Geschäftsprozesse besser zu erschließen, ist es eminent wichtig, diese von Fachseite nicht nur als Dienstleister zu sehen, sondern als Partner oder sogar Treiber der Fortentwicklung. Schließlich ist die Umsetzung fachlicher Vorgaben in qualitativer und zeitlicher Hinsicht für den Erfolg oft ebenso wichtig wie die Idee selbst. Je besser die vertrauensvolle Zusammenarbeit klappt, desto genauer werden die involvierten Schätzungen ausfallen und umso größer die Verbesserung der Geschäftsprozesse.

Geschrieben von
Jürgen Lampe
Jürgen Lampe
  Jürgen Lampe ist IT-Berater bei der Agon Solutions GmbH in Frankfurt. Seit mehr als 15 Jahren befasst er sich mit Design und Implementierung von Java-Anwendungen im Bankenumfeld. An Fachsprachen (DSL) und Werkzeugen für deren Implementierung ist er seit seiner Studienzeit interessiert.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: