Aktualisieren Sie Ihr Projektstrukturplan-Dokument, nachdem die Anforderungen definiert wurden?

Ich denke, hier liegt ein Frame-Missverhältnis vor, und ich glaube nicht, dass die Frage maßgeblich beantwortet werden kann, wenn die Frames nicht geklärt sind. Meine Diskussion unten zielt ganz ausdrücklich darauf ab, OP nicht in Frage zu stellen oder mit ihm zu streiten. Die Art und Weise, wie Sie Projekte verwalten, ist die Art und Weise, wie Sie Projekte verwalten, und sollte nur danach beurteilt werden, wie effektiv Sie damit Projekte abschließen können. Das heißt, wenn ich schreibe und es widersprüchliche Annahmen gibt, besteht die einzige Möglichkeit, die Frage zu beantworten, darin, meine Annahmen zu artikulieren und dann auseinander zu nehmen, wo sich die Methoden unterscheiden.

(Nebenbei: Ich vermute , dass die Antwort darauf lautet, dass es wie bei vielen PMI-Prozessen einen ständigen Dialog zwischen den Prozessgruppen gibt. Der Grund für die schwierige Planung ist, dass die Erstellung des WBS die Notwendigkeit von mehr Klarheit und Präzision in den Anforderungen hervorheben kann. Das Klärung kann dann eine Überarbeitung des WBS erzwingen, dies muss aber im Rahmen des Change Managements erfolgen).

OP schreibt:

Wenn ich „WBS“ schreibe, meine ich ein organisationsstrukturähnliches Dokument, das Ergebnisse und Arbeitspakete auflistet (und nicht die Spalte „Aufgabenname“ in MS Project). Normalerweise wird dies verwendet, um die Arbeit vor der Definition von Anforderungen während der Analysephase zu initialisieren.

In der Projektmanagementmethodik werden Anforderungen in einen PSP zerlegt; Dadurch wird sichergestellt, dass 100 % der Arbeit geplant und geschätzt wird. Die Arbeit wird nicht initialisiert, bis die Planung abgeschlossen ist und die Planung auf Anforderungen basiert.

Siehe die PMI-Prozessgruppen ; Die Erstellung des WBS erfolgt sehr früh in der Planungsphase und vor der Ausführungsphase.

Bei der Projektinitiierung muss der Projektmanager die Gründe verstehen, warum das Projekt initiiert wurde, die Ziele definieren, die das Projekt erreichen soll, und die Metriken, die verwendet werden, um seinen Erfolg zu messen. Diese werden als „Geschäftsanforderungen“ bezeichnet, die die Anforderungen der Organisation als Ganzes (nicht von Gruppen oder Stakeholdern darin) und den Geschäftswert beschreiben, den das Projekt liefern soll. Die richtige Identifizierung dieser Anforderungen gibt dem Projekt den richtigen Start. PMI-Bibliothek

Wenn der PSP alle zur Durchführung des Projekts erforderlichen Arbeiten darstellen soll, muss der PSP auf den Anforderungen basieren/von diesen abgeleitet werden. Wenn Sie den PSP vor dem Erstellen der Anforderungen erstellen, gibt es keine Möglichkeit sicherzustellen, dass der PSP die gesamte Arbeit enthält. Ich weiß nicht, wie ich Leistungen identifizieren soll, wenn ich die Anforderungen nicht kenne; Es sollte eine Rückverfolgbarkeit von jedem Arbeitspaket und jeder Leistung bis zu einer Anforderung geben. OP folgt eindeutig einer anderen Methodik mit einer anderen Rückverfolgbarkeit - aber es ist mir sehr unklar, wie sich das auf das PMI-Framework bezieht.

Ausgehend von diesem Rahmen-Missverhältnis würde mich nichts, was ich über Projektmanagement gelernt habe, in die Lage versetzen, nützliche Ratschläge zu einer Methodik zu geben, bei der der WBS den Anforderungen vorausgeht.

Ich habe versucht, eine knappe Antwort zu geben (ich kämpfe darum, knapp zu sein, und scheitere häufig). Ich brauche mehr Zeit, um auf den unten festgehaltenen Kommentar einzugehen; Ich glaube, dies ist eine sehr wichtige Beobachtung, aber ich glaube derzeit , dass sie tangential zu der Frame-Nichtübereinstimmung zwischen der Frage von OP und meiner Antwort steht. Ich glaube, dass OP-Annahmen über die Reihenfolge der Anforderungen und den WBS sich von meinem Verständnis der Projektmanagementmethodik unterscheiden.

Besteht die Arbeit nicht darin, die Anforderungen zu erfassen und zu entwickeln, was Konstruktionsentwürfe, Architekturzeichnungen und sogar Proof-in-Concept-Vorprodukte umfassen kann? Ich würde erwarten, dass ein sehr detaillierter WBS für diese Arbeit mit einigen WBS – Elementen höherer Ebene – und Planungspaketen für die verbleibende Arbeit entwickelt werden kann. @DavidEspina

Um auf diesen Kommentar zu antworten, muss ich den Prozess der Projektinitiierung besprechen. Das riskiert, argumentativ zu werden. Meine vorherige Antwort besagt lediglich, dass OP und ich die beiden Prozesse unterschiedlich anordnen und dass die unterschiedlichen Annahmen die Beantwortung der Frage erschweren - sie hebt die Rahmenherausforderung für weitere Analysen hervor. Um auf den Kommentar zu antworten, muss ich diskutieren, was ich als den "orthodoxen" Projektinitiierungsprozess betrachte, der den Prozess von OP zu kritisieren scheint.

Dies wird durch die Tatsache weiter erschwert, dass meiner Meinung nach die Projektinitiierung einer der kritischen Fehler des modernen Projektmanagementmodells ist. Ich würde mich freuen, wenn mich jemand korrigiert/erzieht; Ich würde mich sehr freuen, wenn ich falsch liege.

Eine große Anzahl der initiierenden Prozesse wird normalerweise außerhalb des Kontrollbereichs des Projekts durch die Organisation, das Programm oder die Portfolioprozesse durchgeführt, und diese Prozesse liefern Input für die Gruppe der initiierenden Prozesse des Projekts. pmi.org

Das PMI-Projektmodell ist ein bisschen wie eine Physikdiskussion über das Universum vor dem Urknall – das einzig verbindliche, was gesagt werden kann, ist „Das ist außerhalb des Modells“ – was eine formelle Aussage darüber ist, dass dann ein Wunder geschieht .

Bei einem meiner früheren PMOs haben wir fünf verschiedene analytische Produkte/Prozesse definiert, die vor der Projektinitiierung abgeschlossen werden mussten. Die Projektcharta musste durch einen Business Case unterstützt werden, der durch ein formelles Kostenmodell unterstützt werden musste, das durch eine unendliche Regression von Schildkröten unterstützt werden musste , die jeweils vom CxO unterzeichnet werden mussten. Ich begann zu vermuten, warum > 50 % der PMOs innerhalb eines Jahres scheitern. Unsere haben es getan. Herauszufinden, wie man das klar erklärt, ist nicht wichtig, um die grundlegende Frage von OP zu beantworten. Die Antwort darauf lautet: „Das Erstellen des WBS vor den Anforderungen ist ein neuartiger Ansatz, und nichts in der PMI-Methodik ist hilfreich“.

Ich werde noch etwas darüber nachdenken und versuchen, zurückzukommen und prägnant und reaktionsschnell zu sein.

Durch einen Change-Management-Prozess können sich der PSP und andere Baseline-Artefakte des Performance-Managements ändern, wenn eine Änderung eintritt. Während viele zu implizieren scheinen, dass Änderungen nicht auftreten, wenn Sie nicht agil arbeiten, treten Änderungen mit anderen Bereitstellungsmethoden auf. Viele Dienstleister würden ihren WBS vor Beginn der Arbeit entwickeln, und die Arbeit kann zusätzliche Arbeit an den Anforderungen beinhalten, um zu einer Anforderungsbaseline zu gelangen – Sie können es endgültig oder was auch immer nennen, aber die Baseline kann sich ändern. Wenn sich die Anforderungen erheblich ändern oder weiterentwickeln, kann dies zu einer entsprechenden Änderung des WBS und anderer PMBs führen. Wenn Ihr Veränderungsprozess den Anschein erweckt, dass eine solche Veränderung zu mühsam ist, dann ist Ihr Veränderungsprozess kaputt.

In Bezug auf PBS versus WBS würde ich Ihnen raten, PBS aus Ihrem PM-Repertoire zu entfernen. Sie können einen produktorientierten WBS einrichten, ein einziges Projektartefakt haben, nur ein einziges Artefakt aktualisieren und müssen sich nicht darum kümmern, dass die beiden Produkte übereinstimmen und zugeordnet werden.

Ein "Projektstrukturplan" ist für mich: "Hauspläne". Mit anderen Worten: "Wagen Sie nicht, ein Haus ohne sie zu bauen." PSP-Dokumente, die erstellt werden, bevor die Anforderungen "abgeschlossen" wurden, sind bestenfalls Arbeitsdokumente ... und raten Sie mal, das Wort "abgeschlossen" könnte immer formbar sein. Also geht es. Aber der WBS sollte ein Leitfaden sein.

Der „Arbeitsstrukturplan“ versucht, zumindest eine Strategie auf hoher Ebene darzulegen, was getan werden muss, in welcher Reihenfolge und welche Mitglieder/Fähigkeiten sowohl innerhalb als auch außerhalb des Teams einzubeziehen sind . Meiner Meinung nach sollte es ständig auf dem neuesten Stand gehalten und sorgfältig mit den tatsächlichen Fortschritten (oder deren Fehlen) verglichen werden. "Natürlich kann man es nicht gleich beim ersten Mal richtig machen", aber die Änderungen können sehr aufschlussreich sein. Halten Sie das Ganze auf dem neuesten Stand, auch wenn Sie beobachten, „was Sie richtig gemacht haben und was nicht“.

All dies – insbesondere einschließlich aller Überarbeitungen (!) und der vollständigen Chronologie davon – sollte Teil der permanenten Geschichte des Projekts werden, und Sie sollten es ex post facto sorgfältig auf „Lessons Learned“ überprüfen.

Besonders(!) in Computersoftwareprojekten ist es für die Arbeiter sehr leicht, sich "von Bäumen umgeben zu finden", so dass sie sich fragen: "In welchem ​​Wald bin ich überhaupt? Ich habe es vergessen." Es sind einfach so viele Details, die alle technisch beachtet werden müssen, dass „der totale ‚Arbeitszusammenbruch‘“ verloren geht. Dieses Dokument kann also „der schmale Faden“ sein, der Sie wieder nach Hause führt.

„Einsamer-Wolf“-Entwickler, die sich daran gewöhnt haben, „einzutauchen und es zu tun“, müssen möglicherweise die Vorzüge von „Schauen, bevor du springst“ aufgezeigt werden. Solche Dinge sind ihnen nicht immer selbstverständlich.

Deshalb: Überarbeiten Sie den WBS sofort, nachdem das Projekt grünes Licht erhalten hat, halten Sie ihn dann auf dem neuesten Stand und verwenden Sie die Versionskontrolltechnologie, um jede einzelne Version davon zu erhalten. ("Dito" alle Anforderungsdokumente.) Lassen Sie es immer die genaueste Darstellung von: "The Big[gest] Picture.™" sein und bewahren Sie sorgfältig seine fortlaufende Geschichte.

Wenn Sie einen PSP verwenden, sollten Sie ihn meiner Meinung nach so häufig wie möglich aktualisieren.

Du hast nicht erwähnt, um was für eine Arbeit es sich handelt. Wenn der Kontext Softwareentwicklung ist, dann ist ein WBS normalerweise keine gute Idee. Softwareentwicklungsteams arbeiten in der Regel besser mit einem PBS- oder Product-Backlog-basierten Ansatz als mit WBS. Außerdem können Anforderungen nicht als „endgültig“ angesehen werden, bis Sie sich entscheiden, die Verwendung des Softwareprodukts einzustellen.