Every Request Is a Decision in Disguise By Coach Omo

Early in my business analysis career, a senior manager asked me to build a tracking spreadsheet. Nothing complicated, just somewhere the team could log the status of customer complaints. I built it and it was a good spreadsheet. Within three months, nobody was using it.

The spreadsheet was never the problem. The team did not need a place to record complaints. They needed a way to decide which complaints to escalate, and the criteria for that decision lived in one person's head. No spreadsheet was ever going to fix that. A twenty-minute conversation eventually did.

That experience taught me something I now consider the foundation of good analysis: people rarely bring you problems. They bring you solutions they have already decided on.

The hidden journey behind every request
When a stakeholder comes to you with a request, whether it is a new system, a new hire, a new process or a new report, they have already travelled a mental journey. Somewhere along the way, they noticed a symptom. They formed a theory about what was causing it. And they landed on an answer that felt right.

By the time the request reaches you, all of that thinking is invisible. You only see the destination, not the route.

The traditional business analysis response is to gather requirements around the request. The better response is to walk that journey backwards, because the quality of the eventual solution depends entirely on the quality of the reasoning that produced the request.

This is where decision intelligence transforms the practice of business analysis.

What decision intelligence actually adds
Decision intelligence is the discipline of connecting outcomes to decisions, and decisions to the information that shapes them. Applied to business analysis, it gives you a simple but powerful reframe: every request is a proposed decision, and your job is to test whether that decision actually connects to the outcome the business cares about.

In practice, I run every significant request through four questions:

1. What outcome are you trying to change? Not the deliverable. The business result. Revenue, retention, cost, risk, speed. If the stakeholder cannot name one, the request is floating free of any real purpose.

2. What decision would move that outcome? Outcomes do not change because artefacts exist. They change because someone, somewhere, makes a different decision. Who is that person, and what decision are they facing?

3. What information would improve that decision? Now you are getting close to the real requirement. Often the information needed is far smaller and simpler than the solution originally requested.

4. Does the requested solution actually provide it? This is the moment of truth. Sometimes the answer is yes, and you now have a requirement anchored to a genuine business decision. Often the answer is no, and you have just saved your organisation months of building the wrong thing.

A worked example
A client of mine, a team lead in a mid-sized services firm, was convinced her department needed a workflow automation tool. The business case was already half written.

We ran the four questions. The outcome she wanted to change was staff overtime, which had crept up for two quarters. The decision that would move that outcome was how work got allocated at the start of each week. The information that would improve that decision was simple visibility of each person's current workload.

Did the automation tool provide that? Partly, buried in a module they would probably never configure. What actually solved it was a fifteen-minute Monday planning routine and a shared capacity view that took two days to set up.

The automation tool was a decision made too early, with too little information. The four questions surfaced that before a penny was spent.

Why this matters more than ever
Organisations today are drowning in solutions. Every vendor, every framework, every AI tool arrives pre-packaged as the answer. The scarce skill is no longer building things. It is knowing which things deserve to be built.

That is why I believe the business analysts and consultants who thrive in the next decade will not be the best requirement writers. They will be the best decision architects: people who can trace any request back to the decision it serves, and any decision back to the outcome it moves.

The deliverable was never the system, the spreadsheet or the tool. It was a better decision, made sooner, with more confidence.

So the next time a request lands on your desk, pause before you document a single requirement. Ask yourself: what decision is hiding inside this?

The answer might completely change what you build. It might mean you build nothing at all. And that, sometimes, is the most valuable outcome of an analysis.