Plan milestones

 

 

Where are we?

You are now at the start of the definition phase. You have had your project brief signed off by the sponsor and you are ready to start detailed planning. We will work from the top down, starting with milestones.

 

What is a milestone?

We must be careful with the term milestone, as it is in common use, with many meanings. In project management we will use the term with the specific formal meaning of ‘a point in the project where something physical is produced’.

This simple definition is loaded with meaning in the project context. We will make great use of milestones in both planning and control.

The important part of the definition is ‘something physical’. If your project produces a physical ‘product’ or ‘deliverable’ then you have an opportunity to examine it and make a considered decision about real progress towards your overall objectives. If you can specify in advance what the acceptance criteria are for the deliverable then you should feel very comfortable when trying to measure the progress.

Some milestones (the ones really important to the sponsor) will be visible at this stage. Major milestones are directly tied into what you are trying to produce on the project and should be specified at project definition.

This shows the full format of a formal milestone definition. It has the following parts:

The milestone name, in noun/verb format

• The quality standard
• The testing method
• The person authorised to accept it

Not every milestone needs such formality, but on every project there will be a few major milestones for which you would be well-advised to develop such comprehensive descriptions.

You might be thinking how much work this might entail for you. Well, firstly, if you cannot specify in advance the acceptance criteria for one of your deliverables then you must either accept just any old rubbish that is produced or employ telepaths as project team members.

Secondly, if you can specify the acceptance criteria in advance then the person carrying out the activity will have a much better idea of what to produce. This means that you can start to build quality into your project right from the planning phase, by setting up a control structure that is based upon pre-defined acceptance criteria.

So, milestones are good things. They create a safe and secure control structure for the project. When you ask a team member how an activity is going, you may be told “it’s 90% complete”. You will have no idea what that means, but a milestone cannot be 90% complete. It is either achieved or it is not. This makes for fewer arguments and a safer project.

 

When do we identify the milestones?

There are two ways of planning with milestones. If you are running a project where the pattern of milestones is well-known (and where you would be foolish to deviate from the ‘standard’ pattern) then you can indulge in ‘top-down’ planning.

This entails you identifying the milestones first, and adding in the detail later in the planning process. In any case, in most projects you will be able to see the major milestones associated with project deliverables, right from the outset.

The second method of planning is to carry out detailed planning first, and then add in the milestones later (bottom-up planning). In fact, many project plans are arrived at by a mixture of major milestones identified at the outset and then a series of ‘minor’ milestones added in by the project manager later.

Oh yes, you can add in your own milestones if you wish. As they are an excellent method of keeping close control of the project there is nothing to stop you adding milestones into parts of the project for which you want closer control.

This leads on to an interesting suggestion. If you are running a project about which you know a great deal (you are familiar with the technical activities in the project) do you really need a detailed plan (see the next chapter for some examples of detailed plan). Maybe all you need is a milestone plan, which has less detail (and therefore will be easier to read and update) but which can be very safe in terms of control.

The example below is a milestone plan for the Lake project.

This milestone plan is a simple list, and can be created using a word processor or a spreadsheet. It has the huge advantage that, in being simple, the sponsor might read it, whereas he/she might not read a more complex schedule.

 

What happens at milestones?

Milestones are places where the project manager and sponsor can make serious decisions, such as:

• All is well, let’s go on to the next milestone.

• Things are slightly off track; make some adjustments to get back on track by the next milestone.

• Things have gone badly wrong; we need to stop and consider our options.

• Things have gone well so far, but we need to change the scope of the project.

• We need to change the budget, or the target end date, or the resources, or the technical solution, or the project manager, or the sponsor, or almost anything.

• We need to stop the project, either to a pause for review or as a full cancellation.

To make sensible decisions the key players need facts and figures about the project and the actual progress. The project manager is the only person who can provide such information, and milestones are the mechanism. Examples of milestones being used to control the project are discussed in the chapter on controlling progress.

 

Where do milestones come from?

You will certainly wish to consider:

• The project brief (to identify the main deliverables and hence milestones)

• Your own experience and knowledge of this type of project (less experience will mean more milestones for safety)

• Your colleagues, team members, customers, sponsor, boss

• Regulators or inspectors (people who have the power to sign-off something you will produce)

• Books, manuals, guidelines, methods (which may explain how to break a project down into manageable pieces, each with an associated milestone)

Look for any deliverable that you will produce that can be used as a milestone check-point.

 

How are they documented?

Well, we saw above that a milestone plan could be just a simple list. The example below is another way of presenting a list, this time in a slightly more graphic form:

In many smaller projects the person responsible for every milestone will be you, the project manager, but it is worth thinking carefully. Can you find someone ‘independent’ who will sign off one or more of your deliverables?

During the planning of the project you should be able to estimate a target date for each milestone. Obviously this is easier with bottom-up planning, where you have the detail first and the milestones emerge from that.

By creating a milestone plan (even if this is accompanied by a detailed plan) you can keep the communication with the sponsor at a simple level. Many sponsors would be quite happy with a milestone plan if they knew that the detailed plan existed behind it.

 

Summary

Milestones provide not only the framework for planning the project but also an excellent control mechanism. Your milestone plan will become an effective communication and control tool for the sponsor.

For a smaller or more local project you may feel that a milestone plan is all you need for safe and simple planning and control

 

 

Thanks to Mike Watson of Obsideo for providing this book