Your project is on schedule and within budget. Which RAG status colour applies, and how do you open the weekly status email?
GREEN + formal status statement is correct. RAG status emails should:
State the RAG colour explicitly — "Status: Green" — so stakeholders can scan quickly without reading the full update
Use formal language — "progressing on schedule," "no impediments to report" rather than "all good" or "fine"
"No issues" (Option A) and "All good!" (Option D) are too casual for a stakeholder status report
Option C (Amber) would be incorrect if no issues exist — RAG should reflect reality, not caution
2 / 5
A dependency has delayed your API integration by 3 days. The project can still hit its final deadline if nothing else slips. What RAG status is appropriate?
AMBER is correct here. RAG definitions in project management:
GREEN — on track, no known risks
AMBER — at risk; a problem exists that could escalate, even if the end date is currently safe
RED — the end date or scope is already breached or will be unless action is taken now
A 3-day delay absorbed by buffer is still a risk indicator — it means buffer has been consumed and there is less tolerance for further slippage. AMBER triggers stakeholder awareness without panic. Hiding it with GREEN misleads management.
3 / 5
Which weekly status email structure is most useful for stakeholders who read updates on mobile in under 2 minutes?
The structured bullet format (Status + This week + Next week + Risks) is optimal for fast reading. Why this structure works:
RAG status first — stakeholders know immediately if action is needed before reading further
"This week" and "Next week" — show progress and predictability in parallel
Risks section — even "None" is informative; its presence means you actively checked
Long narrative emails (Option A) require effort to extract key facts
Attachments (Option C) add friction — many stakeholders will not open them
Slack (Option D) lacks the formal record that email provides
4 / 5
Your status is RED — the release date will slip by 2 weeks due to a critical bug found in QA. Which email opening is most appropriate?
Option B is correct. A RED status email opening must include:
The status colour explicitly — "Status: RED" in the first line
The revised date — "revised from 15 June to 29 June" — concrete, not vague
The cause — "critical defect identified in QA on 22 May" — specific and factual
Stakeholders receiving RED emails need to understand impact immediately. Options A and C are emotional but not informative. Option D gives the problem but not the impact (by how much? what is the new date?). In RED updates: state the fact, the impact, and the cause — in that order.
5 / 5
Which closing line best fits a weekly project status email sent to senior stakeholders?
Option C is most effective for senior stakeholders. It includes:
Next update date — "Friday 30 May" — removes ambiguity about cadence
Actionable request — "reply by Wednesday 28 May if you wish to raise agenda items" — gives stakeholders a clear path to influence
Deadline for input — prevents last-minute additions to steering agendas
Option A is passive — senior stakeholders rarely email back with questions; they expect the update to be complete. Option B adds friction with an attachment. Option D ("keep you posted") is vague and common to the point of meaninglessness in professional communication.