Why understanding what you REALLY need is important to finding the right solution.
In his Hitchhiker’s Guide to the Galaxy series of sci fi books, Douglas Adams pokes fun at man’s need to define a purpose for our existence. He spins a tale of the computer Deep Thought which an advanced civilization creates so that it can calculate the answer to “Life, the Universe, and, you know, Everything…” When turned on, Deep Thought announces that it will take thousands of generations to process the question. This, of course, disappoints the machine’s creators, but they resign themselves to leave the answer to their descendants. Many generations later, at a lavish ceremony, the computer declares that the answer they are looking for is “42”. When the crowds that have gathered for the unveiling protest that they don’t understand, Deep Thought reminds them that perhaps their problem is that they don’t really understand the question.
The lesson here, as I see it, is that asking for something isn’t enough. You have to really, REALLY understand what it is you are asking for.
This requires certain questions to be asked. On a project, this is the requirements gathering and analysis phase. It can start with asking about What it is that we think we need. We’re just gathering information at this point. The hardest part about this is making sure that we ask this question of all of the stakeholders.
Most people think they know what they need. We can’t just take the answers to this question at face value and call it a day, however. People have conflicting needs. They interpret their own needs differently. Often times, they don’t truly understand their own needs (even though they may think they do).
So, the next step is to challenge the group’s understanding of their own need by asking Why they need what they said they did. The answers to this question can range from “I don’t know”, to “That’s just how we’ve always done things”, to “There’s a very specific reason for that, here’s what that is…”
We aren’t just gathering information anymore. Now we’re starting to get our group to really think about something they took for granted. And as we do that, both we and they are gaining a better understanding about what is truly needed. The two-way street of requirements gathering begins here; by asking people to explain their need we are also asking them to start to analyze it themselves.
This part can go on for quite a while. I counsel my clients to repeat this part as if they were a five year old child. Keep asking Why until you’re satisfied with the answer or have exhausted the knowledge of the person you’re talking to. In the latter case, move on to someone else and keep asking Why. This way we get to the root issue behind our need, which is where the lines between requirements gathering and business analysis start to blur.
Next, we can ask How else their need could be satisfied. This is where we start to actively change the perception of an individual’s need. We may offer alternatives. We may suggest a new product that just came on the market that satisfies everyone’s Why criteria. People start to evaluate their own assumptions, and we engage them in thinking about how they could be doing something differently. In this way, we shift the paradigm from “doing something” to “doing something better than we are now”.
The key here really is the unwavering curiosity of the second step. All too often I see analysts asking users What they need and developers figuring out How make that happen. Without asking Why, we’re not really getting to the root of the issue, we haven’t bridged the gap between the need and solution.
Asking Why allows for the discussion and evaluation that is needed for innovation, and it is essential to truly understand what we’re asking for.
Have you asked yourself Why you are working towards your goal? You can reflect on your Why’s at www.MeetMaple.com.
R. Alliance, LLC 