Tote Linien - Umgang mit Deadlines

Ein Projekt hat per Definition ein Anfangs- und ein End-Datum, sonst wäre es kein Projekt. Somit hat ein Projekt mindestens eine Deadline - nämlich das End-Datum.

Warum Deadlines
Nun, Deadlines sind ein beliebtes Instrument, um ein Projekt noch weiter strukturieren zu können, beispeilsweise mit Zwischendeadlines:

• Zu jedem Milestone
• Ende einer Projektphase
• Ende eines Arbeitspaketes
• Ende eines Tages
• etc.

Der Vorteil ist, dass dadurch eine gewisse Verbindlichkeit im Projekt geschaffen wird und es können Verantwortlichkeiten festgelegt werden.

Doch es gibt auch einiges zu beachten:

• Zu viele Deadlines erzeugen unnötigen Druck beim Projektteam oder beim Kunden
• Deadlines können zu unnötigen Prozessen führen (z.B. Schriftliche Abnahme beim Erreichen eines Meilensteins).
• Zu viele Deadlines können nicht eingehalten werden. Es entsteht ein „Laisser fair“ Feeling im Projekt und keiner hält sich mehr an Termine oder Abmachungen. Hier gilt "weniger ist mehr".
• Deadlines werden am Anfang des Projektes festgelegt und nicht adhoc mitgeteilt.
• Eine der wichtigsten Deadlines ist in der Regel der Endtermin, der sollte eingehalten werden. Sollte es sich während des Projektes herausstellen, dass der Endtermin nicht eingehalten werden kann, so muss der PL frühzeitig reagieren.

Dealines sind für ein Projekt eine Voraussetzung - und dürfen auf keinem Fall als "tote Linie" interpretiert werden. Jedoch sollten die "Termine" mit Bedacht gewählt werden und jeweils transparent aufgezeigt werden. Es nützt nichts, wenn ich am Mittag sage: „bis heute Abend muss das fertig sein“. Hier erzeuge ich nur unnötig Druck und die betroffene Person hat gar keine Möglichkeit, sich darauf einzustellen. Vielmehr ist das eine Aussage "in der Not" weil das Projekt nicht mehr vorwärts geht. Hier sollte man die Ursache lieber wo anders suchen.

Die Bugs sind keine Bugs - aber was dann?

IT Projekte sind immer wieder eine Herausforderung, vor allem auch in der Rolle als Dienstleister. In diesem Beitrag wird das Testen auf Kundenseite beleuchtet.

Bevor ein System auf dem Testsystem beim Kunden installiert wird, wird dies intern getestet, je nach Kundenanforderung sehr ausführlich. Dennoch sollte der Kunde, um das System schlussendlich abnehmen zu können, ebenfalls testen. Das steht idealerweise auch im Angebot, im Projektplan und allen weiteren Dokumenten und man hat ein entsprechendes Bug-Tracking-System im Einsatz. 

Nun beginnt der Kunde also zu testen. Und erfasst Issues. Tatsächlich sind  es aber keine Bugs, sondern Issues:

• Der Kunde weiss oftmals nicht, wie das System zu bedienen ist und glaubt, ein bestimmtes Verhalten des Systems sei ein Bug - richtigerweise ist es aber ein Bedienungssfehler.
• Der Kunde bedient mit dem Beginn des Testens zum ersten Mal das System. Zuvor hat er sich beispielsweise in einer Präsentation eines Zwischenreleases den Status zeigen lassen oder er hat nur Screenshots vom Design/oder Wireframes gesehen. Immer wieder erhalte ich dann Issues wie „Der Schriftzug ist zu dominat, wir hätten ihn gerne etwas kleiner“ oder „Können Sie diese Buttons blau einfärben?“.

Solche Issues sind in der Regel aus Sicht des Projektteams kein Fehlverhalten des Systems. Entweder wurde es nicht bis ins letzte Detail spezifiziert oder man sieht, dass beispielsweise das Design mit „realen Inhalten“ doch nicht so ganz passt. Hier einige Tipps, wie mit einer solchen Situation umgegangen werden kann:

• Schulung VOR Testbeginn planen und durchführen: Damit hat der Kunde beim Testen bereits das KnowHow wie das System zu bedienen ist
• Design-Issues mit dem Kunden besprechen. Hier helfen die Designvorlagen, der Styleguide und die Browser, auf die optimiert werden soll. Sind es tatsächlich Fehler, so sollen diese behoben werden. Sind es Wünsche so können diese als Change Requests aufgenommen werden. Ist es nirgends definiert, so muss mit dem Kunden eine Lösung gefunden werden (z.B. Kostenteilung etc.)
• Bei grosser Unsicherheit: Testunterstützung beim Kunden vor Ort anbieten und die Testpersonen beim Testen begleiten. Bedinungsfehler können direkt angeschaut und eliminiert werden.
• Gemeinsame Definition von Bugs: Was soll der Kunde im Bugtracking System erfassen? Wie wird ein Fehler beschrieben. Allenfalls einige Beispiele von guten Fehlerbeschreibungen zeigen.
• Transparente Kommunikation während der Testphase: Aufzeigen, wie ein Issue eingeschätzt wird, gemeinsam mit dem Kunden definieren, wann was korrigiert wird und wann ein neuer Release/Patch geliefert wird. Hier helfen z.B. Testpläne, Releasepläne, wöchentliche Meetings oder wenn notwendig sogar tägliche Telkos
• Ressourcen und Puffer (Kosten, Zeit) für Fehlerbehebungen einplanen

Ich habe bereits die Erfahrung gemacht, dass es oftmals mehr Designissues gibt als funktionale Fehler. Für den Kunden sind diese auch oft schwerwiegender. Verständnis seitens Projektleiter gegenüber dem Kunden aber auch gegenüber des Projektteams ist entscheidend in dieser Phase. So kann der Projektleiter sicherstellen, dass das Projekt auch in der "letzten" Phase vor Going Live auf Kurs bleibt.

Der Schwarze Peter

Niemand will es offen zugeben, aber eigentlich wäre der Schwarze Peter  ein willkommenes Teammitglied. Es wird vieles einfacher, wenn der Schwarze Peter mit an Board ist: Man kann ihm alle Schuld zuweisen. Und das schönste ist, er reagiert nicht darauf, was vieles einfacher macht.

In jedem Projekt tauchen Probleme auf und natürlich wird auch immer fleissig nach der Ursache geforscht, was auch seine Vorteile haben kann. Aber es kippt sehr schnell in die Schuldzuweisung. Plötzlich muss ein Name her, Fragen wie „wer hat das so entschieden?“ oder „wer hat das gemacht?“ werden aufgeworfen und man sucht nach einer Antwort. Meistens ist das Team mehr damit beschäftigt herauszufinden, wer es war, als nach einer Lösung zu suchen. Warum das so ist, liegt auf der Hand: Lösungen erarbeiten können sich als sehr komplex erweisen, sind anstrengend und bedeuten Aufwand. Aber man weiss sehr schnell wie es zu der Situation gekommen ist und wer dafür verantwortlich ist, und meistens soll dann gleich auch der Verantwortliche eine Lösung erarbeiten. Sehr einfach und leider oft die traurige Realität.

Je nach Erfahrung des Projektleiters lässt er solche Situationen zu, oder er kann dem entgegen wirken. Aber vielleicht ist es wirklich gar nicht verkehrt, einen imaginären Schwarzen Peter im Team zu haben. Bei Problemen ist die Frage, wer es war, sehr schnell beantwortet: der Schwarze Peter. Damit gibt es keinen Grund sich noch weiter mit dieser Frage zu beschäftigen, sondern man kann gleich zur Lösunsgserarbeitung übergehen.

Schlussendlich steckt hinter einem Projekt ein Team, das gemeinsam auf ein Ziel arbeitet. Natürlich macht jedes Team Fehler und muss dann mit den Konsequenzen leben. Das passiert nun mal und damit muss das Team umgehen können. In einem funktionierenden Team soll eine Feedback-Kultur gelebt werden, auch Kritik soll zugelassen sein. Aber Schuldzuweisung wenn ein Problem auftaucht, ist aus meiner Sicht kontraproduktiv. Diese soll ganz schnell auf den imaginären Schwarzen Peter abgeschoben werden.

Der War-Room (oder ein Projekt im Ausnahmezustand)

An allen Ecken und Enden brennt es:

• Der Kunde beklagt sich über die schlechte Qualität der gelieferten Software
• Die Entwickler beklagen sich über das zu implementierende Produkt
• Der Produkthersteller gibt dauernd Updates heraus und nach deren Installation läuft die Anwendung nicht mehr korrekt
• Es tauchen immer wieder neue Fehler auf
• Der Projektleiter ist am Ende mit seinem Latein
• Alle sind demotiviert
• Das Projekt kommt nicht vorwärts

Solche Projektsituationen gibt es tatsächlich und sind natürlich für alle Beteiligten ziemlich unschön. Eine Möglichkeit, das Projekt aus dem „Sumpf“ zu ziehen ist der War-Room.
Das Projektteam zieht sich einige Tage zurück und arbeitet in einem Raum am Projekt. Gleichzeitig wird das Team mit Experten angereichert, die zusammen mit dem Team mögliche Lösungszenarien ausarbeiten und gleich auch umsetzen. Im War-Room arbeiten alle am selben Projekt und alle auf das selbe Ziel hinzu.

Was ist dabei zu beachten:

• Definition welche Leute anwesend sein müssen und etwas bewirken können: auch den Kunden mit einbeziehen (er könnte z.B. als Tester mit im War-Room sitzen und wertvollen Input hinsichtlich Qualität/Fehler etc. liefern.)
• Klare Rollendefinition bevor die War-Room Zeit startet: Möglicherweise übernimmt vorübergehend ein erfahrener Experte den technischen Lead oder das Projektmanagement
• Klare Spielregeln: Arbeitszeiten, Mittagspausen etc. müssen festgelegt werden
• Tägliche Briefings- und Debriefings
• Zieldefinition: Was soll nach dem War-Room erreicht sein? Ziel muss es nicht sein, dass das Projekt abgeschlossen wurde, sondern dass die Probleme, welche das Team hindert das Projekt abzuschliessen, aus dem Weg geräumt sind.
• Dauer des War-Rooms zu Beginn festlegen: Eine War-Room Zeit ist für alle Beteiligten ziemlich anstrengend. Deshalb sollte eine War-Room-Situation nicht allzu lange auftreten und vor allem niemals zur „Normalsituation“ werden.
• Die Zeit nach dem War-Room festlegen: Nach einer gewissen Zeit muss das Projekt wieder in seine gewohnten Bahnen gelenkt werden. Die Experten ziehen sich zurück und das Projektteam übernimmt die Aufgaben wieder. Das soll schon zu Beginn zusammen mit dem War-Room Team geplant werden, insbesondere auch um allfällige Unsicherheiten zu eliminieren.

Fazit:
War Room Situationen können helfen, ein Projekt wieder auf Kurs zu bringen. Ich habe damit bis jetzt positive Erfahrung gemacht. Dennoch gibt es auch einige Nachteile, die man beachten sollte: Durch einen War-Room (und durch die Experten) kann das bestehende Projektteam eingeschüchtert werden und damit verliert es das Selbstvertrauen, das Projekt ohne Hilfe zu Ende zu bringen. Das könnte einem Projekt noch mehr schaden. Innerhalb des War-Rooms können schnell Konflikte auftreten: Experten kritisieren, man sucht den Schuldigen etc. Das ist natürlich kontraproduktiv. Kritik gehört nicht in einen War-Room sondern zum Projektabschluss.

Welcher Projektleiter ist der Beste?

Kürzlich habe ich über verschiedene Projektleitertypen geschrieben. In diesem Post möchte ich nun ein übergreifendes Fazit ziehen.

Ich glaube, dass mit allen beschriebenen Projektleiter-Profilen ein Projekt erfolgreich geleitet werden kann. Und zwar weil ich bis jetzt eine wichtige Dimension noch nicht genannt habe: Der Charakter des einzelnen Projektleiters!

Wenn sich der Projektleiter egal zu welchem Typus (IT-Experte, fachfremder Projektleiter, Berater und Projektleiter) er am ehesten passt, sich seinen Schwächen bewusst ist, kann er das Projekt dennoch erflogreich leiten. Nämlich genau mit der Erkenntnis, an seinen Schwächen zu arbeiten und sich Hilfe zu holen, wo es notwendig ist. 

Offenheit, Transparenz gegenüber dem Auftraggeber und dem Projektteam, Ehrlichkeit und ein hohes Mass an Sozialkompetenz gehören heute zu den fast wichtigeren Erfolgsfaktoren als Methodik oder Expertenwissen. Wer sich dessen bewusst ist und diese "Charakterzüge" in einem Projekt geziehlt einsetzt, hat sicherlich Erfolg in seinen Projekten.

Sich zu Beginn des Projektes die Risiken, welche die Situation mit sich bringen könnte offen zu legen, sich das Projektteam genau anzuschauen und sicher zu stellen, dass die richtigen Leute an Bord sind (allenfalls mit Unterstützung eines Coaches) und den Auftraggeber in die Entscheidungen mit einzubeziehen, sind eine wichtige Grundlage für die Wahl des "richtigen" Projektes (oder des richtigen Projektleiters). 

Auch die Erfahrung eines Projektleiters in den Bereichen Fachwissen und Projektmanagement-Wissen deuten darauf hin, ob diejenige Person in der Lage ist, ein bestimmtes Projekt zu leiten.

In der Praxis ist es leider oftmals nicht der Fall, dass der Projektleiter sein Projekt oder der Auftraggeber sein Projektleiter selbst wählen darf. Man wird einem Projekt "zugewiesen". In solchen Situationen ist die Transparenz und Offenheit umso wichtiger.

Teil 3: Der Projektleiter als Experte und Projektmanager

Diese Projektleiter sind vermutlich die Besten! Sie sind Experten im Fachgebiet in denen sie die Projekte leiten und haben ein exzellentes Projektmanagement Knowhow. Sie fungieren damit dem Auftraggeber gegenüber einerseits als Berater, da sie fachliches Beurteilungsvermögen besitzen, andererseits wissen sie aber auch, wie ein Projekt geleitet werden soll und haben Termine, Risiken, Kosten und Scope fest im Griff. 

Sie verfügen über folgendes Wissensprofil:

Der klassische Projektverlauf

Das Projekt verläuft gut, Risiken werden früh erkannt und der Projektleiter steuert das Projekt so, dass es sich immer in den vorgegebenen Zieldimensionen (Termine, Kosten, Leistung) bewegt. Gegenüber dem Auftraggeber kann der Projektleiter kompetente Auskunft auch über inhaltliche Themen geben und weiss somit noch besser, wie es um das Projekt steht. Das Projekt wird ohne grösseren Zwischenfälle abgeschlossen, da sich der Projektleiter in seiner Aufgabe zu 100% sicher gefühlt hat.

Doch am Schluss hat das Projekt die Ziele (Kosten, Termine, Leistung) erreicht, aber es stellt sich die wichtige Frage, ob der Kunde auch tatsächlich zufrieden ist mit dem Ergebnis? Der Projektleiter hat zwar alles gegeben, um das Projekt erfolgreich zu leiten und konnte durch sein Fachwissen mögliche Hindernisse sofort aus dem Weg räumen. Damit läuft er aber Gefahr, alles zu perfekt zu machen. Hindernisse können nämlich auch neue Wege eröffnen. Und der Auftraggeber möchte diese Wege vielleicht sogar gehen, auch wenn es eine Abänderung der vereinbarten Ziele mit sich bringt.

Fazit:

In einem Projekt treten ständig Änderungen auf, diese können ab und zu auch einen grossen Mehrwert mit sich bringen. Der PL beurteilt aber dann eine Situation schnell zu Gunsten des Projektes, ohne den Auftraggeber über die mögliche Innovation überhaupt informiert zu haben. Das kann zur Folge haben, dass das wichtigste Projektziel, die Kundenzufriedenheit, nicht erreicht wird.

Vor allem in Konzeptionsprojekten kann eine solche Situation auftreten. Oftmals konzipiert man im Rahmen der bereits vereinbarten (Kosten) Ziele. Innovative Ideen, die Mehrkosten und Terminänderungen mit sich ziehen werden leider oftmals nicht weiterverfolgt, obwohl diese vielleicht zur grösseren Kundenzufriedenheit beigetragen hätten, als das Einhalten von Kosten, Termine und Leistung. 

Teil 2: Der fachfremde Projektleiter

Es gibt sie, die perfekten Projektmanager! Davon bin ich überzeugt, ich kenne sogar einige. Sie können ein Projekt (egal welcher Komplexität) leiten und managen. Diese Projektleiter tun eigentlich nichts anderes als Projekte zu leiten. Sie haben grosse Erfahrung, verschiedene Projekte gesehen und sind beihnahe schon "Projektgurus".
Der fachfremde Projektleiter weist folgendes Wissensprofil auf:

Doch diese Projektleiter haben einen Mangel - sie haben kein fachspezifisches Knowhow. Sie haben (in unserem Fall) keine Ahnung, wie ein Webprojekt abläuft und was ein solches Projekt beinhaltet.


Der klassische Projektverlauf:
Das Projekt wird sauber geplant und aufgesetzt und der Start verläuft eigentlich ganz gut. Jedoch treten öfters unvorhergesehene Ereignisse auf, auf die der Projektleiter nicht vorbereitet war. In seiner Professionalität weiss der Projektleiter aber wie mit solchen Situationen umgegangen wird, er kann immer wieder das Team neu motivieren und das Projekt "gerade" noch vor dem Ruin retten. Am Schluss kann er ein ansehlicher Abschluss, ein  motiviertes Team und einigermassen vernüftige Zahlen vorlegen - und er ist um eine Projekterfahrung reicher und weiss, aus seinen Fehlern im nächsten Projekt zu lernen.

Fazit:
Die fachfremden Projektleiter können Projekte leiten, sie behaupten vermutlich sogar, dass es egal ist, in welcher Branche und wie gross das Projekt ist. Sie wissen, dass, wenn sie ein fachfremdes Projekt leiten, ein umso stärkeres Team haben müssen, damit das Projekt zum Erfolg wird. Die Projektleiter "wappnen" sich für das Projekt mit erfahrenen Experten und steuern das Projekt nur. Das ist eigentlich ganz gut, jedoch muss der PL aufpassen, dass er keine "Marionette" seiner Experten wird. Wenn er sich immer auf die Meinungen von anderen stützen muss, ist er womöglich nicht in der Lage, die richtigen Entscheidungen zu treffen. Sich in alle Details einzuarbeiten und sich das Wissen anzueignen bevor eine Entscheidung getroffen wird, wäre  der richtige Weg jedoch fehlt oftmals die Zeit dafür. So verlässt man sich auf die Experten. Haben die aber noch weitere Interessen, die dem Projekt womöglich schaden können, kann das ziemlich fatal ausgehen. Der PL muss seinen Experten vertrauen und das darf von diesen nicht ausgenutzt werden.
Meine zweite These: Ein fachfremder erfahrener Projektleiter kann mit dem richtigen Team ein Webprojekt durchführen, wobei eine starke Vertrauensbasis zwischen Team und Projektleitung vorhanden sein muss.

Teil 1: Der Projektleiter als IT Experte

Oftmals werden aus der Situation heraus Projektleiter ernannt. Meistens gibt es ein Projekt, bei dem „noch schnell ein PL her muss“. Der Teamleiter ernennt ein IT Experten zum Projektleiter. Er kennt die Materie gut und die Risiken können somit minimiert werden. Der IT Experte hat folgendes grobes Wissensprofil:

Der klassische Projektverlauf:

Der IT Experte legt einen überzeugenden inhaltlichen Projektstart hin: Es liegt eine excellente Spezifkiation vor, ein technisches Konzept, eine überzeugende Architektur. Eigentlich eine ideale Grundlage für ein Implementierungsprojekt. Nun beginnt es aber schwierig zu werden: Der Auftraggeber hat immer neue Anforderungen, die auch alle in der Spezifikation ergänzt werden. Nur hat sich der IT-Experte nie auf den Projektscope festgelegt. Es gibt keine Fortschrittskontrolle, nur einen rudimentären Projektplan… Der weitere Projektverlauf ist klar: Unzufriedenheit, Kosten nicht eingehalten, Termine nicht eingehalten – kurz: Chaos.

In der Praxis gibt es die IT Experten in der Rolle des Projektmanagers aber sehr oft. Coaching und PM Ausbildungen können den IT Experten zu einem sehr wertvollen Projektmanager machen. Wichtig ist, dass er eine Starthilfe kriegt und sich des Wissensmangels im PM Bereich bewusst ist. Leider ist das oft nicht der Fall (weshalb vielleicht auch einige IT Projekte scheitern).

Fazit:

Die Fachexperten sind enorm wichtig für die inhaltliche Definition des Projektes, doch ohne Projektmanagement-Wissen sind Projekte mit einem IT Experten als Projektleiter zum Scheitern verurteilt. Organisation, Kommunikation, Scoping etc. sind für einen Projekterfolg unabdingbar. Diese Punkte müssen von einem Projektleiter berücksichtigt und gelebt werden. Der IT Experte legt den Fokus auf das Fachliche, nicht auf das Organisatorische. Meine erste und vermutlich auch sehr "banale" These: „Projekte sollten von einem Projektleiter mit PM Wissen geleitet werden“.

Wieviel sollte der PL vom Projektinhalt verstehen?

Es gibt Leute, die behaupten, dass ein  Projektleiter unabhängig vom Projektinhalt jedes Projekt leiten kann, er muss einfach ein guter Projektmanager sein. Für den Inhalt hat der PL ja dann die Fachexperten. Andere meinen, dass ein Projekt ohne die Kenntnis über den Inhalt des Projektes nur schwer, resp. gar nicht zu managen sei. 

Den Vergleich zwischen einem Bauprojekt und einem IT Projekt möchte ich an dieser Stelle nicht machen, sondern ich möchte auf Web Projekte eingehen. Wie viel muss ein Projektleiter von Software-Entwicklung und Web verstehen um ein solches Projekt managen zu können? Aus meiner Sicht gibt es hier unterschiedliche Ansichten (die sich allenfalls auch auf andere Projektarten anwenden lassen). Damit verbunden sind gegebenenfalls auch unterschiedliche Rollen, in die der PL schlüpft:

• Teil 1: Der Projektleiter als IT Experte
• Teil 2: Der fachfremde Projektleiter
• Teil 3: Der Projektleiter als Berater und Projektmanager

In den nächsten Blogeinträgen werde ich die einzelnen Ansichten genauer erläutern und zum Schluss ein übergreifendes Fazit ziehen. 

Hilfe ein Change Request

Es gibt praktisch kein Projekt, in dem es keine Changes gibt.  An und für sich ist das auch nicht schlecht, doch sollte der Projektleiter auf Changes vorbereitet sein und bei dessen Auftreten entsprechend handeln können.

Auswirkungen von Change Requests (CR)

Änderungen während eines Projektes wirken sich oft drastisch auf die Projektdurchführung aus. Insbesondere dann, wenn der Änderungsaufwand so gross ist, dass ein neues Arbeitspaket gebildet werden muss und mit in die Projektplanung einbezogen werden muss. Hier entstehen neue Teilziele (weil neues Arbeitspaket), zusätzliche Kosten und neue Termine. Dies kann zu einer Änderung des vertraglichen Liefer- und Leistungsumfanges führen.

In der Regel bringen  Änderungen eine Neukalkulation der Kosten, Termine und Risiken mit sich. Um vom Auftraggeber Mehrkosten, respektive eine Terminverschiebung zu verlangen ist eine saubere Dokumentation der Änderungen, inklusive  deren Kosten und Termine unumgänglich.

Aufwandschätzung von CR's

Es wird sehr oft unterschätzt: ein Change Request bringt auch einen grossen administrativen Aufwand mit sich. So muss der PL prüfen, ob sich der CR mit den ursprünglich vereinbarten Zielen verträgt, wo dieser im vorliegenden Projektplan eingebaut werden kann, wie die Risikoeinschätzung aussieht, ob andere Arbeitspakete dadurch "gefährdet" sind und nicht zuletzt muss der CR auch geschätzt werden.

Um eine optimale Schätzung abliefern zu können, sollte der PL untenstehende Fragen, welche er mit dem Projektteam klären sollte bereithalten:

• Wurde bei dieser Schätzung das Testing berücksichtigt?
• Wurde bei dieser Schätzung das Deployment berücksichtigt?
• Können allfällige Risiken auftreten? (Risikopauschale mit einberechnen)
• Wurde bei dieser Schätzung die zusätzlich anfallende Dokumentation und Spezifikation berücksichtigt?
• Sind die Projektleitungs- und Administrationsaufwände mit einberechnet?

Kommunikation von CRs  
Tritt ein Change Request auf, so muss dieser natürlich auch als solcher erkannt werden. Nicht selten schleichen sich CRs nämlich ins Projekt ein, ohne dass dagegen etwas unternommen wird.
Sobald aber ein CR auf dem Tisch liegt, muss dies entsprechend kommuniziert werden, beispielsweise über das Issue Tracking System oder im Weekly Report.
Dem Auftraggeber muss transparent aufgezeigt werden, welche Auswirkungen der CR in Bezug auf Kosten, Termine und weitere Arbeitspakete hat. Der CR muss anschliessend vom Auftraggeber genehmigt werden.