Project Management for Embedded Projects — Why the Hardest Work Lies Before the First Schematic

In my work as an embedded specialist, I have seen the same patterns for over three decades when projects run off course. They are rarely technical hurdles in the narrow sense — code gets written, hardware gets manufactured, the FPGA gets configured. What goes wrong lies before and after: unclear requirements, a specification that misses the actual problem, an architecture that breaks under real load, documentation the client cannot continue, and an acceptance protocol that shows gaps at the decisive moment.

The temptation is great to view project management as bureaucratic overhead, to be reduced to the minimum so that one can begin the actual work faster. This temptation is expensive. In all the larger embedded projects I have had to clean up afterwards, the cause of failure lay not in the implementation but in a phase that comes well before it.

Requirements capture — the most consequential conversation in the project

The first meeting with the client is the most consequential phase of an embedded project. What is not captured here will reappear later as a change request — usually at a moment when the correction would cost a multiple of the original capture. What is misunderstood here enters the specification as an assumption and stays invisible there until the first prototype misses the client's expectation.

A structured requirements capture works along three axes. The functional axis asks what the system shall do — and within what limits. The non-functional axis asks for properties that are often underexposed in the requirements specification: latency, power consumption, temperature range, lifetime, maintainability, updateability, diagnostics. The regulatory axis asks which standards the product must meet — and what evidence is required for that. A requirement such as „must comply with IEC 62304“ is not a requirement, it is an assignment to derive an entire requirements catalogue from it.

In practice, I capture these three axes in a first meeting with the client, document the answers in bullet points, and develop from them a draft requirements specification, which I present to the client for correction. This draft is never complete after the first round — and that is not the goal. The goal is for the client to see the gaps that they did not see during the spoken conversation.

A lesson from spaceflight: Mars Climate Orbiter, 1999

The Mars Climate Orbiter was meant to orbit Mars and return atmospheric data. In September 1999 it instead entered the Martian atmosphere too steeply and broke apart. The cause was not an implementation error in the narrow sense. A software component from a supplier calculated thrust impulses in pound-seconds — the receiver expected newton-seconds. The values were formally plausible, the system processed them onward without warning, and over months the error accumulated into an orbital deviation that brought the spacecraft too close to the planet.

The technical cause was a single units-of-measurement mismatch. The actual cause lay in the interface definition: an interface between two software components of different origin had been described — but not formally enough, not checked in its units of measurement, not validated by an acceptance test.

The lesson for every embedded project: interfaces between components, between teams, or between supplier and contractor are among the most fragile parts of a system. Their definition is the task of project steering, not implementation. Anyone who leaves the interface definition to the respective implementers gets two compatible components that formally match — and in detail do not.

From requirements specification to functional specification

Requirements specification and functional specification are often used synonymously in practice. That is wrong and leads to misunderstandings that take their revenge later. The requirements specification describes what the client wants. The functional specification describes how the contractor implements the requirements. Both documents have different authors, different addressees and different consequences.

The requirements specification states the requirement. The functional specification states the solution — the architectural approach, the chosen components, the procedures, the interfaces, the test concepts. The client reads the functional specification to check whether the planned solution truly meets their requirements. Aha moments occur regularly here — requirements that were formulated in the requirements specification turn out, in the mirror of the solution, not to be what was actually meant. These aha moments are valuable and belong to the early phase. Producing them later in the implementation is significantly more expensive.

Functional specification and architectural design are the central deliveries of the conceptual phase. They are also the deliveries by which the quality of an embedded specialist is most clearly recognized. A functional specification that merely rewords the requirements specification is worthless. A functional specification that justifies the architectural decisions and rejects the alternatives is gold.

The trace matrix — obligation and tool

In safety-relevant industries — medical technology, automotive, aerospace, industry under IEC 61508 — traceability from the requirement to the test is a regulatory obligation. In industries without this obligation, it is nevertheless one of the most effective methods for keeping a project under control.

The trace matrix is a table. The rows hold the requirements; the columns hold the implementation units and the associated tests. The cells hold the reference: which code file, which hardware module, which FPGA block implements this requirement. Which test demonstrates fulfilment.

An honestly maintained trace matrix reveals three classes of problem that remain undetected in projects without this methodology: requirements with no implementation part assigned (they were forgotten); implementation parts with no requirement assigned (they were built on suspicion and unnecessarily increase maintenance effort); tests with neither requirement nor implementation assigned (they test something nobody needs anymore). The mere act of regularly maintaining this table has a project-steering effect, independent of external audits.

FMEA and FTA — from method to tool

FMEA, the Failure Mode and Effects Analysis, is a method from aerospace that today is standard in many safety-relevant industries. For each component, it asks: what failure modes are there? What consequences would each of these failure modes have for the overall system? What measures are taken to reduce the probability or the consequences?

FTA, the Fault Tree Analysis, asks the converse: what chain of individual failures could lead to a defined top event? It is the deductive sister of the inductive FMEA, and the two complement each other.

Both methods can be operated in two ways. As a bureaucratic exercise — then they are a thick document in the project folder that nobody opens again. Or as a tool to sharpen the architecture — then they expose weak points long before the system is built, and lead to architectural decisions that would not have been taken without an FMEA. The difference lies in the attitude. Whoever fills in the FMEA table after the architectural design phase is doing bureaucracy. Whoever maintains it during, and adapts the architecture to its findings, is doing engineering.

Status reports that change something

Status reports are the most visible element of project management and at the same time the most frequently misunderstood. A good status report is not the report that makes everything look good, but the report that enables the client to make the right decisions.

In practice, I write status reports with three sections: completed since the last report, planned for the next period, risks and open decisions. The third section is the most important — and the most honest. When a risk becomes visible, it belongs in this status report, not the next one. When a decision is pending from the client, it belongs visibly highlighted, with the options and their consequences. This form of report is uncomfortable because it forces the client to think along. That is precisely its purpose.

The most common pathology of status reports is the soft-pedalling. Problems get smoothed over, delays get relabelled, risks stay unmentioned because one hopes to bring them under control in time. This hope is mostly false. Concealed risks turn into crises, and crises cost a multiple of what their timely mention would have cost.

When project management does harm

Not every project needs the full methodical arsenal. A one-week bug fix in a familiar code base needs no functional specification, no FMEA, and no trace matrix. Whoever forces methodology on it slows the project down more than they advance it.

The methodical depth must match the project size and the risk class. An end-to-end product development with safety requirements demands the full arsenal. An algorithm implementation as a study demands a specification, an architectural design and an acceptance test — no more. A short-term code takeover demands a properly documented handover, no more. This scaling belongs to experience — and it is one of the points where an experienced specialist differs from a methodically trained project manager without an embedded background.

Why I offer project management only in conjunction with technical responsibility

In my practice I have decided to take on project management only when I also bear the technical responsibility — either as part of an end-to-end development, or to accompany a team led by the client whom I can advise technically. Pure coordination without technical depth would be a bad deal for my clients. A project manager who cannot themselves judge whether the proposed architecture holds, whether the specification is realistic, whether a risk is to be taken seriously or is an exaggeration, cannot meaningfully steer the project. They can only manage what the implementers report to them — and that is precisely the risk I want to avoid.

This self-restriction is also a filter. Anyone looking for an interchangeable project manager is in the wrong place. Anyone looking for an embedded specialist who leads the project alongside the technology will find exactly that with me.