What is RAG status in project management?

RAG status is typically shown on a RAG status dashboard, in Jira, other project management platforms, and reports to provide stakeholders with a quick, intuitive overview of a project's performance. It helps teams identify problems early and take corrective action.

RAG status tolerance defines the thresholds that determine when a project's status changes between Red, Amber, and Green. These thresholds are established during project planning and reflect acceptable variations in key performance areas such as budget, timeline, and scope.

Here are some RAG status examples:

• A schedule delay of less than 5% might remain Green.
• A delay of 5-10% could trigger Amber.
• Anything over 10% might turn Red.

Tolerance levels are typically calculated by analyzing project risks, aligning with organizational priorities, and considering stakeholder expectations. Setting clear tolerances ensures consistent and objective status reporting across all projects. Here are 5 best practices to adhere to:

Check that thresholds reflect the project's critical success factors, such as deadlines or budget constraints. For example, a high-priority deliverable may require stricter tolerances than less critical tasks.

Collaborate with key stakeholders to understand their expectations for acceptable risk levels. This avoids confusion or misalignment later in the project lifecycle.

Review data from similar projects to set realistic thresholds. For example, if past projects often experienced minor cost overruns, a 10% budget tolerance might be reasonable.

Adjust tolerances based on the complexity of the project. Simpler projects may have tighter thresholds, while more complex initiatives might require greater flexibility.

RAG tolerances should be flexible to account for changes in a project's context, such as different risks or stakeholder priorities.

A reliable RAG status rests on live delivery data, not opinion. The most useful signals are schedule progress against the plan, budget and cost against what's been delivered, open blockers and how long they've been stuck, and team workload.

When a status is backed by those, the color means something specific and consistent, and when it changes, you can see which signal moved it. A RAG status set by feel, without that data underneath, tends to drift into "watermelon" reporting: green on the surface, red inside.

Teams that implement RAG status in project management can reap several practical benefits to enhance project oversight and decision-making:

• Improved visibility: An easily viewed summary of project health that enables stakeholders and team members to understand the status without detailed reports.
• Enhanced communication: The simple color-coded system facilitates clear and consistent communication across diverse teams, including non-technical stakeholders.
• Proactive issue resolution: Highlighting potential risks (Amber) and critical problems (Red) allows teams to take corrective action before issues escalate further.
• Increased accountability: Assigning specific RAG statuses encourages team members to own their roles and resolve challenges related to their tasks.
• Streamlined reporting: a RAG status dashboard saves time with simplified progress updates, in place of manual meetings and reports.

Enji provides teams with the data they need to successfully observe and manage a project's progress without micromanagement and unnecessary communication. Managers and other stakeholders can use Enji to calculate accurate RAG tolerances thanks to these features:

• Project Margins: See historical data for similar projects and get up-to-date information on current project profitability.
• Code Metrics: Know the minimum and maximum available effort in your development team to arrange proper RAG signals.
• PM Agent: Ask your AI assistant for quick updates based on your RAG parameters without extra meetings. Copilot also provides insights based on your data to create accurate plans.

A RAG status is only as trustworthy as the data behind it. Enji's PM Agent reads the live signals that actually move a project's status, so a color reflects what's really happening rather than someone's guess. Three it watches closely:

• Blockers: work that's stuck and what it's waiting on so a stall shows up as caution before it derails the timeline.
• Schedule drift: how far the current pace is from the plan, so a slip turns Amber while there's still time to correct it.
• Workload pressure: where the team is overloaded, so capacity strain is visible before it forces a Red.
  Because PM Agent reads these continuously, a status change comes with its cause attached; you see not just that a project went Amber, but why, and what to do about it.