Definition

Email this page to a friend   

Milestone

(Alias: management gate)

At 15 I set my heart upon learning.
At 30 I established myself (in accordance with ritual).
At 40 I no longer had perplexities.
At 50 I knew the mandate of Heaven.
At 60 I was at ease with what ever I heard.
At 70 I could follow my heart's desire without transgressing the boundaries of right.
             - Confucius

No Milestones = No visibility	Milestones = Visibility

Describing a Milestone  ⇑

In defining your Software Development Methodology (SDM) you should describe your milestones in terms of the following attributes:

• Milestone name. A short catchy phrase or acronym that describes the milestone (Example: Preliminary Design Review - PDR)
• Project event. A description of the project event to which the milestone is tied (Example: formal approval of the Preliminary Design by the PDR team)
• Milestone goals. The criteria that will be applied to determine if the milestone has been reached - the milestone goal(s) (Example: Preliminary Design approval).

When you apply the SDM to a specific project all your milestones should also be defined in terms of an absolute date or an elapsed time period from a previous milestone such as project commencement.

Setting Milestone Goals  ⇑

Make sure your milestone goals are verifiable. You should be able to verify a goal with a yes or no answer. For example, the Software Requirements Specification is either complete or not complete, the Software Design Description has either passed or not passed peer review. The software product is or is not in commercial operation.

Beware of fuzzy, unverifiable milestone goals that allow one phase of a project to merge into another resulting in loss of visibility and project control. For example, "high level design complete" is a fuzzy goal, "Software Architecture Design Description Document approved", is more verifiable.

Typical milestone goals are:

• Designated deliverables approved
• Phase completion review complete
• Tests complete and all anomalies rectified.

The verification that a milestone has been reached usually occurs in the context of a management review. Milestones are therefore often named after major project review meetings. For example, Critical Design Review.

In some situations the commencement of work can be a valid milestone, the principle being that you can't meet your end date if you haven't met your start date. Canny project managers often use this type of milestone when supervising remote sub-contractors. They prefer to know about late starts when action can be taken to lessen the impact of a late delivery on the project.

Major Milestones for Software Projects  ⇑

Milestones are classified as major and minor. The major milestones give visibly or progress to people external to the project. For example, project sponsors and customers. The table provides a set of classical major software project milestones together with their milestone goals.

Minor Milestones for a Software Project  ⇑

Minor (or micro) milestones are the monitoring points you as project manager use to maintain control of day to day activities. They divide the elapsed time between major milestones into shorter intervals to give you the confidence that the major milestones will be met. They also give the team a sense of achievement by demonstrating progress on a daily or weekly basis. The table provides examples.

How Many Milestones?  ⇑

How many milestones should your project have? The answer springs from the frequency at which you need to monitor progress to keep the project under control. This frequency is determined by how fast things can go wrong with no oversight. Two examples of common "go wrong" scenarios are:

• User rejection. A large team of developers burning through project funds at the rate of $70,000 per day takes three months (without intermediate milestones) to deliver a system function that is rejected by the end user.
  Solution: Implement Agile Development. Involve the user in the development process. Create a milestone every two weeks where the developers must demonstrate some functionality to the users.
• Immature technology. A project team is attempting to implement new technology in a production environment. The technology does not perform. Several workarounds are tried; all fail. At the end of six months, unbeknown to management, nothing has been achieved.
  Solution: Establish monthly progress review milestones. Require documented evidence of progress in Technical Investigation Reports.

The following scenarios further demonstrate how judicious use of milestones can maintain visibility of progress:

• Inexperienced people require daily milestones to ensure their lack of practical skills does not lead them too far down the wrong path
• Complex technical issues and algorithms need regular peer review and decision making to avoid "analysis paralysis"
• Large projects need fine grained deliverables to provide visibility that the project is progressing.

Rules of Thumb  ⇑

Some general rules of thumb in nominating milestones are:

• All tasks should have a demonstrable milestone at least once every 5 to 10 working days
• Code development needs demonstrable progress with a minor milestone every one to five days. In fact some development strategies call for a nightly build of the product
• If you are a project sponsor, a major milestone demonstrating progress at 1 to 3 month intervals will probably be adequate. After all, you have a competent project manager performing the micro management don't you?
• All projects should have at least 4 major milestones: requirements complete, design complete, code complete and test ready, and product shipped/accepted/deployed.