So what do you do? In today’s video, I share 5 ways to help difficult stakeholders on the path to change.

For those who like to read instead of watch, here’s the full text of the video:

Today, I want to talk about how to handle resistant stakeholders. We received a question from the community about this particular business analyst who was working with users of a potential CRM system who really liked their paper processes. I’m there! I’ve got paper notes right here (but there are a lot of things I do electronically too). But they were resistant to transitioning over to using the new customer relationship management system and he just wondered if he’d done everything he could to help bring them up to speed on the new system and to engage them and make sure it met their needs.

Let’s talk about that. How do we handle resistant stakeholders, those who really don’t like technology?

I’m going to talk about five different strategies to make sure that you’re engaging resistant stakeholders to the best of your ability.

#1 – Build an Individual Relationship

The first is build an individual relationship. We have a whole video that I talk about different ways of cultivating a 1:1 relationship with the stakeholder and helping them understand business analysis. Make sure you’re taking some time to invest in that relationship with that stakeholder. Not just as “a stakeholder,” but as a person.

A work relationship doesn’t have to be like you are best friends and go out for coffee or drinks every day, but that you care about them as a person and that you’re not just there because of a project need, but that you have a relationship with them outside of just the context of that specific project. It’s going to help build trust and smooth the wheels for more conversations, deeper conversations, and a real basis of trust and understanding.

#2 – Understand their Current Business Process

Take time to understand their current process. Their current business process, as paper-bound as it might be, what are they taking notes on, how do they manage information, especially when it’s a resistance to technology, where does the paper come in, and why is the paper easier to them? Why does it feel easier to them? What need is that serving?

Just understanding it. Not trying to change it, improve it, or do anything to it, just let me understand your current process. I want to make sure, no matter what solution we come up with, it meets your need, your process, your way of doing your work. Because, presumably, they’re good at what they do and that’s why they’re in the roles that they’re in, and probably why there’s a little bit of resistance, too (like, “this is working for me”). Take some time and understand that. That’s a great way to also deepen that relationship with that stakeholder.

(Not sure how to document a business process? We’ve got a free Business Process Template download for you.)

#3 – Focus on Their Problems

Focus on their problems. What are they frustrated by? In the scenario that the BA brought up with us, it sounded like there was, maybe, some frustration that they traveled a lot. They had all these paper notes that were in filing cabinets that they couldn’t refer to easily.

• Is that a point of frustration for them, or is it not?
• Do they have a way of working around that? If so, what is it? What’s their frustration?
• If the system could do one thing for them, what would it be? What would change the game for them?

Sometimes, especially if you’re dealing with higher level stakeholders that have a lot of power in the organization but haven’t really been involved in the project so far, this is where you can use a little bit of that influence you have as a BA. You can say,

“You know, this frustrates this important stakeholder. I know we weren’t planning to address that potential issue right away for this project, but do you think we could address some things that would really help get them on board?”

You help bring that frustration into the scope of the project, and that can help wear down some of that resistance. Now you’re solving a problem that they care about, that they want solved, and you’re bringing it into the context of the project and you’re putting it in the light of if we can solve this problem, we’re also going to solve all these other bigger picture problems, which is probably why the project got started in the first place.

I saw a project manager do this in one of the organizations where I worked. I was a contractor and everybody was new to me, and we knew this particular team was going to be resistant and that we might not get any information from them. They were just so resistant. When we got going, then they gave us the wrong information. It was craziness. So she went in and said, “Let’s just talk about your problems. What’s on your plate? What’s slowing you down?” They just gave us this overload of information about what their frustrations were. Some of it wasn’t in scope for their project, originally.

She took that and went back to the executives and said, “We really need to address this in addition to the things that you wanted to address in the first place. We might have to actually eliminate a few of your things to make sure that we get this important group up.” And it did wonders. She had just paved a trail of gold for me as the business analyst to walk behind her and say, “Okay, now, let’s get the detailed requirements for these issues that have been bothering you for a long time.” She broke down that disengagement and turned it into trust and generosity and excitement about the project.

#4 – Share Wins

As you do this, then you also want to share wins. This is a little bit above and beyond. Now that you see other salespeople working and using the CRM, once your project gets going, if you’re still facing resistance, share the wins.

• Who are the people that are using the system effectively?
• What are their processes?
• How did they organize their work differently?

Share those wins and adjustments. How is it affecting their sales or their numbers? For example,

“So and so was able to leave early on Fridays because his sales notes process is so much easier.”

Whatever it is that might be important to that stakeholder, share those wins. When you see somebody having success, share that more broadly so that people start to see people are using the system and having results, and they’re solving these problems.

#5 – Secure Higher-Level Support

Those are 4 strategies, let’s talk about the 5th. That is to secure higher level support. At the end of the day, as business analysts, we have influence; we don’t have authority. We can’t fire people. We can’t remove their paper. We can’t do anything specific to make anybody do anything. Nobody can make you do anything. But as business analysts, we can’t use direct authority.

Sometimes we have to get higher level stakeholders involved. That can be escalating to the director, the VP, or the manager. Whoever is that level up from that person who is resistant. It’s up to them to say if the problem to be solved by this project, if the return on investment of using this new system is so important to the company, we’re going to stake our performance metrics on it.

“I’m going to pull out the rug on the old system, we’re going to make it uncomfortable for you not to use the new system in some way.” After they go through all the influence and authority, and ‘you need to do this’ tactics, it might come down to a much harder line. That’s not for you to do as a business analyst; this is for you to be aware of, of how these things might play out in an organizational context.

Not All Resistant Stakeholders Will Change

Fun story, or kind of a quirky story, is my mother-in-law is a retired nurse and she still talks about the day that they introduced electronic health records at her office and that led to her retirement. She consciously chose not to learn to use the new system and chose to retire instead. To this day, she doesn’t use a computer. She does not see our kids’ pictures on Facebook. We can barely get a hold of her on a cell phone. She has no desire to be any part of that technology. That was a choice. She organized her career around it and her exit from her career around it.

That happens, too, in some organizations and with some people that are truly resistant to change. You can do all these things, but you can’t force people to change. Just kind of be aware of the limits of the scope of what you can do as a business analyst. (We talked about this in more depth on Protecting Your Emotional Investment.)

Do your best. You don’t want a bunch of people retiring because of your project, but sometimes that happens and that’s okay, and it doesn’t mean you did a bad job.

I hope this answers your question. Great question. We could talk about this topic for a long time. It’s a good one; it’s a juicy one. I’m looking forward to seeing your engagement with stakeholders and helping them overcome that resistance to technology. This is the sales process that we do as business analysts in helping people see a brighter future and change the way that they need to change, that creates a positive change for organizations as well.

You’re doing great work. Thank you for what you do.

Figure Out What Your Business Users Really Want [Free Template]

One of the most important boundaries you can set as a business analyst is to be sure your business stakeholders are deeply involved in the requirements process, and have a lot of direct input and feedback. Starting by analyzing their business process helps put them in the position to tell you what they really, really want.

Business process analysis is often the very first technique used by business analysts when we start learning a new domain or analyze the scope of a project. Today, I’m offering my Business Process Template to you (absolutely free of charge!).

Download Your Free Guide – 10 Tips to Improve Stakeholder Engagement

And  if you are looking for even more tips to manage difficult stakeholders, download this free guide. You’ll

• Save time and effort by clarifying the requirements more quickly.
• Build stronger relationships that elevate your reputation and career.
• Improve project outcomes by communicating more effectively.

This is not the truth. This is a limiting belief.

Today’s video is all about how to succeed as an introverted business analyst. Because – guess what? – I’m an introverted business analyst too!

And even if you are an extroverted personality, you may want to check out today’s video. It’s likely that you have many introverted stakeholders, and you’ll learn some tips and tricks for working more effectively with them. Sometimes our quietest stakeholders hold the information we need the most.

For those who like to read instead of watch, here’s the full text of the video:

Hey there, Laura Brandenburg from Bridging the Gap. Today, let’s talk about how to excel as an introverted business analyst.

Definition of an Introverted Personality

Now, if you’re wondering what I mean by introverted, this is not about being shy. Introversion is when you get your energy, or your energy gets built up by being alone vs. an extrovert, who has energy, and their energy gets built up when they are with other people. Some of us are introverts, and some of us are extroverts. Whether you or an introvert or an extrovert, I think you’re going to gain a lot from today’s video.

If you are an introvert, you’re going to learn tips from somebody like me who is an introvert on succeeding and excelling as a business analyst. If you’re an extrovert, you’re going to learn tips for working with the introverts that are part of your team. So, let’s dive right in.

We talked about an introvert not necessarily being somebody who’s shy, but somebody who gets their energy from being alone or working independently. There are some challenges that introverts face as business analysts and, quite honestly, a lot of people are surprised to learn that I’m an introvert because I do things like this, like share videos and really engage on social media, and speak at events, and do live training programs. But, I will tell you that those activities are draining to my energy in a certain way.

After I speak, even at an hour and half long chapter meeting, I need some time to decompress and be on my own. That is true for a lot of introverts. We can do it. We can be out there. We can be visible, but it’s not necessarily the activity that fuels us and that energizes us.

I get much more energized writing a blog post, or figuring out an analysis model, or working on something independently than I do being on the phone with a client, or speaking publicly. Things like that. This is common for introverts. It’s not that we can’t do those things, it’s just that’s not the thing that fills up our energy.

What If Your Business Analyst Personality Means You Don’t Think Fast Enough?

Some of the comments that come up, though, from introverts – and I face these challenges too – one of the things is about slow thinking. Like,

“Oh, it feels like I think slow. Everybody else has this fast pace of thinking. In a meeting, it feels like I’m always trying to catch up because I think too slow.”

I remember telling an early coach of mine, I just need to learn how to think faster because I think too slow. She was like, “Yeah, I don’t really think that’s your problem. Let’s look at some other strategies for how to handle this.” She was right. It wasn’t that I think slow, it was that I think better when I am processing information independently because that’s when my energy is getting built up.

It wasn’t so much about finding a strategy where I could think as “fast” as everyone else in a meeting. It was about finding a strategy where I could have the space to think critically and analytically in an independent way and bring those ideas back to the meeting.

As a business analyst, we have perfect tools to do this. We can say, “Hey, I need to take everything we learn in this meeting today and put it together in a draft visual model.” And I’ll schedule another meeting to review. And now that draft model, or draft requirements document has your best thinking. You get time to work on it, to think it through, to look at it analytically, and structure the requirements and put things together and find questions to ask. Then you get to come back to the group and present those ideas and facilitate a discussion that’s leveraging some of your best thinking.

If you are an extroverted BA, or even if you’re an introverted BA, a lot of your stakeholders, especially end-user business process stakeholders who do a lot of work that’s not externally facing (your billing people, your internal HR people, and people that work on those systems day to day) are probably going to be introverted too. You want to look at ways and strategies to engage them; give them time to review a document ahead of time, to think through something and bring their ideas to the meeting so that you’re getting that balance of perspective and not just getting the requirements from your more extroverted stakeholders.

Leverage Your Unique Business Analyst Personality Strengths by Focusing on Analysis, Not Perfection

The other thing to think about is focusing on analysis and not perfection.

Because you get your energy from that independent work, that time to be thinking critically and working on things, and thinking through models, it’s going to be really tempting to perfect those models and to overanalyze, or spend a lot of time figuring out how to get everything perfectly aligned in Visio. Because that’s going to be somewhat energizing because you’re going to feel like you’re working through something.

It’s important to recognize that for what it is. And, yes, you want to do your thinking and structured thinking, and critical thinking, and give yourself space to do that. But, you also, really, want to make sure you’re getting those models back in front of stakeholders and getting feedback and really engaging people in that process as a business analyst, and not just working on it all on your own and putting it out when you feel it’s perfect. Most likely, then, you’re going to get that, “Eh, yes, but…” response that causes challenges and you’re going to feel like you had this perfect model that just got torn apart in a meeting.

You want to create time and space to do those more extroverted people-oriented activities so that you’re getting that buy-in, asking those questions, getting that feedback all along the way.

What If Your Business Analyst Personality Means Your Voice Gives Out?

The third thing I want to talk about came out from somebody I was recently on a mentoring call with. She talked about how her voice will literally give out in a meeting. She’s like, “Is there something I can do about that? Like what’s going on here?” And, you know, it’s not uncommon to have some sort of a physiological response to fear that might be coming up. And, so, there might be fear at play there, or something else going on at play there.

I, personally, have noticed that as I’ve increased the visibility of my work at Bridging the Gap, and doing things like more videos and more webinars, and expanding the reach of some of our programs, I’ll get sore throats and coughs, and sinus infections. They always tend to come up when I’m supposed to be recording videos, or during my training, or something like that.

It could just be a coincidence. We have young kids and, so, there are tons of germs in our house. But, also, it could be related a little bit to that fear around getting visible and doing things like this, like recording a video.

There’s not a one-stop solution to this. It’s about, for you, figuring out is there a reason that this is happening?

• Is there a fear that I’m not acknowledging?
• Do I want to let my voice giving out or my cold or whatever stop me from acting here?
• Is there a strategy that I can work around it?

Kind of doing some self-reflection on that and figuring out what’s going on.

In the space, though, take a few deep breaths. Ask a question. Let there be some silence. Let other people fill the space with answers to that question. Take an agenda item. Take a next step that allows you to do something independently like we just talked about. Just create solutions that work in the moment.

Now, one of them that I like to do – this is something I’ve learned just recently. It’s a little “woo-woo,” but if you are a little bit woo-woo (or even if you’re not, there is some good research behind this too), it’s call EFT. EFT is just, you can tap here (on your hand). This is your karate chop point. You can also tap these other points (on your face). Google it. There’s some good information about EFT on YouTube videos, for sure. It’s called EFT – Emotional Freedom Technique, also called Tapping. It’s just a good pattern interrupter.

If I’m on a webinar and I feel my voice crackle or I get nervous about a question that’s come in, or I’m like, “Oh my, who am I to be up here talking to everyone?”, I’ll just start tapping quietly like this. It’s perfect. You can do that under your desk. I’m doing it right now. You can’t see me. You can do that under your desk during a meeting if you wanted or if you’re running conference calls; you can do it wherever. You can just sit here and do this while you’re on your conference call.

It’s just a pattern interrupt technique that tends to shift your energy. It’s a good way to deal with any fear. Whether you’re introverted or extroverted, EFT can be useful. Kind of a little bit of a woo-woo way to think about it.

Most Importantly, Don’t Let Your Personality Be an Excuse

What I want you to take away from this is that there’s no reason that as an introvert, you shouldn’t be a business analyst or you can’t be a business analyst, or, really, any role that involves so much critical and analytical thinking. You have a lot of skills that are going to serve you really well in this role. That ability to think critically and to work independently, and to dive into a requirements model – super important.

You just need to balance that with the activities that are going to make sure you’re engaging with you stakeholders fully and leverage the tools that you have to prepare for those meetings and get through those meetings and deal with any other stuff that comes up along the way, and not let that fear drive you. Let, instead, that time that allows the awareness of your energy to drive you and find a balance that’s going to work for you in your career.

Lots more that we could say about this one but I hope those tips are useful as an introvert. Or, if you’re an extrovert and just learning how to deal more effectively with introverted people.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

In this video, I share 3 quick tips for being more effective, and why virtual meetings are a huge opportunity to leap forward in your career.

Some notes:

Virtual Meetings Are a Huge Opportunity

Opportunity #1 – Strengthen Your Communication Skills

Inside all challenges are opportunities. The opportunity right now is that this is a time when we are facilitating virtually, so we actually get to strengthen our communication skills.

Anytime we are put in a new project domain, or work in a new way, we have the opportunity to hone our skills and go back to the basics. We get to use the basics to do our work better in the new environment.

Every time things change on the surface, what gets stronger are our business analysis skills.

As we are facilitating meetings online, what will get stronger is our communication and facilitation skills. We may have had some crutches that will no longer be effective. This is the time to identify and refine them.

Opportunity #2 – Shift to Virtual Work

Another opportunity is that if we can do this well, and continue to do this effectively on your projects, you can make a case for working virtually long term. I think we will see organizations shifting towards more virtual work. We will also see fewer requirements for travel, especially for business analyst consultants.

Virtual Meeting Best Practice #1: Stick to Tried-and-True Best Practices

Take your best and most engaging in-person business analyst techniques and bring them online.

We have a tendency to think that because everything has changed, we need to learn new skills from scratch. Here are some examples:

• Observation – While you may have done this sitting at someone’s desk, it can now be done through screen sharing.
• Brainstorming – Can be done through a shared Google document or virtual whiteboarding tool.
• Visual Models and Documentation – creating documents like business process models, use cases, and data models are all extremely useful in an online setting.

Don’t let a virtual meeting be an excuse to depart from time-tested best practices.

Also, don’t let virtual meetings be an excuse for a boring meeting. You want to do the things that create an interaction in an in-person setting and look for opportunities to bring those online.

Virtual Meeting Best Practice #2: Verbalize Body Language

If you are reviewing a document in a room full of people, you might be used to recognizing body language in person. That is a lot harder to tell online, even if you are sharing video. You also might not be getting accurate information. If someone is looking at a second monitor, you might be looking at your requirements document. Or you might be looking down to take notes.

Online cues are not the same as in-person cues. So you have to ask your participants to verbalize more. And you have to verbalize more yourself.

When you are reviewing a document, this could mean more active pauses. Another idea is to prepare specific questions in each section (which is a best practice we’ve been teaching for in-person business analysis work as well).

Stop with each section and invite input. And if there is no input, ask for confirmation from each person that there really is no feedback, versus tacit approval.

This will also prepare you to be more effective as a stronger facilitator in person to engage stakeholders, especially when you are building new relationships or dealing with extremely introverted stakeholders who don’t use a lot of body language.

Virtual Meeting Best Practice #3: Be Clear On Your Business Analysis Process

People are more naturally engaged when they know what the next step is, and how their work relates to the big picture. In our Quick Start to Success workshop, you’ll learn the 8-step business analysis process framework that we teach at Bridging the Gap. Please feel free to leverage this framework as a starting point.

Again, this is great when you are working in an in-person setting as well. But it’s even more important online, not just for meetings, but also to effectively communicate what you are doing as a business analyst and what your next step is. Making your process clear sets you up for success, and prepares you to step up into more leadership roles.

>> Start YOUR Path to Success

If you are looking for more success as a business analyst, the absolute best next thing to do is to join my free Quick Start to Success Workshop. In that workshop, you will learn more about the business analyst career path, as well as details about the business analysis process framework that will give you the structure that you need to manage your day and your projects appropriately.

>> Click here to join the Quick Start to Success workshop <<

Again, if business analysis is right for you, we are here to help you at Bridging the Gap. We provide online training and certification to business analysts who are looking to start and succeed in their business analyst careers.

For now, just remember that we build our profession one business analyst at a time. Success starts with you.

Thanks for being here.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

What’s more, when you cultivate this skill of running an effective meeting, your stakeholders will be more likely to show up – and even show up on time! Your work gets more fun, and you get more done quickly.

In this video, I share a few of my tips for running a super effective meeting.

Hi, I’m Laura Brandenburg from Bridging the Gap.

Do you ever go to boring, crazy, unproductive meetings? Do you want to be the business analyst that everybody wants on their project because you run the best possible meetings?

Running a meeting is a skill. It’s something you can learn. It’s something you can master. Today I want to share just five tips with you for running a super productive working meeting that gets things done and encourages your stakeholders to actually show up on time, ask you to schedule meetings for them, and be excited when they see your name pop up on your calendar. Let’s dive right in.

Effective Meetings Tip #1 – Create an Agenda

The very first tip is to create an agenda. This is like Meetings 101. You want to know who was invited, what the purpose of the meeting is, what you’re hoping to accomplish. You want to provide that in advance so people know why the meeting is important and what they can hope to get done while they’re there.

The other piece to the agenda; maybe I’ve got that. You want to take it a step further and link what’s in your agenda to the progress of the project. When we get this done, when we review this requirements deliverable, or when we make this decision about prioritization, then we are going to be able to take this step forward in the project and show how it’s critical to moving the project forward.

Stakeholders see why their investment in time, energy, coming and showing up to the meeting, how that’s going to be valuable to them.

Effective Meetings Tip #2 – Prepare Deliverables

Tip #2 is to prepare a deliverable. Sometimes you don’t need a deliverable. You can show up and you just have questions at the very beginning of a project. But it almost always makes sense to prepare some sort of deliverable that can either be a rough working draft, or sometimes as you get further along in the project, you’re reviewing, validating, and going through that in a lot of detail. Examples might be a business process document, a use case document, a wireframe, a data model. Use that document to help organize the structure of the meeting.

One of the things I like to do is as I go through that document or deliverable is put in questions of where is there ambiguity. What do I need to know? We can use that as the step-by-step that we walk through and use to create discussion.

If you’re not sure what deliverable you should be creating, you probably want to start with a business process. I’m going to leave my link to our free business process template below this video so you can download that for free and get started with your more effective meetings relatively quickly.

Effective Meetings Tip #3 – Set the Stage

Tip #3 is set the stage. In our courses, we provide scripts or talking points. You’re not going to read a script. There are scripts that you can practice for how to set the stage for various types of requirements meetings that you might run to analyze or discover details for a specific kind of deliverable. That’s how important this skill is. Just give some thought in how you are going to open up the meeting.

Often you want to talk through who are the people there, what are you hoping to accomplish, what are you hoping each of them to contribute? You want to recap how this discussion you’re going to have moves the project forward, and you want to set the scope for the meeting.

This makes it a lot easier to redirect unproductive conversations that tend to come up in requirements meetings because people get excited and have ideas and want to explore nuances or go down rabbit trails, as we like to say. It’s important to create the frame for the meeting and set the stage so when you have to redirect and adjust later, it’s easier to refer back to.

Effective Meetings Tip #4 – Keep the Meeting On Track

That leads us to tip #4 which is to keep your meetings on track.

When those side trails do come up, or when somebody starts going too deep into a technical discussion that’s not required, use an issues list or a tracking sheet to say, “That’s not critical to the outcome that we set for this meeting. I want to make sure that we can accomplish what we set out to do today. Can I assign you an action item or put this on the issues list and we’ll make sure to come back to it later?”

You need to show that leadership ability as a business analyst to keep your meetings on track. It helps ensure that you’re consistently adding value, moving the meeting forward and you’re running the meetings that people want to show up to because they know you are going to organize it and make sure what needs to get done, gets done.

Effective Meetings Tip #5 – Close with Next Steps

Tip #5, and it really follows from Tip #4. That is to close with next steps. If you are gently redirecting, adding action items, or capturing issues on issues logs, you want to make sure that you revisit what all of those next steps are at the end of the meeting.

People get lost and forget. They’re off thinking about the next meeting and will they have time to use the bathroom in between. Re-close with next steps. Recap what was decided, what are the open items, and who’s in charge of what. Send that out afterwards as well. Take a few minutes at the close of the meeting to wrap things up. Even if you don’t accomplish the whole objective of what you set you to do – maybe you thought you could make a decision and you needed some more information.

Celebrate the progress that you’ve made. Acknowledge the progress for everyone. They’re going to be like, “Oh yeah, we really did get something done in this meeting.” There’s an appreciation factor that goes into that. You’re bringing awareness to it, which also helps cultivate their interests and desire to show up for your next meeting. You’re already planting the seed of what’s going to happen in the next meeting when you close with what was accomplished and also with next steps.

To Recap…

Those are my five tips. Just to recap:

1. Create an agenda and make sure that the agenda is tied to the progress of the project.
2. Prepare some deliverables. If you don’t know where to start, download my business process template below. It’s usually a good starting point.
3. Set the stage. Think about how you’re going to open the meeting and get it on the right track.
4. Keep the meeting on track throughout. This is where we show leadership, guidance and keeping everyone moving towards the desired outcome of the meeting.
5. Wrap up by closing with both acknowledging what was accomplished and highlighting those next steps so that you know exactly what you need to accomplish in your next meeting.

I hope these tips help you. Leave a comment below. Let me know what adjustments you are going to be making to your meeting. I want to hear what you’re going to apply from this free video.

Again, I’m Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

Download Your Free Business Process Template Today

> Click here to download the Business Process Template <<

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

In my work helping business analysts, I see a lot of lack of self-confidence. I see people underestimate their abilities all the time. Our analytical minds can have a field day with our self-belief. It’s so easy to pick our skills and abilities apart, which leads to self-doubt and inaction.

In our programs, the most common result people share with us is that they feel more confident. We’ve unlocked the code to building more confidence, and today I want to share that code with you.

For those who like to read instead of watch, here’s the full text of the video:

Hi, I’m Laura Brandenburg from Bridging the Gap and we help business analysts start their careers.

Today, I want to talk about a big challenge that I see in our profession and that is confidence. Confidence is a belief. It’s a belief in yourself and your ability to do what you need to do to be successful in your role. In our work training the next generation of business analysts, one of the most common results we have people express when going through our programs is that they feel more confident. I feel like we’ve unlocked the code of what it takes for an analytical professional to truly feel confident in their skills and abilities. Today, I want to share that code with you.

Building Confidence #1: Get Clear On Your Purpose

The first thing is to get clear on your purpose. In all of our programs we ask, “Why are you here? What are you hoping to accomplish? What about this is important to you?” We want to start to see yourself in the future, want to see yourself doing something more, and you want to link whatever it is you’re doing today to the big picture of where you’re going in your life and your career.

You might not have your big picture figured out yet, next step is okay. Where I want to be three months from now is okay. Where I want to be at the end of the year is okay. We can get overwhelmed with purpose. What does the next thing look like for me and why is that important to me? We need some fuel to do the work of building and cultivating confidence, and so that purpose gives us the fuel.

Building Confidence #2: Learn from a Trusted Resource

Second is to learn from a trusted resource. What I see is people reading dozens of different resources and trying to put all the pieces together and get overwhelmed with information and end up in analysis paralysis. Do your research. I don’t want to encourage people not to research. Sometimes, when a resource resonates with you and the results that they have resonate with you are what you want aligned with your purpose, it’s okay to say, “This is where I’m going. I’m going to trust this resource.”

Sometimes it’s trusting yourself.

Building Confidence #3: Take Action Before You Are Ready

Then you want to take action. What we do in our programs is not just consume information. That’s part of the learning process. But the confidence comes not from consuming information.

The confidence comes when people take action.

Taking action before they feel ready. You’re never going to feel ready, you’re never going to feel you take the action. It’s a little bit of the chicken and the egg, and I’m going to tell you, all you’ve got to do is just start taking the action. Take the action, do the deliverable, do the work, put your feet into the water. Start practicing the new behaviors that you want to be doing that are aligned to that goal that you have.

Building Confidence #4: Receive Feedback (From the Right People)

Ideally, you want to be in an environment where you can receive feedback from the right people. Your stakeholders are not always the right people. They have their own agendas. They don’t know what a good requirement looks like or a good process looks like. They could say this looks great, when it doesn’t. They could say this is hard for me to understand when you’ve followed every rule in the book.

Your stakeholders are often not the best people to receive feedback from, and your manager may or may not be. Some managers grew up as business analysts, and so they get it. Others don’t. They’re just as unfamiliar with the profession and what good requirements look like as you might be. They might not be the best person to provide feedback to you either.

Look, again, for feedback from somebody who really does understand what it takes to be successful as a business analyst. That person could be inside your company, a senior mentor, could be somebody you meet at a local meeting, it could be hiring a coach or a mentor, an instructor. But find somebody that you can get feedback from because that’s where once you take the action and receive that feedback, that’s where we see the confidence come from. That’s an important part of the code.

You want to build that feedback from an authoritative resource who can give constructive feedback, not just, “Oh, that’s horrible.” That doesn’t help you. That’s not going to build up your confidence. But here’s what you did right, here’s where you can improve, and here is where you need to make some updates. That gives you, like, “Oh, now I can be confident in what I did right, and now I can take new action to improve on what I didn’t do right.” That’s the kind of feedback you’re looking for.

Building Confidence #5: Celebrate the Small Wins

As you do that, you want to celebrate the small wins. It’s easy to be like, “Okay, great. I did a new thing,” and move on.

Success creates more success. Confidence creates more confidence.

I do things today that were, literally, unimaginable to me a year ago, two years ago. It’s because I’m continually taking new action, continually receiving that feedback and celebrating every win along the way and acknowledging, “Look, I did that. Now I can do this next thing that also feels a little scary.” Confidence just keeps coming from taking those actions.

Building Confidence Tip #6: Take Responsibility for Mistakes

Finally, when you do make a mistake, which is inevitable. We all make mistakes. It happens all the time. What I see is people worry so much about making a mistake that they don’t take action, they never get to that confidence. What I want you to do is realize you’re going to make a mistake and it’s okay. Often, we can recover from these mistakes. More often than not, we can recover. But be prepared to just take responsibility for it. Apologize, if that’s appropriate in the situation, take responsibility, and fix it. Take ownership of it.

As soon as you start to blame the stakeholder or the company or this, your failure and success is dependent on all these outside circumstances which doesn’t enable you to create an environment in which you can be successful. When you take responsibility for your successes by celebrating your wins and your failures by taking ownership of your mistakes, then you can always be confident in any situation. You can start to have that true inner confidence that makes it okay, even if you make a mistake.

What I really want you to take away from this video is that confidence is not something that somebody else can give to you.

Confidence is something that you give to yourself and it’s the greatest gift that you can give to yourself, to be able to take action in confidence, or even to just know that the actions you’re taking, even if they feel scary, are going to give you confidence in the end. This is a gift you give yourself. There’s no one else on earth who can give this to you.

I hope that this helps you take a step forward to find more confidence in yourself. The world needs more business analysts like you doing great work, taking risks every day, speaking up in meetings, making sure that companies are thinking through the real problems that need to be solved, and working on the best possible projects. We need us as a profession and individually to all be taking that next step in more confidence.

Again, my name is Laura Brandenburg at Bridging the Gap. We help business analysts start their careers.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

A lot of issues are really blessings in disguise. Better to clear them out early than let them fester and cause even bigger project problems later.

So, without further ado – Trick or Treat!

For those who like to read instead of watch, here’s the full text of the video:

Happy Halloween, if you are in the U. S. and watching this video. Soon after it’s published, it’s on or near Halloween, and this is a special edition of our videos series because we’re doing a trick or treat video today.

I’ve got my orange and black on (those are Halloween colors here). And I want to take it a step further. This is crazy – first time ever in a Bridging the Gap video – I’m going to do this with a tiara. This is from my 3-year-old’s Halloween costume. She’s going to be Tinkerbell. Okay, does this look ridiculous? Probably a little.

We are business analysts. We still get to have fun. First time ever video with a Tinkerbell tiara on.

We’re talking about tricks or treats as a business analyst. What I mean by that is things that feel like they are issues in the moment, but are actually treats in disguise. How can we reframe the things that happen, the issues that pop up in our work as BAs, so that we feel like they are a positive thing that we can move forward from?

Trick #1 – You Didn’t Get This Right

The first one is, when we get feedback on a model or requirement, it’s like, hey, you didn’t get this right. It’s totally wrong.  At first, we can feel like we did something wrong. Aren’t we supposed to know the requirements? We’re the BAs after all. Didn’t I get this right? Should I have worked harder? Should I have analyzed it more? Should I have kind of figured this out somehow?

Most often, if you’re asking questions, and doing analysis, and doing your best to prepare for your meetings, and prepare for your models, and doing the research that a normal business analyst would do, most often, you didn’t actually do anything wrong. Most often, that feedback of “you didn’t get this right” or “you made a mistake” is really the feedback that we needed. It’s why we create these models in the first place.

And, so, I want you to not feel like you somehow messed up when that happens and, instead, just reframe that. “Hey, great, I want to hear about my mistake. How would you correct this requirement? What would you add to this model? Let’s have a discussion about it.” Totally move on. It’s not a mistake.

Trick #2 – Hearing Crickets

The second thing that can seem icky at first, and we’re going to reframe it, is what happens if you just hear crickets? You ask a question and then nothing. Silence. Silence is uncomfortable, isn’t it? Kind of like wearing a tiara in a video for a business analyst. It’s uncomfortable. It’s uncomfortable for you. It’s uncomfortable for your stakeholders.

Sometimes, people need time to think. If you are more introverted, we just had a video about being a more introverted business analyst. Some of our stakeholders are more introverted. We need time to think.

Maybe, I don’t know quite the answer. Maybe I’m nervous, or maybe I’m expecting somebody else to pipe up with the answer. Give that a little bit of space. It’s okay to have some silence in our meetings. It doesn’t have to be boom, boom, boom, boom, boom, like that. You can have silence. Allow that silence to work its magic and for people to come up with their answers.

You don’t want to go on forever, though. You wouldn’t want to have like five minutes of silence in a meeting unless you’re all doing independent brainstorming, which is a great technique to break the silence. Like having everybody just independently write their own ideas and then get together and share those. Great way to engage introverted stakeholders as well and give them some space to have those thoughts. Use a technique like that to break the silence.

Again, go back to modeling. Draw something up on the whiteboard and let them point out your mistakes instead of trying to feel like they should come up with the answer for you. At first, you lead them through it and help them get that “Yes, but” response.

Or, as a last resort, do you not have the right stakeholders in the room? Again, these are positive things. You’re learning. If they’re having difficulty answering the question, maybe there’s a better technique I need to use as a business analyst to engage them. If they don’t know the answer to the question, maybe there’s somebody else I should be asking. There’s always a way to take that a step forward and to use that as information that moves your project forward.

Trick #3 – That’s Impossible

The third one that I’m going to talk about, which is common, is when an attack person says, “Hey, great requirements idea. Totally impossible. Can’t do it.” Particularly frustrating when it comes up after your stakeholders, like after you’ve involved them in some sort of review. They’ve been involved, maybe, in a bit of the requirements process, and nodded their head and said, “Yeah, that makes sense.” And now, somewhere along the way, they say, “Sorry, we can’t do it.”

It’s frustrating and hard, usually, to go back to the business stakeholders, but think of the alternative. Would it have been better for them to continue with implementing those requirements and maybe the plug would have been pulled out on the project before they could implement anything of value? Whereas, if they’re coming back to you early and saying, “Hey, we can’t do it like the design or the requirements say. We need to make some adjustments.” Often, that’s the time where you can still negotiate and figure out alternate solutions and get together and create a better outcome before months have gone by and now it’s too late and nothing of value is delivered.

Would it have been better if they just did whatever they wanted? Coming back to you and saying, “Hey, this isn’t going to work,” is better than them just coming up with an alternative solution and implementing that instead, which happens. That’s a bigger problem because that’s the silence problem. That’s the not hearing back about your requirements problem.

Again, that feedback is always a blessing in disguise. Instead of thinking about it as a trick, it’s so hard. It is hard. But it is an opportunity to revise the requirements and come up with a new solution.

Again, it’s Halloween in the U.S. My Tinkerbell. I wish I had the wand with her costume so we could just go, “Trick” and turn that into a treat. “Trick,” turn that into a treat. But the theme here is more information is better information. The more that your business analysis process is moving forward and you’re learning your stakeholder engagement, getting feedback, even if it’s not the feedback you really wanted or thought of, or expected, if it’s moving the process forward, you’re heading in the right direction.

Always be thinking about how can I turn this trick into a treat, and you’ll be on the path to doing better business analysis.

Have a happy Halloween! Talk to you soon.

Some time ago, I received a call from an IT manager from a large NY-based company.

This manager (let’s call him John) wanted my help in Phase 2 of a project whose first phase had experienced serious cost overruns.  The purpose of the project was to customize an off-the-shelf content management system for use by various business departments. “I want to warn you,” he said, “that the stakeholders you’ll be dealing with are very difficult. They worked with the BA initially assigned to the project, signed off on the requirements document, and only on the day we offered a demo, right before the go-live date, decided to complain about things that never came up during the requirements phase. We ended up missing an important deadline because the project sponsor refused to approve the release until a long list of change requests was implemented.”

I asked John a few questions about the requirements that had been missed, and quickly concluded that they could have been easily anticipated and dealt with in a timely manner, had the business analyst asked the right questions to the right people during the discovery phase.

One of the main objections from stakeholders was that the solution didn’t allow members of the Marketing team to easily reshuffle a series of events after they had been published to the website’s calendar. The software requirements clearly described how users would be able to create individual events, preview them in the calendar, make adjustments, and publish to the website. However, the requirements failed to account for changes in dates of connected events after they had been published.

Imagine that in early August, the Marketing team published a full calendar of events for September, pertaining to the release of a new product.  Then, mid-August, the product team announced that the release would be delayed three weeks. In this common scenario, there would be a high risk that the calendar ended up with incorrect dates due to the time-consuming process of reshuffling each associated event manually.

The BA’s mistake was to rely on the stakeholders to tell her which capabilities they needed to perform their job. A good first step here would have been to focus on how the stakeholders are behaving today. Stakeholders don’t necessarily realize that they have a problem to solve (“move around a series of linked events without having to manually change individual dates, to reduce the effort and mitigate the risk of human error”). But they are very good at describing how they perform their tasks today, and this knowledge is an invaluable source of information about what needs to be built.

Here are the some of the questions that would have helped the BA in John’s project identify the deal-breaker requirements that were initially overlooked: 

• Can you walk me through the process you follow, from the time you learn of a new event or series of events that need to go into the calendar, to the time the events are live in the website’s calendar?
• How often do you have to publish events to the website calendar?
• How often do you have to update events after they’ve been published?
• What do you normally do when you have to update an event after it’s been published?
• What is the most frustrating thing that you have to do when you are creating or updating an event?

Note how all those questions focus on how the interviewee is behaving today, as opposed to asking about what he or she would like the solution to do for them. By asking questions about the present, rather than the future, the BA would have learned that it was common for the marketing team to have a series of events with dates that are relative to each other (e.g., Conference Day 1, Conference Day 2, etc.) and that might have to be moved after the schedule had been published.

Stakeholders would have explained how they currently built the monthly calendar using an internal project management tool that allowed them to multi-select the events you need to move and shift them all together to a future date, preserving their sequence in the series. This piece of information would have allowed the BA to identify the ability to move a whole series of events in bulk as a necessary capability in the new solution, to avoid an inefficient and error-prone process of rescheduling events one by one.

You may be thinking, “but each situation is different—what if the missing requirement is not about something that the users currently do, but rather about what they’ll have to start doing in the new application?”.  As any business analyst knows, understanding and translating what our stakeholders truly need into software specifications that deliver the right solution is easier said than done. Different circumstances call for different interview techniques to uncover what the stakeholders’ real needs are.

>>Learn More

If you could use help in this area, check out Adriana Beal’s e-book: Tested Stakeholder Interviewing Methods for Business Analysts. This e-book offers proven techniques and actionable steps to ensure you uncover any deal-breaker requirements early on and avoid last minute surprises in all your projects.

Keep reading to learn about 8 ways to get more of the right information you need during each requirements meeting and minimize the amount of follow-up you have to do.

#1 – Define the Outcome of the Meeting

We manage a lot of ambiguity as business analysts and it’s easy to allow ambiguity to seep into our meetings too.  Often we don’t think of questions ahead of time because we don’t really know where we’re headed with a particular discussion about the requirements. When your meeting has a clear and distinct outcome, it helps you think of all the questions you need to ask.

Here’s how my thought process works as I am preparing for a meeting agenda.

Let’s see, I need to figure out XYZ today. And to do that I need to know A. And to learn about A I need to ask about B. Oh, and I completely forgot about C – here’s a question I need to ask about that. OK. Let’s look back at XYZ – are we doing everything we need to do to accomplish XYZ today? Oh, there’s one more thing.

And now that “one more thing” makes it into the meeting agenda, which we’ll talk about next.

#2 – A Little Planning Goes a Long Way

While having a clear goal for a meeting can solve a lot of your information problems, you’ll do even better at getting more of the right information earlier on once you start to put together detailed agendas. A meeting agenda is essentially a working plan for how you want your meeting to go. What you’ll talk about first, second, third, etc. It should include the outcome of the meeting (so all participants know what is to be accomplished) as well as one or more discussion topics supporting that outcome and any supporting material.

Another planning technique I use is to create a requirements questionnaire. This is a tool for me to think up every question I can before the meeting. I don’t always share it with my stakeholders, as the list of questions itself can be overwhelming, but I review it throughout the meeting or whenever there is a lull and I need to step in and lead the discussion to keep things going.

(By the way, we’ve pulled together a collection of feature-specific questions and made them available in our Requirements Discovery Checklist Pack.)

#3 – Gather Background Information

There’s a sure-fire way to get little meaningful information from a meeting and irritate your stakeholders – ask them questions you could have easily answered yourself by reviewing the current system or existing documentation. They will be bored, overlook important details, and you’ll never get to the juicy information where the real requirements are.

Now, this does not mean that you need to become the proverbial expert before you ever hold a meeting with your stakeholders. But it does mean that you need to take some time to learn what you can about the project, system, and processes before going into the meeting. Here are 8 documents that can help you ask all the right questions.

#4 – Prepare Materials for Review

Many stakeholders have difficulty answering questions and might even find them a bit annoying. But give them a wireframe to look at or a draft specification to provide feedback on and you’ll often find that they are full of information to share and that they even (gasp!) start having fun with the process.

#5 – Review Your Agenda Before and Throughout the Meeting

It’s easy to get caught up in the flow of the discussion, lose track of time and your agenda, and allow the elicitation session to go off-track. As the facilitator of a requirements discussion it is your job to lead the meeting. And this can mean that you need to build in pauses when you step back and look at your agenda to ensure you are covering everything.

While it can feel unnatural to pause during a meeting and review your notes and agenda, doing so gives you a minute or so to collect your thoughts and ask your next question. And if you’ve been using active listening techniques throughout the meeting, you might even find your stakeholders interject relevant information even if you don’t ask for it.

So let’s look at the power of active listening, shall we?

#6 – Use Active Listening Techniques to Get More Information

BAs worry a lot about the questions we ask. But it’s just as important to listen, really listen to the answers our stakeholders give to the questions we do ask.

This accomplishes a few different things.

• First, when we listen actively, our stakeholders realize we actually care about what they are saying. As a result, we earn their trust and that often leads them to share information they might not otherwise. No questions necessary.
• We also better understand what they share with us, and so follow-up questions naturally pop into our heads even if they aren’t on our pre-built questionnaires.
• Finally, active listening slows the pace of the meeting down and gives everyone a chance to digest what’s being discussed and think of relevant information to contribute.

And while it can seem counter-intuitive, slowing down a discussion actually speeds up the process as a whole because it minimizes follow-up questions from yourself and everyone else involved.

#7 – Ask For What You Are Missing

As important as it is to create an agenda, don’t get sucked into assuming you’ve come up with every possible relevant question. Before you end a requirements discussion, it’s always a good idea to ask if anyone has anything else to share or if there are any questions you should have asked but didn’t.

This can lead to some very interesting information and, even if it doesn’t, it let’s your stakeholders know that you are open to receiving more information in the future, should they think of something important.

#8 – Close the Meeting with Next Steps

We started this post by discussing how critical understanding the outcome of the meeting is. As you close the meeting, it’s a good idea to do a gut check against the intended outcome and let your attendees know what your next steps will be. I always like to throw in that I’ll be reviewing everything we discussed and I might have follow-up questions. This way any follow-up questions I do have do not catch them by surprise and end up being less irritating.

Often closing the meeting with next steps will trigger the following running dialog in your stakeholder’s mind, which can be very effective at getting you relevant information you might not be thinking about.

Oh, we’re going to do that next? But we didn’t talk about E yet. Aren’t we going to talk about E first? I better bring up E.

And as long as you’ve been a good listener all along, your stakeholder will share E. And you’ll be a happy, informed BA with happy stakeholders.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

However, we’ve probably all had experiences where the reality seems quite different.  Sometimes groups don’t seem to “gel” very well, and sometimes certain delegates look like they want to contribute but seem to be self-censoring themselves.  Perhaps their boss is in the room, and they are afraid of speaking out.  Or perhaps they lack confidence and are afraid of asking “stupid” questions.

The irony, I believe, is that the so-called “stupid” questions are the most important.  Often they are so fundamental that they’ve been overlooked, until someone is brave enough to raise them.  It’s important to foster an environment in a workshop that creates the permission to ask any relevant question, however provocative or obvious it seems.  This will ensure your workshop is most effective and uncovers the cold, hard facts.

When planning a workshop, it is worth considering whether you need to include workshop levelers in your agenda.  Workshop levelers are tools and technique that remove rank, prevent a single attendee from monopolising the conversation, and allow shy people to contribute without fear of having to speak out in front of their boss.  Here are a few notable tips that I like using:

1. Set the scene:  On the agenda, and at the beginning of the meeting, ensure that you create the permission for people to ask provocative questions.  Explain that all views are valid; we might not action every idea that is mentioned, but even some of the most “quirky” ideas might prove useful after subsequent discussion.

2. Leave rank and job titles at the door:  As part of setting the scene, let attendees know that when they enter the room, they leave their rank at the door.  Contributions from front-line staff are just as valid as those from the CEO (and, in many case, front-line staff are able to provide excellent insight into what real customers want).

3. Mix it up:  If you are running a larger workshop and you split the attendees into syndicate groups, ensure each group has a mixture of backgrounds and seniority.  This will allow cross-pollination of ideas, and will help prevent the delegates from slipping back and focusing on their own rank/job title. You may want to include a suitable icebreaker to help people to get to know each other better, and to break down the barriers of formality.

4. When appropriate, embrace anonymity:  Consider using techniques that allow people to make a contribution anonymously.  Allowing people to post stick ‘post-it’ notes with their ideas to a flip-chart will encourage even the most shy of person to contribute.  The output can then be discussed in total rather than identifying individual ideas.  (This technique needs to be used with care; anonymity can lead to a lack of ownership, but managed carefully it works well).

5. Facilitate fairly:  During group discussions and debates, don’t allow a single attendee to monopolize the airways.  If someone looks like they need to speak, actively invite them.  Say something like, “John, you’ve been a bit quiet – I just wanted to check you’re OK with this. Do you have anything you’d like to add?”

6. Recognise body language and trust your gut:  If someone looks uncomfortable or unhappy, don’t ignore it.  If you aren’t able to get to the bottom of their concerns during the meeting, consider following up with them after the meeting (perhaps over coffee).

There are so many more excellent techniques I could have mentioned, but these are six of my favourite.  I hope you have found them useful!

3 Things Michael Does Right

#1 – Everyone in the conference room! Yep, it’s annoying, but Michael gets everyone in the room at the same time. Meetings are most efficient when everyone who needs to be there shows up – on time and engaged for the duration of the discussion. In fact, remember the time when Pam tries to avoid a discussion by faking car trouble? Michael stops the meeting until she comes back. Although it can seem really inefficient in the short-term to stop or cancel a meeting when all the key stakeholders aren’t engaged, doing so can increase productivity over the long haul.

#2 – Invites dialog. In a meeting with Michael, there’s almost always that uncomfortable point when he calls someone out. While I don’t condone Michael’s habit of bringing up personal and confidential information in a group setting, often as BAs we need to surface information a stakeholder has shared with us to get the discussion going or make sure all relevant information is out on the table.

#3 – Uses visuals. Remember the episodes when Michael hangs up pictures of famous people, draws out the pyramid scheme, or plays a video of his participation in a game show as a child? In all cases, the truth comes out via visual representations, even if it’s not the truth Michael was hoping for.

As BAs, we can draw on whiteboards, prepare formal or informal models, and bring in scenarios to help surface the reality underneath all the talk. So often, the success of a meeting is highly dependent not so much on what happens in the meeting, but what  deliverables we prepare for the meeting.

(By the way, if any of this sounds like something you’d like support bringing to your organization, I’m piloting an Essential Meeting Skills virtual course. It starts August 15 and includes my step-by-step process for facilitating a working meeting, the opportunity to listen in on expert meeting sessions, and 1-1 instructor support as you apply new meeting techniques in your work setting.)

3 Things Michael Does Wrong

#1 – Lack of a Clear Agenda. Most of Michael’s meetings are impromptu and unplanned. Even those that are scheduled in advance don’t seem to follow a clear agenda. Most often, it appears as if Michael is just winging it, perhaps with one or two tricks up his sleeve – tricks that rarely turn out like he expects.

I can sympathize. It’s nearly impossible to put together an agenda that will hold up to a working meeting, which means real work gets done and unknowns get explored. There is always something unexpected that crops up and a savvy BA knows how to re-arrange the agenda on-the-fly to achieve the ultimate goal of the meeting. They also know that a sensible agenda organized to achieve a clear purpose is a powerful guidepost.

#2 – Creates a Stage. Have you ever noticed the most common configuration of the conference room? All the staff are sitting in rows with Michael up front running or being the show. You don’t need to configure your conference room as a theater to face this problem.  If the same person always sit at the head of the table or behind the desk in their office, they are positioned as a presenter and your collaborative meeting can quickly become more of a show. This type of meeting can be useful in a small number of situations, but it shouldn’t be the primary type of meeting a BA facilitates.

#3 – Shuts People Down. Sure Michael invites response and draws people out, but he’s almost always looking for a specific answer. When he gets an answer he does not expect, he discredits the information (or worse, the person) or turns it into a joke. This is not a way to build trust with your stakeholders.

It’s easier than you think to form assumptions about the answers you expect and challenge a stakeholder when they bring up conflicting information. And while you might not be overtly dismissive, this communication pattern can send a signal that you are not actively open to accepting new information. I’ve done this more times than I’d like to admit, most often when I’m trying to elicit and analyze requirements in the same meeting.

If you are looking to improve your meeting facilitation skills, I hope you’ll let Michael Scott be your guide. Take his best qualities and by all means avoid his mistakes.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

However – not all workshops achieve their goals.  What are some of the common pitfalls, and how can they be avoided? I have listed 7 key pitfalls below:

1. Insufficient planning and preparation

A workshop needs structure, and a good facilitator will spend time considering which methods, tools and techniques should be used. It’s important to craft this into a carefully considered agenda to make sure that the key points can be covered in the allocated time.

The amount of planning needed is likely to vary depending on the number of attendees, whether it’s a routine or a “One off workshop”.  Think of it this way – if you hold a 3 hour workshop with 10 people present, that’s 30 hours of collective time.  That’s a huge cost! The workshop needs to be a success, so don’t feel guilty spending 3 or 4 hours preparing.

Preparation involves preparing your audience by providing them with an agenda, and where needed making individual phone calls/visits to ensure they have everything they need. It also involves planning to arrive early to set up the room and test any equipment needed.

2. Unclear or non-existent workshop goals

Have you ever been to a meeting or workshop where nothing has been achieved, and the conversation has gone round and round in circles?  This can be down to the fact that stakeholders had a different understanding of the purpose of the workshop.  Perhaps one thought it was to define scope, and another thought it was to reduce scope.  Subtle differences lead to people talking cross-purpose.  All workshops should have an agreed goal/objective up front.

“We are here to focus on… This workshop will be a success if by the end of the meeting we achieve…”  

3. Inviting the wrong people 

Workshops are most effective when they are kept short, succinct and the key decision makers are in the room.  If you can’t get the key people to commit to attending, consider deferring the workshop.  If it looks like the workshop will involve 25 people, consider asking what each individual’s area of expertise is. Are they a decision maker? Do they need to be there? Could the workshop be split into two shorter focussed workshops to keep attendance down to a manageable level?

4. Letting energy get low

A workshop should be interactive and energising.  If you need creativity, think of ways to keep the energy levels high.  Bring cakes.  Take away the seats.  Use colour, music… do whatever you need to keep people engaged and interested!

5. Ignoring conflict

It’s all too easy to gloss over conflict in a desire for stakeholder consensus.  I have a controversial view here – workshops are exactly the right place to encourage conflicting ideas to be discussed!  Let’s face it – conflict is going to occur sometime during the project.  Better to get it on the table when people are together, so a resolution can be found early (or at least the issue is acknowledged).

6. Feeling afraid to jump in

This is something I used to struggle with. I think it’s a product of being British (and our national obsession with “politeness”), but I used to find it difficult to “interject” and move someone on.  Sometimes people seem to make their point over and over again, or perhaps they go drastically off topic.

Let me set the record straight.  As a facilitator, it is perfectly OK to respectfully cut someone short, to “park” an item, agree a future time it’ll be discussed and move on through the agenda.  In fact, it’s quite likely that the rest of your audience will thank you for it!  Make sure you have an “actions log” and “parked ideas log” so that these ideas and concerns aren’t lost – they can be discussed offline if needed.

7. Not documenting the meeting

Chances are, nobody will remember the decisions that were made in a meeting held at 10:30am on a Monday morning 6 months ago.  To ensure there is a clear understanding of what was discussed and agreed, it is worth ensuring that the workshop is recorded, in whatever format works for you and your stakeholders. Your meeting notes should also be made available for review after the workshop.  (You don’t have to take this role on yourself.  You could consider allocating the role of “scribe” to a willing volunteer.)

A good workshop can be productive, fun and effective.  Good planning, preparation and facilitation is a key differentiating factor.  And some cakes or candy to bribe the attendees can be a good move too!

I am awaiting feedback from a client on a Requirements document. It has been 3 weeks and I haven’t gotten any response. I have already sent an email reminding them. How do I request feedback or even sign-off without sounding too demanding?

Laura’s Response:

As business analysts it’s our job not just to craft requirements documentation, but also to ensure that they reflect the actual business needs. To do that, we require feedback and input from our business stakeholders. So, to start with, I’d worry less about sounding too demanding than about doing what it takes to get your job done.

But let’s look at the potential root causes of this situation and some ideas for circumventing each of them.

#1 – Not Setting Clear Expectations Upfront

Often this sort of problem creeps up because we do not set good expectations when starting a project. Consciously or not, we allow our stakeholders to mistakenly assume that once they meet with the BA once – poof! their wishes will be answered and sometime later the software will magically appear that is exactly what they need.

As BAs, we need to manage the requirements process – and this means setting specific expectations for the roles we need our stakeholders to fill for us to be effective. Otherwise, we run the risk of them assuming that requirements take too long. Every time I meet with a stakeholder, I let them know we’ll be meeting again or collaborating in some way. If I can, I let them know exactly what I’ll need them to do. If I’m not sure, I leave the window open so they know they’ll be on the hook for something.

If your stakeholder doesn’t understand that their delay in providing feedback is holding up the project, oftentimes clarifying why their feedback is important and how this task you’ve asked them to do fits into the overall project lifecycle will get things moving again.

#2 – Asking For Non-Specific Feedback

Another root cause might be that you’ve asked for “feedback” but have not been specific about the type of feedback you require. Requirements documents can be very intimidating for stakeholders (especially when they are longer than they need to be). They may not understand what information you need or how to review the document you’ve sent. They may be looking at this big “to do” in their inbox and making excuses for putting it off day by day.

You can help by determining exactly what kind of feedback you need from the stakeholder. Do they need to review the entire document? Do you need them to answer some follow-up questions? Reframe your request very specifically and it’s more likely to seem doable and therefore get done.

#3 – Project is Not a Priority

If you’ve addressed the first two causes, then it may be that this project simply isn’t important. It may be that your stakeholders don’t understand the importance of the project to the organization, in which case escalating to your management might get things moving. Or, it might be that the project isn’t important to the organization. Try to get assigned to more critical path work.

Your To Do List

Since it’s been three weeks and your request is hanging out there, here’s what I’d suggest as a series of next steps.

1. Determine exactly what kind of feedback you need from the stakeholder. Reframe your request very specifically.
2. Ascertain the impact that their lack of response is having on the project. What can’t happen until they provide feedback? When do you need this feedback by to keep the project moving as planned?
3. Initiate a one-on-one conversation with the stakeholder. Yes, it’s important at this point that you have a conversation and not just send an email. Mention your previous request and ask if there is something specific that’s been holding them back from getting started. Clarify your request and how it fits into the project lifecycle.  Gain a commitment from the stakeholder to provide the feedback you need by a specific day.
4. If your stakeholder is not sure how to provide the feedback you require, schedule a meeting to do a requirements review.  Often a conversation is much more productive than an offline review. Or, it may be that you need to engage additional stakeholders in your requirements process to finalize the specifications.
5. Learn from the experience so you can improve next time!

>>Get the Feedback You Need

Here are a few articles from the archive that look at how to get the feedback you need to be successful as a business analyst.

• How to Get Sign-Off Without a Requirements Walk-Through
• 7 Questions that Will Get Even More Information Out of Your Stakeholders
• 8 Ways to Be Less Irritating and Minimize Follow-Up Questions After Requirements Meetings

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

According to the BABOK, the purpose of Prepare Requirements Package is:

“To select and structure a set of requirements in an appropriate fashion to ensure that the requirements are effectively communicated to, understood by, and usable by a stakeholder group or groups.”

And the BABOK goes on to further articulate why this is important.

“Requirements should be presented in formats that are understandable by the stakeholder. This task describes the work required to decide which format(s) are appropriate for a particular project and its stakeholders. They must be clear, concise, accurate, and at the appropriate level of detail. Requirements documentation should be created only to the extent needed to ensure clear understanding by the team.”

I think this is a powerful task because it clearly separates the elicitation and analysis of requirements from the creation of a package to communicate requirements. This is essentially saying that discovering the requirements is not the end-all-be-all of business analysis. We must also invest the effort in creating packages that support our stakeholders in understanding those requirements.

And these packages are not necessarily documents. They can also be presentations or visual models.

It’s difficult to think about a project where I didn’t create a requirements package of some sort. And they have ranged significantly from a collection of nicely formatted wiki pages to slide decks presented to the board of directors to formal documentation (aka big thick requirements documents) reviewed by a large cross-functional stakeholder group. As I matured as a BA, this is one area that I found myself experimenting with, always looking for a simpler and easier way to communicate the essence of the requirements to inform a particular decision or follow-up task.

One example I’m especially proud of is a one page epic I created to scope a significant feature to be developed using agile. On one page I captured the business rationale for the feature, key stakeholders, essential business requirements, constraints, risks, and unknowns. It was easy to review and validate, and a great touchstone for elaborating the requirements into a product backlog and user stories.

Just like the perfect birthday or holiday gift starts with understanding what the person really wants, the perfect requirements package starts with understanding what your stakeholders really need and how they will best understand it.

This post is one installment in our Journey Through the BABOK with BA Stories series.

I read an article today from our respected colleague, Yaaqub Mohamed about the importance of data analysis as part of a good analyst’s tool belt. Well that is not exactly how he put it, but you get the gist.

Anyhow, it got me to thinking about another type of data that often goes unnoticed until it is far too late to even say, “Oops!” Yes, yes I’m speaking of nomenclature and that involves the identification of terminology and the definitions and aliases used to capture meaning.

It doesn’t seem all that important, but it can be as dangerous as a missed stakeholder with a bad attitude and political agenda if not properly handled. Allow me to paint you a scenario to consider.

I work for an organization that started with one division and it ended up buying three more along the way. We all do the same thing, but we do it in different states under different legal guidelines and the like. Each division had been in business for a number of years prior to being merged with the others. So, it stands to reason that each division’s employees does things a little differently while achieving the same goal. Along with that, each division refers to the same entities by a different name. Imagine trying to build an enterprise application with this standing in the way. I cannot begin to tell you how interesting the JADs are before we realize that there are either four names for the same thing or one definition applied to four disparate terms.

It would seem that a glossary would cover the issue and we could move on with our lives, but that requires people to read it. When was the last time you took the time to look up a word that you didn’t understand? The real issue rears up with usage, context and general comprehension during conversation. Most of the time we can figure out context while holding conversations and can even pick up an accurate meaning periodically.

However, when there are 30-40 people arguing about things while using often very similar, yet still completely different terms, the last thing that people seem to do is whip out their trusty glossary. Most of us go with the flow, so we don’t appear stupid, and that is about the stupidest thing we could do. If terminology is not clearly and consistently understood, there is a huge margin for error in the solutions that you as analyst recommend to your audience. If there is more than one audience and they aren’t on the same page, then guess what happens? Yup! Think about the error conditions of implementing business rules if there is not clear terminology for governing the entities of the organization. Migrate those problems into code and you have real issues.

The analyst has a grandstand seat to watch these struggles in order to understand trends between stakeholders, and plays an important role in bringing people together to talk and listen to one another in order to find common ground in terminology. Failure to do so can lead to costly, yet surprisingly simple errors. Here are a few things you can do…

• Identify your terms. As you take notes and write documentation, pick out the domain terms that are repeated or singled out as words that have meaning to your stakeholders….especially those that can have multiple meanings.
• Make a simple glossary a mandatory part of your documentation. Even if everyone speaks the same language (meaning dialect) and calls an orange an orange….your writing will capture that fact. Eventually, someone will be hired who refers to an orange as a lemon and you will have the baseline established.
• Ask if you don’t know what something means! If anyone is going to ask stupid questions, it better be you functioning as an analyst. That is why you are there…and don’t forget that! We ask the questions that people having been avoiding for years while they were trying to look smart. Why do you think they need analysts now?
• Validate your terms and definitions against the business rules, whether in text or code.
• Validate your terms and definitions with ALL stakeholders.
• Define all known aliases to bring mindsets and conversation together.

In summary, take a little time to make your life and that of your stakeholders and developers by calling out variations in the words you hear used to describe the domain that you are working in. Take ownership of controlling this knowledge, and put it to use as a part of your project. You will not believe all the use a good set of terms can have, not the number of times others tell you how great it would have been if they had it previously.

Michelle’s Response:

After reading this question, I found myself thinking that yes I have been through this before and I have also been able to make this work and have successful sessions with my stakeholders.  The most critical difference that I can see is the stakeholder who can see the value of fixing or changing the process.  Most stakeholders want to be there; they want to be able to help.

However, two thought processes might be happening here:

First, what does a BA do and how can she help me?

Second, how does this change affect me and my team?

Recently I had several business owners miss my meetings or show up late.  When I talked with them, they did not see the value in a business analyst.  They had the understanding that I was an administrative resource who was to be utilized as they wanted – mostly for note taking and for setting up meetings.

Now this is just fine if that was the role I was hired to do, but I was hired to move forward on a business process change.  I talked with them about the change, what I could do to help them and the value I could provide.  Understanding what their process is and being able to represent it during full team sessions is critical.  In addition, bringing back updates to proposed thoughts and ideas becomes valuable to the process owners if they cannot always attend every meeting.  But I could and I would be able to represent their team on their behalf.

Change is such a difficult process to go through whether it is in your personal life or business life.  I always come into a project fully appreciating the change that the business owners will be managing.  I sit down with them, usually one on one (or by conference call, again one on one) first to talk about that change and start building a relationship.  What does it mean for them?   What does it mean for their team?  How does this change affect their process coming into their team and leaving their team?  How do they view this process, and can they find the value in the change?

Then I talk about how I can help with this.  How I can support them with understanding the change, making it work for them, documentation, training, and whatever else they need.  If they see the value then you become part of their team too, and the trust that you build is the most important part of the developing relationship. They start attending your meetings because they trust you and see your role in helping them achieve their goals.

>>Prepare More Effectively For Your Next Meeting

Want to feel more confident asking questions in a new domain and save valuable stakeholder time in the meetings you facilitate? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

• Consider the focus of the meeting or workshop;
• Minimize duration & maximize value;
• Involve everyone – create a collaborative spirit among those who will participate.

With these themes in mind, your distributed team’s discovery, design and planning activities can be accelerated with the use of virtual brainstorming to collect divergent information. Allowing remote and local participants an equal opportunity to reflect and contribute their unique perspectives will make effective use of your meeting time.

Best practices for virtual brainstorming

There are a couple of things I found surprising when I first started conducting virtual brainstorming sessions:

1. Silence can be productive. I like to start a live brainstorming session by asking each person to quietly consider their individual answer and jot down their conclusions.  At first the silence feels a bit odd during a teleconference, but allowing time for personal reflection encourages subsequent contributions from those with a more contemplative style.
2. Anonymity is an equalizer.  When the organizational hierarchy or clients are present at a meeting some people tend to filter their words and stay in the “safe zone” of conversation.  However I was delighted to find that the self-editing tends to disappear when text input is gathered anonymously.  Virtual meetings can actually deliver an advantage over face-to-face: participants  get to see everyone’s comments  but not who they are attributed to, generating a more true and robust collection of insights and concerns.

Virtual brainstorming scenarios

When a distributed workshop calls for brainstorming ideas, plan your virtual meeting with a web and teleconference tool that will simplify the process. Here are a few scenarios that business analysts deal with quite often.

Scenario 1: Gather team input.

Web-based whiteboards enable a meeting leader (or participants, with permission granted) to scribe during a virtual meeting.  Capture discussion bullet points on a blank screen that is shared on each participant’s computer screen via the internet.  Some tools even have drawing features to graphically represent the discussion; my favorites create a work space for multi-user drawing & virtual sticky notes; find a tool that’s compatible with your style by experimenting with these free web resources:  Scribblar, Twiddla, and Dabbleboard.  Other tools are purely text-based, using a discussion board interface; Writeboard and Huddle whiteboard feature work well to create a new topic for multi-user editing or comments. Another option to try is the text chat function common in web conferencing software (for example GoToMeeting or Webex).  Pose a question to stimulate written brainstorming contributions and ask everyone to concurrently type their responses. The Chat window will provide a shared scrolling view of the individual answers.

Setting it up: Determine who will attend, then use the tool’s invitation features to send an e-mail link that will help attendees to schedule and join the electronic workspace at the appropriate time.  Once the meeting is done the tools enables saving a record of your whiteboard work.

Scenario 2: Stakeholders must collaborate to uncover key issues & impacts.

If generating ideas has been problematic try using small group breakout sessions to encourage everyone to participate. Results improve by pairing a smaller number of people together for private collaboration, then having each small group report their results to the combined assembly of participants.  MaestroConference enables a teleconference leader to designate small group membership and initiate a timed breakout session.  Most web conferencing software also includes a phone breakout feature for their audio tools.

Setting it up: In addition to the invitation process, the meeting leader designates random or assigned sub-group membership.  Once the teleconference is underway, meeting leader features allow you to launch the breakout session, instantly initiating multiple private teleconferences.  Designated facilitators can even drop in on the individual conversations if needed to guide the discussions.  Closing the breakout session using manual or timed features rejoins the audio into a single conversation.

Scenario 3: Requirements sign-off from a client with a globally distributed team

When time zone differences interfere with same time communication turn to asynchronous brainstorming. Asynchronous activities do not take place in real time; rather participants log in to contribute on their own schedule.  Document editing and threaded discussions are conducted over the Internet in a shared space for text editing (mirroring word processing features) and comment entry (as a discussion post). This type of brainstorming can also help to gain input in advance of a live workshop or as a follow up assignment. Your organization may use a Business Collaboration platform such as SharePoint; a Yahoo Group or Wiki can also serve this purpose in the private sector.

Setting it up: A similar invitation process authorizes invitees to join the working document space.  The discussion host can set up alerts to be notified of additions from collaborators.

My virtual collaboration experiences have become more engaging and productive by introducing these methods for gathering wide-ranging input.

After the meeting, Anne sought me out to apologize.  She explained that in her role as business analyst she was in meetings all day, back to back to back.  She didn’t have time to get a cup of coffee or take care of other human needs.  So she tended to show up a few minutes late for various meetings and she wanted to let me know that it wasn’t personal.  I smiled and said I understood, and she felt compelled to continue, explaining that the constant meetings did not allow her the time to respond to the urgent emails and other tasks that were in her queue until after work at six o’clock.  She felt as though she had two jobs: meeting attendee and business analyst with the latter starting at dinner time every night. I asked if she ever got home for dinner.  Her response:  “rarely”.

Unfortunately, this is not an unusual situation in the lives of business analysts. Many business analysts complain about being “meetinged to death”.  There are information gathering meetings, review sessions, status meetings, demonstrations and presentations, more status meetings, meetings about the last meeting and meetings to prepare for the next meeting.  Anne’s work life was out of control.

I suggested, somewhat facetiously, that she must be important to be included in all these meetings.  She denied her importance.  She said that her calendar just gets filled up with people including her on their meetings. When I asked, she said that she has the technical ability to decline attendance, but did not feel it was politically correct and, besides, it might be considered by some as shirking her duties as a business analyst.

And thus, many business analysts feel as though they are pulled in many directions by many constituencies: the development team needs the business analyst for advice, counsel and blame; the users need to be reassured and have a sounding board for their complaints and ideas; business management wants to make sure the product is being developed the way they expect and don’t feel the technical project manager will give them the straight scoop; upper level management leans on the business analyst for mediation and negotiation and information for decision making; and so it goes.  How can the business analyst say no?

I made a suggestion, one that has stood me in good stead.  I suggested she contact the moderator of the meeting and ask what her purpose would be in attending the meeting.  Ostensibly, she is checking to see if there is something she should bring with her, or a presentation she should be prepared to make, or any other activity that might be expected of her concerning the meeting.  When the moderator says “no, I just thought you might like to be there”, or “I invited everyone on the project mailing list”, she can ask if it’s all right if she skips the meeting and would the moderator be so kind as to provide her with the minutes, if they are kept and distributed.  I suggested to Anne that she might find herself freed from meetings where her attendance was less than mandatory.

That was Tuesday.  I saw her again in a meeting Thursday morning and she was on time.  “No meeting earlier?” I asked.  “No,” she replied. “I got out of it, and three others today. And two yesterday.  You know, it really works.  Most people just invite others to their meetings to prevent issues and because it’s politically correct. They don’t really care if you don’t attend. And I have so much I can get done instead of attending a meeting and pretending I’m interested while trying to not let anyone see me returning emails.”  This was fortunate because I really needed to hear some business analyst perspectives on the topic at hand in this particular meeting.

It’s your time. In the end you will be held accountable for what you do, not how many meetings you attend. Just because your name is on the list does not mean you have to attend.  If you have nothing to present, no particular constituency to represent, no immediate concern about the information being passed (you can wait and read the minutes), have nothing to offer in any decisions to be made, and don’t know why you are expected to be in the meeting, ask the moderator.  When the moderator confirms that there are no expectations of you other than attendance, ask to be excused.  Most likely, the moderator will be just as happy to have one less person in the meeting. Then you can use that available hour for more important activities, like getting that cup of coffee so you can be on time for the next meeting.

In this article, lets look at 10 ways you can communicate even more effectively on IT projects.

Communicate with Business Stakeholders

1. Always remember: It is never a waste of time to define the problem before discussing solutions.

2. Sometimes business stakeholders just aren’t sure where to start with “requirements”. Become a sounding board for new ideas and look for ways to help your stakeholders discover technical possibilities.

3. As business analyst, we are often in a position to reach across organizational boundaries, especially the gulf that seems to separate business and technology. Doug Goldberg provides a host of ideas on why attitude issues surface on both sides and how a business analyst is in a position to forge new paths of communication between business and IT.

Improve Analyst / Developer Communication

4. Have you ever had a developer tell you “that’s impossible”? I certainly have. Read my advice for how to overcome this communication barrier between analysts and developers.

5. And to avoid the above problem in the first place, always look for opportunities to share business context with your technical team. It is a positive form of communication and will do wonders in establishing your relationships.

6. Have you witnessed a tense moment between a developer and a stakeholder? Have you wondered how you can help your teammate? Doug Hill shares a wonderful story about a small gesture that created a big positive experience.

Overcome Common BA Communication Challenges

7. It can be difficult to turn off our analysis hat and really listen to what our stakeholders have to say. Using a variety of active listening techniques will help your stakeholders realize you did really hear what they said and understood what they meant.

8. Have you wished you had resisted the urge to say “I told you so” or the more professional equivalent of “remember last week when I pointed that out”.  Learn to think of these moments as opportunities to learn how to better influence your stakeholders next time.

Leverage Techniques and Templates to Improve Communication

There are a few tools that I rarely leave my desk without because they do so much to improve both my own organization and how I communicate with others. They include

9. Be proactive with an issues list to drive attention to open items and breed accountability amongst your stakeholder team.

10. Avoid mystery meetings with quick and simple meeting agendas and start your meetings by establishing context.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

You need to get control of the discussion. You need to be assertive and interrupt them. But how do you do this in a polite and dignified way?

In what follows I’ll suggest a few ways you can go about interrupting someone without being rude or damaging the stakeholder relationship.

In many cases, especially with new stakeholders, I do feel that waiting for a lull, no matter how brief, is appropriate. And in that lull, you can ask a question to redirect the conversation.

One of my favorites is

“I think I’m missing something here, can you explain how this relates back to [insert problem to be solved.]”

You have to say this with 100% sincerity. (It helps if you sincerely believe you might be missing something, even if you your prior experience would indicate they are probably heading off track.)

Another statement I use for interruption is

“I can see that’s important, but if we talk about that now I won’t have XYZ ready [reference a deadline or deliverable in such a way that it adds value to the stakeholder]. Do you mind if we stay focused on [the topic at hand] for this discussion?”

A third technique I use is to actively acknowledge what I’ve heard. Sometimes the person who is continuing on just doesn’t realize that they are being heard and understood. By summarizing what you hear in total, focusing on a piece of the conversation that is relevant to the agenda, and perhaps asking a follow-up question, often you can get the meeting back on track without it feeling like an interruption at all.

Sometimes, almost unconsciously, I interrupt with my body language. I might put my hand out indicating it’s time to pass the conversation on. I am a feverish writer during meetings, so if I haven’t written anything down in a few minutes, make direct eye contact, and nod, it sends a signal that I’d like to say something.

If I can get the lull, then I jump in to redirect the conversation to the topic at hand.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

Over the years I’ve developed some habits that help me fill both the meeting facilitator role and the note-taker role simultaneously.

• Before the meeting, I list out agenda topics with sub-questions that I want to ask. Sometimes I send this to the attendees, sometimes this is my personal reference for what needs to be accomplished. I leave space between each item so I can jot down notes next to my questions. (By the way, my meeting agenda and meeting notes templates are included in the Business Analyst Template Toolkit.)
• I’ve developed a bit of short-hand for capturing key items. For example, I use “AI” to call out an action item and “NR” to call out new requirements identified in the meeting. Other short-hand elements keep me focused on what was discussed in context of the original meeting purpose and the sidebars that might be issues that need to be followed up on outside the meeting.
• For  intensive meetings, I block out time immediately following the meeting to type up notes. I find it nearly impossible to write everything down in the meeting itself without slowing the meeting to a bare crawl. But if I have time to type up my notes immediately after the discussion I can often remember things through stream of consciousness that I might forget the next day or even a few hours later.
• Throughout the meeting I summarize the outcome and use other active listening techniques to slow down the pace of the discussion and ensure everyone has a common understanding of what’s been discussed. Good meeting notes reflect a common understanding of all participants. Often what I thought I heard and what other participants heard are different stories entirely. Summarizing is a good practice that fills both the facilitator and the note-taker roles.

Trying to hold down multiple roles is not always the best situation, but you can make the best of it by incorporating some of these habits. These habits help me keep my sanity and at times prevent duplicate discussions, missed details, or a false sense of alignment.

It’s elegant.

It’s simple.

It’s even got a hint of beauty about it.

When you get ready to present it to your technical team for implementation, you get the answer you least expect…”that’s impossible” or it’s close equivalent “that will take us months” (when the budget is weeks).

As the business analyst, what can you do?

Well, one option is to let the project manager deal with it. After all, you did “your part” in figuring out the problem and the requirements. You can sit back on your laurels knowing you’ve provided a solution that the customer wants and stay out of the fray. But that’s not what you will do because it’s in your DNA to handle these things differently.

The best BAs do not simply define requirements, they create change and solve problems.

Now there are many ways to handle this situation and how you proceed will depend as much on the individuals on your team as your history with these people.

First of all…breathe. I mean take a really deep breath and relax. Let the tension of the situation out and focus on what you want. You want to help the business solve this problem, right? What’s the best way forward?

One tactic I like to use at a cross-roads between requirements and design is to take a couple of steps back. Oftentimes we get so excited about our own ideas and those of our customer that we forget to get the implementation team involved early enough. So by the time we’ve got it all worked out, they feel like all the intellectual challenge is gone. They push back because it’s easy to find issues with another person’s solutions when you have no ownership in them. Think about it, you’d probably do it if you were in their shoes too, just to spite you and your difficult BA self.

So, take a few steps back. Go back to the problem you are solving and get crystal clear on it as an implementation team. Encourage them to ask questions and help you clarify your thinking. It’s important you go into this activity with a truly open mind. You have to trust your implementation team, but also respect their intellects and believe that there is most likely a better solution.

Then start collaborating on solutions. Brainstorming sessions can work. List out 10 ideas. Pick 3 and dive a bit deeper. Be open to hearing what they have to say. Facilitate active discussion amongst them.

Only chime in if the solution is far off track from a real business requirement. And then say something like “I see the value of this idea, but I’m not sure how XYZ would be accomplished.”

Oftentimes after these sessions you’ll be surprised how close the team’s solution is to your own. It will be tempting to point this out. Don’t.

Remember, it’s never important that you know how to solve a problem. As a BA your hands are most often tied when it comes to implementation. What’s important is that your implementation team is confident they can solve a problem within the constraints of time and budget.

You can’t force people to code your solution.

You can lead them there.

You can facilitate discussions.

You can help find good solutions.

But you can’t force them. In the end, they have to own it or it’s simply not going to work.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

Meeting Agenda Tip #1: Identify the Goal of the Meeting

If you do only one thing when planning a meeting, be very clear about the goal. “Discuss XYZ” is not a goal, it’s an activity.  Most meetings seem to have implicit goals for the attendees to decide something.  If so, state what decision is needed and, if possible, describe the next action someone can begin once that decision is made.

The next action really gives your goal credibility because you have a valid litmus test for whether or not the decision was made at the end of the meeting.

But not all meetings are called for decision-making.  Sometimes the goal is to simply review a requirements document for feedback, generate ideas about a feature, or determine the effort associated with a specific requirement or project.  Think clearly about your expected outcome for the meeting and write it out in your agenda.

Meeting Agenda Tip #2: Identify Meeting Topics

Once you’ve determined your outcome,  list out the topics (a.k.a. agenda items) that will help you achieve that outcome, preferably as a bullet list.

For example, if your goal is to make decisions about how to assign resources among projects, you might first ask the business stakeholders what their current priorities are, review who is assigned to what, then negotiate adjustments.  This list provides a clear progression toward the desired end state. If you are generating ideas about a feature, you might facilitate a quick ice breaker, followed by a structured brainstorming activity, and closed with a review of the ideas generated.

No matter what your goal, there are usually a few activities you can list to support it.  When running the meeting, it will be important not to let these activities become goals in and of themselves.  If you are engaged in an “agenda item” and it’s not helping you achieve your goal then it might be worth discarding on-the-fly.  Likewise it can often make sense to slot in a new agenda item when it becomes clear it’s needed to achieve your goal. Honoring serendipity is prudent.

Meeting Agenda Tip #3: Prepare Deliverables

Whenever possible, prepare a requirements deliverable in advance and send it out with your meeting agenda, or at least prior to the meeting.

Here are some examples of deliverables you could create:

• Scope Statement – to help clarify the business needs driving a project and the project scope.
• Business Process Model – to articulate an as-is or to-be business process
• Use Case – along with a corresponding wireframe, a use case documents software functionality and will help you get business and technical users on the same page about the requirements.
• Data Models – to clarify business terminology, database requirements, and data flow between systems.
• Business Analysis Plan – to identify your business analysis process approach, what stakeholders you need involved when, and gain buy-in on their involvement.

>>Get My Meeting Agenda Template

The BA Template Toolkit includes a meeting agenda template, along with templates for capturing meeting notes and 10 other common BA specifications such as a scope statement, business process model, use case, business analysis plan, and a few data models – so you don’t have to start from scratch.

Click here to learn more about the BA Template Toolkit

There are many reasons you can give yourself to not to ask your question.

• Maybe you asked it already and got an answer (but you aren’t satisfied).
• Maybe you feel you should know the answer (but you don’t). This happens a lot when you are in a new business domain.
• Maybe you think everyone else understands what was said (they probably don’t).

I’m here to tell you DON’T DO IT. Find a way to get over, past, or around whatever hesitation is causing you to hit your internal pause button. Ask your question. And don’t just ask it, ask it until it is answered and your internal gut check comes back positive for comfort.

I’ve been in these situations.  You ask a question and you see the following accumulation of non-verbal responses: a blank stare , an eye roll, and a sigh…yes, maybe you’ve temporarily frustrated a few people who want out of the meeting.  But I’m telling you if you have a question and if you’ve done your homework, the worse thing you can do is let it go unanswered.

When I was first starting out as a BA and uncertain of my BA skills, I did this all the time.  I assumed everyone in the room was smarter than me and that they knew and would act on the underlying answers to these latent questions of mine.  I feared appearing incompetent so I kept many questions to myself. But many, many times, the same issue that sat on the tip of my tongue surfaced as a much bigger issue a few weeks later. If anyone had thought about the issue, they certainly hadn’t acted on it.  Just like painting over mildew doesn’t rid you of the real problem.

I’ve taken a new stance on questions and understanding.  If I don’t understand something, I assume someone else is also in the dark.  And if it strikes me as important, I ask it then and there.  I deal with the non-verbal reactions head on and probe until I get my answer.  I can’t tell you how many times this behavior has yielded an “aha” moment for someone else on the team.

True leaders worry less about how they are perceived in the short-term and more about actionable results in the long-term.  Ask your questions; probe until you get answers.

>>Read These Next

• What Questions Do I Ask During Requirements Elicitation?
• How to Get Your Stakeholders to Stop Repeating Themselves
• 7 Questions that Will Get Even More Information Out of Your Stakeholders

>>Not Sure What Questions to Be Asking?

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

I had an immediate attack of self-realization when I thought back over some past interactions.  Yep, I had sure made that difficult for so and so. But just as Gordon predicted about all “difficult” people, I also had the best interest of the company and usually that person at heart.

We are all difficult in certain contexts and 99.99% of the time we are operating from the belief that we are doing the right thing.

I think as business analysts we are probably in this situation more often than most.  If we do our job well, we have spent a great deal of time thinking about and (over)-analyzing a problem. Very often, we are the most informed person in the room and we probably know it.  We’ve got an answer for everything and everyone. And we passionately want what is best for our clients and our company. Smell difficult to you?

So how can we see our way beyond our “difficultness”?  Here are some of 8 ideas for becoming less difficult in situations BAs encounter every day.

1. If you are the type who tends to over-analyze,  you are probably difficult to people who see the forest while you have deep knowledge about the trees, so step back from the details and learn to appreciate their perspective. Consider some alternate ways of validating requirements.
2. But you will also deal with people even more in the details than you and you will be difficult because you are trying to get them to see the forest.  Be patient. Communicate in every possible way, especially visually. (Some thoughts on using domain models as a visual.)
3. Realize that most informed does not mean fully informed.  There is someone in the room who knows something you don’t.  And you want to know what it is.
4. You have to take the emotions out of it. You are probably very proud of your work and the proposal you’ve come up with.  You know its strengths and weaknesses.  When you present that solution, you’ve got to step back from your idea.  Let people be critical of the solution without assuming they are being critical of you.
5. Another way BAs tend let their emotion filtrate their work is during decision-making.  You’ve presented all the data.  You know the best solution but you are not the decision-maker.  But the stakeholder picks an alternative.  Clarify these types of discussions with a direct discussion of risks and benefits.  Ask the stakeholder for their reasoning…they might surprise you.
6. A lot of us have just enough technical knowledge to be dangerous.  Maybe you wrote code years ago or have put up our own website.  Yea, developers hate that and it makes you difficult when you try to minimize their technical challenges.  Whatever you think you know, forget it.  Challenge, but don’t presume. And be as delicate in your approach to this area as you possibly can.
7. We can also become quite passionate about our customer.  After all, we spend large amounts of time figuring out exactly what they want.  When the developer says “that’s impossible” or “that will take us 2 years” you might get just a little irritated and just a little difficult.  Sound familiar? These are times to negotiate and seek alternatives.
8. As BAs, we can also be very process-oriented. Our silver lining in every failure is an opportunity to improve the process so we never have to go through that again.  Try to balance process improvement with an understanding of what works in different contexts. Unfortunately, not every problem has the same solution.

And remember…everyone is a difficult person to someone. That means you are difficult to someone.

If all else fails, check out 8 ways to be less irritating and minimize follow-up from your requirements meetings for 8 more solid tips.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection