PM Practice: Using Milestones

While hiking on a trail outside a Swedish town where I used to live, we passed a milestone on the side of the path. This piece of stone was about a foot wide, 6 inches thick, 4 feet high and many hundreds of years old. There were a couple of features about it that caught my attention.

It was easy to spot from a distance, but it didn’t take up much space. The face of it was inscribed with one number indicating where we were on the path and a 2nd number informing travelers how far it was to the next major town. As we walked along the path, we were either moving towards it or, having passed it, moving away from it. The time that we spent ‘at’ the milestone was maybe a second. The parallels to project milestones make it clear why these ‘moments on the path’ share the same moniker:

• Milestones provide a clear measure of progress and are uniformly visible to all stakeholders. When you pass the ‘Design Complete’ milestone, pencils go down and girders go up. If you’ve still got a pencil in your hand, you haven’t passed the milestone yet.


• Milestones have no effort associated with them. Tasks do. ‘Design Complete’ is a milestone. ‘Complete Design’ is a task.


• Milestones have no duration. They’re just markers on a path. If you stop to marvel at your accomplishments upon reaching a milestone, fine - many people do. But that’s a task (‘Admire Progress’) that has nothing to do with the milestone.


• Milestones are either 0% or 100% complete. There is no ‘50% complete’ for milestones. Once you complete all the tasks needed to reach the milestone, the milestone is passed. Until then, keep working.


• Different milestones may hold the interest of different stakeholders. ‘Key’ milestones are of interest to everyone and often associated with either a major deliverable (‘Test Case Creation Complete’) or a change of the project phase (‘Testing Complete’).


• Milestones are placed with reasonable regularity. I aim for some kind of milestone about every 4 to 6 weeks. Agile Project Management leans heavily on this idea because sponsors need only commit to the process incrementally.


• Key Milestones are on the critical path. As a communication tool for progress, they work better when they don’t wobble around due to float.

Some milestones existing today have been in place for centuries, yet still convey accurate information (Stockholm hasn’t moved). They tend to be stable. Project milestones are similar.

PM Practice: The Right Way to Track Actuals

Most project managers I know track actuals at a task (e.g., 25% complete) or duration (e.g., 4 days spent, 3 days left) level. Effort (or work) is generally left to be managed by their scheduling tool. The method you choose for tracking actuals affects the ability of your schedule to predict final time, cost, or scope. The problems come when PMs use task-level tracking (low predictive power) in order to manage a project where high predictive power is required (i.e., project milestones are 'set in stone').

Effort is the real currency of most all projects. It measures, in hours, the heads-down work performed by individual members of the project team. It is a key determinant for the duration and cost of most tasks. Project managers that track actuals at an effort level are able to sort out what is causing delays or cost overruns because their project data is more granular. When I track actuals in my projects, I can make smaller, more targeted, corrections in concert with my project team. My projects still slip (after all, we only manage risk, we don't control it), but they do so less often, and usually less dramatically (and therefore more correctable).
Tracking actuals at the effort level is just as easy as other methods. I follow these steps:

1. Each week, my team reports ATD (actuals-to-date), in work hours, for any task that was ongoing at some point during the week. I build my schedules such that each team member will typically work on 1 to 3 tasks per week.
2. For each of these tasks, my team also provides and ETC (estimate-to-complete). Obviously tasks that they completed will have an ETC of 0 hours. Steps 1 and 2 take each team member about 5 minutes a week.
3. I set up a tracking view in my scheduling tool (whatever my client needs me to use) that allows me to apply ATD and ETC to individual tasks every week. There are tons of tools that will automate this process, but even if I do it manually, we are talking 10-15 minutes every Monday morning for a team of 30 people.
4. I save my project plan, updated with last week's actuals, and begin my weekly upkeep (a tidy schedule is a defensible schedule I always say!).

I have taught several hundred project managers the nuts and bolts of this process over the years and those still in the job today couldn't imagine not tracking their actuals another way. Anyone can learn how to do this and the impact on project manager performance is a blast to watch. New project managers gain confidence because they develop a better understanding of their projects. Experienced, capable PMs get a real boost from this method because it helps them validate their intuition about adjustments they may need to make.

Agile adjustment: This practice works with Agile, though you may choose to shorten the interval from a weekly timesheet to a daily verbal report of ATD and ETC. Properly measured, tracking effort can help Agile teams compensate for deficiencies in the organizational implementation of the development method ... but that discussion is for another time.