Wohl jeder Dienstleister, der für seine Kunden Software entwickelt, kennt folgende Situation…

Ein Kundenprojekt mit einem (zumindest zu Beginn) fixen Scope ist zu einem Festpreis umzusetzen. Und dies obwohl nicht nur der Dienstleister als Lieferant, sondern auch der Kunde an einem iterativ-inkrementellen Vorgehen interessiert ist – insbesondere an der expliziten Möglichkeit, Anforderungen noch während der Umsetzung ändern oder detaillieren zu können. Der Kunde jedoch kann oder will nicht nach einer agilen Methodik verfahren und aktiv eine Rolle in einem agilen Prozess (z.B. Product Owner in Scrum) wahrnehmen. Sei es entweder, weil die Kundenorganisation mangels Erfahrung agile Prozesse scheut oder weil sie diese aufgrund von Restriktionen (von meistens vertraglicher Natur) schlicht verunmöglicht.

Change for Free – Definition

Eine solche Ausgangslage wirkt sich ungünstig auf den Projekterfolg aus und lässt offen, wie mit Change Requests verfahren werden soll. Dass diese Ausgangslage aber bei vielen Projekten auftritt, hat auch Scrum-Mitbegründer Jeff Sutherland erkannt. Daraufhin stellte er sein Konzept Change for Free vor, welches schlussendlich als Scrum Pattern weiter Eingang in die Agile Community fand. In vereinfachter Form ist sein Konzept bzw. Pattern aber sowohl in agilen wie auch in plangetriebenen Projekten anwendbar:

Während der Umsetzung des Projekts können Anforderungen ohne Mehrkosten gegen ursprünglich nicht vereinbarte Anforderungen ausgetauscht werden sofern folgende Voraussetzungen erfüllt sind:

  1. Die zu entfernenden Anforderungen befinden sich noch nicht in der Umsetzung.
  2. Der Umsetzungsaufwand der zu entfernenden Anforderungen ist identisch mit dem der hinzuzufügenden Anforderungen.

Auf dieser vereinfachten Auffassung von Sutherlands Change for Free basieren auch die in dem Buch Der agile Festpreis behandelten Lösungsansätze zu den üblichen Problemen eines mehr oder weniger agilen Entwicklungsprozesses im Rahmen von Festpreisprojekten. Das Buch ist eine grosse Praxishilfe, vor allem wenn es um Vertrags- und Nachforderungsmanagement geht.

Change for Free bei YMC

Was allerdings fehlt, sind Vorgaben oder Empfehlungen für die bestmögliche Anwendung von Change for Free im Tagesgeschäft zwischen Lieferant und Kunde. Doch leider gibt es bis dato zu Change for Free keine etablierten Praktiken. Aus diesem Grund haben wir unsere eigenen Lessons Learned zu Change for Free in Form von vier Best Practices und vier Bad Practices zusammengefasst, die wir in diesem Blogartikel vorstellen möchten.

Zusätzlich haben wir alle acht Best/Bad Practices kompakt auf ein “Cheatsheet” zum Ausdrucken gepackt. Viel Spass damit! Feedback nehmen wir natürlich sehr gerne entgegen…

Legende

Practice #1 (Best Practice)

Der einfachste Fall von Change For Free: Der Kunde möchte eine neue Anforderung (auf hoher Abstraktionsebene) zum Projektumfang hinzufügen. Zusammen mit dem Lieferanten entscheidet er, welche bestehende Anforderung dafür aus dem Projektumfang entfernt wird.

Practice #2 (Best Practice)

Eine einzelne Anforderung kann auch mit mehreren Anforderungen ausgetauscht werden – solange der (summierte) Aufwand übereinstimmt.

Practice #3 (Best Practice)

Wie in Practice #1, nur handelt es sich bei den miteinander ausgetauschten Anforderungen um Anforderungen auf niedriger Abstraktionsebene mit einer gemeinsamen Anforderung auf hoher Abstraktionsebene.

Diese Practice ist besonders zu empfehlen, da der Aufwand von Anforderungen auf niedriger Abstraktionsebene mit weniger Ungewissheit als der Aufwand von Anforderungen auf hoher Abstraktionsebene schätzbar ist und der Austausch aus diesem Grund mit vermindertem Risiko einhergeht.

Ferner erleichtert eine einzige Anforderung auf hoher Abstraktionsebene den Austausch, da so nur eine Aufwandsschätzung angepasst werden muss.

Practice #4 (Bad Practice)

Dem Kunden sollte prinzipiell die Freiheit zustehen, auch eine ungeschätzte Anforderung in den Projektumfang hinzufügen zu können, die erst im Zuge des Austauschs geschätzt wird.

Hierbei sollte aber vermieden werden, dass die zu entfernende Anforderung alleinig vom Kunden bestimmt wird und/oder dass die hinzugefügte Anforderung alleinig vom Lieferanten im Nachhinein “geschätzt” wird, indem der Lieferant einfach die Aufwandsschätzung der entfernten Anforderung unverändert übernimmt.

Bei der entfernten Anforderung könnte eine technische Abhängigkeit zu einer anderen Anforderung bestehen, die nur der Lieferant erkennen kann. Und bei der Übernahme eines feststehenden Werts für den Aufwand müsste man ggf. die Anforderung ändern (z.B. vereinfachen), was wiederum nur dem Kunden zusteht.

Practice #5 (Bad Practice)

Eine Anforderung, die sich bereits in Umsetzung befindet, sollte niemals ausgetauscht werden – unabhängig davon wie weit die Umsetzung bereits fortgeschritten ist.

Wie in allen Practices ab einschliesslich Practice #3 zu erkennen ist, sind die Anforderungen auf niedriger Abstraktionsebene einer sich in Umsetzung befindlichen Anforderung auf hoher Abstraktionsebene potentiell weiterhin austauschbar, da sie in sich abgeschlossen sind.

Practice #6 (Bad Practice)

Anforderungen mit jeweils unterschiedlichem Aufwand sollten niemals miteinander ausgetauscht werden.

Ist der Aufwand der hinzuzufügenden Anforderung höher als der Aufwand der zu entfernenden Anforderung, kann nicht mehr ohne weitere Massnahmen sichergestellt werden, dass das Projekt fristgerecht umgesetzt werden kann. Zudem dürfte wohl unvermeidlich das Budget überschritten werden (zu Lasten des Lieferanten).

Auch der umgedrehte Fall ist problematisch: Ist der Aufwand der hinzuzufügenden Anforderung niedriger als der Aufwand der zu entfernenden Anforderung, so müsste dem Kunden ein Preisnachlass gewährt werden, welcher bei Fixpreisprojekten jedoch i.d.R. nicht vorgesehen ist.

Practice #7 (Best Practice)

Practice #6 kommt in abgewandelter Variante dennoch in Frage: Kunde und Lieferant ändern gemeinsam (siehe Practice #4) und zusätzlich zum Austausch der Anforderungen eine andere Anforderung, so dass die summierten Aufwände effektiv gleich bleiben.

Practice #8 (Bad Practice)

Practice #7 sollte vermieden werden, wenn die geänderte Anforderung keinen inhaltlichen Bezug zu den miteinander ausgetauschten Anforderungen hat, da der Vorgang des Austauschs zusammen mit der Änderung einer anderen Anforderung mit einer höheren Komplexität und damit mit einemhöheren Risiko einhergeht. (siehe auch Practice #3)

(This blog post is also available in English)

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *