Wie steuern wir den Scope? Und wie validieren wir ihn? Auch dieses Kapitel ist stark „klassisch-lastig“, also wenig agil. Änderungen sind in agilen Umgebungen „Build-In“ und erfordern daher keinerlei Change Request oder ähnliches.
Kurze Erinnerungshilfe
Hier geht es um Änderungen am Inhalt und Umfang.
Kommen neue Liefergegenstände hinzu, „verbreitert“ sich die WBS. Es handelt es sich wahrscheinlich um eine Änderung.
Merksätze
Änderungen müssen dokumentiert werden, auch sehr kleine.
Änderungen folgen einem festgelegten Prozess.
Änderungen bedürften in der Regel einer Freigabe.
Nach genehmigten Änderungen muss auch die Dokumentation angepasst werden.
Auch nicht genehmigte Änderungen müssen dokumentiert werden.
Ein weiterer wichtiger Punkt rund um das Scope-Geschehen ist die
Kurze Erinnerungshilfe
Abnahme der Liefergegenstände = Verifizierung der Leistung
Meilensteine (oder andere Checkpunkte) und die Abnahme von Teilleistungen dienen im Verlauf des Projekts dazu, zu wissen: Sind wir gut unterwegs? Tun wir das richtige?
Verifizierung der Leistung
Welcher Liefergegenstand sollte in welchem Status an welchem Checkpunkt wie vorliegen?
Welche Kriterien müssen zu welchem Zeitpunkt erfüllt sein?
Genaue Beschreibung, am besten in messbaren Größen.
Die Beschreibung erfolgt in einer sehr frühenPhase.
Allgemeine Merksätze sind gut, müssen jedoch u.U. projektindividuell angepasst werden.
Die fertigen Liefergegenstände definieren die Projektleistung.
Der Stand der Fertigstellung soll sich an definierten Meilensteinen zeigen.
Die Kriterien, nach denen die Fertigstellung beurteilt wird, sind früh und gemeinsam festzulegen.
Die Abnahme im Werkvertrag nach §631 ff BGB folgt noch weiteren Regeln.
Abnahme ist nicht nur die Abnahme am Projektende, sondern auch zu Meilensteinen.
Reflektionsfragen
Welchen Zweck haben die Prozesse Validate Scope und Control Scope?
Und wie unterscheiden sie sich?
Was ist Scope Creep und warum ist er gefährlich? Welche Rollen kann die Scope Baseline dabei spielen?
Was tun Sie, wenn sich der Scope mitten im Projekt ändern soll (oder muss)?
Zum Themenkomplex einer WBS gehören eine Reihe von Begriffen, die verstanden werden müssen.
MCP oder CA
Ein MCP ist ein Management Control Point und ein CA ist ein Control Account. Mögen die Projektcontroller einen Unterschied zwischen den beiden machen – das PMP-Examen macht es nicht.
Also was sind MCPs oder CAs?
Kumulative Stellen in der WBS, auf die kontiert oder rückgemeldet werden (aus Controlling Sicht). Wenn ein Projekt 1000e von Elementen enthält (nicht selten), dann ist es aus Steuerungssicht meist nicht sinnvoll, alle 1234 Elemente in das Controllingtool einzugeben, sondern eben nur die MCPs/CAs.
In der nachfolgenden Graphik ist eine WBS angedeutet (auf einem virtuellen Whitebord wie z.B. Miro) und die rosa „Knoten“ würden in diesem Falle dem Controlling als MCP dienen.
Folgende Begriffe rund um die WBS dürfen für Sie zu diesem Zeitpunkt kein Buch mit sieben Siegeln mehr sein:
WBS
PSP
WBS Dictionary / PSP-Strukturplanverzeichnis
Control Account (CA)
Management Control Point (MCP)
100%-Regel
Decomposition
Zerlegung
Scope Baseline
Könnten Sie jeden dieser Begriffe erklären? Und wissen Sie, wo bzw. wann er genutzt wird?
Das Scope Statement ist ein ganz wichtiger Schritt in der Projektdefinition. Und die Liefergegenstände ein wichtiger Teil des Scope Statements.
Kurze Erinnerungshilfe
Definition: Ein eindeutiges und überprüfbares Produkt. Also etwas sehr konkretes.
Merksätze zur Übersetzung/Umwandlung von Zielen in Liefergegenstände:
Unter Liefergegenständen versteht man sehr konkrete Beschreibungen der Ergebnisse, die am Projektende „abgeliefert“ werden sollen. Das sind aber meist nicht die Ziele des Sponsors, sondern der Weg dorthin.
Zu Beginn des Projektes ist es sinnvoll und notwendig, gemeinsam die Übersetzung von Zielen in Liefergegenstände vorzunehmen und zu fixieren. Wird dies versäumt, läuft das Projekt Gefahr, sich von Anfang an in eine falsche Richtung zu entwickeln.
Nach der gemeinsamen Festlegung verantwortet der Projektleiter primär die Liefergegenstände.
Werfen wir einen genaueren Blick auf das Scope Statement
Kurze Erinnerungshilfe
Die Projektumfangsbeschreibung
Inhalt
Ziele
Liefergegenstände
Annahmen
Einschränkungen
Qualitätsanforderungen
…
Gilt für kleine und große Projekte gleichermaßen
Merke:
Es muss eine Vereinbarung zwischen Sponsor und Projektleiter geben.
Nicht in Details verlieren.
Wichtig: Was gehört zum Umfang des Projekts, was nicht.
Das Scope Statement ist kein Projektplan.
Budgets, Zeiten und andere Dinge werden nur zur Kenntnis genommen oder als Rahmenbedingungen genannt, aber an dieser Stelle nicht verpflichtend vereinbart.
Reflektionsfragen
Welchen Zweck hat das Scope Statement?
Welche Werkzeuge und Methoden können Sie einsetzen, um das Scope Statement zu entwickeln?
Was ist der Unterschied zwischen Requirement, Liefergegenstand und Ziel?
Wenn Sie von Ihrem Projekt ein Scope Statement anfertigen sollten, wie viele Seiten hätte dieses?
Was ist der Unterschied zwischen Annahmen und Einschränkungen?
Was sind Requirements (Anforderungen) und wie werden Sie am Besten in die Projektarbeit übersetzt.
Kurze Erinnerungshilfe
Können zu Zielen oder zu Liefergegenständen (Deliverables) führen.
Im PMBOK Guide nicht auf dem Niveau von Requirements Engineering.
Im agilen Bereich sind User Stories (fast) Requirements.
Zentrales Werkzeug und Dokument: Requirements Traceability Matrix (RTM).
Der Requirementscartoon – Das „Schaukelbild“
Arten von Requirements
Die Business Analyse, die sich ja zentral mit dem Thema Requirements auseinandersetzt, kennt acht verschiedene Arten von Requirements:
Business Requirements
Stakeholder Requirements
Solution Requirements
Functional Requirements
Nonfunctional Requirements
Transition Requirements
Project Requirements
Quality Requirements
Die Traceability Matrix
Ein ganz wichtiges Werkzeug im Zusammenhang mit Requirements ist die Requirement Tracebility Matrix. Wurde oben im Video bereits erläutert, an dieser Stelle nochmals die Betonung auf die Übersetzungstabelle zwischen Anforderungen einerseits und Projektarbeit andererseits.
Willkürlich einfaches Beispiel
Auch wenn die RTM einfach aufgebaut ist, erlaubt sie doch eine Rückverfolgung der ursprünglich angedachten Anforderungen zur tatsächlichen Projektarbeit.
Reflektionsfragen
Was ist ein Requirement, eine Anforderung und ein Liefergegenstand?
Wie finden Sie die Anforderungen für Ihr Projekt heraus?
Welche Rollen spielen die Projektstakeholder bei den Requirements?
Was ist eine Anforderungsrückverfolgbarkeitsmatrix und welchen Zweck hat sie?
Zum Weiterlesen
Process Groups Practice Guide, Prozess 5.3 – Collect Requirements
PMI Practice Guide: Business Analysis for Practitioners
Diskussion und Illustration der unterschiedlichen Zielebenen. Es ist wichtig, dass beide Parteien (Sponsor und Projektleitung) ihre beiden Seiten und ihre beiden Ebenen und die Inhalte kennen. Der Projektleiter wird nur sehr seltendirekt die Ziele des Sponsors erfüllen können.
Kurze Erinnerungshilfe
Verschiedene Zielebenen am Beispiel der Safari
Ziele des Projektauftraggebers
Nutzen soll sich entfalten
Leidensdruck „Pain“ soll nachlassen
Business Case sich erfüllen
Projektmanager übersetzen diese Auftraggeberziele in Projektziele
Liefergegenstände:
Konkrete Lieferungen am Ende des Projekts
sollen dafür sorgen, die Ziele des Auftraggebers zu erreichen und
liegen in der Verantwortung des Projektleiters.
Es gibt also zwei Zielebenen: Sponsor (Nutzen etc.) und Projektverantwortung(Liefergegenstände)
Reflektionsfragen
Warum ist diese Übersetzung der Ziele erforderlich?
Was passiert, wenn der Sponsor seine Ziele dem Projektleiter als dessen Liefergegenstände vorgibt?
Was würde passieren, wenn Sie im Reisebüro die garantierte Sichtung von 3 Nashörnern im Vertrag verlangen würden?
Versuchen Sie in Ihrem Umfeld diese Übersetzungen zu sehen und bewerten Sie den Projekterfolg guter Übersetzungen und schlechter Übersetzungen.
Was ist ein Managementplan? Und speziell ein Inhalts- und Umfangsmanagementplan?
Kurze Erinnerungshilfe
Scope Management Plan: Wie wollen wir den Scope in diesem Projekt managen? In einem Scope Management Plan werden Spielregeln vereinbart. Diese könnten unter anderem sein: Nehmen wir spezielle Tools? Wer kümmert sich um was? Wie gehen wir mit Änderungen um?
Keine Requirements, Liefergegenstände oder Ziele.
Einer von vielen Managementplänen, die gemeinsam den Projektmanagementplan bilden.
In Managementplänen steht nie das „Was“ sondern immer nur das „Wie“.
Reflektionsfragen
Ist Ihnen ganz klar, dass in einem ScopeManagement Plan kein Scope drin steht?
Sondern?
Welchen Zweck hat der Scope Management Plan?
Wie hängt der Scope Management Plan mit dem Project Management Plan zusammen?
Zum Weiterlesen
ProcessGroupsPracticeGuide (PGPG), Prozess 5.2 – Planning Process Group
Scope wird im deutschen mit Inhalt und Umfang übersetzt. Interessant, dass es hierfür in unserer Sprache zweier Begriffe bedarf.
Es geht also um die Frage, was denn (genau?) im Projekt gemacht wird. Also der Inhalt.
Und es geht um die Frage, wo die Grenzen des Projekts verlaufen. Was ist drin, was ist nicht drin. Der Umfang.
Damit hängt der Scope eng an den Themengebieten Ziele, Anforderungen, Benefit, die wir an anderer Stelle behandeln. Scope ist von diesen Themengebieten aber abhängig, da es die Ziele eines Vorhabens konkretisiert. Bei der Konkretisierung ist der erste Schritt: Festlegen der Liefergegenstände. Welche Liefergegenstände erfüllen die Ziele?
Dann wird die Konkretisierung detaillierter, es gibt die Arbeitspakete. Welche Arbeitspakete machen die Liefergegenstände aus?
Diese werden nochmals in Aktivitäten zerlegt. Welche Aktivitäten erledigen ein Arbeitspaket?
Wenn das alles richtig gemacht wurde, werden alle Ziele erreicht, wenn alle Aktivitäten erledigt wurden. Das ist die Logik. In der Praxis ist das aber schwer genug, weswegen wir hier etwas näher auf die einzelnen Schrittfolgen eingehen.
Klassischer Ansatz
Selbst im klassischen Projektansatz entstehen viele Missverständnisse – und im agilen Ansatz nicht weniger. Betrachten wir im nachfolgenden Video erst einmal die klassische Denke:
Agiler Ansatz
Die komplette Zerlegung des klassischen Ansatzes hat eine Grundvoraussetzung: Das Endprodukt ist weitgehend bekannt und lässt sich dadurch und vorher (in der Planung) bereits gut umreißen und zerlegen.
Ist das Produkt eher unbekannt, wird erst „im letzten Moment zerlegt“. Daher sind Änderungen wesentlich einfacher zu integrieren. Und der agile Ansatz kennt nicht annähernd so viele „Artefakte“ rund um das Scoping wie der klassische Ansatz.
Begriffsübersicht
Wir betrachten die Themen- und Begriffswelt:
Ziele / Nutzen / Vision
Ziele sind das, worauf die Arbeit und das Projekt hin ausgerichtet sind. Eine angestrebte strategische Position, ein herzustellendes Produkt oder eine zu erbringende Dienstleistung.
Im agilen Kontext spricht man dabei oft von Vision statt von Ziel.
Ziele gehören eher dem Auftraggeber/ Sponsor / Product Owner
Liefergegenstände / Deliverables
Ein eindeutiges und überprüfbares Produkt/ Ergebnis/ Dienstleistung, das/die hergestellt bzw. erbracht werden muss, um einen Prozess/ Phase/ Projekt vollständig abschließen zu können.
Merke: Anhand der Liefergegenstände wird festgestellt, ob ein Projekt (oder Phase oder Prozess) erfolgreich abgeschlossen wurde. Dazu müssen Liefergegenstände validiert und abgenommen werden.
Liefergegenstände gehören dem Projektleiter.
Anforderungen /Requirements
Anforderungen beschreiben die Bedingungen oder Fähigkeiten, die ein Produkt, eine Dienstleistung oder ein Ergebnis erfüllen muss. Sie werden in einem Vertrag oder einer sonstigen formal vorgegebenen Spezifikation festgehalten. Dazu werden die Stakeholderbedürfnisse und -anforderungen, die zum Erfüllen der Projektzielvorgaben notwendig sind, identifiziert, dokumentiert und gemanagt.
Merke: Anforderungen müssen erfüllt werden, um eine Zielvorgabe zu erreichen.
Requirements kommen typischerweise vom (End)Kunden, vom User, der das Produkt oder die Dienstleistung tatsächlich einsetzt.
Einschränkungen (oder auch Beschränkungen) / Constraints
Ein einschränkender Faktor, der die Durchführung eines Projekts, Programms, Portfolios oder Prozesses beeinflusst.
Merke: Nicht änderbare Rahmenbedingungen von außen, die berücksichtigt werden MÜSSEN und dadurch den Scope beeinflussen.
Annahmen / Assumptions
Ein Faktor im Planungsprozess, der als wahr, real oder sicher erachtet wird.
Merke: Annahmen müssen nicht zwingend zu- oder eintreffen. Es kann schwierig sein, sich alle Annahmen (oder zumindest die wesentlichen) bewusst zu machen. Von vielen Annahmen gehen wir unbewusst aus. Und verschiedene Stakeholder könnten auch verschiedene Annahmen haben.
Annahmen sind auch eine gute Quelle für Risiken, wenn die Annahmen einfach umgedreht werden. Was, wenn nicht?
Scope Management Plan / Inhalts- und Umfangsmanagementplan
Eine Komponente des Projekt- oder Programmmanagementplans, welche beschreibt, wie der Inhalt und Umfang definiert, entwickelt, überwacht, gesteuert und verifiziert wird.
Es geht also nicht um den Scope selbst, sondern wie man ihn erarbeitet und managt.
Beschreibung des Projektinhalts und -umfangs / Project Scope Statement
Die Beschreibung des Projektinhalts und -umfangs, wesentlicher Liefergegenstände, Annahmen und Beschränkungen.
Also alles, was im Projekt „hergestellt“ werden muss – einschließlich des Projektmanagements selbst!
Projektstrukturplan (PSP) / Work Breakdown Structure (WBS)
Eine hierarchische Zerlegung des gesamten Inhalts und Umfangs. Die durch das Projektteam auszuführenden Arbeiten, um die Projektziele zu erfüllen und die erforderlichen Liefergegenstände zu erstellen.
Bis runter zur Ebene der Arbeitspakete. Eine ordentliche und korrekte WBS ist die wesentliche Voraussetzung für die weitere Planung des Projekts; einschließlich Terminen und Kosten. Die WBS bildet sozusagen eine der Seiten des Magischen Dreiecks ab. Was nicht in der WBS ist, ist nicht im Projekt!
Inhalts- und Umfangsbasisplan / Scope Baseline
Die genehmigte Version einer Inhalts- und Umfangsbeschreibung sowie eines Projektstrukturplans (PSP/WBS) und des damit verbunden PSP-Verzeichnisses. Die kann nur mittels formeller Änderungssteuerungsverfahren geändert werden und dient als Ausgangsbasis für Vergleiche.
Im Unterschied zum Inhalts- und Umfangsmanagementplan oben, sind in diesem Plan tatsächlich Inhalte festgeschrieben. Dieser Basisplan ist auch wichtig, um z.B. Scope Creep, den schleichenden Inhalts- und Umfangszuwachs, zu erkennen.
Ihre Aufgabe: Verstehen
Am Ende des Tages müssen Sie alle obigen Begriffe voneinander differenzieren können und sattelfest bestimmen. Und versuchen Sie doch einmal in Ihrer realen Projektumgebung, diese unterschiedlichen Artefakte zu identifizieren. Vielleicht steht nur nicht der Name drauf, den PMI oder das PMP-Examen verwendet.
Vielleicht steht da ein ganz anderer Begriff drauf. Aber Sie sollten wissen, was drin ist.
