The Six-Week Project and the Small Feature
You lead a five-person engineering team. A client project must ship in six weeks. One engineer begins three weeks of parental leave next Monday. The client has just requested a “small” reporting feature that your team estimates at 90–120 hours. Across the six weeks the team has roughly 40 hours of genuine slack. Two of the five engineers are still ramping up and cannot own critical-path work. The contract includes a change-control clause but no agreed rate for additional scope. The client’s executive sponsor says the feature is needed for a board demo in week five. Your manager wants no schedule slip and no additional headcount.
1. How do you respond to the client and your manager?
Read the worked answer
I would separate the request into three claims: the board demo, the full reporting feature, and the contractual change. The demo is a real deadline; the full feature is 90–120 hours against 40 hours of slack; the contract requires change control but has no rate. Treating all three as one demand would force the team to absorb hidden overtime and put the ship date at risk.
To the client I would say: we can support the board demo with a thin, read-only report by week four using the available slack, and we can deliver the full feature after launch through a written change order. I would give two concrete options: a demo-quality slice now with the remainder deferred, or a full feature with an agreed trade-off, such as deferring a lower-value item from the current scope. I would ask the sponsor to confirm which outcome matters for the board.
To my manager I would present the same options with dates and hours, not a complaint. I would state that no schedule slip and no extra headcount are compatible only if scope changes or the demo is narrowed. I would ask for a decision by a named date so the team can plan.
2. What is your six-week plan to protect the ship date and the team?
Read the worked answer
Week 1: Run a 60-minute scope workshop with the client. Confirm the demo audience and the minimum viable report. Freeze critical-path work. Pair each ramping engineer with a senior owner and assign only bounded, well-tested tasks. Issue a written change request for the full feature with an estimated range and a requested rate or trade-off.
Weeks 2–3: Build the thin demo slice using the 40 hours of slack, capped at 30 hours to preserve contingency. The engineer on leave hands over runbooks and a named backup before Monday. Stop all non-essential meetings and internal tooling work.
Week 4: Demo review with the sponsor. If the slice is accepted, continue to ship. If the sponsor insists on the full feature, activate the trade-off: defer a current-scope item of comparable effort, in writing.
Weeks 5–6: Regression testing, release rehearsal, and a go/no-go checkpoint. Any new request goes through change control. I would track actual versus estimated hours weekly and escalate at the first 10% overrun, not at the end.