Milestones are like progress bar indicators for internal stakeholders’ use. They provide feedback on progress to everyone involved. In different software programs, I have come across at least three different progress bars: the first easily reaches 90% then stalls, making you wonder if it has stopped.
The second one just shows that it’s working and does not stall but you don’t know how much work remains to be done. The third one gives you the impression of accuracy because it provides a realistic estimate. Even if the progress bar indicates there is still a lot of time left, you tend to prefer it over other time bars because you know you have time to do something else. Let’s look on some aspects of tracing progress.
Your project is getting closer to a release deadline and you ask the lead developer, “How’s is it going? Are we going to ship on time?”
“Hmm, something has come up!”, she tells you, “I have done really great for the last 4 weeks, but today I found something no one thought about and the timetable slipped 3 months.”
What’s the chance of that happening? I’d say it’s a small chance. The reason is timetable slip-ups don’t happen at the end of the milestone or project. Slip-ups show up at the end. Yet they happen every day and every hour. As soon as someone answers an unexpected e-mail, rushes home because of a sick child, or tracks down an intermittent but catastrophic bug, slip-ups happen. The sooner you can identify how much time is left and prevent slip-ups, the better you can estimate time periods, assuring team members and stakeholders that the timetable is still reliable.
