The Sponsor Who Wanted Everything by Friday
Northwind Retail has approved a €480,000 project to build a customer self-service portal. The approved business case names three outcomes: reduce call-centre volume by 15%, cut average order-status calls from 6 minutes to 2, and free two agents for returns processing. The sponsor, newly appointed, has added 14 features to the backlog, including a loyalty gamification module, and told the team the portal must launch in eight weeks to align with a marketing campaign. The team has six developers, one part-time business analyst, and no dedicated tester. At the first timebox review, the team demonstrates a working order-status journey, but the sponsor says it is 'not the full product' and asks for a revised plan covering all 14 features. The business analyst notes that only four features map directly to the business-case outcomes; three are regulatory; the rest are 'nice to have'. The project manager must respond before the next sprint.
1. Identify the project-goal problem in this situation and explain how you would restate the goal so it can guide decisions.
Read the worked answer
The problem is goal displacement: the sponsor is treating a feature count as the project goal. The approved business case defines outcomes - call volume, call duration, agent capacity - but the working goal has become 'deliver 14 features by launch'. That makes every feature look equally necessary and removes any rational basis for trade-off.
I would restate the goal as: 'By launch, deliver the smallest coherent portal that achieves the three business-case outcomes within the €480,000 and eight-week constraints, while meeting the three regulatory requirements.' Then classify: four business-case features plus three regulatory items are in scope for the first release; gamification and the remaining seven are candidates for later.
The restated goal must be agreed with the sponsor in writing and used at every review. It is not enough to publish it. The sponsor must confirm that a release meeting the outcomes but missing gamification is acceptable. If the sponsor will not accept that, the project has a different goal, and the business case, date, or budget must change. Otherwise the team will optimise for feature count and miss the benefits.
2. The sponsor insists on all 14 features by the launch date. Using DPMM thinking, outline your response and the prioritisation you would propose.
Read the worked answer
I would reject the implicit triple constraint of fixed scope, fixed date, and fixed team without an explicit trade-off. I would use MoSCoW against the business case. Must: the three regulatory features and the four that directly deliver the business-case outcomes. Should: features that improve adoption but have a manual workaround. Could: gamification and cosmetic items. Won't: anything not needed for launch.
Then I would present the sponsor with three explicit options. Option A: launch on the date with Must and Should items, defer gamification and the rest. Option B: keep all 14 features and move the date by a calculated number of weeks, with the cost of delay stated. Option C: add two developers and one tester, accepting onboarding risk and cost. I would recommend A because it protects the business case and reduces defect risk, especially with no dedicated tester.
The decision must be recorded in the business case and decision log. If the sponsor chooses B or C, the plan and business case are re-baselined. What must not happen is silent scope absorption. At the timebox review I would show the working order-status journey against the outcome metric, not just a feature checklist.
3. What should happen at the next timebox review to keep the goal visible?
Read the worked answer
The review should demonstrate outcomes, not output. Show the order-status journey working end-to-end and present a benefits tracker: baseline call volume, pilot call duration, and the manual effort removed. State which business-case outcome this increment moves and by how much evidence exists.
Re-run prioritisation with the sponsor present, using MoSCoW and the business case. Review the three regulatory features for evidence of compliance. Ask the sponsor to confirm the deferred items and their target release. Record decisions, assumptions, and any change to expected benefits. If the sponsor still insists on all 14 features, escalate to the business owner or portfolio with the trade-off analysis rather than letting the team absorb the conflict.
The goal stays visible when every review asks two questions: what business outcome did this increment move, and what did we consciously defer? That prevents 'feature complete' from replacing 'benefit delivered'. It also gives the team a defensible reason to say no to low-value work without appearing uncooperative.