The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

(adapted from More about Software Requirements by Karl Wiegers)

“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected.

The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than why and means essentially the same thing, but it has a more collaborative feel to it.

When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information:

• The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
• Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is true. It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
• Asking why can reveal implicit requirements that no one thought to mention yet.
• The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
• Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
• Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
• Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.

Asking why might save you a lot of work. One project was replacing an existing customer relationship management (CRM) system with a package solution. Senior management directed the team to use out-of-the-box features from the package as much as possible and to limit the extent of configuration or changes to the package. One user representative asked that a specific function be added, a counter that indicated how many times a customer had used a certain product feature. It would have cost a significant amount to modify the core package to accommodate this requirement.

When the BA asked why that function was needed, the user said that the function was present in the current CRM application. The BA probed further: “What exactly does this counter show?” “Why do you check it?” “What action do you take depending on what it tells you?” This discussion eventually revealed that several stakeholders all thought that someone else was using the data. In reality, no one used it at all! By asking “why” a few times, the BA and user representative agreed that the function wasn’t needed, thereby saving a significant amount of money.

A BA needs to be a bit of a skeptic. Don’t believe everything you hear, and don’t accept it all at face value. Ask “why” enough times to give you confidence that you’ve got the real requirements in hand.