Tag: Business Analysis

5 Ways to Find Missing Requirements

Written by Laura Brandenburg on April 13, 2015. Posted in Articles.

Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been on enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.

In this article, we’ll look at 5 practices we employ as business analysts to discover hidden requirements, and how organizational pressures, project circumstances, and business analysis processes can negatively impact the outcomes of those techniques, leading to the costly reality of overlooking requirements.

Practice #1 – Requirements Reviews and Buy-In

It is not uncommon to discover dozens of requirements during the final requirements review stage. Walking through a requirements specification, or a portion of a requirements specification, with the goal of being sure everything necessary has been included, almost necessarily uncovers additional information.

When you are getting ready to approve, finalize, or simply be done with a requirement, your stakeholders tend to invest a little extra time and energy in being sure it is right.

But the review process only works if you establish the importance of the review, making it very clear that once we review this document, development will begin based on what is inside it, and that means the cost of change starts to go up.

This stage of the process can go wrong if stakeholders do not show up to requirements meetings, do not understand the enormity of what approval means, or do not feel bought into the project in the first place. It also does not work if a critical stakeholder is not invited in the first place, which leads us to the next way to find missing requirements.

Practice #2 – Include All Possible Stakeholders

While it is never a great idea to invite dozens of people to a single requirements meeting, good business analysts ensure that all relevant stakeholders are looped into the project and given the opportunity to share their concerns, needs, and expectations. If you are consistently neglecting requirements in a particular area, identify a new stakeholder from that area to include on your project teams.

This part of the process can go wrong when business analysts are assigned to specific areas of the business and projects are assumed to only impact that area. It can also go wrong when managers assign uninformed stakeholders to projects or refuse to assign stakeholders at all. Organizational politics can also be a factor, say, if a business sponsor purposely excludes one or more stakeholders from the project.

Practice #3 – Apply Analysis Techniques

While stakeholders are the source of many requirements, other requirements are discovered by analyzing the stakeholder needs and discovering implications. The result of good business analysis is a complete view of the solution. For example, every field on a report must be entered into the system at some point, whether directly by a user or by some sort of data feed.

Unfortunately, well-intentioned templates can negatively impact the analysis process. When you are capturing requirements in long lists, it is difficult to make all of the necessary links between requirements. As luck would have it, the same is true if you are capturing requirements in a substantial product backlog. You need analysis models, such as business processes, use cases, or data models, to help you discover the missing connections.

What’s more, a large template can give the false sense of security. Just because you have filled out a 30 page template with twice as many sections does not necessarily mean that you have discovered all of the requirements!

Practice #4 – Invest (Just) Enough Time

Good requirements take time from stakeholders, from technical experts, and from someone performing business analysis activities. Part of being a business analyst is putting together a reasonable plan that explains the steps you will go through to elicit, analyze, and confirm the requirements, identify who needs to be involved in each step, and about how long each step will take.

While it might seem counter-intuitive, more time is not always better. Business and technology contexts change quickly. Investing too much time in the requirements process can mean that your early requirements become stale before they are even ready to be implemented. Minimizing missed requirements comes from crafting a plan that secures just enough time to discover the best possible requirements given the project goals and constraints.

However, it is not uncommon for a business analyst to be assigned a mere week or two to finish requirements before development on a sizable project is targeted to start. When organizations shrink project timelines, or the time dedicated to the requirements aspect of the project, without also shrinking the scope of the business analysis effort, then we nearly guarantee we will miss requirements.

Practice #5 – Start at the Beginning

You cannot solve a problem that you do not understand. You cannot address a business need that has not been defined. You cannot sell a product that the customer does not want.

Business analysts understand the big picture of the project, which includes why the organization is investing in the project and the over-arching goal to be accomplished.

I would venture to say that the vast majority of missing requirements are actually missed at the very beginning of the project. If no one inside the project compels the business community to be clear about exactly what problem needs to be solved, or if a business sponsor resists a business analyst’s typical “why” line of questioning, the entire team is working like a ship without a rudder. You run the risk of chasing rabbits down holes and discovering a lot of requirements that are irrelevant, while overlooking the big important requirements that should be staring you right in the face.

Create More Positive Outcomes

As business analysts, we can expect to face circumstances that, if left unchecked, will cause us to miss requirements. It is up to us to clarify the conditions under which we can do our best work and improve our contexts so we can improve our requirements.

Don’t forget to leave your comments below.

The Pros and Cons of Using a Smart Pen for Business Analysis

Written by Mark Owen on April 13, 2015. Posted in Articles. 1 Comment on The Pros and Cons of Using a Smart Pen for Business Analysis

For those that aren’t in the know, a digital pen (also known as a smart pen) allows you to capture what you are writing in an electronic format.

These pens use a variety of techniques to do this ranging from using a camera, to being connected to a computing device. Some also allow you to record a conversation taking place while you are writing notes.

I have used a digital pen in a lot of elicitation situations and, in this article, I would like to describe some of the lessons learned.

WHICH DIGITAL PEN DO I USE?

I use a camera-based pen. It is slightly larger than a normal pen and contains a small camera and a microphone. By using digital paper, the pen can track what is being written and store it. At the same time, it can synchronise the audio being recorded with what is being written. At a later stage, you can press the pen anywhere on the page (on which you have written your notes) and play back the conversation that was taking place at that particular time.

HOW I USED IT?

In any elicitation situation where I was taking notes, I would use the pen to keep a record of the actual conversation taking place. At the same time, I would take be taking notes.

After the session I would play back the conversation at various points to confirm that my notes were correct, or to expand on what I had written (you know that written notes don’t always capture everything that was discussed).

Using the an associated computer application, I was able to convert my written notes into a dynamic PDF that could be archived or distributed to others in the team. This PDF had the audio embedded, and the reader could click on any word to playback the discussion taking place at that time.

WHEN I WAS NOT THE SCRIBE

Often when you are running an elicitation workshop, you are up in front of everyone leading discussions, asking questions, prompting and encouraging responses. You can’t do this and write everything down. In this case, there is usually someone else who assigned this task (the scribe).

When I was in this situation, I was still able to use the smart pen. Whenever there was a change in the discussion, or a particular point that could be summarised in a word, I would write that on the special dot paper. After the session, I could still playback what was said at that point.

THE PRO’S OF USING A SMART PEN

Using a smart pen has a lot going for it:

You can capture the whole discussion and tie it in with your notes.
The audio is synchronised to the written notes, so you can play back the conversation that was taking place at specific points.
You can share the notes with audio with other members of the team, or with the stakeholders (if desired), as part of your Work Product.
You are confident that you can go back over the audio to pick up things that were said, but not written down.

LESSONS LEARNED

Using the pen has been very handy, but it also has its downsides. What follows are some of the lessons learned.

ASK PERMISSION

Before using the pen during any elicitation event where there are other people involved (workshops, interviews, active observation, etc.) ask if it is OK to record the conversation. Usually, people are pretty good about this and don’t mind.

However, it is important to reassure participants that you are using the pen merely as a tool to support the notes you are taking. And as a professional BA, you need to remember that.

DON’T LET THE PEN BE A REPLACEMENT FOR ACTIVE NOTE-TAKING

Use the pen to capture the conversation, but don’t be lazy. You still need to listen actively, and write down the important points from the conversation.

YOU STILL NEED TO CONFIRM

You still need to validate that the stated requirements match the stakeholder’s understanding of the problem and their needs even though you have an audio record of the conversations. What is written, and what was said still might not be what was meant.

MAKE YOUR NOTES MEANINGFUL

As I mention above, in a workshop situation you might just write a word of two and let the pen capture the conversation.

I’ve had situations where, after a series of seven one-hour workshops I’ve gone back over my notes and haven’t been able to work out which part of the workshop the squiggle on the page or that strange sentence I wrote (which meant something to me at the time – three days earlier) referred to.

When you are writing headings to describe certain parts of a conversation or discussion, write something meaningful so that, five days later it will still be clear to you. The discussions in workshops, or interviews, don’t always take place in nicely defined sub-sections.

NEVER JUST RECORD THE SESSION

This is a classic newbie mistake and relates to something I wrote above, Never, ever, just record the elicitation session with the intention of writing up the notes later on. You might have a three day workshop in between the time you recorded the notes and when you get to write. Remember – when you playback the audio, it will take three days to listen to it! (And this includes all those side-conversations, jokes, and irrelevant comments that get made.)

SECURE THE OUTPUT

This is related to Ask Permission above.

Regardless of whether you have been given the OK by the session participants to record what is being said, be aware that a lot of things said during the workshop/interview/active observation session might not be relevant or are off-record. It may not be your intent, but you don’t want a situation where something someone says is used against that person later.

HAVE A WAY OF CHARGING THE PEN

The pen can be used for several hours, but it won’t last forever. With the smart pen I used, I could plug a USB cable into it, and plug that into my PC, allowing the pen to always be charged while I writing notes. Useful, but it was not very handy.

ENSURE YOU HAVE ENOUGH PAPER

The smart pen uses paper with microdots on it. This allows the pen to be able to map what is being written, and the location on the page.

Often this paper is sold in the form of notebooks, etc. Ensure that you have an extra notebook with you. You might never use it, but, then again, you might. (In my situation, I could print out the microdot paper myself, but read the next Lesson

Learned for more on this.)

KEEP TRACK OF THE PAGES

Each page in the notebook has a unique, sequential, ID. This way, the pen can keep all the pages in the correct order. Don’t write your notes on random pages. It makes it difficult when it comes to working with the notes and audio when you are back at your computer.

PRINTED PAGES

As mentioned above, you can print out the microdot paper yourself. If you do this, you will have several loose sheets. These are handy if you want to put the sheets in a ring binder, but be aware that, as with the notebooks, each page is in sequential order. Keep them in the correct order (the page number is printed on each). This saves a lot of pain when exporting to a PDF.

CONCLUSION – WOULD I RECOMMEND USING THE PEN?

The pen is an incredibly handy tool (with the later version offering even more functionality, as well as looking like a real pen).

However, for the purposes of Business Analysis I would not recommend using it.

WHY?

As I alluded to in some of the Lessons Learned, being able to record the conversation taking place is valuable. But it also makes you relax.

It’s easy to think “Oh I won’t write that down – I’ll go back over the audio later.” WRONG! The idea of the elicitation session is to capture the main points actively, in real-time.

That’s part of being a good BA. Active listening, and active note taking. You are in the elicitation session to understand the message that the stakeholders are communicating. And you need to make sure that you have captured it properly.
Going back over a recording of a session, in my opinion, is of little value. The real value should be in your notes. If they need expanding upon or clarifying, that is something that needs to be done directly, with the appropriate stakeholder.

I’m not saying that a smartpen is worthless. But if you think about it, BAs have been taking notes as part of the elicitation process for years. How many have recorded the session?

However…

My conclusion above is how I feel about it. For you, fellow BA, it might be a different situation.

In fact, someone pointed out to me that their handwriting is terrible, and they often can’t read their notes. Having the pen would mean that they could, indeed, dive into what was being said at the time the notes were made.

I can’t argue with this reasoning…

YOUR OPINION

Have you ever used a smart pen? In what situations have you used it? What are thoughts on it? Do you think that I am wrong in not recommending it for BA work? Feel free to let me know in the comments.

Don’t forget to leave your comments below.

BA-elzebubs Glossary Four – The ‘B’s

Written by Marcos Ferrer on April 6, 2015. Posted in Articles.

My brilliant readers know this piece of fun. Get credit in my next blog by offering more “B”s (and “C’s”) in the comments at bottom.

BA: See Business Analysis or Business Analyst.

Baseline: 1. A method of slowing progress to fit communal bandwidth; for example, the monthly rhythm of a change control board. 2. A clear, consistent, concise definition of feasible requirements suitable for: a) ruining with last minute executive confusion and “demand” deliverables; or b) for improving with carefully considered change management.

BB: Profession following BA.

BC: See BB.

Benchmark: 1. The mark made on the bench by project teams that watch what others do, similar in value and concept to the “hashmark”. 2. Solution speed comparison tests, as in “Wow, Amazon’s on-line store put us out of business in less than 10 years.”

Benefit: 1. Value that a solution might provide if implemented successfully; 2. The source of stakeholder fear of a solution. Example: “Digital blueprints mean that we don’t have to drive all over the county fetching and delivering blueprints, but driving around is more fun than actually supervising sewer work, on-site, most of the day.”

Best Practice: NOT what you are doing. Believe it. Diagnose it. Now change it. Repeat. Now you’re getting it – oops, not quite! Keep trying.

Beta Test: Formal term describing a solution that is not ready for commercial release, but is released to a limited number of users who help by giving feedback to the developers. Apple modernized this practice by releasing to all users while dropping the “beta” designation and using the word “free” instead. Microsoft is fighting back by moving to alpha releases but continuing to charge money, giving the illusion of product maturity.

Bit: 1. An information technology word never to be discussed with a business stakeholder. 2. A canned response to common stakeholder concerns. Example: “When the stakeholder objected to the process model, the BA bit them in the ear and the stakeholder dropped the objection”.

Box: A polite word for those in an organization who write the checks for “change consultants”. They do this for their own protection. Example: “He wanted Org X to get out of the box, so he hired the change consultant, but it turned out that he WAS the box, so he fired the change consultant!”

BPMN: 1. A notation for modeling a business process domain for stakeholders who can’t pretend to read but have no trouble pretending to understand a picture. 2. An alternative to sticking with text rendered so large that it can be confused with a picture. See PowerPoint discussion by Edward Tufte.

Brief: A highly compensated, highly expensive way of communicating. The most successful executives are brief in their communications (“of course this will be everything you want”) and in their tenures (“good luck, it was nice working at you”).

BS: Business Synthesis. What did YOU think?

Bug: A critical yet unexpected system feature from a developer. These (widely misunderstood) features help ensure that the developer’s software gets tested thoroughly once it is already released. Testing before release is optional – see “Baseline”).

Business: None of yours, hopeful elicitor :).

Business Analysis: The precursor to Business Synthesis.

Business Analyst: Anyone precursing Business Synthesis.

Business, Monkey: 1. The illegal trade in endangered primates. 2. Any decision made in the “C” suite without any sense of the impact on end users.

Business Requirement: 1. As commonly practiced by business executives, a business requirement is any requirement promoted by a “business” person in the organization, suiting the “business ego” needs of that stakeholder, in direct contradiction to BABOK. Example: “When this is over, we will still be a Microsoft shop, won’t we”? * 2. As defined by the BABOK, a business requirement describes the needs of the organization as a whole, and not groups of stakeholders within it. Example: “When this project is initiated, existing systems must continue to operate without additional downtime, as measured by existing availability reports.”

Business Rules: 1. Code buried deep where no businessperson can find it, known only to programmers, who can’t explain it. 2. Arbitrary wants that are un-code-able, as they cannot be explained. Example: “The system should automatically pick the best employee for promotion.” 3. Actual policies that govern transactions and entity relations of great value. These policies are typically kept out of code so they can be modified on the fly by spontaneous human judgment. Example: “No insurance company should carry more than 33% of all liability” is easily modified to add the phrase “unless the insurance company is run by people who assure us that all is OK and besides they are our friends.”

Button: The solution to everything. Examples: “Can’t we just add a button”? or “Can’t the system just push the button for us”?

Enjoy! And give BA-elzebub (not me!) some “C’s” below (Cache, Cynicism, Customer, Cost-Benefit, Critical-Path more) should your Cranium Crave Creative Comprehensibility by Chuckling Colleagues 🙂

Don’t forget to leave your comments below.

The Challenge of Challenging Appropriately

Written by Bob Prentiss on March 31, 2015. Posted in Articles.

See Bob Prentiss Live in Washington May 4th – 6th at
Project Summit Business Analyst World Washington!

You want to make progress. You know that you are an innovator for your organization. You simply want people to listen to you, yet your voice and any challenge you put forth to do the right thing seems to go unheard or unrecognized. You need to ask yourself “why?” I get it, it can be very frustrating when you probably have the answer to a problem and are trying to prevent your company from settling for the status quo. So how can you get your voice heard? Let me ask you this: “Do you think you have been challenging appropriately?” Now “appropriately” sounds like I am just talking about being “nice”. It is actually much, much, more than that, which is why challenging appropriately is in fact, a challenge. For some of us, the answer is intelligent disobedience, but for some of us, it is learning how to challenge appropriately.

There are many barriers to challenging successfully. I often joke that the root cause of these barriers is that people suck! Now I mean this in the nicest possible way, I love people – I really do! I am first and foremost a people person, however, I know that people want what they want, when they want it. People are different: personalities, needs, desires, goals, experiences, and more. People are just hard to figure out. What we think is obvious and should be acknowledged, another thinks is ludicrous and walks away. Add to it the complexity of communication and you run into many more barriers like: wrong place, wrong time, wrong person, wrong facts, wrong approach, not enough alternatives, budget, resources, personal pride, personal agendas, positional authority, your dog ate your homework… well, there is simply a lot that can get in your way.

What does it mean to challenge appropriately? I think there are many things that make up the definition. My personal definition is:

“An individual or group, who works with other individuals, groups or organizational structures in a collaborative fashion, challenging the status quo to achieve a common purpose or goal for the greater good of the people, project, or the organization.”

This is all well and good as a definition, but it still does not tell us how to challenge properly. It would be great if we could first all agree that we should have the ability and right to challenge as part of collaboration to ensure we meet the goals appropriately, but all of those “barriers” come creeping in quickly. So what can you do?

There are 100’s of ideas that I am sure everyone has, so I hope that everyone chimes in with their favourite ways of increasing the chances of challenging successfully. Certainly there are some basic rules that we should all abide by when challenging – mutual respect, being nice, honest, positive, seeking to understand, critically thinking and not rushing to judge, open minded, and being flexible and adaptable.

Here are 6 tips that have helped me for over the years successfully challenge for the greater good.

Know thyself. It is advice I have given for years. As I have worked with people from all walks of life, I have found that those who are able to challenge appropriately are those that have a strong sense of who they are and what they want out of life. The better you know yourself, the better chance you have of dealing with other people because at the very least you have a strong center to work from. I know exactly what my strengths and weaknesses are, what type of person I am, what I want out of life. All of this gives me an opportunity to relate to people better. Think Myers-Briggs Type Indicator, Insights Discovery Personal Profile, or Strengths Finder 2.0 is beneath you? They have all been my best friends and valued tools for many years. I am happier now than I ever have been because of these tools and how they have helped me shape who I am. They have helped me know myself.
Know what motivates people. What is their WIIFM factor? WIIFM – what’s in it for me? It is hard to challenge successfully unless you know what is going on in the mind of the other individual and what is motivating them. It is often impossible to influence others without understanding their motivation. And that is the whole reason for challenging, right? You are trying to influence them to another way of thinking and doing. How do you do this? Perhaps just ask! Most people will tell you. Keep it simple like “Hey Jon, help me understand…” Notice I did not put the word “you” in that question. Don’t put anyone on the defensive with the “you” trigger. A natural, organic conversation will often yield how people feel about things – their WIIFM.
Know the facts. I’ll take some mastery of the facts with a side of options, please. A challenge without a mastery of the facts can be perceived as incompetence. If you talk to your boss about changing something, or complain about something that does not work, and you have not given them any options with sound facts for how it can be resolved, you will often be perceived as a whiner. Make sure you have more than just your gut feel for something. Yes, for most people, your gut is likely to be right, but many people will not proceed or agree based off a gut reaction or instinct. Details are needed. And if you do have the facts? Make sure you have a backup plan – options. Not everyone is going to respond to your first option. Always have a backup. Even if your goal is to show them the backup so that they realize the first option is the best way to go.
Time and location. If you challenge at the wrong time or in the wrong location you might as well have not tried at all. Understand the implications of the when and where. Once upon a time I tried to challenge something early in the morning. I am not a morning person. I am often incoherent until after 9 a.m. Okay, maybe 11 a.m. if I am honest. Although I had my facts, I was not articulating them well. Although never formally diagnosed, I sometimes speak my words backwards – a form of dyslexia. After making my case, people just stared at me and then continued in a conversation like I was not there. When I am focused and alert it does not happen. I also do not drink coffee, so good mornings for me are generally dependent on good sleep. I also once tried to challenge something in the office of a Senior VP. Well, let’s just say that I was not given the time of day as he paid attention to his computer and everything else in his office. I had the “when” right but not the “where”. Your strategy of when and where can make all the difference in your results.
Coalitions. I do not often challenge alone – I find strength in numbers. A coalition is a group of like-minded people that share your vision. People in your coalition may have strengths that you do not (of course you need to know what those are first). When I challenge, I am keenly aware that I do not always need to be the frontrunner for the challenge. I am okay if there is someone else better suited to do so. It is the end goal we need to get to and my ego is checked at the door.
Know how often to challenge. Challenge, and then challenge again! I often talk to people about how they challenge. The story usually goes something like “I brought it up to them that it was not going to work, I offered a solution and they just ignored me!” Well, that is not really a full challenge. That is an attempt. A challenge is something that often needs to be sustained or repeated. You must be willing to go back to the well if you believe in your cause. For most things I use the approach of: “Two toots and a salute!” This is the idea that you challenge once, and when no movement or resolution comes forth, challenge again in a different way through coalition members, other creative options, or new facts. Still no movement? Then it is time for “Yes, sir!” “Yes, ma’am!” You must be aware that pushing too hard can result in a CLM (career limiting move). Figure out both what the individual and organizational tolerance is for challenge so that you can adjust your strategy accordingly. There are definitely times I will challenge three or four times if the tolerance is there, especially when I have the facts and the support.

At the end of the day you want to help move your organization forward. You want people to listen to you. You want to do the right thing. I believe that when we challenge appropriately it helps to build relationships and foster better collaboration. Intelligent disobedience works too, but a balance between these two things is even better. So where have you had success with challenging appropriately? What is your strategy to remove the “challenge” from challenging?

See Bob Prentiss Live in Washington May 4th – 6th at
Project Summit Business Analyst World Washington!

Don’t forget to leave your comments below.

Ask the Naked Question: How To Ask the Right Question part 4

Written by Steve Blais on March 2, 2015. Posted in Articles. 1 Comment on Ask the Naked Question: How To Ask the Right Question part 4

In the previous episodes, we established a framework more conducive to asking the Right Question, increasing the probability that you will ask the Right Question, if even inadvertently. We talked about what to ask, and to a degree when to ask it. Now let’s wrap up with talking about how to ask the Right Question.

“How” is as important as “what”

The quality of the response is affected not only by the content of the question, but also by its manner of delivery, especially its pace and timing.
Michael Marquadt [3]

The trick to asking the Right Question may not just be in knowing what to ask, it may be in knowing how to ask it. This requires good questioning skills according to Andrew Griffiths who states that in addition to getting good answers, “good questioning skills will empower you and can transform your confidence, ability and results”. This being the evidence of leadership which “… is all about asking questions: the right questions at the right time in the right way”. [1]

Ask naïvely

Even though we know what information we want, we don’t want to assume we know what the answers are actually going to be. We may have asked the same question of eighteen other responders and gotten the same answer 18 times in a row, but the 19th time we ask, we want to ask it as though we never asked it before.

But, Steve, you might say, if I’ve been rummaging around the call center asking questions of everyone to define a new call center system, won’t the people I’m asking questions of know that I’m asking questions that have been answered by someone else?

Sure, and if you preface your question with “I’m not sure I understand this, which is why I’m asking you” or something similar, the person will tend to answer your questions as though he or she is the very first person you are questioning.

The same holds true for confirmation questions. When you preface the question with “so I understand this is how [fill in the blank] is done, is that correct?” You will get the close-ended response of “Yes”. And this is good for confirmation. However, if you start the confirmation question from the opposite point of view (“I’m having trouble understanding this, perhaps you could clear it up for me…”), you will likely get an answer that confirms your previous information and also adds new information or at least includes the personal perspective of the responder.

Getting Naked

To the degree possible, getting the Right Answer and not just a superficial response requires us to convince the responder that we genuinely want to know the answers to the questions we are asking and we invite all the information they have on the subject. This means approaching the information gathering session with a degree of humility as described by Patrick Lencioni in his book, Getting Naked. Lencioni suggests that we should be “so concerned about helping [our customers] that [we should be] willing to ask questions and make suggestions even if those questions and suggestions could turn out to be laughably wrong…readily admit that we don’t know and be quick to point out – even to celebrate – [our] errors because protecting [our] intellectual ego is not important to them.” [2]

There is one somewhat universal truth when it comes to getting answers to questions: people will not tell you something that they think you already know. When you ask a question and appear to already have knowledge about the subject, the responders will give you very generic and high-level answers. No one likes to give a detailed answer to then hear the other person say, “yes, right, I know all that, but what I really want to know is…” Appearing less knowledgeable gets more information for example using the approach Denzel Washington does in the movie Philadelphia, “tell it to me like I am six years old.”*

The trick here is to curtail your natural inclination to “discuss” the situation or responses by offering your opinion or knowledge gained on the topic. When your goal is to gather information, focus on the flow of information – coming to you and not going from you to the responders. Remind yourself that you will have plenty of time in review sessions and other engagements to exhibit your grasp of the situation and solution.

And Listen Naively

Listening naïvely is the technique in which you appear to be a sponge willing to learn everything that the responder can tell you about the topic.

To get the most information and the Right Answers, the questioner has to listen naively. That is, listen with no preconceived notions, exerting zero judgment, absorbing all information that is proffered without analysis. In other words, the questioner must hear the information as though for the first time. This is difficult because it requires the questioner to be totally in the moment and focused.

When you establish the information gathering session “frame” (as discussed in the previous article), you set the stage in the responder’s mind that you are in need of this information. It also reminds you to sit back and listen as though for the first time.

In other words, just ask the questions, the naked questions, unadorned by preface, explanation, suggestion, direction, assumption, or supposition. Here’s an example: when the responder does not understand the question and asks for an explanation, rather than give an explanation or background, rephrase the question so that you continue to ask questions rather than provide answers. As stated, there will be plenty of time to provide the answers when all the information has been collected.

You will find that people love to tell you what they know and if you are listening naïvely, they will tell you a lot more than your questions ask, perhaps even filling in the gaps between your questions.

Avoid Asking the Wrong Questions

“If they can get you asking the wrong questions, they don’t have to worry about answers.”
Thomas Pynchon

The opposite of “right” questions would likely be “wrong” questions. So if there are a few “right” questions, the rest must be wrong, unless there is some middle ground between right and wrong like mediocre.

Therefore, one solution might be to adopt the stance that all questions are “right” with a few exceptions which might be considered “wrong”

Questions which caused the information gathering session to be terminated by the responder: “so, before this new system replaces your job and we lay you off, can you describe some of the things we can do to make the system better?”
Questions which stemmed the flow of information: “yes, we get that. You clearly do not understand what we are looking for here. What happens when…?”
Questions which resulted in the same information you’ve already received (except when you are specifically looking to confirm information obtained from another source).
Questions that result in an abrupt change to the responders’ focus: “so to continue with the Accounts Payable voucher process, what did you think about the best picture award at the Oscars?”

Since cognitive studies have shown that we humans tend to remember the negative things more than the positive things that happen to us, we most likely remember those “inappropriate” questions a lot more and a lot longer than we remember the hundreds of “right” questions asked. And this remembrance of the less than optimum questions might explain why so many of us agonize over the “right question” issue.

So perhaps the best advice on how to ask the “right” question is to simply avoid asking the “wrong” questions. If you don’t ask any “wrong” questions, then clearly all the questions that you ask must be “right”.

Some Good Advice

Marquardt offers some good advice for asking the Right Question to elicit the Right Answer:

“Respond without judging the thoughts, feelings or situations of other people
Consider yourself a beginner, regardless of experience
Avoid focusing on your own role (which can lead to a self-protective approach) and take the role of an outside observer, researcher or reporter
Look at the situation from multiple perspectives, especially your respondents’
Be tolerant of yourself and others
Ask clarifying questions” [3]

Tips for Asking the Right Question(s)

Here are some final thoughts that might help you ask the Right Question.

Review your questions to see if you have the ‘right’ answer in mind, before asking the question. If you do, then either delete the answer, and all other judgment from the question, or don’t ask it.
Continually refer to the responder’s previous answers or comments for subsequent questions. This not only reaffirms what the responder has said previously, but it also reminds the responder that you are listening carefully to what the responder says, thus encouraging even more information to be shared.
Avoid focusing on your role or your deliverable. Focus on their problem or their part in the problem / solution. Be prepared to discover that they may not consider the problem you are striving so vigorously to solve to be important to them or not even a problem at all.
Ask the questions delicately and naïvely, and listen naïvely to the information provided. To paraphrase the X-Files: the Right Answer is in there.
Ask just the questions, naked unadorned questions, and keep asking

In the end, the Right Answer is the result of piecing together a lot of answers generated by a lot of Right Questions. You will be obtaining the Right Answers from people who probably don’t even know that they know the Right Answers. And this is the magic of information gathering and problem-solving. Go forth and ask more questions.

[1] Griffiths, Andrew, Ask a Stupid Question, Lightning Press, UK, 2012
[2] Lencioni, Patrick, Getting Naked, Jossey-Bass, San Francisco, 2010
[3] Marquadt, Michael, Leading with Questions, Jossey-Bass, San Francisco, 2014

* In the movie “Philadelphia” which involved an insurance trial in which Tom Hanks was the plaintiff, Denzel Washington was the lawyer called in specifically because of his knowledge of the complex insurance laws and regulations. Throughout the movie, in depositions and during the trial, Denzel Washington, as the lawyer, said to witnesses and others who were describing aspects of the case, “Tell it to me like I am six years old”. As an expert, he didn’t need for it to be made simpler, but those who were judging the case did, and by requesting the witness to respond in the simplest way possible reduced the ambiguity, vagueness and potential misunderstanding of the response.

Don’t forget to leave your comments below.