I recently wrote a post asking if the RAG status of your project reflects delivery expectation as you approach go-live. [Is your project’s RAG status an accurate reflection delivery expectation] We’ve all seen the projects that are Red week after week but then miraculously deliver on schedule. Likewise, we’ve all seen the opposite where everything is Green until the go-live date is missed.
I shared that post across several LinkedIn groups and had some really interesting comments. A number of these focused on the over-simplification that a RAG status represents. Surely our business stakeholders are sufficiently sophisticated and intelligent that they require more detailed information on their projects and programmes than a simple traffic light system? A common suggestion was the need for a project or programme dashboard. But what should appear on such a dashboard?
Before I answer that question, I want to discuss how to use RAG status reporting effectively. A number of the comments challenging my earlier post focussed on looking at the RAG status as the reporting mechanism as opposed to the sign-post it should actually be used for.
If an organisation has an established and effective PMO with responsibility for assurance and challenge, then the RAG status becomes a sign post for where stakeholders need to focus their attention. Green projects are truly on track and only require planned attention such as checkpoint or stage gate sign-offs etc. Those at amber need some attention to ensure they stay on track and those at Red require immediate remedial action.
But for the RAG status to be a true representation it needs to be properly informed and assessed against a whole range of criteria. And this is where the dashboard comes in. Simple RAG assessments look at some set criteria such as milestones missed or at risk, forecast spend against business case, forecast benefits against business case, resources in place etc etc.
These are not robust indicators. For example, one multi-million pound programme I ran the PMO for would simply raise a change request to move milestone dates to ‘bring them back into governance’ or to reduce the benefits for a particular project. These projects would then ‘Return to Green’. Did this make the overall programme Green? Absolutely not! The programme had a benefits ‘gap’ and had to identify new projects to deliver the missing benefits. Until projects were identified to fill the gap, the programme was at best Amber and more realistically Red, especially as the programme completion deadline loomed ever closer.
So what other indicators like the benefits gap I mentioned above could be used to inform the RAG status of a project or programme? Here are a few suggestions:
Volume of Red/Amber milestones
Individual milestones can be critically important. But the volume of Red/Amber milestones either in absolute terms or in percentage of total terms can be an excellent indicator of the quality of the underlying plan. They can also indicate a growing bow wave of activity heading towards a deadline that will become ever more difficult to deliver. Beware the situation I described above where change requests are used to return milestones to Green. That can hide the bow wave in a sea of Green.
Too few risks or issues
Projects are inherently risky and always face issues at some stage. beware the project that has too few of either. How do you know if there are too few? Use statistics from other projects as a guide or ask for support from your PMO. As you become more experienced you will get a feel for this.
Risk and issue resolution dates slipping
I always track how many risks and issues have had their resolution date slipped and how many times. If either metric starts to rise, this is a sign of potential problems with the project.
Project spend against progress
It’s very easy to maintain your forecast spend as being in line with the business case when it either isn’t or you don’t have enough controls to tell you whether it is or isn’t. One such control or indicator is to compare the proportion of budget spent against where the project is in terms of actual deliverables. Have you spent 50% of the budget but only delivered 33% of the project? This is where the disciplines of earned value come in to play in engineering and construction projects. However, these techniques are rarely used, if ever, in corporate change and in-house systems delivery,
Resource turnover or attrition
Some level of resource turnover is to be expected and even built in to the plan. The skills and profile of resources required for a project will change during the lifecycle. But higher than planned turnover or attrition is a sign that all is not well with the project. It may not be the project itself – there could be a lot of external market demand for your key resources, but it still bodes badly for delivery of your project.
All projects need a level of business involvement in such areas as requirements definition, process re-design, testing etc. But business demands often mean projects don’t get the full level of commitment they need, especially where the business input is in marginal time rather than through dedicated resources. Measuring the actual business involvement against the planned or requested involvement is another measure of whether a project is on track or heading fro problems.
These are a few of the typical key performance indicators I include in my project and programme dashboards. All are used to inform the RAG status of the project/programme and to indicate where stakeholder attention is required.
What KPIs do you include on your dashboard?