Reducing Schedule Risk
One of the most common problems with software development is managing the project schedule. How can you consistently deliver a project on time?
While there is no silver bullet against overly optimistic schedules, you can reduce schedule risk through Project Milestones, a best practice that requires you to identify and track significant points or achievements in your project.
The following 5 principles highlight the key points of the Project Milestones best practice.
Define Milestones Early in the Project
As a general rule, the sooner you implement a best practice in your project lifecycle, the better. Project milestones are no exception to this rule. All milestones should be identified early on, and they should be transcribed on a project plan or visual chart such as a PERT diagram (see Figure 1).
Figure 1. PERT diagram
While a chart on its own will not necessarily help you reduce schedule risk, it will significantly increase visibility of the key milestones and project’s progress, which is important to other managers.
Even though I recommend you start tracking milestones at the early stage of the project, keep in mind that it’s never too late to implement this best practice. It can be beneficial at any phase of the lifecycle, especially during project recovery.
Keep Milestones Small and Frequent
To reduce schedule risk, you must focus on miniature milestones. If you're delivering a software application, you clearly want to track major achievements such as the code freeze date. However, those milestones alone do not give you a realistic view of the project’s progress. In Figure 1, if you were to only track the code freeze date, you wouldn't realize the project is late until it is complete. By then, it would be too late to rectify the situation. All you could do at this point is project recovery.
To reduce schedule risk, you need to identify small, frequent milestones, such as signing off on written requirements, having a developer do a demo of his/her prototype and feature, and submitting a unit test report. Generally speaking, you should have anywhere between 1 and 5 milestones per week, depending on the size and duration of the project.
The Set of Milestones Must Be All Encompassing
When identifying the milestones, make sure you include every task required to release your software. Omitting necessary activities will most likely result in missing functionality and/or artifacts, and perhaps a schedule slip.
In order to identify an exhaustive list of tasks, ask your developers to prepare a list of everyday jobs that you can include in your PERT diagram. Also review milestones you used in previous projects. Keep in mind that milestones should go beyond the implementation of the software code and should include other activities such as documentation and customer training.
Each Milestone Must Be Binary
Define milestones so that they are either complete or incomplete. Make them binary, and clearly identify how you are going to measure their completion. Not only will this help you reduce schedule risk, but it will also motivate your software developers by making them responsible for a tangible delivery.
Reporting milestones in terms of percentages is too subjective and doesn't present a realistic view of the project’s progress. In software development, when the first 90% of a feature is complete, the second 90% begins. Don't mark a milestone as done when it’s “almost” done.
Carefully Monitor the Critical Path
A critical path is the path that dictates the fastest time at which the project can be completed. In Figure 1, the critical path highlighted in red indicates that the fastest time to completion for the project is 22 weeks (8+4+3+3+4=22).
While reaching every milestone is important to the success of a project, you must pay extra attention to the achievements on the critical path. The Feature A milestones could slip by a few days or even weeks without affecting the project’s schedule. However, if one of the Feature B milestones slips, the release date is going to slip accordingly.
It’s therefore critical that you carefully monitor the critical path and shuffle resources from one area to another if you anticipate that the milestones on the critical path will not be accomplished on time.
Monitor Your Progress and Revise Your Plan
There you have it. Another simple yet effective best practice that will help you reduce schedule risk. Keep in mind that the earlier you know a milestone is in jeopardy of not meeting its target date, the more successful you will be at keeping the project on track. In view of that, make sure you measure the status of the milestone using the binary metrics you pre-defined.
In the event that a milestone is late and you cannot rectify the situation, update your plan accordingly. Do not try to hide the fact that a milestone has not been completed on time or that the critical path has slipped. Do your best to pro-actively rectify the situation, and when you can’t, recalibrate your plan.
This article was originally published on www.gantthead.com.