RAG Status Criteria for Client Implementation Projects

Red, amber and green status criteria for a client implementation should rate schedule, budget or hours, scope, client-side dependencies and go-live readiness separately. Each area is measured against thresholds you and the client sponsor agree at kickoff. Green means within agreed tolerance, amber means recoverable with a named action, and red means the sponsor must decide or help. A written roll-up rule then turns those ratings into a single overall status, so the project can't show green while one area is red.

What should red, amber and green mean on a client implementation?

On a client implementation, red, amber and green should describe what the sponsor needs to do, not how the team feels. Green asks nothing of the sponsor. Amber tells the sponsor about a risk you are already recovering. Red asks the sponsor for a decision, approval or help, by a stated date.

Use these definitions word for word in your status report:

• Green: Within the agreed tolerance. No action needed from the sponsor.
• Amber: Outside tolerance or likely to be, with a recovery action that has an owner and a date. The sponsor is informed and may be asked to watch a dependency.
• Red: Outside tolerance with no recovery the delivery team can complete alone. The sponsor is asked for a decision, approval or help by a named date.

This follows the common definitions: Designveloper describes green as within agreed tolerances, amber as recoverable with active attention, and red as needing intervention or escalation. The implementation version adds who acts, because on a client project the person who can fix a red is often on the client side.

Which areas should you rate separately?

A client implementation should be rated on schedule, budget or hours, scope, client-side dependencies and go-live readiness, each on its own line. Rating each area separately stops a strong area from hiding a weak one, and it shows the sponsor exactly where their help is needed.

Designveloper recommends rating areas such as schedule, budget, scope, quality, risk and readiness separately and then combining them with a written rule, and it names dependencies the project manager doesn't control, such as sandbox access, data ownership and sign-offs. For implementations, give client-side dependencies their own line. Late data, missing access, slow sign-offs and unavailable client staff sit outside the delivery team's control, and they belong to the client to resolve.

Rate these areas:

1. Schedule: milestones and go-live date against the agreed plan.
2. Budget or hours: hours used against hours planned for the work completed.
3. Scope: open change requests and work outside the statement of work.
4. Client-side dependencies: client tasks, approvals, data and access that are due or overdue.
5. Go-live readiness: each module or workstream against its readiness checklist.

What thresholds go in the criteria table?

The thresholds in an implementation criteria table should be numbers you and the client sponsor choose together, written so every value falls into exactly one colour. No published threshold is a standard, so treat any figure you find as a starting point for that conversation, not a rule.

Published thresholds disagree. ClickUp suggests red above 20% over budget, while Eleco's PM3 guide cites a default of red at 10% or more. Pick values that fit your contract and the client's tolerance, then write them down.

Copy this table and fill in the brackets:

Before you share the table, assign every boundary value: decide whether exactly [X]% is green or amber. Then define "recovery action" as an action with an owner, a date and a reason it will work.

What goes on the readiness checklist?

A go-live readiness checklist lists the conditions each module must meet before cutover, each with an owner and a sign-off. Microsoft's guidance on how to prepare to go live covers areas such as the cutover plan, data migration and user training. Agree your list with the sponsor and rate each module against it:

• Cutover plan reviewed and approved by [client sponsor].
• Data migrated and validated by [client data owner].
• Users trained for [module], confirmed by [client team lead].
• Support handover agreed, including who the client contacts after go-live.
• Rollback decision owner named on both sides.
• [Any module-specific item agreed at kickoff].

How should client-caused delays affect the status?

A delay caused by the client should change the status like any other delay, and the report should say who owns the fix. Hiding a client-side slip to keep the relationship comfortable is how a project ends up green on the outside and red underneath.

Apply these rules:

1. Rate the impact, not the blame. If an overdue sponsor approval puts the go-live date at risk, schedule is red regardless of who caused it.
2. Name the owner in the same line: "Red, owner: [client contact name], [client team]."
3. State the specific ask: what you need, from whom, and by when.
4. Record the original due date, so the slip stays visible after the item is done.
5. Re-rate when the item arrives, not when it is promised.

Wording you can use in the report: "Client-side dependencies: Red. [Data extract] was due [date] and has not arrived. Testing cannot start without it, which moves go-live to [date]. Ask: please confirm a delivery date for [data extract] by [date], or approve moving go-live."

How do you roll the ratings up into a single overall status?

The overall status of a client implementation should follow a written roll-up rule agreed at kickoff, not the lead's impression on the day. The simplest reliable rule is that the overall status is never better than the worst area that affects go-live or the agreed statement of work.

A roll-up rule you can adopt as written:

• Any red in schedule, client-side dependencies or go-live readiness makes the project red.
• Any red in budget or scope makes the project red if go-live or the agreed statement of work is at risk, otherwise amber. "At risk" means one of the table's own red triggers applies: go-live forecast to move, hours forecast to exceed the statement of work, or a rejected change that go-live depends on.
• Any amber makes the project at least amber.
• The project is green only when every area is green.

Designveloper gives a similar example, where any unresolved release-critical red makes the project red. Keep the rule short enough that the sponsor can check it against the area ratings in a glance.

How do the criteria change by phase?

Implementation RAG criteria should shift with the phase, because the risk that matters most moves as the project progresses. Early on, client-side dependencies and access dominate. Near cutover, go-live readiness for each module carries the most weight, and after launch, support and adoption issues take over.

Adjust which area you watch most closely:

• Kickoff and discovery: client contacts named, access granted, data owners confirmed.
• Configuration: hours against plan, open change requests, client reviews of each deliverable.
• Testing: client testers available, defects that block sign-off, test sign-off dates.
• Go-live: readiness checklist per module, cutover plan approved, rollback decision owner named.
• Hypercare: open issues by severity, agreed exit criteria for handing over to support.

Write the phase-specific checks into the readiness row of your table, with the sponsor sign-off each one needs.

How do you agree the criteria with the client sponsor at kickoff?

Agree implementation RAG criteria with the client sponsor in the kickoff meeting, before the first status report goes out. The Institute of Project Management recommends that the sponsor and key stakeholders agree criteria before reporting starts. Agreement up front makes a later red a fact you both recognise, not a surprise.

Steps for the kickoff:

1. Send the criteria table with the kickoff agenda, with your proposed values filled in.
2. Walk through each row and ask the sponsor to change any value they disagree with.
3. Confirm the roll-up rule and who on the client side acts on a red.
4. Record the agreed version in the kickoff notes and attach it to every status report.

Script you can use as is:

"Before we start reporting, I'd like us to agree what each colour means, so a red from me is never a surprise to you. Here is what I propose for schedule, hours, scope, your team's tasks and go-live readiness. Where you'd set a threshold differently, tell me now. When something turns red, I'll name what I need from you and by when. Who on your side should receive that, and who covers when they're away?"

What does a filled-in status look like?

A filled-in implementation status shows each area's colour, the evidence behind it, and the next step, followed by the overall status from the roll-up rule. The examples below are illustrative, with placeholders for every name, date and figure.

Example 1: several areas under pressure

Overall: Red (client-side dependency is red and blocks testing)

Decision needed from [sponsor name] by [date]: confirm a delivery date for [data extract], or approve moving go-live to [date].

Example 2: green on the outside, red underneath

This is the case a single gut-feel colour hides. Most areas look healthy, but one overdue sponsor approval sits on the critical path.

Overall: Red (client-side dependency is red and blocks the critical path)

Under the roll-up rule, any red in client-side dependencies makes the project red, even with every other area green. The report says so plainly: "Overall: Red. Four areas are on track, but [client approval] is overdue and blocks [next workstream]. If it arrives by [date], go-live holds. If not, go-live moves to [date]."

When should a status change colour?

A status should change colour only when the evidence changes, not when a plan is promised. The Institute of Project Management sets out a useful rule: red moves to amber only when a recovery action is documented, agreed and under way, and amber moves to green only with evidence the issue is fixed.

Add these checks to your reporting:

• Write the reason for every colour change in the report, with the evidence.
• Keep red if the recovery is agreed but not started.
• Treat a project that is always green with suspicion. Eleco warns that a permanently green status is a warning sign, and Mastt also cautions against all-green reporting.
• Pair every amber and red with a plan back to green, as Eleco recommends.

What should happen when a status turns amber or red?

When an implementation status turns amber or red, send the sponsor a specific ask as soon as it changes, rather than waiting for the next status report. The ask should name the decision, approval or help needed, the options, your recommendation, and the date the answer is needed.

Ask template:

"[Area] is now [colour]. [One sentence of evidence]. To protect [go-live date or milestone], I need [decision, approval or help] from you by [date]. Options: [option A] or [option B]. I recommend [option] because [reason]. If we don't hear back by [date], [what happens next]."

Follow up before the date if there's no reply, and escalate to the backup contact named at kickoff if the date passes. Unblockd supports asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email. Whatever tool you use, record the answer in the next status report and show what the team did after it, so the sponsor sees their response turn into progress.