Put The Acceptance Risk In The Smallest Milestone

Mostafa Dhouib·10 min read

Put The Acceptance Risk In The Smallest Milestone

The short answer. On a fixed-price firmware engagement where the final acceptance test runs on hardware you will never physically touch, that last stage is the stage you control least. You cannot put a probe on the failing signal, you cannot see what else is attached, and you cannot distinguish your defect from their fixture. Most milestone plans weight stages by effort, which puts the largest payment behind the weakest position. Weight by controllability instead. The large blocks of work belong in the middle, where you own the bench and the evidence. The remote-acceptance stage should be the smallest line on the schedule, with acceptance criteria written tightly enough that it can actually close.

A firmware build for a medical wearable was fixed price. The device existed in one place, and that place was not my bench. Every unit I would ever influence was going to be verified by somebody else, somewhere else, on a setup I would only ever see described.

That single fact should change how the money and the schedule are laid out, and usually it does not.

Milestones are usually weighted by effort, and that is the error

The default way a statement of work gets built is by estimating the work and splitting the fee in proportion. Three months of driver and signal-path development is the bulk of the effort, so it gets the bulk of the fee. Integration and acceptance are short, so they get a thin slice at the start and a chunky completion payment at the end because that is how the commercial habit runs.

The result is a plan where the final payment, often the largest single one, is gated by the stage with the least observability on either side. You have the most money outstanding exactly when you have the least ability to act.

Effort is a reasonable basis for pricing the whole engagement. It is a bad basis for deciding where the risk of non-closure sits, because effort and controllability are different axes, and the second one is what determines whether a milestone can be closed at all.

Controllability is what the weighting should track

Controllability, in this context, means something narrow and testable: if this stage fails, can I diagnose the cause and fix it without depending on somebody else's attention, equipment or calendar?

Score each stage on that question and the ranking tends to come out like this.

Highest control: anything on my own bench. Development board, instrumented firmware, a logic analyser on the bus, a power analyser on the rail, a signal generator standing in for the sensor. If it fails, I see why, and the loop between a hypothesis and an answer is minutes.

High control: anything with a deterministic harness. Unit tests, host-side simulation of the front end, replayed capture files, static analysis gates. Failures here are reproducible on demand, which is the single most valuable property a failure can have.

Medium control: anything on the real hardware, in my hands. Now the hardware can be wrong as well as the firmware, but I can still probe it, swap it, and eliminate variables physically.

Lowest control: anything on hardware I will never touch. I get a report. The report says what somebody else observed, through their fixture, with their instruments, in a context I cannot inspect. Between their observation and my code there are several layers I cannot see, and every round trip costs a day or more.

What makes remote acceptance genuinely the hardest stage

It is worth being specific about why the last category is different in kind and not just in degree.

You cannot observe the failure, only the report of it. The useful information in a firmware defect is the waveform, the register state and the timing. What arrives instead is a sentence. Converting a sentence into a waveform takes several exchanges, and each one is a day.

The fixture is an uncontrolled variable. Their probe, their ground arrangement, their supply, their cabling, their ambient conditions. Any of those can produce a symptom that looks exactly like a firmware defect, and you have no way to rule them out from where you are sitting.

Instruments differ. Two meters measuring the same current can legitimately disagree depending on how they sample and what shunt they insert. A disagreement about a number can consume a week before anybody suspects the instrument.

The test operator is not the test author. A procedure that is clear to the person who wrote it is ambiguous to the person running it, and the ambiguity surfaces as a failed step with no explanation.

Fault attribution is contested by default. When something does not work and two organisations are involved, deciding whose problem it is becomes a negotiation rather than a measurement. Fixed-price engagements turn that negotiation into a question about money, which is the worst possible frame for a technical discussion.

The calendar is not yours. Even a trivial fix needs their bench, their operator and their availability. Your ability to finish is bounded by somebody else's week.

The shape that follows

Once controllability is the axis, the plan reshapes itself.

Make the first milestone small and about proving access. Not features. Toolchain, programming, debug visibility, a confirmed build running on real silicon, and whatever contract with the hardware you are going to depend on later. This is cheap, it closes fast, and it de-risks the assumption that everything after it rests on.

Put the mass of the work in the middle, on your own bench, behind evidence you generate. Drivers, the real-time paths, the memory and ownership structure, power behaviour, fault handling. Each of these can be demonstrated with a capture, a log and a test report that you produced and can reproduce on request. Acceptance of these milestones should depend on artefacts, not on anyone else's hardware being available.

Make the remote-acceptance milestone the smallest line on the schedule. Small enough that if it drags for a month you are inconvenienced rather than exposed. The work in it is not smaller because it is easier. It is smaller because its probability of closing on time is the lowest, and the payment weighting should reflect probability rather than hours.

Put a defined support window after it rather than inside it. A fixed block of time for remote investigation, priced as a block, is honest for both sides. An open-ended obligation attached to the final payment is not, because it has no termination condition.

Writing criteria the small milestone can actually close against

A small final milestone only helps if it can close. If the acceptance criteria are subjective, shrinking the milestone just shrinks the payment attached to something that may never be signed.

Every criterion is a measurement with a threshold, written before work starts. A number, an instrument, a method, a pass or fail. "Works correctly" is not a criterion. "This register sequence produces this output within this tolerance, measured this way" is.

Name the fixture. Which unit, which revision, which supply, which probe, which software version on the host side. A criterion measured on an unspecified setup is not a criterion.

Make the firmware produce its own evidence. A diagnostic mode, a self-report of version and configuration, a log that a remote operator can capture and send without understanding it. This is the single highest-return investment in a remote-acceptance engagement, because it converts their sentence into my waveform without a round trip.

Separate defect from difference. State in advance what happens when a test fails for a reason outside the delivered scope. Who investigates, who pays, and how the milestone proceeds. Deciding this in advance costs an awkward conversation early and saves an expensive one late.

Time box the stage with a defined fallback. If the remote test cannot be run within a stated window for reasons on their side, state what happens. Usually: the milestone closes on the evidence available and remaining work moves into the support block.

What this is not

It is not shifting risk onto the client. The total fee is unchanged and the work is unchanged. What moves is which stage carries the exposure, and the argument for moving it is that neither party benefits from a plan whose completion depends on the least observable step.

It is also not a reason to skip remote acceptance. The test on their hardware is the test that matters, because it is the only one run in the real configuration. The point is to arrive at it with almost everything already proven, so the stage verifies rather than discovers.

The honest limit

This is a structure for bounding exposure, not for removing it. If the firmware is wrong, remote acceptance will find it, and you will be fixing it across a slow loop regardless of how the milestones were weighted. Weighting does not improve the diagnostics, it only limits what is riding on them.

It also depends on the client agreeing to a shape that looks unusual. A plan with a small completion payment reads, to a procurement team used to holding a large retention, as a weaker guarantee of delivery. The counter-argument is that a large final payment gated on an unobservable stage creates an incentive to argue rather than to fix. That argument is winnable, and it is a conversation, not a clause you can slip past.

And controllability is a judgement, not a measurement. I have scored a stage as high control and then discovered the real variance was in the hardware revision, not the firmware. The ranking is a tool for thinking, and it can be wrong about the specific project in front of you.

FAQ

Why should the final milestone be the smallest on a fixed-price firmware project? Because when final acceptance runs on hardware you will never physically touch, it is the stage you control least. You cannot probe the failure, cannot inspect the fixture, and cannot act without someone else's bench and calendar. Weighting payment by effort puts the largest sum behind that stage. Weighting by controllability keeps the exposure proportional to the chance of closing.

What does weighting milestones by controllability mean? Rank each stage by whether you could diagnose and fix a failure in it without depending on someone else's equipment, attention or schedule. Your own bench ranks highest, a deterministic harness next, real hardware in your hands after that, and hardware you will never touch lowest. Then size the payment and the scope of each stage inversely to that risk.

How do you keep a small acceptance milestone from stalling forever? Write every criterion as a measurement with an instrument, a method and a threshold, agreed before work starts. Name the exact fixture. Build a diagnostic mode so the firmware produces its own evidence. State in advance who investigates a failure outside the delivered scope, and time box the stage with a defined fallback if the test cannot be run.

Is this just moving risk onto the client? No. The fee and the work are unchanged. What changes is which stage carries the exposure. A large final payment gated on an unobservable stage gives both parties an incentive to argue about attribution instead of fixing the problem, which is worse for the client than for the supplier.

What is the highest-return thing to build for a remote acceptance test? A diagnostic mode that makes the firmware report its own state: version, configuration, error counters, and a capture a remote operator can export without understanding it. It converts a one-sentence failure report into actual data, which removes the slowest step in the loop, which is the round trip needed to find out what was actually observed.

Should remote acceptance be skipped if it is this risky? No. It is the only test performed in the real configuration, so it is the one that matters. The aim is to arrive at it with nearly everything already demonstrated on a bench you own, so that the stage confirms known behaviour rather than discovering new behaviour under the worst available observability.