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

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
applications/prom/workbreakdownstructure.1361959242.txt.gz · Last modified: 2013/02/27 11:00 by rtavassoli