Two Approvers, No Owner, and a Silent Slip

Three distinct problems are being treated as one.

1. Capacity/loss of a key resource - the lead developer is now 50% gone. This is the most urgent because it directly explains the slippage and cannot be fixed by process.
2. Unclear decision rights - two approvers for page copy. Ambiguity here is not a communication problem; it is a structural defect that guarantees rework and stalls.
3. Process gaps - no change control for sales' requests, and no status cadence that surfaces slippage early.
4. Team/people friction - designer-developer rework is partly interpersonal, partly an undefined handoff.

Sequence:

• First, the resource. Quantify the impact of the 50% loss against the next two milestones in days and cost of delay, then take it to the sponsor and the functional manager together. Frame it as a trade-off, not a complaint: "At 50%, milestone 3 moves from Aug 12 to Sept 2; production support needs to be staffed elsewhere or the date moves."
• Second, decision rights. Publish a RACI where each deliverable has exactly one accountable approver (e.g. merchandising director approves copy; content lead is consulted). Say it out loud in a team meeting so both parties hear the same ruling from the sponsor, not from the PM.
• Third, change control for sales, then a short weekly status cadence.

Fixing process before capacity will look organized while the date keeps moving.

Lead with the truth and the ask; a status report is a decision tool, not a mood indicator.

Structure:

1. Overall health: RED or AMBER with a one-line reason. If two milestones slipped and the sponsor has not been told, the honest color is not green.
2. Milestones: baseline date vs forecast date vs variance, for each. Slipped: Content migration (Aug 1 → Aug 15, +10 days), Checkout integration (Aug 20 → Aug 29, +7 days).
3. Why: root cause stated factually without blame - "lead developer capacity reduced 50% from July 14; copy approval ambiguity caused one full rework cycle."
4. Recovery plan with options: (a) restore capacity → dates recover to +3 days; (b) hold capacity, cut the loyalty-page scope → original dates hold; (c) accept new dates. Recommend one.
5. Risks and issues with owner and needed decision.
6. Budget burn vs plan, briefly.

The critical behavior is no surprises: the sponsor should never learn about slippage from someone else. The PM should also state plainly that earlier slippage was not escalated and describe the new threshold for escalation (e.g. any variance over 3 days is reported within 48 hours). Owning the gap is what makes the next report credible.

Every request enters one logged channel and gets an impact analysis - no exceptions, no silent acceptance.

Process:

1. Single intake: a request form or ticket (not email chains to the PM). This protects the PM from becoming an unwitting scope funnel.
2. Log it in the change log / backlog with requester, date, description, priority.
3. Impact analysis before any commitment: effort in days, effect on schedule and budget, testing and accessibility cost, risk.
4. Decision by the right authority. Small, in-scope items can be accepted by the PM; anything that moves baseline scope goes to the sponsor or change control board. The PM recommends; the sponsor decides.
5. Respond with options, not a yes/no: "This is 4 days of design and dev. We can (a) swap it for the promo-banner page, keeping the date; (b) add it to the next release in October; (c) add it now and move the launch by 4 days. Which do you want?"

First request: log it, do the impact analysis, and reply with the three options inside two business days. This does two things at once - it respects the sales director's need (which is usually a customer deadline, not a whim) and it makes the cost of scope visible to everyone, including the sponsor, who is currently hearing that the project is simply "behind." Silent acceptance is what turns a request into a slipped milestone nobody can explain.