Project Metrics ReportThe last post covered why it was important to define, track and report project outcomes NOT just the performance of the project i.e. progress against milestones, budget, etc.  This post covers the steps to defining a process to track project metrics.

What are you tracking?

This may be a strange question as the answer is “Outcome metrics”.  While this is correct, when you dig deeper, you will find that the expectation of stakeholders and management will be different.  For example, do they want to see changes in the BAU (business as usual metrics) to demonstrate progress.  However, others may want to see metrics that demonstrate the change has been successfully implemented i.e. metrics that show a process has been implemented in all required locations.  You must help the stakeholders to be clear otherwise you will not track and present the information they wish to see.

Project Metrics

These are the mechanical metrics relating to a project i.e. milestones delivered, costs, resources, etc.

Business As Usual Metrics

Often known as BAU metrics.  These are metrics used to manage and organisation and would be used even if there was not a project.  For example, measuring the time a process takes to complete, such as 10 minutes.

Change Metrics

These are more interesting and sit between Project and BAU metrics.  Their purpose is to demonstrate progress against the change.  For example, the project metric maybe a milestone to deliver software, the BAU metric may be that processing time reduces from 10 minutes to 5 minutes.  The change metric will be measuring that the new software has been implemented and is being used i.e. the software is being implemented in 20 countries, you would track against 20.

Initial Metric Definition

The process must allow for the metrics to be defined early in the process.  A very good point is as part of the development of the business case.  As case is developed, it is logical that the expected benefits should be captured together with what will be measured to show progress that the benefits have been achieved.

Another good reason for including in the business case is that, the sponsor and PMO can insist that suitable metrics are included before the business case is signed-off.  This means that the metrics must be clearly thought through before sign-off.  This includes defining what targets need to be achieved to declare success.  For example, 100% completion may be unachievable.  However, 95% will achieve the objective.

As part of this, ensure that the metric description and rationale is clear.  This will allow for the proposed metric to be evaluated and ensure that all recipients of the data understand what the metric is, why it is important and how it demonstrates progress.

The PMO should ensure that the business case templates has a clear section for the capture of benefits, ideally in a standard table format.  This will allow the benefits from the signed-off case to be easily captured and transferred to the benefits tracking process.

Benefits Register

Ideally the project should have a benefits register to track and monitor progress.  Likewise, the PMO should have a central register.  The reason for this is it is likely that many of the benefits will not be achieved for months or even years after the project has been completed.  The PMO can be the custodian to make sure that they are realised.

As there may be a long period before benefits are achieved, this is why having a way to measure progress delivering the change is important.  In theory, if the correct change metrics are chosen, these should complete at the end of the project i.e. change matric to implement process in all locations complete, benefits of the change process not due until 6 months after project completion.

Metric Reporting Cycle

The project should be reporting progress on a regular basis (usually weekly, fortnightly or monthly).  The metrics and benefits should be reported as part of the process.  However, you need to consider the value of reporting metrics and benefits too frequently.  For example, reporting may be weekly.  However, due to the amount of effort and timing of finance reports, etc, it may make more sense to report metrics and benefits monthly (only report so that it adds value).

It is also important to encourage the project manager to report using the language of “outcomes”.  Mechanical reporting would be reporting that a milestone is complete.  However, the sponsor and stakeholders want to understand “what this means for the organisation”.  Helping project managers to think and report with this mind set will result in less challenge and happier stakeholders.

Metric Dashboard

Sponsors and stakeholders will want to see a concise summary of the metrics to monitor progress.  Designing and easy to understand dashboard to include in SteerCo’s / management meetings will allow the information to be easily shared.

The dashboard should contain all of the agreed metrics.  It is worth pausing on this point.  When the metrics have been defined with clear rationale, make sure that you review them with the stakeholders to ensure they are fit for purpose.  This will reduce the risk that the metrics are not appropriate, meaning you do not have to spend more time defining new metrics and dashboard.

Make sure the dashboard includes:

  • Current metric value
  • Total metric value (i.e. what represents 100% completeness)
  • Target metric value
  • Previous reporting period metric value

Having these will allow stakeholders to quickly understand progress against target and improvement since last period.  You may also wish to add a time element if appropriate.

Review

Ensure that there is the appropriate review steps both at the project and dashboard level.  It can be very damaging to report poor data that is easily challenged and discredited.  If this happens it will be very hard to gain credibility again.

Ideally the metrics for each project should be presented at their appropriate governance forums and signed-off before being consolidated.  This means that senior stakeholders should have probed and tested the metrics and are happy they are correct.

Summary

Implemented a structured approach to benefits, metrics and outcomes should result in more projects delivering value.  Make sure the process is clear and communicated to all participants:

  • Clear definition of different metric types
  • Process for the initial definition of metrics
  • Benefits register to baseline and monitor realisation
  • Reporting cycle to report progress
  • Intuitive dashboard with agreed metrics to report progress
  • Robust review process to ensure quality data

Following these principles will allow for a strong process for capturing and reporting outcomes to be implemented, that reports the data required by the stakeholders.