Tag: Elicitation

The Courage to Try Something Old – Use Cases

Written by Elizabeth Larson on May 30, 2023. Posted in Articles.

There are many articles about project management trends for 2023. Among the common threads are a focus on AI and more automated PM tools. There are also contradictory trends like workers returning to the office or continuing to work from home. What I find most interesting, though, is that many of the trends have been around for years—like change management, agile and hybrid development methods, and focusing on benefits.[i] Does that mean that these old horses are not really trends? Not at all. It means that even when these techniques are out of favor, they are needed to successfully manage our projects.

One “old” trend I was happy to see was entitled Use Cases Are Back.[ii] Not that they’ve ever gone away. They’ve had different formats and names, like the Given, When, Then format, but the thought processes needed to develop a use case model have always been required.

To review, a use case is a model that describes how stakeholders want to use pretty much anything that’s being built, like a car, an elevator, a phone app, or a change to an existing system. But defining them is not easy. We can’t just ask our stakeholders how they would like to use a microwave or what functionality is needed in a sales app. We need to ask the right questions. And a use case model is a great tool for getting at those requirements.

A use case model, like almost all models, has both a graphical and textual component.[iii] The first component, a use case diagram, is a picture of the how the stakeholders will interact with what’s being developed. It identifies all stakeholder groups who will use the end product and how they want to use it. It also describes all the systems and other components needed to make it work. It becomes a picture of all the people and technical components, as well as all the functionality needed to make it useable. And it’s a great picture of the scope of the effort.

Some PMs and BAs have trouble getting started, so I have developed 5 business questions that can provide a jumpstart in the creation of a use case diagram.

Use Case Diagram Questions

What’s being built? It’s usually called a system, but we can call it whatever we want. Examples include a new car, a change to an order system, and kitchen cabinets.
Who are the stakeholders who will use this system? These are often called actors, such as an auto service consultant, a consumer, and cabinet designer.
How do these stakeholders want to use the system? What functionality do they need? These are the use cases themselves. They are stated as high-level processes, like Start Car, Order Product, Measure Cabinets.
What other systems or components will interact directly with the system? These are also commonly called actors, like Ignition system, Replenishment system, and Cabinet Delivery Schedule system.
How will the actors and the system talk to each other? These eventually become the user interfaces that allow the system to recognize what the actor wants to do. The driver sends some signal to the Start Car use case. A consumer enters an item into Order Product use case. A cabinet designer enters measurements into a design cabinet use case.

The textual component is known as a use case narrative or scenario. It describes the process steps which detail the interaction between the stakeholders and what’s being built.

Advertisement
[widget id=”custom_html-68″]

For example, how do we start the car? Does the driver put a key into the ignition? Press a button? Does the car start when the car phone app is connected and the driver opens the door? Something else? There is no one right answer. But the questions below will help our stakeholders go through the required thought processes.

Use Case Scenario Questions:

How do I know where to begin? Preconditions provide the answer. They tell us where to begin by describing what has already occurred. In our example, do I already have my keys? Have I already unlocked the car? Adjusted the mirrors? More preconditions mean that the use case scenario will be shorter and there will be fewer different paths. For example, if a precondition is that I have my keys, we don’t need to document what happens when I’ve lost my keys in this scenario.
How do I know when I’m done? These are the postconditions. We stop when we reach these conditions. The pre and post conditions form the scope of the use case because they define what’s in and out of each one.
What is the most common way of getting from the pre to the post condition? This is the “happy path.” There are no decisions in this path, such as what happens if the car won’t start.
What are other ways of getting from the pre to the postcondition? These are the alternate paths. The car starts, but it takes three tries.
What prevents us from getting to the postcondition? These are the exception paths, like when the battery is dead.

Use case models are extremely useful for getting the requirements of the interaction between stakeholders and what’s being built. There are other ways of getting them, but the structure of the use case can help us focus on what questions to ask and ultimately saves time and frustration.

[i] https://www.theprojectgroup.com/blog/en/project-management-trends/; https://www.replicon.com/blog/project-management-trends/ are two examples.

[ii] https://www.projecttimes.com/articles/top-business-trends-to-watch-for-in-2023/

[iii] I’m not including a use case diagram because of the many different conventions used. What’s important are the thought processes, not the conventions.

The Power of Active Listening

Written by George Pitagorsky on December 6, 2022. Posted in Articles.

“ It is only in listening that one learns.” J. Krishnamurti

Communicating is central to optimal performance. Listening is a powerful capability for success. It is the most critical part of communicating. As a project manager, or in any role, in any relationship, listening both shows respect for others and informs you, so you are better able to learn and respond effectively. Listening enables a meeting of the minds.

Hearing, Listening, and Active Listening

Listening is different from hearing. Hearing is passive. A sound is received by the ears and registers in the brain.

Listening is active. It exercises focus, self awareness, and social intelligence. It is giving attention to (“I am listening to what you are saying”), making an effort to hear (“I am listening for a signal”), or it can mean to act on what someone says (“The kids/my boss/the staff just don’t listen”). Not listening is ignoring or not making the effort to hear and understand.

In the context of relationships, leadership, and management, we have changed the meaning of to listen from “give one’s attention to a sound”[1] to give attention to the communication experience. We refer to this as active listening. active listening is not just about sound. It is paying attention to the full experience of the sounds, words being spoken (or written), tone of voice, facial expression, body language, and “vibe” or emotional state. Active listening involves questioning to validate understanding. And it includes listening to one’s inner voice and feelings.

Meeting of the Minds

Communication is an act of sharing. It consists of giving, listening, and understanding. It is most effective when it achieves communion – the sharing of detailed and thorough thoughts and feelings to reach a meeting of the minds – mutual; understanding. Active listening promotes mutual understanding.

Some may question whether the sharing of thoughts and, especially, feelings has a place in organizations and business relationships. This kind of sharing does not mean sharing one’s deepest feelings when that is inappropriate. But with detailed and thorough knowledge, there can be the mutual understanding that leads to better decisions and healthier relationships.

Mutual understanding transforms the state of mind of the participants. It implies that the people involved meet one another with open mindedness and the intention to understand one another’s meaning. With that kind of understanding, team members are motivated to act, to follow through on agreements, or to know that the there is disagreement.

Advertisement
[widget id=”custom_html-68″]

A Scenario

I recently requested information from a colleague. I was clear that obtaining the information was important to me and he made it clear that while he was aware of that, he was not going to share it.

We had a meeting of the minds. It was an agreement to disagree.

My sense was that while he was listening to me and I to him, we were not thorough in our sharing. We had listened to one another’s words. I had listened to my feelings, and they gave me the sense that he had not shared the underlying reason for his position.

I was satisfied that my sense of a hidden agenda was not driven by my disappointment but from an interpretation of his tone and unwillingness to address his motivation. Unless he shares it, I can only guess at his thinking. While we had a meeting of the minds regarding the content, we did not meet on a deeper, more meaningful level.

You might ask, “What does meet on a more meaningful level have to do with project management and performance?” The answer is that when there is unwillingness to honestly share, relationships suffer. When relationships suffer, performance suffers.

Listening is a Challenge

“And for most of us, listening is one of the most difficult things to do. It is a great art, far greater than any other art.” J. Krishnamurti Excerpt from What Are You Looking For?

Listening promotes healthy relationships and optimal performance. But it is a challenge. It requires the intention to actively listen, and the mindful self-awareness to know if you are paying attention or are distracted by our own thoughts and feelings; to assess your patience, and focus.

Are you busily planning what to say next or caught up in judging yourself or others? Are you verifying that the other party has understood what you meant and that you accurately understood what they meant?

For example, I have a habit interrupting others because I think I have understood their meaning before they have finished talking. Most of the time I do understand, and often they are going on and on repeating the same thing. But my interrupting is driven by impatience. It violates one of the most important parts of listening, respecting others’ need to express themselves.

Questions as a Way Of Listening

Working with my impatience (habits are hard to change), I am learning to step back and let the other party speak his piece. If I feel it is useful, I interrupt with a question. For example, “What I think you are saying is … . Do I have that right?” Questioning in this way shows that you are interested in what is being said and gives the other party an opportunity to see if you do understand and to correct or further describe their content. Questioning can also be a way of making sure the other party is paying attention and that there is successful communication.

What if the Other Party Isn’t Listening

Communication seeks mutual understanding. Listening is an individual act. When one party is not listening, communication is limited, mutual understanding is not achieved.

In the midst of conversation, there are ways to manage the situation to get the other party to listen. One way is to stop talking. It gets the other party’s attention and once you have it you can continue. Questioning is another useful way. In this context, you can say “I’d like to make sure I am being clear. Would you mind telling me what you think I’m saying?” Questioning engages the other and lets you know if they were listening and whether they ‘got’ what you were trying to get across. It transforms the conversation from a lecture to a dialogue.

Seek to Improve

In the long run there is a need for training in communication skills.

Start with yourself. Assess your skills, particularly your listening skills, and make a commitment to get them to be as sharp and effective as possible.

Then do what you can to promote effective communication in your team and other relationships. You can raise awareness by implementing a team training or engaging a coach or facilitator.

[1] Oxford Languages

5 Human Interaction Skills Needed for Effective Elicitation

Written by Elizabeth Larson on November 24, 2021. Posted in Articles.

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
[widget id=”custom_html-68″]

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

Written by Elizabeth Larson on November 2, 2021. Posted in Articles.

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.

Advertisement
[widget id=”custom_html-68″]

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:

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.
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.
We need to ensure that the business problem we’re solving and the proposed solution align with the organization’s goals and objectives.
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.