# Business analysis: the problem behind the request

*People ask for solutions. Your job is to find out what they were trying to do.*

## Production summary

- Modules to record: 2
- Total script: 1151 words, about 8 minutes of finished audio
- Voices: Amara (host) and Nadia (practice educator)
- Level: New business analysts and anyone gathering requirements

## Accreditation wording that must appear in the description

- **The CPD Certification Service** (planned): Application scheduled.

> Do not upgrade any of these words in a description or a thumbnail. Aligned is not accredited, and planned is not approved.


---

## Finding the problem behind the request

**Runtime** about 4 minutes. **Words** 615. **Starts at** 00:00 in the full course recording.

### Learning outcomes to state on camera

- Separate a solution from the problem it was meant to solve
- Write requirements as need rather than implementation
- Map a process as actually performed
- Handle conflicting requirements without averaging them

### Script


`[CUE 1]` *A stated solution unwinding into the actual problem across three questions.*

**AMARA**  [00:00]
A stakeholder asked me for a dropdown. I built the dropdown. They are still unhappy.

**NADIA**  [00:06]
Because a dropdown was never the requirement. It was their guess at a fix for a problem they never told you about.

**AMARA**  [00:14]
They seemed very clear about what they wanted.

**NADIA**  [00:18]
They were clear, and they had already done the analysis in their head and skipped to the answer. Nobody asks for a requirement. People ask for solutions.

**AMARA**  [00:28]
So what should I have asked?


`[CUE 2]` *The same need met by four different solutions, only one of which was requested.*

**NADIA**  [00:31]
What are you trying to achieve. And then ask again. Not interrogation, and not the mechanical five whys that makes people feel handled. Two or three real questions.

**AMARA**  [00:42]
Walk me through it with the dropdown.

**NADIA**  [00:45]
Can we have a dropdown on that screen. Why? Because people keep typing the department name differently. And why does that matter? Because the monthly report is wrong, we cannot group by department.

**AMARA**  [00:58]
So the requirement is about the report, not the screen.

**NADIA**  [01:02]
The requirement is consistent department data for reporting. A dropdown is one way to get it. So is a lookup, an integration with the staff directory, or removing the field entirely and deriving it from who logged in.


`[CUE 3]` *Weak requirement specifying a control, beside a need based one leaving options open.*

**AMARA**  [01:17]
That last one is much better and nobody would have asked for it.

**NADIA**  [01:22]
Nobody ever does, because they were reasoning from the screen they were looking at. And there is one question that does most of this work for you.

**AMARA**  [01:33]
Which is?

**NADIA**  [01:34]
What would you do with it once you had it? The answer is almost always the real requirement, and it very often reveals that the thing they asked for was not the shortest route to it.

**AMARA**  [01:48]
How should I write it up?


`[CUE 4]` *Documented process beside observed process, with the workaround highlighted.*

**NADIA**  [01:51]
Describe the need and leave the how open. Weak version: the system shall provide a dropdown of departments on the referral screen. That specifies a control, a location and a mechanism, and closes off every better option.

**AMARA**  [02:05]
And the better version?

**NADIA**  [02:07]
A user must be able to record the referring department in a way that allows grouping by department in reporting, without free text. Same need, all the solutions still available.

**AMARA**  [02:19]
What about acceptance criteria?

**NADIA**  [02:21]
Make them testable. It should be easy to use is not a criterion, it is a wish. A user can complete the referral in under two minutes without training is a criterion, because somebody can go and check.


`[CUE 5]` *The desktop spreadsheet doing what the system should.*

**AMARA**  [02:36]
Process mapping. People tell me the process and then do something different.

**NADIA**  [02:41]
There are always two processes. The one in the procedure document, and the one people actually perform. Your system has to support the second one, and it is never written down anywhere.

**AMARA**  [02:53]
Is that just people cutting corners?

**NADIA**  [02:56]
Almost never. It is usually a workaround for something the official process does not handle, and that workaround is the single most valuable piece of information in your whole analysis.

**AMARA**  [03:08]
How do I find them?


`[CUE 6]` *Conflicting requirements dissolving at the level of underlying need.*

**NADIA**  [03:10]
Watch people work rather than only asking. Ask what they do when it goes wrong. Ask what happens at month end. And ask what the spreadsheet on their desktop is for.

**AMARA**  [03:22]
There is always a spreadsheet.

**NADIA**  [03:24]
There is always a spreadsheet, and it is always doing something the system should have been doing. Find it and you have found your requirements.

**AMARA**  [03:34]
Last thing. Two stakeholders want opposite things.

**NADIA**  [03:37]
Do not average them, because the midpoint usually serves neither. Go back to the problem behind each request first.

**AMARA**  [03:45]
And if they still conflict?

**NADIA**  [03:47]
Then name it explicitly, set out the options and consequences, and take it to whoever owns the decision. An analyst who quietly picks a winner has made a business decision they had no authority to make, and it always resurfaces as a complaint that nobody was consulted.

### Sources for the on screen credit

- BCS business analysis body of knowledge, BCS, The Chartered Institute for IT
- Requirements engineering practice literature, IEEE Software
- Service design and user research guidance, Government Digital Service

---

## Workshops, data and landing the change

**Runtime** about 4 minutes. **Words** 536. **Starts at** 04:06 in the full course recording.

### Learning outcomes to state on camera

- Run a requirements workshop that produces decisions
- Use data to test what people tell you
- Write findings people act on rather than file
- Support the change landing, which is where analysis actually pays off

### Script


`[CUE 1]` *A workshop that should have been two interviews.*

**AMARA**  [04:06]
My workshops sprawl. Two hours, lots of talk, nothing decided.

**NADIA**  [04:10]
Then start with whether it should have been a workshop at all. A workshop is for what needs several people in a room: conflicts, cross team process, priorities. Gathering information one person holds is an interview wearing a room booking.

**AMARA**  [04:26]
And when it genuinely needs the room?

**NADIA**  [04:28]
Structure beats charisma, every time. State the decision the session exists to produce, at the start, on the wall. Timebox the sections. Park what does not belong, visibly. And end by reading back what was decided, who owns each action, and by when.


`[CUE 2]` *The decision on the wall, timeboxes, a parking lot, and the read back.*

**AMARA**  [04:46]
The read back feels bureaucratic.

**NADIA**  [04:48]
It is ninety seconds, and it is the difference between a decision and a memory. Three weeks later, the read back is the only version anybody agrees on.

**AMARA**  [04:59]
I have a senior person everybody waits for.

**NADIA**  [05:02]
Collect views on sticky notes before anybody speaks. Positions then exist before the senior one does, and you will be astonished what people write down that they would never have said after the director spoke.


`[CUE 3]` *Sticky notes collected before the senior voice speaks.*

**AMARA**  [05:16]
And the person who takes everything into the weeds?

**NADIA**  [05:20]
The parking lot, used kindly and relentlessly. That is important and it is not this decision, it goes on the wall, and it does go on the wall, because a parking lot that loses things stops working in one meeting.

**AMARA**  [05:36]
You said data tests what people tell me.

**NADIA**  [05:39]
Interviews tell you what people believe happens. Data tells you what happens. The gap between them is usually your finding.


`[CUE 4]` *Belief beside data: rare exceptions at a third, one day approval at nine.*

**AMARA**  [05:47]
Example.

**NADIA**  [05:47]
The team tells you exceptions are rare. The data says a third of cases take the exception path. The map says approval takes a day; the timestamps say nine. Everybody blames the old system; the queue is actually in front of one person who checks everything by hand.

**AMARA**  [06:06]
Do I need proper tooling for that?

**NADIA**  [06:09]
Counts, dates and durations in a spreadsheet answer most analysis questions ever asked. What did people actually do, how often, how long, where did it wait.


`[CUE 5]` *A date field that is always Friday, unmasked as a batch job.*

**AMARA**  [06:20]
Can I trust the data?

**NADIA**  [06:22]
Check its honesty first. Mandatory fields get filled with rubbish to pass validation. And a date that is always a Friday is a batch job, not a fact about the world.

**AMARA**  [06:34]
How do I report so it gets acted on?

**NADIA**  [06:38]
Three findings, each one a sentence somebody can act on, with what it costs today and what changes if fixed. Evidence attached, method in an appendix for the one person who wants it. A forty page document is where analysis goes to be filed.


`[CUE 6]` *Three actionable findings, and the workaround reappearing in week three.*

**AMARA**  [06:55]
And then I move to the next project.

**NADIA**  [06:58]
And then the change fails, and the analysis failed with it, whatever the document said. Stay for the landing.

**AMARA**  [07:06]
What does staying look like?

**NADIA**  [07:08]
The people whose workaround you removed built it for a reason. Involve them in what replaces it, or they will rebuild it in a new spreadsheet within a month. And watch the first weeks in the data you already have.

**AMARA**  [07:24]
Looking for what?

**NADIA**  [07:25]
The workaround reappearing in the numbers. If the exception path was a third of cases and the new process pretends it is rare, you will see it in the data before anybody says a word to you.

### Sources for the on screen credit

- BCS business analysis body of knowledge, BCS, The Chartered Institute for IT
- Facilitation practice, International Association of Facilitators
- Process mining and data driven analysis literature, Business process research

---

*Copyright WAJD Group. Built by WAJD AI.*