Doing Better Brainstorming: A Business Analyst’s Guide

Instead of a “go with the flow” approach to brainstorming sessions, arm yourself and your team with brainstorming best practices guaranteed to give you results. Business analysts must learn to be intentional in their brainstorming to generate worthwhile, actionable ideas consistently.

Here’s how to lead more productive brainstorming sessions.


Take Care of the Logistics

First, you must take care of the brainstorming session logistics. Sometimes, spontaneous brainstorming sessions are necessary, but they should be few and far between. Instead, you should walk into most of your meetings with a plan.

Determine how long your session is going to last and where you’re going to hold it. Decide who is going to attend. Name your notetaker, facilitator, and timekeeper. Create an agenda or outline to distribute. And be sure everyone has access to and knows how to use the tech tools you’ll be using.

Also, come to every session with a clear purpose.


Come to Every Session With a Purpose

One of the worst things you can do in a brainstorming session is go into it without a clear goal or objective. Instead of developing solutions to problems or tangible ideas, you’ll have a lot of random conversation that ultimately goes nowhere.

Every time your team comes together to brainstorm, there should be a straightforward goal you’re trying to achieve. For example, are you trying to solve a problem? Do you want to determine the next steps at a project’s checkpoint? Are you there to mull over a new direction?

Make your purpose clear to the team, and let that purpose lead your brainstorming session.

Consider the Personalities in Attendance

It’s also wise to consider the personalities of the people you’ve invited to the brainstorming session. How you approach brainstorming with a group of extroverts will be different than how you facilitate brainstorming with a mixed crowd or one made up of reserved individuals.

Equally important is your personality and how you can use your strengths to facilitate a successful session. For instance, let’s say you’re introverted. Introverts are typically laid back and quiet, but can absolutely still be successful team leaders. So, play to your strengths.

Write your main speaking points down on paper so you don’t forget them. Use your exceptional listening skills to absorb everything thrown out in your session. Find opportunities to connect with people one-on-one and empower them.


Encourage Everyone to Participate

Considering everyone’s personality is also a good idea because you can make the brainstorming session more welcoming for each person when you know how they operate. And that, in turn, furthers your effort to encourage everyone to participate.

Set ground rules for brainstorming. It should be a no-judgment zone. Welcome every idea regardless of how crazy or out of the box it may seem. Allow everyone to express their creativity and experiences.

Moreover, everyone should have an opportunity to share. When someone starts dominating the conversation, politely interrupt them and ask others to contribute. You could even use a timer to ensure each person has equal time to express themselves.




Experiment With Tried-and-True Brainstorming Methods

Experimenting with different brainstorming methods can get the creative juices flowing for your team too. There are many tried and true brainstorming strategies to sift through until you find one or a combination that works for the individuals in your session.

Mind-mapping is one brainstorming method to try. You start with a main idea and generate sub-topics surrounding that central subject. Then, you come up with smaller ideas around those sub-topics. Finally, connect your ideas with lines, and you’ve got a mind map.

It’s an incredibly flexible brainstorming technique that allows for a surplus of creativity and idea generation in your session.

Here are a few other brainstorming methods to try:

  • Modified design sprint
  • Brainwriting
  • Stepladder technique
  • Round-robin brainstorming
  • Rapid ideation
  • 5 whys analysis

Leave Each Session With an Action Plan

Many people deem brainstorming sessions ineffective because nothing comes out of them. In other words, teams are leaving meetings without an action plan. So, all of the ideas generated in these sessions live out the rest of their days in a file on your computer instead of in the real world.

Each idea or solution your team voted to move forward with in your brainstorming session should be accompanied by an action plan. You, your notetaker, or facilitator can take the lead on creating this action plan.

Document next steps and assign someone to each step. Put a deadline on each step and when you want the action plan completed in its entirety. And don’t forget to follow up on each action plan to ensure it gets done.



Business analysts need brainstorming to excel in their roles. If your sessions have been less than productive so far, use the tips above to elevate them and come out with real results.


The Strawman: When a Wrong Makes a Right

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.




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!


[1] Strawman Arguments: What They Are and How to Counter Them – Effectiviology,

Analysis Efficiencies: Turning The Mirror On Ourselves

As analysts, typically we’ll spend a lot of time examining and critiquing the processes of other departments. We might be looking for ways to make an operational process slicker, quicker and ‘better’, or we might be looking to solve particular problems. There are a whole set of elicitation, problem analysis and process analysis techniques in our toolkit that help us do this. Yet how often do we turn these tools in on ourselves to examine our own practices to see if there are ways that we can improve? As practitioners of change, surely we should be looking to continually improve ourselves too?

I suspect we all intuitively do this, at least to a degree, but I wonder if it’s an area where there’s room for improvement. I’ve included some examples to whet your appetite below:


  1. Deciding How To Decide: Have you ever got to an approval gateway in a predictive (waterfall-type) project and it’s unclear who needs to make the approval? Or the approver shirks responsibility? This can manifest differently on adaptive (agile/evolutionary) initiatives, for example with wrangling over the ‘definition of done’ with different stakeholders having different (and unresolved) perspectives. These things can fester if unresolved, perhaps stakeholders concede in the short term and sign on the dotted line, but resentment builds and bubbles up, only to explode out later at the most inconvenient time.


This creates friction and drama that takes time to resolve, and when it comes to organizational change, time is money. It’s therefore beneficial to spend a little bit of time up front agreeing how these types of decisions will be made. This sounds so obvious doesn’t it? Yet, so often in the blind rush to “just get going” it isn’t discussed… and it is only as the decision emerges is the omission spotted.  Practical tools such as the RACI matrix can be extremely useful here.




  1. Planning the Requirements Architecture: When BABOK® v3 was released back in 2015, one of many significant additions was a more explicit recognition of requirements architecture. If you have ever found yourself mid-project with a whole set of useful, but disparate requirements artifacts (“These process models are great. But how on earth do they relate to those user journeys, these scenarios and those wireframes?!) you’ll know what I mean.


Taking time up front to quickly and roughly sketch out how it’s anticipated that the requirements will fit together helps avoid this. Of course, things change, as requirements emerge, new types of artifacts suddenly become relevant (“Ah, so statuses are important… I think I’ll include a state transition model…”), however having a starting point to deviate from when appropriate is better than fumbling around in the fog.

On a legislative project, you might write a quick problem statement to act as a high-level goal/outcome, and define some critical success factors/key performance indicators which will act as desired outcomes. These will all link to the organization being compliant with a piece of legislation, that’s another (external) artifact, but one which some rules can be derived from. Those rules will include internal decisions about how the legislation is interpreted; so those probably need to be captured too.  Those rules might be automated or orchestrated via processes, and there might be steps in a process which will be automated via some detailed functional solution requirements.  You can see how these different concepts relate to each other here; and of course there will be other types of artifacts too.  The point is that creating a quick sketch showing how the concepts map together before creating them will prevent artifacts from being created that don’t clearly relate to each other.


  1. Planning How To Store/Manage Requirements Artefacts: If you’re lucky, you’ll have some form of requirements (or story) management tool. If that’s the case, does everyone actually know how to use it? Is there a common agreement around how things like priorities/statuses and other metadata will be used? If not, will this create noise and friction as the initiative progresses? If so, a short discussion up-front is likely to yield significant benefit.

If you are using documents and a shared document repository (e.g. word processing tools, drawing tools, spreadsheets etc.), decide things like naming conventions and version control conventions up front. It can be very confusing when someone in the team is using a file naming convention that uses “v0.1”, “v0.2” then “v1.0” when it’s signed off, when another person is using “FILENAME v1.0 (Updated) (Second Updates) (Final) (Really Final This Time) (Updated Again).docx”


  1. Plan For The Analyst And Stakeholder Of Tomorrow: Stuff you’re creating today will be useful for the analysts and stakeholders of tomorrow. That process model you’ve created? If it’s detailed enough, I bet the training team would love to use it, and the operations team might too. It might be the catalyst to the creation of a single, unified process repository (if that doesn’t already exist in your organization).

Those performance non-functional requirements for your customer-facing website?  You know, the ones that were like pulling teeth to elicit, that required benchmarking and speaking to the technical folk? They might be a useful baseline and starting point for others producing customer-facing web applications within your organization.

As we create artifacts, we ought to be thinking not just about how they can be used today, but how they might be used tomorrow and how we can ensure they will be found.  This is a much bigger, organizational, question—however it’s one of the many areas where BAs can nudge the agenda. By creating common pools of knowledge, and by encouraging information sharing we open up channels for these types of artifacts to flow. This has the advantage that information flows in both directions and also that there will be a wider range of documents available at the start of projects too.

Of course, these are only four suggestions, there will be many more. The key is that we shouldn’t rest on our laurels; as BAs we should be looking to hone our craft and improve the efficiency and effectiveness as much as we can. This involves not just “speeding to get the job done”, but also thinking about the stakeholders of tomorrow!


Requirements Gathering: Pants or not?

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.


Establish Your BA Practice from Scratch

I have had the opportunity to establish BA practice within an organization a few times. After first time doing BA practice establishment, I have summarized a toolkit for myself, which in turn helped me setting up BA practice more consistently and effectively. If you are looking to set up your own BA practice, regardless of the organization that you work at, I believe you can benefit from this industry-agnostic BA Practice framework.


Element 1: Streamlined Onboarding

Well began is half done. Onboarding starts when offer is accepted. Trigger IT equipment and system access provision process as early as practical. Consider including any additional productivity equipment, such an as additional monitor, in the IT equipment provision.

The week before new joiner commencement, give them a call to understand their need, questions or concerns regarding onboarding. A phone call, although old-school, will give the new employee a good human-to-human style start. On or prior to day 1, send out all business unit wide email to announce the new starter.

Schedule one-on-one “causal catch up” at the start time on day 1, and project introduction meetings right after, to make new starter feel welcome and cared into new environment.

Make sure you do everything above in a remote-friendly way. Remote working is here to stay.


Element 2: 90-Days Action Plan

If you fail to plan, you plan to fail. Planning is always the best quality assurance. Set up a 90-day plan with the employee and you both stick to it. Focus on both performance and professional development. Regularly review progress with your new starter.


Element 3: Scheduled Communications

“A manager in need is a manager indeed.” (by Lawrence Dong). To avoid the situation that you are too busy to attend to your employees’ needs, schedule communications in advance so that you will have time for this important matter. Apart from the performance review conversations, the most obvious communications opportunities include:

  • Manager/Employee 1:1
  • Regular team meetings

Set them up in an appropriate and recurring way.


Element 4: BA Skill Matrix and Career Levelling

Business Analyst, like most other jobs, can and should be measured at work. For all the right reasons, it is critical to provide a fair and equal path to everyone. In order to give a chance to everyone’s career progression, it is fundamental for the manager to acknowledge the existence of different career levels and skill levels among their employees.

An example of career levelling could be:

  • Junior BA
  • Intermediate BA
  • Senior BA
  • Lead BA
  • Etc.

And an example of skill matrix could be:

  • Requirements gathering (1 out of 3)
  • Process mapping (2 out of 3)
  • Stakeholder management (3 out of 3)
  • Etc.

It is worthwhile to mention that the entry criteria of a particular career level may consist of more than skills and deliverables. Behaviors and collaboration are equally important, if not more.


Element 5: Templates and Processes

Consistency is key to high quality customer experience. With BA templates and processes put in place, effectively there is less room for confusion in “what should be delivered and how”. Just make them easily accessible to the team.


Element 6: BA Services Catalogue

Business analysis work is sometimes dynamic and self-evolving. From a SDLC perspective, BA’s may benefit more than other from a well-defined BA Services Catalogue, whenever there are questions about the boundary of their roles and responsibilities.


Element 7: Knowledge Sharing

Sharing is caring. A regular knowledge sharing forum is a great addition to the regular team meetings, where team members can have the podium and be empowered. When a team member feels empowered, they will be more creative, and everyone involved will feel the positive chemistry.


Element 8: Coaching and Mentoring

“Coaching” and “mentoring” look similar, but a lot of people understand the obvious difference. Coaching is quite performance driven and short-term based, while mentoring is more development driven and long-term aimed. What’s subtle is that mentoring requires a none conflict of interest communication, which means people managers are least appropriate mentors to their direct reports. However, a great support people managers can to is to encourage and even help their employees find a good mentor.


Element 9: Training and Education

It is somehow a “moral contract” between permanent employees (and the likes) and the employer that training and education will be made available when and if required.

Therefore, it is the manager’s role to identify the required training and education opportunities that will strengthen the skills of individual employees.


I hope you have got some inspirations now to use the industry-agnostic BA Practice framework to guide your future team and capability management. If you demonstrate commitment to your employees by building a mutually beneficial BA Practice, consistency will be created, and employee engagement will be elevated. Win-win.