Craig Brown (one of my favorite Blogs) posted a piece about the use of Milestones. Actually it was a comment from Eugenio regarding measuring small increments.
Here in the defense world we work very hard to NOT have milestones in the way discussed in the post. Are are the reasons:
- A milestone is essentially a rock on the side of the road stating how far it is to some place, or how far you've come. The Romans had milestones all over Europe and England shows the distance to Rome. But in the end that's all it is - "a distance marker."
- The milestone itself does not state attributes about the project, just that you've arrived at this milestone. So looking at the schedule you can't tell where you SHOULD be at this point, only that you've arrived at the milestone. It's up to another process to assess where you should be.
- The milestone is a measure of the passage of time not the state or maturity of the deliverables from the project.
So what do you do?
- Define a program (project) event that describes the expected maturity of the deliverables at this point in the project. This maturity needs to be predefined. "We'll have the preliminary system architecture defined and approved."
- Define the Accomplishments needed to reach the predefined state of maturity. "To have the preliminary system architecture, we must have accomplished the following..."
- Define the Criteria used to assess the completion of the work needed to produce the Accomplishment that reaches the predefine level of maturity
Below is a notional picture of the elements of what is called Integrated Master Plan / Integrated Master Schedule. This paradigm speaks about "increasing maturity" of the deliverables independent of the passage of time or consumption of resources. There is a schedule of course, but the schedule defines the sequence and duration of the work needed to increase the maturity of the deliverables. It is essentially secondary to the measurement of this maturity.
The units of measure of the increasing maturity are always measurable in some physical evidence that can be assessed as "complete."
To see this in MSFT Project, the following is again a notional example. The tasks are connected to the Accomplishment Criteria. These are the "exit" criteria for the Work Package containing the work effort. The Accomplishment Criteria (Criteria) then flow to the Significant Accomplishments which are the "entry" criteria for the maturity assessment Program Event.
The construction of the Event, Accomplishment, Criteria relationship is the Strategy for the successful completion of the project. It is the road map for increasing the maturity of the deliverables. Without this road map to show you where you are going, the only thing left are to look at the milestones along the way. But as well know seeing the milestone on the side of the road doesn't tell us if we're on the right road or if this road takes us to the destination.
The basis for this approach can be found in the Integrated Master Plan Integrated Master Schedule Preparation and Use Guide. While it may appear this document is arcane and used only in defense systems it is the basis of all credible project management processes for one simple reason:
You have to know what DONE looks like before you start on your journey. If not, you're lost before you start and you won't recognize it when you arrive.
For those using agile, DONE is at the end of the iteration for the interim progress. But you still need to know what DONE DONE looks like. And it's now when the money runs out.
Remember Covey's advice - start with the end in mind. That's the key to success in any project.
Anyone working in ERP or enterprise IT should have a look to see how complex software intensive systems are managed in other domains and contexts.
