Another Use For ‘Why?’

Man Asking Why

Why?” The question is our inspiration and our muse. “Why?” is the justification for our requirements. The key to identifying “What?” and “When?”, which lead to “How?” and “How Much?” But there is another use for “Why?” – communication of intent (with stakeholders and implementers). Requirements documents are artifacts, but they are also dynamic documents. By documenting “Why?” a requirement is a requirement, we make it easier for future readers to understand.

Meeting Debriefing

I was observing a meeting earlier this week where a member of my team was reviewing a “finalized” requirements document. The requirements in that document were gathered previously, and validated for both correctness and completeness. This review, another step in the elicitation process, involved stakeholders who were not involved in previous sessions. The meeting was not an efficient one.

Inefficiency

Over the course of two hours, the team reviewed and discussed no more than ten requirements. The project is a migration project from a legacy system to a new solution. There are minimal process changes in this phase of the project (and therefore the review is looking minimally at process re-engineering).

The following are some of the questions asked by participants in the review:

  • What is the difference between those two [variations of] start dates?
  • Why do we need that information in the system?
  • Why can’t we simplify X to Y?

The answers to these questions (each was asked multiple times about most of the requirements that were reviewed) generally involved relatively detailed explanations, hypothetical examples, and occasional diagramming of business object relationships to effectively communicate why the existing requirements had been written, and why they had been written in the way they had been written.

Perception

At the end of the meeting, one of the project sponsors expressed concern that a “final review” meeting was so ad-hoc and disorganized. Our sponsor now has a fear that requirements are being missed, or documented incorrectly.

Anecdotally, there were no significant changes to those requirements as of the end of the meeting. Why did we have to spend 20 man-hours to make no perceptable changes?

Because we didn’t document the answers to these questions the first time!

Document Creation

The creation of, and initial validation of the requirements document involved interviews, contextual inquiries, and side-by-side comparisons and gap-analysis with existing process documentation. The resulting requirements were documented.

All of the questions that were raised in this meeting had been raised in previous sessions. None of the answers had been included in the documentation. And the overall project is large enough, and complex enough that people inconsistently remembered or completely forgot the justifications for the requirements.

Documenting Why

Including the justifications, scenarios or examples, snippets of business object models, and other supporting information would have prevented much of the debate. If we had included the underlying “Why” data that drove the “What” data (the requirements) in our documentation, we would have avoided rehashing these same issues.

It isn’t enough to ask why during elicitation – we have to document the justifications along with the requirements.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

5 thoughts on “Another Use For ‘Why?’

  1. I agree that providing context and justifications in requirements documents is a good practice. However, the experience you describe makes me think there was a much more serious problem.

    Requirements are the why in a sense, as they do nothing more than restate the problem to solve in verifiable terms. If the reviewers were having so much trouble understanding the “why”, it’s mostly likely because the specifications were so far removed from the problems that they weren’t requirements.

    Problem: It takes the average user more than five minutes to place an order.
    Requirement: It shall take no more than five minutes for the average user to place an order.

    Sure, it’s helpful to explain that users are frustrated by the amount of time it takes, and that this frustration leads to negative word of mouth, which leads to lower sales, which leads to lower revenue. But I think most reviewers are going to be able to grasp the importance of the requirement without such explanation in this case, because the requirement itself essentially “explains” the problem.

  2. Hey Roger, thanks for commenting and reading – as always!

    Let me rephrase the premise, so that this particular thread doesn’t become a debate about “what is a requirement.”

    First, this is not a product management project, it is a software deployment project – put on a business analyst hat for a moment…

    This is the definition of more detailed elements of a migration project from a legacy system to a new system. We have already identified the goals / requirements (such as “User must place order in under five minutes.” We are now dealing with the next level of detail (e.g. defining what is required – from a business perspective – to place an order). Here are some examples that might explain better.

    Given a business process of “user can place an order”, we are defining the following level of detail:

    1. User will be able to identify the product to be ordered.
    2. User will be able to identify the desired delivery date.
    3. System will prevent the order if the user is not on the ‘bad credit risk’ list
    4. System will confirm that the product can be shipped by the desired delivery date

    The point is that in the documentation of this level of detail, which does have to happen at some point in the software development / deployment process, it is important to document the “why” of the particular pieces of information.

    Picking one example – we choose to prevent the order for ‘bad credit risk’ users, because the business believes that this strategy will increase bottom line profits by reducing ‘bad credit’ write-offs.

    Scott

  3. At our company, we’ve tried using a very condensed requirement format as described by Mike Cohn in “Agile Planning and Estimating”.

    As a >, I want > so that >.

    The last part, the business value that the capability is providing, answers the “why” question in our requirements documentation. Combine that with the “who” and the “what” in the first half of the sentence, and you get a very powerful requirement format that imparts all of the necessary information to business users and the development staff alike.

    Using your bad credit example, we would re-write that requirement something like this:

    “As a retailer, I want to prevent the order from completing if the user is not on the ‘bad credit risk’ list so that we can increase bottom line profits by reducing write offs.”

    We’ve been able to share requirements amongs many different stakeholders using this format without needing any extra translation steps.

  4. Oops, server couldn’t handle my brackets. Here’s that story format again:

    “As a {type of user}, I want {capability} so that {business value}.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.