User Tools

Site Tools


applications:prom:workbreakdownstructure

This is an old revision of the document!


Der Projektstrukturplan

Es gab eine lange Suche nach dem richtigen Modell für die Projektstruktur. Das CAP Theorem sagt uns ja, dass man immer nur maximal 2 von 3 gewünschten Zielen erreichen kann: Konsistenz, Verfügbarkeit, Partitionstoleranz. In der Suche nach der optimalen Projektstruktur habe ich mich immer wieder im Kreis1) gedreht, weil mal die Konsistenz der Schwerpunkt der Analyse war, dann die Partitionstoleranz, dann die Verfügbarkeit.

Hier sind die Regeln, die eingehalten werden müssen, und die zur letztendlichen Struktur geführt haben:

  • Die Projektstruktur muss immer konsistent sein. Es darf also in der Baumstruktur keine Zirkelbezüge geben, und ein Projekt darf nicht mehrmals im Baum erscheinen. Die zweite Regel betrifft die Domäne, sie kann im Lesemodell aufgelockert werden, solange dadurch kein Schaden entsteht2),
  • Die Projektnummern müssen global eindeutig sein, und es muss die Möglichkeit geben, sie fortlaufend und lückenlos zu erzeugen,
  • Projekte müssen innerhalb eines Hauptprojektes frei verschiebbar sein, am besten auch zwischen Hauptprojekten3),
  • Ein Projektleiter muss Teilprojekte anlegen können und diese komplett an Teilprojektleiter abgeben können,
  • Wenn Teilprojektleiter an ihren Projekten arbeiten, soll dieses unabhängig voneinander geschehen, d.h. dass der Projektstrukturplan pro Teilprojekt isoliert von den anderen Projektstrukturplänen verwalten und gestalten werden können muss.

Die Lösung wird im folgenden Bild dargestellt: Was hat das auf sich? Relativ einfach:

  • Ein neues Hauptprojekt entspricht einem neuen PSP vom Typ Projekt. Das bedeutet, dass das oberste Objekt im PSP ein Projekt sein muss. Innerhalb des Strukturplans kann man weitere Element anlegen. Der Plan ist dabei für die Struktur zuständig, die Objekte4) werden lediglich referenziert,
  • Auf einer Ebene dürfen immer nur Elemente desselben Typs liegen. Unter Projekt-ID 1.1 gibt es 3 Teilprojekte. Unter Produkt-ID 1.1.1.1 im Teil-PSP Produkt-PSP 1.1.1.1 gibt es 3 Arbeitspakete. Der PSP kann diese Regel sicher stellen,
  • Ein Strukturelement im PSP kann auch ein Teil-PSP sein. In dem Bild ist z.B. das Produkt 1.1.1.1 unter Projekt 1.1.1 ein eigenständiger PSP. Dieser ist fest vom Typ Produkt, muss also ein Produkt auf oberster Ebene haben. Der Produkt Teil-PSP hat wiederum ein Teil-PSP vom Typ Arbeitspaket. Auf diesem Weg kann man Teilaufgaben komplett an jemanden anderes delegieren, der den Teil-PSP dann unabhängig und isoliert von den anderen bearbeiten kann,
  • Strukturelemente können innerhalb eines PSPs frei verschoben werden. Dabei müssen lediglich die festgelegten Regeln eingehalten werden, nämlich keine Vermischung von unterschiedlichen Elementen auf einer Ebene, sowie keine Zirkel in der Struktur. Da sich das alles im PSP-Aggregate abspielt, ist das kein Problem.
1) besser im CAP Dreieck
2) Die erste Regel ist in Stein gemeißelt. Zirkelbezüge, auch temporäre, sind für das Lesemodell Gift, und für sie kann nur schwer kompensiert werden, bzw. korrigiert werden
3) aber nicht zwingend. Die bisherigen 4 Kunden leben seit 10 Jahren damit, dass das nicht geht
4) Teilprojekte, Produkte|lieferbare Ergebnisse, Teilaufgaben, Arbeitspakete, Aktivitäten
applications/prom/workbreakdownstructure.1361962743.txt.gz · Last modified: 2013/02/27 11:59 by rtavassoli