4 exercises — requesting extensions with context, proposing phased delivery, raising dependency risks early, and communicating late-stage delays proactively.
0 / 4 completed
1 / 4
You need to request a 2-week deadline extension for a feature. Your manager asks why. Which explanation is most professional?
Option B uses the original estimate → documented changes → quantified scope growth → two options structure:
1. References the original estimate context: "Based on scope at kickoff" — shows the estimate was reasonable at the time 2. Documents specific changes: "authentication requirement added" and "data model changed twice" — concrete, named changes 3. Quantifies the growth: "40% larger than originally planned" — puts a number on the scope change 4. Offers two options: extension OR ship original scope now — maintains the relationship and the manager's agency
Why A fails: "Underestimated" puts all responsibility on the estimation process without explaining what changed
Why C and D fail: Vague — "longer than expected" and "technical problems" give the manager no information to make a decision
Extension request formula: Original estimate context → Specific changes since → Quantified scope growth → Extension OR partial delivery now
2 / 4
A project deadline is truly impossible to move. You need to negotiate phased delivery instead. Which proposal is strongest?
Option C is an ideal phased delivery proposal:
1. States the constraint honestly: "can't ship without cutting quality in ways I'm not comfortable with" — personal professional commitment, not policy 2. Names each phase clearly: dates, feature names, and what percentage of user value is delivered in Phase 1 — the PM can make an informed decision 3. Identifies the business value of Phase 1: "~70% of user value" — acknowledges that the most important part ships first 4. Interprets the business need: "shippable product for the launch announcement" — connects the phased plan to the likely business reason behind the fixed date 5. Closes with a question: "Would that structure work?" — invites dialogue rather than demanding acceptance
Why A fails: States the problem without offering a solution
Why B fails: Asking "can we get more time" after a fixed deadline is already set is a wasted question
Why D fails: "Try to deliver what we can" is the worst possible commitment — neither the PM nor the engineer knows what "what we can" means
Phased delivery formula: State constraint + why → Phase 1 (date + scope + % of core value) → Phase 2 → Phase N → Ask if structure works
3 / 4
You committed to a deadline but a critical dependency — an external API — has not been delivered by the vendor. How do you raise this?
Option B is a professional dependency risk escalation:
1. Named, specific risk: "payment gateway API due March 1, still not received by March 8" — precise language, no vagueness 2. Quantified impact: "7 days to do 10–12 days of work" — the manager instantly understands the pressure 3. Three numbered options: escalation, parallel development, or timeline revision — shows preparation and analytical thinking 4. States a recommendation: "option 2 to protect deadline while option 1 runs in parallel" — doesn't just list options and walk away; takes a position 5. Returns decision authority: "Your call on how to proceed" — keeps manager in control
Why A fails: Blame language ("the vendor's fault") without a solution plan — doesn't help the situation and sounds defensive
Why C fails: "Might be late" without data or a path forward
Why D fails: "I'll update you when it arrives" is passive risk management — by the time it arrives you'll have no time
Dependency risk formula: Named dependency → Expected vs actual dates → Time impact → Options numbered → Recommendation → Decision returned to manager
4 / 4
After completing a project, you discover the post-release testing will take 2 days longer than planned. The client launch is at risk. How do you communicate this?
Option B is a professional late-stage delivery risk notification:
1. Names the specific problem: "gap in the test suite that requires additional test cases" — not vague "testing issues" 2. Quantifies precisely: "2 additional business days — Wednesday rather than Monday" — exact, not "a couple of days" 3. Proactive timing: "I want to be transparent before Monday arrives rather than after" — giving the client 2 days to react is vastly better than a Monday morning surprise 4. Two options with framing: "proceed Monday with known gaps" OR "wait until Wednesday for full coverage" — presents the stakeholder with a real choice 5. States the recommendation with reasoning: "I recommend Wednesday — a production incident costs more than 2 days" — helps the client make an informed decision 6. Offers urgency path: "I'm available to discuss today if the launch date is critical" — signals responsiveness
Why A and C fail: Describe the symptom without a recommendation or options
Why D fails: Recommendation without context — why? By how long? What are the options?
Late delivery formula: Specific cause → Exact new date → Why transparency now → Two options → Recommendation + reasoning → Offer to discuss urgently