Value Breakdown Structure (VBS)

Ziel

Der PMBOK Guide definiert die Value Breakdown Structure (VBS) als hierarchische Struktur, die den Projektumfang und seinen erwarteten Wert mit dem Produktumfang verknüpft, der diesen Wert erzeugt (§2.2.1). Abschnitt 5 beschreibt sie als PSP, in dem jedes Element eine Schätzung seines Werts trägt.

Ein PSP sagt, was das Projekt liefert und was jeder Teil kostet. Er sagt nicht, was jeder Teil einbringt. Ohne diese Angabe weiss das Team weder, welches Lieferobjekt es bei knappem Budget opfert, noch, was eine gewonnene Woche wert ist. Stephen Devaux hat die Methode aus dieser Feststellung heraus entwickelt. Für ihn ist ein Projekt eine Investition. Das klassische Projektmanagement verfolgt die investierte Summe und lässt den Wert beiseite, den diese Summe erzeugen soll.

Mit der VBS entscheiden Auftraggeber und Team, welche Elemente obligatorisch sind, welche optionalen Elemente ihre Kosten wert sind und was es einbringt, ein Element auf dem kritischen Pfad zu beschleunigen. Die Technik liefert einen Baum der Lieferobjekte. Jeder Knoten trägt einen Status (obligatorisch oder optional) und einen Wertbeitrag. Nach dem PMBOK Guide zerlegt das Team jedes Blatt dieses Baums über den PSP. Der Guide schreibt für diese Verbindung keine Form vor. Eine Traceability-Matrix dokumentiert sie: Sie ordnet jedes Blatt den Arbeitspaketen zu, die es erzeugen.

Einsatz

Wann einsetzen

• Bereits bezifferter Nutzen: Der Business Case nennt einen Wert in Franken oder in messbaren Einheiten, der sich bis auf die Lieferobjekte herunterbrechen lässt.
• Budget oder Termin zwingt zum Kürzen: den Umfang nach dem Wert jedes Elements sortieren.
• Datumsabhängiger Wert: beziffern, was eine Woche Verzug kostet, wenn das Projekt auf einen saisonalen Start, eine regulatorische Frist oder Einsparungen ab der Inbetriebnahme zielt.
• Abwägung auf dem kritischen Pfad: entscheiden, ob man einen kritischen Vorgang gegen Bezahlung beschleunigt oder aus dem Umfang streicht.
• Projekt, von dem ein Programm abhängt: Jede Woche Verzug in diesem Projekt verzögert den Wert des ganzen Programms.
• Lieferant zum Festpreis auf dem kritischen Pfad: die Prämie für vorzeitige Fertigstellung beziffern, die in den Vertrag gehört.

Wann nicht einsetzen

• Kein bezifferter Wert vom Auftraggeber: Werte, die das Team allein schätzt, erzeugen eine Scheingenauigkeit; mit MoSCoW priorisieren (siehe Priorisierung).
• Vollständig vorgegebener Umfang: nichts abzuwägen; die Zeit mit dem Critical Path Drag beziffern.
• Adaptiver Ansatz ohne PSP: Das nach Wert geordnete Product Backlog übernimmt diese Rolle in jeder Iteration.

Beschreibung

Die Elemente

Der Knoten ist ein Lieferobjekt oder ein Teil-Lieferobjekt. Man benennt ihn als Ergebnis ("Online-Einreichung der Rechnungen") statt als Tätigkeit ("Einreichungsmodul entwickeln"). Die oberste Ebene versammelt die Hauptlieferobjekte, die die Stakeholder gemeinsam besprochen und festgelegt haben (PMBOK Guide, §2.2.1).

Der Wertbeitrag schätzt, was das Element zum Projekt beiträgt. Der PMBOK Guide lässt zwei Formen zu: eine Zahl in der Werteinheit des Projekts oder einen Prozentsatz seines erwarteten Gesamtwerts. Ein Unternehmen rechnet in Umsatz oder Einsparungen. Der Guide nennt auch gerettete Leben und Kinder, die lesen lernen.

Der Status ordnet das Element ein. Ein obligatorisches Element ist eines, ohne das das Projekt weder Sinn noch Wert hat. Devaux zählt das Element, das ein Gesetz oder eine interne Regel vorschreibt, zur selben Klasse. Sein Wertbeitrag entspricht dem des ganzen Projekts. Der PMBOK Guide notiert ihn mit 100%. Ein optionales Element bringt Wert, doch das Projekt kommt auch ohne es aus. Sein Wert ist der Wert des Projekts mit dem Element abzüglich des Werts ohne das Element.

Devaux zeigt das an einem Haus. Ohne Badezimmer erhält das Haus keine Bezugsbewilligung und ist nichts wert: Das erste Badezimmer ist obligatorisch und trägt die 200'000 Dollar des Hauses (100%). Das zweite Badezimmer ist 40'000 Dollar wert: die Differenz im Verkaufspreis zwischen einem Haus mit einem Badezimmer und einem Haus mit zwei.

Devaux geht von der MoSCoW-Methode aus. Aus Must wird obligatorisch. Should und Could werden optional und erhalten einen bezifferten Wert. Won't bleibt ausserhalb des Umfangs.

Werte lassen sich nicht addieren

Im PSP entsprechen die Kosten eines Elternelements der Summe der Kosten seiner Kinder. Für den Wert gilt diese Regel nicht. Ein Kleinflugzeug wird für 100'000 Dollar verkauft. Seine beiden Flügel sind obligatorisch und je 100'000 Dollar wert. Das Flügelpaar ist trotzdem nicht 200'000 Dollar wert. Zwei Elemente können sich auch überschneiden: Zusammen sind sie dann weniger wert als die Summe beider. Sie können sich umgekehrt verstärken und die Summe übertreffen.

Eine Krankenkasse baut ein Online-Portal für Rückerstattungen. Der Business Case des Portals beziffert die Einsparungen auf CHF 23'000 pro Betriebswoche: CHF 5'980'000 über fünf Jahre.

Die Kosten der Kinder ergeben die CHF 300'000 des Elternelements. Ihre Werte ergeben CHF 6'240'000 und übersteigen damit den Wert des Elternelements. Eine Wertsumme, die den Baum hinauf berechnet wird, ist deshalb falsch. Das Team schätzt mit dem Auftraggeber den Wert des Elternelements selbst.

Die Struktur aufbauen

1. Die Hauptlieferobjekte erheben. Die Stakeholder besprechen sie und legen sie gemeinsam fest. Sie bilden die oberste Ebene (PMBOK Guide, §2.2.1). Sie stammen aus dem Business Case, dem Projektauftrag oder der Umfangsbeschreibung.
2. Jedes Lieferobjekt mit dem Auftraggeber einstufen. Abschnitt 5 des PMBOK Guide liefert den Test: Ein Element ist obligatorisch, wenn sein Wegfall den Wert des Projekts auslöscht.
3. Den Wertbeitrag schätzen. Ein obligatorisches Element erhält 100%. Ein optionales Element erhält die Wertdifferenz zwischen dem Projekt mit dem Element und dem Projekt ohne das Element. Auftraggeber, Kunde oder Investor liefern diese Zahlen. Die Analystin ordnet sie den Lieferobjekten zu.
4. Zerlegen. Das Team teilt jedes Lieferobjekt in Teil-Lieferobjekte und gibt ihnen nach denselben Regeln einen Status und einen Wert. Die Zerlegung endet, wenn der Auftraggeber über jedes optionale Element einzeln entscheiden kann. In der Küche seines Hauses unterscheidet Devaux eine obligatorische Spüle von einem optionalen Geschirrspüler.
5. Mit den Arbeitspaketen verbinden. Jedes Blatt zerfällt über den PSP in Arbeitspakete und Vorgänge (PMBOK Guide, §2.2.1). Die funktionale Dekomposition beschreibt diesen PSP und seine Regeln.
6. Wert und Kosten gegenüberstellen. Ein optionales Element bleibt im Umfang, wenn sein Wert seine Kosten übersteigt. Das Team beurteilt den obligatorischen Umfang als Block. Der erwartete Gesamtwert enthält bereits alle Optionen. Übersteigen die Kosten des obligatorischen Umfangs diesen Wert, macht keine Auswahl an Optionen das Projekt rentabel.
7. Den kritischen Pfad beziffern. Für jedes Element auf dem kritischen Pfad die Drag Cost schätzen und mit den Kosten einer Beschleunigung oder eines Wegfalls vergleichen.
8. Überarbeiten. Die Werte neu schätzen, wenn sich der Business Case ändert oder der Termin der Inbetriebnahme sich verschiebt.

Die Drag Cost auf dem kritischen Pfad

Der Wert eines Projekts hängt oft von seinem Termin ab. Devaux nennt das Beispiel einer ferngesteuerten Schneefräse. Steht sie drei Tage vor dem ersten Wintersturm im Laden, soll sie 25 Millionen Dollar einbringen. Jede Woche Verzug kostet 10% dieses Umsatzes.

Abschnitt 5 des PMBOK Guide definiert zwei Begriffe, die diese Empfindlichkeit beziffern. Der Critical Path Drag ist die Zeit, die ein kritischer Vorgang der Projektdauer hinzufügt. Man liest ihn am Netzplan der Methode des kritischen Pfades ab. Die Drag Cost ist der Rückgang der erwarteten Rendite des Projekts, den dieser Drag verursacht. Das Team schätzt diese Kosten für jedes Element auf dem kritischen Pfad aus den Wertbeiträgen der Struktur (§2.2.1).

Für ein Element auf dem kritischen Pfad schlägt Abschnitt 5 vor zu prüfen, ob ein anderer Plan mehr einbringt: Das Element zu beschleunigen oder zu streichen kann mehr einbringen, als es kostet.

Die Drag Cost allein entscheidet nichts. Ohne die automatische Rechnungserkennung geht das Portal vier Wochen früher in Betrieb. Dabei geht mehr Wert verloren, als gewonnen wird.

Ein Projekt, von dem ein ganzes Programm abhängt, trägt den Wert dieses Programms. In einem Beispiel von Devaux ist eine Brücke der einzige Zugang zur Baustelle eines Hotelkomplexes. Der Komplex soll 3,5 Millionen Dollar pro Woche einbringen. Jede auf der Brücke gewonnene Woche ist diesen Betrag wert. Baut ein Unternehmer die Brücke zum Festpreis, empfiehlt Devaux, für jede Woche vorzeitiger Fertigstellung eine substanzielle Prämie in den Vertrag zu schreiben.

Fallstricke

Werte addieren. Die Summe der Knoten übersteigt den Wert des Projekts schnell und erreicht manchmal ein Mehrfaches davon. Eine Tabellenkalkulation, die Werte wie Kosten aufsummiert, liefert eine Summe, die niemand lesen sollte. Die Kontrolle: keine Summenformel in der Wertspalte.

Das Team die Werte erfinden lassen. Devaux stellt fest, dass der erwartete Wert fast nie bis zur Projektleitung und zum Team gelangt, selbst wenn die Geschäftsleitung oder der Auftraggeber ihn beziffert hat. Ein Team, das diese Lücke füllt, baut den Baum auf eigenen Vermutungen. Die Zahlen kommen vom Auftraggeber, vom Kunden oder vom Investor. Ein Wert, der nicht von dort kommt, trägt den Namen seines Urhebers und den Vermerk "Annahme".

Alles für obligatorisch erklären. Jeder Stakeholder verteidigt sein Lieferobjekt. Ein Baum ohne optionales Element fügt dem PSP nichts hinzu. Der Test aus Abschnitt 5 entscheidet: Behält das Projekt seinen Wert ohne das Element, ist das Element optional.

Wert und Kosten verwechseln. Ein Team, das die Kosten eines Elements als seinen Wert übernimmt, kann die Optionen nicht mehr unterscheiden: Jede ist genau so viel wert, wie sie kostet. Der Wert wird auf der Seite der Nutzer oder des Auftraggebers gemessen: Umsatz, Einsparung, vermiedenes Risiko.

Vor dem PSP aufhören. Eine Struktur, die nicht bis zu den Arbeitspaketen reicht, steuert die Arbeit nicht. Ein Arbeitspaket, das kein bewertetes Blatt rechtfertigt, fügt Kosten hinzu, ohne Wert hinzuzufügen. Die Traceability-Matrix macht diese nicht verlangte Zugabe sichtbar (Gold Plating).

KI-Überlegungen

Ein Sprachmodell entwirft einen ersten Baum aus einem PSP, einem Projektauftrag oder einem Business Case. Es formuliert Tätigkeiten als Lieferobjekte um. Es vergleicht die Struktur mit dem PSP und listet die Arbeitspakete ohne bewertetes Blatt auf. Es findet in einer Tabellenkalkulation die Formeln, die Werte addieren. Es schreibt die Formeln, welche die Drag Cost und die Abwägungen neu berechnen; die Tabellenkalkulation rechnet. Für jedes optionale Element bereitet es die Fragen an den Auftraggeber vor.

Die Werte bleiben Sache des Auftraggebers. Ein Modell erzeugt plausible Zahlen. Niemand steht für sie ein. Für den Status obligatorisch gilt dasselbe. Die Zahlen des Business Case sind vertraulich. Bei einer Krankenkasse betreffen die Leistungsdaten die Gesundheit: Das nDSG zählt sie zu den besonders schützenswerten Personendaten (Art. 5 Bst. c). Die Organisation legt fest, welche dieser Zahlen und Daten an einen gehosteten Dienst gehen dürfen und zu welchen Bedingungen. Alle anderen bleiben intern.

Beispiele

Im Portal der Krankenkasse reicht die versicherte Person ihre Arztrechnungen online ein.

Drei obligatorische Elemente tragen je CHF 5'980'000. Die automatische Rechnungserkennung trägt nur ihren Zuwachs. Wer die Knoten der ersten Ebene addiert, erhält CHF 18'460'000 für ein Projekt von CHF 5'980'000.

Visualisierungen

Die Traceability-Matrix ordnet jedes Blatt der Struktur den Arbeitspaketen des PSP zu. Die letzte Zeile zeigt ein Paket, das kein Blatt rechtfertigt.

Aufwand

Werkzeuge

Für die meisten Projekte genügt eine Tabellenkalkulation. Jede Zeile enthält ein Element mit Code, Elternelement, Status, Wertbeitrag, Kosten und den Codes seiner Arbeitspakete. Eine Kontrollspalte meldet jede Formel, die Werte addiert.

Eine Planungssoftware wie MS Project oder Primavera P6 führt den Wert in einem benutzerdefinierten Vorgangsfeld. Sie berechnet den Netzplan und die Pufferzeiten. Den Drag berechnet sie nicht. Das Team leitet ihn von Hand aus dem Netzplan ab (siehe Critical Path Drag). Ein Diagramm- oder Mindmap-Werkzeug zeichnet den Baum für den Workshop mit dem Auftraggeber.

Quellen

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8. Aufl., PMI: die Definition der VBS, ihre oberste Ebene, die zwei Formen des Wertbeitrags, die 100% eines obligatorischen Lieferobjekts, die Verwendung zum Priorisieren und zum Schätzen der Drag Cost, die Zerlegung über den PSP (§2.2.1); die VBS als bewerteter PSP, der Test des obligatorischen Elements und die Prüfung eines anderen Plans mit höherem Ertrag (Abschnitt 5, Eintrag "Hierarchical charts"); der Critical Path Drag und seine Kosten (Abschnitt 5, Einträge "Critical path drag" und "Critical path drag cost").
• Stephen A. Devaux, "The Value Breakdown Structure (VBS): What, How and Why?", Total Project Control, 3. April 2015: der Übergang von MoSCoW zu den Status, obligatorische und optionale Elemente, die fehlende Additivität der Werte, die Beispiele des Flugzeugs, des Hauses und der Schneefräse.
• Stephen A. Devaux, "How to Determine the Expected Value of Those Crucial Enabler Projects!", Total Project Control, 2. Juli 2015: das Beispiel der Brücke und das Projekt, von dem ein Programm abhängt.
• Stephen A. Devaux, Total Project Control: A Practitioner's Guide to Managing Projects as Investments, 2. Aufl., CRC Press, 2015: die vollständige Darstellung der Methode durch ihren Urheber. Er hat sie 1999 in der 1. Auflage eingeführt.

Stephen Devaux hat die VBS entwickelt und bleibt ihre einzige ausführliche Quelle. Der PMBOK Guide behandelt sie in zwei Absätzen.