How we see a subject depends on our perspective. Inevitably, our own experience takes precedence when we discuss any activity that we’ve personally engaged in. My experience of roller blading, travelling to Iceland, or bringing up children, may be nothing like yours when I tell the story. And it is to be expected.
Being able to rely on multiple perspectives, then, allows us a more rounded view, as if looking through an eye of a dragonfly. The anecdotes of others, rather than our own, emphasize the variety of personalities, situations, and cultures that a single person will never have opportunity to be exposed to.
This is the perspective that coaching others can give us. My experience of coaching business analysts gave me insights into different perceptions, attitudes and expectations about the profession that I would not come up with on my own. Now, I want to share some of these insights with you.
This first coaching story relates to a pattern that I’ve seen too often to ignore. Sometimes we role-play stakeholder interviews and asking questions during the initial discovery and requirements analysis. As I play the role of a client, my coachees would regularly ask me a variation of “So tell me how you want to do this”:
“So how do you want to enter this information?”
“How do you want to let the customer know?”
“Do you want to add this as a new field to the table?”
“How do you want the system to send this information to the supplier?”
“How do you want to change this form?”
When questions of this type are asked during the initial discovery of requirements, they carry a high risk. Rather than an innocent slip of the tongue, they indicate a belief that a business analyst’s main responsibility is to document what they are told.
The analyst is assuming that the client already knows what they want to change and how, and all that is left is to write it down.
It’s true that sometimes your clients may think they know what they want. Too frequently though, their idea about the solution to their problem is limited by their understanding of the system, interest in specific use cases, or sensitivity to particular pain points. Someone has to analyze the real problem that is causing the pain points and understand what the real need is. Otherwise, we may fix one issue and create another one, possibly with a higher impact.
Understanding of the real problem and what needs to be achieved comes first. Then, the best solution can be designed. The solution may be quite different from what the client visualized, and that is why we want software engineers and architects to design software solutions.
The best solution may be to solve the customer problem proactively, instead of notifying the customers and waiting for their instructions. The best solution may be to get rid of the form altogether rather then making it more cumbersome, and find a different source of information.
Of course, you never want to be rude. Listen to the client’s ideas and suggestions and suggest that you will bring them up during the design discussion. But your questions must be focussed on understanding the problem, not on encouraging the customer to engage in “solutioning”.
It is business analyst’s job to:
- Listen to the client
- Ask the right questions
- Understand the business problem
- Articulate this business problem to the partners who are responsible for designing the solutions
- Make sure everyone has the same understanding of business requirements
Ask “What”, not “How”.
Ask “What do you need to achieve”, not “How do you want to do it”.
Requirements do not come from business. Requirements come from business analysis.
Contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function. Explore the #ba_mindset in books, videos, or courses.