Scope Creep ist der Fluch im Leben eines jeden Projektmanagers und bis zu einem gewissen Grad unvermeidlich, sagt Andrew Vermes, Technology Practice Leader beim Beratungsunternehmen Kepner-Tregoe.
Scope Creep kann von vornherein vermieden werden. Sollte dies jedoch nicht möglich sein, werden wir uns Möglichkeiten ansehen, wie man damit umgehen kann. Dies ist eine Sammlung praktischer Techniken und kein Ersatz für das umfangreiche theoretische Wissen, das Sie im Project Management Body of Knowledge (PMBoK), im Capability Maturity Model for Projects, in PRINCE2 oder an anderer Stelle finden können.
Es gibt gute Gründe für Unternehmen, die Anforderungen in einem IT-Projekt zu erweitern oder zu ändern: Die Welt dreht sich weiter; neue Bedrohungen für die Datensicherheit werden entdeckt, externe Kundenanforderungen ändern sich, die Technologie schreitet so weit fort, dass das Unwahrscheinliche oder hoffnungslos Teure in praktische Reichweite rückt. Die schlechten Gründe für Anforderungsänderungen lassen sich so zusammenfassen: „Wir haben es am Anfang einfach nicht richtig durchdacht“.
Sie können einen Großteil des Scope Creep vermeiden oder bewältigen, indem Sie die folgenden Ansätze bei jedem Projekt oder Teilprojekt anwenden:
- Bewerten Sie den Prozess, an dem Sie arbeiten möchten;
- Beziehen Sie die Stakeholder intensiv in die Planung ein;
- 5-Why-Methode – Ergründen Sie die Hintergründe der genannten Anforderung;
- Managen Sie kontinuierlich Risiken und Chancen;
- Machen Sie Annahmen sichtbar.
Den Prozess bewerten
Um den endgültigen Umfang fest im Griff zu haben, müssen Sie die Stakeholder an der Prozessüberprüfung beteiligen. Auf diese Weise werden sie auf Mängel im aktuellen Prozess hinweisen sowie auf Punkte, an denen der „reale“ Prozess erheblich vom Betriebshandbuch der Abteilung abweicht. Spätere Überraschungen führen zu unerwünschten Änderungen.
Wenn Sie eine bestehende Funktion ändern, lassen Sie einige Anwender ihre Arbeitsabläufe durchspielen. Post-it-Notizen sind eine hervorragende Möglichkeit, die einzelnen Schritte festzuhalten. Achten Sie darauf, dass sie Ihnen zeigen, was sie tun, anstatt nur zu beschreiben, was ihrer Meinung nach passiert. Bei einem neuen Prozess können sie mit Ihnen den von ihnen vorgestellten Ablauf durchgehen.
Sobald Sie den Prozess erfasst haben, lassen Sie ihn die Anwender bei einer realen Aufgabe testen. Zeichnen Sie bei Bedarf ein paar grobe Entwürfe der Benutzeroberfläche auf Papier und fragen Sie die Anwendergruppe, wie gut diese funktionieren. Dokumentieren Sie die Lücken und spielen Sie den Prozess so lange durch, bis Sie sicher sind, dass er das tut, was er soll.
„White Space“ ist ein Schlagwort, das in letzter Zeit häufig verwendet wird. Der Begriff, der in den neunziger Jahren von Alan Brache und Geary Rummler bekannt gemacht wurde, bezieht sich auf die Beobachtung, dass ein Großteil der wichtigen Arbeit in jeder Organisation außerhalb der „offiziellen“ Prozessschritte und ohne Rücksicht auf die Organisationshierarchie erledigt wird. Wäre dies nicht der Fall, könnten viele unserer Unternehmen zusammenbrechen.
Ein Ansatz besteht darin, zu versuchen, alles in die Prozessvorgaben zu zwingen. Aus der Sicht eines Projektmanagers zeigt dies auch, dass wir uns um die Schnittstellen zwischen den Prozessschritten kümmern müssen. Was passiert eigentlich entlang des Pfeils von einem Schritt zum nächsten? Was tun die Menschen, um einen Mehrwert zu schaffen, der im Prozessfluss nirgendwo dargestellt ist?
Stakeholder intensiv in die Projektplanung einbeziehen
Beziehen Sie die Anwender- und Stakeholder-Gemeinschaft viel stärker in die Entwicklung des Projektumfangs ein. Der typische Ansatz besteht darin, dass Business- und Systemanalysten Fragen stellen, Anforderungen entwerfen und diese dann mit den Stakeholdern abstimmen. Die Risiken sind bekannt: Anwender liefern eine schlecht durchdachte Wunschliste und fügen dann während des gesamten Entwicklungszyklus ständig neue Punkte hinzu oder ändern ihre Meinung.
Ein typischer Projektumfang definiert fünf Elemente: Was, Warum, Wie, Wann und Wie viel. Die Definition dessen, was das Projekt erreichen soll – bekannt als Project Statement –, ist entscheidend. Es muss das Endprodukt prägnant beschreiben, und zwar so, dass der Anwendergemeinschaft klar wird, was sie erhält, und den Erstellern (uns), was wir produzieren müssen.
Die richtigen Worte – oder Bilder – in dieser Phase zu finden, ist extrem wichtig. Es ist auch nützlich, die Stakeholder-Gruppe an der Erstellung des Projektstrukturplans zu beteiligen. Während es kontraproduktiv sein kann, sie in jedes Detail einzubeziehen, gibt ihnen ihre Anwesenheit bei der Festlegung der wichtigsten Ergebnisse ein Verständnis dafür, was wie gebaut werden soll, und dient als nützlicher Realitätscheck.
Projektziele (Warum machen wir das?) sind häufig selbst eine Quelle für Scope Creep, insbesondere wenn wir uns zu Ergebnissen verpflichten, die das Projekt allein nicht liefern kann.
Eine einfache Technik, die Sie für einen Realitätscheck und zur Hinterfragung von Anforderungen einsetzen können, ist die 5-Why-Methode. Die 5-Why-Methode hat ihren Ursprung bei Toyota in Japan und sollte die Ursache eines Problems aufdecken. Die Idee dahinter ist, dass man durch fünfmaliges aufeinanderfolgendes Fragen nach dem „Warum“ den Wissensstand erhöht, den man für eine Lösung benötigt, indem man den Kern des Problems versteht, das das Unternehmen zu lösen versucht.
Worin besteht das Problem?
Wir können die neue Serverkapazität nicht rechtzeitig installieren.
Warum?
Es gibt Beschränkungen für die Anzahl der Maschinen pro Rack
Warum?
Die erzeugte Hitze ist hoch
Warum?
Verwendung von Maschinen älterer Bauart
Warum?
Weil die vorherige Generation eine hohe Stabilität bietet
Dieses kurze Beispiel zeigt, dass unsere Herausforderung darin besteht, die bewährte Stabilität beizubehalten, wir aber einen Weg finden müssen, die Kapazität schnell zu erhöhen. Es hilft auch, den Fokus weg von der Suche nach mehr Platz für Serverfarmen hin zu dem Versuch zu lenken (vielleicht), Maschinen zu identifizieren, die die gleiche Betriebszeit bei geringerer Wärmeentwicklung liefern können.
Es ist nicht immer der Fall, dass fünf „Warum“ ausreichen. KT befürwortet das, was es „Hinterfragen bis ins Leere“ nennt – mit anderen Worten, die Frage so lange zu wiederholen, bis man sicher ist, dass man alle verfügbaren Informationen oder Ideen ausgeschöpft hat.
Die 5-Why-Methode ist auch nützlich, um die Hintergründe der genannten Anforderung zu ergründen:
Wir müssen unsere CRM-Datenbank mit dem System für das regulatorische Meldewesen verbinden
Warum?
Wir benötigen Einblick in meldepflichtige Beschwerden, wenn wir mit neuen Kundenanfragen zu tun haben
Warum?
Wir wollen sicherstellen, dass die technische Beratung angemessen ist
Natürlich werden Sie die Formulierungen variieren, um nicht wie ein Papagei zu klingen: „Was hat Sie zu diesem Bedarf geführt?“ „Inwiefern hilft Ihnen das weiter?“
Ereignisse managen
Risikomanagement wird von jeder Instanz im Projektmanagement befürwortet, einschließlich des Project Management Body of Knowledge. In der Realität konzentrieren sich Risikoprotokolle jedoch zu oft auf greifbare, offensichtliche Risiken wie „Serverausfall“ oder „Gebäudebrand“ und versäumen es, die spezifischen Projektherausforderungen tief genug zu untersuchen. Beim Management des Projektumfangs kommt es darauf an, sich sowohl auf Chancen als auch auf Risiken zu konzentrieren und alle potenziellen Abweichungen vom Umfang auf die gleiche Weise zu behandeln.
Unser Ziel sollte es sein, ein kontinuierliches Verständnis dafür zu entwickeln, wie Veränderungen um uns herum unser Projekt beeinflussen oder verbessern können. Für das Management des Projektumfangs ist das Geschäftsumfeld die Kategorie von Risiko/Chance, die am meisten Beachtung finden sollte, sowie die Ereignisse innerhalb und außerhalb der Organisation, die uns dazu veranlassen könnten, unsere Meinung über Anforderungen zu ändern.
Führen Sie wöchentliche Sitzungen zu Problemen, Risiken und Chancen mit den Stakeholdern durch. Unpraktisch? Nein – vor allem dann nicht, wenn Sie ein einfaches Framework verwenden und das Meeting oder den Call auf 30 Minuten begrenzen. Die Schlüsselfragen lauten stets:
Welche Probleme sehen Sie, die in irgendeiner Verbindung mit diesem Projekt stehen?
In welcher Weise?
Was ist die aktuelle (tatsächliche) Auswirkung dieser Probleme, falls vorhanden?
Was ist die potenzielle (zukünftige) Auswirkung?
Listen Sie die spezifischen Risiken, wahrscheinlichen Ursachen und potenziellen Maßnahmen auf
Listen Sie die spezifischen Chancen, wahrscheinlichen Ursachen und potenziellen Maßnahmen auf
Wählen Sie aus, welche Risiken und Chancen Sie –
– vorerst ignorieren
– genau beobachten
– aktiv angehen
Annahmen sichtbar machen
Jedes Projekt basiert auf vielen Annahmen. Diese können interne und externe Märkte, Lohnsätze, verfügbare Technologien, regulatorische Beschränkungen, Margen für Produkte und Dienstleistungen und sogar die Art des Geschäfts betreffen. Der Projektumfang muss wahrscheinlich angepasst werden, wenn sich eine der Annahmen wesentlich ändert. Ein Frühwarnsystem kann uns helfen, die Störungen besser zu bewältigen.
Im Extremfall bedeutet eine grundlegende Änderung der Annahmen, dass das Projekt beendet werden muss. Je schneller wir das erkennen, desto besser, um die Verschwendung von Ressourcen zu reduzieren. Im vorangegangenen Beispiel des technischen Support-Teams war eine zentrale Annahme – dass qualifiziertes Personal verfügbar und kostengünstig ist –, die damals zutraf, heute weniger gültig. Und die Umstände können sich erschreckend schnell ändern.
Die Liste der Ideen ist nicht erschöpfend, aber dies sind sechs Dinge, die Sie und Ihr Projektteam schnell und mit wenig zusätzlichem Aufwand tun können.
Beim Management des Projektumfangs geht es vor allem darum, auf die kleinen Dinge zu achten. Die Anzeichen dafür, dass sich die Dinge ändern, sind überall um uns herum, wenn wir uns entscheiden, sie zu hören und zu sehen.