Four Weeks You Do Not Have
Your regulatory-reporting project was baselined at 26 weeks and USD 800,000. At the end of week 8: PV = 260,000, EV = 210,000, AC = 245,000. The remaining critical path is integration build (6 weeks), UAT (4 weeks), data migration (3 weeks) and training (2 weeks, with 2 weeks of float). A middleware vendor quotes 5 weeks' lead time. QA has agreed that UAT cannot drop below 3 weeks without falling under the 95% defect-detection threshold the regulator's auditors expect. The sponsor now says the system must go live in week 22 - four weeks earlier - because a reporting deadline moved. Overtime is available, but the team is already carrying 15% unplanned overtime.
1. What does the earned value data tell you, and which compression options are genuinely available?
Read the worked answer
Read the numbers first. SPI = 210/260 = 0.81; CPI = 210/245 = 0.86. You are behind schedule and over cost, so the remaining work will not run at planned productivity. EAC ≈ 800,000/0.86 ≈ 930,000.
Where compression is real:
- Training (2-week float) - consume float first; this is free and recovers nothing on the critical path but protects the sequence.
- Fast-track migration with integration - overlap them. Buys weeks, but migration against changing interfaces risks rework and a second migration pass.
- Crash integration build - add people. Ramp-up, coordination and review overhead mean 2 added people rarely yield 2 person-weeks; expect partial returns and watch quality.
- Vendor lead time - 5 weeks is a hard constraint; place the order today or it becomes the new critical path.
- Scope - if the regulation permits phasing, deferring non-mandatory report templates is the only lever with no quality cost.
Conclusion: four recoverable weeks are unlikely. Bring the sponsor an option set with cost, date and residual risk - not a promise.
2. The sponsor suggests cutting UAT to two weeks. How do you respond?
Read the worked answer
This is a quality-acceptance decision above your authority, so neither silently comply nor refuse.
Frame it as a trade, not an objection: two weeks of UAT breaches the defect-detection threshold QA agreed with the auditors, so residual defects move into production - in a regulatory system, that risk is visible to an external party.
Offer mitigations that make a shortened window survivable if the sponsor still chooses it: automated regression coverage for the highest-risk reports, a staged rollout to a subset of entities, an extended hypercare period with named on-call ownership, and a production smoke-test script signed off by QA.
Then get the decision recorded: who accepts the residual risk, in writing, at what level, with which trigger for rollback. Note it in the risk register with an owner.
Why: the project manager's job is to make the consequence of the choice explicit and owned - not to hold the quality line alone, and not to hide it behind a schedule update. If the regulator's auditors will not accept the reduced coverage, that constraint settles the question.
3. What must happen before the schedule baseline changes?
Read the worked answer
A four-week pull-in against a fixed regulatory deadline is a change to an approved baseline, not a re-plan.
Sequence:
- Complete the impact analysis - schedule, cost, quality, risk, and which milestones are affected.
- Raise a formal change request with the options considered and your recommendation.
- Route it to the change control board (or whatever governance body owns this baseline), including QA and compliance input on the testing threshold.
- On approval, update the schedule and cost baselines, the risk register, and the change log; re-forecast dependencies and the vendor commitment.
- Communicate the new dates and the accepted risks to all affected stakeholders - the regulator-facing business owner in particular.
Why the process matters here: an offline re-plan means cost and risk reporting continue against a baseline nobody believes, and the eventual variance lands on you. Baseline change discipline is also the evidence trail if the go-live date becomes a contractual or audit issue.