Tag: Elicitation

Growing Pains – Requirements vs. Designs

Written by Bill Baxter on January 30, 2019. Posted in Articles.

I think that the requirements elicitation aspect of Business Analysis is in many respects experiencing growing pains.

I’ve tried to capture a technique that I apply when I’m feeling the ache – hopefully there’s something in it for you.

Consider; you walk into a restaurant and say, “I’m hungry”. In response, you’re asked to choose the condiments you want on your sandwich. There have been a bunch of assumptions made about what would solve your “hungry” problem… and that “hungry” is your actual problem. It’s possible that a sandwich is the right solution, but it’s just as possible that it isn’t too.

Alternatively, you walk into a restaurant say, “I’m hungry”. In response, you’re asked whether you want to eat with your hands or cutlery, whether you’d like to sit down to eat or eat on the go, whether you have any food sensitivities or allergies, and whether you’d had enough water to drink today. Your answers help guide what you’re served – while the solution may still end up being a sandwich, whatever you end up eating is more likely to satisfy you.

Food service has been around a long time, and restaurants have refined their requirements process a great deal. There are signs out front to provide a cue as what kind of restaurant it is, menus to describe what’s on offer and help address potential dietary restrictions. The questions people expect to be asked, the questions that either have implied answers or can be safely assumed and relevant terminology are all widely understood. Questions regarding what you should eat (or not eat) are typically avoided altogether. While these kinds of things optimize the interaction and reduce the time it takes to provide service, it doesn’t mean that the differences between requirements and design aren’t being respected – the relationship between them is just so intuitive now that it all seems like one thing.

Maturing service areas – like technology – don’t offer the same refinement as mature service areas. Very similar concepts can have very different names, and very similar names can represent very different concepts. The risk of misunderstanding and of problems common to different areas in an organization receiving independent treatment is much higher. There are opportunities to mitigate these risks every time a team is formed by sorting out the language used to describe concepts everyone understands but may label differently.

A distinction I feel is particularly important is between “requirements” and “designs”. I like to distinguish between these concepts like this:

Information that describes the capabilities needed to solve a problem are “requirements” (what you need)
Information that describes the characteristics of whichever solution has been selected to meet the requirements are “designs” (how you’ll deliver what’s needed).

In many cases, people want to leap-frog over the “what” and focus on “how”, and I can empathize. “How” is more fun – it’s often more tangible and easier to envision. It does, however, reduce the opportunity to consider alternatives to the way a single person (or a small number of people) have envisioned it. As with the sandwich, the best solution may end up being the one that was originally envisioned – exploring options helps build understanding and consensus – a good thing for any team.

I’ve heard several different ways to describe what I call “designs” here, usually as requirement (system requirement, solution requirement, technical requirement, etc.). I’m not suggesting that this is wrong per se, but I am suggesting that blending everything under the “requirements” label can make it trickier to keep stakeholders focused on what they need vs. how they envision the solution.

The challenge in maintaining focus comes from an honest place – business stakeholders are often “restaurant owners” (in keeping with the analogy) – they are experts in the area. They live and breathe it and have become so immersed in their knowledge that they view it as a single thing. It’s the rest of a project team that benefits most from distinguishing between requirements and designs initially, although some stakeholders may suffer from “that’s-the-way-it-has-always-been” syndrome – asking them to clarify why things are important to them can lead to some interesting discoveries.

The single biggest obstacle to decoupling requirements from designs is not that people don’t understand the difference – it’s the time it can take to sort information in this way. If commitments have been made (to delivery dates, vendors, resource managers etc.) around a specific outcome before any requirements were gathered, it can be difficult to get back to it.

In some cases this discussion may be easy –any assumptions or conclusions your business experts have made independently can often be readily explained and if there is clarity with respect to the problem that needs to be solved and the capabilities that will help solve it – whether “requirements” have been formally gathered or not – the team can proceed.

In other cases, the discussion may not be as easy. I’d suggest that the time it’d take to make sure people are clear on the “what” and “why” will be a fraction of the time the team will experience in delays and other waste if they proceed to discussing “how” without this understanding – even the most delicious, perfect sandwich in the history of sandwiches crafted with the utmost care and attention to detail will go in the bin if the customer is allergic to bread.

You Are Not Asking Enough Questions

Written by John Vaught on January 30, 2019. Posted in Articles. 1 Comment on You Are Not Asking Enough Questions

If you have kids, when they were around 4 years old you were subjected to them asking a single question that they would keep asking over and over till it would drive you crazy.

One study found that they average about 73 questions per day. What is the main question they ask? You know the answer to this one:

WHY?

Why is the sky blue? Where did I come from? Where did the moon go? Why are those animals wrestling? “That’s a good question to ask your mom, kiddo.”

And the Why’s usually doesn’t stop with the first answer, does it? You might think you gave them a great response, but as soon as they ask it for the second, or third, or fourth time, it gets frustrating:

It doesn’t seem like their questions are ever going to end (hiding doesn’t work, you’ve tried it); and
It is frustrating how quickly you run out of good answers.

But in reality, the last thing we really want to do is to stop kids from asking questions. It’s a fundamental way they learn and develop. Maybe one of the reasons why our own development as adults slows down later in life is because we stop asking so many questions.

Are we telling our kids, consciously or subconsciously, to stop asking questions?

Now, there is a point later in life that kids start to ask questions again. Anyone have a teenager at home? If you are holding up your hand, let me comfort you with these words – this too shall pass.

For teens, the questions change from being about the world around them to directly about them. Why do I have to do chores? Why can’t I go out with my friends? The questions at this stage are less about how nature works and more about how you work. We get frustrated with these questions because it feels like they are challenging our authority.

But… maybe even these teen questions are good questions as well. Let’s turn it around for you – how well do you like it when someone at work tells you “Because I said so”? Friends, that’s not a good answer in the home or the workplace.

Are we telling our work staff, consciously or subconsciously, to stop asking questions?

Let’s just be honest – we sometimes get frustrated with coworkers asking questions, and probably for the very same reasons we lost our minds when our kids were doing it:

It seems like questions are taking the place of doing work; and
There may not be good answers for their questions.

I totally get #1. You can almost see the fear in people’s eyes when someone starts asking questions in a meeting, wondering if they are summoning the dreadful Analysis Paralysis, the dreaded gorgon that stops us in our tracks and wreaks havoc with our schedules.

But before we jump into action, let’s make sure we aren’t squashing the drive to ask questions. Because sometimes activity is just a way to mask the fact that we don’t have the answers; which gets us to point #2.

If we don’t have clarity around why we are asking someone to do something, then maybe that something doesn’t need to be done.

Here’s a scary equation that often drives people to squelch questions:

Time Cost of Asking Questions = Time Cost of Doing Something

It’s easy to look at that equation and go, “Oh my! We don’t have time for questions! Someone do something, for goodness sake!” But what we don’t think about is the huge costs of doing the wrong things that could have been saved with a small amount of questions:

Time Cost of Asking Questions < Time Cost of Doing the Wrong Thing + Time Cost of Rework

For some reason it is easy to think that asking questions is far less valuable than doing actions – even when we don’t know exactly why we are doing it! Activity does not equal value; creating artifacts or a product that no one really wants drives value down. in fact, asking people to think about what they are doing might be the most valuable thing you can do.

I’m encouraging you to bring out your inner 4-year-old and keep asking why – it may drive the people around you a little nuts but they may just end up thanking you in the end.

Business Analysts…Quit Asking Questions

Written by Aaron Whittenberger on January 22, 2019. Posted in Articles.

I won’t take full credit for this article, as I got a reminder while reading an IIBA Whitepaper authored by Kupe Kupersmith on Empathizing with the Real Customer.

In his whitepaper, Kupe proposes a few newer, non-traditional elicitation techniques, not covered in the BABOK®, business analysts should work into their BA toolkit…one of which is Story Prompts.

What Are Story Prompts?

Story Prompts is an elicitation technique used as an alternative to asking a series of clarifying questions or the 5-Why technique. Instead of questions, prompt your stakeholder to tell you a story about…

As a business analyst you are taught to ask a lot of questions; however, there is a time and place for asking a lot of questions and a time to listen to a story. There is a tendency for stakeholders to feel that you are controlling the conversation when you ask a series of questions; have them follow your train of thought. As an alternative, allow the stakeholder to tell their story in their words and in their train of thought. This may help you to better understand the needs, desires, pains and wants of your stakeholders.

In the whitepaper, Kupe sites the book Business Storytelling for Dummies by Lori L. Silverman and Karen Dietz, PhD:
“Story Prompts have two parts: the front end of the statement and the closing to the statement. The front end starts with a phrase such as, ‘Tell me about. . . ‘. With certain individuals, it may help to say, ‘Tell me about a time when. . .’, or “Tell me about an experience with…”. The word ‘about’ is key in this statement. If you leave it out, all you’re doing is turning a question into a statement (as in Tell me how you . . . or Tell me what you . . .).”

“The closing portion of a Story Prompt is as critical as the front piece of the statement. Avoid being general. Phrase it in such a way that the person recollects only one or a few memories. This will make it easier for the person to select a story to share with you. For example, instead of saying, “Tell me about that new project you’re working on”, rephrase it as “Tell me about an unforgettable situation that happened to you recently on that new project you’re working on.”

When to Use Story Prompts

There really isn’t a bad time to use Story Prompts. It may be most useful during the early stages of an initiative when definition around the true problem is still vague. Stakeholders may be discussing the solution rather than the problem we are trying to solve or the desired outcome. Then you may want to try “tell me about how you concluded we need that solution.” Or if no solution is being discussed yet, try “tell me about how this problem was identified.”

Making it Work

The key is to listen intently once you have prompted your stakeholder for their story. There are two things different about listening to stories and asking questions:

Focus on listening to the story, not taking notes. This may go against your natural instincts as a business analyst, but can you recall any great stories your grandmother told? Did you take detailed notes while she was telling her story? I am guessing not. It is amazing how much you remember by just sitting and listening to a story. You can write down detailed notes after the stakeholder has left.
Never interrupt. Again, this may go against your natural business analyst instincts; but let the stakeholder tell the story in their words, without interruption. If you are listening well you will remember the important details of the story. Later, you can determine any follow-up questions you want to ask and schedule a follow-up session with the person.

Conclusion

There is still a time and place for asking a series of questions or using the 5-Why technique. However, every once in a while, try prompting your stakeholder for their story instead of asking a lot of questions. It is a way to show the person that you value them and their point of view. Prompt your stakeholder to tell their story…hard telling what you may learn.

How To Get Requirements From Resistant SMEs Part 3

Written by Deena Chadwick on January 16, 2019. Posted in Articles.

Eliciting Requirements Like an FBI Agent.

Subject Matter Experts (SMEs) prefer conversation to interrogation.

Have you ever seen the cartoons that compare requirements gathering to torture? People are hesitant and even uncomfortable answering a series of direct question. The FBI and CIA gather almost all of their information without using interrogation techniques.

Like an FBI Agent

Common Sense tells us to listen to the experts. When it comes to getting information, the FBI tops the list. They train their agents how to gather information overtly and discretely. They also teach people, with classified or secret information, how to recognize when someone is trying to elicit information. Here are a few tips and tricks from that training.

Take Advantage of Natural Human Instincts

A good business analyst knows that people have certain natural instincts. Understanding these instincts can help you when eliciting requirements.

Natural tendencies include:

A desire to appear well informed, especially about our profession
A desire to feel appreciated and believe we are contributing to something important
A tendency to expand on a topic when given praise or encouragement; to show off
A tendency to correct others
A desire to convert someone to our opinion

Techniques Used By FBI Agents

There are many different techniques that can be used for elicitation and requirements gathering. Many can be used in tandem. Here are a few and their descriptions.

Assumed Knowledge: Using knowledge or associations in common with a person.

Bracketing: Provide a high and low estimate in order to entice a more specific number.

Can you top this? Tell an extreme story in hopes the person will want to top it.

Deliberate False Statements / Denial of the Obvious: Say something wrong in the hopes that the person will correct your statement with true information.

Feigned Ignorance: Pretend to be ignorant of a topic in order to exploit the person’s tendency to educate.

The Leading Question: Ask a question to which the answer is “yes” or “no,” but which contains at least one presumption.

Oblique Reference: Discuss one topic that may provide insight into a different topic.

Word Repetition: Repeat core words or concepts to encourage a person to expand on what he/she already said.

Identify When Someone Is Resisting

Every business analyst has experienced the brush off. It is easier to handle when it is obvious, but people are not always straightforward, sometimes it isn’t easy to recognize when someone is trying to avoid answering your questions or giving you information. If you experience any of these, you might be working with someone who is resistant to requirements gathering and elicitation.

Refer you to someone else or documentation
Ignore a question or statement you make
They responded with questions of their own
Give nondescript answers
Questioning why you are asking
Saying they aren’t sure if they should share or saying they cannot discuss
Saying they don’t have time…when you know they do

Common Sense tells us not to waste our time. Avoid SMEs who are not forthcoming with information, if you can. If that person is the only person, who has what you need, then get creative. I hope your inner child – Part 1, Maternal/paternal instincts – Part 2, or FBI training can help.

The Knowledge Awareness Matrix

Written by Larry Blankenship on January 15, 2019. Posted in Articles.

Most everyone has seen the Productivity Matrix with the following rows and columns:

	Urgent	Not Urgent
Important
Not Important

The idea is to focus most of our activity in the Important and Urgent quadrant. It’s critical to pay attention to Important but Not Urgent items so that they don’t suddenly become Urgent And Important. Avoiding putting effort into the other two quadrants is essential to productivity.

There’s a different type of matrix that can be used when gathering requirements. Use it to help identify information that might not otherwise have been discovered until the last minute or even after an application goes to production.

Murphy’s Law of Requirements: Unspoken requirements will always be revealed at the most inopportune time.

Think of it as a Knowledge Awareness Matrix. The intersections of knowledge and awareness show who is most affected, the Subject Matter Expert (SME) or the Business Analyst (BA). In all cases, it’s assumed the knowledge is needed in order to have a full picture of the requirements.

	Aware	Unaware
Know	SME	SME
Don’t Know	BA	BA

I got the idea for this from a Donald Rumsfeld comment while he was Secretary of Defense. “There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.”

PMI discusses this in terms of risk and refers to it with regards to evaluating risk. I use it when planning interviews with SMEs.

The four categories are:

Knowledge the SME is aware of – Things they are conscious of knowing and aware that other people will need to know.
Knowledge the SME is unaware of – Things that are intrinsic to anyone with similar experience or in a similar profession. They may not be aware they need to tell other people about them because the assumption is that everyone knows what they know. Or they know it so well they don’t even think about it. Professional jargon, including acronyms, or a well-established process are places where this often comes up.
Knowledge the BA is aware they don’t have – Questions that need to be asked because it’s readily apparent the information is necessary to acquire. This is most often the first draft of the questions that the BA writes for the initial interview. As elicitation continues, the awareness of other needed information becomes apparent. It’s important to identify items in category 2 as part of this process.
Knowledge the BA isn’t aware they don’t have – Information that they don’t have and aren’t aware they need. This can be edge cases, specific rules, or data combinations that aren’t communicated.

In my experience, Categories 2 and 4 are the most dangerous and can cause the biggest problems in any situation.

They are the biggest source of last-minute changes, and it’s the BAs job to ferret them out.

Category 1 techniques

The question I try to ask at the end of every elicitation interview is “Were there questions you expected me to ask that I haven’t?” Often this helps to drive out information that the Subject Matter Expert (SME) knows and is aware that they know but forgot to mention during the interview.

Using reflective listening on a continual basis not only checks the BA’s understanding but may also help the SME remember other facts that they need to share.

Another technique I like is Example Mapping, which fleshes out a user story with rules and examples and that can drive out further detail. If you want more information check out Matt Wynne’s blog post here: https://cucumber.io/blog/2015/12/08/example-mapping-introduction

Category 2 techniques

Most BAs are familiar with the idea of egoless questions. This is useful when working with a SME that is extremely experienced and knowledgeable. Approaching them as a student, even when knowledgeable about the domain, can often make them more aware of what they know and the need to share it.

Questions that can be used to find edge cases that aren’t immediately obvious:

Has this process failed in the past?
What happened?
Was it fixed, or did you have to come up with a work around?
What did you do?

Another way to help elicit intrinsic knowledge is to interview a more experienced SME with a junior member of the staff in that area. Often the less experienced staff member will have their own questions, which effectively doubles the BAs interviewing power and will further prompt the more experienced person to provide information.

Category 3 techniques:

This is really the bread and butter of any BAs work. Asking questions, and capturing the answers is the most important thing we do. The most important tool in this case is a good set of questions. Taking time to prepare for the interview, reading any documentation, and researching any terminology specific to the area so you can speak the same language are all helpful in this instance.

Keep a record of the questions you’ve used previously in this domain, it can save you time if you need to do an interview with other domain experts.

Always focus on the domain expert’s needs in the interview. The goal is to present yourself as an advocate to get their problem solved. You want to be a trusted advisor, which will help your source be more open and comfortable about asking for your help.

Category 4 techniques:

This is the hardest category to work with, for obvious reasons. If you’re not aware you don’t have information you need, how are you supposed to ask about it? This can often combine with Category 2 in unfortunate ways. In this case the answer is to listen carefully and ask lots of follow up questions.

Things to watch for:

Unfamiliar terms
References to people or processes you weren’t aware of.
Answers that are overly generalized or vague.

Often following up on these questions can uncover additional information, either information that the SME hasn’t provided, or information that they didn’t know they needed to provide.

One technique to deal with this is from sales. There are lots of articles on sales web sites about discovering customer needs. Approaching the business with this approach helps them see you as an ally and trusted advisor in solving their specific problem. That will help things focused on what and why, rather than how, which is a big part of the BAs role, and the focus of the whole process.

What techniques have you used to uncover items in categories 2 and 4?