Milestones are often confused with Condition Of Satisfaction (COS). Milestones are specific interim results that must be produced by a particular time in order to produce a Condition of Satisfaction.
Milestones differ from COS in that Milestones create a framework for the achievement of the project. At this point, you have a clear idea about the end of your project, but no sense of the smaller steps to get from here to there (or “The Merlin” way of thinking of it, from there to here.) Milestones make the project clear in scope, make it more tangible, and reveal most of the resources you need. Also, they can reveal breakdowns you may encounter beyond those that are immediately obvious.
To Create Milestones
Create milestones for each COS Separately. Start with each end result and work backwards asking the question “What must happen before that can happen?”
You will not be able to do this in a completely linear fashion, because that is not how people think, but starting with the end result will yield a more linear through process than starting at the beginning.
The discussion to determine milestones can be a brainstorming session of sorts. It happens in streams of consciousness which sprout other streams of consciousness. It is a give and take conversation in which the connection between the future and the present becomes real. It should be allowed to flow freely.
The discussion is not without discipline, though. The tendency will be to discuss the details of each milestone. Keep the conversation focused on the results to be produced.
After most of the milestones have been listed, make sure they are in order and put dates on them. Some will fall into natural groupings. Efficiencies will reveal themselves, as will resource needs and leveraging opportunities. And perhaps most importantly, it will become clear who must be involved either for their decision-making capacity or their expertise.
Often during the process of defining the timelines, you will find that one of the COS you had defined is actually a milestone of another one. In other words, you must complete one before you can start work on the other.
For example: At a recent project design for an IS project, “new servers installed” and “new software installed and tested” were both defined as COS. As the team established milestones for installing the software, they realized that there servers had to be installed before they could install the software. Therefore, installing the servers was a milestone for installing the software, not a COS.
If we hadn’t done the milestone process, the dependency would have been discovered when the folks accountable for installing the software went to work on their piece of the project.
If you had a project of increasing employee satisfaction by a minimum of 20% by the next survey, one COS might be “and 80% participation rate in the survey.” The milestones might be as follows (each would need a completion date):
- Get a count of employees at each site.
- Designate a site sponsor for each survey site
- Have a meeting of the sponsors to determine a plan
- Create and implement a plan for employee communication
- Provide training for the site sponsors in introducing the survey.
- Have the site sponsors contact the site manager to create partnership and get buy-in.
- Create convenient methods of filling out the survey which maintain confidentiality.
- Conduct the survey.
- Collect the surveys.
This is neither the ‘right’ set of milestones, nor the only way they might be ordered. But they should be in time order.
The best way to create milestones is in a meeting of the entire project team. If this isn’t practical, the next best approach is to assign the creation of milestones to groups of people who will be responsible for achieving the various conditions. The least desirable approach is for just one person – the project manager or any one person on the team – to create the milestones.
Once you have finished the milestones, it is time to assign accountabilities, create groups or committees, get alignment on dates from groups, establish a communication protocol, and design a way to work out breakdowns or issues that arise during the project. Each person or group accountable for a COS will design their own strategies and plans for achieving their milestones.
in some companies, there are other elements that must be produced before a project can be considered fully designed. These may include the budget, the impact on the company, or linear responsibility charts. These are much easier to create if you have first completed the process described above.
This approach has been used effectively in both large and small companies, for huge, strategic projects as well as small departmental ones. Practice it, use it and it will serve you well.