Recording script
Business analysis: the problem behind the request
- 2modules
- 1151words
- 8minutes when read
- 2voices
How to record this
Amara is the host. Curious, a little sceptical, asks the question the learner is actually thinking, and pushes back when something sounds unrealistic on a short staffed shift.
Nadia is the practice educator. Warm, direct, never condescending. Answers the awkward question rather than deflecting it.
Leave a beat of silence between speakers rather than overlapping. Timestamps assume 150 words per minute, which is a natural teaching pace. Cue numbers mark where each on screen graphic should land.
Wording that must not be upgraded
planned The CPD Certification Service
Application scheduled.
Do not promote any of these words in a video title, description or thumbnail. Aligned is not accredited, and planned is not approved.
1. Finding the problem behind the request
About 4 minutes, 615 words. Starts at 00:00 in the full course recording.
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
2. Workshops, data and landing the change
About 4 minutes, 536 words. Starts at 04:06 in the full course recording.
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