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 Kreis¹⁾ 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 Projektnummern müssen global eindeutig sein, und es muss die Möglichkeit geben, sie fortlaufend und lückenlos zu erzeugen,
• Projekte müssen frei verschiebbar sein, innerhalb eines Hauptprojektes, und auch zwischen Hauptprojekten,
• 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 ersten 3 Regeln sagen nichts anderes, als dass es eine globale Projektstruktur geben muss. Nur so kann man diese Regeln konsistent einhalten. Da eine Projektanlage aber ein Punkt ist, bei dem die Konsistenz absolut vorrangig ist, wird der Anwender verstehen, wenn es dort eventuell zu Zeitverzögerungen kommen kann²⁾.

Die letzten beiden Punkte besagen, dass Änderungen innerhalb eines Projektes aber nicht global serialisiert werden dürfen. Sobald ein Projekt angelegt wurde, sollten Änderungen maximal innerhalb des Projektes serialisiert werden. Die globale Projektstruktur bestimmt also nur die Position des Projektes im Baum. Jedes Projekt hat dann wiederum eine eigene Projektstruktur für Produkte, Arbeitspakete und Aufgaben|Vorgänge.