Fixed price, ten-week promise, fourteen-week estimate
You are the project manager for a fixed-price £480,000 CRM implementation for a client with 300 users. Sales has committed to a 10-week go-live with 3 weeks of parallel running. Your team's bottom-up estimate is 14 weeks at 70% confidence. Requirements workshops produced 42 user stories; 11 are marked must-have, but only 6 have acceptance criteria. Data migration covers two legacy systems. A sample of 500 records shows 18% duplicates and 7% missing mandatory fields. The contract says 'all reasonable requirements are included' and requires the client PM to approve change requests within 5 days. Your sponsor wants the charter signed this week to release £120,000 of mobilisation funding. The client's IT director, who holds delegated approval, is on leave for 3 weeks. The sales lead says the estimate gap is just team pessimism. What do you do?
1. Should you sign the charter this week? Set out the conditions under which you would sign and the clauses or attachments you would require.
Read the worked answer
Sign only if the charter separates the commercial commitment from the delivery baseline. The 10-week date is a sales commitment that your estimate does not support. Signing without conditions converts an estimate gap into a project-level failure that the team will own.
Conditions I would require:
- A 14-week baseline, or an approved phased release. A 10-week pilot for a limited user group can be viable, but only if the must-have scope and acceptance criteria are fixed. The remaining scope moves to a second release with its own date.
- An assumptions and exclusions log attached to the charter. It must state the data quality found in the sample, owner of data cleansing, integration assumptions and client decision latency.
- Acceptance criteria for the 11 must-haves. Six with criteria is not enough to plan or test. The other five must be elaborated before build starts or explicitly moved out of the first release.
- A named client decision-maker for the IT director's absence. Otherwise the 5-day change approval clock will expire with no approver and work will stall.
- A change control procedure with an escalation path, not deemed approval. Deemed approval can let unresolved scope become contractual scope.
If the sponsor insists on an unconditional signature, record the advice in writing and ask for a formal risk acceptance. Release mobilisation funding against defined mobilisation activities, not against the full delivery promise.
2. How will you plan and estimate the work given the 10-week contractual date and the 14-week estimate? Include contingency and the data migration uncertainty.
Read the worked answer
Plan two tracks: the contractual commitment and the forecast. Do not hide the gap inside a single optimistic plan.
- Run a two-week data profiling spike before committing migration effort. Expand the sample beyond 500 records, quantify duplicates and missing fields by source system, and identify the business owner for cleansing. A 7% missing mandatory field rate is a schedule and quality risk, not a rounding error.
- Use three-point estimates for migration and integration. The uncertain stories should carry ranges, not single numbers. Report the 70% confidence estimate and the assumptions behind it. The sales lead's 'pessimism' claim is not evidence; the sample data is.
- Separate contingency from padding. Hold a management reserve for unknown data remediation and a schedule contingency for integration rework. The reserve is released by the sponsor against defined triggers.
- Phase the release. Deliver the agreed must-haves to a pilot at week 10, then the remaining scope by week 14. If the client rejects phasing, require a formal re-baseline before build proceeds.
- Protect testing and parallel running. The 3-week parallel run is part of the delivery, not slack. Compressing it to recover the 4-week gap would transfer risk to go-live.
Use rolling-wave planning for the unclear stories and a definition of ready before each enters a sprint. The estimate gap is a planning fact to be resolved, not a motivation problem.
3. The client invokes 'all reasonable requirements are included' and refuses a change request for 11 extra reports. What is your response?
Read the worked answer
Refuse blanket inclusion and convert the argument into a scoped decision. 'Reasonable' is not testable; a list is.
- Reconstruct the agreed scope. Use the workshop outputs, the 42 stories, the 11 must-haves and any written acceptance criteria. Ask the client to identify which of the 11 reports were in the original workshops and which are new.
- Assess impact, not just cost. Estimate effort, effect on the 14-week baseline, testing load and any data dependencies. Present the impact of all 11 versus a subset.
- Offer a trade-off. Propose swapping lower-value reports for must-haves, or phasing the reports after go-live. This protects the relationship while preserving the baseline.
- Escalate with the contract position. If the client refuses any change, log it as a formal dispute and ask the sponsor and commercial lead to decide. Do not instruct the team to absorb the work silently.
- Protect the team. No build starts on the disputed reports until a decision is recorded. Otherwise the project delivers the scope and loses the change argument.
The lesson for the charter is that vague inclusion clauses must be converted into an agreed list before signature, not argued about during execution.