Skip to main content

Author: Elizabeth Larson

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is a consultant and advisor for Watermark Learning/Project Management Academy, and has over 35 years of experience in project management and business analysis. Elizabeth’s speaking history includes keynotes and presentations for national and international conferences on five continents. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 6 grandsons and 1 granddaughter.
PMTimes_July13_2022

The Courage to Try Something Old – Part 1: Facilitation

Written by Elizabeth Larson on . Posted in Articles.

We know that it often takes courage to try something new. But what about trying something old? Sometimes it takes courage to do the basics, things that we know work, but for a variety of reasons are deemed to take too long or seem too “old school.” Often the old ways are not welcome. To be sure, the old ways do not always add value. But when they do, it can take courage to convince the organization that it’s worth spending the time. The first one of these oldies but goodies that I will address is about facilitating requirements meetings. Even the concept of a meeting seems a bit old school, and when you add on the discipline needed to successfully facilitate, it can seem insurmountable.

The glorious thing about requirement meetings is that rather than interviewing many stakeholders separately, which is time-consuming, we can get the stakeholders together. It’s a chance to get issues discussed, questions answered, and direction set. But stakeholders may come unprepared or with hidden agendas. There are usually different personalities and communication styles which cause different types of disruption. And it takes courage to take the time to successfully facilitate. It takes courage to keep the meeting focused. Here are three tips that will provide you courage and increase the likelihood of success.

 

Preparation. No matter how experienced we are, no matter how many meetings we’ve facilitated, no matter how many disruptive stakeholders we’ve encountered, we face new challenges each time we facilitate a requirements session. We can’t eliminate the disruptions, but we can minimize their effect. Thoughtful preparation with the appropriate stakeholders will help us go into each requirements event with confidence. Minimally, we need enough preparation to communicate the following before the meeting:

• Objective. This is an action, stated as a verb. Examples include: to resolve issue(s), develop a process describing a current or future state, review the results of an iteration/phase, or project.
• Desired outcome. This is a thing, stated as a noun. Examples include: decisions, issues, parking lot topics, requirement models and lists, story maps, flows and other diagrams, user stories, action items, follow-up items, and responsibilities, to name a few.
• Attendees, prep work needed of each, and expectations for their contributions during the meeting.
• Topics to be covered, who owns the topic, and approximate time to be spent on each.
• Tools and techniques to be used and how, when, and by whom.

 

Advertisement
[widget id=”custom_html-68″]

 

Meeting agreements (ground rules, protocols). The ability to keep focus during the session requires the use of meeting agreements, or ground rules. Throughout the years we have tried to soften the use of the term “ground rule,” maybe because “rule” seems so inflexible. Regardless, these agreements help keep us grounded. Getting participants to establish and then follow them, though, is tricky but necessary—necessary because disruptive participants can make everyone miserable. If we call out the disruptor, we risk breaking the safe environment and having the other participants shut down. If we do nothing, we will not successfully meet our objectives. There is no one right way to handle disruption. What has worked best for me is to anticipate disruption, include it in the prep work, and hold pre-meetings with those most likely to be disruptive. And the use of a parking lot can be one of the many agreements established.

 

Quick decision are not decisions. The final thought is that decisions cannot always be made during the meeting. There are a myriad of reasons why trying to curtail discussions and move forward will result in frustration and future changes. We can’t demand that decisions be during the meeting. But we can have a tentative agreement, and then it’s up to us to check in with reluctant participants as needed.
Sound a bit old school? Yes, of course. These are techniques that have been around a very long time. But they work.

We tried getting rid of meetings, and that didn’t work. We tried getting rid of meeting agreements. Chaos. We tried getting quick decisions, only to be blindsided and saddled with rework later. Sometimes the old is not the most popular, but it is the best approach, even if it takes courage to get people on board.

 

[i] I use the terms requirements meetings, sessions, events, and workshops synonymously.
[ii] I once suggested the use of a parking lot and some of the attendees didn’t know that it was a list of tangential topics that would be handled outside of the meeting or at a future one. They thought that we were actually going to meet in the company’s parking lot!

Critical Skills Needed for Project Success – Part 2 Translation

Written by Elizabeth Larson on . Posted in Articles.

This article is part of a series and presents the second critical skill that all project managers (PMs) and business analysts (BAs) need for success. This one is about the importance of being able to translate technical complexity into business language. As the technology in organizations has become not only increasingly important to its success but also more complex, the need for business stakeholders to understand its true value has increased accordingly. Both PMs and BAs need to talk to their stakeholders about technology, its use, its value, and the results it produces. The language they use has to be about both the technology and the business and be stated in terminology that stakeholders understand.

BAs have always been translators. From the early days of business analysis to the present we have translated business requirements into specifications that could be designed, built, tested, and delivered. But translation has never ended there. We take technical designs and specifications and translate them back to the stakeholders to be sure they understand what they’re actually getting. We have been translators as technologies and methodologies have changed. So being a translator is nothing new. What’s new is that with more complex technologies like AI, the importance of translation is being recognized.

Advertisement
[widget id=”custom_html-68″]

Years ago I started a new job as a PM. The team was full of technical jargon when they talked to me (OK) and in their discussions with stakeholders (not OK). I encouraged them to translate what they were saying into business language. So instead of talking, for example, about DB14 or problems with Joe’s program abends, I encouraged them to translate these issues into business language–to talk about Price information and how to fix the results caused by program errors. At first there was resistance, but gradually there was a focus on the business and not the technology. I’m not sure the team was entirely bought into a business focus. After all it’s cool to be able to talk techie. But I had several sponsors comment on the positive change.

The fact is, the more complex the technology, the greater the need for us to help stakeholders understand our elicitation questions so that they can make good business decisions and understand the ramifications of their decisions.

OK, so BAs have always been translators. What in it for PMs? We PMs spend lots of time with our sponsors and executives. I know how tempting it is to try to impress them with our technical prowess. We can easily fall into the trap of  thinking we’re adding to our credibility by showing how fluent we are in the technical language. But far more impressive is understanding the technical terms and concepts well enough to clearly explain how the technology provides value to the organization.

To be successful translators, we need to understand not only the technology, but the business, including the industry, the organization’s goals and objectives, and the specific business area. But what does “understand” mean? On an AI project, for example, we don’t need to understand the details of model creation, but we do need to know that the algorithms being used further the business objectives. We need to be conversant enough in the technology to formulate our questions as well as answer questions that arise.

3 techniques for effective translation

Visual business models are among the best tools for the translator. Process, data, use case, and prototype models help the technical staff better understand the business requirements. Models abstract detailed information and present it in a way that’s useful to all audiences. Abstraction, of course, is the process of filtering out extraneous information, leaving only the essential details. Most people find models way more useful than requirements written in a lengthy list of “shalls,” which is how we used to document them.

When we translate, we also need confirmation from the business. Visual business models help translate back from the technical to the business stakeholders. The emphasis, of course, is on business models, because we don’t want to hand technical specifications or designs to our stakeholders without translations into business language.

Synthesis. Being able to translate means we need to take in a lot of information at once and almost instantaneously sort through it, discard the extraneous, and present the most important concepts. What helps us is understanding the context of the topic at hand. And we need both business and technical context. This allows us to take disparate facts gotten in previous conversations and put them back together in a framework that helps the business understand what we’re talking about and how they’re going to get value.

Elicitation. In Part 1 I covered elicitation, saying that we ask questions and listen to the responses, and that’s how we learn. There are times during translating when we need elicit information. For example, if we’re providing stakeholders information on AI results based on the algorithm used to create those results, we may want to ask the model creators why that algorithm was used or how it helps the business. Once we have this information, we can be confident that our explanation to the stakeholders is both technically accurate and valuable to the business.

Translation is critical to project success. It’s one of those skills that sounds easy, but which takes knowledge and a mastery of various skills. Translation is part of what distinguishes us from the order-taking BAs and PMs who are less valuable to our organizations.

5 Human Interaction Skills Needed for Effective Elicitation

Written by Elizabeth Larson on . 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 . 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:

  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.

Three Lessons in Courage from The Green Knight

Written by Elizabeth Larson on . Posted in Articles.

There are many ingredients that enable us to influence others, including perhaps the hardest to achieve—courage. Unless we have the courage to recommend the right things for our organizations, to speak out when we think our stakeholders are on the wrong path, and to promote workable solutions that are unpopular with executives, we cannot hope to be influential. As PMs and BAs we need to be able to influence others as part of our job. And that takes courage.

I have always loved fantasy books/movies as well as those where the characters grow because they have found the courage to complete difficult tasks. That is why the Lord of the Rings trilogy has always been one of my favorites. And I remember loving the fourteenth-century poem that I read decades ago in college, Sir Gawain and the Green Knight. Seeing the movie The Green Knight, which is based on that poem, reminded my why—it’s a fantasy story about courage.

Sir Gawain, a knight in King Arthur’s court, undertakes a treacherous journey to fulfill a promise. The story is about integrity, knowing what is right and wrong, and making and meeting commitments—and the consequences of not doing so. There are many lessons BAs and PMs can learn about courage from the story. I’ve chosen 3 to discuss here.

Lesson #1 – It takes courage to make commitments

The story. The poem begins on Christmas when King Arthur’s knights and relatives are gathered for a feast. Among the knights is Sir Gawain, the king’s nephew. Then an uninvited guest, a green giant riding a giant green horse and wielding a giant green axe barges in and addresses the king and guests with a challenge: “Who will take this axe and cut off my head? If you accept this challenge, you must meet me in a year at my green chapel. At that time I’ll decide whether or not to cut off your head.” No one says a word. “The Green Knight taunts the gathering– I have heard so much about the bravery of King Arthur’s knights. Not one of you is has the courage to accept this challenge?” Finally, Sir Gawain does so. He takes the axe and lops off the head of the Green Knight. To everyone’s amazement, the Green Knight picks up his head and rides off, reminding Gawain to meet him in one year. By accepting the Green Knight’s challenge, Sir Gawain makes a serious commitment. Although he has no idea of the specifics of the difficulties he will encounter along the way, he knows the end result may be his death.

Lessons for BAs and PMs. We may not always realize how important it is to make commitments. I had a boss who never had to meet commitments because he never made any. Making commitments can be scary. Those of us who have been in meetings with intimidating executives know how hard it can be to speak up when presented with unreasonable expectations. We need to let our stakeholders know that we must do our homework before making commitments. But we cannot avoid making them altogether.

Lesson #2 – It takes courage to be transparent about what prevents us from meeting those commitments

The story. On his way to fulfill his promise to the Green Knight, Sir Gawain stops at a castle where most of the poem takes place. The castle is owned by an unnamed lord and his wife. The lord, who we later learn is actually the Green Knight, is a great hunter and makes a bargain with Sir Gawain: “Whatever I capture on the hunt will be yours,” he says, “but you’ll have to give me whatever you get here in the castle.” Sir Gawain agrees to the exchange. While the lord is out on a hunt, his wife urges Gawain to take a green sash. She says if he always wears it, he will be protected from all danger. Reluctantly Gawain takes it but keeps it a secret from her husband. The lord tells Gawain that he knows about the sash and that his wife was sent to test Gawain’s honor. Gawain knows he has failed the test.

Lessons for BAs and PMs As PMs and BAs, there are almost always unexpected issues that arise that can prevent us from meeting our end of the project “bargain.” We often ignore these issues thinking they will resolve themselves. When these issues get in the way of our commitments, we think of lots of reasons not to tell our sponsors. We don’t want to let them know that their expectations, for a variety of good and not-so good reasons, will not be met. It’s easy to be guided by the faulty thinking that we can make up that time or that the sponsor will never find out. I have found, however, that sponsors generally admire transparency, as painful as it sometimes is.

Lesson #3 It takes courage to volunteer for difficult tasks. However, the inevitable pain can be mitigated by courageously admitting problems and errors as they occur.

Advertisement
[widget id=”custom_html-68″]

The story. At the beginning of the poem, before the Green Knight interrupts the festivities, King Arthur wants to hear of brave deeds done during the past year. Unlike the other knights, Sir Gawain has none to relate. He realizes that to attain his goal of becoming a legend, he will have to endure pain and put his life in danger. So when the Green Knight challenges the court, Sir Gawain knows he has to accept that challenge. Sure, it may cost him his life, but it’s his best chance to become a legend that will endure throughout time.

When Sir Gawain, thoroughly ashamed of his cowardice, faces the Green Knight, he offers to return the green sash. The Green Knight tells him to keep it as a reminder of disloyalty and dishonor. The Green Knight does not kill him. He knicks his neck and admonishes him to remember the lessons he’s learned.

Lessons for BAs and PMs As a BA I once worked for a PM who used to dread being assigned large, visible projects. He thought of them as dragons peering around the corner of our cubicles. You could see the head and that was scary enough. But once more of the project/dragon was revealed, it would be larger and scarier than anyone could imagine. I’ve always enjoyed challenging projects but not the pain that invariably accompanies these efforts —dealing with conflict, scope creep, missed deadlines, stakeholders unhappy with the final product, stakeholders not believing the results are accurate, sponsors happy with the project, but unhappy stakeholders and team members who were not– or vice versa. Volunteering for difficult tasks with the knowledge that they will be painful at times may seem foolhardy. But the if we face our mistakes, conflict, unforeseen delays, and stakeholders’ dissatisfaction with courage, we just might earn respect and positive recognition, and we will likely be highly sought-after for future initiatives.