One of the important parts of tracking project progress is defining milestones. These are points during the project where the required tasks and the goals for time meet. It only makes sense that the definition of milestones and how they are treated are an important part of project success.
Defining Milestones Simplified
Although these steps in the definition process are necessary, that does not mean they have to be complex. Every project is different, but I have found these guidelines useful. In fact, I use them every time we need to craft milestones.
1. Milestones must have a deliverable
Defining a deliverable for a milestone is rarely a problem. However, I have seen vague descriptions like “complete the application UI” as the total of the objective. This description is a start, but not truly definable. Nor is there a deliverable mentioned. We have to be able to say a milestone is complete (or not) without ambiguity. This example is improved by including a UI demo to be delivered as part of the objective.
2. The deliverable must be visible to the customer
This point is often an issue during a project. There will be a step that includes securing the site or building a backend database. Unfortunately, the implementation does not have a visible result. That is not okay. Find a way to craft the deliverable so that the customer can see that progress has been made. The progress may be a login screen tied to an ACL or the result of some select statements to show default data in a database. When in doubt, modify the milestones, so the “invisible” work is part of visible steps.
3. Provide a Method For Feedback
Milestones are more than just getting work done. They are also an opportunity to gather customer feedback. Use the milestone deliverables as a way to verify the implementation is still on track with the vision and goals of the client. This option helps deliver a successful project instead of just delivering a project.
Defining Milestones For Success
We have already alluded to milestones being about more than progress. They can also be designed to improve the chances of a successful project. As mentioned earlier, the first step is to ensure that customer feedback is part of delivering any milestone. This goal can be achieved through regular demos and review sessions that coincide with milestone deliverables. I find that presenting milestone deliverables in some way is useful for drawing out feedback as well as a sort of test of the deliverables. That extra look over the deliverable can be a sanity check well also revealing gaps.
Scheduling the milestones in a way to reduce risk is recommended. When the milestones that have the most risk are tackled early in a project, it allows for the less risky steps to be used to make up time. Of course, that is not always possible. In most cases, the work on challenging items early in a project is a way to bring up estimation issues and slippage sooner.
Defining Milestones in a Vacuum
We are not always a part of the project definition. Thus, we run into those projects that are ill-defined and yet, we want to be successful. In these cases, I find it is best to break the work you control (or are assigned) into milestones. Your position in the team may not allow for customer feedback as part of milestone delivery. However, you can usually find someone to which the deliverable can be presented. Every little bit helps.
Even the largest projects can be broken down into smaller “sub-projects.” This step is where milestones come into play. Thus, an over-whelming or “impossible” task becomes more manageable. Since there are so many ways projects can go wrong we need to use tools like milestones to improve our chances for success wherever possible.
