There is an old joke in programming attributed to Tom Cargill of Bell Labs: the first ninety percent of the code accounts for the first ninety percent of the development time, and the remaining ten percent of the code accounts for the other ninety percent of the development time. It is funny right up until it is your project. Because in real life it looks like this: at every meeting You are told "almost done, about ninety percent", and so it goes for three weeks in a row. And then another three.
I have watched this picture many times, sometimes, I admit, from inside my own projects. And I have come to the conclusion that the problem is almost never lazy developers. The problem is how we measure progress. If You measure it wrong, honest people will honestly report wrong numbers.
Percentages lie, milestones do not
"Ninety percent done" is an estimate of a feeling, not a fact. The developer has done the bulk of the work, sees that little remains and names a number. He is not lying. He simply does not yet know that the remaining "little" hides an integration that will not work the first time, edge cases nobody thought of and changes after the demo to the client.
So the first rule of deadline control: replace percentages with milestones. A milestone is not "work on the payment module is in progress" but "card payment works on the test server and You can try it". A milestone has two states: reached or not. No "almost". It can be shown, touched, checked. Like stations on a railway: the train has either passed the station or it has not. Nobody says the train is ninety percent in Kharkiv.
Progress that cannot be shown is not progress but hope. Measure what can be opened and touched.
The rhythm of checkpoints
The second rule: milestones must be frequent. If the first verifiable point in a project is three months away, You fly blind for three months. When it finally turns out that something went wrong, fixing it will be late and expensive.
I prefer a rhythm of one to two weeks. Every week or two there should be a demo of a working result, however small. It disciplines everyone. The team cannot spend a month working on something nobody sees. The client sees where the project is heading and can adjust the course while that is still cheap. The manager gets real data on speed rather than impressions.
It helps when milestones grow out of the project's decomposition. If You have read my article on WBS, You know that a project breaks down into work packages. Milestones are placed where a logically complete group of packages closes and can be shown as a result.
The Gantt chart and the critical path
Many people dislike the Gantt chart because it looks like bureaucracy from the last century. Bars on a timeline, arrows, dependencies. But it has one irreplaceable property: it shows what depends on what. And from this follows the concept of the critical path, the chain of tasks where a delay in any one of them shifts the entire project.
Knowing the critical path matters because not all delays are equal. If a task with slack is a week late, the project will not even notice. If a task on the critical path is a day late, everything is a day late. A manager who understands this distributes attention correctly: he watches critical tasks like a hawk and does not pester people about the rest.
Where to keep the reserve
Every experienced manager builds a time reserve into the plan. The question is where to keep it. Intuitively You want to add a little to each task: a couple of days here, a couple of days there. The problem is that work tends to fill all the time allotted to it, which was noticed long ago and is called Parkinson's law. If a task is given five days instead of three, it will take five. On top of that, people tend to start working in earnest closer to the deadline, the so-called student syndrome.
So it is better to keep the reserve separately, as a shared buffer at the end of a stage or project. Tasks are estimated honestly, without padding, and the buffer is spent only when something really goes wrong. And the rate at which the buffer is consumed becomes an excellent indicator of the project's health in itself: if half the buffer is gone in the first third of the way, it is time to sound the alarm.
The most important thing: early signals
Everything above is tools. But the main thing in deadline control is not tools but a culture in which problems are raised early. A missed deadline is almost never a surprise to the person actually doing the work. He knows about the risk weeks ahead. The only question is whether he will say it out loud.
People will speak up if they know that bad news will bring help, not punishment. If messengers with bad news are traditionally executed, You will learn about problems on the last day, when nothing can be done anymore. That is why I always say thank You for early warnings, even when the news is unpleasant. It is the cheapest information in a project.
What to do tomorrow
Look at your current project and replace all percentage statuses with two-state milestones. For each upcoming milestone answer: what exactly will You be able to open and check when it is reached, and when will that happen. If the nearest milestone is more than two weeks away, break the path to it into smaller ones. And at your next team meeting ask not "what percentage is done" but "what is stopping us from reaching the next milestone on time". The answer to that question is worth more than any report.
