C0110

Begriffe rund um Scope (1097)

Um was geht’s?

Nachfolgend eine Übersicht von gängigen Begriffen rund um das Thema Inhalt und Umfang (Scope). In Deutsch und in Englisch.

Reflektionsfragen
  • Können Sie jeden der unten stehenden Begriffe zuordnen?
  • Gibt es einen Begriff, den Sie noch nie gehört haben?
 Definitionen englisch – deutsch
Acceptance CriteriaAbnahmekriterien
Accepted DeliverablesAbgenommene Liefergegenstände
Approved Change RequestGenehmigter Änderungsantrag
Approved Change Requests ReviewPrüfung genehmigter Änderungsanträge
AssumptionAnnahme
Assumption AnalysisAnalyse von Annahmen
BaselineBasisplan
Business CaseBusiness Case
Business ValueGeschäftlicher Wert
Change ControlÄnderungssteuerung
Change Control BoardSteuerungsgremium für Änderungen
Change Control SystemÄnderungssteuerungssystem
Change Control ToolsWerkzeuge zur Änderungssteuerung
Change LogÄnderungsprotokoll
Change RequestÄnderungsantrag
CharterAuftrag
Collect RequirementsAnforderungen sammeln
ConstraintEinschränkung, auch Beschränkung
Control ScopeInhalt und Umfang steuern
Create WBSProjektstrukturplan (PSP) erstellen
Define ScopeInhalt und Umfang definieren
DeliverableLiefergegenstand
Planning PackagePlanungspaket
ProductProdukt
Project CharterProjektauftrag
Project ScopeProjektinhalt und -umfang
Project Scope ManagementInhalts- und Umfangsmanagement in Projekten
Project Scope StatementBeschreibung des Projektinhalts und -umfangs, (auch Pflichtenheft)
RequirementAnforderung
Requirements DocumentationDokumentation der Anforderungen
Requirements Management PlanAnforderungsmanagementplan
Requirements Traceability MatrixAnforderungs-Rückverfolgbarkeits-Matrix
Rolling Wave PlanningRollierende Planung
ScopeInhalt und Umfang
Scope BaselineInhalts- und Umfangsbasisplan
Scope ChangeInhalts- und Umfangsänderung
Scope CreepInhalts- und Umfangszuwachs, (schleichend)
Scope Management PlanInhalts- und Umfangsmanagementplan
SponsorSponsor
WBS DictionaryPSP-Verzeichnis
Work Breakdown Structure (WBS)Projektstrukturplan (PSP)
Work Breakdown Structure ComponentProjektstrukturplankomponente
Work PackageArbeitspaket

Copyright Gita GmbH. Alle Rechte vorbehalten.

Änderungen und Abnahmen (1096)

Um was geht’s?

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ühen Phase.
  • 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 Weiterlesen

PMBOK Guide, 6.Ausgabe

  • Prozess 5.5 – Inhalt und Umfang validieren
  • Prozess 5.6 – Inhalt und Umfang steuern

Copyright Gita GmbH. Alle Rechte vorbehalten.

WBS-Begriffe (1095)

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?


Copyright Gita GmbH. Alle Rechte vorbehalten.

Vom Liefergegenstand zur WBS (1094)

Um was geht’s?

Was ist ein Projektstrukturplan und wie erstellt man ihn?
Schauen wir uns das Schritt für Schritt an.



Kurze Erinnerungshilfe
  • Sie machen erst im Projekt weiter, wenn die Liefergegenstände geklärt und mit den Zielen des Sponsors abgestimmt sind.
  • Dann werden die Liefergegenstände in Arbeitspakete zerlegt. Sozusagen vom Liefergegenstands- „Molekül“ hin zum Arbeitspaket- „Atom“.
  • Merke: Die Summe der Arbeitspakete müssen den jeweiligen Liefergegenstand VOLLSTÄNDIG beschreiben.
  • Ein Arbeitspaket ist eine managbare Einheit von Arbeit:
    • deren Erledigung Sie klar feststellen können,
    • die Sie einer (verantwortlichen) Stelle (Person/Organisationeinheit) zuweisen können,
    • auf deren Ebene Schätzungen (z.B. für Kosten, Zeit) erfolgen können.
  • Ein Arbeitspaket darf nicht
    • weggelassen werden, nur weil Sie niemanden finden, der sich darum kümmert.
    • unscharf sein, weil nicht klar ist, was passieren soll.
    • mit zeitlichen Restriktionen oder Abhängigkeiten in Verbindung gebracht werden. Das kommt später im Netzplan.
  • Es geht erst einmal nur um die Zerlegung der Arbeit, sonst nichts.

Die klassische Methode, um vom Liefergegenstand zum Arbeitspaket zu kommen, ist:


Kurze Erinnerungshilfe
  • Eine an den Liefergegenständen orientierte Zerlegung von Arbeitspaketen
  • WBS = Work Breakdown Structure ist synonym mit PSP = Projektstrukturplan
  • AP = Arbeitspaket = WP = Work Package
  • Verschiedene Darstellungsformen sind möglich.
  • Eine gelebte WBS verändert sich im Laufe des Projektfortschritts.
  • Kommen weitere Liefergegenstände hinzu, ist das in der Regel ein Change.
  • 100%-Regel: Die Summe der Nachfolger eines Elements müssen den Vorgänger (Knoten) vollständig beschreiben.
  • Eine gut aufgestellte WBS zerlegt den Liefergegenstand zum Arbeitspaket so, dass
    • „nur“ die Endelemente (Arbeitspakete) die komplett zu leistende Arbeit abbilden.
    • nach der Zerlegung besser geschätzt und geplant werden kann.
  • Die WBS ist für Sie als Projektleiter das wichtigste Werkzeug überhaupt, da sie die Grundlage für viele weitere Planungsschritte ist.

Reflektionsfragen
  • Warum soll überhaupt zerlegt werden?
  • Was ist der Sinn der mehrstufigen Zerlegung?
  • Was passiert, wenn ein Arbeitspaket vergessen wurde?
  • Was gehört alles in die WBS hinein?
  • Was ist mit Elementen, die nicht in der WBS sind?
  • Bis zu welchem Punkt brechen Sie die WBS herunter? Wann ist es genug?
  • Was ist Rolling Wave Planning und wie steht diese in Zusammenhang mit der WBS?
  • Ist eine weitere Dekomposition zu einem späteren Zeitpunkt ein Change Request?
  • Was ist ein Basisplan im Vergleich zu einem Managementplan?
  • Wie ist der Inhalts- und Umfangsbasisplan (Scope Baseline) aufgebaut und aus was besteht er?
Zum Weiterlesen

ProcessGroupsPracticeGuide, Prozess 5.5 – Create WBS

PMI Practice Standard for Work Breakdown Structures

Bei PMI gibt es außerdem den Practice Standard for Work Breakdown Structures. Dieser beschreibt die WBS im Detail.


Copyright Gita GmbH. Alle Rechte vorbehalten.

Scope Statement und Liefergegenstände (1093)

Um was geht’s?

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:
    1. 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.
    2. 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.
    3. 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?
Zum Weiterlesen

ProcessGroupsPracticeGuide, Prozess 5.4 – Define Scope


Copyright Gita GmbH. Alle Rechte vorbehalten.

Requirements (1201)

Um was geht’s?

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
  • PMI Practice Guide: Requirements Management:

Copyright Gita GmbH. Alle Rechte vorbehalten.

Ziel ist nicht gleich Ziel (1199)

Um was geht’s?

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 selten direkt 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 ZielebenenSponsor (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.

Copyright Gita GmbH. Alle Rechte vorbehalten.

Scope Management Plan (1092)

Um was geht’s?

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


Copyright Gita GmbH. Alle Rechte vorbehalten.

Business Analysis (1200)

Um was geht’s?

Die Frage nach dem Zweck, Ziel und Nutzen eines Projekts wird in der Disziplin der Business Analyse beantwortet.



Kurze Erinnerungshilfe
  • Ziele der Business Analysis
    • Problembereiche, Geschäfsbedarfe und neue Produktfelder identifzieren.
    • Machbare Lösungen hierfür aufzeigen.
    • Anforderungen der Marktteilnehmer herausarbeiten, um das richtige Produkt zu entwickeln.
    • Die Markteinführung des entwickelten Produkts begleiten.
  • Businessanalyse erweitert den Projektrahmen, schafft die Klammer
    • Zum Projektanfang
      • Business Need?
      • Requirements?
      • Business Case?
    • Während des Projekts
      • Entspricht Produktentwicklung (=Projekt) immer noch dem Business Need?
    • Zum Projektende:
      • Markteinführung
      • Nutzenprüfung
  • Wer ist Businessanalyst?
  • Es dreht sich alles um Requirements

Das PMI & die Businessanalyse – wie gehören die zusammen?


Kurze Erinnerungshilfe
  • Wie ist das Thema bei PMI verortet?
    • Global Standard „Business Analysis for Practitioners – Practice Guide“.
    • PMI ist Platzhirsch in Sachen Projektmanagement.
    • Aber: PMBOK Guide beantwortet die Fragen rings um das Projekt (Gründe und Nutzen) nicht.
    • Es gibt andere Anbieter für die Beantwortung dieser Fragen, also für die Businessanalyse.
    • Der eigene Practice Guide ist die PMI-eigene Antwort.
  • Der Practice Guide beschreibt 40 Punkte, an denen Projektleiter und Analyst zusammenarbeiten (können).
    • Nicht für das Examen notwendig.
    • Überfliegen kann aber nicht schaden.

Schauen wir uns zum Schluss noch mal an, welche Gebiete die Businessanalyse umfasst.


Kurze Erinnerungshilfe
  • Needs Assessment (vor dem Projekt)
    • Ergebnis: Der Business Case
  • Business Analysis Planning (vor dem Projekt)
    • Die Planung des Ansatzes an sich (Spielregelplanung)
    • Ergebnis: Der Business Analysis Plan
  • Requirements Elicitation (vor dem Projekt)
    • Wie finden wir Anforderungen?
  • Tracebility & Monitoring (während des Projekts)
    • Wie wird sichergestellt, dass die Anforderungen auch umgesetzt werden?
  • Solution Evaluation (nach Projektende)
    • Ist der versprochene Nutzen eingetreten?

Reflektionsfragen
  • Was genau ist Business Analysis?
  • Wie hängen Business Analysis und Projektmanagement zusammen?
  • Warum ist es für Projektleiter sinnvoll, die Businessanalyse zumindest in Grundzüge zu kennen?
  • Welche Rolle(n) kann ein Business Analyst in einem Projekt haben?
  • Wie heißen die Business Analysten in Ihrer Organisation?

Zum Weiterlesen
  • ProcessGroupsPracticeGuide (PGPG), Kapitel 5
  • PMI Business Analysis Practice Guide

Copyright Gita GmbH. Alle Rechte vorbehalten.

Der Scope-Kontext (1091)

Um was geht’s?

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.

Blog

Es gibt es auch noch einen Magazinartikel, der ebenfalls einige wichtige Elemente rund um den Scope beschreibt und einen kleinen Test mit Ihnen macht:
http://magazin.wuttke.team/viel-scope-viel-plan-ein-kleiner-test/

Nach oben scrollen