PRINCE2

1.4Die vier integrierten Bausteine von PRINCE2

Nachdem wir uns im letzten Abschnitt den Grundlagen des Projektmanagements, angehaucht mit einigen PRINCE2-Merkmalen angeschaut haben, gehen wir nun in die Methodik PRINCE2.

PRINCE2 kann man im Grunde auf vier einfache Bestandteile aufteilen: Grundprinzipien, Themen, Prozesse und Anpassung an die Projektumgebung. Jeder der vier Bausteine hat eine Daseinsberechtigung in unterschiedlicher Ausprägung. Im Folgenden gehen wir auf die einzelnen Bausteine ein, bevor diese dann Kapitel für Kapitel näher aufgearbeitet und verknüpft werden.

Die 7 Grundprinzipien: Die Grundprinzipien kann man festen Leitsätzen gleichsetzen. Nach der PRINCE2-Terminologie ist jedes der sieben bestehenden Grundprinzipien zu befolgen, sollte man beabsichtigen, ein PRINCE2-Projekt zu initiieren und zu managen. Den 7 Grundprinzipien schenkt dAbschnitt 1.5 noch gesonderte Aufmerksamkeit.

Die 7 Themen: Die 7 Themen beschreiben den Inhalt von PRINCE2 bzw. den Inhalt einer richtigen Projektstruktur. Zum Beispiel: Wie man eine richtige Projektorganisation erstellt oder wie Reportingstrukturen auszusehen haben.

Die 7 Prozesse: Die 7 Prozesse stellen die Ablaufbeschreibung um die 7 Themen herum dar: Wann wer was im Projekt erstellt bzw. durchführt.

Anpassung an die Projektumgebung: Die Anpassung an die Projektumgebung ist in der PRINCE2-Terminologie nicht allzu umfangreich beschrieben, stellt in der Praxis jedoch das größte Thema eines Projektmanagers in Verwendung von PRINCE2 dar. Das liegt daran, dass dieser Baustein die PRINCE2-Terminologie vollkommen anpassbar und auf sämtliche Projekte adaptierbar macht.

1.5Die 7 Grundprinzipien

Wie in Abschnitt 1.4 beschrieben, sind die Grundprinzipien wichtige Leitsätze, die in PRINCE2 vorherrschen; Leitsätze, die sich aus rund 30 Jahren richtig gutem Projektmanagement ergeben haben. Viele davon wird man im Rahmen seiner eigenen Projekterfahrung als bekannt und bewährt einstufen. Andere bringen interessante, neue Ansätze mit sich. Wer sich im agilen Projektmanagement wie SCRUM oder Kanban bereits auskennt, dem wird auffallen, dass die Grundprinzipien ihrem Zweck, dem Agilen Manifest, sehr nahe sind. Die Inhalte sind freilich unterschiedlich, der Hintergrund, nämlich das einheitliche Verständnis von Gesetzen, ist hingegen absolut gleichwertig. Die 7 Grundprinzipien sind:

Fortlaufende geschäftliche Rechtfertigung¹⁾: Dieses Grundprinzip bezieht sich auf den vom Projekt zu liefernden Nutzen oder Mehrwert. Dieser muss von Anfang an gegeben sein, um ein Projekt überhaupt zu initiieren. Ist dies der Fall, kann mit einer Umsetzung des Projekts begonnen werden. Wichtig ist hierbei, dass dieser Nutzen durch eine iterative Vorgehensweise ständig überprüft und gegebenenfalls angepasst wird. Der Nutzen stellt wie in Abschnitt 1.3 (Projektsteuerungskreislauf) beschrieben eine Projektdimension dar, die der Projektmanager dauerhaft managen muss. Die geschäftliche Rechtfertigung muss der Projektmanager der PRINCE2-Methodik nach in einem Dokument festhalten, welches durch dauerhafte Anpassung sozusagen „lebt“. Dieses Dokument wird als Business Case beschrieben. Hierzu wird es im Folgenden sogar noch ein eigens zu behandelndes Thema geben.

Bei der Olympiade ist der Nutzen natürlich sehr einfach und umfangreich zu beschreiben. Hier sind es die bereits genannten neuen Arbeitsplätze, die aufgrund von Tourismus in der Stadt entstehen; nicht zu verachten sind die umfangreichen Einnahmen, die die Londoner Geschäfte zu verzeichnen haben sowie etwaige nichtmonetäre Prestigeeffekte für die Stadt.

Lernen aus Erfahrung²⁾: Dieses Grundprinzip befasst sich im Grunde mit den Erfahrungen aus Vorgängerprojekten. Erfahrung muss hierbei keinesfalls negativ zu bewerten sein. Durchaus können gute Ansätze aus Vorgängerprojekten ebenfalls Anwendung finden. Im Grunde genommen ist die PRINCE2-Methodik als eine große Sammlung der besten Anwendungen aus Vorgängerprojekten nichts anderes als die Operationalisierung dieses Grundprinzips. Dieses Grundprinzip findet meist zu Beginn des Projekts eine intensive Anwendung, da in frühen Projektphasen eine enorme Unsicherheit herrscht und hier ein starkes Erfahrungsregister aus Vorgängerprojekten gute Unterstützung leisten kann.

In der Geschichte fanden bereits 100 Olympiaden statt. Da wird es doch ein Leichtes sein, auf die Erfahrung jener zurückzugreifen und die Olympischen Spiele von London hocheffizient zum Erfolg zu führen. – Das ist leider zu naiv gedacht; unterscheiden sich die Vorgängerprojekte doch stark hinsichtlich dem Geist der Zeit, Region, Kultur. Selbst wenn die Rahmenbedingungen annähernd gleichbleiben, ist hierdurch keine Erfolgsgarantie zu erwarten, nur weil man auf Erfahrungen aus Vorgängerprojekten zurückgreift. Die Chance, Wiederholungsfehler zu vermeiden ist jedoch allemal gegeben, weshalb die Chance auf einem Projekterfolg zumindest ausdrücklich steigt.

In der Praxis fällt auf, dass ein bewusstes „Lernen aus Erfahrung“, meist nur sehr halbherzig betrieben wird. Natürlich, unterbewusst haben Senior Projektmanager einen enormen Erfahrungsschatz, auf den sie zurückgreifen, auch ohne irgendwelche Lessons Learned Meetings durchzuführen. Die Erfahrung zeigt jedoch, dass regelmäßige Lessons Learned Meetings einen für den Projekterfolg positiven Effekt mit sich bringen. Hierbei ist zu beachten, dass die Betonung auf „regelmäßig“ nicht auf „nur am Ende eines Projekts“, wie es doch in den meisten Projekten gehandhabt wird, liegen muss. Ein regelmäßiges „sich zu hinterfragen“ ist im agilen Projektmanagement ein gelebter Ansatz. Auch im klassischen Projektmanagement gehört es, der Theorie zufolge (PRINCE2-Methodik) schon längt zum Tagesgeschäft.

Definierte Rollen und Verantwortlichkeiten³⁾: Wer kennt es nicht? Innerhalb eines Projekts kommt (gefühlt) aus dem Nichts eine Aufgabe auf, welche zwar bekannt war, jedoch hatte niemand dafür Sorge getragen, dass diese auch ordnungsgemäß erfüllt wurde. Grund hierfür ist, dass sich niemand dafür verantwortlich gefühlt hat. Dieser Planlosigkeit der Verantwortung wirkt die PRINCE2-Methodik stark entgegen, in dem sie klare Rollen (Projektmanager, Teammanager uvm.) vorgibt und dahinter klar deren Anforderungsprofil, deren Kompetenzen sowie Rechte und Pflichten aufzeigt.

Bei der Olympiade hat der Projektmanager all seinen Teammanagern, also den fachlichen Teilprojektleitern, genau die richtige Verantwortung delegiert. Bei Projekten dieser Größe ist es nicht möglich, dass der Projektmanager alleine die zum Beispiel Budgetverantwortung für sämtliche Teilprojekte trägt. Die Teammanager können nicht frei Budgets verteilen. Sie haben vielmehr seitens des Projektmanagers gewisse Budget-Toleranzwerte übergeben bekommen, innerhalb deren sie frei und ohne ständige Abstimmung mit dem Projektleiter interagieren können, sogar müssen.

Wichtig ist hierbei, das Grundprinzip der klaren Rollen und Verantwortlichkeiten richtig zu leben, da sonst der Teilprojektleiter und der Teammanager wegen Kleinigkeiten die Abstimmung mit dem Projektmanager suchen, da dieser keine klaren Verantwortlichkeiten für sein Projektteam vorgegeben hat.

In der harten Praxis wird das Thema „Rollen und Verantwortlichkeiten“ so gelebt, dass zwar offizielle Verantwortlichkeiten delegiert wurden, jedoch die jeweilige Hierarchiestufe trotzdem in ständiger Abstimmung mit der nächst höheren Hierarchiestufe ist. Das liegt natürlich daran, dass es Situationen gibt, die dies durchaus hergeben, zum anderen liegt es aber auch daran, dass die jeweiligen Mitarbeiter Angst haben zu entscheiden. Hier muss dann die höhere Hierarchiestufe eingreifen und dem Mitarbeiter entweder diese Angst nehmen oder den Mitarbeiter austauschen, da die Führungskraft durch eine derartige Arbeitsweise schnell in ineffizientes Mikromanagement verfällt.

Steuern über Managementphasen⁴⁾: Dass sich ein Projekt durch einen regelmäßigen und wiederkehrenden Kreislauf ausmacht, ist inzwischen klar. Dass dieser Kreislauf unter anderem über so genannte Managementphasen zu funktionieren hat, ist an der Stelle neu. Eine Managementphase stellt, in der Logik von PRINCE2, eine abgeschlossene, eigenständige Projektphase dar. Diese kann zum Beispiel „Initiierungsphase“ oder „Testphase“ heißen. Alleine der Name hinter der Managementphase gibt Aufschluss darüber, was in der jeweiligen Phase vonstattengeht. Immer am Ende einer jeweiligen Phase muss der Projektmanager an das Entscheidungskomitee, in PRINCE2 „Lenkungsausschuss“ (LA) genannt – in der Praxis aber auch oft als Steering-Komitee bezeichnet – reporten. Hierdurch wird klar, dass ein Abschluss einer Managementphase ein essentielles Ereignis innerhalb eines Projekts darstellt. Ein Ereignis, in dem der Projektmanager sich natürlich rechtfertigen muss, der Lenkungsausschuss wichtige Entscheidungen treffen muss und auch sonstige, für eine Eskalation nicht ausreichende Ereignisse, Vorkommnisse oder einfach Anliegen besprochen werden. Welche Personen bzw. Stakeholder in einem Lenkungsausschuss sitzen, wird im Thema „Organisation“ in Abschnitt 2.3 konkret beschrieben. Wie lange eine Managementphase dauert und wie viele es davon gibt, wird ebenfalls noch konkreter beim Thema „Fortschritt“ in Abschnitt 3.5 beschrieben.

Beim Projekt Olympia bietet es sich natürlich ebenfalls an, die Errichtung der Olympiade in logische Managementphasen zu unterteilen. Hier würden wir zum Beispiel eine Initiierungsphase zur Planung der Anforderungen durchführen, gefolgt von einer Planungsphase zur Strukturierung des Projekts inklusive Verteilung der Rollen und Verantwortlichkeiten. Das nur als ein paar wenige Phasen von vermutlich hunderten.

In der Praxis werden Phasen oft wenig gelebt. Das liegt zum einen an dem hohen Stresslevel der Projektmanager, welche die Einteilung in logische aufeinanderfolgende Phasen oft in ihrer Projektplanung schlichtweg vergessen oder sie fehlerhafterweise als obsolet ansehen. Neben dem tatsächlichen Vorteil, dass durch eine klare Gliederung der Phasen ein vereinfachtes Fortschritts-Tracking vonstattengeht, da immer zu einem genau bestimmten Zeitpunkt reportet werden muss, ist es auch ein nicht zu verkennender psychologischer Vorteil, dass man Phasen tatsächlich abschließt. Die Projektorganisation ist in ihrem täglichen Business nur von Problemen und Risiken sowie von Zeit- und Budgetdruck getrieben. Da ist der Zwischeneffekt, etwas geschaffen bzw. geschafft zu haben, ein hervorragender Mechanismus, um die Motivation dauerhaft ausreichend hochzuhalten.

Steuern nach dem Ausnahmeprinzip⁵⁾: Ist das Grundprinzip „Steuern über Managementphasen“ als ein zeitlich getriebener Überwachungs- und Planungsmechanismus zu werten, bezieht sich das Grundprinzip „Steuern nach dem Ausnahmeprinzip“ deutlich mehr auf die Ereignissteuerung. Um dieses Grundprinzip hinreichend gut zu leben, muss dieses Prinzip auch außerhalb der PRINCE2-Projekt-organisation, also der in das Projekt aufgehängten Linie, bekannt, anerkannt und gelebt werden. Hierbei geht es fast um eine Art Wert, also eine innere Überzeugung. Man kann auch von einer Führungsphilosophie sprechen. Bekannt ist dieses Prinzip neben der PRINCE2-Terminologie auch aus der angewandten Betriebswirtschaftslehre, in der dieses Prinzip neudeutsch als „Management by Exception“ gelehrt wird. Hierbei geht es im Grunde darum, als Führungskraft Verantwortung an die nächst tiefere Hierarchieebene zu delegieren. Das bringt den immensen Vorteil mit sich, dass zum einen der in unserem Beispiel typische Projektmanager durch die Einbeziehung seiner Teammanager entlastet wird und die neu eingebundenen Mitarbeiter darüber hinaus über ihren Zuwachs an Verantwortung viel besser mit in den Projekterfolg einbezogen und ggf. noch zusätzlich motiviert werden. Gerade bei Großprojekten, bei denen es eine Vielzahl von Teammanagern gibt, muss das Prinzip gelebt werden, da ansonsten sehr schnell eine Überlastung des Projektmanagers eintritt. Damit dieses Ausnahmeprinzip funktioniert, sind einige wichtige Bestandteile zu beachten: Es sollte im Vorhinein eine klare Kommunikation der Rollen und Verantwortlichkeiten (siehe Grundprinzip Definierte Rollen und Verantwortlichkeiten) durchgeführt werden. Im Weiteren müssen auch Toleranzen, also Bereiche, in denen der Projektmanager und der Teammanager, ohne die nächst höhere Hierarchiestufe einzubinden, in sämtlichen Dimensionen, also Zeit, Budget, Qualität, Risiko, Umfang und Nutzen, mitdelegiert werden.

Der Olympia-Projektmanager hat in dieser Hinsicht von dem Lenkungsausschuss eine Budgetverantwortung von rund 200 Millionen Euro pro Managementphase übertragen bekommen. Diese Summe gilt es dann im Rahmen der richtigen Delegierung an die Teammanager bzw. Teilprojektleiter bedarfsgerecht zu verteilen. Hierbei gibt die PRINCE2-Terminologie nicht vor, ob es Bottom Up, also mit einem ersten Planungsvorschlag der Teammanager, oder Top Down, also mit einem ersten Planungsvorschlag der Projektmanager, verteilt werden soll. Vielmehr geht es darum, in einem gemeinsamen, regelmäßig stattfindenden Planungsmeeting Planungs- und daraus entstehenden Budgetmehrbedarf zu ermitteln und im Rahmen der Budget-Toleranzen der jeweiligen Managementphase zu verteilen.

In der Praxis wird dies meist deutlich intuitiver gehandhabt. Hier geben in aller Regel die Teammanager eine erste Indikation vor, auf deren Basis der Projektmanager dann im Rahmen seiner von dem Lenkungsausschuss vorgegebenen Toleranzen eine Budgetanpassung in seinem Sinn vornimmt. Die Tatsache, dass die Teammanager mit einem besonders großen Puffer an Budget in die Verhandlung mit dem Projektmanager gehen, ist ein ungeschriebenes Gesetz. Ebenfalls ist es ein ungeschriebenes Gesetz, dass der Projektmanager sich über diese Tatsache bewusst ist und deswegen den Teammanagern überdurchschnittlich viel der Budgetplanung wieder kürzt. Im Übrigen spielt sich dieses Szenario auf allen Planungsebenen, also Teammanager, Projektmanager, Lenkungsausschuss und Unternehmensmanagement ab: Die tiefere Ebene kommt mit einer deutlich höheren Budgetplanung als benötigt zur nächst höheren Hierarchieebene, welche wiederum deutlich mehr der Planung streicht, als eigentlich benötigt wird, womit das Ergebnis im Grund genau dem Planungsbedarf entspricht. Beide Parteien sind sich dem in den meisten Fällen bewusst.

Produktorientierung⁶⁾: In den meisten Projektmeetings hört man Teilnehmer immer nur über die Projektaktivitäten sprechen: die Aktivitäten der letzten Woche, die dieser Woche, und welche schiefliefen. Hierbei verliert man jedoch schnell den Blick auf das große Ganze und auf das, was am Schluss das Projekt liefern soll: das Produkt. Diesen Blick wiederherzustellen ist das Ziel des Grundprinzips der „Produktorientierung“. Dem Grundprinzip zufolge geht es darum, den Blick auf die vom Projekt zu liefernden Produkte zu lenken. Wobei Produkte hier nicht unbedingt physische Produkte sein müssen, sondern auch immaterielle Produkte oder Dienstleistungen sein können. Das spiegelt sich vor allen in der Planung des Projekts wider. Hierbei plant man von dem Projektendprodukt, also dem Produkt, welches das Projekt am Ende als Output generieren soll, hin zu den jeweils tieferen, feineren Produktgruppen. Erst am Ende der Planungstiefe, also dann, wenn man auf der von den Teams granularsten zu liefernden Produktebene angekommen, teilt man diese (Teil)-Teilprodukte auf die dafür notwendige Aktivitäten auf. Es kommt also eine Art Rückwärtsplanung zum Einsatz.

Die Olympiade wurde so, von dem großen vom Projekt zu liefernden Endprodukt der stattfindenden Olympiade, in tausende Teilprodukte zerlegt: Häuser, Stadien, neue U-Bahn-Stationen, Hotels, rechtliche Angelegenheiten etc.

Anpassung an die Projektumgebung⁷⁾: PRINCE2 ist eine sehr umfangreiche Projektmanagement-Methodik. Dabei ist sie für Großprojekte absolut geeignet, durch die Anpassung an die Projektumgebung jedoch so adaptierbar und generisch, dass mit der Methodik annähernd jedes Projekt gemanagt werden kann.

Bei einem Großprojekt wie der Olympiade ist die Anpassung an die Projektumgebung sicherlich weniger gegeben, da, je größer ein Projekt ist, ein höherer administrativer Aufwand sich a) in den Gesamtkosten weniger bemerkbar macht als in kleineren Projekten und b) auch einfach gegeben sein muss, damit das Projekt weiterhin steuerfähig bleibt.

Oft fällt auf, dass die Tendenz innerhalb der meisten Projekte eher in Richtung „Admin Overhead“, also in Richtung zu vieler Templates, zu viel Administration, zu vieler Meetings geht, als in eine schlanke und effiziente, also eine angepasste Projektumgebung. Das liegt auch unter anderem an dem oft vorhandenen Irrglauben, dass wenig bis gar keine Administration Agile bedeutet und viel und umfangreiche Administration automatisch „klassisches bzw. Wasserfall-Projektmanagement“. „Managt man offiziell ein ‚klassisches‘ Projekt, sollte man daher automatisch einen hohen Administrationsaufwand mit sich bringen“: so zumindest die falsche Annahme vieler Projektmanager. PRINCE2 sagt hierzu allerdings klar, dass die Administration sich der Projektumgebung anzupassen hat. Wenn das Projektbeispiel weniger risikobehaftet ist, kann einem Projektmanager mehr Freiraum zu Verfügung gestellt werden, als wenn ein hohes Risiko vorliegt.

Neben dem 7. Grundprinzip stellt die Anpassungen an die Projektumgebung (Tailoring) auch einen der 4 Bestandteile von PRINCE2 in Gänze dar. Vorallem in der neuen Vesrion 2017 ist das Tailoring deutlich mehr in den Vordergrund getreten, weshalb wir hierzu nochmal ein Extra-Kapitel entwickelt haben, welches unter Kapitel 1.8 zu finden ist.

1.6Die 7 Themen

Wie bereits beschrieben, sind die 7 Grundprinzipien Werte, die einen erfolgreichen Projektablauf möglichst positiv beeinflussen sollen. Für die Werte muss es allerdings noch eine Beschreibung zur Umsetzung geben. Diese Beschreibung stellen die sieben Themen dar. Sie geben eine Antwort auf die Frage „Wie ist es zu tun?“ Die Inhalte müssen während des Projekts kontinuierlich behandelt werden. Im Folgenden sind die sieben Themen aufgeführt und kurz beschrieben. Im den darauffolgenden Kapiteln wird jedes einzelne Thema, auch im Zusammenspiel mit den Prozessen, aufgearbeitet. Die sieben Themen sind:

Business Case¹⁾

Organisation²⁾

Qualität³⁾

Pläne⁴⁾

Risiko⁵⁾

Änderungen⁶⁾

Fortschritt⁷⁾

Diese werden im Folgenden detailliert beschrieben.

Business Case: Das Thema „Business Case“ wird durch das Grundprinzip der „fortlaufenden geschäftlichen Rechtfertigung“ getrieben. Es geht darum, Mechanismen einzurichten, welche a) dazu da sind, eine geschäftliche Rechtfertigung zu erlangen, und b) sie kontinuierlich zu pflegen. Im Kern geht es darum, ein Projekt so auszurichten, damit es über die gesamte Laufzeit auf Ziele zum Beispiel der Organisation abzielt, es einen Nutzen bietet. Im Laufe des Buches gehen wir noch auf ein bestimmtes Dokument, den Business Case, tiefer ein. Dieses Dokument ist sozusagen die aus dem Thema „Business Case“ herauskristallisierte Essenz, die schriftlich festgehalten wird. Hierbei ist zu beachten, dass nicht jedes Thema ein eigenes Dokument mit sich bringt.

Organisation: Hierbei widmen wir uns der Operationalisierung des Grundprinzips der „definierten Rollen und Verantwortlichkeiten“. Das Thema beschreibt die benötigten Rollen, die Rollenverteilungen, welche sich ausschließen und welche Kompetenzen und Verantwortungsbereiche hinter den verschiedenen Rollen festgeschrieben sein müssen. Es beantwortet die Frage, „wer?“ innerhalb einer Projektorganisation für die jeweilige Umsetzung verantwortlich ist.

Qualität: Das Thema „Qualität“ beschreibt in seiner vollen Ausprägung den richtigen Umgang mit den Stakeholdern in Bezug auf die vom Projekt zu erfüllenden Anforderungen. Das hier wichtigste Grundprinzip ist die „Produktorientierung“. Oft kommt es vor, dass Kunden zu Beginn eines Projekts mit nur sehr subjektiven Äußerungen an das Projektteam herantreten. „Das Haus der Chinesen soll deren Kultur entsprechen“ könnte bei der Olympiade eine typisch formulierte erste Anforderung sein. Die Aufgabe des Themas „Qualität“ ist es in dem Zusammenhang, dem Projektmanager Leitlinien an die Hand zu geben, mit der er es schafft, die zuerst nur sehr weich formulierten Kundenqualitätserwartungen in hart definierte Projektabnahmekriterien zu überführen. Es geht darum, die Frage nach dem „Was“ zu beantworten.

Pläne: Hierbei geht es um die Frage, „wie“ etwas geliefert wird. Weiß man bereits aus einer guten Ausarbeitung des Themas „Qualität“, was der Kunde wünscht, muss man sich im nächsten Schritt mit einer Umsetzung der Kundenwünsche befassen. Damit befasst sich das Thema „Pläne“. Hierbei ist zu beachten, dass nicht nur die eigentliche Umsetzung geplant wird, sondern auch die Art und Weise, „wie“ die Planung innerhalb eines Projekts durchgeführt wird. Welche Tools werden dafür genutzt? Wie sollte das Layout eines von dem Projekt zu liefernden Projektplans aussehen? Wie feinkörnig sollte die Projektplanung aufgestellt sein? All diese Fragen werden neben der eigentlichen Planung innerhalb eines Projekts im Thema „Pläne“ genauer beschrieben. Auch dieses am Thema hat als Grundprinzip die „Produktorientierung“ und das „Steuern über Managementphasen“.

Risiko: Wie bereits beschrieben, wird in der Terminologie von PRINCE2 das Risiko nicht per se als negativ gewertet. Vielmehr geht es darum, Risiken als Unsicherheiten anzusehen, die Auswirkungen sowohl in die negative als auch in die positive Richtung haben können. Wie mit Unsicherheiten eines Projekts umgegangen werden soll, welcher Prozess nach der PRINCE2-Terminologie verwendet werden soll, welche Strategien es für Gegenmaßnahmen gibt, wird alles tiefgehend im Folgenden beim Thema „Risiko“ beschrieben.

Änderungen: Dieses Thema befasst sich mit einer Steuerung der Änderung der Kundenanforderungen. Es geht hierbei in erster Linie darum, Struktur in das Änderungssteuerungsverfahren zu bringen: Welche Arten von Änderungen gibt es? Welche prozessualen Unterschiede liegen hinter den verschiedenen Arten von Änderungen? Die Antworten liefert das Thema „Änderungen“. Darüber hinaus befasst sich das Thema „Änderungen“ mit dem Konfiguarationsmanagement innerhalb eines Projekts. Das Konfiguarationsmanagement beschreibt, kurz gesagt, die Art und das Management von verschiedenen Versionen von Produkten. Das klingt zunächst sehr kryptisch, und zugegebenermaßen ist das nicht für alle Projekte adaptierbar. Jedoch ist u.a. die Versionierung, besonders in der Softwareentwicklung, ein wichtiges Must-Have. Versionierung bedeutet, dass jede neu releaste Version der Software sich klar von der letzten unterscheidet und auch durch eine Versionsnummer entsprechend gekennzeichnet wird.

Fortschritt: Dieses Thema beschreibt, wie die Reporting-Kultur, die Eskalationswege und der Toleranzbereich eines Projekts aussehen sollen. Es soll hierdurch sichergestellt werden, dass zu jedem Zeitpunkt eine Aussage über den Projektfortschritt getroffen werden kann und der Projektmanager oder der Lenkungsausschuss dadurch in die Lage versetzt wird, zu jedem Zeitpunkt eine Entscheidung, die richtige Entscheidung treffen zu können.