Skip to main content

Tag: Facilitation

BATimes_June27_2022

The Strawman: When a Wrong Makes a Right

Written by Anna Rajander on . Posted in Articles.

Sometimes, the easiest way to find out what someone really wants is to show them what they don’t want.

The strawman approach is frequently used by business analysts – sometimes knowingly, and sometimes not. Actively inviting stakeholders to engage with and criticize an inaccurate reflection of requirements can provide insights that greatly speed up the requirements elicitation process. However, it can also be a risky approach.

This article describes that strawman approach, its potential pitfalls, and tips for using the approach to support productive requirements elicitation.

What is the Strawman Approach?

You may have heard of a strawman argument – an argument that distorts an opposing stance to make it easier to attack [1].

In business analysis, a strawman can be created by presenting knowingly incorrect, incomplete or distorted requirements to stakeholders in order to provoke a response. This is usually done in the form of a model or prototype solution, providing a visual representation that stakeholders can engage with and refute. The idea is that the way stakeholders respond to the inaccurate strawman will inform more complete, coherent and representative stakeholder requirements.

Stakeholders often find it difficult to articulate their requirements. They can be vague when it comes to specifying their wants (I want a bright color…), yet very specific when it comes to specifying what they don’t want (…but not pink!) This is because people often find it easier to specify their wants and needs in opposition to something. In such cases, presenting an inaccurate or incomplete model/prototype representation of requirements as a strawman can provoke a strong response from stakeholders, creating a better understanding of what they don’t want, and providing a starting point for conversations about what they do want.

 

Advertisement

 

The Pitfalls of the Strawman Approach

While the strawman approach can be a powerful requirements elicitation technique, the approach should be used with caution. Some of the potential pitfalls associated with using a strawman include:

  1. Impact on your credibility: When done right, presenting a strawman to stakeholders can make a business analyst appear open, co-operative, and responsive to stakeholder needs. However, presenting something that is clearly wrong can also impact a business analysts’ credibility, leading some stakeholders to question the analyst’s abilities.
  2. The strawman becomes the answer: The point of the strawman is that it isn’t accurate! You want stakeholders to refute it and provide information that will allow you to change and/or improve it. However, in cases where stakeholders really do not know what they want, they may not challenge the strawman. This could lead to the strawman (either in part or whole) becoming the answer.
  3. The business analyst can feel exposed: Presenting a strawman is not an easy thing to do. It takes a degree of professional courage to produce a piece of work and present it, only to have it criticized – even if that was the intention.
  4. Some stakeholders are too nice: Some people find criticism difficult and may be unwilling to say what they really think about a strawman, particularly when they are being asked to criticize it in a group setting.

Tips for using the Strawman Approach

The following are a few tips to consider when using a strawman to elicit requirements:

  • Do you research. Make the ‘strawman’ as accurate as possible. Differentiate between elements of the strawman that are based on known, more accurate requirements, and those that are ‘best guesses.’
  • Know your stakeholders. Think about how your stakeholders might react to the strawman. Think about how you present the strawman to different stakeholder groups. Consider presenting the strawman to ‘friendly’ stakeholders 1-on-1 to get feedback to improve it, prior to exposing it to more influential stakeholders and/or a larger group.
  • Acknowledge it is a strawman. Sometimes acknowledging what you are presenting is a ‘strawman’ will give stakeholders the permission they need to constructively criticize it.
  • Don’t rely on it. The strawman approach should not be used as a primary requirements elicitation approach, but rather a tool that may be deployed to elicit those more subjective requirements, engage a particular stakeholder group, or as a check for validating what you know and what you don’t.
  • Clearly label your strawmen. Once in the wild, the strawman can obtain a life of its own, being reproduced and/or discussed in unintended places. Therefore, it is important to clearly label, store and/or otherwise indicate the strawman is a draft, prototype or experiment.
  • Don’t take is personally. Remember, the stakeholders are reacting to and criticizing what is presented to them – not you personally!

 

Reference
[1] Strawman Arguments: What They Are and How to Counter Them – Effectiviology, www.effectiviology.com/straw-man-arguments-recognize-counter-use/
BATimes_June22_2022

Requirements Gathering: Pants or not?

Written by Mike Boris on . 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?

Advertisement

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.

BATimes_May19_2022

Don’t. Step. Back.

Written by Christina Lovelock on . Posted in Articles.

‘We need to take a step back’ is a common phrase amongst BAs, and while the intention is understandable, this entreaty simply isn’t helping.

You know the feeling.

  • The project is already running away with itself.
  • Stakeholders have identified a solution before articulating the problem.
  • This great new idea does not align to strategy or objectives.
  • The CEO wants to implement a system they’ve seen work elsewhere without understanding our context and challenges.

 

You know we need to calm down, think logically, act rationally. In every meeting, you want to say things like:

  • We need to slow down
  • What about the bigger picture?
  • Let’s go back a step.

But no one wants to hear that.

The start of initiatives are about energy, motivation and enthusiasm. BAs can be seen as blockers. What we think is pragmatism can be interpreted as negativity.

 

Restraining Language

When BAs are constantly using language which is perceived as holding back progress, stakeholders begin to avoid us, work around us, and don’t include us in discussions where we could offer a valuable perspective. BAs then become increasingly worried and frustrated, and our warnings become more dire and more persistent.

It can look like our input is focused on restraining the initiative and identifying additional work.

Is it possible deliver the same information in a more impactful way?

Advertisement


Examine Our Role

BAs often feel we are the conscience of a project, and our job is to protect stakeholders and the organization from poor decisions. Is that a reasonable expectation to set for ourselves?

Trying to reign-in a project which has senior backing, forward momentum and is moving at pace is perhaps not the best way to expend our energy. It’s OK to be on board with an idea and to be enthusiastic. We don’t have to ensure every ‘lesson is learned’. It’s more important that the project benefits from an engaged BA that is consulted at the appropriate time and is seen as someone who is contributing to moving the initiative forward.

 

Enabling Language

Swapping our restraining language for forward-focused language may not be as difficult as we think.

Instead of “We need to take a step back” we can say “We need to be clear on the best next step”.

Instead of using “Yes, but….” to list off all the problems, we can use “Yes, and…” to keep our contribution constructive.

We can use language that says I’m onboard with this project, I want to see it progress and my contribution helps move us forward.

BAs can sometimes see positivity as naivety. It is possible to be positive and well informed. We can use our experience to help projects avoid potential pitfalls, without insisting on a backwards step.

 

Conclusion

BA don’t need to single-handedly restrain projects. In fact the best way to influence projects and products in the right direction is to demonstrate that we are invested and enthusiastic about the outcome.

Language matters. Swapping restraining language for enabling language shows our stakeholders we care, we understand and want a positive outcome. There may still be difficult messages to deliver, but  we can frame these as future-facing hurdles to overcome rather than backwards-facing steps to make.

Techniques for prioritizing requirements

Written by Aly Cassam on . 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.

Advertisement

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.

Avoiding Communication Gaps

Written by Kristen Gandier on . Posted in Articles.

Information is critical to successful change in organizations. How information is communicated can either significantly propel or break down a project. Business Analysts have a critical role in facilitating and influencing communication to impacted areas of the organization. Without a communication skillset, Business Analysts risk being the weakness in the linkage system organizations need for synchronized transformation.

Here are some communication gaps to avoid as a BA practitioner:

  1. The “Barrel Ahead” BA

Each organization has its own pace and comfort zone. When working with stakeholders and business partners, it is important to understand all aspects involved in a potential change. This includes awareness of culture, capacities, readiness, and even other initiatives that are also on the move that may pose distraction or compete for resources. An essential aspect of communication for Business Analysts is listening. Effective listening includes reserving judgment and knowing your audience to form appropriate responses to encourage engagement.

A Business Analyst that is only focusing on pre-conceived outcomes of initiatives poses a risk to not only the stakeholders but to the ultimate success of the outcome. Rushing through steps can also create risks of knowledge gaps and missed requirements.

Pace is significant to initiative success, from framework to implementation. “Tunnel vision” and a too-rapid approach to simply reach the finish line can be easily identified by stakeholders in poor communication, which can then break down engagement and crack the important foundation of trust.

Advertisement

  1. The “Non-Organization Structure” BA

Every organization has a different blueprint of business areas, information, and involved systems. Resources can exist in physical forms such as a database or library, or be integrated within individual knowledge or entire business units. It is important for Business Analysts to understand the organizational landscape so communication can be appropriately deployed. Being an effective Business Analyst includes being able to “bridge” organizational areas, and knowing their structure, purpose, and goals helps to create a solid base for communication.

Not taking the time to understand or learn about the organizational structure can be a risk to the governance approach of a project. Creating and sending communication to the wrong decision-maker can not only create problems within an initiative, but it can also create inter-organizational conflict.

  1. The “Isolated Island” BA

Teamwork is essential to successful change. This is likely why “Elicitation and Collaboration” are paired together in the BABOK. Having stakeholders and business partners appropriately engaged moves the collective pieces of the organization successfully through changes. Having the correct approach to stakeholder communication can set the stage for continuous involvement and support.

While some organizations have Business Analyst roles in various layouts, whether you are on a team of same titles or spread out as a function within various areas, it is important to keep a level of connectivity with all business partners. Business Analysts do their best when they keep avenues of collaboration active with well-fed communication. Active communication helps to reinforce organizational awareness and also creates proactive project efficiencies. Approaching initiatives as a single-ownership can erode stakeholder engagement, as teams may see goals overshadowed by interest in individual portfolio rather than a true business need.

More Than the Destination

Informed stakeholders are comfortable stakeholders. From the start of planning the Business analysis approach to evaluating solutions, communication is essential for teams to successfully meet and satisfy business needs.

Facilitating a collaborative, informed, and trusted environment will help the organization get the most out of not only the outcome but the journey.