Projektmanagement bei Embedded-Projekten — warum die schwierigste Arbeit vor dem ersten Schaltplan liegt

In meiner Tätigkeit als Embedded-Spezialist sehe ich seit über drei Jahrzehnten dieselben Muster, wenn Projekte aus dem Ruder laufen. Es sind selten technische Hürden im engeren Sinn — der Code wird geschrieben, die Hardware wird gefertigt, der FPGA wird konfiguriert. Was schiefgeht, liegt davor und dahinter: unklare Anforderungen, eine Spezifikation, die das eigentliche Problem nicht trifft, eine Architektur, die unter realer Last bricht, eine Dokumentation, die der Kunde nicht weiterführen kann, und ein Abnahmeprotokoll, das im entscheidenden Moment Lücken zeigt.

Die Versuchung ist groß, das Projektmanagement als bürokratischen Überbau zu betrachten, den man auf das Nötigste reduziert, um schneller mit der eigentlichen Arbeit beginnen zu können. Diese Versuchung ist teuer. In allen größeren Embedded-Projekten, die ich nachträglich aufräumen musste, lag die Ursache des Scheiterns nicht in der Implementierung, sondern in einer Phase, die deutlich davor liegt.

Die Anforderungsaufnahme — das schwierigste Gespräch des Projekts

Das Erstgespräch mit dem Kunden ist die folgenreichste Phase eines Embedded-Projekts. Was hier nicht erfasst wird, taucht später als Änderungswunsch wieder auf — meist zu einem Zeitpunkt, an dem die Korrektur ein Vielfaches der ursprünglichen Aufnahme kosten würde. Was hier missverstanden wird, geht als Annahme in die Spezifikation ein und bleibt dort unsichtbar, bis der erste Prototyp die Erwartung des Kunden verfehlt.

Eine strukturierte Anforderungsaufnahme arbeitet mit drei Achsen. Die funktionale Achse fragt, was das System tun soll — und in welchen Grenzen. Die nicht-funktionale Achse fragt nach Eigenschaften, die im Lastenheft oft unterbelichtet sind: Latenz, Stromverbrauch, Temperaturbereich, Lebensdauer, Wartbarkeit, Updatefähigkeit, Diagnose. Die regulatorische Achse fragt, welche Normen das Produkt erfüllen muss — und welche Nachweise dafür zu führen sind. Eine Anforderung wie „muss IEC 62304 erfüllen" ist keine Anforderung, sondern ein Auftrag, einen ganzen Anforderungskatalog daraus abzuleiten.

In der Praxis erfasse ich diese drei Achsen in einem Erstgespräch mit dem Kunden, dokumentiere die Antworten in Stichpunkten und entwickle daraus einen Lastenheft-Entwurf, der dem Kunden zur Korrektur vorgelegt wird. Dieser Entwurf ist nie vollständig nach der ersten Runde — und das ist auch nicht das Ziel. Ziel ist, dass der Kunde die Lücken sieht, die er beim mündlichen Gespräch nicht gesehen hat.

Eine Lehre aus der Raumfahrt: Mars Climate Orbiter, 1999

Der Mars Climate Orbiter sollte den Mars umrunden und atmosphärische Daten liefern. Im September 1999 trat er stattdessen zu tief in die Marsatmosphäre ein und zerbrach. Die Ursache war kein Implementierungsfehler im engeren Sinn. Eine Software-Komponente eines Zulieferers berechnete Schubimpulse in Pfund-Sekunden — der Empfänger erwartete Newton-Sekunden. Die Werte waren formal plausibel, das System verarbeitete sie ohne Warnung weiter, und über Monate akkumulierte sich der Fehler zu einer Bahnabweichung, die das Raumfahrzeug zu nahe an den Planeten brachte.

Die technische Ursache war ein einzelner Maßeinheits-Mismatch. Die eigentliche Ursache lag in der Schnittstellendefinition: Eine Schnittstelle zwischen zwei Software-Komponenten unterschiedlicher Herkunft war beschrieben — aber nicht ausreichend formal, nicht in den Maßeinheiten geprüft, nicht durch einen Akzeptanztest validiert.

Die Lehre für jedes Embedded-Projekt: Schnittstellen zwischen Komponenten, zwischen Teams oder zwischen Zulieferer und Auftraggeber gehören zu den fragilsten Stellen eines Systems. Ihre Definition ist Aufgabe der Projektsteuerung, nicht der Implementierung. Wer die Schnittstellendefinition den jeweiligen Implementierern überlässt, bekommt zwei kompatible Komponenten, die formal zusammenpassen — und im Detail nicht.

Vom Lastenheft zum Pflichtenheft

Lastenheft und Pflichtenheft werden in der Praxis oft synonym verwendet. Das ist falsch und führt zu Missverständnissen, die sich später rächen. Das Lastenheft beschreibt, was der Kunde haben will. Das Pflichtenheft beschreibt, wie der Auftragnehmer die Anforderungen umsetzt. Beide Dokumente haben unterschiedliche Verfasser, unterschiedliche Adressaten und unterschiedliche Konsequenzen.

Im Lastenheft steht die Anforderung. Im Pflichtenheft steht die Lösung — der Architekturansatz, die gewählten Komponenten, die Verfahren, die Schnittstellen, die Testkonzepte. Der Kunde liest das Pflichtenheft, um zu prüfen, ob die geplante Lösung seine Anforderungen wirklich trifft. Hier kommt es regelmäßig zu Aha-Momenten — Anforderungen, die im Lastenheft formuliert waren, erweisen sich im Spiegel der Lösung als nicht das, was eigentlich gemeint war. Diese Aha-Momente sind wertvoll und gehören zur Frühphase. Sie nachträglich in der Implementierung zu produzieren ist deutlich teurer.

Pflichtenheft und Architekturentwurf sind die zentralen Lieferungen der Konzeptphase. Sie sind auch die Lieferungen, an denen man die Qualität eines Embedded-Spezialisten am ehesten erkennt. Ein Pflichtenheft, das nur das Lastenheft umformuliert, ist wertlos. Ein Pflichtenheft, das die Architekturentscheidungen begründet und die Alternativen verwirft, ist Gold.

Die Trace-Matrix — Pflicht und Werkzeug

In sicherheitsrelevanten Branchen — Medizintechnik, Automotive, Luftfahrt, Industrie nach IEC 61508 — ist die Nachverfolgbarkeit von der Anforderung bis zum Test eine regulatorische Pflicht. In Branchen ohne diese Pflicht ist sie trotzdem eine der wirksamsten Methoden, ein Projekt unter Kontrolle zu halten.

Die Trace-Matrix ist eine Tabelle. In den Zeilen stehen die Anforderungen, in den Spalten stehen die Implementierungseinheiten und die zugehörigen Tests. In den Zellen steht der Verweis: Welche Code-Datei, welche Hardware-Baugruppe, welcher FPGA-Block setzt diese Anforderung um. Welcher Test weist die Erfüllung nach.

Eine ehrlich geführte Trace-Matrix zeigt drei Klassen von Problemen, die in Projekten ohne diese Methodik unentdeckt bleiben: Anforderungen, denen kein Implementierungsteil zugeordnet ist (sie wurden vergessen). Implementierungsteile, denen keine Anforderung zugeordnet ist (sie wurden auf Verdacht gebaut und vergrößern unnötig den Pflegeaufwand). Tests, denen weder Anforderung noch Implementierung zugeordnet ist (sie testen etwas, das niemand mehr braucht). Allein die regelmäßige Pflege dieser Tabelle wirkt projektsteuernd, unabhängig von externen Audits.

FMEA und FTA — von der Methode zum Werkzeug

FMEA, die Failure Mode and Effects Analysis, ist eine Methode aus der Luft- und Raumfahrt, die heute in vielen sicherheitsrelevanten Branchen Standard ist. Sie fragt für jede Komponente: Welche Ausfallarten gibt es? Welche Folgen hätte jede dieser Ausfallarten für das Gesamtsystem? Welche Maßnahmen werden getroffen, um die Wahrscheinlichkeit oder die Folgen zu reduzieren?

FTA, die Fault Tree Analysis, fragt umgekehrt: Welche Verkettung von Einzelausfällen könnte zu einem definierten Top-Ereignis führen? Sie ist die deduktive Schwester der induktiven FMEA, und beide ergänzen sich.

Beide Methoden lassen sich auf zwei Arten betreiben. Als bürokratische Pflichtübung — dann sind sie ein dickes Dokument im Projektordner, das niemand mehr aufschlägt. Oder als Werkzeug zur Architekturschärfung — dann decken sie Schwachpunkte auf, lange bevor das System gebaut wird, und führen zu Architekturentscheidungen, die ohne FMEA nicht getroffen worden wären. Der Unterschied liegt in der Haltung: Wer die FMEA-Tabelle nach der Architekturentwurfsphase ausfüllt, betreibt Bürokratie. Wer sie währenddessen führt und die Architektur auf ihre Befunde anpasst, betreibt Engineering.

Statusberichte, die etwas verändern

Statusberichte sind das sichtbarste Element des Projektmanagements und gleichzeitig das am häufigsten missverstandene. Ein guter Statusbericht ist nicht der Bericht, der alles gut aussehen lässt, sondern der Bericht, der dem Kunden ermöglicht, die richtigen Entscheidungen zu treffen.

In der Praxis schreibe ich Statusberichte mit drei Abschnitten: erledigt seit dem letzten Bericht, geplant für die nächste Periode, Risiken und offene Entscheidungen. Der dritte Abschnitt ist der wichtigste — und der ehrlichste. Wenn ein Risiko sichtbar wird, gehört es in den Statusbericht, nicht in den nächsten. Wenn eine Entscheidung des Kunden ansteht, gehört sie sichtbar gemacht, mit den Optionen und ihren Konsequenzen. Diese Form von Bericht ist unbequem, weil sie den Kunden zwingt, mitzudenken. Genau das ist ihr Sinn.

Die häufigste Pathologie von Statusberichten ist das Schönschreiben. Probleme werden weichgespült, Verzögerungen umetikettiert, Risiken verschwiegen, weil man hofft, sie noch rechtzeitig in den Griff zu bekommen. Diese Hoffnung ist meist falsch. Verschwiegene Risiken werden zu Krisen, und Krisen kosten ein Vielfaches dessen, was die rechtzeitige Erwähnung gekostet hätte.

Wann Projektmanagement schadet

Nicht jedes Projekt braucht das volle methodische Arsenal. Ein einwöchiger Bug-Fix in einer bekannten Code-Basis braucht kein Pflichtenheft, keine FMEA und keine Trace-Matrix. Wer hier Methodik überstülpt, lähmt das Projekt mehr, als er es voranbringt.

Die methodische Tiefe muss zur Projektgröße und zur Risikoklasse passen. Eine durchgängige Produktentwicklung mit Sicherheitsanforderungen verlangt das volle Arsenal. Eine Algorithmusumsetzung als Studie verlangt eine Spezifikation, einen Architekturentwurf und einen Abnahmetest — mehr nicht. Eine kurzfristige Code-Übernahme verlangt eine sauber dokumentierte Übergabe und nicht mehr. Diese Skalierung gehört zur Erfahrung — und sie ist einer der Punkte, an denen sich ein erfahrener Spezialist von einem methodisch ausgebildeten Projektleiter ohne Embedded-Hintergrund unterscheidet.

Warum ich Projektmanagement nur in Verbindung mit technischer Verantwortung anbiete

In meiner Praxis habe ich mich dafür entschieden, Projektmanagement nur dann zu übernehmen, wenn ich auch die technische Verantwortung trage — entweder als Bestandteil einer Komplettentwicklung oder zur Begleitung eines vom Kunden geführten Teams, das ich fachlich beraten kann. Reine Koordination ohne technische Tiefe wäre für meine Kunden ein schlechtes Geschäft: Ein Projektmanager, der nicht selbst beurteilen kann, ob die vorgeschlagene Architektur trägt, ob die Spezifikation realistisch ist, ob ein Risiko ernst zu nehmen oder eine Übertreibung ist, kann das Projekt nicht sinnvoll steuern. Er kann nur verwalten, was die Implementierer ihm berichten — und genau dort liegt das Risiko, das ich vermeiden möchte.

Diese Selbstbeschränkung ist auch ein Filter. Wer einen austauschbaren Projektmanager sucht, ist bei mir falsch. Wer einen Embedded-Spezialisten sucht, der das Projekt zusammen mit der Technik führt, findet bei mir genau das.