Zurück zur Methodenübersicht

Projektstrukturplanung

Projektstrukturplanung: Basis

Einleitung Projektstrukturplanung

Im Projektstrukturplan (PSP) als “Mutter aller Pläne” wird die Arbeit beschrieben, die erforderlich ist, um die Projektziele - insbesondere die Leistungsziele - zu erreichen. Wie in einem Puzzle ergibt die Summe aller Ergebnisobjekte einzelner Arbeitspakete des PSP die Leistungsziele des Projekts. Deshalb muss hier die Projektleitung für Konsistenz sorgen zwischen den Zielen und der notwendigen Arbeitsergebnissen der einzelnen Arbeitspakete.

In aller Regel ist es sehr empfehlenswert, sich die erforderlich Arbeit nicht selbst im Elfenbeinturm auszudenken, sondern den wesentlichen Teil des PSPs von den Fachleuten erstellen zu lassen, die sich mit der Arbeit meist viel besser auskennen und die viel motivierter an die Arbeit gehen, wenn sie ihre Arbeit selbst und vor allem realistisch planen durften.

Die Projektleitung ist vor allem dazu da, das methodische Rüstzeug zu liefern und zum Beispiel zu erklären, nach welchen Gliederungsprinzipien man die Arbeitspakete gliedern kann und mit welchen Vor- und Nachteilen die verschiedenen Gliederungsprinzipien verbunden werden. Wichtig ist in aller Regel auch, gewisse Vorbehalte bei den Fachleuten zu überwinden, was die nähere Beschreibung der einzelnen Arbeitspakete angeht. In diesem Kapitel werden der Projektleitung Argumente geliefert, wie man mit möglichen Widerständen (“Soll ich arbeiten oder Formulare ausfüllen”) argumentativ und psychologisch am besten umgehen kann.

Mit Projektstrukturplan und Arbeitspaketbeschreibung lückenlose und redundanzfreie Abdeckung der Ziele ermöglichen

Ein Projektstrukturplan (PSP) gliedert wie ein „Puzzle“ die Gesamtaufgabe (Projekt) hierarchisch in Teilaufgaben und Arbeitspakete.

Im Projektstrukturplan werden die für den Kunden interessanten Endergebnisse (Deliverables, Lieferobjekte) aus den Zielen für die laufende Projektarbeit in in sich abgeschlossene Zwischenergebnisse aufgeteilt. In Summe ergeben die Zwischenergebnisse die gewünschten Endergebnisse. Jedes Arbeitspaket fasst die Einzelaktivitäten zusammen, die für so ein Zwischenergebnis notwendig sind – am besten beschrieben durch eine Arbeitspaketspezifikation. Ein Arbeitspaket beschreibt insofern eine in sich geschlossene Aufgabenstellung innerhalb des Projekts, die von einem Arbeitspaketverantwortlichen

  • alleine,
  • im Team oder
  • von einer organisatorischen Einheit bis zu einer Deadline mit klar definierten Lieferobjekten, Aufwänden/Kosten und definierbaren Fortschrittsgraden erarbeitet werden kann.

⚠️ Ein Arbeitspaket wird im Projektstrukturplan nicht weiter unterteilt und ist deshalb das kleinste Element im Projektstrukturplan.

💡 Ich würde den Projektstrukturplan immer mit den Fachleuten erarbeiten, die für die Projektarbeit vorgesehen sind. Insofern würde ich immer den Prozess der groben Ressourcenplanung erst mal abwarten, bis ich die konkreten Namen der Projektmitarbeiter haben und diese dann zu einem Workshop einladen. In diesem Workshop würde ich den Projektstrukturplan immer zuerst in einer grafischen Struktur erarbeiten, weil das im Team in aller Regel deutlich einfach und flexibler funktioniert als in einer tabellarischen Struktur. Sobald der grafische PSP mehr oder weniger verlässlich steht, spricht je nach verwendeten Templates nichts dagegen, den PSP zum Beispiel in Excel in einer tabellarischen Struktur abzubilden. Gerade, wenn man eher kleinere Projekte verantwortet und die Verwendung von Tools zu aufwändig und/oder teuer erscheint. Mittelfristig empfehle ich zur Verwaltung von Arbeitspaketen natürlich immer die Verwendung von Tools wie MS Project in der Desktop-Version oder MS Planner, der eine Vielzahl nützlicher Sichten gerade für eine effiziente Teamarbeit beinhaltet.

Die Codierung der Elemente, z.B. alphanumerisch, sorgt für fehlerfreie Stundenbuchung auf das korrekte Arbeitspaket. Dafür ist gesorgt, wenn die Codierung des Wurzelelements der Projektnummer entspricht. Ohne eine eindeutige Codierung der Arbeitspakete ist eine exakte Verbuchung der Iststunden auf einzelne Arbeitspakete kaum effizient möglich. Das wiederum reduziert die Aussagekraft des Projektcontrollings stark. Man kann zwar ganz allgemein Abweichungen der aufgelaufenen Istkosten von den Plankosten zum Stichtag darstellen. Aber die naheliegende Frage des Auftraggebers nach den Ursachen von Abweichungen (die meist in einzelnen Arbeitspaketen liegen), kann man nicht schlüssig beantworten.

Anbei die wichtigsten Codierungsprinzipien:

  • Numerische Codierung – Elemente werden fortlaufend nummeriert, ohne inhaltliche Bedeutung der Zahl (z. B. 1, 1.1, 1.2, 2, 2.1).
  • Dezimal-/dekadische Codierung – Hierarchien werden durch Dezimalstellen abgebildet, zum Beispiel 1000 (Wurzelelement, 1100 (Ebene Teilaufgabe), 1110 (Ebene Arbeitspaket oder weiterer Teilaufgabe), 1121 (Arbeitspaket). Vorteil: Bei großen PSPs, die sich auf mehrere Seiten erstrecken, sieht man auf den ersten Blick, ob es weitergeht oder der PSP mit der 1121 an sein natürliches Ende gekommen ist. Im Gegensatz zur numerischen Codierung ist eine niedrigere Gliederungsebene nicht möglich.
  • Alphanumerische Codierung – Kombination aus Buchstaben und Zahlen zur inhaltlichen Unterscheidung von Strukturelementen (z. B. SPM 3.2 steht für Teilaufgabe Konzeption für die dritte Sportmesse).
  • Klassifizierende Codierung – Die Codierung spiegelt Projekt, System, Bauteile und Kunde wieder und werden gerne von der Zulieferindustrie aufgrund ihrer komplexen Lieferketten, mehrerer paralleler Kunden und der großen Variantenvielfalt verwendet. Beispiel: P23-ENG-MTR-045-BMW steht für Projekt 23, System Engineering, Bauteil Motor, Bauteilnummer 045 für den Kunden BMW.

💡 Gründe für einen gut gestalteten Projektstrukturplan und ausreichende Arbeitspaketbeschreibungen:

  • Der Projektstrukturplan dient in erster Linie dazu, den gesamten Projektumfang übersichtlich darzustellen, Verantwortlichkeiten zuzuordnen und die Planung und Steuerung des Projekts zu erleichtern.
  • Ein guter PSP ist die Basis für
    • pragmatische Ablauf- und Terminplanung
    • Feintuning der Ressourcenplanung
    • Präzisere Kostenplanung und damit präziseres Controlling
    • Dokumentation, Strukturierung der Dokumentenablage
    • Risikomanagement bezüglich der Arbeitspakete
    • Reduktion von Mikromanagement
    • Motivationsvergrößerung durch - in der Linie manchmal weniger ausgeprägte - Erfahrungen von Selbstwirksamkeit bei der erfolgreichen Erledigung von Arbeitspaketen
  • Eine gute Arbeitspaketbeschreibung erlaubt eine
    • genauere Schätzung von Aufwand, Dauer und Projektkosten
    • präzisere Fortschrittsgradmessung mit objektiven Verfahren der Fortschrittsgradmessung
    • bessere Kontrolle der Vollständigkeit der Arbeitspakete für die Beschreibung einer Teilaufgabe
    • bessere Kontrolle Doppelzuordnungen von Aktivitäten in verschiedenen Arbeitspaketen (Redundanzfreiheit)
    • begründete Abnahme des Arbeitspakets durch die Projektleitung
    • größere Effizienz durch genau definierte Qualität (nicht nur Mindest- sondern auch Maximal-Qualität)
    • Reduktion von Missverständnissen gerade bei größeren und unbekannten Arbeitspaketen und bei Übergabe der Arbeitspakete bei Personalwechsel Es lassen sich sicher noch mehr Gründe für einen gut gestalteten PSP und gute Arbeitspaketbeschreibungen aufzählen. Nicht umsonst wird der PSP deshalb die Mutter aller Pläne genannt.

Deshalb lohnt sich die Beschäftigung mit PSP-Qualitätskriterien:

Mit Qualitätskriterien für PSP-Aufbau und Arbeitspakete die Strukturplanung deutlich effektiver machen**

  • Lückenlosigkeit bzw. vollständige Abdeckung der Projektziele ohne Goldplating mit ausreichender Beschreibung sicherstellen:
    • Der Abgleich eines PSP mit der Zielhierarchie lohnt sich. Oft fehlen noch erforderliche Arbeitspakete zur Erreichung aller Ziele. Deshalb müssen auch Arbeitspakete von externen Dienstleistern integriert werden, sonst ist der Konsistenzcheck zwischen PSP und Zielen nicht sinnvoll durchführbar. Dieses Kriterium ist in der Regel nur durch eine Beschreibung der Arbeitspakete möglich. Nur mit der Bezeichnung kann die Lückenlosigkeit nicht sichergestellt werden.
    • Eine Arbeitspaketbeschreibung hilft mit eindeutigen Kriterien vor Übererfüllung und Goldplating: Es gibt oft auch Arbeitspakete, die in der Dynamik eines PSP-Workshops ohne expliziten Kundenwunsch entstanden sind nach dem Motto: „Diese Thema wäre doch auch grundsätzlich interessant“. Hier hat die Projektleitung auch die Aufgabe, das magische Dreieck einzuhalten und auch die Erreichung der Kosten- und Terminziele im Blick zu haben: Hier ist oft die Streichung einzelner Arbeitspakete und/oder die Anpassung von Arbeitspaketspezifikationen im Sinne einer  qualitativen Obergrenze zu bedenken. Mit diesem Projektleitungs-Mindset kann Perfektionismus und „Goldplating“ verhindert werden. Diese Neigungen sind manchmal bei intrinsisch bzw. fachlich besonders interessierten Fachspezialistin in ihrer Rolle als Arbeitspaket-Ownern zu beobachten. Auch hier hilft in der Regel nur eine Beschreibung der Arbeitspakete.
  • Redundanzfreiheit bzw. keine Überschneidungen der Arbeitspakete mit ausreichender Beschreibung sicherstellen
    • Doppelarbeiten werden meist durch unklare Arbeitspakete verursacht. Die verschiedenen Arbeitspaketverantwortlichen eines Teams interpretieren in bloße Arbeitspaketbezeichnungen (Beispiel “Konzeption erstellen” oft andere Inhalte hinein als die Teamkollegen.
    • Hilfreich ist hier insbesondere ein Feld “Schnittstellen/Abgrenzung”, durch sich zwei Arbeitspakete mit Überschneidungspotenzial voneinander abgrenzen können.
  • Für Außenstehende verständlicher klarer Aufbau des Projektstrukturplans und verständliche Benennung der Arbeitspakete Der Plan sollte so aufgebaut sein, dass er für Außenstehende nachvollziehbar ist. Dazu trägt nicht klare Strukturierung bei sondern auch verständlich benannte Arbeitspakete. Natürlich muss es erlaubt sein, Fachsprache zu verwenden. Aber die Art der Fachsprache und verwendeten Abkürzungen sollte für die Führungsebene nachvollziehbar sein. In aller Regel wird die Projektleitung zwar nicht auf Grundlage des Projektstrukturplans berichten (in bestimmten Branchen ist das durchaus üblich). Aber zumindest ab und zu wird schon mal der Projektstrukturplan an das Management versendet oder ihm gegenüber präsentiert. Und da ist es kontraproduktiv für eine konstruktive Diskussion und Ideenbildung, wenn ein Großteil der Arbeitspakete vom Management nicht verstanden werden. Hier gilt es, einen sinnvollen Kompromiss zwischen Fachsprache und Verständlichkeit zu finden.
  • Sinnvolle individuell passende Größe von Arbeitspaketen: Arbeitspakete können je nach Bedarf lang, kurz, umfangreich, wenig umfangreich sein (siehe Extrakapitel zum Arbeitspaket mit Größentipps). Dabei gilt aus meiner Sicht immer das Primat des Projekts und der Projektleitung. Manchmal wird vom Controlling gefordert, alle Arbeitspakete zu einer Standardgröße kleinzuschneiden, damit man sie mit bestimmten Standardverfahren (z.B. der 50-50 Methode) effizient kontrollieren kann. Davon halte ich wenig. Am wichtigsten für die Projektarbeit ist aus meiner Sicht ein individuell passend zugeschnittenes Arbeitspaket. Und erst danach überlege ich mir, wie ich das jeweilige Arbeitspaket mit einer individuell passenden Methode messen kann.

💡 Ein PSP sollte als „Mutter aller Pläne“ nicht zu Gunsten eines Gantt-Chart-Tools übersprungen werden. Er hat eine eigene Existenzberechtigung. Er lenkt den Fokus auf die Vollständigkeit der Projektarbeit, die die Projektleitung zu organisieren hat. Viele Projektleiter verzichten auf einen Projektstrukturplan und nutzen direkt Tools wie MS Project mit dem Argument, dass hier ja eine ausreichende Strukturierung vorgenommen würde. Die Ablenkung bei einer zu frühen Nutzung eines Gantt-Chart-Tools sind aber vielfältig. Beispiele: Entstehende Balken bei der Erfassung von Vorgängen. Bastelarbeiten bei der Pflege der Abhängigkeiten. Automatisch berechnete Termine, die i.d.R. nicht der Kundenvorgabe entsprechen und die den Erfasser in Optimierungsszenarien abdriften lassen.

💡 Projektstrukturplan und Arbeitspaketbeschreibungen als Kopiervorlage bei Standardprojekten nutzen.

Mit sinnvoll dimensionierten und ausreichend beschriebenen Arbeitspaketen die Grundlage einer guten Strukturplanung schaffen

Arbeitspakete repräsentieren die unterste Gliederungsebene des Projektstrukturplans. Sie werden in diesem Plan nicht weiter aufgeteilt. In den Arbeitspaketen wird vor allem geplant, welche Lieferobjekte beim einzelnen Paket herauskommen sollen und welche Arbeiten dafür erforderlich ist.

Der Projektstrukturplan soll neben der Lückenlosigkeit und Redundanzfreiheit auch die Verantwortung für die Arbeiten organisieren. Jedes Arbeitspaket erhält nämlich einen Verantwortlichen, den sogenannten Arbeitspaketverantwortlichen. Im Arbeitspaket können noch weitere Spezialisten Arbeiten erledigen, aber einer trägt die Hauptverantwortung. Selbst, wenn im Organigramm nur eine organisatorische Einheit steht, die für bestimmte Arbeiten zuständig ist, sollte der zentrale Ansprechpartner als Verantwortlicher genannt werden. Im Kapitel “Ablauf- und Terminplanung” werden wir sehen, dass es unter Umständen sinnvoll sein kann, das Arbeitspaket in diesen Plänen weiter aufzuteilen und Einzelaktivitäten des Arbeitspakets darzustellen, sogenannte Vorgänge. Aber das sind andere Pläne mit anderen Zwecken.

Grundsätzlich sollte Arbeitspakete näher beschrieben werden. Die Ausnahme sind prozessnahe Arbeiten, wo die Fachspezialisten seit Jahren jeden Handgriff kennen. Diese Arbeiten projektspezifisch zu erfassen, wäre eine überflüssige und ineffiziente Fleißarbeit. In der Regel haben Projekte Grad an Individualität und Neuartigkeit - sonst wären es keine Projekte. Wenn man die vielen Qualitätskriterien einer guten Projektstrukturplanung für sein Projekt beachten möchte (siehe weiter unten), dann kommt man aus meiner Sicht um eine (gerne auch minimale) Beschreibung eines Arbeitspakets nicht herum.

Feldbeschreibungen der Arbeitspakete:

  • Feld Ziel: Beinhaltet oft das wesentliche, noch nicht SMART beschriebene übergreifende Lieferobjekt des Arbeitspakets (im Beispiel „Prozessbeschreibung“). Zusätzlich wird oft auch der Nutzen des Arbeitspakets für übergreifende Ziele/Lieferobjekte oder für nachfolgende Arbeitspakete skizziert („…um das PM-Handbuch möglichst auf deren Bedürfnisse anzupassen). Ggf. kann man hier auch den Qualitätscheck guter PSPs einbauen, nämlich den Bezug zu Projektzielen und Zwischenzielen wie Meilensteinen.
  • Feld Lieferobjekt und Kriterien: Um die Zielerreichung genauer messen zu können, werden einzelne Lieferobjekte sowie – wenn es geht – möglichst SMARTe Kriterien zwischen Projektleitung und Arbeitspaket-Owner vereinbart. Die Projektleitung muss sicherstellen, dass die AP-Lieferobjekten auf die Gesamtziele einzahlen. Zusätzliche Felder wie der Verweis auf betroffene Leistungsziele aus der Zielhierarchie (zur Sicherung der Konsistenz) sind denkbar. Dieses Feld sorgt für Klarheit, welche Qualität mindestens für die AP-Abnahme, aber auch maximal für eine effiziente Bearbeitung erwartet wird (Vermeidung „Gold Plating“). Durch klare Messpunkte/Kriterien kann die Projektleitung (zur Not nach Rückversicherung mit dem Fachbereich) das Arbeitspaket auch ohne fundierte fachliche Kenntnisse abnehmen.
  • Feld Vorgänge/Aktivitäten: Im Gegensatz zu den Lieferobjekten ist es hier die Hauptverantwortung des Arbeitspaketowners, wie er und ggf. sein Team die Lieferobjekte erreicht und die relevanten Aktivitäten ableitet. Die Projektleitung redet hier idealtypisch nicht rein (Philosophie „AP-Owner als Unternehmertyp“, Eigenverantwortung und Commitment statt Mikro-Management). Es sollten nur eng zusammenhängende Arbeiten gebündelt werden, um die Nähe der benötigten fachlichen Qualifikation zu ermöglichen. Vor allem, wenn mehrere Personen involviert sind, kann man schon hier – also vor der Ablaufplanung - überlegen, die Vorgänge mit Namenskürzeln den einzelnen Personen zuzuordnen, später über eine 1:n-Beziehung im Ablauf- und Terminplan darzustellen und danach die geplanten Vorgangstermine im Arbeitspaket zur besseren Orientierung von AP-Owner und Team zu aktualisieren. Weil bei der Erzeugung von Arbeitspaketen in der Regel nicht klar ist, ob das Arbeitspaket planerisch über 1:n in einzelne Vorgänge aufgeteilt werden soll, ist die passend, weil sie flexibel für verschiedene Situationen geeignet ist. Bei einer 1:1-Beziehung dienen sie als Aktivitäten dem AP-Owner zur Orientierung, was alles zu tun ist. Bei einer 1:n Beziehung gilt natürlich dasselbe, aber hier haben die Aktivitäten eher den Charakter von „Vorgängen“, die im vernetzten Balkenplan als eigene Objekte abgebildet werden. Oft ist es hilfreich, für die Aufwandsabschätzung bereits hinter den Aktivitäten Aufwandszahlen zu hinterlegen, um Bottom Up den Aufwand des Arbeitspakets abzuleiten.
  • Feld Schnittstellen: Hier können z.B. benötigte Informationen von aufgelisteten Fachbereichen der Organisation eingetragen werden oder (m.E. sehr empfehlenswert) die inhaltliche Abgrenzung zweier Arbeitspakete und Klärung, welches Arbeitspaket im Detail welche Themen übernimmt (Vermeidung Redundanzen und Lücken). Mit Schnittstellen ist hier kein technischer Begriff gemeint, z.B. eine Schnittstelle zwischen Altsystem und Neusystem. Wie bei den anderen Feldern handelt es sich um einen „Projektmanagement-Begriff“. Es gibt in der Praxis verschiedene denkbaren Inhalte: Abgrenzung von einem anderen Arbeitspaket: Beschreibung in Prosa, in welchem Arbeitspaket man sich um eine bestimmte Arbeit kümmert und in welchem Arbeitspaket nicht. Grund: Vermeidung um Doppelarbeit (beide machen es) oder Lücken (keiner macht es). Relevanter Input für das Arbeitspaket: Man benötigt von einem Teammitglied oder einer fachlichen Stelle außerhalb des Projektteams irgendein etwas Relevantes, was noch nicht in einem anderen Arbeitspaket spezifiziert wurde und auch nicht spezifiziert werden soll (z.B. weil es sich wegen dem Umfang nicht lohnt).
  • Feld „Vorgänger“ und „Nachfolger“: Die Vorgänger und Nachfolger werden meist erst bei der Ablaufplanung bestimmt. Natürlich kann man schon bei der Arbeitspaketbeschreibung nach bestem und Gewissen eine Arbeitshypothese zu den Abhängigkeiten abgeben, aber erfahrungsgemäß kann sich hier in der Ablaufplanung noch einiges ändern bzw. noch einige Abhängigkeiten dazukommen. Deshalb empfehle ich, besser eine vernünftige Ablaufplanung zu machen und das Ergebnis erst dann in der Beschreibung einzutragen. Ggf. benötigt man von den Lieferergebnissen z.B. des Vorgängers nicht alle Lieferergebnisse, sondern nur ganz Bestimmte. Wenn man das als Arbeitspaket-Owner weiß, kann man selbständig auf den Verantwortlichen des Vorgängers zugehen und fragen, ob dieses relevante Lieferobjekt schon fertig ist (Hinweis: Klärung mit Projektleiter, ob ein solches Prozedere schon vor der offiziellen AP-Abnahme möglich ist). Die Felder Vorgänger, Nachfolger können ggf. schon bei der Bildung der AP-Spezifikation eingetragen werden. Vorteil für AP-Owner: Er muss nicht unbedingt zusätzlich im Gantt-Chart nachsehen, wann er mit seinem AP drankommt, von welchen Vorgängern er ggf. Input benötigt und an welche Nachfolger er seine Ergebnisse abgibt. Hinweis: In vollintegrierten Tools wie MS Project (Plan 1) kann zwischen AP-Spezifikation und Gantt-Ansicht flexibel gewechselt werden. Spätestens dann sollten die ggf. noch leeren Felder in der AP-Beschreibung mit den Terminen aktualisiert werden. Feld Risiken: Empfehlenswert ist die Beachtung der Formel Ursache (Fakten, hier „Komplexität“), Risiko (im Konjunktiv, hier Toolablehnung) und Auswirkung (auf Zeit, Kosten und oder Leistungsziele). Diese Risiken gehören zusätzlich in eine Gesamtliste (Risikoregister) zusammen mit anderen Risiken, die aus anderen Quellen stammen als aus der Quelle „Arbeitspakete“. Durch die doppelte Risikoauflistung in Register und Spezifikation wird gewährleistet, dass für das Arbeitspaket relevante Risiken beim AP-Owner nicht untergehen und von ihm beachtet werden – unabhängig davon, ob er sich persönlich um die Mitigation kümmern muss.
  • Feld Fortschrittsgradmessung: Hier wird eine zum Arbeitspaketinhalt und zur Häufigkeit des Berichtswesens passende Fortschrittsgradmessmethode eingetragen.
  • Feld Aufwand: Wenn man nichts anderes macht (ohne Unterbrechungen), als sich am Stück mit einem Vorgang bzw. Arbeitspaket zu beschäftigen: Wie viele Stunden oder hier Tage würde man benötigen? Der Wert kann oft leicht bottom up über den Aufwand der einzelnen Aktivitäten abgeleitet werden.
  • Feld Dauer: Anzahl der Arbeitstage, an denen hintereinander gearbeitet wird (in den Grundeinstellungen von MS Project ohne Wochenende, Feiertage oder freie Tage). Die Dauer ist deshalb oft nicht identisch mit der Differenz zwischen Start und Ende (zumindest nicht, wenn man Tools wie MS Project nutzt).
  • Die Felder Start und Ende werden klassisch erst nach durchgeführter Ablauf- und Terminplan eingetragen.

⚠️ Mögliche Widerstände gegen die Arbeitspaketspezifikation:

Bei der Methode der Arbeitspaketspezifikation muss die Projektleitung mit offenen und verdeckten Widerständen rechnen.

Offenem Widerstand („zu aufwändig“) kann mit dem Argument begegnet werden, dass es streng genommen kein zusätzlicher Aufwand sondern nur eine Vorverlagerung der Planung ist, um Redundanzen und Doppelarbeiten zu antizipieren:

  • Die offenen Widerstände gegen das Ausfüllen von AP-Spezifikation sind oft groß: “Das ist zu viel Aufwand“. „Soll ich Formulare ausfüllen oder Arbeiten?“
  • Dem Argument „zu viel Aufwand“ kann die Projektleitung wie folgt begegnen:
    • Der Zusatzaufwand ist geringer als man denkt.
    • Spätestens, wenn das Arbeitspaket ansteht, muss man sich Gedanken über Ziele, Ergebnisobjekte, Schnittstellen, FGR-Messung usw. machen.
    • Die Gedankenarbeit ist der bei weitem größte Anteil am Aufwand. Der geringste Anteil am Aufwand ist das Aufschreiben. Die Befüllung der AP-Spezifikation schon während dem Workshop ist also lediglich eine Vorverlagerung des Nachdenkens über das Arbeitspaket mit vielen Vorteilen:
      • Früherer Zeitpunkt der AP-Planung: Während der Planungsphase wird die Planungsqualität deutlich erhöht, es entstehen echte Leitplanken für das Projekt. So können z.B. schon während der Planung Doppelarbeiten und Lücken benachbarter Arbeitspakete eingeschränkt werden.
      • Wenn man diesen Abgleich während der Planung - z.B. während eines Workshops - nicht macht - macht man es nach meiner Erfahrung zumindest nicht mehr strukturiert im gesamten Projektteam. Sondern oft erst dann, wenn es zu spät ist und während der Realisierung irgendwann auffällt, dass verschiedene Projektmitarbeiter Doppelarbeiten vorgenommen oder sich auf den jeweils anderen verlassen haben.
      • Das Schriftlichkeitsprinzip sorgt für eine intensive Beschäftigung mit den Anforderungen der einzelnen Felder (siehe oben). In der Regel setzt man sich mit mehr Aspekten des Arbeitspakets auseinander als bei einer rein kognitiven Beschäftigung mit den Inhalten.
      • Das Schriftlichkeitsprinzip sorgt auch für eine noch bessere Planung: Lücken und Redundanzen werden durch die größere Detailgenauigkeit noch besser entdeckt als bei einer rein mündlichen Besprechung, wer für was zuständig ist. Erst das Schriftlichkeitsprinzip sorgt dafür, dass man z.B. in einem Workshop zwei AP-Spezifikationen nebeneinanderhängen kann, um Lücken und Redundanzen zu entdecken (ggf. macht das perspektivisch auch die KI)
      • Bei einem längeren Ausfall eines Arbeitspaketverantwortlichen ist Vertretung oder die Übergabe des Arbeitspakets bei einer ordentlichen Beschreibung natürlich auch viel einfacher.
      • Man kann aus meiner Sicht auch mit Effizienz und Effektivität argumentieren. Angesichts der oft sehr umfangreichen Projektarbeit kann man es sich nur selten leisten, ohne Not ständig die Anforderungen des Kunden zu übertreffen. Es geht ja nicht nur um die Erreichung einer Mindestqualität. Sondern ebenso darum, es bei Erreichung einer Obergrenze gut sein zu lassen, um sich dem nächsten Arbeitspaket zu widmen.

Schwieriger ist es oft, mit dem (teilweise) verdecktem und oft emotionalen Widerstand umzugehen. Das Bedürfnis nach Autonomie ist laut vieler Psychologen bei den meisten Menschen stark ausgeprägt. Viele arbeiten mit hohen Freiheitsgraden und ohne externe Kontrolle „vor sich hin” und entscheiden selbst, wenn ein Arbeitspaket aus ihrer Sicht eine ausreichende Qualität hat. Dazu gehört z.B. auch, bei Aspekten, die ggf. weniger wichtig sind, einen individuell ggf. stark ausgeprägten Perfektionismus auszuleben oder nach dem Spaßprinzip interessante Themen zu vertiefen. Mögliche Maßnahme:

  • Diesen Zusammenhang offen ansprechen, Verständnis für das Bedürfnis aufbringen, aber betonen, dass die individuellen Vorteile von Projekten (Abwechslung zum Tagesgeschäft, Umgang mit neuen Themen, persönliche Weiterentwicklung) mit den Zwängen der Firma (Effizienz, sorgsamer Umgang mit dem Budget) in Einklang zu bringen sind.
  • Aussagen wie „es dauert so lange wie es dauert“ seien da eher kontraproduktiv. Projektleitung und Teamkollegen müssen mit konkreten (nach bestem Wissen und Gewissen geschätzten) Daten (Aufwand, Dauer usw.) arbeiten, um sich darauf einstellen zu können.
  • Unternehmens-/Projektkultur: Es ist kein einfaches Thema, wenn in einem Unternehmen die Eigenverantwortung kein essenzieller Kulturbestandteil ist. Projektleiter wollen nicht vor vollendete Tatsachen gestellt wird, z.B. wenn erst nach dem geplanten Ende des Arbeitspakets berichtet wird „leider noch nicht fertig“). Maßnahme: Die folgende Botschaft sollte als Teamregel verabredet werden, welche zu einer – ggf. von der Unternehmung – abgegrenzten Projektkultur führt: Projektleitung:
    • „Ich rede dir nicht rein, wie du die Ziele des Arbeitspakets erreichst, also wie du die eigentliche Tätigkeit gestaltest. Ich bin kein Mikromanager und respektiere da dein Autonomiebedürfnis. Du bist der Fachmann, die Fachfrau und kennst dich viel besser aus als ich.
    • Als kleine Einschränkung dieser Autonomie erwarte ich aber zwei Dinge:
      • Ich möchte bei den Ergebnisobjekten gemeinsam mit dir besprechen, wie sie auf die Gesamtziele des Unternehmens einzahlen.
      • Ebenso möchte ich mit dir mindestens, aber auch maximal nötige Qualität über Kriterien besprechen.
      • Ich erwarte, dass du mich bei den ersten Anzeichen darüber informierst, dass es Probleme bei der Erreichung der Ziele sowie der Plandaten geben könnte.
      • Dann besprechen wir gemeinsam sinnvolle Maßnahmen (Management by Exception).
      • Insofern übernimmst du die Verantwortung für das Arbeitspaket gegenüber mir.
      • Ich übernehme die Gesamtverantwortung gegenüber dem Auftraggeber (Management by Objectives) Es liegt auf der Hand, dass die Projektleitung die Themen Verantwortungsübernahme bzw. das Mindset eines Unternehmertyps oder „Mini-Projektleiters“ je nach Unternehmenskultur und individueller Disposition nicht einfach hinbekommt. Ggf. hält man Unterstützung von der Unternehmensleitung oder dem PMO (aktuelle Change-Initiative oder ein bereits existierender Code of Conduct mit entsprechenden Unternehmensregeln zu den Themen Selbstorganisation und Verantwortung.
  • Ich habe die Erfahrung gemacht, dass anfangs skeptische Arbeitspaketowner ein motivierendes Gefühl der Selbstwirksamkeit erfahren, wenn sie sich zusammen mit der Projektleitung ehrgeizige Ziele setzen und diese am Ende auch erreichen. Die formelle Abnahme eines anspruchsvollen Arbeitspakets durch die Projektleitung ist - so wurde es mir oft zurück gespiegelt - etwas ganz anderes, als die selbst bestimmte Beendigung eines nicht näher beschriebenen Arbeitspakets durch den Verantwortlichen. Was auf den ersten Blick wie das perfekte Ausleben des menschlichen Automomiebedürfnisses wirkt, ist dann beim zweiten Blick eine oft geringere Wahrnehmung und Würdigung der Arbeitspaketergebnisse durch die Projektleitung, die die Übererfüllung der Qualitätsvorgaben aus AP-Ownersicht nicht beurteilen und deshalb auch nicht würdigen kann.

💡 Größentipps für Arbeitspakete:

Es kursieren zahlreiche Tipps in der Praxis, wie man ein Arbeitspaket dimensionieren soll. Im Grundlagenteil beschränke ich mich auf die wenigen Tipps, die aus meiner Sicht den größten Mehrwert bringen:

  • Der oben erwähnte eine Verantwortliche sollte einen Arbeitsumfang in seinem Arbeitspaket erhalten, dass er aufgrund seiner organisatorischer Aufhängung und seiner Qualifikation möglichst selbständig alleine oder mit seinem Team bearbeiten kann.
  • Das Arbeitspaket sollte so klein sein, dass Aufwand, Kosten, Dauer und Fortschrittsgrade zugeordnet werden können. Es sollte aber auch nicht zu klein sein.
    • Die gefühlte Untergrenze ist zumindest bei mir ein Personentag, weil der Personentag gleichzeitig eine übliche Obergrenze auf Aufgaben in agilen Vorgehensmodellen ist.
    • Vorsicht vor Mikromanagement: Ich habe vor einigen Jahren einen Projektleiter kennengelernt, der mir stolz seine Liste von über 500 Einzelaktivitäten (überwiegend im Stundenbereich) zeigte und der den Bearbeitungsstand täglich kontrollierte. Damit machte er natürlich nicht nur sich selbst, sondern auch sein Team wahnsinnig. Das deutliche Signal an das Team war fehlendes Vertrauen. Solche Signale können ein Team zur Passivität und fehlenden Eigenverantwortung erziehen. Insofern ist es immer sinnvoll, den Fachspezialisten die Art der Umsetzung zu überlassen und die Aktivitäten zu einem “Paket”, einem Arbeitspaket zusammenzufassen. Es ist effizienter und motivierender 20 Arbeitspakete zu überwachen als 500 Einzelaktivitäten mit einem Aufwand von jeweils nur ein paar Stunden.
  • Selbstverständlich können die Arbeitspakete auch sehr groß werden. Auch hier gibt es verschiedene Regeln, was eine sinnvolle Obergrenze sein könnte: Wenn es zu wenige und zu große Arbeitspakete gibt, wirken sich schlecht laufende Arbeitspakete viel stärker auf das Gesamtprojekt aus. Ein Nachsteuern ist meist schwerer möglich als bei der Überwachung kleinerer Arbeitspakte. Beispiel für so eine Faustregel:
    • Ein Arbeitspaket repräsentiert ca. 5% der Facharbeit (nicht Projektmanagement). Insofern hätte man ca. 20 Arbeitspakete in seinem Projekt.
    • Je nach Gesamtgröße des Projekts wären damit die einzelnen Arbeitspakete im Schnitt umfangreicher oder weniger umfangreich, aber es bleibt bei einer überschaubaren und gut kontrollierbaren Anzahl.

Projektmanagement gehört zu den Projektarbeiten dazu und hilft bei angemessener Visualisierung bei den Verhandlungen zum PM-Budget

Die Arbeit für das Projektmanagement sollte auch visualisiert werden. Einen repräsentativen Überblick gewähren die Projektmanagementphasen nach DIN69901. Diese Projektmanagementphasen können auch als Arbeitspakete des Projektmanagements verwendet werden. Die Setup-Phase des Phasenplans beinhaltet meist Initialisierung, Definition und Planung und gehen insofern im Projektstrukturplan in der Teilaufgabe „Projektmanagement“ auf. Steuern und Abschließen kommen aber in der Teilaufgabe “Projektmanagement” dann noch dazu.

💡 Verhandlung mit dem Auftraggeber über den Projektmanagementaufwand:

Gegenüber dem Auftraggeber kann aufgrund der visuellen Darstellung argumentiert werden, dass sich die Arbeitspakete nicht mit Selbstorganisation erledigen und man in planbasierten und hybriden Ansätzen Budget für Projektmanagement benötigt. Selbst in rein agilen Projekten gibt es oft die Rolle der Projektleitung mit einem entsprechenden Budget.

Verbreitete „Praktikermethode“:

  • Beispiel 10 Prozent bei mittleren Projekten als normal ansehen, was auch immer „mittlere Projekte“ sind.
  • Beispiel 11 – 20 Prozent: Bei kleineren Projekten oder Changeprojekten ist der Anteil meist etwas höher. Bei Changeprojekten deshalb, weil der erhöhte Kommunikationsaufwand dem Projektmanagement zugeordnet werden kann. 
  • Beispiel 5 %: Bei Großprojekten (Skalierungseffekte) und bei Projekten mit einem hohen Anteil an Materialkosten (meist einfacher zu managen als Personal) ist dieses Verhältnis in der Regel etwas geringer. Und das, obwohl mit zunehmender Projektgröße Strukturen geschaffen werden (Teilprojektleiter, Projektoffice-Mitarbeiter), die den PM-Aufwand wiederum erhöhen.

Letztlich ist der mögliche Umfang von Projektmanagement m.E. immer ein Verhandlungsgegenstand mit dem Kunden. Je höher der geforderten PM-Anteil, desto eher lohnt sich eine konkretere Argumentation als mit dem pauschalen Überblick nach DIN-PM-Phasen. Beispiele:

  • Business Case des Kunden permanent im Blick haben und Projekt ergebnisorientiert steuern
  • Teammitgliedern Aufgaben und Verantwortungsbereiche zuweisen
  • Dolmetscherfunktion zwischen Kunde und Projektteam
  • Kommunikation innerhalb des Teams bereitstellen (üblicherweise Herzstück der Arbeit der Projektleitung)
  • Führung und Motivation des Projektteams. Auch, wenn Selbstorganisation in agilen Strukturen im Trend liegt, wird es bei Kundenprojekten immer einen „Single Point of Contact“ beim Dienstleister mit Aspekten einer Führungsrolle geben
  • Mit geeigneten Kreativitätstechniken sinnvolle Lösungsansätze finden
  • Risiken identifizieren und managen
  • Interne Verhandlungen über Ressourcen
  • Projektfortschritt überwachen
  • Abweichungen analysieren und beseitigen
  • Vereinbarte Qualität bereitstellen (passiert nicht automatisch)
  • Änderungswünsche besprechen und umsetzen
  • Projektergebnisse vor Lieferung prüfen
  • Beschaffung: Freiberufler und externe Dienstleister (SEO-Spezialisten, Web-Designer, Web-Entwickler…) beauftragen und koordinieren
  • Fortschrittsberichte an Kunden senden
  • Diverse zeitfressende „Verwaltungsarbeiten“…

Bei einer Weigerung des Kunden, für PM zu bezahlen, muss der Kunde damit rechnen, dass der Aufwand für Projektmanagement in der Facharbeit intransparent „verschmiert“ wird. Auch wenn das ggf. nicht üblich ist, könnte der Kunde z.B. freiwillig mehr für Projektmanagement bezahlen wollen, wenn er die Befürchtung hat, dass der Dienstleister dafür zu wenig vorgesehen hat;-).

Oft wird genügend Budget für Projektmanagement zur Verfügung gestellt. Wenn trotzdem nicht genügend Zeit mit Projektmanagement verbracht wird (unabhängig von der Qualität), liegt das oft an der fehlenden intrinsischen Motivation der Projektleiter, sich mit dem “schnöden Managementgedöns” zu beschäftigen. Die fachlichen Herausforderungen erscheinen in solchen Fällen oft attraktiver. Ich habe schon einige Projektleiter beobachtet, die sich in Facharbeit fast schon geflüchtet haben, weil sie dort ihre Komfortzone haben und ihre wahre Motivation liegt.

Mit einem zum Projektinhalten passenden Gliederungsprinzip der Arbeitspakete zusätzliche Effizienzpotenziale haben

Unabhängig vom Gliederungsprinzip gilt: Die zu leistende Arbeit ist insgesamt dieselbe und nimmt mit der Wahl eines anderen Gliederungsprinzips nicht ab. Die Arbeit wird nur anders strukturiert. Aber die Erfahrung zeigt, dass sich je nach Projektinhalt bestimmte Gliederungsprinzipien anbieten und andere weniger. Arbeit wird dadurch nicht gespart, aber die Effizienz bei der Arbeit kann sich teilweise erheblich unterschieden. Deshalb sollte man sich die Projektleitung mit den wichtigsten Gliederungsprinzipien beschäftigen. Es gibt noch mehr, ich habe hier nur die aus meiner Sicht wichtigsten und häufigsten Gliederungsvarianten aufgelistet.

Objektorientierung: Fokus Lieferobjekte Ein Lieferobjekt ist ein materielles oder immaterielles Projektergebnis, das man dem Kunden zur Nutzung bei der Abnahme übergibt

  • Bei großem Wert auf Effizienz und Priorität von Kostenzielen
  • Bei vielen unabhängigen aber parallelen Lieferobjekten
  • Einfache Integration externer Teilprojekte oder Arbeitspakete
  • Der Fokus liegt auf Lieferobjekten: Die Gliederung basiert auf der Struktur des zu erstellenden Produkts.
  • Wenn man besonderen Wert darauf legt, bei jedem Arbeitspaket sicherstellen möchte, dass es auf das Objekt der Teilaufgabe einzahlt
  • Einfache Ableitung aus einem eventuell vorliegenden Produktstrukturplan

💡 Wenn die Leistungsziele in der Zielhierarchie in Form von Lieferobjekten gestaltet worden sind, ist die Ableitung einer objektorientierten Struktur beim PSP in der Regel einfacher.

Phasenorientierung: Fokus WANN

  • Bei Priorisierung von Terminzielen
  • Bei sequenziellem Durchlaufen von Phasen zu einem Endprodukt
  • Einfache Ableitung aus dem Phasenplan möglich
  • Bei Wert auf Einfachheit durch Konsistenz zum Phasenplan: So können sich weniger erfahrene Projektmitarbeiter leichter orientieren.
  • Fokus WANN, in welchem Abschnitt und in welcher Abfolge?
  • Unterschiede zu Funktionsorientierung:
    • Eine phasenorientierte Teilaufgabe steht für dominante Tätigkeiten oder Funktionen in dieser Phase, es können aber auch andere Funktionen durchgeführt werden.
    • Die phasenorientierte Teilaufgabe wird im Substantiv benannt. Die funktionsorientierte Teilaufgabe mit einem Verb dargestellt, um die Tätigkeit zu unterstreichen – ggf. ergänzt mit einem sinnvollen Substantiv.*
    • Eine phasenorientierte Teilaufgabe repräsentiert immer eine Sequenz. Deshalb spricht man bei der Phasenorientierung auch gerne von Ablauforientierung. Bei der Funktionsorientierung kann natürlich auch ein Ablauf dargestellt werden. Aber oft werden hier sehr spezielle Tätigkeiten/Funktionen benannt, die auch parallel und nicht sequenziell stattfinden.

💡 Wer später seinen PSP in einen Ablauf- und Terminplan überführen möchte und ein professionelles Projektmanagementool wie MS Project verwenden möchte, tut sich nach meiner Erfahrung leichter mit der Phasenorientierung.

Funktionsorientierung: Fokus was ist zu tun (Darstellung über ein Verb)

  • Eine Tätigkeit oder Funktion ist nicht leicht zu bilden. Sie sollte in sich homogen sein, z.B. Testen, Entwickeln, Verkaufen. Aber was homogen ist und auf welchem Abstraktionsniveau Funktionen gebildet werden, ist natürlich auch Geschmacksache. Wenn die Homogenität der Tätigkeiten verloren geht, sollte man auf ein anderes Gliederungsprinzip zurückgreifen. Ein weiteres Kriterium für eine gute Funktion ist die Möglichkeit, klar einen Spezialisten benennen zu können, der diese Funktion ausübt.
  • Die Teilaufgabe repräsentiert oft eine Abteilung, die auf bestimmte Funktionen spezialisiert ist (z.B. Marketing machen). Allerdings sollte man darauf achten, dass die ggf. vielfältigen Marketingaufgaben von einem Spezialisten durchgeführt werden können. Wenn verschiedene Marketingfunktionen von einem Marketingexperten durchgeführt werden können, ist gegen die Funktion „Marketing machen“ aus meiner Sicht nichts einzuwenden. Sonst sollte man eventuell eher die Organisationsorientierung wählen.
  • Je nach Funktion (z.B. Tests durchführen) repräsentiert sie auch keine Abteilung, wenn es z.B. keine „Testabteilung“ gibt, sondern die Tests von mehreren Fachbereichen durchgeführt werden. Dann steht die Funktion im Vordergrund.
  • Eine Funktionsorientierung ist z.B. empfehlenswert, wenn sich eine überschaubare Anzahl von Funktionen auf eine Vielzahl von Lieferobjekte bezieht und sich die Funktionen klar trennen lassen. Dann ist eine funktionsorientierte Darstellung oft übersichtlicher als eine objektorientierte Darstellung mit wenigen sich wiederholenden Funktionen.
  • Weiteres typische Einsatzszenario: Wenn Projekt viele abstrakte Aspekte hat, die über materielle Gegenstände hinausgehen (z.B. Veränderungsprojekt). Es ist hier oft plausibler, „Projektmarketing“ als Funktion bei einer Teilaufgabe anzugeben als z.B. „Mindsetwechsel“ als Objekt.
  • Herausforderungen:
    • Funktionsorientierung leidet oft darunter, dass Arbeitspakete mit vielen ineinander greifenden Funktionen nicht mehr eindeutig einer Teilaufgabe zugeordnet werden können.
    • Der PSP wird oft breit und unübersichtlich, was ein gebündeltes Management (z.B. über eine Teilprojektleitung) schwierig macht.
    • Die Anzahl der Arbeitspaket und Gefahr von Mikromanagement wächst.
    • Formale Demonstration einer „Pseudo-Funktionsorientierung“ („IT machen“) durch Verb-Nennung. Bei Bedarf verschiedener Fachspezialisten sollten entweder konsequent die benötigten Spezialfunktionen genannt werden oder gleich die Organisationsorientierung (Teilaufgabe IT) verwendet werden.

Organisationsorientierung: Fokus WER, welche Abteilungen, Spezialisten, Gewerke erbringen die Leistungen?

  • Bei großer Anzahl sich stark überschneidender Funktionen, die gleichzeitig von derselben Qualifikation durchgeführt werden können.
  • Die Teilaufgabe repräsentiert eine Abteilung bzw. Organisationseinheit, die meist auf bestimmte Funktionen spezialisiert ist (z.B. Marketing machen). Insofern gibt es oft eine große Ähnlichkeit zur Funktionsorientierung.
  • Wenn man die Arbeitspakete nach verschiedenen klar trennbaren Funktionen einer Organisationseinheit aufteilen möchte (z.B. Testen, Bugfixen, Dokumentieren innerhalb der Organisationseinheit IT), könnte man ggf. eher eine Funktionsorientierung wählen, wenn die verschiedenen Tätigkeiten von unterschiedlichen Spezialisten bzw. „Qualifikationen“ durchgeführt werden müssen.
  • Wenn allerdings die Anzahl der Funktionen sehr groß ist und die Funktion ineinander greifen oder sich überschneiden, sollte man eher auf die Organisationsorientierung zugreifen: Die Übersichtlichkeit steigt. Und die Effizienz bzw. Wartbarkeit steigt, weil man weniger Mühe hat, die Arbeitspakete voneinander abzugrenzen. Bei einer starken Überschneidung funktionsorientierte Teilaufgaben fällt die Abgrenzung oft schwer.
  • Die Organisationsorientierung ist typisch für Einflussprojektorganisation mit geringem PM-Reifegrad: Die Projektmitarbeiter gewinnen eine gewisse Vertrautheit durch ähnliche Struktur wie Firmenorganigramm.

Mischorientierung: Die Mischung von Gliederungsprinzipien ist weiterverbreitet und auch völlig in Ordnung, wenn sich die Mischung auf verschiedene Gliederungsebenen bezieht. Zum Beispiel könnte das Objekt ein “Konzept” auf der Ebene der Teilaufgaben sein. Darunter auf Arbeitspaketebene werden dann nicht - wie bei einer Stücklistenauflösung - die einzelnen Konzeptkapitel als Objekte aufgeführt, sondern die Funktionen, was mit dem Objekt Konzept zu passieren hat, also zum Beispiel “schreiben, prüfen, anpassen, umsetzen, testen, freigeben”.

Für die Praxis würde ich sogar noch einen Schritt weitergehen und auf der Ebene der Arbeitspakete für eine Mischung von Objekt- und Funktionsorientierung plädieren, um besonders deutlich zu sein und Missverständnisse soweit wie möglich zu verhindern. Dann würde dort zum Beispiel stehen: “Konzept schreiben”, “Konzept prüfen” usw.

⚠️ Eine Mischung der Gliederung innerhalb einer Gliederungsebene sollte vermieden werden. Die Gefahr von Redundanzen mit der Folge von Doppelarbeiten oder die Gefahr von Lücken ist einfach zu groß.

Beispiel:

  • Man baut einen PSP für die Wiesn auf
  • In der Ebene der Teilaufgaben kommen als Lieferobjekte rein: Zelt 1, Zelt 2, Zelt 3 usw.
  • Unter Zelt 1 bis Zelt 3 schreibt man jeweils die gleichen Arbeitspakete wie zum Beispiel “Bänke und Tische aufstellen, “Bühne für Bands vorbereiten”.
  • Wenn man auf der Ebene der Teilaufgaben die Zeltobjekte mit zum Beispiel “Bänke und Tische aufstellen” mischen würde, dann würde man darunter logischerweise auf Arbeitspaketebene die Zelte darstellen. Dann müsste man sich aber merken, dass man Zelt 1 - Zelt 3 auspart, weil für diese Objekte die Arbeit bereits geplant ist. Es ist klar, dass man bei einer Mischung der Gliederungsprinzipien auf einer Ebene sehr schnell den Überblick verliert.

Klassische Bauprojekte in Deutschland verwenden oft eine Mischorientierung nach der HOAI-Logik (HOAI = Honorarordnung für Architekten und Ingenieure):

  • Leistungen, Honorare, Verträge und Abrechnung nach den HOAI-Leistungsphasen (LPH 1–9) strukturiert sind.
  • Projektsteuerung, Controlling und Nachweise phasenbezogen erfolgen.
  • Viele Beteiligte (Architekten, Fachplaner, Bauherren) dieselbe Denklogik verwenden. Deshalb kommt im PSP meist: Projekt → HOAI-Phasen → Objekte / Bauwerke → Gewerke / Arbeitspakete. Beispiel: Projekt Neubau Bürogebäude
  • 1.1 LPH 1 Grundlagenermittlung
    • 1.1.1 Gebäude A
    • 1.1.1.1 Architektur
    • 1.1.1.2 Tragwerksplanung
  • *1.2 LPH 2 Vorplanung
    • 1.2.1 Gebäude A
    • 1.2.1.1 Architektur
    • 1.2.1.2 TGA
  • 1.3 LPH 3 Entwurfsplanung
    • …

Viele Projekte verwenden die Objektorientierung schon in der ersten Ebene, wenn es sich nicht um HOAI-getriebene Bauprojekte handelt: Beispiel Projekt Produktionsanlage x

  • 1 Produktionsanlage
    • 1.1 Detailplanung
    • 1.2 Konstruktion
    • …
  • Fördertechnik
    • 2.1 Detailplanung
    • 2.2 Montage
    • …
  • Steuerungssystem
    • 3.1 Software
    • 3.2 Inbetriebnahme
    • … Oder die Planung eines Volksfestes
  • 1 Projekt Volksfest Wiesn
    • 1.1 Zelt Betreiber x
      • 1.1.1 Aufbau
      • 1.1.2 Betrieb
      • 1.1.3 Abbau
    • 1.2 Zelt Betreiber y
      • 1.2.1 Aufbau
      • 1.2.2 Betrieb
      • 1.2.3 Abbau