We welcome change!

Einfach erklärt, geht Change Management in einem klassischen Projekt so: Kunde kauft Feature A, B, C, stellt aber nach einer gewissen Zeit fest, dass nun Feature D wichtiger ist. Der Projektleiter schlägt Alarm, da D nicht im bisherigen Projektbudget enthalten ist, grenzt ab. Er erstellt einen Change Request für D, lässt den Aufwand schätzen, der Kunde bewilligt formell und Feature D kann umgesetzt werden.

Irgendwie umständlich. Wie ich auf einen solchen Kundenwunsch reagieren möchte ist: Feature D ist nun wichtiger? Kein Problem, setzen wir um. C wird dafür nach hinten priorisiert. Mit einem derartigen Verhalten schade ich nicht der Kundenbeziehung indem ich mich abgrenzen und Diskussionen führen muss, was nun in/out of Scope ist. Und so zerstöre ich das aufgebaute Vertrauen nicht. Auch vermeide ich die beträchtlichen Aufwände der Spezifikation des Changes, den Schätzungen, Meetings und kann die Zeit in Entwicklung (also direkten Kundennutzen) investieren.

Der in der Einleitung beschriebene Umgang mit Changes ist klassisch für Fixpreis-Projekte. An sich sinnvoll, ja sogar zwingend, denn wenn man einen fixen Scope für einen fixen Preis offiert, wäre man ja dumm, neue Anforderungen (auf eigene Kosten) zuzulassen. Deshalb vermeide ich Fixpreis-Projekte wo immer möglich. Sie bringen meiner Meinung nach weder dem Kunden einen Nutzen, noch dem IT Dienstleister, der sie umsetzt. Agile Methoden wie Scrum erlauben ein konträres Verhalten. Im agilen Manifest ist sogar explizit erwähnt, dass ‹Reagieren auf Veränderung› wichtiger ist, als einem Plan zu folgen. Scrum strebt maximale Transparenz an, das äussert sich unter anderem in regelmässigen Lieferungen bei Sprintende. Diese werden angeschaut und ermöglichen neue Erkenntnisse (Changes). Diese fliessen dann als Anforderung ins Backlog ein. So kann man zyklisch auf verändernde Anforderungen am Markt, neue technische Entwicklungen oder noch wichtiger: Enduser Feedbacks reagieren und ein Produkt entwickeln, das heute relevant ist und Nutzen bringt. Und nicht ein Produkt, dass vor zwei Jahren spezifiziert wurde und nach Fertigstellung bereits veraltet und irrelevant ist.

Soweit die Theorie. In der Praxis? Kein Kunde gibt einem IT Dienstleister einfach blanko Geld für Sprints. Niemand kauft die Katze gerne im Sack. Meistens gehen Workshops voraus, um die Anforderungen grob zu verstehen, zu formulieren und diese dann in Form eines Angebots mit einem Preisschild zu versehen. Im Sinne von: Wir entwickeln dir nach Aufwand und einer agilen Projektmethodik die Applikation mit dem Funktionsumfang xy für 500k. Dadurch rückt das Thema Change Management aber wieder bedrohlich nahe, denn was würde nun passieren, wenn der Kunde 500k bezahlt hat, aber die Applikation bei Projektende nicht den im Angebot beschriebenen Funktionsumfang hätte?

Um eine derartige Situation bei Projekteende zu vermeiden, habe ich begonnen, das Thema offen bei Projektbeginn anzusprechen. Ich musste es zuerst falsch machen, um es zu lernen (Orientierunglos). Beim kürzlich durchgeführten Kick-off eines agil organisierten Projekt, habe ich aber direkt das Change Management angesprochen und anstelle des klassischen Change-Prozesses folgende Statements formuliert, als Vorschlag für die Zusammenarbeit:

• We welcome change!
• Change = Backlog Anpassung = Neupriorisierung durch Kunde
• Scope Limit = Budget. User Stories und Bugs, die nach Projekt- / Budget-Ende im Backlog verbleiben, werden nicht mehr umgesetzt, können aber Teil eines neuen Projekts bzw. einer neuen Bestellung sein.

Erwartet habe ich Diskussionen. Die effektive Reaktion darauf war aber ein Nicken und die Aussage ‘Ja, genau so muss das gemacht werden’. Grossartig! Was haben wir mit dieser Abmachung erreicht?

• Der Kunde hat die Flexibilität, auf Veränderungen zu reagieren und Anforderung nach seinen Kriterien umzupriorisieren. Er erhält das Maximum an Resultat für sein Geld; nämlich eine effiziente Entwicklung eines passenden Produkts und nicht Aufwände für Koordination, Change Request Dokumente, Meetings, Diskussionen und Bürokratie.
• Der IT Dienstleister und somit ich als Projektleiter habe die Sicherheit, dass das Budget eingehalten wird und das Team sich mit diesem Budget auf diejenigen Anforderungen fokussieren kann, die für den Kunden Priorität haben und ihn glücklich machen. Ich kann mein Budget- und Leistungscontrolling auf ein Minimum zurückfahren, was wiederum die Motivation und Zusammenarbeit des Teams fördert, da sie ihre Zeit für die beste Lösung investieren können ohne den Druck einer zeitlichen Limite.

Durch diese Entscheidung wurde das Projekt meiner Meinung nach von einer Raupe zu einem Schmetterling. Von etwa schwerfälligem, zu etwas leichtem, befreiten, schönen.

Wie lebst du Change Management in agilen Projekten?