“Curiosity is different from intelligence or creativity or even from leadership. Not everyone has those qualities, but everyone can be as curious as they want to be, and it doesn’t matter when you start. Furthermore, your curiosity can help you be smarter and more creative, it can help you be more effective and also help you be a better person.”
– Brian Grazer, A Curious Mind: The Secret to a Bigger Life

Last fall, I spoke at BA World in Chicago and today I want to share some ideas from that presentation, “Curiosity Never Killed the Business Analyst,” with you. This topic is worth discussing because it forces us to look at project success in a different way. And it prevents us from becoming an order taker instead of a true business analyst.

What’s Wrong With Being an Order Taker?

While meeting expectations for the timeline and cost are important, the project can still be considered a failure months and years after that on-time, on-budget delivery. Why? Because we didn’t explore enough to fully understand what the client needed versus what they told us they wanted. This happens when a BA becomes what I call an “order taker.” They listen to everything the stakeholders want and they deliver exactly that. Unfortunately, later, they all discover that what was built does not really improve the process, or grow overall business, for the client. It is a failure because although it is exactly what the client asked for, it is left unused. A curious analyst would start by asking, does this really happen that often? Or why do you think you need that? Unfortunately, Standish Group’s Chaos Report reveals that 65% of features are rarely or never used. Even worse, Joel on Software suggests that 80% of users only use 20% of the features available to them. A curious analyst would ask, how does this happen? Well, I’ve got some bad news. It’s not them. It’s us.

As analysts, we are not brought in to automate a broken process. We are brought in to analyze and build solutions that solve problems. We need to ask questions, raise concerns, and offer alternatives. Simply noting down the processes already in use and turning them back around to the business is not helpful. But yet, this is what we see time and time again, even with experienced analysts. They lack the curiosity to challenge the stakeholder, to truly analyze the data and to find a better way. We call the process “requirements elicitation” because we need to pull the information out of people’s minds and the documentation around us. We must dig deeper to find the really interesting, meaty information, not settle with the evidence lying at the surface.

How can we be More Curious?

Ask Smart Questions.

We can start by asking smart questions. Probe. Brainstorm. Research. See what other people think or what other organizations are doing to solve similar challenges. Smart questions are open-ended. They tend to start with words like how, what, could or would. They don’t have a yes/no answer. The smartest question is Why? Why? Why? Then you listen and ask and listen and ask until they really tell you the whole story.

You should also probe for exceptions and complaints. Exceptions include those times when the system behavior doesn’t follow the “happy path” and could be uncovered with questions like: “What might prevent a user from successfully completing a task?” or “How should the system treat various error conditions?” Complaints about the existing system can include issues like “the system crashes all the time” or “I have to click so many times to do x.” When these are heard you should ask more questions to dig into those issues. You may hear about things like stability, response times, ease of learning and speed for experts.

We like to prepare some questions ahead of time. Coming with a list is a great starting point, but don’t be afraid to deviate from the script.

A great starting point once you’ve identified a problem to solve is utilizing the Sandler Pain Funnel. We trained our entire team in the Sandler Sales Process years ago because we found that the questions really helped get at the root of the problem, understand how big/impactful the problem really is and what has already been done to try and solve the problem. Some of these questions include “Can you be more specific? Give me an example.” or “What have you tried to do about that? And did that work?”

Also, and I’m sorry to say this, but there are dumb questions. Unfortunately, though, we need those answers to do our job well. So ask your dumb questions anyway, but feel free to hedge them in a way that provides a reason for why you can’t remember something or adds some humor to the conversation. Something like, “I’m probably supposed to know this and I’m going to feel stupid when you tell me the answer, but what does CYA mean?”

Stop Being Afraid.

Don’t let your fear of appearing dumb get in the way of getting the information you need. In fact, according to a Harvard Business Review article “The Business Case for Curiosity,” we demonstrate our curiosity by asking questions and as it turns out, people like us more and view us as more competent when we do ask questions.

And while we are talking about not being afraid…Dare to disagree. In one of her TED talks, Margaret Heffernan discusses the challenge most organizations face. It is the struggle to think. It’s not that they don’t want to, they just can’t because the people inside of them are too afraid of conflict. The fact is that most of the biggest catastrophes that we’ve witnessed rarely come from information that is secret or hidden. It comes from information that is freely available and out there, but that we are willfully blind to because we can’t handle, don’t want to handle, the conflict that is provoke. But the truth is, conflict leads to creativity because it allow others to also share their concerns and gets the entire group thinking about new solutions.

Have More Conversations, But Don’t Stop There.

Too often we see BAs utilizing just one method for elicitation…and that is interviews. Of course these are extremely important, but there are many other avenues to elicit requirements. Consider these other options:

• Surveys/questionnaires
• Observations of users to analyze their current behavior
• Prototyping
• System Interface Analysis (both system and user)
• Competitor online analysis
• Focus groups
• Facilitated sessions

Next Up…Utilizing Models

Let me know if you have questions about any of the above as I can go in to great detail if need be. And I can’t fit all of my presentation into one post so next time I’ll write on the importance of utilizing models. Requirements models provide confidence that no requirements were missing, lead to asking the right questions and are easy to read by all audiences. So I’ll show you how we do that and provide a few more tips for improving your curiosity in the next blog!