Der ultimative Leitfaden zur Kontrolle des Projektumfangs

Bis zu diesem Artikel haben wir verschiedene Aspekte der Projektplanung und -durchführung besprochen. Wir haben die Erstellung eines vollständigen Projektauftrags, die Kosten- und Terminplanungsowie den Umgang mit Risiken durch vorausschauende Planung für unvorhergesehene Ereignisse angesprochen. Im Folgenden widmen wir uns einem weiteren grundlegenden Aspekt der Projektdurchführung: der Überwachung und Steuerung der geplanten Prozesse.

Aber warum sind Überwachung und Steuerung genauso wichtig (wenn nicht sogar wichtiger) als die Planung und Durchführung eines Projekts? Die Antwort ist recht einleuchtend. Bei der Projektplanung entwirft man idealisierte Szenarien, die (hoffentlich) auf bisherigen Erfahrungen basieren und (hoffentlich) an die spezifischen Merkmale und Anforderungen des Projekts. Diese Szenarien spiegeln jedoch selten die ungewisse Zukunft der Projektdurchführung wider. Bei der Ausführung der einzelnen Aufgaben stößt man unweigerlich auf unvorhergesehene Ereignisse, die Anpassungen der Aufgabenbeschreibungen, Ziele, Fristen und Kostenschätzungen erfordern. Hier spielen Steuerung und Überwachung eine entscheidende Rolle: Sie sind die Werkzeuge, mit denen man den Kurs bei Bedarf korrigieren kann.

Die im PMBOK Guide als Überwachung und Steuerung definierte Prozessgruppe setzt sich unter anderem aus folgenden fünf grundlegenden Prozessen zusammen:

• Kontrollbereich
• Kontrollplan
• Kostenkontrolle
• Kontrollqualität
• Kontrollrisiken

Das ist nichts Neues für uns. Erinnern Sie sich an unsere Diskussion darüber, wie man einen vollständigen Projektauftrag erstellt? Von den acht Abschnitten, aus denen der Projektauftrag besteht, sind die fünf wichtigsten aus Sicht der Steuerung und Überwachung:

• Projektumfangsbeschreibung
• Projektergebnisse
• Kosten und Kostenvoranschläge
• Ziele
• Projektbeschränkungen und -risiken

Sie stehen in engem Zusammenhang mit den fünf Hauptprozessen, die im PMBOK Guide definiert sind! Um die Übereinstimmung dieses Kurses mit dem Buch zu gewährleisten, werden in diesem und den folgenden vier Artikeln alle fünf Abschnitte detailliert behandelt.

1. Überprüfung der Definition des Projektumfangs

Bevor wir uns mit den konkreten Werkzeugen zur Steuerung des Projektumfangs befassen, sollten wir uns zunächst etwas Zeit nehmen, um zu verstehen, was der Projektumfang eigentlich ist.

Der Begriff „Projektumfang“ ist etwas vage. Er umfasst verschiedene Bereiche des Projekts und definiert dessen Grenzen hinsichtlich Kosten, Zeitplan, Aufgaben, Ergebnisse und Qualitätsstandards. Anders ausgedrückt: Der Projektumfang legt die allgemeine Ausrichtung des Projekts.

Obwohl der Projektumfang die grundlegendste Definition in einem Projekt darstellt, gerät er bei der Planung und Durchführung spezifischerer Projektteile leicht in Vergessenheit. Dies ist uns in den von uns betreuten Projekten schon mehrfach passiert, und der Ablauf ist im Großen und Ganzen folgender: Ihr Kunde (ob extern oder aus einer anderen Abteilung desselben Unternehmens) präsentiert Ihnen eine Vorstellung des gewünschten Produkts oder der Dienstleistung. Er beschreibt seine Anforderungen präzise und erläutert sie Ihnen detailliert. Ihre Aufgabe ist es, sowohl die Geschäftsanforderungen zu verstehen als auch die übergeordneten Ebenen des Projektstrukturplans (PSP). Nach einigen Überlegungen und Diskussionen mit Ihrem Team legen Sie den Projektumfang fest, indem Sie die Hauptmerkmale des Projekts sowie die Anforderungen an Zeitplan, Kosten und Qualität definieren. Soweit, so gut.

Doch während der Projektdurchführung und mit der Zeit tauchen neue Funktionen und Ideen auf. Ihre Kunden fordern neue Funktionalitäten, die ursprünglich nicht im Projektplan vorgesehen waren. Sie analysieren die Ideen und stellen fest, dass sie aus einer detaillierten Perspektive durchaus vielversprechend sind. Funktion für Funktion, Aufgabe für Aufgabe nimmt Ihr Projekt eine andere Form an als ursprünglich geplant. Anstatt den Projektumfang erneut zu überprüfen, um festzustellen, ob die neuen Funktionen oder Änderungen im Hinblick auf das ursprüngliche Ziel relevant sind, einigen Sie sich mit Ihrem Kunden darauf, sie einfach in den Projektdurchführungsplan aufzunehmen, da sie relevant erscheinen.

Lassen Sie mich Ihnen ein persönliches Beispiel geben. Vor einiger Zeit leitete ich ein Projekt zur Entwicklung einer Website für ein Immobilienunternehmen. Ziel des Projekts war es, die Nutzererfahrung beim Finden, Kaufen, Mieten und Verkaufen von Immobilien zu verbessern. In den Kundengesprächen kam es fast schon routinemäßig vor, dass Kunden Ideen wie „eine Kommunikationsfunktion speziell für Hotels hinzufügen, damit Hotelmanager im Notfall schnell mit den Gastgebern kommunizieren können“ einbrachten. Dies widersprach völlig der ursprünglichen Zielsetzung des Projekts, und wir mussten unsere Kunden immer wieder daran erinnern, dass sich das Produkt an die Immobilienbranche richtete. Das heißt aber nicht, dass wir jede Idee, die vom ursprünglichen Ziel abweicht, verwerfen müssen; stattdessen können wir vorschlagen, sie in einem separaten Projekt umzusetzen. Abschnitt 3.4 dieses Artikels beschreibt, wie man mit unberechtigten Kundenwünschen umgeht und stellt ein geeignetes Vorgehen vor.

Als Projektmanager ist es Ihre Aufgabe, Grenzen zu setzen und Ihre Kunden davon abzuhalten, zu weit von ihren ursprünglichen Anforderungen abzuweichen. Es liegt in Ihrer Verantwortung, sie darauf hinzuweisen, wenn ihre Wünsche nicht relevant sind, und sie an ihre ursprünglichen Ziele zu erinnern.

Das ist der Kern der Scope-Kontrolle und -Überwachung: zu vermeiden, dass die natürlichen Veränderungen, die mit der Durchführung des Projekts einhergehen, am Ende zu einem völlig anderen Ergebnis führen.

Ein klar definierter Prozess zur Steuerung des Projektumfangs hilft Ihnen, jede Änderungsanforderung mit den ursprünglichen Projektzielen abzugleichen und zu entscheiden, ob sie in den Projektstrukturplan (PSP) aufgenommen werden soll. Er unterstützt Sie außerdem bei der Definition eines Maßnahmenplans für den Umgang mit Anforderungen, die nicht zum Projektumfang passen. Sollten Sie ein neues Projekt zur Umsetzung vorschlagen? Einen externen Dienstleister beauftragen, der das Produkt/die Dienstleistung bereits anbietet? Oder die Umsetzung komplett vermeiden?

In den folgenden Abschnitten werden die verschiedenen Eingaben, Werkzeuge und Ausgaben des Prozesses zur Überwachung und Steuerung des Projektumfangs vorgestellt. Beginnen wir mit einer Übersicht darüber, welche Dokumente Sie sammeln sollten, um mehr Informationen zu erhalten und besser mit Problemen und Abweichungen im Projektumfang umgehen zu können.

2. Erforderliche Eingaben für die Projektumfangssteuerung

Erinnern Sie sich an unsere Besprechung des Projektumfangs, der die allgemeine Richtung und die übergeordneten Rahmenbedingungen Ihres Projekts definiert? Bei der Überwachung und Steuerung des Projektumfangs geht es darum, Ihre tatsächliche Leistung mit diesen ursprünglichen Definitionen zu vergleichen, um zu überprüfen, ob Sie die ursprünglich festgelegten Vorgaben einhalten. Hier finden Sie eine umfassende Liste der Dokumente, die Sie während der Umfangssteuerung gemäß dem PMBOK Guide zur Verfügung haben sollten

2.1 Projektmanagementplan

Der Projektmanagementplan stellt die verschiedenen Projektphasen dar und verknüpft alle relevanten Dokumente zu einem stimmigen Ganzen. Er enthält Informationen wie den Projektlebenszyklus, die für jede Phase relevanten Makroprozesse, den Beitrag jeder Phase zum Erreichen des Projektziels, eine Übersicht des Änderungsmanagementplans sowie weitere Abschnitte. Letztendlich sollte der Projektmanagementplan eine Zusammenfassung aller projektbezogenen Informationen enthalten. Vermeiden Sie es jedoch, alle Dokumente vollständig im Projektmanagementplan abzubilden: Dies führt zu einem unübersichtlichen Dokument, das niemand komplett lesen wird. Fassen Sie stattdessen die Informationen zusammen und präsentieren Sie die wichtigsten Punkte jedes Abschnitts zusammen mit dem Link zum jeweiligen Plan.

Wir empfehlen, bei der Durchführung der Umfangsprüfung die folgenden fünf Abschnitte dieses Dokuments zu berücksichtigen.

2.1.1 Umfang-Basislinie

Die Scope-Baseline setzt sich aus der Scope-Definition und dem Projektstrukturplan (PSP) zusammen. Anhand dieses Dokuments sollten Sie die tatsächlichen Projektentwicklungen überprüfen, um festzustellen, ob Änderungen oder Anpassungen erforderlich sind.

Die Scope-Deklaration sollte zwei Hauptabschnitte enthalten: den Produkt-/Service-Scopemit allen relevanten Merkmalen und Funktionalitäten sowie den Projekt-Scopemit einer Beschreibung der Arbeiten, die für die erfolgreiche Durchführung des Projekts erforderlich sind.

2.1.2 Umfangsmanagementplan

Der Scope-Management-Plan definiert die Richtlinien, die bei Änderungen des Projektumfangs befolgt werden müssen. Grundsätzlich sollte man nicht alle Bereiche des Projekts für Änderungen offenlassen. Einige der ursprünglichen Definitionen müssen beibehalten werden, da sie das Wesen des Projekts ausmachen; eine Änderung dieser Definitionen würde letztendlich ein völlig neues Projekt zur Folge haben.

Nehmen wir als konkretes Beispiel ein Architekturprojekt. Sobald das Bauteam mit dem Bau begonnen hat, lassen sich nicht mehr alle Aspekte des Bauplans ändern: Die Fundamentkonstruktion und andere bauliche Gegebenheiten schränken die Möglichkeiten ein. Die Argumentation ist analog: Vor Projektbeginn (wenn Sie noch Anforderungen, Produktspezifikationen und andere Details mit Ihrem Kunden besprechen) ist alles änderungsfähig. Sobald Sie mit der Ausführung beginnen, gibt es Bereiche, die nicht ohne Weiteres geändert werden können, ohne ein komplett neues Projekt zu erzwingen. Diese Bereiche sollten im Projektmanagementplan klar definiert werden.

Um Ihnen bei der Erstellung des Scope-Management-Plans zu helfen, finden Sie hier einige Ideen für konkrete Vorgehensweisen, die Sie definieren könnten (diese Liste ist nicht vollständig, ergänzen Sie sie daher gerne um Ihre eigenen Fragen):

• Welche Bereiche des Produkt-/Projektumfangs und des Projektstrukturplans können sich nach der Genehmigung ändern?
• Welche Abteilungen oder Interessengruppen sollten vor der Umsetzung der Änderungen konsultiert werden?
• Welche Anforderungen müssen bei einer Änderung des Projektumfangs beachtet werden?
• Welche Ergebnisse können verworfen oder aktualisiert werden, und welche sollten nicht verändert werden?
• Was ist das ultimative Ziel des Projekts (das Endziel, an dem Sie ankommen möchten)?
• Was sind die wichtigsten Projektphasen und welche Anforderungen stellen sie?
• Wie aufwendig ist es, eine abgeschlossene Projektphase zu ändern, und welche Auswirkungen hat dies auf das Projekt?

Unser Artikel zur Berechnung des Projektplans bietet einen hervorragenden visuellen Algorithmus zur Identifizierung von Sequenzbeschränkungen in einem Projekt. Dies wiederum hilft Ihnen zu verstehen, wie jede Projektphase andere Aufgaben im Projektstrukturplan beeinflusst und von ihnen beeinflusst wird.

2.1.3 Änderungsmanagementplan

Der Änderungsmanagementplan ist das Dokument, das zusammenfasst, wie Änderungen im Projekt gehandhabt werden. In unserem Artikel über Kommunikationsmanagement haben wir ausführlich erörtert, wie man Änderungen in einem Projekt managt, und außerdem einige Tipps gegeben, wie man in Änderungsphasen mit verschiedenen Stakeholdern umgeht.

Ein ausgereifter Änderungsmanagementplan ist unerlässlich, um bei der Umsetzung der erforderlichen Änderungen im Projektumfang vorzugehen. Er hilft Ihnen, Fragen zu beantworten wie: Wer sollte in den Entscheidungsprozess einbezogen werden? Wer sollte nach den Entscheidungen benachrichtigt werden? Und welche praktischen Schritte sind in Bezug auf die verschiedenen Änderungskategorien zu unternehmen?.

2.1.4 Konfigurationsmanagementplan

Der Konfigurationsmanagementplan legt fest, welche Merkmale des Endprodukts oder der Dienstleistung änderbar sind und wie diese Änderungen nachverfolgt und analysiert werden. Er definiert außerdem, welche Punkte einen formelleren Genehmigungsprozess erfordern und welche während der Projektdurchführung im Ermessen des Projektteams liegen.

2.2 Anforderungsdokumentation

Die Dokumentation der Projektanforderungen definiert, welche Bedürfnisse und Anforderungen der verschiedenen Stakeholder durch das Projekt erfüllt werden müssen. Anders ausgedrückt: Sie legt die „Anforderungen“ fest, die die Stakeholder durch das Projektergebnis erfüllen wollen. Während ein Geschäftsführer beispielsweise eine akzeptable Gewinnspanne vom Projekt erwartet, konzentriert sich ein potenzieller Käufer möglicherweise auf Qualität, Kosten und Kompatibilität.

Die verschiedenen Stakeholder haben unterschiedliche Anforderungen, die teilweise im Widerspruch zueinander stehen können (beispielsweise fordern Geschäftsführer hohe Gewinne, während der Qualitätsanspruch des Kunden den Einsatz teurerer Rohstoffe erforderlich machen könnte). Die Kontrolle des Projektumfangs umfasst auch die Sicherstellung der vollständigen Erfüllung der Anforderungen und die bedarfsgerechte Anpassung des Umfangs während der Projektdurchführung.

Darüber hinaus sollten Sie den Zusammenhang zwischen Produktkonfiguration und Produktanforderungen. Eine andere Produktkonfiguration erfordert andere Inputs, daher erfordert jede Änderung der physischen oder immateriellen Aspekte Ihres Projektergebnisses eine Aktualisierung des Beschaffungsplans.

2.3 Tatsächliche Arbeitsleistung

Die oben aufgeführten Dokumente bilden 50 % der erforderlichen Eingangsdaten für das Projektcontrolling. Die anderen 50 % ergeben sich aus den Daten zur tatsächlichen Arbeitsleistung. Denn das Kernstück des Projektcontrollings besteht darin, die tatsächliche Leistung mit der prognostizierten zu vergleichen.

Für die Überwachung des Projektumfangs sind Daten zur Beschreibung der tatsächlich durchgeführten Aufgaben relevant. Detaillierte Kosten- und Terminpläne sind weniger wichtig; diese behandeln wir im Abschnitt Kosten- und Terminkontrolle. Im Bereich des Projektumfangs liegt Ihr Fokus darauf, zu wissen, welche Aufgaben ausgeführt werden und ob deren Ergebnisse das Projekt dem erfolgreichen Abschluss näherbringen. Natürlich ist ein allgemeiner Überblick über Kosten und Zeitplan wichtig, um sicherzustellen, dass das Projekt innerhalb des finanziellen und zeitlichen Rahmens durchgeführt wird. Die detaillierte Prüfung von Kosten und Zeitplan gehört jedoch nicht zum Aufgabenbereich des Projektumfangsmanagements.

Im Artikel zur Projektplanung haben wir einen detaillierten Projekt-Tracker. Der Tab „Aufgaben-Tracker“ bietet Ihnen einen vollständigen Überblick über die laufenden Aufgaben, deren Fortschritt und die tatsächlichen Kosten. Mit jedem Projektmanagement-Tool können Sie basierend auf den von Ihrem Team hinzugefügten Informationen verschiedene Berichte erstellen.

Eine weitere wichtige Folge der Berichtserstellung und der Aktualisierung der Leistungsindikatoren ist die Gewährleistung, dass diese stets mit den aktuellsten und gültigsten Informationen aktualisiert werden. Es kann vorkommen, dass Ihr Team unrealistische Angaben zum Aufgabenfortschritt und den Kosten macht. Die Überprüfung der Diskrepanzen zwischen gemeldetem und tatsächlichem Fortschritt ist ebenfalls eine Aufgabe des Projektcontrollings.

3. Werkzeuge und Techniken zur Steuerung des Projektumfangs

Sobald Sie den Großteil der notwendigen Dokumentation zusammengetragen haben (je nach Struktur Ihres Projekts können Sie möglicherweise auf einige Dokumente verzichten), ist es an der Zeit, mit der eigentlichen Festlegung und Überwachung des Projektumfangs zu beginnen.

3.1 Wie oft sollten Sie den Umfang Ihres Projekts überwachen und anpassen?

Eine häufig gestellte Frage von Projektmanagern ist, wie oft die Überwachung und Anpassung des Projektumfangs erfolgen sollte. Die Antwort darauf ist leider nicht standardisiert: Sie hängt stark von der Art des Projekts ab. Zwei Beispiele sollen dies verdeutlichen.

Stellen Sie sich zunächst ein Softwareentwicklungsunternehmen vor, das in einem sehr schnelllebigen Umfeld agiert. Für dieses Unternehmen ist die Überwachung des Projektumfangs möglicherweise ein- bis zweimal wöchentlich erforderlich. Die Vielzahl an Ideen, die Umsetzungsgeschwindigkeit und die Geschwindigkeit, mit der Wettbewerber ihre Produkte aktualisieren, machen die Technologiebranche extrem volatil. Daher müssen Sie in der Lage sein, schnell zu reagieren, indem Sie die Gesamtstruktur des Projekts mindestens wöchentlich anpassen. Ein weiterer Aspekt von Technologieunternehmen, der sie für die kontinuierliche Umfangsanalyse prädestiniert, ist die Fähigkeit, praktisch jeden Teil des Projekts mit minimalen Auswirkungen auf die zugehörigen Prozesse zu ändern. Während in der Bauindustrie das Fundament eines Hauses nicht ohne Weiteres geändert werden kann, ohne das gesamte Gebäude zu beeinträchtigen, kann ein Technologieunternehmen seine Serverstruktur ändern und sein Produkt dennoch schnell mit der neuen Datenbank verbinden. Dieser Prozess ist zwar nicht so schnell wie andere Aktualisierungen, kann aber mit geringen Auswirkungen auf das Endprodukt durchgeführt werden (abgesehen von der Schicht, die das Frontend-Produkt mit dem Backend-Server-Speicherdienst verbindet).

Am anderen Ende des Spektrums stehen Branchen wie Architektur und Bauwesen. Hier ist es äußerst schwierig, Änderungen rückgängig zu machen, sobald eine Projektphase abgeschlossen ist und die nächste beginnt. Ist das Fundament eines Gebäudes fertiggestellt und mit dem Bau des ersten Obergeschosses begonnen, gilt der Teil des Leistungsumfangs, der das Fundament betrifft, als unveränderlich. Dasselbe gilt für jede Projektphase, die von den vorherigen abhängt. In diesen Branchen sind Änderungen des Leistungsumfangs daher deutlich seltener als in der Technologiebranche. Andererseits sind diese Monitoring-Sitzungen wesentlich detaillierter und dauern in der Regel deutlich länger als ein 30-minütiges Meeting.

Wie häufig Sie Sitzungen zur Festlegung des Projektumfangs durchführen, hängt von Ihrer Branche, Ihrem Team und der Projektpriorität ab. Es ist wichtig, diese Punkte mit allen relevanten Beteiligten zu besprechen und im Vorfeld festzulegen, wann Anpassungen des Projektumfangs erfolgen.

3.2 Vergleich der tatsächlichen und erwarteten Ergebnisse mithilfe der Varianzanalyse

Die Varianzanalyse untersucht, ob die natürlichen Schwankungen während der Projektdurchführung so groß sind, dass eine aktive Korrektur oder Anpassung erforderlich ist. Ihr Projekt wird höchstwahrscheinlich im Laufe der Zeit vom ursprünglichen Projektstrukturplan abweichen, und es liegt in Ihrer Verantwortung zu beurteilen, ob diese Abweichungen korrigiert werden müssen oder nicht.

Aus dem bisher Besprochenen lässt sich ableiten, dass die Umfangssteuerung eher beschreibend als numerisch ist. Wir können zwar allgemeine Kosten- und Terminplanzahlen haben, die Berechnungen sollten aber den spezifischen Kosten- und Terminplanungsprozessen überlassen werden. Beim Umfang geht es uns darum zu vergleichen, ob die Aufgabenbeschreibungen und die Struktur unserem ursprünglich geplanten Projektstrukturplan (PSP) und der Umfangsdefinition entsprechen.

Die Varianzanalyse geht daher einen Schritt weg von der reinen Statistik. Für das Scope-Management sollten Sie sich auf den Vergleich der Projektstruktur selbst konzentrieren, anstatt auf die Zahlen.

3.3 Nutzung von Was-wäre-wenn-Szenarioanalysen zur Ableitung von Anpassungsvorschlägen

Die Was-wäre-wenn-Szenarioanalyse ist ein einfacher, aber solider Ansatz, um die Auswirkungen verschiedener Ereignisse auf Ihr Projekt zu analysieren. Sie wird zwar üblicherweise zur Prognose der Folgen unerwarteter Ereignisse eingesetzt, ihre Prinzipien gelten aber auch für das Scope-Management.

Die grundlegende Frage, die das Was-wäre-wenn-Szenario zu beantworten versucht, lautet: „Wie wird mein Projekt beeinflusst, wenn Ereignis X eintritt?“ Dieselbe Argumentation lässt sich anwenden, um zu analysieren, wie sich die Umsetzung von Änderung X oder Korrektur Y auf Ihr Projekt auswirkt. Welche Konsequenzen ergeben sich hinsichtlich Arbeitsstruktur und Aufgabenbeschreibung? Werden neue Kompetenzen benötigt, die Ihr Team aktuell nicht besitzt? Welche Empfehlungen haben Sie, um die durch die Änderung entstehenden Probleme zu lösen?

Eine effektive Methode, um zu analysieren, ob die vorgeschlagenen Änderungen sinnvoll sind und umgesetzt werden sollten, besteht darin, die prognostizierten Projektergebnisse im Ist-Zustand (ohne Änderung) und im vorgeschlagenen Szenario (mit Änderung) zu vergleichen. Gibt es große Unterschiede zwischen den Prognosen? Lohnt sich eine belastende Anpassungsphase? Ist der Nutzen der Änderung hoch genug, um die Kosten zu decken?

Da der Projektumfang die Grundlage für Ihr gesamtes Projekt bildet, sind Änderungen daran schwerer rückgängig zu machen. Daher sollten solche Fragen Gegenstand einer eingehenden Diskussion zwischen Ihnen und den relevanten Stakeholdern sein, und die Konsequenzen jeder Änderung sollten eingehend geprüft werden.

3.4 Wie man eine Ausweitung des Projektumfangs vermeidet und mit unangemessenen Kundenanfragen umgeht

Scope Creep ist der Fachbegriff für das, was wir im Zusammenhang mit dem unkontrollierten Wachstum des Projektumfangs besprochen haben. Der PMBOK® Guide definiert es eindeutig:

[Scope Creep ist die Praxis,] Funktionen und Funktionalitäten (Projektumfang) hinzuzufügen, ohne die Auswirkungen auf Zeit, Kosten und Ressourcen zu berücksichtigen oder ohne Zustimmung des Kunden.

PMBOK, 4. Ausgabe, 2008

Eine Ausweitung des Projektumfangs kann aus verschiedenen Gründen auftreten, zu den wichtigsten zählen:

• Unfähigkeit, Kundenanfragen zu bearbeiten: Viele Manager scheuen sich, unpassende Kundenanfragen abzulehnen, aus Angst, den Kunden zu verärgern. Doch das Gegenteil ist der Fall: Indem Sie aufzeigen, dass die Anfrage nicht zum aktuellen Projekt passt und alternative Vorgehensweisen präsentieren, beweisen Sie Ihr Interesse am Erfolg des Kunden.
• Mangelnde Kontrolle des Projektumfangs: Das Vermeiden von Kontrolle und Überwachung des Projektumfangs kann sehr leicht zu einer Ausweitung des Projektumfangs führen, da es keine regelmäßige Überprüfung der im Projektumfang enthaltenen Aufgaben gibt.
• Mangelhafte interne und externe Kommunikation: Werden Projektänderungen nicht ordnungsgemäß kommuniziert oder die notwendige formale Genehmigung bei Projektänderungen unterlassen, kann dies zu einer Ausweitung des Projektumfangs und zum Verlust der Kontrolle über den Projektumfang führen.
• Ein nicht klar definiertes Produkt: Wenn es keine klaren Merkmale und Grenzen für das zu entwickelnde Produkt oder die Dienstleistung gibt, ist es viel schwieriger, den Umfang des Projekts zu kontrollieren und in die Falle der Ausweitung des Projektumfangs zu tappen.

Dies sind nur einige Beispiele für mögliche Probleme im Projektumfangsbereich. Um diesen entgegenzuwirken, wollen wir einige Techniken und Empfehlungen des PMI genauer.

3.4.1 - Jeder interessierte Stakeholder soll seine eigene Projektcharta entwickeln

Ein Projektauftrag enthält alle wichtigen Abschnitte zur Planung, Durchführung und Steuerung eines Projekts. Indem verschiedene Projektbeteiligte ihre eigenen Projektaufträge erstellen, erhalten Sie unterschiedliche Perspektiven auf wichtige Projektmerkmale. Dies wiederum hilft Ihnen, einen klar definierten Projektumfang festzulegen und eine Ausweitung des Projektumfangs aufgrund unzureichender Projektdefinition zu vermeiden.

3.4.2 – Definieren Sie den Änderungsmanagementplan, bevor Änderungen eintreten

Projektmanager tappen oft in die Falle, Ressourcen für die Erstellung eines Änderungsmanagementplans erst dann bereitzustellen, wenn Anpassungen für das Überleben des Projekts unerlässlich sind. Dies führt jedoch zu mangelhaften und unvollständigen Änderungsprozessen, die nicht alle notwendigen Aspekte für die ordnungsgemäße Implementierung von Änderungen im Projekt abdecken.

Durch die frühzeitige Entwicklung des Change-Management-Plans schaffen Sie vordefinierte Abläufe, die eine Ausweitung des Projektumfangs verhindern, indem Sie Ihren Entscheidungsprozess standardisieren.

3.4.3 - Betrachten Sie den Projektstrukturplan sowohl aus makro- als auch aus mikroökonomischer Perspektive

Eine Ausweitung des Projektumfangs entsteht auch dadurch, dass der Projektumfang nur auf Mikroebene analysiert wird und Produktmerkmale einbezogen werden, die zwar akzeptabel erscheinen, deren Einordnung in den Gesamtkontext des Projekts aber unberücksichtigt bleibt. Die Berücksichtigung sowohl der Makro- als auch der Mikroperspektive ermöglicht eine bessere Beurteilung, ob Änderungsanträge zu einem besseren Projektergebnis beitragen oder nicht in den Projektumfang aufgenommen werden sollten.

3.4.4 – Umgang mit unangemessenen Kundenanfragen

Erinnern Sie sich an das Beispiel mit der Immobilienwebsite und der App-Funktionalität für Hotelmanager? Aus Kundensicht ist das nachvollziehbar: Die Funktionalität ist branchenspezifisch, und Kunden wünschen sich ein Produkt mit möglichst vielen Funktionen, damit verschiedene Zielgruppen dasselbe Produkt nutzen und so ihren Marktanteil steigern. Aus Sicht eines Managers ist das jedoch absurd: Es ist sinnvoller, zwei separate Produkte zu haben, die jeweils einen einzigen Service implementieren. Das führt zu besseren Produkten und gezielteren Marketingmaßnahmen und erhöht somit die Erfolgsaussichten am Markt. Und falls ein Produkt scheitert, steht immer noch ein anderes vielversprechendes Produkt zur Verfügung, auf das man sich konzentrieren kann.

Dies ist ein klassischer Fall von Scope Creep (einschließlich Funktionen, die nicht zum Gesamtziel des Projekts passen). Doch wie geht man mit solchen Anfragen um? Wie teilt man dem Kunden mit, dass die gewünschte Änderung für das aktuelle Projekt nicht geeignet ist?

Der erste Schritt besteht darin, die Motivation Ihres Kunden zu verstehen. Warum hat er diese Funktionen angefordert? Welche Marktbedürfnisse möchte er erfüllen? Dies liefert Ihnen wichtige Informationen, um die geeignete Vorgehensweise zu besprechen, ohne die Ideen oder Erwartungen Ihres Kunden zu enttäuschen.

Sobald Sie eine Vorstellung davon haben, was Ihr Kunde erreichen möchte, erstellen Sie einen umfassenden Umsetzungsplan für ein separates Projekt. Besprechen Sie dabei alle wichtigen Bereiche der Geschäftsplanung: Kostenanalyse, Umsatzprognosen, Marktanteile, Marketingpläne, Produktmerkmale und weitere Aspekte, die Sie für relevant halten.

Setzen Sie sich nach Fertigstellung dieses Dokuments mit Ihrem Kunden zusammen und erläutern Sie Ihre Vorschläge. Erklären Sie ihm, dass Sie die Idee für gut halten und sie unbedingt umsetzen sollten, sie aber zu weit vom Rahmen des aktuellen Projekts abweicht. Erinnern Sie ihn dabei an den Projektumfang und die ursprünglich gewünschten Produktmerkmale.

Zeigen Sie ihnen Ihren Businessplan und die von Ihnen durchgeführte Analyse und bekunden Sie Ihr Interesse an der Produktentwicklung als neues Projekt. Gleichzeitig können Sie die Vorteile zweier separater Produkte erörtern, die jeweils auf eine Hauptfunktionalität fokussiert sind: besseres Branding, effektiveres Marketing, präzisere Zielgruppenansprache und verbesserte Funktionalitäten.

Diese Vorgehensweise ist zwar deutlich effektiver und kundenfreundlicher, doch viele Projektmanager schieben die Entscheidung oder das Gespräch mit dem Kunden auf. Vermeiden Sie das. Wenn Sie bereits wissen, dass die eingehende Anfrage nicht zum Projekt passt, ersparen Sie sich unnötigen Ärger und schlagen Sie alternative Vorgehensweisen vor, von denen sowohl Sie als auch Ihr Kunde profitieren.

4. Ergebnisse der Projektumfangssteuerung

Die Kontrolle und Überwachung des Projektumfangs führt unweigerlich zu Änderungen in der gesamten Projektstruktur. Im Folgenden werden die drei wichtigsten Wissensbereiche erläutert, die von der Umfangskontrolle betroffen sind.

4.1 Aktualisierungen der Organisationsprozesse

Aktualisierungen der organisatorischen Prozesse sind eine unmittelbare Folge einer guten Projektsteuerung, da fehlerhafte Prozesse normalerweise die Ursache für Abweichungen zwischen der erwarteten und der tatsächlichen Projektaufgabenstruktur sind.

Wir meinen damit Folgendes: Wenn die Planung Ihres Projekts während der Ausführung nicht wie geplant verlaufen ist, liegt das daran, dass es irgendwann organisatorische Probleme gab, die zu Unstimmigkeiten führten. Hier einige Beispiele:

• Schlechte Projektplanung: Es wird nicht genügend Zeit für eine ordnungsgemäße Planung aufgewendet und eine ausreichende Anzahl von Variablen berücksichtigt, die das Projekt beeinflussen könnten.
• Schlechte Kommunikation: Unzureichende Kommunikation mit den Stakeholdern und unpräzise Definition der Projektmerkmale für das Team.
• Mangelhafte Ausführung: Nichterfüllung der ursprünglichen Kundenwünsche oder Minderleistung aufgrund schlechter Managementpraktiken.

Beachten Sie, dass es sich bei diesen Beispielen allesamt um Organisationsprozesse handelt. Es gibt etablierte Prozesse zur Projektplanung, zur Kommunikation mit den Stakeholdern sowie zur Interpretation und Ausführung von Aufgaben.

Anders ausgedrückt: Die Aktualisierung dieser Prozesse besteht darin, die Erkenntnisse aus der Projektumfangssteuerung einzuarbeiten. Sie helfen Ihnen dabei, die Prozesse zu identifizieren, die die Abweichungen zwischen erwarteter und tatsächlicher Leistung verursacht haben, und die notwendigen Maßnahmen zur Behebung dieser Probleme abzuleiten.

4.2 Aktualisierungen des Projektmanagementplans

Die beiden wichtigsten Abschnitte des Projektmanagementplans, die im Zuge der Scope-Kontrolle aktualisiert werden, sind (1) die Scope-Definition und (2) der Projektstrukturplan (PSP). Stellen Sie sicher, dass Sie alle Stakeholder über die Aktualisierungen und deren Auswirkungen auf die laufenden Arbeiten informieren

Zusätzlich zur Projektumfangsbeschreibung und dem Projektstrukturplan (PSP) müssen Sie möglicherweise weitere Abschnitte des Projektmanagementplans sowie die zugehörige Detaildokumentation aktualisieren. Falls, wie bereits besprochen, eine Änderung des Projektumfangs zu Änderungen der Anforderungen oder der Beschaffung führt, sollten die entsprechenden Dokumente aktualisiert werden.

4.3 Änderungsanträge zur Projektdurchführung

Ihr Projekt befindet sich höchstwahrscheinlich bereits in der Ausführungsphase, wenn Änderungen am Projektumfang vorgenommen werden. Ihre Aufgabe als Projektmanager besteht darin, diese Änderungen in konkrete Handlungsanweisungen zu übersetzen und Ihr Team darüber zu informieren.

Wir haben ausführlich besprochen, wie Änderungen in Ihrem Projekt gehandhabt werden sollten. Am besten dokumentieren Sie alles, um Missverständnisse zu vermeiden. Nutzen Sie das Änderungsprotokoll, um die Änderungen des Projektumfangs sowie deren Auswirkungen auf die Arbeit Ihres Teams festzuhalten. So stellen Sie sicher, dass alle Teammitglieder Zugriff auf die aktuellsten Informationen haben und Arbeitsverluste durch veraltete Aufgaben vermieden werden.

5. Schlussworte

Scope-Management ist für den Erfolg Ihres Projekts unerlässlich. Dennoch halten viele Projektmanager es für unwichtig und verschieben seine Implementierung, bis deutliche Anzeichen dafür vorliegen, dass das Projekt in die falsche Richtung läuft. In diesem Fall verbrauchen Korrekturen deutlich mehr Ressourcen, als wenn die Probleme frühzeitig im Projekt erkannt worden wären.

Unser letzter Tipp: Handeln Sie proaktiv statt reaktiv. Warten Sie nicht auf Warnsignale, sondern prüfen Sie regelmäßig, ob Ihr Projekt auf dem richtigen Weg ist. Wenn ja, haben Sie höchstens ein paar Minuten verschwendet; wenn nicht, ersparen Sie sich viel Ärger, indem Sie die Probleme frühzeitig beheben.