Skip to content
QSWEQB
hardCase StudyScenarioMidSeniorStaffLead

How do you turn an effort estimate into a delivery date you would defend, and what do you do when the sales lead has already promised an earlier one?

Convert effort to duration through explicit productive capacity, then check it against the critical path and the customer's dependencies, because dates are often bound by sequence rather than effort. Against a promised date, commit a smaller scope rather than a compressed plan.

5 min readUpdated 2026-07-28

What the interviewer is scoring

  • Does the candidate derive duration from stated capacity assumptions rather than dividing effort by headcount
  • Whether they identify a critical path that extra people cannot compress
  • That customer-side dependencies are treated as schedule items with owners and dates
  • Whether the response to a promised date is a reduced committed scope rather than a compressed plan
  • Does the candidate get the disagreement recorded in writing without making it a confrontation in front of the customer

Answer

Effort is not duration, and the conversion is where dates are lost

A number of person-days says nothing about a calendar until you state how much of a person's month is actually available to the project. Doing that conversion explicitly is the whole discipline, because the alternative — dividing effort by headcount and reading off a month — silently assumes people work every working day on one thing.

Take a build estimated bottom-up at 420 person-days with a team of five engineers.

Productive capacity, stated as assumptions

  working days per person-month                     21
  less public holidays and leave, averaged         -1.5
  less ceremonies, support rota, interviews        -2.5
  less onboarding to the customer's estate,
    amortised over the engagement                    -1
                                                 ------
  productive days per person-month                  16

  team of 5  ->  80 productive days per month
  420 / 80   =  5.25 months of build

Then the phases that are not build

  mobilisation, access, environments               0.75 month
  build                                            5.25 months
  UAT support and defect fixing                    1.0 month
  cutover, parallel run, hypercare                 0.75 month
                                                 ------------
  elapsed duration                                 7.75 months

Sixteen productive days out of twenty-one is the line that does the work, and it is the line that gets deleted when a plan is being made to fit. It is also the line an experienced delivery lead will check first, because a schedule built on twenty-one is a schedule that has already spent its contingency on the assumption that nobody takes leave.

Then check the sequence, because effort is usually not the constraint

Having a duration derived from capacity, test it against the order in which the work has to happen. Suppose the integration workstream is 60 days, requires the one integration specialist you have, and cannot start until the customer's test environment exists.

Critical path, not effort

  weeks 1-3    mobilisation
  weeks 4-9    customer test environment provisioned  <- their dependency
  weeks 10-24  integration, 60 days, one specialist, sequential
  weeks 24-28  end-to-end test, needs integration complete
  weeks 28-32  UAT, cutover, hypercare

  earliest credible go-live: week 32, about 7.4 months
  effort-derived duration:            about 7.75 months

  Integration cannot start at week 6 however free the specialist
  is, because the environment it runs against does not exist
  until week 9. The effort figure still governs, but only just,
  because the workbench and ingestion streams cannot all run in
  parallel with only five engineers. Put eight on it and the
  schedule becomes dependency-bound at week 32, so the three
  extra people buy a fortnight.

Producing both numbers and reconciling them is the part that reads as senior. It tells you which lever actually moves the date: where the schedule is effort-bound, more people help; where it is dependency-bound, the only compression available is starting the customer's environment work earlier, and that is a conversation with them rather than a resourcing decision of yours.

When a date has already been promised

Assume the sales lead has told the customer seven months, and your work says seven and three-quarters at best, with the integration specialist as a single point of failure. Three responses are available and only one of them is honest.

You can compress the plan, which means deleting the leave assumption, halving UAT, and running hypercare with the same people who are building phase two. This is the option that gets chosen, it is invisible in the document, and it fails in month six in a way that is then attributed to delivery.

You can refuse, which makes you the obstacle and gets you routed around within two quarters.

Or you can hold the date and reduce what is committed to it, which is the answer worth giving. Commit contractually to intake and ingestion live in production at month seven, with the exceptions workbench following at month nine, and phase the milestones and the payments to match. The customer keeps the date they were given, you keep a number you can defend, and the thing that moved is scope — which is the only one of the three variables that can move without someone absorbing it quietly.

The phrasing matters because the sales lead has to be able to take it to the customer as something positive.

"We can hold the seventh of April. What goes live on that date is claims intake and document ingestion, which is the part your regulatory commitment depends on, and I will put an SLA against it. The exceptions workbench lands in June. If we try to put all three on April I would be committing you to a date on a plan with no float, and the first thing to slip would be testing, which is the last place either of us wants to find time."

Getting it recorded without a confrontation

Never litigate this in front of the customer, and never leave it verbal. The same day, in an email the sales lead and the delivery lead both receive, state the effort basis, the capacity assumption, the critical-path constraint, the date you can defend and the scope attached to it. That is not a defensive act, it is what makes the disagreement resolvable at the right level — a deal board can decide to accept a schedule risk knowingly, which is a legitimate commercial decision, and it can only do so if the risk is written down.

If you are overruled, the recorded position converts into delivery instructions rather than an argument: the integration specialist gets a named backup from week one, the customer's environment date goes into the assumptions with a day-for-day relief clause, and the first slip is escalated in week three instead of month five. A promised date that you have documented the conditions for is survivable. A promised date nobody wrote the conditions down for is where the write-down comes from.

What separates a strong answer here

Weak answers treat the date as a negotiation about confidence, and offer either capitulation or a flat refusal. Strong answers do arithmetic in public: capacity per person-month, effort divided by capacity, sequence checked separately, and the disagreement between the two numbers explained rather than averaged. Then they change the scope rather than the estimate, because an estimate revised downwards under commercial pressure has not become more accurate, it has only become quieter.

Likely follow-ups

  • The customer offers to fund three more engineers to hit the earlier date. What do you tell them?
  • How would you phase the delivery so the promised date has something real on it?
  • What do you put in the assumptions section to protect a date that depends on their test environment?
  • You are overruled and the earlier date is committed. What do you do in the first two weeks of delivery?

Related questions

estimationschedulingcritical-pathcommercialspresales