Who Owns the Decision? Business Ambassador vs Technical Coordinator
On a 6-month AgilePM project delivering a claims-handling system, a disagreement has stalled a timebox. The business ambassador wants a validation rule that rejects claims submitted without a supporting document, arguing it protects the business. The technical coordinator argues the rule will add 3 days of work and that the current timebox is already at capacity; she proposes deferring it to a later timebox. The team leader says the team could do it if a lower-priority 'could have' (a dashboard widget) is dropped. The project manager is on leave. The business sponsor has not been involved and expects the timebox to end on schedule. The requirements list marks the validation rule as a 'should have'.
1. Explain which roles should make this decision and how AgilePM's role model resolves it.
Read the worked answer
AgilePM separates business decision-making from technical/solution decision-making, and the resolution should respect that split.
- Business ambassador represents the business need day-to-day and is the right role to argue what the business requires and its priority. She does not, however, unilaterally dictate technical feasibility.
- Technical coordinator owns the technical integrity and the solution architecture, and advises on effort/feasibility. Her capacity concern is legitimate input, but 'it costs 3 days' is a technical constraint, not a business priority decision.
- Team leader manages the team's work and can propose the trade-off (drop the 'could have' widget) - that is a delivery-level suggestion.
- Project manager facilitates the trade-off and escalates; in their absence, the decision should not simply stall.
- Business sponsor owns the business case and is the ultimate escalation point for priority conflicts that affect business benefit.
Correct process: the business ambassador and technical coordinator establish the facts (3 days effort vs capacity), the team leader confirms the swap is feasible, and the business ambassador (with the project manager, or sponsor if unresolved) decides priority. Because the rule is a 'should have', it is legitimately deferrable - but only the business side should decide that, not the technical coordinator. The dashboard widget is a 'could have' and is the correct thing to sacrifice first under MoSCoW.
2. What should happen about the sponsor's expectation that the timebox ends on schedule, and what does AgilePM say about protecting the timebox?
Read the worked answer
AgilePM's timeboxing principle is that time and cost are fixed and scope is flexed - so the sponsor's expectation of an on-schedule end is correct and should be protected. The mechanism for protecting it is MoSCoW prioritisation, not overtime or scope creep.
Actions:
- Do not extend the timebox. The fixed end-date is the control; extending it erodes the very predictability the sponsor is relying on.
- Apply MoSCoW: drop the 'could have' dashboard widget (and, if needed, the 'should have' validation rule) so the 'musts' are delivered. The team leader's proposed swap is exactly the right instrument.
- Communicate proactively: the project manager (or deputy) should inform the sponsor of the trade-off - what will and will not be delivered at the timebox end - rather than let the sponsor discover it. AgilePM stresses 'Collaborate' and 'Demonstrate control'.
- Record the deferred item: the validation rule should be captured for a later timebox, with the business ambassador confirming the deferral is acceptable (it is a 'should have', so this is defensible).
- Escalate only if a 'must have' is at risk - then the sponsor must decide, because that affects the business case.
The lesson: the sponsor's schedule expectation is honoured because scope is flexible; the failure mode would be silently adding 3 days and blowing the timebox.