Im Projektalltag ist es nicht einfach, den Kopf klar zu behalten. Während man die jeweilige Projektphase plant, stößt man im Lastenheft auf Unglaubliches, nicht zu Ende Gedachtes, sich Widersprechendes, aber letztendlich zu Implementierendes.
Mit dem Team und dem Kunden bespricht man das weitere Vorgehen. Und für den Kunden ist das eine Spezifikationsverfeinerung. Das Team findet das auch - irgendwie. Aber irgendwie sind sich auch alle sicher, dass die jetzt definierten Anforderungen komplexer geworden sind. Also dass sie mehr Zeit in der Feinkonzeption und der Entwicklung brauchen. Zeit für einen kostenpflichtigen Change Request. Aber wie erhält man hierzu jetzt eine Zusage?
Was ist eine Änderungsanforderung?
Ein Change Request (kurz: CR, Wikipedia) ist eine Änderungsanforderung, diese geht nach Lehrbuch vom Auftraggeber aus.
Seltenst meldet sich aber der Kunde mit: "Das ist ein CR. Mach mal das passende Angebot." Im Projektalltag gilt es, Einverständnis mit dem Kunden darüber herzustellen, mit welchen Anforderungen er eine Änderungsanforderung und mit welchen Anforderungen er eine Spezifikationsverfeinerung formuliert.
Das ist nicht immer einfach. Auftraggeber sehen nicht immer entsprechend Budgets vor. Und so wird um jeden CR erbittert verhandelt.
Erwartungsmanagement beim Auftraggeber
Bei Vertragsschluss sollte man seinen Auftraggeber darauf aufmerksam machen, dass Anforderungsänderungen üblich - und daher budgetär einzuplanen - sind. Das ist für diejenigen Auftraggeber, die selten IT-Projekte einsteuern, eine Überraschung. Seid klar und zeichnet ein realistisches Bild vom zu erwartenden Projektverlauf.
Je komplexer ein System von Beginn an ist, desto wahrscheinlicher ist es, dass es zu CRs kommen wird. Auch lange Projektzeiten erhöhen die Wahrscheinlichkeit von CRs. Konkurrenten könnten zum Beispiel während des Projekts neue Features veröffentlichen, die dann über CRs auch in Euer Projekt nachimplementiert werden müssen.
Im Prinzip bestehen jetzt zwei Möglichkeiten:
- Ihr nehmt bereits in den Vertrag ein CR-Kontingent auf. Identifzierte CRs werden genehmigt und aus dem Kontingent finanziert.
- Vorteil: Der Auftraggeber hat so die Sicherheit, dass er nicht nachträglich weiteres Budget freigeben muss.
- Nachteil: das Projektvolumen ist entsprechend höher; und für den Auftraggeber ist dieses Budget fest an Euer Projekt gebunden.
- Ihr teilt Eurem Auftraggeber entsprechend Eurer Erfahrung mit, mit welchen Aufschlägen er durch CRs rechnen muss (in % vom Projektvolumen). Ihr empfehlt, dass er eine entsprechende Summe in
seinem Budget für CRs reservieren sollte.
- Vorteil: Falls die CRs nicht abgerufen werden, hat der Auftraggeber größere Entscheidungsfreiheit in seinem eigentlichen Budget.
- Nachteil: Je enger das Budget des Auftraggebers wird, desto "härter" werden die CR-Verhandlungen ausfallen.
Während des Projekts
Das korrekte Vorgehen rund um Change Requests hängt stark von der Projektkultur desjenigen Projekts ab, in dem Ihr den Change Request aushandeln möchtet. Zwei übliche Ausprägungen werden folgend näher beleuchtet.
Transparente Projektkultur
Ihr habt gemeinsam mit Eurem Auftraggeber - Eurem Projektpartner - eine Vertragsgrundlage erarbeitet, die folgende Punkte für jedes Teilprojekt aufführt:
- Zielsetzung "was wir erreichen möchten"
- Leistungen "das tun wir"
- Abgrenzungen "das tun wir nicht"
- Aufwand "so lange werden wir brauchen - in den einzelnen Disziplinen"
Wenn nun eine Anforderungsänderung definiert oder identifiziert (!) wird, kann man sehr einfach aufzeigen, dass zum Beispiel die Zielsetzung sehr ähnlich ist, aber die Umsetzung anders ausfällt. Dann gilt es die entsprechenden Leistungen, Abgrenzungen und Aufwände neu zu definieren und zu bewerten.
Durch die Neubewertung können auch Negativaufwände auf Eurer Seite ausgewiesen werden. Diese sind dann im Sinne einer transparenten Projektkultur an den Auftraggeber "zurückzugeben". Da dieses Verfahren vereinbart ist, haben beide Projektparteien jederzeit das Recht, Änderungen in der o.g. Form abzuklopfen. Damit ist die eingangs beschriebene Situation gar nicht vorhanden. Sollte diese dennoch auftreten, ermittelt man nach dem obigen Verfahren die "neuen" Aufwände und kann sehr ruhig die CRs verhandeln.
Dennoch mag nicht jeder diesen Weg gehen. Denn das transparente Ausweisen aller Aufwände im Detail in der Verhandlungsphase öffnet einer Preis- und Aufwandsdebatte Tür und Tor. Nicht jedem ist es gegeben, diese Verhandlung positiv abzuschließen.
Stark formalisierte Projektkultur
Klassische Projekte nach Wasserfall-Methode werden oft über Lasten- (Auftraggeber) und Pflichtenhefte (Auftragnehmer) beschrieben. Der eigentliche Leistungsgegenstand des Vertrags ist im Pflichtenheft definiert. Texten aus Pflichtenheften ist eigen, dass sie oftmals eine Mischung aus fachlichen Anforderungen und technischer Umsetzung enthalten. Das mag dem Umstand geschuldet sein, dass das Pflichtenheft eine Verfeinerung des Lastenhefts darstellen, in dem der Auftraggeber seine Anforderungen definiert hat. Gerade für technisch komplexe Systeme formulieren Auftraggeber oftmals eine halb-technische Sicht, weil diese Darstellung gefühlt sehr präzise ist. Viele Auftragnehmer übernehmen diesen Duktus für ihre Pflichtenhefte.
In dieser Gemengelage ist die Aussage "aber das war doch immer klar" und die Ablehnung von zu Recht vorgetragenen Mehraufwänden sehr leicht zu finden.
Daher sind im Pflichtenheft den jeweiligen Komponenten Zielsetzungen voranzustellen. Die Darstellung der fachlichen und technischen Anforderungen sollte streng getrennt erfolgen.
Damit der Auftraggeber einen realistischen Eindruck vom Projekt und den Änderungen und Ergänzungen hat, solltet Ihr regelmäßig - auch aufwandsneutrale und aufwandsmindernde - Änderungen reporten. Auf diese Weise entwickelt der Auftraggeber ein Gefühl der Komplexität der Aufgabe. Eine aufwandserhöhende Änderung bzw. Ergänzungen, die von Euch benannt wird, sind in diesem Kontext plausibel - und die entsprechenden Change Requests sind verhandelbar.
Stolperstein: das eigene Gewissen
Bei CR-Verhandlungen steht man sich gerne selbst im Weg. Hat man in der Ursprungsbeschreibung des Projekts selbst Anforderungen nicht gesehen, ist man geneigt, die entsprechende Verfeinerung "zu schenken". Denn das schlechte Gewissen pocht. Hätte man das nicht vorher sehen können?
Rationalisierung ist hier gefragt. Vertrag ist Vertrag. Und Ihr habt eine bestimmte Leistung, die beschrieben ist, versprochen. Dafür bekommt Ihr den Aufwand gezahlt. Wenn sich jetzt der Komplexitätsgrad der Aufgabe erhöht, muss sich der zu zahlende Aufwand auch erhöhen.
Also seid nicht nur fair in der Darstellung der CRs und Verhandlung Eurem Auftraggeber gegenüber. Sondern auch Euch selbst. Mit der daraus resultierenden Haltung und dem entsprechenden Auftreten wird es Euch leicht fallen, die identifizierten Anforderungsänderungen erfolgreich als CRs in bezahlten Aufwand umzuwandeln.
Update: Change Requests sind in den Projektplan zu integrieren. Das Change Management ist für das Team zu planen.
Dieser Blog-Post ist ein privater Beitrag von Judith Andresen.
- Nächster Artikel: Projektcontrolling
- Vorheriger Artikel: PHPucEU 2012 | Veranstaltungsräume gesucht
- Kategorie: Projekt, Verhandlung
Kommentar schreiben
Johann-Peter Hartmann (Mittwoch, 21 März 2012 10:37)
Ich mag hier das Verfahren von David J Anderson (der Kanban-man), der die Summe aller Änderungen aus Wissenszugewinn rational und geplant behandelt. Er nennt das "Dark Matter", dh. Dinge von denen man weiss, dass es sie gibt, aber man kann sie selbst nicht sehen. Zur Dark Matter gehören Fehlannahmen über die externen Voraussetzungen, Probleme mit der Standardlibrary und der übersehene Locking-Aspekt in der Fußnote auf Seite 300 des Manuals der externen Lösung.
Daneben gibt es den Feature / Scope Creep, bei neue oder grundlegend andere Ausprägungen von Features eingeführt werden müssen, weil Ihr Businessvalue einfach größer ist als der vieler anderer Dinge im Projekt.
Je nach Projekt kann beides zwischen 10 und 100 Prozent liegen, und es spielt nicht nur im Budget und im Vertrag eine Rolle, sondern auch vor allem auf der Zeitlinie.
Und so löst er es:
a) Zeitlinie: Ich monitore die Dark Matter und den Scope Creep. Weil ich Kanban mache passiert das natürlich im Kummulativen Fluss - beides zusammen ergibt die Dinge, die dazukommen. Wenn ich sehe, dass ich pro Iteration 10% des Gesamtvolumens an Dark Matter erkenne, weiss ich, dass ich nach 10 Sprints vermutlich das Projektvolumen - und damit oft auch die Zeitlinie und Budget - verdoppelt habe. Wenn eins von beidem konstant ist muss ein Descoping vorgenommen werden, um aus der neuen, jetzt doppelt so grossen menge an Features die oberen 50% abzugreifen.
b) Vertrag: natürlich kennt auch klassisches Projektmanagement diese Unbekannten und Risiken, und versucht sie typischerweise mit einem expliziten oder gut verstecktem Buffer, oder alternativ über Buchhaltung (eben die Change-Request-Buchführung und Recherche über was enthalten war und was nicht) zu erschlagen - was der Kooperation nicht beiträgt. Bei Kanban wird der Risikobuffer explizit gemacht und über Erfahrungswerte nach Projektart und -größe dimensioniert. Die Buchhaltung geschieht aber nicht über Change Requests, sondern über eben oben genanntes Tracking von Dark Matter und Feature Creep - und wird pro Iteration beobachtet. Wenn man dort sieht, dass die ursprüngliche Einschätzung erheblich daneben liegt muss ohnehin wieder bilateral geklärt werden, ob man das Scoping, die Zeitlinie oder auch die Kapazität (ja, Brooks's Law) ändert.
Judith Andresen (Mittwoch, 21 März 2012 11:50)
Ja, ich stimme Dir zu - das Offenlegen von Risikobuffer hilft allen Beteiligten. (Der meinige, obige Vorschlag für Nicht-Kanban-Situationen ist das CR-Kontingent.)
Deine Art der Messung und Prognose der "dark matter" in Kanban ist interessant. Das werde ich mal ausprobieren ;-)
Christoph Luehr (Mittwoch, 21 März 2012 16:02)
Was in meinem Team gilt, gilt auch fuer den Kunden: Probleme muessen moeglichst frueh erkannt und kommuniziert werden - dann findet sich meist auch eine Loesung.
Probleme rechtzeitig sichtbar zu machen ist daher oberstes Gebot: Sei es durch "release early, release often" im technischen Bereich oder durch entsprechende Planung mit Metriken und iterativer Ueberpruefung dieser.
Fallstricke koennen sich ergeben, wenn bestimmte Problembereiche erst spaet im Entwicklungsprozess auftauchen ("oh, auf dem iPad haben wir das nie ausprobiert") - das ist allerdings generell schwierig. Es hilft da, entsprechend Scrum User Stories mit hohem Risiko und grosser Komplexitaet frueh in den Prozess einzutakten (aber auch hier kann es selbst mit Planning Poker zu Fehleinschaetzungen seitens des Teams kommen).
Wir empfehlen Kunden, die Komplexitaet und damit das Risiko von Projekten gleich von Anfang zu reduzieren und das Projektbudget lieber in Phasen/Milestones/Projektteile aufzusplitten. Damit einhergehend kann man insbesondere CRs auch in die jeweils naechste Phase schieben und entsprechend kalkulieren.