Tag: Elicitation

Add some UMPH to your UML

Written by Kristen Gandier on August 25, 2022. Posted in Articles.

In the world of analysis, at least one thing is true: if you like diagrams, you have probably come to be close with Unified Modeling Language (UML). UML Diagrams are helpful to show flows and relationships of information. This helps to illustrate data points, structure and interactions. Here are some ways to enhance their effectiveness when dealing with stakeholders at all levels:

Clean Connectors

Showing directions and connections is helpful, but connectors crossing over can quickly turn a diagram into a confusing web. Because UML Diagrams can vary in complexity and granularity, crossing streams can be unavoidable. Lines should cross as minimally as possible, but if they do have to cross, they should show as a “hop”. Most programs default to this feature when connectors go through each other without a particularly specified intersection. If connectors are not looking separated enough and have too many unnecessary hops, consider the component or class layout being used and see if the objects/items can be better sequenced.

Connector types should also be utilized where necessary to show the nature of interactions, whether it is to illustrate direction or dependencies. This can allow for some detail that could be taken out of the explanation pieces of your documentation.

Know your Domain

UML diagrams have a specific best-case utility and are strongest when they are describing and modeling objects and displaying aspects of system views. Alternatively, Business Process Modeling Notation (BPMN) helps to show or describe the business process. Understanding how the two differ and how to best use them in your modeling can help to optimize the effectiveness of your documentation and communication. Depending on the project, UML diagrams may be helpful in creating documentation to detail functionality and object interaction. BPMN diagrams can be useful communication aids, especially since they can tailor to the audience; for example, a BPMN that shows a high-level view of the process may be best to use in presentations to individuals that have executive governance in a project.

Speaking of Communication…

Using the correct pieces of UML diagrams can also help to keep any text requirement of information appropriately concise. This means avoiding having to describe your intention of objects or classes to a reader, and instead, simply using the standardized shapes and connectors to represent the information being illustrated. A good UML should have minimal text detail in the itemized areas, and the rest of the information conveyed through the standardized language UML provides.

Requirements Gathering: Pants or not?

Written by Mike Boris on June 22, 2022. Posted in Articles.

It’s been a long time since I’ve had to wear real “business casual” pants to work. Not since the Before Times has a client seen me from the waist down. Well not anymore! For the first time since February of 2020 I will sit down with a client…in person…in a room…with pants on. I can’t tell you how happy that makes me.

We BAs are social creatures. Being locked-up in my house for the better part of 2 years was not…shall we say…optimal. Don’t get me wrong, It was great spending every minute… of every hour… of every day with my lovely wife of 32 years. Really…it was…great. It’s just that I struggled to do my job well… heck, I struggled to get out of bed sometimes.

I have spent 30 years splashing around in the wading pool of process design and improvement…and almost every day was spent interacting with live human beings. A June 1st article in the BATimes by Lee Templeton, listed “10 Soft Skills You’ll Need To Be A Successful Business Analyst” (check it out, it’s a good read). As she points out, these soft skills are people related skills…you know…for working with people. I have these skills! I’m really good with these skills! But now that the world has seen that working from home actually…er… works from home… there’s a perception that getting together in a brick and mortal room is no longer necessary (as if donuts and coffee weren’t necessary). Unfortunately most, if not all, of the skills on the list… the skills I have… suffer in both application and effectiveness during a virtual meeting.

We all know that rapport building is the poster-child for BA skills. It’s number 1 on Ms. Templeton’s list for a reason. We can’t do our job without it. Clients need to trust us. We’re going to get them to air their dirty laundry… to tell us the bad and the ugly as well as the good. They say “you can’t read the room on a Zoom”. A more truthful statement has ne’er been uttered. I need to pick up on the vibe in the room so I can adjust my strategy, delivery, and approach. Where are people sitting? Is their body language open or defensive? Who’s giving furtive glances to whom? Well let’s see…people are sitting at their kitchen tables…their body language is, well …slouchy… and they can’t glance at anyone. Of course, I can see that much only if they have their cameras on! A quick show of hands…who’s had their initial meeting with a group of SMEs where everyone had their video turned off? I swear I lose a little piece of my BA soul every time a window goes dark. Oh, I can build that rapport, and those relationships… eventually… but what I could do in 30 minutes in person can take hours online. C’mon SMEs! I don’t have all day!

Back to the list…Enthusiasm. Great…I’m enthusiastic. This should be an easy one. But just how enthusiastic can I be when I’m a head in a box? I’m talking with my hands like an Italian grandmother…showing how this flows into that, where this step loops back to here…and no one can see it! OK…Creativity… creativity… maybe I should throw up a whacky virtual background… break some ice… get a chuckle from the guy sitting out on his deck. What do I have that wouldn’t A) offend someone, B) make me come across as goofy and unprofessional, (as opposed to goofy but professional?), or C) make my head disappear? Ugh. Boring corporate logo it is.

So what’s a BA to do? Well, we need to Adapt (another soft skill from Ms. Templeton’s list). We need to find new tools and techniques that not only allow us to do what we did in the Before Times, but to do it better. We need to embrace the new reality, jump on the bandwagon, go with the flow, and do some other catchy phrase that hopefully involves the word “paradigm”.

Remote learning for school was the necessity that drove the invention of new types of learning software. The glazed-eye inducing PowerPoint deck was joined by game-based and interactive Q&A platforms, concept visualization tools, old-people-friendly software for creating short videos and animation, and my favorite…virtual whiteboards. I have fond memories of the smell of a new dry-erase marker in a room with whiteboard walls… of gliding around the room scribbling this over here, laying down an arrow to that over there, drawing a cow in the corner while everyone’s on a bio-break…ah, the good ol’ days. But we must Adapt, right?

My first go at Adaptability was to find an online whiteboard. Boy howdy! There’s a lot of ‘em. Here’s as far as I got before succumbing to virtual overload. (deep breath, here we go)… Microsoft Whiteboard… Miro… Explain Everything… TutorialsPoint… Educreations… Limnu… Mural… Groupboard… Ziteboard… ConceptBoard… LiveBoard… StormBoard… ThisBoard.. ThatBoard, and TheOtherBoard… and my favorite “we’ve run out of whiteboard names” board: FigJam. It was interesting to see the differences in functionality…and by extension, the requirements the BAs wrote. Some were straight up blank boards (i.e. lazy BAs), some were big on templates, some had magic Post-It notes, some allowed you to embed files, some had voting and cute little avatars, and some tried to do everything…and failed spectacularly. I even bought a graphics pad and pen to see if my horrible handwriting was just as horrible in the virtual world. It was worse.

OK, so I spent so much time on the virtual whiteboard tool investigation that I stopped there… but my point is that there are options out there for adding virtual tools to our BA toolbox. Software, however, is not a soft skill. It’s only part of the picture. We need to consider what new people skills we might need. One example is Virtual Contributor Management (I just made that up). We’ve all had to deal with the “Dominant Contributor”. You know, the guy who takes over the conversation, is first to jump in with the answer or a comment, and routinely interrupts polite people. He’s hard enough to manage in a room, but in a virtual meeting, he can shut down the highly knowledgeable, but introverted, SME with much greater efficiency and speed (not a process improvement, by the way). We need to learn, and get comfortable with, how best to “mute” a Dominant Contributor (without using the actual “mute” button…although…) and invite others to join in. We also have to sort out the “You go; No, you go; No, you go…” politeness pit of doom. Our audience is now scattered to the four winds, and we have to be able to wrangle them into a cohesive, responsive source of information. What? Are you looking at me for the answer… Good luck because I don’t know. That’s a soft skill I’m working on.

But I don’t need know how to do that just yet, because next week I’ll dust off my neglected khakis, pack up my Big Bag o’ Real World Soft Skills and go meet with actual warm bodies in a real room with a real whiteboard! Maybe I’ll even bring donuts.

Note to self: Socks…don’t forget socks.

Techniques for prioritizing requirements

Written by Aly Cassam on January 13, 2022. Posted in Articles.

One of the major challenges that Business Analysts face is getting stakeholders to prioritize requirements. Everyone is used to high syndrome – where the stakeholders say everything is a high priority.

The key to dealing with this problem is for BAs to understand the drivers of the project and then create priority evaluation criteria to assess each requirement. This is a key step that is often overlooked when starting the business analysis deliverables of the project.

Let’s say the objective of a project is to optimize a business process for an operations group. As a BA it’s important to understand what constitutes an optimized process. It’s a simple upfront question that will surface criteria that the BA can use to help the business prioritize the requirements. For example, the stakeholders may indicate that the optimal process would be one in which the To-Be process has fewer manual hand-offs, reducing the amount of paper that flows through the process, reducing the number of steps requiring manual entry of data, etc.

These criteria can then be used to develop a framework with which to evaluate and prioritize requirements. My preferred approach is what I call the scale approach. With the scale approach, you get the stakeholders to call out how well each requirement aligns with the assessment criteria on a scale of 1,3 and 5 (where 1 means the requirement is poorly aligned with the criteria, 3 somewhat aligned, and 5 highly aligned). This gives a numeric priority assessment of the requirement and a quantitative method of comparing requirements. This helps to get stakeholders out of the “high” trap mode.

Scale Approach:

Here is an example of the scale approach. The scaling approach uses a 1,3,5 scale where 1 is poor alignment, 3 is some alignment (in the middle) and 5 is highly aligned. The max score for any requirement is 15 and the minimum is 3. I’ve tried more granular approaches like 1 to 10…but it just causes a lot more sitting on the fence when you have that many values to apply to a criterion…and it’s not as “distinct” an outcome as the 1,3,5 scale. I specifically avoid using numbers instead of High, Medium, and Low because I find that a numeric approach makes things more subjective than a High, Medium Low evaluation approach.

#	Requirement	Evaluation Criteria 1 (Reduce Manual steps)	Evaluation Criteria 2 (Reduce paper through the process)	Evaluation Criteria 3 (Reduce number of manual steps)	Total Criteria Score
1	Requirement 1	3	5	1	9
2	Requirement 2	5	5	3	13
3	Requirement 3	1	3	1	5
4	Requirement 4	3	3	3	9

Typically, with the above scoring system I would then map it to the more traditional High, Medium, and Low using the following ranges:

Low – score equal to 5 or lower

Medium – score of 6 to 10

High – score of equal to 11 or higher

Based on the above you would then prioritize the requirements as follows:

#	Requirement	Priority
1	Requirement 1	Medium
2	Requirement 2	High
3	Requirement 3	Low
4	Requirement 4	Medium

Heat Map Variation:

Most stakeholders are very visual. So sometimes I’ll combine this with a heat map approach. With the heat map approach, each score on the scale is associated with a color.

Score of 1 – shade the cell red

Score of 3 – shade the cell yellow

Score of 5 – shade the cell green

So, if we take the above example and add colors, it will look like:

#	Requirement	Evaluation Criteria 1 (Reduce Manual steps)	Evaluation Criteria 2 (Reduce paper through the process)	Evaluation Criteria 3 (Reduce number of manual steps)	Total Criteria Score
1	Requirement 1	3	5	1	9
2	Requirement 2	5	5	3	13
3	Requirement 3	1	3	1	5
4	Requirement 4	3	3	3	9

As you can see above – it really jumps out at you that there is a “strong” fit with requirement 2 and a poor fit with requirement 3. I find the heat map approach helpful when there are a lot of requirements because it’s a lot easier to gauge and compare requirements based on colors than numbers. Also, a lot of times with a heat map you don’t need a total criterion score at the end. It just jumps out at you.

You can further simplify things by just using the colors instead of the numbers.

Does it take more time?

The simple answer is no it doesn’t take more time. All it takes is a little bit of prep, a prioritization meeting and then you have prioritized requirements. When you compare that to having numerous emails, meetings, and discussions about what the requirements priorities are you’ll see it’s a much simpler and effective approach. It also forces stakeholders to really think about the requirements and how they want to achieve their objectives – so less second-guessing of requirements in the future.

One final note:

When I use this approach, I put the actual scoring matrix into the appendix of the requirements document and not in the main body to enable a wider audience to more easily read the requirements document.

Critical Skills Needed for Project Success

Written by Elizabeth Larson on November 4, 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.

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.

M_SSING Context

Written by Divya Kishore on November 3, 2021. Posted in Articles.

Have you ever had a conversation where the context was missing? Have you considered going the extra mile so that everyone has the same viewpoint?

Let us look at the scenario below:

*Person A and B are looking for the same flour brand at a grocery store.

At a grocery store:

Person A: Hello! Would you know in which aisle can I find ABC brand flour?

Store employee: I am sorry, we are out of that brand.

Person A: Thank you!

*END OF CONVERSATION 1*

At a grocery store:

Person B: Hello! Would you know in which aisle can I find ABC brand flour?

Store employee: I am sorry, we are out of that brand.

Person B: Thank you! Would you know if there are other brands of flour? I need the flour for a craft project.

Store employee: Aisle 15 is where you can find all the brands of flour. Any brand would work since you need it for a craft activity. If you would like, feel free to check aisle 20 for craft supplies.

Person B: Thank you so much!

*END OF CONVERSATION 2*

One requirement yet different experience. For a fruitful conversation, all the participants must have the same understanding. The team must work based on the same set of assumptions. How can you ensure the team is on the same page? Start by asking questions. It is second nature for a business analyst (BA) to ask questions. Asking questions merely to extract information does NOT help uncover the detailed requirements. As a result, lack of details could often lead to misinterpretation and miscommunication.

Here are a few ideas that can get everyone on the same page and their benefits:

1. Provide a brief background about why you are asking the questions.

E.g., Instead of asking the stakeholder what is the current billing process? You can ask, “I would like to understand how is billing done? What are the pain points? What are the components of the process that would need to stay in the new application? Comprehending the as-is state will help understand the gaps and offer solutions.

2. A Business analyst (BA) can ask contextual questions to stakeholders. Stakeholders must reveal details without holding information.

Tip: Share these questions ahead of a conversation with a stakeholder. The stakeholders can organize their thoughts and come up with a list of questions if needed.

Bonus: A BA can offer alternative solutions if they have the same background as the stakeholders.

3. Providing context paves the way for sharing real-world examples by stakeholders. These use cases aid, everyone, on the team in visualizing the user’s world. Based on the second conversation above, it is evident that there are more use cases to flour than cooking.

4. Let us change gears from the stakeholders and talk about the team. When team members have the same context, they can ask questions amongst themselves to strengthen their understanding.

Conclusion:

Next time around, be it any conversation, make a conscious attempt to explain why you need what you need? That helps the other person understand your perspective and intent. After all, one term can have multiple meanings depending on the context used. The context can change the entire landscape of the conversation.

“For me, context is the key – from that comes the understanding of everything.” – Kenneth Noland.