The cost of waiting
On a fixed-price project the team is staffed from day one. If the client has not finished its internal analysis and the requirements are not signed off, every idle day comes straight out of the budget. The pressure to start development lands on the project manager, and there are two bad answers to it.
The first is to wait and log the delay as client-caused. It is correct on paper, and the team sits idle while the budget burns. The second is to build whatever the team thinks is right and show it later. The client loses control, and a wrong guess surfaces at the worst possible moment.
A third option: plan against documented assumptions
I build on the most likely interpretation of the requirement, I write it down, and I agree a validation date with the client. The team stays productive and the client stays in control, because nothing is hidden. In practice it sounds like this:
We will build on this interpretation from Monday. If it is wrong, the change is small and visible. Can you confirm it by Thursday?
How I write an assumption
- A clear statement in business language: what we believe the requirement means.
- An owner on the client side who can confirm or correct it.
- A validation date, agreed with the client rather than announced to them.
- A note of the cost if we are wrong, so the riskiest assumptions are confirmed first.
What this is not
It is not building in secret, and it is not a way around the sign-off. Assumptions live in the RAID log next to risks and dependencies, they are reviewed every week, and the client sees them. When one turns out to be wrong, the change is small because we found out early, and it is visible, so nobody is surprised.
Which assumptions to confirm first
Not all assumptions are equal. I rank them with two questions: how likely is it that we are wrong, and how expensive is it to change later? An assumption about a label on a screen can wait. An assumption about how two systems exchange data, or about who is allowed to approve a payment, cannot. The riskiest ones go to the top of the validation list, and I ask the client for those answers first, even while the rest of the requirements are still moving.
None of this replaces a proper sign-off process. I agree that process with the client at the start: who signs, in what form, and within how many days. Assumptions only bridge the gap while the process catches up. When the sign-off arrives, the assumption is closed in the log, with the date and the name of the person who confirmed it. That small record is often what keeps the conversation calm if a requirement changes later.
In the fixed-price delivery division I led, this was one of the practices that helped keep bench time at zero while billability grew year on year.