Einheit 15. Vom Epic-Plan zur vollständigen Projektschätzung: Gantt-Diagramm, Aufgaben- und Risikoschätzung, Teamkosten

3. November 2026 · vorbereitetes Skript zur Einheit · ≈ 1 Std. 30 Min. (geplant). Dieses Material beruht nicht auf einem Transkript. Es wurde auf Wunsch des Dozenten vor der Einheit erstellt und setzt die Logik der Einheiten 01–14 fort, vor allem 05, 12, 13 und 14. Durchgängiges Beispiel ist eine Roboterzelle mit Manipulator, Computer Vision und KI, die on-premise auf NVIDIA Jetson und ROS 2 läuft. Alle Dauern, Sätze und Beträge sind Lehrbeispiele, keine Marktdaten. Sie wurden in einem Excel-Modell und einem Monte-Carlo-Skript berechnet (siehe „Materialien der Einheit“). Nach der Einheit wird der tatsächliche Verlauf als eigener, datierter Block ergänzt; dieser Text wird nicht umgeschrieben. Redaktionelle Ergänzungen sind gesondert gekennzeichnet.

0. Einordnung in den Kurs

Einheit 14 endete mit einem detaillierten Plan für EPIC 1 mit 29 Schritten und den Gates G1–G4. Dort hieß es auch: Ein Embedded-Projekt mit Mechanik und Hardware hat nie nur ein Epic — mindestens drei. Für diese Einheit waren EPIC 2 und folgende Epics, das Gantt-Diagramm, die Teambildung und die Profile der Ingenieure angekündigt. Heute schließen wir die Kette, die der Kurs seit September aufbaut:

Ablauf der Einheit: Fall → Epics und PSP → Aufgabenschätzung → Gantt-Diagramm → Risiken → Team und Kosten → vollständige Schätzung und vollständiger Zeitplan → Praxistipps.

1. Der Fall: eine Roboterzelle mit CV+KI, on-premise, Jetson, ROS 2

Wir setzen die Linie aus Einheit 06 fort (ein Robotermanipulator mit eigenem Endeffektor), nehmen aber eine andere, stärker produktionsnahe Anfrage. Der fiktive Kunde fertigt Metall- und Kunststoffteile. Er möchte eine Pilotzelle:

• ein kollaborativer 6-DoF-Roboter (Zukaufteil) greift Teile aus einem Tray;
• Kameras und ein CV/KI-Modell erkennen Teiletyp, Lage und sichtbare Fehler;
• der Roboter sortiert die Teile in Behälter, Ausschuss separat;
• der Bediener sieht Aufträge, Alarme und Berichte auf einem HMI;
• alle Daten bleiben im Werk: keine Cloud, Modelle werden auf dem eigenen Server des Kunden trainiert (on-premise);
• die Inferenz läuft auf einem NVIDIA Jetson direkt bei den Kameras;
• die Integrationsplattform ist ROS 2: Der Kunde betreibt bereits andere Zellen mit ROS 2 und will einen einheitlichen Stack.

Randbedingungen sind keine Anforderungen

Einheit 06 hat gewarnt: Ein Technologiename ist für sich noch keine Anforderung. Hier kommen Jetson, ROS 2 und on-premise jedoch vom Kunden, und zwar aus guten Gründen: Datenpolitik, vorhandener Stack, Serviceteam. Deshalb halten wir sie als Design Constraints (Entwurfsrandbedingungen) mit Begründung fest, nicht als funktionale Anforderungen:

Redaktionelle Ergänzung. Die Risikobeurteilung von Maschinen erfolgt nach ISO 12100; Sicherheitsanforderungen an Industrieroboter und Roboteranwendungen enthalten ISO 10218-1:2025 und ISO 10218-2:2025 (dritte Ausgabe, Februar 2025). Sicherheitsfunktionen von Steuerungen werden nach ISO 13849-1 bewertet. Die konkrete Normenliste legt der Safety-Ingenieur für die jeweilige Anwendung fest; im Kurs sind sie nur die Reference Basis (Einheit 05), kein fertiges Ergebnis.

Redaktionelle Ergänzung zu ROS 2. Aktuelle LTS-Distributionen sind Jazzy Jalisco (Mai 2024) und Lyrical Luth (22. Mai 2026, Support bis Mai 2031). Tier-1-Plattform für Lyrical ist Ubuntu 26.04. Die Ubuntu-Basis im JetPack Ihres Jetson-Moduls kann von der Tier-1-Plattform der gewählten Distribution abweichen. Dann muss man zwischen Containern, einem Build aus den Quellen oder einer anderen Distribution wählen. Das ist eine klassische PoC-Frage; Einheit 14 formulierte sie so: „Gibt es für dieses Betriebssystem einen ordentlichen Compiler?“

2. Von der Schrittliste zum PSP und drei Epics

In Einheit 14 war der Plan für EPIC 1 eine Liste von Schritten. Für ein Gantt-Diagramm und eine Kostenschätzung muss jede Zeile ein Arbeitspaket mit fünf Attributen werden:

1. ID und Name — was genau wir tun;
2. Dauer — drei Schätzungen O / M / P (Abschnitt 3);
3. Abhängigkeiten — wonach die Aufgabe beginnen kann;
4. Rollen und Auslastung — wer mit welchem Anteil einer Vollzeitstelle (FTE) daran arbeitet;
5. Typ — Arbeit, Warten oder Kontrollpunkt (Gate).

In unserem Fall zerfällt das Projekt, wie in Einheit 14 vorhergesagt, in drei Epics:

Der vollständige PSP umfasst 34 Arbeitspakete. Hier eine gekürzte Ansicht (die vollständige Tabelle mit allen Feldern steht in der Excel-Arbeitsdatei):

Rollenkürzel: PM — Delivery / Engineering Manager, SA — Systemarchitekt, ROS — Robotik-Ingenieur (ROS 2, MoveIt 2), CV — CV/ML-Ingenieur, SW — Software-Ingenieur (HMI, On-prem, MLOps), FW, HW, ME — Firmware-, Hardware-, Mechanikingenieur, SAF — Safety-Ingenieur, QA — V&V-Ingenieur, TECH — Montagetechniker (Einheit 14), PROC — Procurement Manager.

Drei praktische Regeln für den PSP:

• Paketgröße. Ein Arbeitspaket wird geschätzt, wenn es sich in einigen Tagen oder Wochen erledigen und prüfen lässt. Sagt ein Ingenieur „drei Monate“, muss das Paket weiter zerlegt werden. Ausnahme sind Warteaufgaben: Die Leiterplattenfertigung dauert 3–5 Wochen, sie zu zerlegen ist sinnlos.
• Warten bekommt eine eigene Zeile. Fertigung, Versand und Verzollung haben kaum Aufwand, aber echte Kalenderdauer. Werden sie nicht getrennt ausgewiesen, verbrauchen sie Zeit, die im Plan nicht vorhanden ist.
• Integration bekommt eine eigene Zeile. Die Summe der Teilsysteme ist nicht das System: Das Zusammenfügen kostet echte Zeit (bei uns Paket 3.1, etwa drei Wochen).

3. Aufgabenschätzung: von „2–10 Tagen“ zu PERT

Wer schätzt

Einheit 12 hat das Problem der Verantwortung für eine Schätzung benannt: Ein externer Experte unterschätzt eine Aufgabe womöglich, weil ein anderer sie ausführt. Daraus folgt die Regel: Es schätzt, wer die Arbeit ausführen wird, und es prüft, wer Ähnliches schon gemacht hat. Gibt es noch kein Team, schätzen das Pre-Sale-Kernteam (Einheit 06) und bei Bedarf bezahlte externe Experten. Ihre Schätzungen werden als Annahmen markiert und nach der Einstellung überprüft.

Drei Punkte statt einem

Ein Ingenieur, der „2 bis 10 Tage“ sagt, hat bereits die optimistische (O) und die pessimistische (P) Schätzung genannt. Es fehlt die wahrscheinlichste (M). PERT verbindet sie so:

E = (O + 4M + P) / 6, σ = (P − O) / 6,

wobei E die erwartete Dauer und σ ein Maß ihrer Unsicherheit ist. Beispiele aus unserem PSP:

Die Dauern sind in Arbeitstagen angegeben. Beachten Sie: E liegt immer von M in Richtung P verschoben, weil Risiken „nach rechts“ im Engineering länger sind als „nach links“. Eine Aufgabe kann nicht in weniger als null Tagen fertig sein, sich aber beliebig verzögern.

Redaktionelle Ergänzung. PERT (Program Evaluation and Review Technique) wurde Ende der 1950er-Jahre für das Polaris-Programm der US Navy entwickelt. Die Formel E = (O + 4M + P) / 6 nähert eine Beta-Verteilung an; sie ist kein Naturgesetz. Nützlich ist sie, weil sie zwingt, eine Spanne zu nennen, und die Asymmetrie des Risikos sichtbar macht.

Aufwand, Dauer und Kalender sind drei verschiedene Zahlen

Schätzt ein Ingenieur in „idealen Stunden“ — ohne Meetings, Reviews und Kontextwechsel —, wird die Schätzung durch einen Fokusfaktor geteilt (meist 0,7–0,8). In unserem Modell sind O/M/P bereits in realen Arbeitstagen angegeben.

Wie man KI-Aufgaben schätzt

Modellgenauigkeit lässt sich nicht in Tagen schätzen: Niemand weiß im Voraus, wie viele Tage es braucht, um 99,0 % bei spiegelnden Metallteilen zu erreichen. Deshalb schätzt man das Experiment, nicht das Ergebnis:

• Paket 2.16 ist „Datensatz v1 + drei Iterationen Daten → Training → Bewertung“, zeitlich begrenzt (Time-Box);
• die nach drei Iterationen erreichte Genauigkeit geht ins Review: Entweder ist die Anforderung erfüllt, oder es greift Risiko R2 mit eigenem Plan (Abschnitt 5);
• PoC-A (1.6) beseitigt die Hauptunsicherheit früher: ob das Modell nach der TensorRT-Optimierung auf dem Jetson in 150 ms passt.

4. Das Gantt-Diagramm: Abhängigkeiten, kritischer Pfad, Gates

Wie man es aufbaut

1. Abhängigkeiten festlegen. Meist sind es Ende-Anfang-Beziehungen: Aufgabe B beginnt, nachdem A beendet ist.
2. Vorwärtsrechnung: Der früheste Anfang ES einer Aufgabe ist das späteste früheste Ende ihrer Vorgänger; frühestes Ende EF = ES + E.
3. Rückwärtsrechnung: Vom Projektende zurück erhält man den spätesten Anfang LS und das späteste Ende LF.
4. Puffer (Float) = LS − ES. Aufgaben ohne Puffer bilden den kritischen Pfad: Jede Verzögerung darauf verschiebt das gesamte Projekt.
5. Gates und Abnahmen (FAT, SAT) als Meilensteine markieren.

Was das Diagramm zeigt

Der kritische Pfad verläuft durch Hardware und Mechanik, nicht durch Software:

1.1 → 1.2 → 1.3 → 1.4 → 1.6 → 1.8 → 2.1 → 2.2 → 2.4 → 2.6 → 2.7 → 2.8 → 2.13 → 2.14 → 3.1 → 3.3 → 3.4 → 3.5 → 3.6 → 3.7 → 3.8.

Die Länge des kritischen Pfads nach PERT beträgt 195,7 Arbeitstage ≈ 39,1 Wochen. Dagegen hat die Zellsoftware (2.15) 38 Tage Puffer, Datensatz und Training (2.16) 54 Tage, der On-prem-Server (2.17) 65 Tage. Das illustriert die These aus Einheit 05: Ein Gantt-Diagramm im Embedded-Bereich hängt von Dingen ab, die durch einen weiteren Software-Ingenieur nicht schneller werden.

Redaktionelle Ergänzung. Das Brookssche Gesetz („Wer einem verspäteten Softwareprojekt Personal hinzufügt, verspätet es weiter“, F. Brooks, The Mythical Man-Month, 1975) gilt hier in verschärfter Form: Die Leiterplattenfertigung beim Lieferanten wird nicht kürzer, egal wie viele Programmierer man hinzufügt.

Positionen mit langer Lieferzeit haben Puffer, wenn man sie rechtzeitig bestellt. Paket 2.3 (Cobot, Serienmodul Jetson, Sicherheitsscanner) startet direkt nach G4 und hat 40,8 Tage Puffer. Bestellt man den Cobot „aus Gewohnheit“ erst nach dem Mechanik-Review (2.7), wird dieses Paket selbst kritisch und verschiebt das Projekt. Das ist der erste Praxistipp (Abschnitt 8).

Gates im Diagramm:

Alles rechts eines Gates ist ein bedingter Plan. Einheit 13 erinnerte daran, dass Gates alle Regeln ändern. Deshalb planen wir den nahen Horizont detailliert (EPIC 1 tagesgenau) und den fernen in großen Paketen. Nach jedem Gate wird der Plan verfeinert (Rolling Wave Planning). So verengt sich der Unsicherheitskegel in der Praxis.

5. Projektrisiken schätzen: Register, Reserve und Monte Carlo

HARA und Projektrisikoregister sind verschiedene Tabellen

Beide Tabellen entstehen gemeinsam in einem Termin des gesamten Ingenieurteams (Paket 1.4). Die Mechanik ist gleich, die beantworteten Fragen sind verschieden.

Risikoregister des Falls

EMV (Expected Monetary Value) = Wahrscheinlichkeit × Auswirkung. Die naive EMV-Summe beträgt 27,3 Tage. Das ist jedoch eine Überschätzung: R1, R4 und R7 treffen Aufgaben mit großem Puffer und verschieben das Projektende nicht. Die Wirkung eines Risikos auf den Termin hängt also davon ab, wo es im Gantt-Diagramm liegt. Von Hand lässt sich das kaum berechnen, deshalb simuliert man.

Monte Carlo: der Termin als Wahrscheinlichkeit

Die Idee ist einfach: Das Projekt wird 20 000-mal „durchgespielt“. In jedem Lauf wird jede Dauer zufällig aus ihrer Spanne O…P gezogen (mit einer PERT-Verteilung), jedes Risiko tritt mit seiner Wahrscheinlichkeit ein, und der kritische Pfad wird neu berechnet. Das Ergebnis ist kein einzelner Termin, sondern eine Verteilung von Terminen.

Stufen vom naiven zum ehrlichen Termin:

Drei Schlussfolgerungen:

1. Die Schätzung mit M ist die optimistischste der „vernünftigen“. Schon ohne Risiken trifft sie nur mit etwa 7 % Wahrscheinlichkeit ein, im vollständigen Modell mit weniger als 1 %. Der PERT-E-Plan wird im vollständigen Modell nur in etwa 5 % der Läufe eingehalten (Abb. 15.3).
2. Parallele Zweige schieben den Termin nach rechts (Merge Bias). Die klassische PERT-Formel für einen kritischen Pfad ergibt σ ≈ 7,3 Tage und P80 ≈ 201,8 Tage. Die Simulation liefert 204,1: Parallele Zweige, die in manchen Läufen kritisch werden, ziehen den Termin nach hinten. So liegt PoC-B (1.7) in 36 % der Läufe auf dem kritischen Pfad, die Mechanikfertigung (2.9) in 22 %.
3. Unabhängige Aufgaben sind eine Illusion. Die Schätzungen eines Teams irren in dieselbe Richtung: gleicher Optimismus, gleicher Markt, derselbe Kunde. Ein gemeinsamer Multiplikator auf alle Arbeitsaufgaben verbreitert die Verteilung. Deshalb legt ein erfahrener Auftragnehmer bei T&M^ einen Korridor von ±30 % fest (Einheit 13), obwohl eine „saubere“ Simulation unabhängiger Aufgaben einen engeren ergibt.

Redaktionelle Ergänzung. In der PMI-Terminologie ist die Reserve für bekannte Risiken aus dem Register die Contingency Reserve und die Reserve für Unbekanntes die Management Reserve; Letztere gehört meist nicht zur Baseline und wird vom Management gesteuert. Die Parameter des gemeinsamen Optimismusfaktors (0,95 … 1,25) sind in unserem Modell eine Lehrannahme, keine Statistik. Ein reales Unternehmen kalibriert ihn an der Historie der eigenen Projekte: am Verhältnis von tatsächlichen zu geschätzten Dauern.

6. Das Team und seine Kosten

Teambildung aus dem Gantt-Diagramm

Die Teamzusammensetzung ist keine Wunschliste, sondern eine Folge des PSP: Jede Rolle erscheint dann, wenn ein Arbeitspaket sie verlangt. Das Auslastungsdiagramm (Resource Histogram) erhält man, indem man die FTE aller Aufgaben je Woche aufsummiert.

Was daraus für die Teambildung folgt:

• Das Pre-Sale-Kernteam (SA, ROS, CV, PM) wird ab Woche eins gebraucht. Genau diese Personen haben das Problem des Kunden gesehen (Einheit 06).
• Die erste Woche einer Rolle ist ihre Einstellungsfrist. Der HW-Ingenieur wird ab Woche 4 gebraucht, der Mechaniker ab Woche 6, FW ab Woche 10, der Techniker ab Woche 13. Dauert die Einstellung mehrere Wochen, wird die Stelle schon im Pre-Sale ausgeschrieben. Sonst verschiebt sich der Projektstart (Einheit 06: „Keinen Start am Montag versprechen, wenn es das Team noch nicht gibt“).
• Eine Spitze über 1,0 FTE verlangt eine Entscheidung: eine zweite Person, das Verschieben einer Aufgabe im Puffer oder ein externer Auftragnehmer.
• Auch ein Auslastungseinbruch verlangt eine Entscheidung: Während der Fertigung wechseln Leute vorübergehend in ein anderes Projekt, oder der Einbruch wird mit Arbeiten gefüllt, die Puffer haben (Abschnitt 8, Tipp 3).

Selbstkosten und Preis eines Personentags

Einheit 13 hat das „Geheimnis“ des Dienstleistungsgeschäfts gelüftet: Ein Ingenieur erhält bei jedem Vertragsmodell dasselbe Gehalt — es unterscheidet sich die Marge. Daher hat eine Kostenschätzung immer zwei Spalten:

• Selbstkostensatz (Cost Rate) — Gehalt, Steuern, Ausstattung, Anteil an Büro, Verwaltung, Recht und Finanzen;
• Verkaufssatz (Sell Rate) — Selbstkosten plus Marge.

Die Sätze sind ein Lehrbeispiel im selben Sinne wie die „400 Dollar pro Tag“ aus Einheit 12. Das Verhältnis von Preis zu Selbstkosten liegt im Beispiel bei etwa 1,8. Diese Zahl hängt von Unternehmen, Markt und Vertragsmodell ab und ist nicht als Norm zu verstehen.

Nicht nur Menschen: Material und Lieferanten

Einheit 05 erinnerte daran: Eine Embedded-Schätzung hat mindestens vier Ressourcenebenen — Menschen, Material, externe Dienstleistungen, Zeit und Abhängigkeiten. Einheit 14 empfahl, den Lieferantenanteil in T&M zu nehmen.

Die Beträge sind fiktiv; reale Werte stammen aus Angeboten zum RFQ-Termin.

7. Vollständige Projektschätzung und vollständiger Zeitplan

Jetzt fassen wir alles zu einer Antwort für den Kunden zusammen: wie viel, wann und nach welchem Modell.

Die Stufen der Kostenschätzung

1. Aufwand je Rolle (Abschnitt 6) → Selbstkosten und Preis der Arbeit.
2. + Material und Lieferanten (Durchreichung nach T&M + Beschaffungszuschlag).
3. + Risikoreserve — per Simulation, nicht „+20 % auf alles“.
4. Preis je Phase nach Vertragsmodell aus den Einheiten 13–14: FP, wo Gates schützen oder alles unter eigener Kontrolle ist; T&M^, wo es viele Abhängigkeiten gibt; T&M für Lieferanten.

Die Preisregel: P50 und P80

Monte Carlo liefert nicht nur eine Verteilung der Termine, sondern auch eine Verteilung der Arbeitskosten je Phase: Ändern sich die Dauern, ändern sich auch die Personentage. Daraus folgt eine einfache Regel:

• T&M^: Schätzung = P50, Obergrenze („Deckel“) = P80;
• Fixed Price: Preis = P80 × (1 + Aufschlag); der Aufschlag (im Beispiel 10 %) deckt Vertragsstrafen und Reputationsrisiko (Einheit 13).

Zur internen Kontrolle: Die Arbeitsselbstkosten betragen bei P50 ≈ 213 500 €, bei P80 ≈ 228 000 €. Die Differenz zwischen Preis und Selbstkosten ist die Marge, aus der Büro, Verwaltung, Recht und Finanzen bezahlt werden und von der ein Teil Risiken abdeckt (Einheit 13).

Redaktionelle Ergänzung. Das Verhältnis P80/P50 der Arbeitskosten liegt in den Phasen unseres Beispiels zwischen 1,07 und 1,15, also enger als die ±30 % aus der Praxis des Dozenten (Einheit 13). Das Modell enthält nur bekannte Risiken und einen gemeinsamen Optimismusfaktor. Marktänderungen bei den Sätzen, Scope-Änderungen seitens des Kunden und das „unbekannte Unbekannte“ fehlen darin. ±30 % bei T&M^ sind daher ein vernünftiger Schutz, keine Gier. Die P50/P80-Regel begründet den Korridor mit Zahlen; die Vereinbarung ersetzt sie nicht.

Vollständiger Zeitplan

Start: 11.01.2027; die Termine beruhen auf einer Fünftagewoche ohne Feiertage und Urlaub. In einem realen Plan werden diese separat in den Projektkalender eingetragen.

Die Zusage an den Kunden ist P80: 47 Wochen, 6. Dezember 2027. Vergleichen Sie mit dem groben Zeitplan aus Einheit 13 (12 Monate): Die Rechnung liefert eine ähnliche Größenordnung, doch jetzt hat jede Zahl eine Begründung. Genau das forderte Einheit 05: „Jede große Zahl muss erklärt werden: woher sie stammt und was sie verändern würde.“

Wie man es dem Kunden zeigt

Eine Seite ohne eine einzige „nackte“ Zahl:

1. Phasen und Gates auf einer Zeitachse (Abb. 13.1 aus Einheit 13, aber mit berechneten Terminen).
2. Eine Spanne statt eines Punktes: „P50 ist Mitte November, P80 Anfang Dezember 2027; wir sagen P80 zu.“
3. Preis nach Phasen und Modellen — die Tabelle oben.
4. Annahmen: Start 11.01.2027; Kernteam verfügbar; der Kunde stellt Musterteile und Zugang zum Standort vor G1 bereit; IT-Freigabe des Servers bis Woche 13; der Cobot wird nach PoC-B gewählt.
5. Ausschlüsse: Serienausrollung von Zellen, Support nach der Übergabe, Zertifizierung über die vereinbarte Liste hinaus.
6. Überprüfungsregel: Nach jedem Gate wird die Schätzung aktualisiert, und die neue Proposal-Version erhält eine neue Nummer (Einheit 12: Versionierung).

8. Praxistipps

1. Positionen mit langer Lieferzeit am ersten Tag nach dem Gate. Die Beschaffung mit langer Lieferzeit (Cobot, Serien-Jetson, Sicherheitsscanner) startet direkt nach G4, nicht wenn „alles konstruiert ist“. In unserem Plan ergibt das 40,8 Tage Puffer; eine Bestellung nach dem Mechanik-Review würde sie kritisch machen. Das PoC-Kit bestellen wir schon nach G1, parallel zu den Anforderungen: Dev Kits und Kameras gibt es ab Lager, und sie hängen nicht von Architekturentscheidungen ab. Teure Positionen sollte man dem Kunden zum Direktkauf anbieten (Customer-Furnished Equipment, CFE): Er zahlt keinen Zuschlag, und Sie haben keinen fremden Roboter für 30 000 € in der Bilanz. Sein Liefertermin wird dann aber zu einer Annahme im Proposal, und das muss ausdrücklich festgehalten werden.

2. Ein Puffer, am Ende, nicht in jeder Aufgabe. Wenn jeder Ingenieur „sicherheitshalber“ 20 % aufschlägt, wird das Projekt nicht zuverlässiger. Es gilt das Parkinsonsche Gesetz: Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht. Eine auf Aufgaben verteilte Reserve wird unbemerkt verbraucht. Ehrlicher ist es, mit PERT E zu planen und die Differenz bis P80 als einen Projektpuffer vor dem Zusagetermin zu halten (das graue Band in Abb. 15.2). Dann ist sein Verbrauch sichtbar und steuerbar: „40 % des Puffers verbraucht bei 60 % des Weges — Alarm“.

Redaktionelle Ergänzung. Die Idee von Projekt- und Zuführungspuffern (Feeding Buffers) stammt aus dem Critical Chain Project Management von Eliyahu Goldratt (Critical Chain, 1997).

3. Den Auslastungseinbruch mit Aufgaben füllen, die Puffer haben. In Abb. 15.4 ist das Team in den Wochen 20–23 fast untätig (≈ 1,4 FTE): Alle warten auf die Fertigung. Aufgabe 2.16 „Datensatz und Training“ hat 54 Tage Puffer. Verschiebt man sie um 25 Arbeitstage, sinkt die Spitze von 6,4 auf 6,0 FTE, der Einbruch füllt sich auf 2,9 FTE, und der Endtermin ändert sich nicht. Zusatznutzen: Der CV-Ingenieur nimmt den Datensatz bereits mit den Serienkameras auf. Das ist Ressourcenglättung (Resource Levelling) — der Hauptgrund, Puffer überhaupt zu berechnen.

4. P50 für T&M, P80 für Fixed Price. Den Preis nicht aus einem „Risikogefühl“ erfinden, sondern aus der Verteilung nehmen: P50 ist die ehrliche T&M^-Schätzung, P80 die T&M^-Obergrenze und die Basis des FP-Preises. Das Gespräch mit dem Kunden wechselt dann von „warum so teuer“ zu „welche Wahrscheinlichkeit möchten Sie kaufen“.

5. Simulation vor der Hardware und ein Container für zwei Welten. Mit ROS 2 kann man Zellsoftware und MVP auf einem Simulator (Gazebo, NVIDIA Isaac Sim) beginnen, lange bevor der Cobot eintrifft. Das ist der Schritt „Modell / Virtualisierung“ aus dem Plan für EPIC 1 (Einheit 14). Bauen Sie ein und dasselbe Container-Image für den Entwicklerrechner (x86) und den Jetson (arm64). Dann ist „auf meinem Rechner läuft es“ kein Integrationsrisiko mehr.

6. Excel → Jira per CSV. Der Dozent empfiehlt, in Excel zu planen (Einheit 14). Enthält die Tabelle von Anfang an die Spalten Summary, Issue Type, Epic / Parent, Original Estimate, Assignee, lässt sich der Plan mit dem Standard-CSV-Import ohne Abtippen nach Jira übertragen. Das ist die Brücke zur angekündigten Migration des Plans nach Jira.

Praktische Schlussfolgerungen

• Eine Schrittliste wird zum Plan, wenn jede Zeile eine Dauer O/M/P, Abhängigkeiten, Rollen mit FTE und einen Typ hat: Arbeit, Warten oder Gate.
• Es schätzt, wer ausführt; Drei-Punkt-PERT macht Unsicherheit sichtbar; KI-Aufgaben werden als zeitlich begrenzte Experimente geschätzt, nicht als Erreichen einer Genauigkeit.
• Dauer, Aufwand und Kalender sind drei verschiedene Zahlen; man darf sie nicht verwechseln.
• Der kritische Pfad eines Embedded-Projekts verläuft meist durch Hardware, Mechanik und Lieferanten; Software hat oft viel Puffer.
• Das Projektrisikoregister ist keine HARA; die Wirkung eines Risikos auf den Termin hängt vom Puffer der Aufgabe ab, daher überschätzt die naive EMV-Summe die Wirkung, und unabhängige Aufgaben unterschätzen die Streuung.
• Monte Carlo macht aus einem Termin eine Wahrscheinlichkeit: Zugesagt wird P80, nicht der wahrscheinlichste Plan.
• Die Teamzusammensetzung folgt aus dem Auslastungsdiagramm; die erste Woche einer Rolle ist ihre Einstellungsfrist.
• Der Preis besteht aus Arbeitsselbstkosten plus Marge, Material und Lieferanten; das Vertragsmodell wird je Phase gewählt: FP aus P80 mit Aufschlag, T&M^ mit P50 und Obergrenze P80, T&M für Lieferanten.
• Eine vollständige Schätzung ist eine Seite mit Spannen, Annahmen, Ausschlüssen und einer Regel zur Überprüfung nach jedem Gate.

Fragen zur Selbstkontrolle

• Welche fünf Attribute hat ein Arbeitspaket im PSP?
• Warum werden Fertigung und Versand in eigene „Warte“-Zeilen gestellt?
• Wie erhält man aus „2 bis 10 Tagen“ eine PERT-Schätzung, und was fehlt dafür?
• Wie unterscheidet sich die Dauer vom Aufwand und vom Kalenderdatum?
• Wie sollte man die Aufgabe „99 % Genauigkeit erreichen“ für ein CV-Modell schätzen?
• Wie findet man den kritischen Pfad, und was ist Puffer?
• Warum verläuft der kritische Pfad in unserem Fall durch Leiterplatte und Mechanik und nicht durch Software?
• Wie unterscheidet sich eine HARA von einem Projektrisikoregister?
• Warum überschätzt die naive EMV-Summe die Wirkung der Risiken auf den Termin?
• Was ist Merge Bias, und warum ergibt die Simulation einen späteren Termin als die PERT-Formel für einen Pfad?
• Wozu braucht das Modell einen gemeinsamen Optimismusfaktor?
• Wie leitet man Teamzusammensetzung und Einstellungsplan aus dem Auslastungsdiagramm ab?
• Wie unterscheiden sich die Selbstkosten eines Personentags vom Preis für den Kunden?
• Wie werden P50 und P80 zu Preisen für FP und T&M^?
• Was gehört auf die einseitige vollständige Schätzung für den Kunden?

Praktische Aufgabe für die Teams

Für das „Unternehmen“, das Ihr Team seit Einheit 06 führt, und für den Fall aus dem Expertentermin (Einheit 12):

1. Zerlegen Sie das Projekt in mindestens drei Epics und 20–35 Arbeitspakete; geben Sie für jedes O/M/P, Abhängigkeiten, Rollen und FTE an.
2. Erstellen Sie ein Gantt-Diagramm (mit der Excel-Arbeitsdatei dieser Einheit), finden Sie den kritischen Pfad und die Aufgaben mit dem größten Puffer.
3. Stellen Sie ein Register mit 6–10 Projektrisiken auf; markieren Sie, welche davon der Puffer auffängt.
4. Erstellen Sie ein Auslastungsdiagramm und eine Rollentabelle; bestimmen Sie, ab welcher Woche jede Rolle gebraucht wird.
5. Berechnen Sie Selbstkosten und Preis je Phase, wählen Sie das Vertragsmodell je Phase und begründen Sie es.
6. Bereiten Sie eine Seite für den Kunden vor: Phasen, Gates, P50/P80, Preis, Annahmen, Ausschlüsse.

Ausblick auf die nächsten Einheiten

Prognose mit Stand 03.11.2026, keine Beschreibung bereits durchgeführter Einheiten:

• Übertragung des Plans nach Jira oder GitHub Projects: Epics → Stories → Aufgaben, Schätzungen, Sprints; Verknüpfung von Plan und Backlog;
• Einstellung und Teambildung: Rollenprofile (Job Descriptions) aus dem Auslastungsdiagramm, Onboarding, Kick-off mit dem Kunden;
• danach der Übergang zu Modul 06: Implementierung, Integration, Test, Release.

Materialien der Einheit

• Excel-Schätzmodell der Pilotzelle (PSP mit PERT, kritischer Pfad, Gantt-Diagramm per bedingter Formatierung, Team, Risiken, Material, Zusammenfassung): .xlsx herunterladen
• Modell- und Monte-Carlo-Simulationsskript (Python, nur Standardbibliothek): .py herunterladen

Geprüfte Links

• ROS 2 Lyrical Luth released (Open Robotics Discourse, 22.05.2026): https://discourse.openrobotics.org/t/ros-2-lyrical-luth-released/55021
• ROS 2 documentation (Jazzy): https://docs.ros.org/en/jazzy/
• ISO 10218-1:2025, Robotics — Safety requirements — Part 1: Industrial robots: https://www.iso.org/standard/73933.html
• Jira Cloud — Import data from a CSV file (Atlassian Support): https://support.atlassian.com/jira-cloud-administration/docs/import-data-from-a-csv-file/
• S. McConnell. The Cone of Uncertainty (Construx, white paper): https://www.construx.com/wp-content/uploads/2019/02/CxWhitePaper_ConeOfUncertainty.pdf