Finding the problem behind the request

Amara A stakeholder asked me for a dropdown. I built the dropdown. They are still unhappy.

Nadia Because a dropdown was never the requirement. It was their guess at a fix for a problem they never told you about.

Amara They seemed very clear about what they wanted.

Nadia 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 So what should I have asked?

Nadia 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 Walk me through it with the dropdown.

Nadia 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 So the requirement is about the report, not the screen.

Nadia 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.

Amara That last one is much better and nobody would have asked for it.

Nadia 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 Which is?

Nadia 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 How should I write it up?

Nadia 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 And the better version?

Nadia 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 What about acceptance criteria?

Nadia 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.

Amara Process mapping. People tell me the process and then do something different.

Nadia 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 Is that just people cutting corners?

Nadia 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 How do I find them?

Nadia 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 There is always a spreadsheet.

Nadia 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 Last thing. Two stakeholders want opposite things.

Nadia Do not average them, because the midpoint usually serves neither. Go back to the problem behind each request first.

Amara And if they still conflict?

Nadia 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.