A milestone called “UAT sign-off” is marked complete on the plan. The developer moved on. Three weeks later the client opens the module, finds two fields missing, and asks when it was signed off and by whom. Nobody can answer, because nobody actually reviewed it. Someone dragged a status from amber to green on a Friday afternoon and the project moved on.
That is the third leak. Not a missed deadline, which is visible and argued about. A missed project milestone review, which is invisible until the rework arrives, and by then the cost has doubled.
Why milestones fail quietly
A deadline has a date, so it announces itself when it slips. A milestone has a date and a judgement, and the judgement is the part that gets skipped. The date passes, the work looks roughly done, and the plan gets updated to say so.
Three things make this easy to do.
First, “done” was never written down. It lived in a scope document written two months ago, in a call nobody minuted, and in the head of the person who sold the work. Ask three people on the project what the milestone required and you get three answers, all reasonable.
Second, nobody owns the review. The plan says the milestone is due on the 14th. It does not say who looks at it on the 14th. When ownership is shared between a project manager, a technical lead and the client, it belongs to nobody.
Third, there is no consequence for silence. If the approver says nothing, the project continues as though approval happened. Silence is treated as yes, but never deliberately, which means nobody planned for what silence should mean.
Fix those three things and most milestone drift disappears. You need a written definition of done, one named approver, a review window with a date on it, and a stated default for what happens when the window closes with no answer.
Write the definition of done before the work starts
A definition of done is not a description of the work. It is a list of observable facts that must be true for the milestone to pass. Someone who was not involved in the build should be able to check it.
Compare these two.
Weak: “Complete the dealer portal login module.”
Useful: “Dealer can log in with mobile number and OTP on Chrome and on Android. Failed OTP shows an error and allows retry three times. Locked account triggers an email to the admin address. Tested with five dealer accounts from the client’s own list. Screen recording attached.”
The second version can be checked in ten minutes by someone who has never opened the code. The first version can be argued about for a fortnight.
Write the definition of done at the point you scope the project, not at the point you deliver it. If you are writing it during delivery, you are negotiating, not reviewing. The same discipline that makes an invoice match the work also makes a milestone reviewable, which is why scoping the project properly is the real precondition for all of this.
A workable definition of done has four parts:
- The deliverable. What object exists at the end. A document, a build, a data migration, a training session with an attendance list.
- The acceptance checks. Three to seven statements that are true or false. Not “works well”. Either the report exports to Excel or it does not.
- The evidence. What the reviewer will be shown. A link, a PDF, a recording, a test login with credentials. If evidence is not specified, the review becomes a meeting.
- The exclusions. What is explicitly not in this milestone. This is the line that saves you later.
Seven checks is about the ceiling. Beyond that, reviewers skim, and a skimmed checklist is worse than no checklist because it produces a signature without a review.
One named approver, and only one
Every milestone gets exactly one approver, named as a person, not a role and not a company. “Client to approve” is not an approver. “Priya in their finance team” is an approver.
One person feels risky. It is far safer than a committee. A committee of four means four people each assuming another has looked, and the approval arriving as a WhatsApp thumbs up from whoever read the message last.
The named approver can consult anyone they like. They cannot delegate the decision without telling you who now holds it. If they go on leave, the project plan records the substitute before the leave starts, not after the milestone is missed.
For internal milestones the same rule applies. A design review approved by “the design team” is approved by nobody. On BizvoraOne, milestones carry a review gate with a single owner attached, which is a small constraint that removes a large category of argument.
Split approvers by type of judgement, not by seniority:
- Functional acceptance: the person who will use the thing daily.
- Commercial acceptance: the person who signs the payment.
- Technical acceptance: your own lead, before it ever reaches the client.
Run the technical gate first, internally. Sending unreviewed work to a client and calling it a project milestone review is how you burn the client’s goodwill on your own defects.
The review window
A gate without a clock is a queue. Give every milestone a review window and put both dates in the plan: the date evidence is submitted, and the date the review closes.
Three working days is a sensible default for most SMB work. Two is tight if the approver has a day job, which they do. Five starts to stall dependent work. For anything that requires the client to test with real users, give five and say so at scoping time.
The window starts when the evidence lands, not when the work finished. If your team completed the build on Tuesday and sent the test link on Thursday, the clock starts Thursday. This matters, because the most common way a review window gets eaten is by your own side sitting on the handover.
Write the window into the schedule as its own block of time. If a milestone is due on the 14th and the next phase starts on the 15th, you have not scheduled a review, you have scheduled a formality.
What happens when nobody signs off by the date
This is the part almost everyone leaves undefined, and it is the part that decides whether the gate is real.
You have three options. Pick one per project, write it into the contract, and say it out loud on the kick-off call.
- Deemed accepted. If the window closes with no response, the milestone passes and the project proceeds. Common in fixed-price work. It protects your schedule and your cash flow. It is also the option most likely to produce an angry conversation in month four, so it only works if the submission was clear, the evidence was complete, and you sent a reminder before the window closed.
- Work continues, sign-off pending. The team moves to the next task, but the milestone stays open and unbilled. Safer for the relationship, worse for your receivables, and it lets open gates pile up until you have five unsigned milestones and a client who wants to renegotiate all of them at once.
- Hard stop. Nothing downstream starts until the gate clears. Reserve this for milestones where proceeding on an unapproved base means expensive rework: data structure, integration contracts, anything with a regulator attached.
Most projects need a mix. Use hard stop for the two or three structural gates and deemed accepted for the rest. What you must not do is leave it undecided, because the undecided default is always option two, chosen by accident.
Whichever you pick, add one mechanical rule: an unanswered gate escalates by name, not by broadcast. Day one after the window closes, your project owner contacts the approver directly. Day three, it goes to the person who signed the contract. Recorded each time, in the project record rather than in a chat thread. Keeping that trail out of chat is easier if you have already moved routine project updates off WhatsApp.
Where this does not apply
Gates cost time. On a two-week engagement with one deliverable, three formal gates will annoy everyone and protect nothing. Use one, at the end.
Retainers are also a poor fit. Ongoing monthly work has no natural milestones, so forcing them produces theatre. Review the month instead, once, against an agreed scope of hours or outputs.
And if your client genuinely cannot review inside a week, do not pretend otherwise in the plan. Build a ten-day window, quote the timeline accordingly, and let them see the cost of their own review speed at scoping time rather than at delivery.
What to do first
Open the project that is currently causing the most friction. Find the next milestone due.
Write four lines: the deliverable, five acceptance checks, the evidence you will send, and what is excluded. Name one approver. Put the submission date and the review close date in the plan as two separate dates. Email the approver both dates and state what happens if the second one passes in silence.
That is one milestone, in about twenty minutes. Do the same for the next project’s structural gate. Once two projects run this way, the pattern travels on its own, because the first time a gate saves a fortnight of rework, nobody needs convincing again.
