“Milestone” or “Milestones” are words you’ll frequently hear in projects. Let’s take a close look at this matter:
• What is a ‘milestone’ in projects?
• How are milestones represented in a schedule?
• What kinds of milestones are there in projects?
• Defining milestones in projects – are there any rules of thumb for this?
• Are milestones linked to sequential tasks (successors)?
• Milestones, HCP and the HCP-Go – what’s the connection?
WHAT IS A 'MILESTONE' IN PROJECTS?
A ‘milestone’ is a special, important point in time. The common milestones are project start and project end, but there are many milestones that can be defined throughout the project lifetime – depending on the project scope. A milestone usually marks the end, or completion, of the execution of a certain package from the scope by entity A and the beginning of execution of a different package by entity B.
The milestone is in most cases defined as an important end point in a project – for example, completion of the creation of a website and its go-live, completion of digging a tunnel or obtaining a CoFo – Certificate of Occupancy for a high-rise building.
Sometimes a start point in a project can be defined as a milestone – for example, issuing an NTP (Notice To Proceed) order. This is the point in time where the entity that ordered the project instructs the contractor to begin his work in the project. Milestones marking the start of a task are, however, very rare, since it is usually more difficult to define whether or not a specific task has begun. For example – start of a software coding project – does it begin with the software specification, when the first line of code gets written, or perhaps after the first 100 lines of code have been completed? Start of casting a bridge pier – does this task begin when the casting of the concrete begins? or when the rebars get tied (before the concrete) or perhaps when the foundations for the pier are being drilled?
For the most part, it is easier to define and ascertain a task completion in the course of the project than a task starts.
HOW ARE MILESTONES REPRESENTED IN A SCHEDULE?
In scheduling programs, if you have defined a task with a ‘0’ duration (days/weeks/months or even hours – as a function of the project’s default definition in the program) – then it will be automatically defined as a milestone and will, by default, be marked as a black diamond.
In the following sample mini-project, two milestones can be seen – Start (task #1) and End (task #5) encircled in red on the left part of the screen.
In Project, there is also a possibility to enter the information definition for the task (task  → information ) and in the “Advanced” tab  check the “Mark task as milestone” . This way it is possible to mark, in the graphic configuration , an activity whose duration is longer than 0, as a milestone , however the software will take the duration of the task that has been defined in the schedule calculation. For example, in the mini-project, let’s define task B as a milestone:
WHAT KINDS OF MILESTONES ARE THERE IN PROJECTS?
In principle, three types of milestones are defined:
Contractual milestone – specifies a work package that has to be completed by a certain date and for which a predefined monetary amount is going to be paid.
Financial milestone – specifies a work package for which a predefined monetary amount is going to be paid. There is no deadline for completion.
Engineering milestone – specifies a work package. It does not bear a payable monetary amount and there is no deadline for completion.
You might come across contracts that have milestones with other names – however you will be able to classify them according to the above definition in accordance with the contract definitions.
By their very nature, penalties can only be defined for contractual milestones – if you do not get the work package done within the specified time allocated – or rewards – if the work package is completed ahead of the deadline.
WHY ARE MILESTONES DEFINED IN PROJECTS?
A project, by its very definition, consists of multiple work packages.
There are projects which are defined as Turn Key Projects – the project has a start date, end date and whatever happens in between is of no interest to the customer. He expects to receive one project, complete, finalized and ready to go – on the project completion date.
Conversely, in projects where the customer is involved and defines milestones – the customer has the possibility to track the project’s progress. At any point in time the customer examines the milestones while the project is in process: are they expected to be completed as specified in the contract, or earlier or later?
Milestones have another role of guiding the entity carrying out the project toward the issues which are of importance to the customer. When the entity carrying out the work receives the contract for execution – he will build the project schedule in accordance with the milestones specified in the project.
HOW ARE MILESTONES DEFINED IN PROJECTS - ARE THERE ANY RULES OF THUMB FOR THIS?
There are two basic rules that have to be integrated into the project while thinking of and understanding the significance of:
- Specifying the most important and critical points for completion in the project. Such points will be (for example):
- Points in time at which another entity has to receive a certain portion of the project.
- Completion of portions which are important to the customer.
- Points in time in this project, which involve other entities.
- In an infrastructure project which involves widening a road on which there is live traffic and where several traffic detours have to be done, it is possible to select all or part of the traffic detours and designate them as contractual milestones.
- In an SEO project for a website, a milestone can be defined as completing the selection of the search words which are important to the owners of the site.
2. The time elapsed between one milestone and the next must be proportional to the project duration and to the time that passes between one schedule update & control meeting and the next. If this definition sounds complicated, you are right – there is a measure of artfulness in this. Let me try and give some examples to clarify this matter. At the same time, you must remember, every rule has its exception and each project requires its own thinking-flexibility:
- If you are working on a 3-year project and you do an update & control meeting every month, then it is advisable to set a milestone every 6 months. In other words, there will be 6 milestones as a minimum.
- If your project is going to last 2 months and you perform a progress assessment every week, you might want to set a milestone for every two weeks, bur no less than every 3 weeks.
A contractual milestone or a financial milestone is not merely a “point in time” or a mark on the Gantt.
It has practical meaning – on the one hand someone else needs to receive the work package and continue with it, and financial significance – all of the payment factors are involved in it.
Defining many milestones is going to involve a lot of paperwork, tests, inspections and approvals by all the parties involved.
Defining too few milestones in a project is going to hamper the ability to control and influence the rate and manner of the project’s progress.
Artfulness, did I mention that already…?
the project successfully.
Want to talk to Tal Levanon about it?
If you answered 'yes' - then we have a solution for you!
ARE MILESTONES LINKED TO SUCCESSORS (SEQUENTIAL TASKS)?
One of the fundamental rules in building schedules is:
There has got to be a successor task for every task in the project, exception of the “end” task.
Since milestones are mostly to do with the completion of work packages, and since contractual milestones are perceived to be customer control points, such that they are ostensibly not part of the project, in many cases those carrying out the project do not link successor tasks to contractual milestones.
Non-definition of successor tasks after the contractual milestones may be a mistake, and this is why:
If the executable tasks linked to that milestone do not have successor executable tasks, this means that all the paths leading up to that milestone are terminated and there is no executive continuity in the project.
Let’s explain this in an example in a new miniproject where there are 2 contractual milestones. The milestones do not have successor tasks . To all appearances, all of the executable tasks are linked and at a glance it seems there’s no problem with this schedule, with the exception of the contractual milestones and even in them, the last one, which represents the completion of the project does not have to be linked to successor tasks (since it’s the last one…).
Let’s do a quick check.
If we delete the predecessors of the milestones – the milestone’s successor tasks will also be deleted from the executable tasks . In this case, if all the executable tasks are linked to other executable tasks – then indeed there is no problem, but if we find that there are tasks that have no successor tasks – and they are not the last tasks in the project  – then there is a problem:
In our miniproject we can see that executable task C has no successor executable task – and this is a mistake in the schedule.
Conclusion: all of the milestones have to be linked to executable tasks – that way we ensure there is no disconnect in any of the project paths.
MILESTONES, HCP AND THE HCP-GO – WHAT’S THE CONNECTION?
The HCP-Go SaaS (software as a service) checks several types of potential malfunctions in the schedule. There are two milestone-related malfunctions:
(1) Tasks which are not linked to successor tasks – as we explained in the previous section, all milestones, except for the final milestone (which represents project end) have to be linked to successor tasks. The HCP-Go finds all of the tasks which do not have successor tasks, enabling the problem to be fixed easily.
(2) Tasks with preliminary successor tasks – in the process of building the schedules, we exercise flexibility – a highly desirable thing in itself. When we ask “What is the preceding task to this task?” Sometimes, we will find ourselves answering, “We have to complete it by the time of the milestone, so we will insert the link FF (finish to finish) with the milestone”.
Why? Because what we have actually done, is to think from the end to the beginning, while the timeline moves only in one direction – from beginning to end. So, flexibility – is great, but preparing a Gantt has to be from beginning to end – since that’s the only way can we can carry out the project.
Let’s explain in an example on a section of the miniproject. Tasks A, B and C precede the engineering milestone. For task D we have specified that it has to be completed by the milestone and therefore we have defined the FF link, where the milestone precedes task D. In this situation, the path is: A → B → C → milestone → D.
This is wrong – and the HCP-Go detects and flags issues like these.
A possible fix for the problem would consist of two moves –
(1) Fixing the link between task D and the milestone – task D precedes the milestone and not vice versa.
(2) Finding the predecessor of task D – this may be task A or B or C – through any logical link according to the actual execution, and perhaps none of these, and then a date constraint has to be added to the beginning. The guideline is – the reality definitions in the project. For example –
TO SUM IT UP –
- A milestone is a very important task in the schedule. It is assigned a ‘0’ duration. Sometimes it signifies a start but mostly it signifies an end of tasks in a project and it has a special symbol in the Gantt.
- There are three kinds of milestones – contractual, financial and engineering – as a dependency of time constraints, budgetary constraints and scope definitions.
- The milestone definitions have two main purposes: to control progress and to steer toward the project issues which are important to the customer.
- There are important rules of thumb in defining milestones – the number of milestones in the and their frequency.
- All milestones have to be linked to subsequent milestones (except the last one, which symbolizes the end of the project).
- There are two common milestone-related malfunctions in schedules, which the HCP-Go can detect and flag, plus indicate what corrective action we should take.