Change Requests – Indikator für die Schieflage?

Change Requests (Änderungsanforderungen) kommen in jedem IT-Projekt vor, das länger als eine Woche dauert. Sie beeinflussen die wesentlichen Risikofaktoren eines Projekts wie Funktionalität/Leistungsumfang, Termine, Kosten und Mitwirkungsleistungen. Ein schlecht gemangter Umgang mit diesen Änderungen gefährdet das Projekt und ist daher ein wesentlicher Indikator für den Projektzustand (zum Artikel Projektstatus geht es hier: <Link IT-Projekte>).

Erfahren Sie in den nächsten Abschnitten,

  • warum sich Change Requests nicht vermeiden lassen,
  • wie sich Change Requests von Moving Targets unterscheiden,
  • welche Arten von Change Requests in IT-Projekten mit ihren Auswirkungen zu unterscheiden sind,
  • wie Sie ein richtiges Management von Change Requests einrichten können und
  • wie Sie die Gesundheit der Change Requests anhand einer Checkliste prüfen und geeignete Gegenmaßnahmen einleiten können.

Voraussetzung für einen Change Request ist das Vorliegen eines vereinbarten Leistungsumfanges. Ein typisches Beispiel ist ein Auftraggeber-Auftragnehmer-Verhältnis mit einer Vereinbarung, zu einem bestimmten Preis einen definierten Leistungsumfang zu liefern. Keine Change Requests gibt es in Projekten, bei denen der Auftraggeber keine Vorstellungen oder Erwartungen über den zu liefernden Leistungsumfang hat, da es in diesem Fall auch keine Abweichungen davon geben kann. In diesen Fällen existiert kein Kriteriengerüst zur Beurteilung des Projekterfolgs. Eine Änderungsanforderung setzt somit voraus, dass es eine Definition mit einem Leistungsumfang gibt, von dem abgewichen werden soll. Ein angenommener (vereinbarter) Change Request ergänzt somit die vertraglichen Vereinbarungen der Projektpartner zum Leistungsumfang (mit Kosten, Terminen, Mitwirkungsleistungen und weiteren Einzelheiten).

Auch der Umkehrschluss ist zulässig: Projekte ohne Change Requests deuten entweder darauf hin, dass die zu erreichenden Projektziele nicht ausreichend spezifiziert sind oder kein bestimmbarer Leistungsumfang vereinbart wurde.

1.                       Warum lassen sich Change Requests nicht vermeiden?

Je länger ein Projekt dauert, desto häufiger kommen Change Requests aus den Fachbereichen auf, deren Arbeit mit IT-Lösungen abgebildet oder unterstützt werden soll. Ich habe oft den Eindruck, dass schon ein reflektierter Umgang mit Prozessen – wie bspw. in der Testphase einer neuen Software – zur kritischen Betrachtung von Abläufen und Schaffung neuer funktionaler Begehrlichkeiten führt. Hinzu kommen neue Anforderungen aus unterschiedlichen Quellen – seien es Gesetzesänderungen, eine weitergehende Erschließung von Geschäftsfeldern oder eine neue Priorisierung von Anforderungen – sie alle führen zu Änderungen am ursprünglich vorgesehenen Leistungsumfang.

Daneben können sich bei der Projektarbeit auch Kenntnisse über Verbesserungsmöglichkeiten und Optimierungen ergeben. Ferner treten in späteren Projektphasen nicht selten Fehler auf, deren Ursachen in Defiziten früherer Projektphasen liegen – hierzu werde ich einen gesonderten Beitrag über Projektphasen, die Entdeckung von Fehlern und die damit verbundenen Beseitigungskosten erstellen.

2.                       Change Requests und der Unterschied zu Moving Targets?

Mit der Durchführung eines Projekts sollen eins oder mehrere Ziele erreicht werden, die auch als Messlatte für den Projekterfolg dienen. Change Requests passen Lösungswege oder Umsetzungsdetails an, sie betreffen jedoch nicht die übergeordneten Projektziele. Falls es gleichwohl zu Änderungen dieser Ziele kommt, liegen sogenannte Moving Targets vor. Sie haben Einfluss auf die Projektprämissen für den Nutzen und den Erfolg des Projekts. Damit einher geht eine fehlende Controlling-Möglichkeit für den Projektfortschritt; ein Maßstab, an dem der Projekterfolg gemessen werden kann, ist nicht (mehr) vorhanden. Dabei kann es sich auch um einen schleichenden Prozess handeln, der von den am Projekt Mitwirkenden erst spät erkannt wird.

Ein Warnsignal, ob schon Moving Targets vorliegen, ist der Anteil der Change Requests am Projektvolumen, das Anpassungen, Test und Einführung umfasst, aber keine Lizenzkosten und keine Hardware. Nach meinen Erfahrungen liegt hier eine kritische Grenze bei ca. 20 %. Bei einem Überschreiten sollten die Projektbeteiligten prüfen, ob nicht die Vereinbarungen und die Komponenten der Projektsteuerung an die neuen Gegebenheiten angepasst werden müssten, damit das Projekt nicht durch das Verfolgen von Moving Targets in eine Schieflage gerät.

Für das Auftreten von Moving Targets ist die Projektmethodik von untergeordneter Bedeutung. Auch bei agilen Vorgehensweisen gibt es in der Regel zumindest eine Erwartung des Auftraggebers, was geliefert werden soll. Damit sind nicht die einzelnen Einträge in den Backlogs gemeint, sondern die Lösung einer konkreten Aufgabenstellung. Falls dieses Ziel nicht mehr erreicht werden soll, greifen Backlog-Änderungen zu kurz; in diesen Fällen empfiehlt sich ebenfalls eine Überprüfung und Nachjustierung der getroffenen Vereinbarungen.

Moving Targets erfordern somit eine Überarbeitung der gesamten Projektaufstellung, während Change Requests in der Regel nur einzelne Bereiche betreffen. Welche Arten von Change Requests gibt es also und was sind deren Auswirkungen?

3.                       Arten von Change Requests

Meist betreffen Change Requests den funktionalen Bereich oder die Standard-Ausstattung (Hardware, seltene Betriebssoftware). Es kommen jedoch auch Änderungen anderer Anforderungen in Betracht. Hierzu zählen die Verschiebung von Terminen, Modifikationen am Umfang von Mitwirkungsleistungen oder an Qualitätsanforderungen.

Im Normalfall werden folgende Hauptziele verfolgt:

  • Erweiterungen des Leistungsumfanges
  • Verbesserung und Optimierung der mit dem Projekt verfolgten Lösung
  • Fehlerbeseitigung

Bei den beiden erstgenannten Punkte bereiten die Zuordnung zusätzlich anfallender Kosten und etwaige Auswirkungen auf die Projektdauer in der Praxis wenig Probleme; das Auftraggeber-Auftragnehmer-Verhältnis mit den vertraglichen Vereinbarungen reicht hier erfahrungsgemäß aus.

Bei Fehlerbeseitigungen wird in der Sachverständigenpraxis die Frage gestellt, ob diese zum vereinbarten Leistungsumfang gehört oder gesondert zu vergüten ist. Dazu ist in vielen Fällen die Frage zu beantworten, ob die vom Auftraggeber gewünschte Leistung im Leistungsumfang enthalten ist oder nicht. Falls beispielsweise der Auftraggeber Ergänzungen des ursprünglichen Leistungsumfanges wünscht, die erst während der Projektdurchführung entdeckt werden, handelt es sich meistens um gesondert zu vergütende Zusatzanforderungen und nicht um die (angeblich) unzureichende Ausprägung eines Standards.

4.                       Richtiges Management von Change Requests

Als Zwischenergebnis halten wir fest, dass Change Requests zu lebenden Organisationen gehören und in nahezu allen IP-Projekten notwendig sind. Wie geht man nun am besten mit ihnen um? Für den Change Management-Prozess hat sich folgendes Verfahren bewährt, das als Grundschema in vielen Projektmethodiken enthalten ist:

  • Formulierung der Änderungsanforderung nach einem vorgegebenen Schema (auch auf einem Formular) mit Beschreibung der gewünschten Änderung, Folgen, erforderlichen Maßnahmen, anfordernder Person, Priorität, Datum; gegebenenfalls können hier auch die notwendigen Unterschriftsfelder für diejenigen Personen vorgesehen werden, die Change Requests beauftragen und entsprechende Vertragsänderungen abschließen können.
  • Prüfung der Anforderung: Der Auftragnehmer konzipiert eine Realisierungsmöglichkeit und prüft dabei die Auswirkungen auf das Projekt. Dies können Seiteneffekte mit Auswirkungen auf andere funktionale Bestandteile, erhöhte Hardwareanforderungen und Änderungen von Aufwänden (Kosten), Terminen, Abnahmeverfahren und Dokumentationen sein.
  • Weitergehende Untersuchungen: Bei komplexeren Änderungswünschen kann es notwendig werden, die Projektarbeit zu unterbrechen und zunächst eine detaillierte Prüfung des Änderungswunsches vorzunehmen.
  • Entscheidung des Auftragnehmers: Auf Basis der ihm zur Verfügung stehenden Ressourcen und der Gesamtsituation entscheidet der Auftragnehmer, ob er den beantragten Change Request umsetzt oder ob er die Realisierung (zunächst) ablehnt und gegebenenfalls auf eine spätere Projektphase verschiebt.
  • Entscheidung des Auftraggebers: Der Auftraggeber bestimmt, ob er ein vom Auftragnehmer vorgelegtes Angebot annimmt und die Durchführung des Change Requests beauftragt.
  • Fristen: Für eine stringente Projektorganisation empfiehlt es sich, Fristen zur Bearbeitung von Change Requests zu vereinbaren.

Falls der Auftragnehmer die Umsetzung des Change Requests ablehnt, muss am besten schon im Vertrag vereinbart worden sein, ob dies durch Zeitablauf oder durch eine explizite Erklärung erfolgt. Alternativ kann auch die Annahme durch Zeitablauf oder ausdrückliche Erklärung vereinbart werden.

Es wurde kein Alt-Text für dieses Bild angegeben.

Bei Annahme von Change Requests sind die entsprechenden Abläufe im Projekt anzupassen. Hierzu gehören beispielsweise Änderungen des Projektplans, der Abnahmespezifikationen, der Beistellungen oder Hardwaremodifikationen. Es ist sicherzustellen, dass auch die Change Requests qualitätsgesichert sind und ihre Umsetzung überwacht wird.

5.                       Checkliste und Gegenmaßahmen

Nun kennen Sie das ideale Vorgehen, aber wie erkennen Sie eine Schieflage im Kontext von Change Requests? Durch die Beantwortung einiger weniger Fragen können Sie überprüfen, ob ein Projekt Gefahr läuft, in eine Schieflage zu geraten oder ob dieses Risiko nicht besteht. Teilweise überlappen sich die Fragestellungen; der wesentliche Einflussfaktor ist, ob die Fragen schnell und einfach (beispielsweise durch Einsicht in ein Dokument) beantwortet werden können oder ob umfangreichere Sichtungs-, Analyse- oder Zusammenstellungsarbeiten notwendig sind. Wenn ich erlebe, dass Change Requests nicht nummeriert sind, keine Übersicht vorhanden ist und der Projektleiter erst Mails durchsehen muss, weiß ich, dass das Management von Change Requests allenfalls in Ansätzen eingerichtet ist und keine wirkliche Kontrolle des Leistungsumfangs und damit des Projektfortschritts etabliert ist.

Zu den einzelnen Fragen gehe ich jeweils aus der Sachverständigenpraxis auf den Hintergrund und mögliche Antworten ein.

  1. Existiert für das Projekt keine klare Zieldefinition? Eine klare Zieldefinition ist Voraussetzung für die Definition von Change Requests. Falls kein Projektziel besteht, kann kein Projekterfolg gemessen und auch kein Leistungsumfang festgelegt werden, von dem abgewichen werden soll.
  2. Gibt es ein vertraglich geregeltes Verfahren zur Abarbeitung von Change Requests?Projekte ohne Zieldefinition werden hier ausgeklammert, da sie eher ein Ausnahmefall sind. Bei allen anderen Projekten fehlt damit ein wichtiges Instrument zur Anpassung von Leistungsinhalten, da bei einer relevanten Projektdauer immer vom Aufkommen von Change Requests auszugehen ist. Wenn ein entsprechendes Verfahren nicht abgestimmt und zwischen den Projektpartnern vereinbart wurde, besteht das Risiko, dass notwendige Änderungen nicht zwischen den Projektpartnern fixiert werden. Dann macht sich das Projekt bei der Änderung von Anforderungen selbstständig und entzieht sich den Kontroll- und Überwachungsmechanismen. Eine Umgehungsmöglichkeit besteht darin, eine weitere Verhandlungs- und Vereinbarungsphase umzusetzen, wenn Änderungsanforderungen auftreten und die damit verbundene Zeitverzögerung einzuplanen.
  3. Weichen die derzeitigen Ziele von den zu Projektbeginn definierten Zielen ab? Diese Frage adressiert Moving Targets, also sich während der Projektlaufzeit verändernde Ziele, und ist daher ein Indiz für die Notwendigkeit eines Prozesses zur Abarbeitung von Change Requests. Es macht einen erheblichen Unterschied, ob eine Rheinüberquerung mit einer Brücke oder einem Tunnel realisiert wird, obwohl weiterhin die gleiche Aufgabenstellung gelöst werden soll. Es kommt daher auf die richtige Flughöhe bei der Aufstellung der (messbaren) Ziele an. Nach meinen Erlebnissen führen sich verändernde Ziele nicht selten zu einem Scheitern des gesamten Projekts.
  4. Welche Change Requests sind vom Auftragnehmer hinsichtlich der Auswirkungen für das Projekt (Zeit, Kosten, Risiken) bewertet worden? Diese Frage prüft, in welchem Umfang ein Management für die Überwachung von Change-Requests eingerichtet ist und ob der Auftragnehmer eine vollständige und realistische Bewertung des Change Requests vorgenommen hat.
  5. Welche Change Requests wurden vom Auftraggeber beantragt, welche wurden bisher nicht beauftragt, welche wurden (endgültig) abgelehnt, in welchem Umsetzungsstadium befinden sich die beauftragten Change Requests (begonnen/in Arbeit, abgeschlossen, bereitgestellt, oder freigegeben durch Auftraggeber)? Auch diesen Fragen zielen auf den Umfang und die Qualität des Managements von Change Requests ab.
  6. In welchem Abarbeitungsstadium befinden sich die beauftragten Change Requests? Diese Frage adressiert, ob ein Verfahren für die Beurteilung des Projektfortschritts vorliegt. Es sollte im Idealfall auch vom Auftraggeber genutzt werden können, um den Projektfortschritt bestimmen und überwachen zu können.
  7. Übersteigt die Anzahl der Change Requests ein Volumen von rund 20 % des ursprünglichen Projektvolumens einschließlich Anpassungen, Tests und Einführung? Nach meinen Erfahrungen ist bei einem deutlichen Überschreiten dieser Grenze davon auszugehen, dass die ursprünglichen Projektannahmen in erheblichem Umfang zu überarbeiten sind. Dies betrifft nicht nur Funktionalität, Zeit und Kosten, sondern auch den Maßstab, an dem der Projekterfolg gemessen werden soll. Änderungen in diesem Umfang sind häufig problematisch, da eigentlich ein vollkommen abweichendes Projekt abzuarbeiten ist. Die Summe der Change Requests kann dazu führen, dass die (geänderten) Ziele nicht mehr erreicht werden. Eine Umgehungsmöglichkeit besteht im Neuaufsetzen des Projekts, was zwar mit einer zeitlichen Verzögerung verbunden ist, aber das Risiko massiv absenken kann. Ein weiteres Risiko sind zu lange Projektzyklen, so dass sich die Anforderungen erneut ändern können oder sich die Anwender an Umgehungslösungen gewöhnt haben und Akzeptanzprobleme resultieren können.

Im Ergebnis ist festzuhalten, dass das richtige Management von Change Requests eine zentrale Risikoquelle in IT-Projekten beherrscht und dazu beiträgt, den Projekterfolg durch die Erreichung der Projektziele zu sichern.

Dr. Siegfried Streitz