How to get IT and the business to agree on what was asked for

The most expensive failure in technology delivery is building the right thing badly described. It shows up at user acceptance, it is attributed to poor requirements, and the cause was almost always that nobody asked the question behind the request.

Treat a request for a tool as an answer

“We need a dashboard.” “We need a workflow system.” “We need Copilot licences.”

Each is a conclusion someone reached, often reasonably. The useful response is to ask what problem it solves, what happens today, and what they would do differently with it. Sometimes the answer confirms the request. Often it reveals something cheaper, or something different.

This has to be done without implying the requester was wrong. The framing that works is that you want to make sure the thing you build actually helps, and for that you need the situation rather than the specification.

Watch the work, do not just discuss it

What people describe and what they do diverge, not from dishonesty but because expertise becomes invisible to its owner. The workarounds, the second spreadsheet, the phone call that unblocks things — none of it appears in a requirements workshop and all of it is where the requirement lives.

An hour sitting with someone doing the work is worth several hours of meetings about the work.

Ask what happens when it goes wrong

Normal-path requirements are easy to gather and usually correct. The exceptions are where systems fail and where the business actually spends its time.

Ask for the last three times something did not go smoothly, in specifics. That conversation surfaces the requirements that would otherwise appear as change requests in testing.

Write outcomes with a test attached

A requirement should say what has to be true and how you would know. “Finance can close the month without exporting to a spreadsheet” is testable. “Improved month-end efficiency” is not.

Where a requirement cannot be given a test, it is usually not yet understood well enough to build from.

Get the disagreements out early

Sales counts a sale at order. Finance counts it at delivery. Operations counts it at dispatch. All three are correct within their own frame, and if the disagreement is not surfaced in design it will surface in testing, when changing it is expensive.

Deliberately putting the conflicting parties in the same conversation is uncomfortable and much cheaper than the alternative. The output is a written definition, agreed, that the build refers to.

Say what you are not building

Confirmation should state what is in scope and what is explicitly not. People fill silence with assumptions, and an unstated exclusion reappears as a defect.

This is also where expectations about timing get set. A request that will not be met for two quarters should be told so when it is made, not discovered by its absence.

What changes when this is done well

Fewer change requests, shorter acceptance testing, and less rebuilding after go-live. The real difference is in the relationship: business teams stop treating IT as a queue, because being asked good questions is evidence that someone is trying to solve their problem rather than close their ticket.