Why should Business Analysts ask their users “WHY?”​ more?

Let me start with a story.

Another ordinary morning ….

A bustling IT department full of energetic people — in some corners, people have gathered around the Scrum wall to have their daily huddle. Some other teams seem to have finished their huddles and have already started ‘pairing’ to get that pull request reviewed or to complete the next code change. Still, others seem to have gone into their ‘quiet time’ — all you can hear around them is the faint sound of music that has managed to escape the headphones they are wearing, and the noise of the keyboard strokes they are frantically typing.

Emanuel, a team member from the collections department, walks down the aisle towards the team that looks after customer eCommerce integrations, with a worried face; it seems like he has a problem. He approaches Naomi, the business analyst, and starts to speak.

“Hey, Nao, good morning! How are you doing?”

“Hi, Emanuel, morning! Yeah I’m good, and you?”

“Um, I wish I could say good … but we have a small problem!”

“Ah, a problem — fill me in!”

“We have a collection issue with one of our customers and we need to resolve this urgently. We send our invoices as email attachments at the moment, so they take forever to key that information into their system. Can we find out the best way to integrate our invoices with their system so they can get them in without having to type the information themselves?”

Let’s pause here for a moment …

This is a typical situation faced by business analysts — i.e. users approaching them with a business problem they are facing and expecting to have it resolved immediately.

There are two ways this conversation can progress from this point on. Let’s have a look at them.

As Emanuel has diagnosed it, Naomi associates the ‘problem’ (of late payment by the customer) with the time it takes the customer to key in the invoice manually into their system.

She gets into her deep-thinking stance for a moment and starts to respond:

“Um … Okay, let me double-check what you just told me, Emanuel … So this customer currently receives our invoices manually, and this leads to delays in entering them into their system — and that leads to them paying those invoices late?”

“Yeah, that’s correct!”

“Okay, what sort of integration are they looking at? Do you know someone I could contact to get more details about their system? Ah, and how urgent is this to you guys? Remember we have this other project we are currently working on — that’s pretty urgent too!”

“It’s pretty bad right now, Naomi. They are almost 90 days behind their last invoice, and this has been going on for quite some time now. They are one of our biggest customers. We are missing out on our cash flow!”

“Hmm, I see. I’ll talk to the customer and to my developers to figure out the best way forward. I’ll let you know if I need anything else. Our product owner will get back to you with more details and the priority.”

“Thank you, Nao … you are the best!”

Second response

This time around, Naomi wants to explore a bit more the circumstances of what Emanuel has raised with her. She knows that the invoice is the last step in the customer-order-processing life cycle. She also doesn’t want to jump into ‘solution mode’ based on limited information. Therefore, she decides to backtrack step by step with a series of questions — questions that start with ‘why?’.

“Okay, Emmanuel, so why do you think integrating our invoices with the customer’s system will solve the problem?”

“Um … I think if invoices are in their system sooner rather than later, they’ll be able to identify errors quickly. Their account department can’t reconcile invoices unless they are in their system. They need to match the purchase order number in our invoice with the actual order they created in their system. And they only pay when they successfully match them.”

“Ah … so these errors on our invoices, why do you think they exist?”

“Sometimes it could be due to mistakes they make at the time of keying in the invoice … But most of the errors occur at the time of creating the sales order at our end. We capture the purchase order number their system generates. The number is long and can easily end up with a couple of wrong digits.”

“Is that all?”

“Well, their purchase order total can be different from the total of the order we create at our end, which means the invoice will not match with their order.”

“I see. But why do we need to capture their purchase order number and why are the prices incorrect?”

“Ah, that’s because they pay by the purchase order. They need their own order number in the invoice so they can match it … Product details can be wrong, as they use an offline product catalogue to browse our products and those details are sometimes out of date.”

“I see … it sounds like the problem may not be with the manual invoice key in, Emanuel, but happening at the time of placing the order. There seem to be two problems we need to address — one, how to ensure that we capture their order number correctly, and two, how to ensure that their system has up-to-date product information … Let me organise a discovery session with my team and yours early next week. We can go through all this in a bit more detail. I’ll have a chat to the branch boys to get more of an idea of what happens with the ordering process too … We can decide how best to take this forward from there.”

“Cool, great, looking forward to it! Thanks, Nao!”

What do you think was different between Naomi’s first and second responses to Emanuel?

The first response was a closed-ended and one-dimensional conversation between the user and the business analyst. Naomi straightaway assumed that the problem was as described — i.e. with the way customers received invoices — and so her line of questioning was to explore more details about that particular situation. Although this clearly made Emmanuel feel comfortable and confident about the issue he was raising, the lack of questions from Naomi to explore the reasons behind each ‘symptom’ along the process prevented her from exposing the real business problem.

The second response Naomi had was a much broader one. Rather than getting trapped within the specific problem Emanuel had raised, she started backtracking one step at a time, exploring more details on the periphery. This led her to uncover a chain of business problems that existed well before the problem Emanuel had mentioned at the start. Identifying the problem that exists at the very beginning of any process (also known as the ‘root cause’) gives us the opportunity to provide solutions that are more effective and comparatively inexpensive to implement.

The power of ‘WHY?’

Every effect has a cause. We’ve given this phenomenon a fancy title — the cause-effect relationship. This simple relationship is what we need to explore in order to get to the real issue our users face.

Let’s apply this to the situation presented in the story.

The questions Naomi asked that started with ‘why’ enabled her to identify the root cause of the symptom Emanuel was explaining. As business analysts, we all must learn to ask questions of our users to ensure we see through their own perception of the problem and, more importantly, the solution they think is the ‘silver bullet’. It is our responsibility to explore all the aspects of the problem, how they interrelate, and the potential impact a solution delivered to fix a problem in one area might have on another area.

The ‘why’ doesn’t have to be limited to users. The same is applicable to your delivery team as well. The solution architecture they propose, the time they estimate, the tech stack they plan to utilise all need to be equally validated, and there is no better way than asking ‘why’.

For example:

• “Why do you guys think this solution architecture is the most suitable for the problem?”
• “Why have we decided the complexity of the solution to be this size and time requirements to be this long, when we know this story is very similar to what we delivered last sprint?”
• “Why did you guys decide on that tech stack as the best one for this story?”

Empathise with the user while asking ‘Why’

Asking ‘why’ makes users think outside the framework they have already put themselves in. It forces them to dive deep into their mind and start identifying actual ‘needs’ disguised within the noise created by ‘wants’. This could irritate users as it forces them to spend more effort; it pushes them out of their comfort zone.

• Be aware of the user’s emotions and how he/she might feel when presented with many questions, especially around a challenging situation.
• Ensure you don’t come across as a condescending person with the words and tone you use.
• Ensure you leave sufficient space between questions for the user to formulate his/her thought process and respond.
• Accept that you might not get all the answers immediately. Let them know that they can get back to you later.
• Use visual tools — grab a whiteboard or a piece of paper and draw simple diagrams to validate that what you have in your mind is in fact what the user has in his/her mind. This will probably make the user comfortable enough to contribute to what you have sketched, reducing ambiguity in the message passed across.

“A picture paints a thousand words!”

Conclusion

A business analyst is the conduit between the user and the delivery team. Understanding ‘why’ users face the problem they say they do, ‘why’ your team want to deliver the solution in the way they think is right, and ensuring each party understands the reasons for the actions of the other party is pivotal to the success of the project and ultimately to making users happy.

Asking ‘why’ doesn’t come naturally to most of us, at least not since childhood. When we were growing up we were often told by our parents and teachers that asking ‘why’ was rude. This led us to be wary of asking this important question even though in most cases we know it will probably provide more clarity to the situation we are currently in and will provide the context we need to understand it better.

Let’s ask ‘why’ more often!