Requirements gathering: asking better questions
People describe solutions rather than problems. Getting to the underlying need is most of the analyst's job.
Fixed budgets and iterative delivery are compatible if scope is the variable. Fixing all three is what causes trouble.
Time, cost and scope cannot all be fixed without quality becoming the variable, and quality is the one nobody agrees to sacrifice explicitly.
Fix budget and date, keep scope negotiable, and prioritise continuously. Most organisations can accept this once it is stated plainly at the start rather than discovered during delivery.
Order the backlog by value so that if delivery stops at any point, the most valuable work is done. This makes a fixed budget safe: you get the best available outcome for the money rather than an incomplete everything.
Re-order as understanding improves. A backlog fixed at the start encodes the least informed view anyone will ever have.
Reporting percentage complete against a fixed task list encourages the appearance of progress. Reporting what now works in production is harder to misrepresent and more useful.
Demonstrating working software each increment keeps the conversation on outcomes and gives stakeholders real information for the next prioritisation decision.
In a fixed-budget arrangement, change requests are where relationships are tested. Handling them mechanically rather than emotionally keeps things straightforward.
Assess the change, state its cost in time or scope, and put the decision to whoever owns the budget. The answer may be to proceed and drop something else, to defer, or to decline — all are legitimate.
What causes trouble is accepting changes informally without cost, then reporting a schedule problem later. Making the trade-off visible at the moment of the request keeps the client in control.
Suppliers confident in their delivery generally prefer it, because it removes the risk premium a fixed-scope price must contain. Suppliers who insist on fixing everything are pricing that risk into your budget.
Fix the discovery deliverable and the first increment precisely, and describe the ongoing arrangement as a costed framework. Most procurement processes can accommodate this.
With value-ordered increments it should not, because each increment is deliverable. Half-finished features indicate increments were sized too large.
Keep reading
People describe solutions rather than problems. Getting to the underlying need is most of the analyst's job.
Demonstrations show the path the vendor has rehearsed. A structured evaluation shows how the product handles your awkward cases.
A fixed price on genuinely novel work is a negotiation about who absorbs uncertainty. There is a more honest structure, and clients increasingly prefer it.