Dmitry Trus | Project RAG Status Indicators How Much Of Them Do We Need

Project RAG Status Indicators How Much Of Them Do We Need

February 27, 2024

Before I begin this small article, I would like to say thank you to the creators of generative AI, particularly DALL-E 3, who visualizes all the horrors and nightmares of the project manager with ease. Let’s start with this illustration 🙂

Or probably you have something like this??

If you are a Project Manager and do not have RAG statuses in your project dashboard yet, that may be also the case. No indicators -> no directions -> no destination???

An analogy comes to my mind. Imagine you are an airplane pilot and have no altimeter, speedometer, or thousands of other indicators that show the health of your flight. You have only a compass and the approximate direction where to fly, and mountains below the wings of your plane. But how far are they, are they dangerous or not; moreover, should you undertake a corrective action right now, even if there are no evident signs that something may go wrong??

I used to be that pilot many times. I consumed existing capabilities of project management tools like Jira, and even used my own custom tool to close the gap between planned and actual team performance, but I always felt that it was not enough to make sure the project was totally under control. In this article, I want to summarize everything about the subject.

First, let’s define how many RAG status indicators you should have. Obviously, two. The first one, with just one “traffic light”, is what your top management expects to see in your status reports. The second, with lots of dimensions, is what you have to work with actually.

To not reinvent the wheel, first, I would like to refer to that article. The picture below, borrowed from that, is perfect in its brevity and explanation of what RAG is.

How many individual lights you should have? Another article suggests the following:

Cost
Progress
Risks
Issues
Stakeholders
Team
Quality
Scope
Value

But how to measure if a 4% increase in the budget against the baseline is a green or amber? What if there is a project risk, known by some of the team members, but not mentioned in the risk registry?? How to map the current quality from zillions of tickets to just a single color??? Obviously, there must be a tool to help the project manager, which works to the project management policies adopted by the organization. If you have already it, e.g. using PM3, then you are lucky, you have nothing to worry about, and can stop reading this article!:) Or, if you are working in a mature Software House like Epam, you may have even more swimlanes and about 120 project metrics contributed!!.

An opposite situation that happens quite often is when you have no policies and tools, but only the raw issue tracker software and your curious mind. Further, I’d like to focus on this scenario and define the most important criteria and thresholds, now in our own table, and in a practically applicable format.

Area	Green Criteria	Amber Criteria	Red Criteria
Cost	CPI between 1 – 1.1 (project under budget or slightly over)	CPI between 0.9 – 1 (over budget, but manageable)	CPI less than 0.9 (significantly over budget)
	Budget variance less than +5%	Budget variance between +5% and +15%	Budget variance greater than +15%
	Estimated at Completion (EAC) within the budgeted range	EAC exceeding budget by 5-10%	EAC exceeding budget by more than 10%
Progress	The SPI value is greater than or equal to 1	The SPI value is between 0.9 and 1 (the project is slightly behind the planned schedule)	The SPI value is less than 0.9 (the project is significantly behind the planned schedule)
	Schedule variance less than 5% behind	Schedule variance between 5-15% behind	Schedule variance more than 15% behind
	Percentage of milestones completed on time > 90%	Percentage of milestones completed on time between 75-90%	Percentage of milestones completed on time < 75%
Risks	Top 5 risks have a combined risk score < 10	Top 5 risks have a combined risk score between 10-20	Top 5 risks have a combined risk score > 20
	Probability of any risk occurring < 30%	At least one risk with probability between 30-60%	At least one risk has probability > 60%
	No risks with high and medium impact classification	One or two risks with medium impact classification, no risks with high impact	One or more risks with high impact classification, or more than two with medium impact
Issues		To be defined based on project details, no common approach is possible; lack of issues e.g. may mean a bad team performance. The acceptable range of open issues in project management depends on the size, scope, complexity, and risk level of the project. There is no universal formula or rule to determine the acceptable range, but it should be based on the project plan, the risk register, the stakeholder expectations, and the historical data from similar projects. The acceptable range should also be agreed upon by the project team, the sponsor, and the client before the project starts, and reviewed periodically during the project execution.
Stakeholders	High stakeholder satisfaction survey score (e.g., >4 out of 5)	Moderate satisfaction score (e.g., 3 out of 5)	Low satisfaction score (e.g., < 3 out of 5)
	No major stakeholder changes	One or two low-level stakeholder changes	Changes in key stakeholders
Team	Low turnover rate (<5%)	Moderate turnover rate (5-10%)	High turnover rate (>10%)
	High team morale (surveys or assessments)	Moderate team morale with some concerns	Low team morale or evidence of conflict
	No deviations from productivity goals set (see details below)*	Minor deviations from productivity goals*	Significant deviations from productivity goals*
Quality	All quality control checks passed	Minor deviations on quality control checks	Major deviations or failures on quality control checks
	High customer satisfaction on quality (> 4 out of 5)	Moderate customer satisfaction on quality (3 out of 5)	Low customer satisfaction on quality (< 3 out of 5)
	The quality of estimates is high**	The quality of estimates is medium**	The quality of estimates is low**
Scope	Change requests with minimal cost and schedule impact	Change requests with moderate cost and schedule impact	Change requests with significant cost and schedule impact
	Less than 2 scope changes or change requests***	Between 2-4 scope changes or change requests***	More than 4 scope changes or change requests***
Value	Value metrics met or exceeded****	Value metrics slightly under targets but achievable with action****	Value metrics significantly under targets or not achievable****

Comments:

* there are lots of specific metrics and KPIs associated with software development, that must be measured and monitored against their previous values or industry best practices. The full list will take another article, here are just some of them:

Metric	Definition	Green	Amber	Red
Cycle time	The time it takes to complete a specific task from start to finish	< 1 day	1-3 days	> 3 days
Velocity	The amount of work completed by a team in a given time period	Consistent or increasing	Variable or decreasing, but no more than 10% against the previous period	Decreased to more than 10% against the previous period
Cumulative flow	The visualization of the work in progress, completed, and in the backlog	Smooth and balanced	Some fluctuations and bottlenecks	Spikes and gaps
Queue time	The time a task spends waiting to be processed	< 10% of cycle time	10-30% of cycle time	> 30% of cycle time

** see https://ddpm.pro/ how to measure and improve this metric

*** even if numbers are given, they must be aligned to the project specific.

**** value metrics are very dependent on the project. The specific value metrics vary depending on the nature of the business/product. Here are some common examples:

Area	Metrics
SaaS (Software as a Service)	Number of active usersNumber of transactions processedAmount of data storedTime saved on tasks due to the softwareIncreased revenue generated (if the software is revenue-focused)
Ecommerce	Number of salesRevenue generatedAverage order sizeCustomer lifetime value
Service-based Business	Number of clients servedHours saved for clientsRevenue increase for clients (if applicable)

Now, when we all are set with the metrics to gather to form our indicators, let’s put our attention to more non-technical aspects. The “Green” status can not tell the truth. Citing the article, green light can have three reasons:

Project is straightforward and is being well managed by the project manager. Nothing unforeseen has occurred;
Culture of the organisation is not to accept any RAG status except green;
Project manager is being less than honest and is covering up any areas of concern for the project.

Pay attention to reason 2), and do something with your organization, or your position, if this is true. If reason 3) is about you, and if you are reading this article, you still have a chance to improve!!

Sources of inspiration for this article: