The Estimation Conflict
A team of six engineers is asked to deliver a feature set for a fixed external launch date in ten weeks. The product manager has already announced the date to a customer. During planning, the engineers estimate the work at roughly 14 weeks at their normal pace, with a wide range driven by an uncertain third-party integration. The engineering manager proposes cutting the estimate to 10 weeks by assuming the integration will be straightforward and by deferring testing to a hardening phase after launch. A senior engineer objects, saying that the team has never met a date estimated this way. The organisation has a history of late launches and a recent incident caused by insufficient testing. The customer contract includes a penalty for late delivery but no penalty for reduced scope.
1. What is the core decision problem here, and what information is missing before a recommendation can be made?
Read the worked answer
The core problem is not whether the team can work faster; it is that a fixed date, a fixed scope, and a fixed team size are being treated as simultaneously negotiable when the estimate says they are not. The estimate of 14 weeks with a wide range around an uncertain integration is the key fact, and the proposal to reach 10 weeks works by removing uncertainty from the estimate rather than from the work. Deferring testing does not remove testing; it moves the cost past the launch date, where it becomes an incident risk, and the organisation has already paid that cost once.
Before recommending anything I would want four pieces of information. First, what is the actual contractual commitment: is it the full feature set, or a subset that the customer cares about most? Second, what is the penalty for late delivery compared with the cost of a launch incident, and who bears each? Third, how uncertain is the third-party integration really: is there a sandbox, a specification, and a named contact, or is it an unknown? Fourth, what is the decision authority of the engineering manager versus the product manager, and can scope be reduced without reopening the customer conversation? Without those, any recommendation is guesswork. I would also want to know whether the 14-week estimate is a single number or a range with a most likely value, because the range is the most useful input to the negotiation.
2. Recommend how the team should respond, including how to communicate it to the product manager and the customer.
Read the worked answer
I would recommend refusing to compress the estimate by assumption and instead offering the product manager a set of explicit options. The first option is to reduce scope to the subset that fits in ten weeks with testing included, using the customer's own priorities to choose. The second is to keep full scope and move the date, accepting the contractual penalty if it is smaller than the expected cost of an incident. The third is to keep the date and scope but add capacity, for example by bringing in a second team for the integration or by buying a supported integration rather than building it. Each option should carry its estimate, its risk, and its cost so the product manager can choose rather than being told no.
On communication, I would be direct and early. To the product manager I would present the 14-week estimate with its range, explain that the 10-week figure depends on an assumption the team cannot verify, and show the three options with their consequences. I would make clear that deferring testing is not one of the options, because it converts a schedule risk into a quality risk and the organisation has already seen that outcome. To the customer, the product manager should lead, but engineering should supply a short, factual statement of what is certain and what is not, and a proposed checkpoint at which the integration risk will be resolved. That checkpoint is the most useful commitment the team can make: it gives the customer a real date for a real decision rather than a false promise about the final date.