Welcher englische Begriff passt im Projektmanagement besser für größere WBS-Elemente: Work Package, Work Stream oder eine Alternative?

**Für größere WBS-Elemente ist _work package_ meist **nicht** der passendste Begriff; _work package_ bezeichnet im Projektmanagement eher ein klar abgegrenztes, plan- und verantwortbares Arbeitspaket auf niedrigerer WBS-Ebene. Für größere Blöcke sind meist _deliverable_, _summary element_, _control account_ oder – je nach Logik – _workstream_ passender.** ## Der entscheidende Unterschied Eine **WBS** ist grundsätzlich **ergebnisorientiert**, nicht tätigkeitsorientiert. Deshalb ist **work package** normalerweise das **untere, ausführbare Element** der WBS: etwas, das man schätzen, terminieren, budgetieren und einer verantwortlichen Person oder Einheit zuordnen kann. **Workstream** ist etwas anderes: Das Wort wird oft für einen **thematischen oder funktionalen Arbeitsstrang** benutzt, der sich auch **quer durch mehrere WBS-Zweige** ziehen kann. Genau deshalb ist es als Bezeichnung für ein großes WBS-Element oft unsauber. Kurz gesagt: - **work package** = eher **kleiner, konkret planbarer WBS-Baustein** - **workstream** = eher **organisatorischer oder fachlicher Strang**, nicht zwingend ein WBS-Element ## Was für größere WBS-Elemente meist besser passt Wenn du **oberhalb des Work Packages** benennen willst, sind diese Begriffe meist präziser: - **deliverable** gut, wenn das Element ein **konkretes Ergebnis/Produkt** beschreibt Beispiel: _Reporting Platform_, _Training Materials_, _Migration Concept_ - **summary element** gut als **neutraler Oberbegriff** für ein übergeordnetes WBS-Element - **control account** passend, wenn du im eher formalen PM-/EVM-Kontext ein Element zwischen höherer WBS-Ebene und Work Packages meinst, an dem Kosten, Termine und Verantwortung zusammenlaufen - **subproject** passend, wenn der Block faktisch wie ein **eigenes Teilprojekt** geführt wird - **component** oder **module** gut bei technischen, produktnahen Strukturen - **phase** nur dann passend, wenn du **zeitliche Abschnitte** meinst – nicht WBS-Hierarchie ## Wann _workstream_ trotzdem richtig ist **Workstream** ist sinnvoll, wenn du nicht die WBS-Hierarchie beschreiben willst, sondern die **Steuerungslogik**. Beispiel: Ein Transformationsprojekt hat die Workstreams: - Process - Technology - Change - Governance Innerhalb jedes Workstreams kann es dann eigene Deliverables und Work Packages geben. Der wichtige Unterschied: **Ein Workstream ist oft eine Management-Sicht auf die Arbeit, keine saubere WBS-Ebene.** ## Praktische Empfehlung Wenn du in einem **klassischen PM-Kontext** über **größere WBS-Elemente** sprichst, ist diese Benennung am saubersten: - **WBS Level oben:** _deliverables_ / _summary elements_ - **untere Ebene:** _work packages_ Wenn du eher die **inhaltlichen Arbeitsstränge** eines großen Programms meinst, nimm: - **workstreams**, aber **nicht** als Synonym für große WBS-Elemente ## Die beste Kurzformel **In einer WBS heißt das große Element meist nicht _work package_, sondern eher _deliverable_ oder neutral _summary element_; _workstream_ passt nur, wenn du bewusst einen fachlichen Steuerungsstrang statt einer WBS-Hierarchie meinst.**