A couple weeks ago I was tasked by boss to look at our RAG report template and come up with a better one, simply because I said I didn’t like the one we currently had.
For the uninitiated a RAG Report is a Red (R), Amber (A), Green (G) Report. A project report that is issued with regular frequency to all stakeholders, internal / external or a mix depending on a project. With the primary purpose being to educate and inform stakeholders on the project status, whether it is Red, Amber or Green against it’s goals and progress. The secondary purpose maybe to seek additional support from the executive sponsor of the project, by articulating the issue and required response in the report – this of course depends on the organisation and it’s approach to escalations.
RAG report is sometimes known by other names, for example i’ve heard other organizations call them Highlight report or FLASH reports. For the purposes of this Blog, we’ll call them RAG reports.
I’ve been thinking, what makes a good RAG report? What inputs, contributions, formats, level of detail is required.
Obviously whether the project is Green, Amber or Red (RAG Status), should be immediately obvious to any reader. That’s given. RAG status should be one of the first items on the report, near the top. So that if the reader has many reports to read they can focus on the Amber and Red projects, ignoring the Greens – as each Green project will simply state “on track”. From a formatting point of view there should be a colour indicator that reflects the RAG, allowing the reader to quickly focus or move on as required.
Some argue that for each area of the project (Schedule, Finance, Risk, Resource, Security, Budget etc) should have it’s own RAG status. I feel this confuses things and adds very little value and is covering by the RAG status and description (below).
Alongside the RAG Status there should be what I would call a RAG description – Why is the Project Red, Amber or Green. If it’s Red or Amber, what are the corrective actions to move the project back to Green, or what assistance from the executive team do you require. A paragraph or two is sufficient to cover this section.
Project milestones should also be listed within the RAG report, with the baseline (original forecast date) and current planned (or achieved) dates. To demonstrate where the project is against original plan. If you have a project budget this should also be listed, with baseline, actual and expected cost at completion.
OK so far we’ve listed what the project is doing, it’s status, it’s progress against original plan and budget. The RAG report should also flag any Amber or Red risks, again it’s not worth listing green risks as these either should not materialise or have an impact on the project.
These Risks should be articulated in a Risk Statement (IF, THEN, RESULTING IN), with impacts, time of impact and response action (Mitigate, Accept, Fallback etc). With a short summary of the risk response actions and who owns them. If you have a lot of Red and Amber risks, i’d limit these to the top ten risks by impact to the project or by your own scoring mechanism.
Alongside and before risk, any issues should also be listed. All issues should be listed, again unless you have a lot and in that case I suggest you keep it to the top ten by impact or score.
Key project dependencies could also be listed, but I list them as milestones within the project. As they should be milestones anyway, listed both milestones and Key dependencies seems like duplication.
In terms of format, it’s a personal choice. I like spreadsheets as you can customise the layout easily and also save them as PDFs, before distribution. I’ve also seen PowerPoint and Word RAG reports. The choice is yours and whatever suits you and your organisation.
In summary the RAG report should be short and snappy, that someone outside the project team can pick up and understand the status of the project, and whether they need to do something of about it. If you can stick to one page then great, if not, put the summary on the first page and the detail on the second, for those who are interested.
iamitpm 