The last couple of posts focused on how the correct use of project milestones can help tell the story of the project. This has the added benefit that the sponsor and stakeholders will have confidence that the correct progress is being made. Take a look at Project Milestones: Using Outcomes to Tell the Story and Guide to Project Milestone Levelling.
Having clearly defined and named milestones is great. However, like with any data, it is only valuable if it is kept up to date. Therefore, it is very important that all the hard work is not lost and that the plan is kept up to date. A simple method to solve this challenge is to establish a Project Milestone Reporting Routine for the regular update of the plan.
Plan Update Schedule
The first step is to define a schedule for when the plan should be updated. While a project plan should be updated on an ongoing basis. It is not very efficient to make updates each day. Therefore, it is a good idea to set a point in time when the plan should be updated each week. For example, all plan updates to be done by 12:00pm each Thursday.
Setting this as a criteria will ensure that all plans are updated on a weekly basis keeping them up to date. While the first few cycles will have variable quality (nice way of saying the project teams will probably forget), when they realise the plans are being monitored, over time they will get into a routine.
This also ensures that where there are multiple projects, each with their own plan, all of the reporting will be at the same point in time. This helps with data consolidation and means senior management can clearly see how each project is performing at a point in time.
Milestone Reporting Criteria
To help the standardisation of data and subsequent reporting, it is important that all milestones are updated using the same criteria. This will ensure that when a milestone is reported Red, everyone is clear why.
It also avoids the situation where 2 different projects have Level 1 milestones, both are 35 days late but project 1 is reporting Red milestone while project 2 is reporting an Amber milestone. This is inconsistent and will cause resentment in project 1 as they will end up having a higher level of scrutiny as they appear to be doing worse than project 2.
It is very easy to set standard milestone reporting criteria.
For example, a very simple RAG criteria for milestones maybe:
- Green: Milestone on track
- Amber: Milestone at risk
- Red: Milestone missed
- White: Milestone not agreed / baselined
- Blue: Milestone complete
Depending on the duration of the project or programme, it is advisable to set time parameters to the RAG criteria.
For example:
- Amber: milestone at risk of being delayed up to 30 days
- Red: milestone at risk of being delayed over 30 days
Milestone Reporting Review
Before the milestone report is submitted, the project manager must review to ensure it is correct. This helps ensure the correct status is reported. It also acts as a reminder to the project manager and will usually lead to them reflecting on what has been achieved, where are the challenges and what needs to be done next.
After the plan / milestones have been submitted, the PMO should then review for consistency. If there are inconsistencies, they should be discussed with the project team with the objective of making the report factually correct.
Produce Report
When the data has been reviewed and confirmed as correct, the final report can be produced. This will then be used to help report progress and status to senior management.
Tip: If the data identifies challenges, it is a good idea to have more detailed information available so you are ready to answer questions. Even better to cover challenges within the commentary of any status reports. It shows you are being open and transparent.
Summary
Following the steps above will help ensure that project plans are kept up to date. This will allow there to be confidence in the data and the subsequent reports.
Remember, while project teams may push back saying this is admin, it is the responsibility of all good, competent project managers to maintain a robust project plan. So you are not asking them to do anything more than what they should be doing.
