Milestones are important, and they are a pivotal part of managing projects. Milestones are a way to communicate project progress to your team and boost confidence from your management. In this video, Bob McGannon explores ways to help you make your milestones effective including frequency, placement, naming of your milestones and incorporation into your schedule.
- I have a good friend who does not like tunnels. Once he enters one, he looks for any markers or the familiar glow of daylight so he knows when he'll see the sky once again. In other words, when in a tunnel, he's looking for milestones. Milestones are important, and they're very useful in projects as well. Milestones are a way to communicate project progress to your team and management. And a good set of milestones will ensure you're communicating the right message to all your stakeholders at the right time.
However, technology projects often have milestones that aren't understood or timed well. There are a few things that help make milestones effective. The first is frequency. I recommend having a milestone about every six weeks. If you have milestones too often, you could be putting unnecessary scheduling pressure on your team. If you have milestones that are too far apart, the project can actually lose momentum and team members lose focus.
With agile projects, the milestone cycle should align with your sprints so each sprint completion would be a milestone. A second consideration for milestones is placement. Projects with a significant number of milestones near the end are at greater risk of not delivering. If one milestone slips, it typically impacts other milestones, and you won't have enough time remaining to recover the schedule. Focus instead on creating review milestones earlier in your project.
For example, schedule a compliance walkthrough of a major document when it's completed rather than waiting till the end of the project. If you follow the six week rule, you won't have a problem with placement. The third consideration is properly naming your milestones. This may sound extremely basic, but it's very important. If a milestone is written in a way that people don't understand what's to be delivered, then you're missing the while point. Use milestones to communicate progress and your achievements.
For instance, I could write a milestone as process maps complete or future business processes documented, gap analysis complete, or product to business process gaps identified. In both cases, the second milestone clearly communicates the progress that's been made. When I first develop a set of milestones for a project, I review them with my business team members and ask for their feedback. I'll ask them, does the milestone seem significant? Are there better words to use so it's understood? And are there milestones missing that would be important from a business perspective? My final recommendation for milestones is to compile them into a milestone schedule chart and review it with your business and technical management teams.
A good milestone chart demonstrates the roadmap you're following to achieve project results. That roadmap with well-documented milestones is your platform to illustrate the project's status. Use the roadmap to show the phases of the project and the milestones within each phase. As milestones are achieved, update the chart to reflect they've been completed. Management wants to see progress, and this is a great way to show how things are moving along.
Oh, and one last thing, try to fit your milestone chart on one page. For larger programs, you can have each phase of the project on a separate page. This makes it easier to show the progress you've made, and it helps your management team see when there is light at the end of the tunnel.
- Identifying and managing stakeholders
- Guiding process and organizational change
- Considering a cloud-based solution
- Planning a technology project
- Assessing risks and changes
- Executing a technology project
- Addressing challenges such as conflict and changing priorities