THE WHY
When reviewing business processes, it is common for consultants and business analysts to ask the all-time favorite “why” question, along with follow up questions to further delve into a topic. Many educational resources explain this method, and how to effectively utilize it. This process is intrinsic to learning about the company’s needs and how end users carry out their duties. This is a process I myself have carried out with dozens of clients. Asking the “why” question helps give us outsiders an inner view to the organization’s work. It helps identify gaps in the system or redundant efforts and provide areas of improvement.
Obtaining a solid business and tactical understanding of the business is important to create efficient solutions. Knowing why a company operates in a certain manner is crucial to then translate their needs to technology. Oftentimes, delving into a said process reveals redundant tasks, obsolete processes, and archaic procedures. A telling point is when the user is unable to explain why a task is necessary, or how it enables them to better carry out their role. More than once, an end user described a tedious process to me, and we broke it down together. Further examination revealed that this process was originally created due to their limited tools/technology, and was actually no longer needed. Without this business review, we would not be able to improve the person’s role. Other times, processes are in place due to change management deficiencies or a user’s resistance to change. It is common for someone to tell me they are doing something because that is what their predecessor did, and the person before them as well. Cue the use of rolodexes and sticky notes.
CHALLENGING THE WHY
Recently, I read an article which challenged the use of the “why”. While I unfortunately cannot find the article to link, the premise was important and resonated with me. Allow me to indulge in paraphrasing some of the key points, along with my own thoughts.
The author opined that asking the “why” question might not be the best approach to take. Firstly, the question can come across as challenging the other and therefore the respondent might get defensive or feel that you are questioning their abilities. This is particularly significant when the participant isn’t fully aware of the need for each step of their duties and is simply carrying out tasks prescribed to them. As a result, they might hesitate to fully share their experiences and omit significant information.
Furthermore, asking “why” leads people to focus on their step-by-step procedures in place of the larger picture. While you might emerge with a functional understanding of their operations, you risk missing the business needs and results of said task. For example, a user might detail the steps they take to reach out to a client, record the conversation, and sell a product. However, since it is “why” (procedural) oriented, this approach doesn’t consider the larger goal of upselling X type of client on Y product. Even if this result is brought up in the discussion, it is likely as a singular statement, without context to the full business results of the upsell efforts. Ultimately, a business is driven by metrics and goals they want to reach. There is a performance result they are targeting, and it important to keep that on the forefront when gathering requirements.
THE HOW
Instead, suggests the author, ask “how”. This is a less confrontational approach and will still provide you with the information you need. “How do you do that”, “how do you carry that out?”, “how does that happen?” are all questions that will help with the procedural side of the conversation. It doesn’t require the user to know the reasoning behind what they do, and provides more context to the purpose of said process. Using the example above, we might ask the user “how do you upsell?”. This in turn would shed light on the target audience and product and lead to a discussion of the business objectives.
On a more significant level, reframing the discussion with “how” questions enables you to delve into the company’s goals and metrics. Transitioning or optimizing a company’s technology should not be a lateral move from system A to B. It should be a time to re-design their processes with business metrics in mind. Constantly ask yourself “how does this fit into their operations?”, “how does this enable them to set/meet goals?”, “how does this optimize the user’s time and skill?”. These are important gain a holistic understanding of the business and its drivers.
Consultants are trusted for their experience is business analysis and solution design. While the “why” method has proven useful, it may be appropriate to consider other approached to requirements and needs gathering that further the company’s goals and mission.