Vom Umgang mit Change Requests

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?

BILD: MORGUEFILE

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.

Change Requests sind in den Projektplan zu integrieren. Das Change Management ist für das Team zu planen.