Change it.

Ein Change Request (oder – old-fashioned – nach GPM: die Änderungsanforderung) bietet immer wieder Diskussionsstoff zwischen Kunde und Dienstleister. Meist angespannte Diskussionen, wie etwa: „Das muss doch in einem Standard Web Auftritt so wie ich ihn hier beauftragt habe enthalten sein.“ „Ja, aber das ist hier nicht spezifiziert.“ „Mir egal, da sind wir uns doch wohl einig, dass das im üblichen Auftritt enthalten ist und keinen Aufpreis bedeuten kann.“

Diese Diskussion ist für beide Seiten unnötig anstrengend. Also muss man daran arbeiten. Was fällt einem dazu sofort ein: klare Linie im Anforderungsheft, Abgrenzungen schriftlicher Natur ohne Ende, präzise gedrechselte Flow Charts, Disclaimer bis selbst der Hausjurist nicht mehr weiß, was eigentlich der Auftrag überhaupt enthält. Diese Strategie enthält viel Gewinnerpotential auf Dienstleisterseite, ist aber im Vorfeld eines Projekts ein Zeitfresser. Und es lässt sich nicht alles abgrenzen und unendlich präzise beschreiben.

Andere Strategie wäre die agile Methode, die näher am Kunden arbeitet und somit eine deutlich höhere Zufriedenheit im Projektverlauf bietet, da hier mehr Einfluss auf die Prioritäten seitens Kunden genommen wird.

Am Ende müssen sich aber beide Seiten doch wieder in die Augen schauen und sagen: Projektende, Abnahme, Schlussrechung, Punkt, aus, Beginn Tagesbetrieb, ab hier Changes, neue Anforderungen. Mist. Man kommt an den Dingern nicht vorbei.

Da wäre doch ein Umdenken toll, anstelle sich über Changes zu ärgern, einfach das Konstrukt als notwendig-sinnvolle Weiterentwicklung aufzufassen, die beiden Seiten etwas einbringt (win-win). Dem Kunden, die Änderung, das neue Feature, die entscheidende (umsatzbringende) Drehung am Auftritt und dem Dienstleister den Spaß an der Weiterentwicklung, dem noch feineren Customizing und Umsatz.

In diesem Sinne: Love it. Change it.