Planning milestones that can be verified — questions

Only the milestone can be passed or missed observably. "We are in the implementation phase" cannot be false. "Attendance recording is archived and its two scenarios ran in front of the client" is either true or not, and everybody in the room can tell which.

That is why a milestone is neither a celebration nor a report: it is a question with a yes-or-no answer, agreed in advance.

Points the answer must contain:

By <date>, <observable condition> is true, checkable by <who> through <how>.

Three properties of the right column: an observer outside the team, because self-certification turns a milestone into a ceremony; a named mechanism, so nobody invents the check on the day; and a condition about the behaviour of the system rather than the activity of the team, which is what lets it survive a change of plan.

The strongest criteria are machine-evaluable — "the pipeline is green on `main`" needs no meeting. Use those where they fit, but do not force them: the interesting milestones involve a person watching the software work.

Points the answer must contain:

Where the uncertainty is — their job is to convert an unknown into a known while the answer still leaves options.

Two rules carry most of the value.

The first thin end-to-end slice goes early. One capability from interface to database, deployed, says more about the project’s risk than three capabilities that all stop at the service layer. Deployment, authentication and the machine nobody has access to are what turn into three lost weeks, and they only surface when something is joined up.

Leave a milestone between feature-complete and the deadline. A slip discovered at the deadline has no answer; one found four weeks earlier can still be answered by cutting scope, which somebody is allowed to decide.

Points the answer must contain:

A systematic slip.

Each individual delay has a good reason and sounds like bad luck. Three in a row moving the same way is not luck — it is a rate, and a rate can be extrapolated to a date nobody wants.

A status report cannot show this because it only ever describes the present. The trend is built by recording, at every review, the expected date of every future milestone — which costs one line per milestone per review.

Honest use: raise the scope conversation early, while the options exist. Dishonest use: leave the date where it is and hope, which is how "we are on track" can be said truthfully every week until the last one.

Points the answer must contain:

Four, and missing one is ordinary — what is assessed is what happens next.

What is not a response: working more hours and saying nothing. It is unverifiable, it does not survive February, and it removes the one thing the milestone existed for — telling somebody else early that a decision is needed.

And the one move that destroys the instrument: lowering the criterion so it can be met. That converts the whole system back into a self-report.

Points the answer must contain:

Because it cannot be false.

There is no condition anybody outside the team could check. The phase ends when the team says it ends, so the statement carries no information and the milestone records nothing except that a date passed. Every project reaches every phase.

It also fails the other two tests. There is no observer — the team certifies itself. And it describes team activity rather than system behaviour, so when the plan changes, the milestone becomes meaningless rather than merely missed.

The repair is to ask what would be observably true if the phase really were complete, and to write that instead: "by 2027-02-06 all capabilities in specs/ are archived, the pipeline is green on main, and the reviewing team has run two scenarios of their choosing on the deployed app." That can be failed — which is the entire point.

Points the answer must contain: