Cost of Delay (III)

Nochmal zum Thema Cost of Delay, also zu den Verzögerungskosten, die auftreten, wenn ein Produkt oder Feature zu langsam fertig wird. Diese Kosten werden gemessen in (ungefähren) Geldbeträgen, die verpassten oder verzögerten Gewinnen entsprechen. Auf den ersten Blick erscheint das Zwangsläufig und nicht weiter erwähnenswert, bei näherer Betrachtung ist darin aber eine eigentlich offensichtliche Implikationen enthalten, die aber manchmal vergessen wird.

Um Verspätungskosten finanziell messen oder schätzen zu können, ist etwas ganz Grundlegendes nötig: ein Business Case des Produkts oder Features nämlich, für das diese Kosten ermittelt werden sollen. Das ist in vielen Fällen auch gut möglich, etwa bei neuen Autos oder Computerspielen, bei neuen Funktionen komplexer und abstrakter Produkten wie z.B. Betriebssystemen oder Online-Portalen ist es dagegen deutlich schwieriger und ggf. sogar unmöglich.

Noch am Einfachsten ist es in Fällen, in denen diese Funktionen kostenpflichtig gekauft oder abonniert werden können. In derartigen Konstellationen lassen sich nach Fertigstellung die Gewinne rückwirkend auf die "verpassten" Monate übertragen, oder alternativ kann bereits während der Planung von einem voraussichtlichen Gewinn ausgegangen werden, dessen drohendes Verpassen ggf. kurzfristige Mehraufwände rechtfertigen kann.

Schwieriger wird es, wenn neu erstellte Features nicht separat monetarisierbar sind. Ein Umweg den man hier gehen kann, ist der über die Marktforschung: wenn eine Neuerung ein Differenzierungsmerkmal ist (oder ein Differenzierungsmerkmal eines Wettbewerbers egalisiert) kann man annehmen, dass Umsätze (und damit Gewinne) ganz oder teilweise auf sie zurückzuführen sind, was sich dann annäherungsweise in Geld quantifizieren lässt.

Praktisch unmöglich wird die Ermittlung von Cost of Delay, wenn die jeweilige Funktionalität weder separat vermarktet wird, noch von Kunden als Differenzierungsmerkmal wahrgenommen wird (oder überhaupt separat wahrgenommen wird). Ein internes Diagnose-Programm wäre ein Beispiel dafür. Natürlich ist es aus Produktsicht sinnvoll und mehrwertstiftend, es ist aber nichts, das man einem Kunden in Rechnung stellen oder ihm gegenüber vermarkten könnte.

Für derartige Funktionen ist eine separate Ermittlung von Verspätungskosten schlicht nicht machbar, was eigentlich auch kein Problem ist - schliesslich müssen sie nicht zwanghaft für jedes Feature gemessen werden. Entweder fallen sie ganz aus derartigen Betrachtungen heraus, oder sie entsprechen der kompletten Verspätungskostensumme des Gesamtprodukts - dann nämlich, wenn dieses ohne die einzelne Funktion nicht verkauft werden kann oder darf.

Der Vollständigkeit halber: Wird in überregulierten Umgebungen versucht, eine kategorische Anwendung dort zu erzwingen, wo das eigentlich nicht geht, ist meistens Cargo Cult die Folge. Dann kann es z.B. sein, dass für Funktionen ohne Business Case einer "nach Bauchgefühl" ermittelt wird, z.B. mit Planning Poker. Diesen Wert kann man dann in die Dokumentation schreiben um den Vorganben gerecht zu werden, es ist aber nicht mehr als Business-Theater, das man auch sein lassen kann.