Matrix Resource Pulled, RAG Reporting That Never Goes Amber
You lead a distributed 14-person team across three time zones delivering a regulatory reporting system against a fixed regulator deadline in five months. Two senior engineers are deadlocked over the reporting data model; one is a long-tenured subject expert who was passed over for your role. Without telling you, the platform functional manager has reassigned the other engineer 60% to a production incident for the last three weeks. Your sponsor is in another country, works by email only, and reads status as on-track because your RAG rule is based on milestone dates, none of which have slipped yet. A junior business analyst has stopped contributing in stand-ups after the subject expert corrected her in front of the team twice. The nine-hour time difference means the only shared hour is 07:00 your time.
1. Sequence your first two weeks. What do you handle first and why, and how do you deal with the reassignment and the deadlock separately?
Read the worked answer
The resource loss and the technical deadlock are different problems and must not be handled in one meeting.
Week one, in order.
- Facts on the reassignment. Confirm the allocation in writing and check the resource agreement or RACI you started with. Then a direct conversation with the functional manager: state the delivery impact in dates, not in frustration, and ask for a named replacement or a defined end date. If it is refused, escalate to the sponsor with the schedule impact quantified. Silent acceptance is how a five-month deadline quietly fails.
- Split the deadlock. The dispute is technical; the passed-over issue is interpersonal. Run the architecture decision as a time-boxed decision with explicit criteria - regulatory traceability, auditability, performance, effort - and written options. If the two engineers cannot converge, you decide, and you record the rationale and the dissenting view.
- The passed-over issue, privately. Acknowledge it directly. Give the subject expert a defined scope of authority - for example technical design authority - so status is restored through a real role rather than through sympathy. Do not pretend it did not happen; unaddressed it will keep surfacing as technical obstruction.
Week two. Re-plan with the actual capacity, re-baseline the forecast, and put the resource dependency on the risk register with an owner. Then move to the reporting problem, which is now documented and no longer a matter of opinion.
2. Why is your RAG status misleading, and how would you change reporting given an email-only sponsor?
Read the worked answer
Your RAG rule measures only one dimension, and it measures it late.
Why it is misleading. Milestone dates are the last thing to slip. A project can be green on dates while labour is at 61% efficiency, a critical resource is 60% gone, and two designs are unresolved. That is the classic watermelon: green outside, red inside. The rule rewards the project for not yet having failed.
Rebuild the criteria. Define RAG on multiple objective triggers, agreed with the sponsor in advance:
- Schedule: forecast finish (not planned finish) outside tolerance.
- Cost: CPI below an agreed threshold or EAC above budget.
- Scope and quality: unresolved critical defects or unapproved requirements.
- Risk and resources: any high risk without an owner and response, or a critical resource below agreed allocation for more than a set number of days.
Adapt to an email-only sponsor. Email is a poor medium for ambiguity, so remove the ambiguity:
- One page, decision-oriented: status, three key facts, what has changed since last report, and the specific decision or support required with a date.
- State explicitly when a status has changed from green to amber and why.
- Propose a 20-minute fortnightly call inside the overlap hour - email-only is the sponsor's preference, but a decision-maker who cannot be reached is a project risk that you must name.
- Keep a decision log so silence is visible and dated.
3. How do you address the business analyst's withdrawal, and what would you change structurally rather than just having a conversation?
Read the worked answer
Her silence is a leading indicator, not a personality issue. Treat it as a safety and process signal.
Direct, private, soon. Ask open questions about what would make it easier to contribute, without making her relitigate the incident. Do not promise to 'deal with' the subject expert in a way that makes her the cause of conflict.
With the subject expert, separately. Be specific about the behaviour, not the person: correcting a colleague in front of the team twice has a measurable cost - you lost an analyst's input on regulatory requirements. Ask for the standard to change: technical challenges go to the person first, or in writing. Frame it around his new design-authority role, which gives him a legitimate channel for exactly the corrections he wants to make.
Structural changes, because a conversation alone will not fix it.
- Change the stand-up format: written-first updates in a shared channel before the call, so the shared nine-hour window is used for decisions rather than performance.
- Round-robin or facilitate so no single voice dominates; explicitly invite the quietest time zone each time.
- Restate team norms once, publicly, and hold to them - including for the most senior expert.
- Add a short retrospective at the four-week mark with one action, so the team sees the norm is enforced.
Watch for a second signal: if her withdrawal continues, the issue is the environment, not the incident.