Das letzte Instrument, das wir vorstellen möchten, ist der Change Request (CR). Dass es zu Änderungen im Projekt kommt, ist vollkommen normal. Am Anfang eines Projektes sind die Arbeitsergebnisse nur zu ca. 80 % bekannt. Insofern müssen 20 % des Budgets als Reserve eingeplant werden. Dabei ist die Regel, dass das Risikomanagement ca. 15 % ausmacht und die Managementreserve 5 %. Wenn das Budget bei Projektstart zu 100 % verplant ist, kann es nicht gehalten werden. In diesem Fall kann der Projektleiter nur Schadensbegrenzung durchführen. Der Prozess, der dann hilft, ist das Change Management.
Jedoch erfordert ein gutes CR-Management zwei Voraussetzungen: Eine gute Projektkonfiguration mit allen Liefer- und Leistungsgegenständen und ein kompetentes CCB – Change Control Board.
Change Request Management erleichtert Planung
Ich selbst habe die positive Wirkung von einem guten CR-Management erlebt. Als ich in dem Projekt CFMU – Central Flow Management Unit, für die Dienststelle, die europaweit die Startzeiten im Flugverkehr berechnet, tätig war, arbeitete ich auf der Betriebsseite. Und wie es als Anwender ist, hatten wir auch täglich gute Ideen. Das Problem mit den Ideen war, dass wir dadurch die Betriebsaufnahme verzögerten. Also beschloss das Programm-Management mit einem formellen CR-Management zu beginnen. Eines Tages ging ich zu meinem Freund Pascal, einem guten Programmierer, und präsentierte ihm eine gute Idee. Und was machte er? Er weigerte sich, die Idee ohne CR umzusetzen! Ich fragte ihn: "Bist du nicht mehr mein Freund?". Er antwortete: "Doch. Jedoch ohne CR bekommen wir Ärger." Was sich im Nachgang herausstellte war, dass unsere guten Ideen manchmal weniger gut waren und die Software-Entwicklung die Änderungen besser planen konnte. Seitdem bin ich ein überzeugter Fan von einem guten CR-Management
Eine gute Projektkonfiguration bekomme ich nur, wenn ich eine gute Planung habe. Und da beißt sich die Katze häufiger in den Schwanz. Ohne eine professionelle Projektplanung wird es nur einen butterweichen Projekt-Scope (Liefer- und Leistungsumfang) geben. Deshalb leiden Projekte häufig unter dem, was im englischen Scope Creep heißt: Der schleichenden, unbemerkten Leistungserweiterung ohne eine Anpassung der Termine und des Budgets. Wenn das Projekt professionell geplant ist, einen klaren Projektauftrag hat, eine saubere Beschreibung der Projektziele und der Abnahmekriterien, daraus einen Projektstrukturplan abgeleitet hat mit vollständigen Arbeitspaketbeschreibungen, die wiederum die Liefergegenstände beschreiben, dann ist ein effizientes CR-Management möglich. Die Liefergegenstände aus den Arbeitspaketen bilden dann die Konfiguration.
Viele Projekte haben nur den Scope im CR-Management. Die anderen Eckpunkte des Projektes werden ohne CRs gemanaged, z. B.: Termine werden ohne einen CR verschoben. Das ist nachteilig, weil der Auftrag an den Projektleiter heißt: Liefere das Projektergebnis innerhalb der Termine und des Budgets ab. Deshalb gehören zu einem CR-Management auch die Termine und das Budget dazu.
Die zweite Voraussetzung, ein kompetentes CCB, ist genauso wichtig. Hier geht es häufig um technische Entscheidungen und weniger um Business-Entscheidungen. In einem CCB diskutieren Experten Lösungen. Fachwissen ist gefordert. Ein politisch motiviert besetztes CCD ist eher ein Nachteil für das Projekt.
Abhängig von der Komplexität des Projektes kann es verschiedene CCBs geben. Wichtig ist, dass der CR-Prozess definiert ist. Es ist ein standardisierter Prozess, mit klaren Entscheidungspunkten. Das CCB trifft sich abhängig vom Projekt einmal im Monat oder einmal pro Woche. Jeder CR wird bewertet, ob die Änderung hilfreich ist, welche Auswirkungen sie auf die Termine und das Budget sowie welche Risiken mit der Änderung verbunden sind. Anschließend werden die CRs in dem nächsten Statusbericht den Auftraggebern zur Entscheidung vorgelegt. Das heißt, für jeden CR sollte das CCB drei alternative Lösungen vorschlagen. Auftraggeber wollen entscheiden, jedoch keine Probleme durchdenken.
Genehmigte CRs werden in die Projektplanung integriert und erzeugen eine neue Baseline, gegen die das Projekt dann gesteuert wird. Von daher sollte der PL das Meeting moderieren, damit er oder sie weiß, was diskutiert wurde. und wo die Risiken liegen und wie er die Auftraggeber informieren kann.
Auch wenn man agiles Projektmanagement betreibt, sind diese Werkzeuge anzuwenden. Letztendlich geht es immer darum Arbeit auf Zeit zu planen, um etwas Einmaliges zu erschaffen.
Das ist nur ein Ausschnitt aus dem Produkt Haufe Finance Office Premium. Sie wollen mehr?
Jetzt kostenlos 4 Wochen testen
Anmelden und Beitrag in meinem Produkt lesen