Project planning can be a difficult process, especially in the early stages when the analysis and business requirements have not been completed. Therefore, it is little surprise that most project managers are happy, even relieved, when they have a first draft plan.
However, in many cases what was captured as the original name / description of the milestone will often remain the same for the lifecycle of the project. While this is probably factually correct, as most milestones will be captured by the project teams, it is not unusual for the milestone name to be captured in “project speak” as opposed to something that will resonate with the sponsor and senior management.
This is a problem as it may lead the sponsor and senior management to be confused or, even worse, make incorrect assumptions on just what will be delivered. This will lead to a very big expectation gap later in the project, typically at the worse time when emotions are running high.
This post aims to provide some ideas on the steps you can take to avoid this situation.
The levelling of project milestones is important. It is fair to say that for most if not all projects, some milestones are more important than others. These are the ones that represent that something significant has been delivered.
The milestone levelling process allows for the project manager to identify these milestones and then tag them. The reason for this is that it allows for the significant milestones to be filtered and reported quickly.
This is good for the project manager to keep an eye on the status of the important milestones. It also allows the project team to prepare reports that provide the important information. Most sponsors will not thank being presented with pages of A3 Gantt charts and have to try and spot important milestones among 100’s of others! It is the project manager’s duty to distil the information so that it can be quickly and easily consumed by the reader.
When there are multiple projects or workstreams in a programme, it is important that they all use the same criteria for levelling milestones. This is where a good PMO will publish guidelines to help ensure consistency. This means that the sponsor will have confidence that they are comparing milestones on a like for like basis.
The picture below is an extract from the PMO Handbook within the PMO Template Framework and shows how milestones can be levelled.
Milestone Story Telling
When you are living and breathing the day to day management of a project, it is very easy to forget that the project is not central to everyone else in your organisation. So it is important to remember that not everyone will have the same level of knowledge and will not really know what is going on (even if you have told them and reported it).
It is for this reason that you need to have a carefully crafted story of the journey that you can quickly tell. This will help ensure that others do start to remember, especially the sponsor. Constantly repeating the same or similar story of how you intend to get from the project start point to the successful completion will help instil confidence that you know what you are doing and have a plan.
Having the clear concise story is part of the solution. It is really important that your milestone report tells the same story. This means that you will be able to use your high level milestone plan to walk the sponsor and senior management through the journey.
This is powerful as the fact that the milestones are printed on paper will make them more real to the audience. It will naturally lead to your story being seen as credible.
Tip: using the levelling capture the important milestones and then practice your story. How you do this is a personal choice. However, sometimes it is good to commit thoughts to paper so that you can then review and refine. However, do not make it so it sounds like a rehearsed speech and definitely do not read your story word for word from a typed note in front of the sponsor. This will spoil the illusion of confidence that you know or believe how you are going to get from start to finish.
This is the other important ingredient to being able to tell the story.
As mentioned earlier, many milestones will be created by project teams and invariably will be written in “project speak”. This is where technical project jargon has been used to name the milestone i.e. Oracle DB Upgrade Complete, Sprint 4 Complete, GUI Build V1.5 Complete.
This is OK for those close to the project team. However, very different to a senior sponsor who has a Business division to manage and has 100’s of active projects.
On a similar note, if you was telling a story in step 2, would you be using language like “GUI Build V1.5 Complete”? I imagine you would not (if you would, you probably need to work on the story)!
One of the most effective techniques I have used over the many years executing and overseeing change is to use “outcomes”. The principle is simple, a project is typically initiated by an organisation to achieve an outcome. It could be increase revenue by developing a new service or saving money by making a process more efficient.
It naturally follows that time should be spent ensuring that the significant milestones follow the same approach of using outcomes in the naming convention.
“Implement Web App e-commerce” becomes “Implement online store”. Straight away the sponsor knows that the online store has been implemented meaning that orders can be taken 24 hours a day! Far more powerful.
Using outcome based milestones will reinforce the story and the sponsor should know exactly what has been achieved avoiding the dreaded expectation gap.
FREE Milestone Outcomes Template
To help focus on capturing outcomes and instil discipline, you can use the link below to download a template that can be used to capture and translate milestones into outcome milestones.
Investing time in building a solid plan is important. Then by levelling, creating and telling the story using outcome based milestones should mean you have a happy sponsor. There is also a side
Milestone Outcomes Presentation