5 Human Interaction Skills Needed for Effective Elicitation

PM Articles by Project Times. 

In my previous article on Elicitation, I discussed many techniques for effective elicitation. Missing, however, were the human interaction skills[i] that are needed to be successful. Some, like Facilitation, are so large a topic that I’ll write about them in separate articles. In this article, I’ll describe five common human interaction pitfalls relating to elicitation and how to avoid them.

Pitfall #1 – Passive listening. In the previous article, I noted that elicitation is about asking questions and actively listening to the responses. A common misconception is that active listening means keeping our mouths shut and nodding our heads. However, that’s really a form of passive listening and it’s a common pitfall. We’re so afraid of interrupting that we rely entirely on those non-verbals to communicate that we’re listening.

Avoiding the pitfall. Active listening, however, involves making sure we understand what’s being said. That sounds easy, but it’s hard to be sure that we’ve understood correctly. Sure, we use those non-verbals noted above to indicate that we understand. They’re important, but not sufficient in themselves. Active listening requires asking clarifying questions, paraphrasing what we think we’ve heard, and asking related questions. These techniques help ensure that we understand and that we’re interested. They also provide an opportunity for the stakeholders to expand and change their thoughts and opinions.

Pitfall #2 – The prosecuting attorney. This pitfall happens when we ask the right questions in the wrong way, in a way that puts the person we’re talking to on the defensive. It’s difficult enough to elicit information when people trust us. If they don’t, it can be a very difficult process indeed. And there are many reasons why they might distrust us. When we sound like prosecuting attorneys, we risk having our stakeholders shut down or give us bad information or none at all.

Advertisement

Avoiding the pitfall. Elicitation is where we learn, and one of the key ways we learn is by asking for the reasons behind statements. Most of us are taught to ask “why” to get at the true meaning, the cause of a problem, the steps in a process, or the usefulness of current information. However, asking why can be an easy way to bust trust, so we have to be careful how we ask it. So how do we ask “why” without asking “why?” I like the old “can you help me understand?” Or preceding the “why” by softening it with something like “I’m curious why…” Or “do you know why…?” Any words that put our stakeholders at ease can help build the trust we need to learn from them.

Pitfall #3 – Misconstruing non-verbals. As PMs and BAs, it’s important for us to pick up on both verbal and nonverbal cues. This can be tricky. Sometimes non-verbals can be misleading. And different cultures have different non-verbal cues. So relying entirely on non-verbals is a pitfall we need to avoid. Here’s a common example. If I bring up a tough topic and the person I’m talking to has their arms crossed, what does it mean? Maybe they disagree with what I’m saying. Maybe they agree but are struggling with the issue. Maybe my timing is off, and they don’t want to discuss the topic at that time. Or maybe they’re simply cold.

Avoiding the pitfall. It’s important not to make assumptions, but rather to ask for clarification. And don’t forget about the “pause/silence” technique. We ask a clarifying question and wait for a response. And wait some more if necessary. I’m the type of person who’s uncomfortable with silence. If the stakeholder doesn’t respond immediately, I have a tendency to jump in with another question. I find it more effective, as hard as it is for me, to count to ten before moving on.

Pitfall #4 – Boomerang conversations. How many people do we know who ask a question and use that as a springboard to talk about themselves? Chances are a lot. It’s important to show interest in what others are saying, and one way to do that is to share similar experiences. But when the discussion becomes a monolog instead of a conversation, it can build boredom and mistrust.

Avoiding the pitfall. Before we share our own experiences, we should ask questions about what our stakeholders are telling us. Even one or two questions can indicate that we value their thoughts. And again, it allows them to expand their ideas.

Pitfall #5 – Hidden agendas. It’s not uncommon for stakeholders to come to a meeting with something on their mind that they haven’t previously mentioned. There are many possible motivations, and we should not assume the worst. For example, perhaps an important new issue has just arisen and they haven’t had time to let us know. Perhaps it’s difficult to get stakeholders together and they don’t want to lose the opportunity to discuss a certain topic. Perhaps we’ve discouraged their ideas and they don’t trust us enough to notify us in advance. Perhaps they have gathered support from others prior to the meeting. Regardless, it is easy to feel that we have been blindsided. And let’s not forget that we may be the ones with the hidden agenda—for many of the same reasons. Even if our intentions are the best, our stakeholders might feel blindsided.

Avoiding the pitfall. I like one-on-one premeetings with an objective but without an agenda. I like to be open about wanting to meet to find out if the stakeholder is comfortable with the upcoming meeting and its agenda and to discuss issues individually. If need be, we can modify the agenda to accommodate additional needs.

In summary, elicitation is one of those critical skills that we all need in order to be successful. It involves not only core elicitation techniques, but also human interaction skills, without which all the great interviewing, business modeling, and other important techniques won’t suffice. This article presented five human interaction pitfalls and tips on how to avoid them. These tips will help us be more effective in doing our work as BAs and PMs.

[i] These are often referred to by other terms. They are sometimes called “soft” skills, but in my experience, they represent the hard stuff. While they can be practiced in a classroom setting, they can only be truly learned through experience, often in the form of a tough lesson learned. Also, I am not fond of the more current term “essential” skills, which implies that skills like interviewing and process modeling are not essential, but they are.

Critical Skills Needed for Project Success

PM Articles by Project Times. 

Part 1 – Elicitation

This article is the first in a series I’ll be writing about critical skills that all project managers (PMs) and business analysts (BAs) need for success. We need these skills regardless of the type of project we’re on, the industry we’re in, the technology we use, or the methodology we follow. Each of these skills requires a combination of what are commonly called hard skills with those needed to work effectively with others.

This first article is about elicitation. It seems easy. After all, what’s so difficult about asking stakeholders questions? Elicitation, of course, is far more than the questions we ask. When all is said and done, it’s about learning. We learn what our stakeholders want, what they need, and hardest of all, what they expect by asking really good questions and listening to what they have to say with great attention. It’s tricky, though. We can’t do what I did early in my career when I tried to develop a list of requirements by introducing myself and asking what the stakeholders’ requirements were, what they really needed, and what they expected by the end of the project. Simply put, we won’t learn enough to create an end product that they’ll be happy with.[i]

What makes the elicitation process so hard? Here are several pitfalls.

Common Pitfalls

#1 – Missed expectations

Expectations are requirements, but they’ve never been stated. Therefore, we cannot get expectations by asking about them. Our stakeholders don’t think to mention them, and we don’t think to ask about them. I didn’t know about hidden requirements early in my career when I asked the questions like those noted above. Another problem– my focus was specifically on the future state solution. I asked for the features and functions, documented them, and got stakeholder approval. Then the development team built the final product according to the specifications with the inevitable result—a lot of stakeholder complaints.

#2 – People fear the future state.

This major pitfall is hard to overcome for many reasons. Some stakeholders are comfortable with their current state and don’t want to learn or train on the new processes and automation. Others are concerned for their jobs. Still others have a stake in the existing ways – perhaps they were part of its development or a known expert on its use. Whatever the reasons, the fear of the future state can make elicitation difficult.

#3 – The time trap

Many of us are often under so much pressure that we don’t have time to dig deep. We gather some high-level requirements, but we don’t have time to uncover the expectations. And even if we have time, which is rare, many of our stakeholders don’t. Many are available for an initial set of sessions, but interest wanes as the difficult detailed meetings drag on.

So, what can we do? Here are 3 tips for successful elicitation.

Tips for Successful Elicitation

Tip #1 – Use a variety of elicitation techniques

The first tip for uncovering expectations is to use a variety of elicitation techniques. That’s because each technique that we use uncovers a different aspect of the requirements. Here are some examples.

  • Process modeling. This has always been one of my favorite techniques. It documents how people get their jobs done. But as with all elicitation, it’s not easy. For example, one of the most difficult aspects about process requirements is that stakeholders argue over where to begin and where to end and how the processes fit together. Using different process models helps avoid this contention. SIPOCS (suppliers, inputs, process, outputs, customers) help narrow the scope of each model and swim lane diagrams help visualize how the processes fit together.
  • Data modeling. Process modeling is great, but people need information to get their work done. Data modeling helps us figure out what information supports each process step. It also provides business rules and is invaluable on our AI initiatives.
  • Use cases. These models help us understand how our stakeholders want to use the final product. They provide not only the scope, but all the functionality of the solution. And use cases, if completed thoroughly, turn into test cases.
  • Prototypes show what the final solution will look like.
  • Brainstorming yields the power of the group, while one-on-ones often reveal what stakeholders really think.

Tip #2 – Ask context questions

A context question is one that surrounds the solution that we’re building. While we do need to ask questions about the  solution’s features and functions, such questions do not provide the complete picture.

I like to group context questions into four categories of questions:

  1. These questions relate to what’s happening outside the organization and include questions like demographics, language, weather, technology, and compliance/regulatory. These may or may not apply to the project. If they do, we need to understand their effect on our work.
  2. These pertain to how ready the organization is to accept the final product. The bigger the change, the more issues there usually are. We need to know, for example, which stakeholders will be on board, which will resist the change, and what needs to be done to prepare the organization for the change.
  3. We need to ensure that the business problem we’re solving and the proposed solution align with the organization’s goals and objectives.
  4. These context questions are usually those about the current state.

Tip #3 – Know when to use open-ended, closed-ended, and leading questions

Open-ended questions allow the respondents to expand their thoughts. We ask open-ended questions any time we want to learn more. For example, we ask these questions when we’re just beginning an effort, during brainstorming, and when we need to get all the issues out on the table, etc.

Closed-ended questions are forced-choice questions. They have the answers embedded in the question itself, sometimes explicitly as in a survey question, or implicitly. I like to ask closed-ended questions when stakeholders are all over the board and we need them to focus. For example, given all these issues we’ve identified, if you had to choose 10, which would they be?

Leading questions are not questions at all. They sound like questions, but they’re really our opinions stated in the form of a question. “This is a pretty cool feature, isn’t it?” My least favorite leading question is one we often hear: “Have you ever thought about…solution.” Again, it’s not a question. It’s us presenting our opinion rather than asking what our stakeholders think. What’s wrong with that? Remember we’re in the middle of elicitation, which is about learning. Presenting our solutions during elicitation cuts off exploration because we’re telling rather than learning. Later, after we’ve completed elicitation and analysis, whether it’s for the whole project or a smaller part, we can make a thoughtful recommendation.

To summarize, effective elicitation is critical to the development of a final product that our stakeholders are happy with. Elicitation is not easy. There are several pitfalls which are difficult to overcome. But if we follow the tips provided in this article, we will deliver a product that our stakeholders actually like and want to use.

[i] I use the terms solution, final product, and end product synonymously. It’s the solution to the business problem we’re solving. It’s also the product or product increment being produced at the end of the project, project phase, or iteration.