Projektplanung, -organisation & -steuerung

Applied Market & Business Strategy (das „Strategy & Management Game”) - NIT / TUHH, Hamburg · Teil meines Technology-Management-MBA · Lernnotizen zur Wiederholung.

---

Das letzte Kapitel hat uns einen unterschriebenen Projekt-Charter verschafft - die „Lebensversicherung” des Projektleiters, die Zielvereinbarung zwischen Auftraggeber und PL. Dieses Kapitel ist das große: wie man aus diesem einseitigen Versprechen einen Plan macht, nach dem Menschen tatsächlich arbeiten können, eine Organisation, die ihn trägt, und einen Regelkreis, der ihn ehrlich hält. Hier liefert ein Strategieprojekt entweder ab - oder es zerfällt still und leise.

Ich baue das Ganze um ein einziges durchgehendes Beispiel herum - stell dir vor, ich bin der PL eines Systementwicklungsprojekts bei CERMEDES, einem mittelständischen deutschen Elektrowerkzeug-Hersteller (eine neue Akkuschrauber-Plattform entwickeln, ausliefern, von einem Erstkunden abnehmen lassen). Fünf Schritte, der Reihe nach: Arbeit planen → terminieren → mit Ressourcen ausstatten → Menschen organisieren → steuern - und das Projekt danach sauber abschließen.

Tipp

Das Rückgrat dieses Kapitels. Fast alles hängt an einem einzigen Artefakt - dem Projektstrukturplan (PSP/WBS). Der PSP speist den Terminplan, der Terminplan speist den Ressourcen-/Budgetplan, und der Ressourcenplan speist die Kostenkontrolle. Bekommst du den PSP richtig hin, ist der Rest Buchhaltung; machst du ihn falsch, rettet dich keine noch so schöne Gantt-Grafik.

1 · Die Arbeit planen

1.1 Beginne mit Ergebnissen, nicht mit Aufgaben

Die Versuchung ist, direkt zur To-do-Liste zu springen. Widersteh ihr. Ein Projekt plant man rückwärts von seinen Ergebnissen her. Das erste Artefakt ist also eine Ergebnisübersicht (Deliverables-Map) - eine Mindmap (oder strukturierte Liste oder ein Organigramm) jedes Ergebnisses, das das Projekt hervorbringen muss, sowohl physischer (ein getesteter Prototyp, ein installiertes System) als auch intellektueller Art (eine Spezifikation, ein Schulungshandbuch, eine Use-Case-Definition).

System vom Kunden abgenommendas Gesamt-Projektziel

↑

Hardware getestetZeichnung · Prototyp · Test

Software getestetkompilierter Code · Integrationstest

System installiertStandortplan · Logistik

Kunde geschultHandbuch · Schulungsmaterial

Eine Ergebnisübersicht für das CERMEDES-Systemprojekt: das Gesamtziel oben, die zentralen Ergebnisse darunter und die Teilergebnisse, die in jedes einfließen. Das ist Brainstorming-Output - es wird zum Rohmaterial für den PSP.

Ergebnisse zuerst zu kartieren leistet zwei stille, aber wichtige Dinge: Es zwingt das gesamte funktionsübergreifende Team, ein gemeinsames Bild davon zu teilen, wie „fertig” aussieht, und es bringt die intellektuellen Ergebnisse (Spezifikationen, Pläne, Protokolle) ans Licht, die eine aufgabenzentrierte Liste immer vergisst.

1.2 Der Projektstrukturplan (PSP/WBS)

Der PSP ist die strukturierte Gesamtübersicht der gesamten Projektarbeit - das mit Abstand wichtigste Planungswerkzeug. Er nimmt die Ergebnisübersicht und ordnet sie zu einem Baum planbarer, steuerbarer Blöcke um, angeordnet in einer Wertstrom- (Arbeitsfluss-)Reihenfolge, sodass man das Projekt von links nach rechts so lesen kann, wie es tatsächlich abläuft.

Er hat drei Ebenen:

Ebene	Was hier sitzt	Wie viele
1 · Projekt	Das gesamte Projekt - eine Box ganz oben	1 Element
2 · Phasen	Hauptphasen oder Teilprojekte (plus eine Management-„Phase”)	4-8 Elemente
3 · Arbeitspakete (APs)	Die kleinste planbare Arbeitseinheit	5-10 je Phase

Jede Box bekommt einen PSP-Code, abgeleitet aus ihrer Position - Phase 3, Arbeitspaket 3.2 usw. - und jede Phase und jedes AP hat genau eine namentlich benannte verantwortliche Person. Ein Arbeitspaket ist das Atom des ganzen Systems: ein identifizierbarer Schritt zum Endergebnis, klein genug, um es zu planen und zu steuern, groß genug, um es wert zu sein, es zu verfolgen.

• 1 · Projektmanagement (die Management-„Phase”)
  • 1.1 Projektplanung · 1.2 Projektsteuerung · 1.3 Berichtswesen & Kommunikation
• 2 · Machbarkeitsstudie
  • 2.1 Systemprinzip-Analyse · 2.2 Test des Schlüsselkomponenten-Prototyps · 2.3 Hardware-in-the-Loop-Test
• 3 · F&E
  • 3.1 Spezifikation · 3.2 Design · 3.3 Mock-up
• 4 · Produktion & Logistik
  • 4.1 Fertigungsanforderungen · 4.2 Beschaffung von Schlüsselkomponenten · 4.3 Fabriklayout
• 5 · Markteinführung
  • 5.1 Zielmärkte · 5.2 Testverkauf · 5.3 Roll-out-Plan

Ein gekürzter CERMEDES-PSP. Phase 1 ist reine Management-Arbeit (Planung, Steuerung, Berichtswesen) - gib dem Management immer einen eigenen Ast, sonst verschwindet es aus dem Budget.

Hinweis

Wer entwirft was. Der PL (oder Auftraggeber) skizziert den ersten Entwurf der Ergebnisplanung; der detaillierte PSP wird mit dem funktionsübergreifenden Team verfeinert. Passe den Detailgrad an das Problem an - ein einfaches Projekt braucht einen flachen Baum, ein Systementwicklungsprojekt einen tiefen. Es geht nicht um Vollständigkeit um ihrer selbst willen; es geht um eine „gemeinsame Basis für jede Projektplanung des Kernteams”.

1.3 Die Arbeitspaket-Spezifikation - der Mini-Charter

Jedes Arbeitspaket verdient seine eigene kleine Vereinbarung, die Arbeitspaket-Spezifikation. Wenn der Charter der Vertrag zwischen Auftraggeber und PL ist, dann ist die AP-Spec der Vertrag zwischen dem PL und dem AP-Verantwortlichen. Sie wird vom AP-Verantwortlichen entworfen, dann im Team abgestimmt, und sie existiert, um allen ein gemeinsames Verständnis des AP-Ergebnisses zu geben und um seinen Umfang abzugrenzen, damit nicht zwei Personen dasselbe bauen.

AP-Spec-Element	Was es festlegt
Administrative Infos	PSP-Nummer, AP-Name, AP-Verantwortlicher, Teammitglieder
Ziele	Die Ergebnisse - SMART: spezifisch, messbar, erreichbar (achievable), relevant, terminiert (time-bound)
Umfang / Out-of-Scope	Was zu diesem AP gehört - und, ebenso wichtig, was bewusst nicht
Voraussetzungen & Inputs	Was zuerst vorhanden sein muss und welche Inputs aus anderen APs kommen
Ergebnisse & Termine	Das Endprodukt, an welche Funktion es geliefert wird und wann
Ressourcen	Die Expertenkapazität (Personentage), die das AP benötigt

Die „Out-of-Scope”-Zeile sieht trivial aus und leistet die schwerste Arbeit - sie verhindert redundante Arbeit und Revierkämpfe zwischen benachbarten Paketen.

2 · Terminplanung

Jetzt bekommt der PSP eine Zeit-Achse. Es gibt drei Terminplan-Sichten, von grob bis fein, und ein gutes Projekt nutzt alle drei.

2.1 Der Meilensteinplan - die Grobterminierung

Ein Meilenstein ist ein zeitkritisches Schlüsselergebnis mit einer Dauer von null - ein Moment, in dem etwas Vorzeigbares geschehen ist („Hardware getestet”, „Freigabe erteilt”, „System übergeben”). Der Meilensteinplan ist die Grobterminierung des gesamten Projekts und, ganz entscheidend, DAS objektive Leistungsmaß: Das Projekt ist genau dann „im Plan”, wenn seine Meilensteine an ihren Terminen erreicht werden.

Definiere fünf bis zehn Meilensteine für das ganze Projekt - nicht mehr. Die klassische Tabelle hat fünf Spalten: PSP-Nummer, Meilensteinname und dann drei Termine, die die Geschichte erzählen, wie der Plan sich verschoben hat.

PSP-Code	Meilenstein	Basisplan	Aktueller Plan	Ist
1.1	Projekt-START	01.01.2015	15.01.2015	20.01.2015
2.1	Hardware getestet	01.01.2016	01.02.2016	01.02.2016
3.2	Software getestet	31.03.2016	15.04.2016	-
4.3	System installiert	01.10.2016	01.10.2016	-
4.4	Kundenabnahme	01.10.2016	01.10.2016	-
1.5	Projekt-ENDE	31.10.2016	31.10.2016	-

• Basisplan - die Baseline, auf die du dich zuerst verpflichtet hast (eingefroren; niemals bearbeiten).
• Aktueller Plan - deine beste aktuelle Prognose (diese bewegt sich).
• Ist - der reale Fertigstellungstermin, eingetragen, sobald Meilensteine passiert sind.

Die Lücke zwischen Basis und aktuell ist deine ehrliche Aufzeichnung des Verzugs; die Lücke zwischen aktuell und Ist ist deine Aufzeichnung der Genauigkeit. Faustregeln: mindestens ein Meilenstein je Controlling-Zyklus; mach sie ergebnisgetrieben (etwas fertig, kein Meeting); und wähle nur Meilensteine, die du präzise dokumentieren kannst.

Hinweis

Pflicht- vs. Kür-Meilensteine. Manche werden von außen auf das Projekt gesetzt - vertragliche Termine, Kundenzahlungen, eine Zertifizierungsfrist. Die sind nicht verhandelbar. Die übrigen gibt sich das Team selbst als nützliche Prüfpunkte. Beide gehören auf den Plan; nur eine Sorte darfst du verschieben.

2.2 Das Gantt-/Balkendiagramm - das detaillierte Bild

Das Gantt-Diagramm (Balkendiagramm) ist der grafische, alltägliche Terminplan. Ein Balken pro Arbeitspaket, seine Länge zeigt die Dauer, aufgetragen auf einer Zeitachse; Phasen bekommen ihre eigenen Summenbalken; Verantwortliche stehen neben jedem Balken; und Meilensteine erscheinen als Rauten mit Datum. Abhängigkeitsverknüpfungen zwischen aufeinanderfolgenden APs zeigen, was auf was wartet.

Q1 2015 - Kick-off ◆  ·  Phase I: AP 1.2, AP 1.3 Ingenieur A

Q3 2015 - Phase II: AP 2.1 Hardware-Design Manager B

Q1 2016 - Übergabe ◆ Hardware getestet 1.1.16

Q4 2016 - Ende ◆ System übergeben 1.10.16

Ein Gantt liest sich als „wasserfallartige” Treppe: Jeder Phasenbalken beginnt dort, wo der vorige grob endet, mit Meilenstein-Rauten, die an Termine geheftet sind. In der Praxis führt man zwei Gantts - ein Gesamtdiagramm mit Phasen und Schlüsselaktivitäten und detaillierte Diagramme je Phase mit jeder Aktivität.

2.3 Der Netzplan und der kritische Pfad (CPM)

Der Netzplan (Critical Path Method, CPM) ist für komplexe Projekte, bei denen Abhängigkeiten mehr zählen als Termine. Jedes Arbeitspaket ist ein Knoten, der seine Dauer und vier Terminwerte zeigt, und Pfeile zeigen, welches Paket welches speist.

Ein Netzplan-Knoten (ein Arbeitspaket)
FA frühester Anfang	Dauer (Zeit)	FE frühestes Ende
SA spätester Anfang		SE spätestes Ende

Jedes Arbeitspaket trägt frühesten/spätesten Anfang und frühestes/spätestes Ende. Wo frühest gleich spätest ist, hat das Paket keinen Puffer - diese Knoten bilden den kritischen Pfad.

Der kritische Pfad (CPM) ist die Kette der Pakete mit null Puffer - die längste abhängige Sequenz durch das Projekt. Jede Verzögerung auf ihm verzögert das gesamte Projekt; Pakete abseits davon haben einen Puffer, den du ausgeben kannst. Es gibt vier Beziehungstypen zwischen Aktivitäten:

Beziehung	Bedeutung
Ende-Anfang	Aktivität 1 muss enden, bevor Aktivität 2 beginnen kann (der Normalfall - testen vor installieren)
Ende-Ende	Aktivität 1 muss enden, bevor Aktivität 2 enden kann
Anfang-Anfang	Aktivität 2 kann nicht starten, bevor Aktivität 1 startet
Anfang-Ende	Aktivität 2 kann nicht enden, bevor Aktivität 1 startet (selten)

2.4 PERT - Dauern schätzen, bei denen du unsicher bist

Echte Arbeitspakete haben keine sauberen Dauern. PERT (Program Evaluation and Review Technique) behandelt Unsicherheit mit Drei-Punkt-Schätzung: Statt eine Zahl zu raten, fragst du den AP-Verantwortlichen nach dreien - einer optimistischen, einer wahrscheinlichsten und einer pessimistischen Dauer - und mischst sie zu einer Erwartungszeit, die sich auf den wahrscheinlichsten Fall stützt, aber die Streuung respektiert.

ErwartungszeittE = (O + 4M + P) / 6

Standardabweichungσ ≈ (P − O) / 6

O · M · P optimistische, wahrscheinlichste, pessimistische Dauer

Kleines Rechenbeispiel. Für CERMEDES AP 3.2 „Design” sagt mein Ingenieur: bester Fall O = 8 Tage, wahrscheinlichster M = 12 Tage, schlechtester Fall P = 22 Tage. Dann:

• Erwartungszeit tE = (8 + 4×12 + 22) / 6 = (8 + 48 + 22) / 6 = 78 / 6 = 13 Tage.
• Standardabweichung σ ≈ (22 − 8) / 6 ≈ 2,3 Tage.

Also plane ich dieses Paket mit 13 Tagen ein, nicht mit den 12, die mein Ingenieur zuerst herausrutschen ließ - der lange Schwanz (22) zieht den Erwartungswert um einen Tag nach oben. Das σ von etwa 2,3 Tagen sagt mir, wie sehr ich ihm trauen darf: Ein Paket mit weiter O-bis-P-Spanne ist ein Paket, das man im Auge behalten muss.

3 · Ressourcen

3.1 Vom PSP zum Ressourcen- & Budgetplan

Der Ressourcen-/Budgetplan kommt direkt aus dem PSP: Wie viel welchen Ressourcentyps und welchen Kostentyps verbraucht jede Phase (später jedes AP)?

Dimension	Beispiele
Ressourcentypen	Marketing, Vertrieb, F&E, Operations, Finanzen, Steuern… (die Funktionen, die die Arbeit tun)
Kostentypen	HR / Personal, Reisen, Investitionen (Mock-ups, Maschinen, Software), Fremdleistungen (Berater, Recht, IT), Material

Du summierst diese je Phase, um einen Projektbudgetplan zu erhalten - und, ebenso wichtig, eine Basis für Kapazitätsprüfungen. Aufgabe des Plans ist es, zu beweisen, dass der Terminplan machbar ist, und Engpassressourcen zu markieren, bevor sie zubeißen.

3.2 Menschen kalkulieren: effektive Tage und Produktivität

Hier ist die Falle, die Terminpläne von Anfängern zerstört. Ein Mensch ist nicht das ganze Jahr verfügbar, und selbst wenn anwesend, ist er nicht jede Minute produktiv. Die groben Kennzahlen der deutschen Industrie aus dem Kurs:

Faustregel	Zahl
Effektive Arbeitstage	~200 Tage/Jahr (Rest verloren an Urlaub, Krankheit, Weiterbildung)
Produktivität bei Anwesenheit	~85 % (Meetings, Verwaltung, Kaffee, E-Mail)
FTE-Kosten Angestellte (white-collar)	~1.000 € / Tag (≈ 200.000 €/Jahr)
FTE-Kosten Gewerbliche (blue-collar)	~750 € / Tag (≈ 145.000 €/Jahr)

Achtung

Das 80-Stunden-Paket braucht 110 Stunden im Kalender. Weil nur ~85 % der Anwesenheitszeit produktiv sind, muss ein 80-Stunden-Arbeitspaket (nominell 2 Wochen) über rund 110 Stunden (etwa 2,75 Wochen) eingeplant werden. Planst du Arbeitspakete mit ihrem reinen Aufwand, läuft jedes einzelne zu spät - nicht durch jemandes Schuld, sondern weil du einen Fantasiemenschen kalkuliert hast, der nie in ein Meeting geht. Wandle immer Aufwand → Kalenderzeit um, bevor du einen Termin zusagst.

3.3 Kapazitätspläne und der Zugesagt-vs.-Geplant-Check

Zwei Sichten schließen den Kreis. Der Arbeitspaket-Kapazitätsplan detailliert je AP, wie viele Stunden jede Abteilung ihm schuldet. Der Abteilungs-Kapazitätsplan dreht es um - die Sicht der Abteilung auf alles, was das Projekt von ihr verlangt, Monat für Monat - und dort zeigt sich Überlastung.

Dann der entscheidende Check: zugesagt vs. geplant. Jede Abteilung hat eine bestimmte Kapazität zugesagt; der Terminplan plant eine bestimmte Last auf ihr. Trage beides auf.

Zugesagte Kapazitätwas die Abt. versprochen hat

vs

Geplante Lastwas der Terminplan braucht

→

Geplant übersteigt Zugesagt?umplanen - nicht hoffen

In der CERMEDES-Mechanikabteilung liegt die geplante Last in den mittleren Monaten um etwa 25 % über der zugesagten Kapazität. Diese Lücke ist kein Rundungsfehler - sie ist ein Signal, Arbeit umzuplanen oder Kapazität jetzt neu zu verhandeln, bevor die Pakete kollidieren.

4 · Die Menschen organisieren

Ein Projekt ist eine temporäre Änderung der funktionalen Organisationsstruktur des Unternehmens - für seine Dauer übernehmen Menschen Projekt-Rollen, die neben (und manchmal in Konflikt mit) ihren Linienjobs stehen. Ein Fachbereichsleiter wird innerhalb meines Projekts zum bloßen „Projektexperten”. Zu klären, wer wer ist, ist die halbe Miete.

4.1 Organisationsformen - wie viel Macht hat der PL?

Unternehmen beherbergen Projekte in einer von drei Gestalten, und der eigentliche Unterschied zwischen ihnen ist eine einzige Variable: wie viel Autorität der Projektleiter hält gegenüber den funktionalen (Linien-)Managern.

Form	Wie sie funktioniert	PL-Autorität	Am besten für
Funktional	Arbeit bleibt in den Abteilungen; Abteilungsleiter koordinieren	Niedrig / keine (ein Koordinator)	Routine-, Einzelfunktionsarbeit
Matrix (inkl. starke Matrix)	Funktionsübergreifendes Team; Mitarbeiter nach Fachgebiet gruppiert, aber an Projekte ausgeliehen	Mittel → hoch (starke Matrix gibt echtes Budget und Entscheidungsmacht)	Die meisten realen Projekte
Projektorientiert / Projekt	Unternehmen ist um Projekte herum organisiert; Teams oft räumlich zusammen	Hoch (große Unabhängigkeit, Ressourcen berichten an den PL)	Große, strategische, alles verschlingende Projekte

Für ein funktionsübergreifendes CERMEDES-Launch-Projekt ist eine starke Matrix die realistische Heimat: Ingenieure gehören weiterhin ihren Abteilungen, aber ich bekomme genug Budget und Entscheidungsmacht, um wirklich zu steuern.

4.2 Die vier Kernrollen

Rolle	Verantwortet	Kernpunkt
Projekt-Auftraggeber (Sponsor)	Strategische Richtung & Passung	Setzt Ziele, ernennt den PL, leitet das Steuerungsgremium, stellt die Finanzierung, genehmigt das Ergebnis. Der Eigentümer des Projekts.
Steuerungsgremium (Control Board)	Strategische Entscheidungen im Auftrag des Sponsors	Vertritt alle beteiligten Funktionen; löst Zielkonflikte und Priorisierungen; hört regelmäßig den Statusbericht des PL.
Projektleiter (PL)	Operative Lieferung	Verantwortlich für das Erreichen der Ziele; plant, organisiert, koordiniert, steuert; fachliche Führung, keine disziplinarische. Es kann nur einen geben.
AP-Verantwortlicher	Ein Arbeitspaket	Operative Verantwortung im eigenen Fachgebiet; entwirft und liefert sein AP.

Hinweis

Fachliche, nicht disziplinarische Führung. Der PL leitet die Arbeit, kann Teammitglieder aber meist nicht einstellen, entlassen oder ihre Gehälter festlegen - das bleibt bei den Linienmanagern. Genau deshalb braucht die Matrix die aktive Rückendeckung des Sponsors und eine klare RACI: Die Autorität des PL ist geliehen, nicht besessen.

4.3 RACI - wer tut was zu jeder Aufgabe

Die RACI-Matrix bildet jedes PSP-Element gegen jede Rolle mit vier Buchstaben ab. Die eherne Regel: genau ein „A” pro Aufgabe.

• R - Responsible (durchführend): erledigt die eigentliche Arbeit (können mehrere sein).
• A - Accountable (rechenschaftspflichtig): letztlich verantwortlich, zeichnet das Ergebnis ab - nur einer pro Aufgabe.
• C - Consulted (konsultiert): Experten, deren Input eingeholt wird (zweiseitig).
• I - Informed (informiert): über den Fortschritt auf dem Laufenden gehalten (einseitig).

PSP	Arbeitspaket	Sponsor	PL	Tim	Marc	Joe
1	Projekt (gesamt)	A	R
2	HW-Entwicklung	I	A	R	C
2.1	HW-Spezifikation	I	A	R	C	C
2.2	HW-Design	I	A	R	C
3	SW-Entwicklung	I	A	R		C

Eine Zeile zu lesen sagt dir sofort, ob eine Aufgabe einen Eigentümer hat (ein A), verwaist ist (kein A - gefährlich) oder verworren (zwei A - ein Streit, der nur darauf wartet, auszubrechen).

4.4 Der Kommunikationsplan

Kommunikation ist kein weiches Extra - sie ist die Ursache Nummer eins für Projektversagen (eine Umfrage schreibt ~57 % der Fehlschläge einem Kommunikationszusammenbruch zu; fehlende Planung/Ressourcen kommt mit ~39 % an zweiter Stelle). Also planst du sie wie alles andere: welche Meetings, mit wem, wie oft, wo.

Meeting	Ziel	Wer	Takt
Sponsor-Meeting	Status, Ergebnisse genehmigen, Projektmarketing	Sponsor + PL	Halbjährlich
Steuerungsgremium	Status, Meilensteine genehmigen, aktuelle Themen	PL + Gremium + zentrale TMs	Vierteljährlich
Jour fixe	3-Minuten-Status pro Person, nächster Meilenstein	Kernteam	Monatlich
Arbeitsgruppe	Nächsten Meilenstein vorbereiten, aktuelle Themen	PL + Teilteam	Zweiwöchentlich

(Vereinbart außerdem ein gemeinsames Datei-/Dokumentationssystem - ein SharePoint oder Äquivalent - damit das Gedächtnis des Projekts an einem Ort lebt.)

Tipp

Das Eisbergmodell. Nur ein Splitter der Kommunikation liegt über der Wasserlinie - die Sachebene: gesprochene Worte, Logik, Argumente, Daten. Der Großteil sitzt darunter - die Beziehungsebene: Gefühle, Bedürfnisse, Überzeugungen, Wertschätzung, der Wunsch, geschätzt zu werden. Die meisten „Kommunikationsprobleme” in einem Projekt sind gar keine Sachstreitigkeiten; es sind unausgesprochene Beziehungssignale. Ein PL, der nur die Fakten über der Oberfläche argumentiert, verliert immer wieder gegen die neun Zehntel, die er nicht sieht.

4.5 Teamentwicklung - Tuckmans Phasen

Teams kommen nicht fertig an; sie durchlaufen vorhersehbare Phasen. Sie zu kennen bewahrt dich davor, im hässlichen Mittelteil in Panik zu geraten.

Forminghöflich, unsicher

→

StormingKonflikt, Rangeleien

→

NormingRegeln setzen sich

→

Performingechter Output

→

Adjourningabschließen, auflösen

Tuckmans Phasen. Storming ist kein Versagen - es ist das Team, das aushandelt, wie es arbeiten wird. Die Leistung sinkt tatsächlich, bevor sie steigt; ein PL, der den Einbruch erwartet, steuert hindurch, statt Leute zu feuern.

Zwei Linsen helfen dir, durch diese Phasen zu führen:

• Maslows Bedürfnishierarchie - Motivation stapelt sich von Grundbedürfnissen (Essen, Ruhe) über Sicherheit, Zugehörigkeit, Wertschätzung/Respekt bis zur Selbstverwirklichung (Kreativität, Problemlösen). Du kannst niemanden mit „interessanter Arbeit” motivieren, wenn er seinen Job als unsicher empfindet. Bediene zuerst die unteren Sprossen.
• Situatives Führen - passe deinen Stil an Kompetenz + Zuversicht der Person bei der Aufgabe an:

Teammitglied ist…	Führe durch…	Stil
Inkompetent & unsicher	starke Anleitung, wenig Unterstützung	Anweisen (Instruct)
Inkompetent, aber willig/zuversichtlich	starke Anleitung und starke Unterstützung	Verkaufen (Sell)
Kompetent, aber unsicher/unwillig	starke Unterstützung, wenig Anleitung	Beteiligen (Participate)
Kompetent, zuversichtlich & willig	wenig Anleitung, wenig Unterstützung	Delegieren (Delegate)

5 · Stakeholder-Management

5.1 Warum es zählt: Erfolg = Ergebnis × Akzeptanz

Das bestgeplante Projekt kann trotzdem von Menschen gekippt werden, die es einzubeziehen vergaß. Die Bewertungsformel des Kurses für (besonders öffentliche) Projekte sagt es sauber:

ProjekterfolgSuccess = Result × Acceptance

Result (Ergebnis) Umfang, Termine, Budget, Qualität - die „harte” Lieferung

Acceptance (Akzeptanz) ob die Stakeholder insgesamt es tatsächlich mittragen

Weil es ein Produkt ist, macht eine Akzeptanz von null das Ganze zu null, wie brillant das Ergebnis auch sei. Der Fall IKEA Altona ist das Lehrbuchbeispiel: IKEA wollte seinen ersten Innenstadt-Store (ein 80-Mio.-EUR-Bau über 3,5 Jahre). Lokaler Widerstand an der Basis, Demonstrationen und ein Bürgerentscheid erzwangen einen Stopp der Planung. IKEA reagierte, indem es Stakeholder-Management zur obersten Priorität machte - öffentliche Workshops und Anhörungen, eine Online-Plattform, eine Vor-Eröffnungsparty und Gutscheine für Anwohner, Co-Werbung mit lokalen Händlern, kostenloses WLAN für die Nachbarschaft - und drehte es zu 77 % Zustimmung in der finalen Abstimmung, gefolgt von einem reibungslosen Bau ohne merklichen Protest. Dasselbe Gebäude; ein völlig anderes Ergebnis, getrieben allein vom „Akzeptanz”-Faktor.

Achtung

Die Änderungskosten steigen etwa um das Zehnfache je Phase. Eine Änderung ist in der Konzeptphase billig und brutal teuer, sobald man in der Produktion ist - grob zehnmal mehr mit jeder Phase, die du fortschreitest. Ein „vergessener” oder „abgehängter” Stakeholder, der spät auftaucht, ärgert dich nicht nur; er erzwingt genau diese späten, zehnfach teuren Änderungen. Stakeholder früh zu managen ist billiger, als ihre Einwände spät zu reparieren.

5.2 Die Einfluss-×-Haltung-Matrix

Kartiere jeden Stakeholder nach wie viel Einfluss er hat und seiner Haltung zum Projekt - das sagt dir, wie hart du ihn bearbeiten musst.

Hoher Einfluss · Kritisch eng managen

• Gewinne sie oder halte sie in Schach - sie können das Projekt stoppen

Hoher Einfluss · Unterstützend eng managen

• Deine Fürsprecher - halte sie eingebunden und ausgerüstet

Geringer Einfluss · Kritisch zufriedenstellen

• Bedenken adressieren, aber nicht überinvestieren

Geringer Einfluss · Unterstützend informieren / minimaler Aufwand

• Leichte Updates genügen

Die beiden Quadranten mit hohem Einfluss sagen beide „eng managen” - ob ein mächtiger Stakeholder das Projekt liebt oder hasst, du kannst es dir nicht leisten, ihn zu ignorieren. Der Aufwand folgt zuerst dem Einfluss, dann der Haltung.

5.3 Der Stakeholder-Management-Plan

Mach aus der Matrix eine Aktionstabelle - jeder wichtige Stakeholder bekommt einen benannten Verantwortlichen und eine konkrete Maßnahme:

Nr.	Stakeholder	Beziehung / Interesse	Priorität	Maßnahme	Verantwortlich
01	CEO	Positives EBIT	Informiert halten	Vierteljährliche Statusnotiz	Sponsor
02	Erstkunde	Premiumkunde (hoch positiv)	Eng managen	Zu Kick-off & Übergabe einladen	Sponsor / PL
03	Leiter F&E	Neue HMI-Technologie (hoch positiv)	Eng managen	Informiert halten, zu Prototyp-Tests einladen	PL
04	Betriebsrat	Skeptisch gegenüber Personalfolgen	Zufriedenstellen	Frühes Briefing, Bedenken adressieren	PL

6 · Risikomanagement

6.1 Der Prozess

Ein Projekt-Risiko ist ein unsicheres Ereignis oder Zustand, der, wenn er eintritt, ein Projektziel beeinflusst (Umfang, Termine, Kosten, Qualität) - positiv oder negativ. Du managst es als Schleife:

Identifizierenbenennen, Ursache & Wirkung

→

BewertenWahrscheinlichkeit × Auswirkung

→

Maßnahmen planenpräventiv & korrektiv

→

Steuernüberwachen & neu bewerten

Der Risiko-Regelkreis. Du identifizierst per Brainstorming, Experteninterviews, vergangenen Lessons Learned, SWOT, Ishikawa (Fishbone) oder FMEA; dann bewertest, planst und steuerst du weiter - denn Risiken ändern sich, während das Projekt voranschreitet.

6.2 Bewerten: Wahrscheinlichkeits- und Auswirkungsskalen

Bewerte jedes Risiko auf zwei Achsen mit vereinbarten Wortschwellen (die Zahlen sind die Berechnungsfaktoren).

Wahrscheinlichkeitsskala:

Stufe	Bereich	Faktor
Sehr gering	unter 15 %	0,0
Gering	15-30 %	0,3
Mittel	30-50 %	0,5
Hoch	50-85 %	0,7
Sehr hoch	über 85 %	1,0

Auswirkungsskala (an die Toleranz deines Sponsors anpassen):

Ziel	Gering	Mittel	Hoch	Sehr hoch
Kosten	unter 10 % Anstieg	10-20 % Anstieg	20-40 % Anstieg	über 40 % Anstieg
Termine	weniger als 5 % Zeitzuwachs	5-10 % Anstieg	10-20 % Anstieg	über 20 % Anstieg
Umfang	kleinere Bereiche betroffen	größere Bereiche betroffen	Reduktion für Sponsor inakzeptabel	Ergebnis faktisch nutzlos

6.3 Die Wahrscheinlichkeit-×-Auswirkung-Matrix

Multipliziere die beiden, und du erhältst eine Ampel-Priorität.

Hohe Wahrscheinlichkeit · Geringe Auswirkung gelb

• „Quick-and-dirty”-Fix - billig, mach es und geh weiter

Hohe Wahrscheinlichkeit · Hohe Auswirkung rot

• Aktiv managen - das sind die, die wehtun

Geringe Wahrscheinlichkeit · Geringe Auswirkung grün

• Nichts tun (vorerst) - nur ein Auge drauf halten

Geringe Wahrscheinlichkeit · Hohe Auswirkung gelb

• Eng überwachen - selten, aber gefährlich, wenn es eintritt

Grün = nichts tun, Gelb = beobachten oder billig fixen, Rot = aktiv managen. Die rote Ecke (wahrscheinlich und schmerzhaft) ist, wohin deine Aufmerksamkeit und dein Risikobudget gehen.

6.4 Die vier Reaktionsstrategien

Vermeiden (Avoid)die Bedrohung eliminieren

Übertragen (Transfer)an Dritte abgeben (versichern, auslagern)

Vermindern (Mitigate)Wahrscheinlichkeit oder Auswirkung senken

Akzeptieren (Accept)anerkennen, nur bei Eintritt handeln

Vier Arten zu reagieren. „Übertragen” verschiebt die Auswirkung und die Verantwortung für die Reaktion auf jemand anderen; „Akzeptieren” ist ein bewusster Kosten-Trade-off, keine Faulheit.

6.5 Das Risikoregister und das Risikobudget

Alles landet in einer lebenden Tabelle:

#	Risiko	Grundursache	Auswirkung	Wahrsch.	Status	Budget	Maßnahme	Verantwortlich
1	Neueinstellungen verzögert	HR kann Kapazität nicht zusagen	2 Wochen	40 %	🟢	-	Akzeptieren	PL
2	Gewerbeerlaubnis verzögert	Unterlagen zu spät, Recht hat keine Kapazität	4 Wochen	80 %	🔴	10.000 €	Externen Rechtsberater engagieren	AP-Verantw.
3	Gewerkschaft ruft zum Streik auf	Info-Leck vor der Verhandlung	50.000-250.000 €	20 %	🟡	-	Eng überwachen, Eingeweihte wenige halten	PL

Tipp

Halte ein Risikobudget vor. Ernste Risiken (die roten und die teuren gelben) brauchen zurückgelegtes Geld, um ihre Reaktion zu finanzieren - etwa die 10.000 € für externe Rechtshilfe in Zeile 2. Ein Projekt ohne Risikobudget muss genau im schlechtesten Moment beim Sponsor betteln gehen. Lege für die Risiken zurück, die du siehst; für die, die du nicht siehst, brauchst du trotzdem Urteilsvermögen.

7 · Das Projekt abschließen

Projekte haben ein definitives Ende - und schlecht abzuschließen verschwendet alles, was du aufgebaut hast. Die Abschluss-Checkliste:

Das Ergebnis übergebenan Sponsor, Linienfunktion oder Nachfolger

Während der Übergabe schulen & unterstützendamit das Ergebnis wirklich genutzt wird

Dokumentation vervollständigen & sicherndas Gedächtnis des Projekts

Lessons-Learned-Workshopernten, was zu wiederholen / zu vermeiden ist

Erfolg feiern · das Team verabschiedenMenschen erinnern sich an das Ende

Den Projektleiter entlastendas Projekt ist formal vorbei

Der Abschluss, der Reihe nach. Der Lessons-Learned-Workshop ist der, den alle überspringen, und der, der sich auszahlt - er ist buchstäblich ein Input für die Risikoidentifikation des nächsten Projekts.

Controlling - der Faden, der durch alles läuft

Eine letzte Idee, die Kapitel verbindet: Während all das oben geplant wird, wird das Projekt zugleich gesteuert (kontrolliert). Zwei alltägliche Instrumente:

• Kostenkontrolle („Burn Rate”) - trage die kumulierten Ist-Kosten vs. Plan über die Phasen auf. Wenn die Ist-Kosten nach Phase 4 bereits das geplante Budget für Phase 5 übersteigen (eine ~16-%-Überschreitung im CERMEDES-Beispiel), hast du ein Problem, das du Monate vor dem Ernstfall sehen kannst.
• Leistungsmaße - erreichte Meilensteine, produzierte Ergebnisse/Artefakte, eine Schätzung des AP-Fertigstellungsgrads und ausgegebenes-Budget-vs.-verstrichene-Zeit. Das ausgefeilteste davon ist die Earned-Value-Analyse, die Termine und Kosten in eine einzige Kennzahl „wie viel Wert haben wir bisher tatsächlich erwirtschaftet” zusammenführt - die ehrliche Antwort auf „sind wir wirklich im Plan?”.

Wiederholungs-Zusammenfassung

Tipp

Die Ein-Minuten-Zusammenfassung

• Plane rückwärts von den Ergebnissen → baue den PSP (Projekt → 4-8 Phasen → je 5-10 Arbeitspakete, mit PSP-Codes); jedes AP bekommt eine SMART-Mini-Spec mit explizitem Out-of-Scope.
• Terminiere in drei Sichten: einen Meilensteinplan (5-10 ergebnisgetriebene Prüfpunkte mit Dauer null; Basis-/Aktuell-/Ist-Termine), ein Gantt (ein Balken je AP) und einen Netzplan/CPM (der kritische Pfad ist die Kette ohne Puffer; vier Beziehungstypen). Schätze unsichere Dauern mit PERT: tE = (O + 4M + P) / 6, σ ≈ (P − O) / 6.
• Ressourcen aus dem PSP. Wandle Aufwand → Kalenderzeit um: ~200 effektive Tage/Jahr und ~85 % Produktivität bedeuten, dass ein 80-Stunden-Paket ~110 Stunden eingeplant braucht. Führe den Zugesagt-vs.-Geplant-Kapazitätscheck durch und plane um, wenn Geplant Zugesagt übersteigt.
• Organisiere: wähle eine Form (funktional / Matrix / projektorientiert) danach, wie viel Autorität der PL braucht; besetze die vier Rollen; schreibe eine RACI mit genau einem Accountable je Aufgabe. Plane Kommunikation bewusst - sie ist die Fehlerursache Nr. 1 - und denk an den Eisberg (Sachebene oben, Beziehung unten).
• Stakeholder: Success = Result × Acceptance; kartiere Einfluss × Haltung und gib jedem eine Maßnahme und einen Verantwortlichen (die IKEA-Lektion).
• Risiko: Identifizieren → Bewerten (Wahrscheinlichkeit × Auswirkung) → Planen (Vermeiden / Übertragen / Vermindern / Akzeptieren) → Steuern; führe ein Risikoregister und ein Risikobudget.
• Schließe sauber ab: übergeben, schulen, Doku sichern, Lessons Learned durchführen, feiern, das Team entlasten. Und steuere durchgehend - Burn Rate und Earned Value.

Weiter: Agiles Projektmanagement → - der andere Weg, ein Projekt zu führen, wenn sich die Anforderungen ständig ändern.