dot.tipp - Was sind die Konsequenzen von Fixed Scope - Fixed Time Projekten?

Claudio Zenerino
14. Mai 2019

Fixed Scope und Fixed Time Vorhaben führen zu minderer Qualität. Mindere Qualität hat Konsequenzen. Dieser Blogbeitrag beschreibt den Preis, der bezahlt werden muss.

Als Beispiel dient ein «Fixed Time - Fixed Scope» Vorhaben eines Kunden, welches in diesem Blogbeitrag bereits umschrieben wurde.

Zusammenhänge des Projektmanagement-Dreiecks

dot_blog_content_kosten_reduktion

Das Projektmanagement-Dreieck beschreibt den Zusammenhang von Projektgrössen und hat je nach Blickwinkel vermeintlich andere Kanten respektive Projektparameter. Die Aussage ist, dass man maximal zwei der Projektparameter festlegen kann, und der dritte Parameter entsprechend veränderbar ist. Bei der Software-Entwicklung hat sich gezeigt, dass häufig die Kanten fachlicher Scope (fachlicher Umfang der Software), Time (der Zeitpunkt, wann die Software geliefert werden soll) und technische Qualität (die technischen Qualitäten, die die Software aufweist: Anzahl Bugs, Anzahl Shortcuts, Anzahl alte Technologien in der Lösung etc.) sinnvolle Parameter sind.

Es sind immer gute Absichten dahinter

Auch bei «Fixed Time - Fixed Scope» Vorhaben startet man normalerweise mit dem guten Vorsatz, auf die entwickelte Code-Qualität zu achten. Je näher eine Deadline rückt, desto mehr ist man gezwungen, Shortcuts in der Entwicklung zu nehmen. Jedoch ist, wie der Name schon sagt, der Scope fix und wird nicht verkleinert. Stattdessen wird zwangsläufig mindere Code-Qualität geliefert. Denn dies ist der einzige Parameter, den man noch verändern kann.

Wie kommt es zu «Fixed Time - Fixed Scope»?

dot_blog_content_binding_contract_commitment

Deadlines mit fixem Scope sind meistens das Symptom von externen Abhängigkeiten. Versprechen, die jemandem ausserhalb des Teams gegeben wurden, wann dieses oder jenes fertig sein wird. Beim porträtierten Kunden-Team ist dies beipielsweise ein Versprechen, welches die Marketing-Abteilung einforderte, welcher Scope zu welcher Zeit geliefert wird, damit TV-Werbeslots eingeplant und Werbefilme gedreht werden konnten. Damit nun diese Kosten nicht unnötig ausgegeben werden, wird die rechtzeitige Lieferung des benötigten Scopes eingefordert. Es ist also eine nachvollziehbare wirtschaftliche Forderung, um nicht unnütz Geld auszugeben.

Gute Absichten führen zu unbewussten verheerenden Konsequenzen

Diese kostenbewusste Forderung geht nun jedoch Hand in Hand mit möglichen neuen Kosten, die dadurch verursacht werden: Die erhöhten Betriebs- und Weiterentwicklungs-Kosten durch mindere Qualität. Denn wie vorher ausgeführt, geht man mit der Forderung nach Deadlines mit fixem Scope zwangsläufig das Risiko ein, Code-Qualitätseinbussen zu verursachen. Man muss also die Kosten beider Medaillenseiten kennen, um einen fundierten Entscheid fällen zu können.

The bitterness of poor quality remains long after the sweetness of low prices is forgotten.
(Benjamin Franklin)

Meistens wird kein bewusster Entscheid dazu gefällt. Auch beim porträtierten Kunden-Team war dies nicht anders. Kein Entscheidungsträger entschied also bewusst, dass geringere Code-Qualität geliefert werden soll, sondern nur, dass die Deadline gehalten werden muss, damit die Marketing-Kosten nicht explodieren.

Mindere Code-Qualität führt zu längerer Time-to-Market

Die folgende Tatsache verdeutlicht das schwerwiegende Problem minderer Code-Qualität: Betrachtet man die Kosten im Lifecycle einer Software, dann sind nicht die initialen Entwicklungskosten vor dem GoLive der grosse Brocken, sondern alles, was danach kommt. Laut Wikipedia entsprechen die Software-Wartungskosten 80-90% der Total Costs of Ownership und nur 10-20% machen somit die initialen Investitionen aus. (Ich gehe davon aus, dass diese IT-Kosten die TV-/Marketing-Kosten deutlich übersteigen. Dieses Bewusstsein muss entwickelt werden.)

So entsteht die Maintenance Trap

dot_blog_content_mess

Mindere Code-Qualität führt zu längerer Time-to-Market und im Extremfall kann mindere Code-Qualität ganze Softwareentwicklungsteams lahmlegen.

Die Software Maintenance Trap stellt sich ein.

Einige Entwickler laufen davon. Andere Entwickler bleiben bei ihrem Job und «überleben» die Mitarbeitenden-Fluktuationen im Team. Sie sind gezwungen, sich im Code-Dschungel zurecht zu finden. Sie häufen sich ein sehr spezifisches Knowhow an, das nur mangelhaft dokumentiert ist und nicht so einfach transferiert werden kann, weil sie alleine sind und nicht gezwungen sind zu dokumentieren. Neue Mitarbeitende einzuarbeiten, wird schwierig. Nun sind wir definitiv in der Maintenance-Trap angekommen, die dann schnell 10 Jahre andauert, bevor eine Neuentwicklung die alte, schwierig wartbare Software ablöst. Weiterentwicklungen sind kaum mehr umsetzbar oder nur mit einem enormen Kraftakt.  

Qualität als Lösung

Um nicht in diese Maintenance-Trap zu fallen, und damit ein Team nach Abschluss eines Vorhabens ein neues Vorhaben umsetzen kann, muss die Qualität stets sehr hoch sein!

Das porträtierte Kunden-Team musste auch Shortcuts nehmen, um die Deadline zu halten. Man hat sich jedoch fest vorgenommen, nach der Deadline die Code-Qualität in einem dedizierten Sprint zu verbessern. Sofern nicht die nächste Deadline ansteht.

Das Gute an der oben beschriebenen Argumentationskette: Jede Qualitäts-/Deadline-Entscheidung kann aufs Neue eine Chance sein, das Richtige zu tun.

Wie funktionieren eure Fixed Time - Fixed Scope Projekte?

Was sind eure Erfahrungen in der Softwareentwicklung mit Fixed Time - Fixed Scope Settings? 

Möchtest du mehr über die Zusammenhänge im SDLC erfahren? Möchtest du gemeinsam deine Vorhaben challengen und durchleuchten?

Kontakt

Keine Kommentare bis jetzt

Lass uns wissen, was du darüber denkst ...

Newsletter Anmeldung

Das könnte dich ebenfalls interessieren

diese Artikel in Effective Delivery