As a business analyst, you can provide tremendous value by not only getting sign off on the requirements, but also getting buy in from stakeholders about what the solution needs to do and how it fits into their workflow before development even begins.

So how do you get buy in and meaningful sign off on your requirements to avoid unnecessarily changes and costs? In this video, Laura shares 3 tips for getting meaningful sign offs that you can use on your next project!

Engaging stakeholders is a critical piece to streamlining your sign off process. Our free guide, 10 Tips for Engaging Stakeholders, is a great place to start so you can supercharge your stakeholder management skills.

>> Download Free Guide <<

One of the most frustrating challenges on a project is when the developers build a solution that everyone thought the business had signed off on, only to have significant changes surface during testing or even after deployment. Business analysts can provide tremendous value by getting not just the sign-off on the requirements, but buy-in from the business stakeholders about what the solution needs to do and how it fits into their workflow before the development even begins.

Gaining buy-in saves a tremendous amount of time and effort and reduces the need for expensive rework late in the development cycle. Keep watching, and I’m going to share how to gain buy-in in a meaningful way on your requirements.

Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos and business analysis tips and techniques.

Requirements Sign-Off Tip #1 – Focus on Sign-Off as a Tool for Obtaining Buy-In

Let’s start off with tip number one, which is to focus on sign-off as a tool for obtaining buy-in.

The BA’s job is to get meaningful feedback on the requirements so that they represent what the business actually wants from the solution. In my very first role, we used to walk through the requirements line by line as part of getting sign-off. These meetings would take hours and would require dozens of people to be there, and then I need to get an email confirmation from each and every person about that same long document.

I know in other organizations, sometimes an actual signature, either physically or electronically, is required and sometimes this can be necessary for regulatory reasons. It’s more important, though, to focus on what that signoff actually represents, and that is buy-in. Buy-in means that the business agrees with what’s documented. It actually wants to move forward with having that solution built based on the specifications.

As I matured as a business analyst, I started to shorten my reviews and really hone my approach to make it more efficient.

Requirements Sign-Off  Tip #2 – Be Clear on What Input You Are Looking For

That leads me to sign-off tip number two, which is to be clear on what input you are even looking for. Most projects have different phases of sign-off. You might sign-off or approve the scope or the business case. You might sign-off on specific requirements, deliverables, such as a business process or a use case, or even a data mapping document. You might have sign-off on the implementation and transition plans.

Gaining sign-off at each stage is significant, and using your business analysis framework to guide that is crucial. It provides a valuable opportunity to engage your stakeholders, to seek their input and ensure their buy-in at each stage of the life cycle so that you don’t get off track doing something that’s irrelevant because you are getting that buy-in incrementally and iteratively throughout the project.

By obtaining sign-off in those major phases, you establish a solid foundation for success, and you also foster a shared sense of ownership from your business team.

Oh, and that business analysis framework I just mentioned, if you don’t have one yet, you certainly need one. You can start by learning about our eight step business analysis process framework that I outlined in another video I did a while ago, which you can watch after finishing this video by clicking below.

The mindset here that you want to bring into your work as a business analyst is, what is the next decision that needs to be made to move my project forward? Always be driving towards that as a business analyst and moving from ambiguity to clarity in the context of that decision. This will keep you moving forward in a proactive and efficient way and not getting bogged out in making decisions about details too early in the project, which often leads to analysis paralysis.

Requirements Sign-Off Tip #3 – Customize Your Approach to Sign-Off Based on Your Stakeholders

Requirements tip number three is to customize your approach to sign-off based on who your stakeholders are.

Let’s really be honest here. Most of our stakeholders are not all that great at reading requirements. As business analysts, we bring a lot of expertise in writing and organizing requirements and analyzing requirements, and there are times when a requirements review or a walkthrough is the best way to get sign-off. But I found that the easiest way to get buy-in is when I customize my approach specifically to a group of stakeholders.

If you have a hard time engaging stakeholders in sign-off or a hard time engaging them in general, we recently created a new free guide that aims to help boost stakeholder engagement. If you want a copy, you can click below to get a download of it.

>> Download Free Guide <<

Let me just share a few examples of how I’ve customized my approach.

• On one contract, I reviewed annotated wire frames with the business stakeholders. I had the use case and the user story right up in hand. I had done that analytical thinking and writing to make sure I had all the questions that I needed to ask and all the information that I needed to verify. I used my use case thinking to identify those questions. But ultimately the details made it into the user stories for the developer to review and implement. But on the screen, it was a visual model of what that screen might look like with some little sticky note annotations that they could review and provide feedback on.
• On another project, I created a clickthrough prototype. That could handle a few different key scenarios and had the business stakeholder actually use that prototype to provide feedback. This was somebody who is just super hands-on and tactile and like needed to see it working in order to be able to really provide great feedback. I was able to do that in a click-through prototype. You might even consider slide decks with abstract visual models and key bullet points for high level and strategic details.

For those who need to buy into the project vision and approach, but not necessarily all of the minute little details, consider who your audience is. Consider what feedback you need from those stakeholders and then look at how to get that specific kind of feedback and buy-in. That is always what you want to be doing as a business analyst to make your process efficient and effective. I really do believe it’s your job to find ways of communicating the requirements and keeping them in sync, and it’s their job to meet you halfway and provide some meaningful feedback.

Is Requirements Sign-Off Still Relevant in Agile?

One question I often get about this is whether requirements sign-off is still relevant in agile.

While agile practices might not require an official “sign-off,” there is definitely an assumption of buy-in built into the user stories that are brought forward for implementation in a sprint. If you want to save unnecessary rework, it’s essential that either a product owner or supporting business analyst gains buy-in from all the necessary business stakeholders on the solution approach and the details before that user story is brought to a sprint for implementation.

To ensure successful signoff and to obtain meaningful buy-in, remember these key steps.

• Focus on securing buy-in from your stakeholders and clearly define the input you need and the decision that needs to be in the main next, and customize your approach for each stakeholder or stakeholder group so that you’re meeting them where they’re at and can get the best possible feedback. Engaging stakeholders is crucial for a streamlined sign-off process.
• Don’t forget to download our free guide, “10 tips for engaging stakeholders,” to supercharge your stakeholder management and your skills in engaging stakeholders.
• Lastly, as part of the sign-off process, incorporating requirements reviews or walkthroughs can be essential.

Join me in the next video below where I’ll share practical best practices for efficient and effective requirements reviews. I’ll see you there.

It’s a built-in insurance policy against future project mishaps and challenges.

In this short video, you’ll learn Laura’s top three tips for building rapport with critical stakeholders that you can begin implementing today.

Today I’m sharing 10 tips for engaging your stakeholders.

Looking to Take These Stakeholder Tips With You?

• 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.

Click here to download our FREE GUIDE – 10 Tips to Improve Stakeholder Engagement

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

My name is Laura Brandenburg from Bridging the Gap. Do you ever have stakeholders not show up to your meetings, or they show up and they’re distracted on their phone or their laptop, and they’re physically there, but presently somewhere else mentally and emotionally? Or you ask questions and you don’t get the answers that you need.

All of these problems will slow down your requirements process. They will make you less effective as a business analyst, and they will make it more challenging for you to discover the true problem to be solved and get the information you need from stakeholders to make sure that you’re solving that problem in the right way.

Today, I have 10 tips to share with you to engage your stakeholders more effectively and to help you work through all of these challenges.

Let’s talk about how to actively engage your stakeholders often through meetings, sometimes through email and other mediums, but most often, we’re engaging our stakeholders through some form of either in-person or virtual meeting. We’re going to talk about that today.

Stakeholder Engagement Tip #1 – Start Your Meetings on Time

The number one tip I have for you is to start your meetings on time no matter what. Be the person in your organization that isn’t the one that starts meetings five minutes late, or 10 minutes late. Your meetings start on time, and if they’re late, they missed something juicy and interesting.

You are encouraging a culture of showing up on time, of starting right away, and making the most of everyone’s time. It’s difficult at first, but as you cultivate this habit, people will show up on time and they will be more engaged.

Stakeholder Engagement Tip #2 – Make Sure Your Meetings Are Working Meetings

Second, in order to do that, you need to make sure your meetings are truly working meetings and that you’re really getting something done, and people want to be there because when they’re there, they are part of the decision, they’re part of the input, and if they’re not there, it’s like they’re missing out on the good important work that is happening to move their project forward.

Make sure your meetings are productive, they’re adding value, they’re moving projects forward, and that work is tied to an end result that’s important to your stakeholders.

Stakeholder Engagement Tip #3 – Ask Powerful Questions

Third, ask questions. Ask powerful questions. Learn how to ask why 20 different ways. Learn how to use analysis models to discover gaps so that you can find the questions that no one else is asking. Those gap filling questions, you’ve got to ask them, you’ve got to hold the space for people to answer them.

Stakeholder Engagement Tip #4 – Use Statements to Root Out Assumptions

Fourth, sometimes you will ask a question and people will be like, “I don’t know.” They either get brain freeze or they literally don’t know the answer, or they get stuck answering the question. Sometimes you do need to make a statement. Sometimes a bold statement to get them thinking. “Oh, wait, that can be an answer to the question. That can be an answer.” You get them thinking.

Sometimes you need to put something almost ridiculous out there because, then, it’s like, “No, not that.” That’s not the answer to this question. With that bold almost ridiculous statement, you’ve at least got them engaged and you’ve got them thinking of alternative answers.

Stakeholder Engagement Tip #5 – Be Quiet and Listen

Number five is to be quiet and listen. A lot of BAs are good at this, but some business analysts still like to talk, like to show how much they know about the solution, like to demonstrate their competence through showing how they’re figuring things out, instead of asking the questions, receiving the information, creating the model to show that.

Sometimes they do just need to be quiet and you need to let somebody work out the answer in their head, need to probe them and ask more questions to get through it. But mostly, you’re quiet and you’re listening and you’re receptive, and you’re taking it all in.

Stakeholder Engagement Tip #6 – Use Your Analysis Tools to Discover the Gaps

Number six is use your analysis tools to help you discover those gaps and ask powerful questions. This might not happen all in one meeting. You might need to listen or ask a question, listen, go back, and have your quiet space to analyze and piece together all the information that you found, then come back and be like, as I was putting this together, I discovered this gap here and this gap here. That’s how you come back the second, third, and fourth time with more powerful questions that demonstrate your insight, your value and get people even more engaged.

Stakeholder Engagement Tip #7 – Clarify What You Don’t Understand

Number seven is clarify what you don’t understand instead of pretending you do understand. This sometimes means you have to go away and digest that information and schedule another follow-up meeting. Sometimes it means in the meeting itself you are defining a term, or instead, somebody’s talking and it’s sliding past me.

Bring yourself back. “What I hear you saying is this. Can you clarify this piece?” Or, “I didn’t catch this and this. Could you clarify that?” Or just asking, again, a clarifying question, clarifying terminology. It’s one of the most powerful things you can do as a business analyst is be the one who’s willing to clarify what you don’t understand.

Trust your brilliance. Trust your knowledge and your insight. Trust your ability to comprehend. Asking questions shows what you do understand and what you don’t, and that’s not a position of weakness, it’s a position of strength. I’m a smart person. I get a lot of things, but this piece isn’t clear to me and here is why it’s important to the project.

Stakeholder Engagement Tip #8 – Reflect Back What Changed as a Result of Stakeholder Input

Number eight, through all of that, reflect back what you’ve heard. There are a few powerful ways you can do this. One is an immediate paraphrase, “What I heard you say is this.” Another way is when we do go back to our desks and are doing our independent work on our analysis models, when we bring that back to our stakeholders to say, “Here are all the things I heard in our last discussion. Here are all the things I took away from that. Here’s the model I put together. Not just because I’m a business analyst and I know all these fancy models, but here’s what I put together to reflect and to summarize, and to capture what I think we, together, created.”

You’re involving them as a co-creator of that model even though you’re the one that did all the work in Visio or put the template together. But you want to show that what you put in there was a reflection of what you understood from them and, again, inviting additional feedback. You’re reflecting back that you value their input, and that’s going to lead to more input and engagement in the future.

Stakeholder Engagement Tip #9 – Assign Action Items

Number nine is assigning action items. When you are in a meeting and somebody’s like, “I just don’t know how that works. I need time to think about that.” Or, “I’m not sure if I want A, B, or C. I need to think about that.” If it’s legit, not just, “Let me think about that and I’ll get back to you later,” but “I really am not sure.”

One way is you can engage in discussing their decision process. You can help them through the decision. “Can you take some time to do that in the next couple of days? Could you get back to me with your decision on X, Y, and Z?”

You’re assigning a very clear action item. (I use an Issues List to manage this.) You’re linking it to forward progress in the project. You’re engaging them. It doesn’t always have to be in the meeting. You’re engaging them in the process. Or “I need to go research this and see how my team is going to handle this.” “Okay, great. How long did you need to do that and can we meet again in two days?” or “Can you summarize for everyone via email what that looks like so we can incorporate it into our decision-making process for this project?” Another way to engage people.

Stakeholder Engagement Tip #10 – Be Clear When Lack of Understanding is Holding Up the Process

Finally, #10, you want to be clear when lack of engagement is holding up the process. A lot of times I think people don’t understand that just showing up to a meeting isn’t enough. “I showed up for all the meetings that the BAs asked me to.” I didn’t realize that because of the way I was showing up unengaged or I couldn’t answer those questions, it was holding the project back.

It takes the discipline for you to know how does this decision fit into the context of the project, and where does it fit in the dependency so that we’re continuing to move forward. You have to have that structure, that approach, and that leadership for your project. It also means communicating to someone the impact that they’re having on the project. A bit of leadership, stepping into a bigger role for some of us as business analysts.

Stakeholder Engagement Tip Bonus: #11 – Believe in Yourself

I have one more bonus tip for you. That was #10, tying in to the result. The bonus tip for you is to believe in yourself. The more that you believe in yourself, in your tools, and have an inner confidence, this shows up in asking questions, in not being afraid to be the one who doesn’t understand a piece of things. The more you can believe in yourself, the more others will believe in you. And the more they will want to be around you and be engaged in the process because you are engaged in the process.

Again, this is Laura Brandenburg from Bridging the Gap. We had 10 tips here for engaging your stakeholders. We came in perfect just around 10 minutes. I hope that you take these tips and apply them to your career, and I’d love to hear what lands for you.

Download Your Free Guide – 10 Tips to Improve Stakeholder Engagement

Looking to Take These Stakeholder Tips With You?

• 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.

Click here to download our FREE GUIDE – 10 Tips to Improve Stakeholder Engagement

There are many requirements elicitation techniques. When many BAs think of elicitation, they think of big complex, full day workshops. In most cases, elicitation happens in much smaller sessions involving just a few stakeholders. 

In what follows, I’ll share my top 5 elicitation techniques that can help you get started on just about any type of project.

Hi, my name is Laura Brandenburg from Bridging the Gap. And today we’re going talk all about the requirements, elicitation techniques that are used by business analysts. I’m going a give you my five top requirements elicitation techniques, as well as a free checklist that you can download to help you get started right away.

When we think of requirements elicitation, most business analysts think of big, complex, full day workshops. Big events. The reality is in most cases, requirements elicitation happens in much smaller sessions and also techniques that don’t even involve stakeholder interaction at all. But those smaller sessions can involve just a few stakeholders. Let’s just take a step back and talk about what is requirements elicitation.

Simply put, elicitation is the process of discovering information that allows you to put together the requirements or draft and analyze the requirements. In particular, elicitation will often refer to engaging with stakeholders in some way to understand their needs and expectations when it comes to the scope and the detailed requirements of a project.

As I mentioned, there are techniques that do not explicitly involve stakeholder interaction. I’m going give you one of those in my top five as well. So let’s talk about these five requirement elicitation techniques.

Requirements Elicitation Technique #1 – Observation

Number one is observation. This is when you’re sitting with a user, or via screen share in a virtual environment, and you watch them do their work, or you have them demonstrate doing their work in a hypothetical way, like this is what I would do if I was processing a new account or processing an order or completing a refund.

There’s a distinction here in user experience circles. There’s sometimes a preference towards pure observation where the stakeholder doesn’t say anything that they would not say in their normal course of doing work and you as the business analyst don’t ask any questions, or for any clarifications. That is to achieve a different objective around really understanding the stakeholders full environment.

As a business analyst, we often will ask questions. We’ll have the stakeholder articulate what they’re thinking, why they’re doing what they’re doing, share the business logic, and we will ask those questions to really clarify the logic as well as alternative scenarios. If it looked like that one worked, what if we had clicked something else here, or if you didn’t receive that document. You start to ask questions so that you’re getting not just the stream of work for that particular instance, but for a broad range of instances.

Requirements Elicitation Technique #2 – Diagram Review / Walk-Through

The second requirement elicitation technique I want to share with you is to do a diagram review or a walkthrough. This could also be called prototyping. This is a great way to elicit unexpected information and to use the structure of a requirements model, like a workflow diagram, or a use case, or a wireframe or an entity relationship diagram, and to use that structure, to help collectively fill in that model which often leads to unexpected information surfacing.

You could start with a draft model. If it’s an entity relationship diagram, you could have a few key concepts drawn on the whiteboard or print it out in a sheet or up on a shared screen if you’re doing a sheet screen share. If you’re doing a wireframe, you could have kind of a skeleton with some navigation and some pieces in place. Or you could start with a blank page. It really depends on your stakeholder group and how adept they are at using that model. You could also start with a fairly finished draft of that model and walk through it piece by piece to get input and feedback from your stakeholder. All different ways to do walkthroughs and use the prototyping technique with different stakeholder groups.

Requirements Elicitation Technique #3 – Structured Interview

Now, the third technique I want to share with you is called a structured interview. This is by far the most common technique that business analysts use. It’s usually with either one or a small group of stakeholders in a meeting. It could be an in-person meeting, or it could be a virtual meeting. You want to be prepared for that kind of meeting with an agenda. You want a meeting agenda, and you want a requirements checklist. You want to know what questions you are going to ask. You might share that with your stakeholders ahead of time if you think they would benefit from doing some preparation. Some stakeholders are much better if you’re asking those questions on the fly and you don’t overwhelm them ahead of time with all the questions that you might have to ask.

You can download a sample requirements checklist absolutely for free. I really invite you to check that out as a way to start thinking through what questions would you ask in an interview. Of course, that checklist is for a specific type of requirement, so you want to be clear of what objective you are trying to accomplish in that meeting and what questions do you need to ask in order to discover the information to achieve that objective.

As you are using a structured interview, it’s really important that you actively engage your stakeholders. Here are a few of my top tips for building stakeholder engagement.

Requirements Elicitation Technique #4 – Documentation Review

I promised you one technique that did not involve stakeholder interaction, and that is our next technique. It’s called documentation review.

This is a requirement elicitation technique where you can discover a lot of information by analyzing any existing documentation to understand potential requirements. This can save a lot of stakeholder time. If your stakeholder time and your access to stakeholders is at a premium, you definitely want to prioritize what documentation you can review ahead of time so that you can be really prepared. It can help you come up with those questions for your structured interview or drafted diagram that you can use, or make your observation more clear as well, or more pointed and specific.

A big caveat on this is that as the business analyst, you don’t want to over invest in documentation reviews or make assumptions. You don’t want to use documentation that could be dated, might not reflect your actual stakeholder perspective to just decide what the requirements are. Often you need to come back to the stakeholders and validate the information that you’ve used or use it to develop, as I mentioned, the requirements checklist, the discovery checklist that will allow you to have a very productive, structured interview to ask those questions.

Requirements Elicitation Technique #5 – Survey or Questionnaire

Now, the fifth and final technique that is sort of a blend of stakeholder interaction, and that is to do a survey or a questionnaire. This is a great way to get information from a lot of people or from people with whom you don’t have a direct connection.

A survey is also a great way to receive more objective information in a low intensity way. Often people will write things into surveys that they may not share personally. On the flip side, sometimes the information is unclear and difficult to interpret without more context. We use surveys here at Bridging The Gap to gather feedback from potential customers and also to get feedback from our course participants after they complete the program.

Most BAs Use a Combination of Elicitation Techniques

You really want to be well adept at multiple techniques so that you can pick and choose what technique is going to work in your specific situation.

And again, if you want a quick way to get started, I invite you to download our free requirements checklist. It’s for a specific domain or specific area of requirements called supporting a customer. And then it will help you get started right away in just thinking through what questions to ask. Even if that’s not the area that you’re working on, just seeing the questions that are available and reinterpreting them for your specific situation is really going to help you get started in figuring out what questions to ask, which is often where business analysts get stuck in the first place.

I’d love to hear in the comments below what requirements elicitation techniques you use as a business analyst, where you want to improve on, and how you are finding that checklist, and how it’s helping you in your business analysis career.

Until next time, I’m Laura Brandenburg from Bridging the Gap. We build our profession one business analyst at a time, and success starts with you. Thanks for being here.

Knowing What Questions to Ask

Part of being strong at any elicitation technique is knowing what questions to ask. Here’s the next video I recommend to help you cultivate this skill set.

You’ll face issues like stakeholders not showing up to your meetings, unanswered questions about requirements that delay your project, and finger-pointing when issues inevitably surface late in the project.

Today’s question comes to us from Natasha, who asks:

“I have secured 5 min of time with my key stakeholder (cornered them in the corridor). They never worked with a BA before. What are the 3 most important things/ideas I should convey to them in order to start building some meaningful engagement?”

This is an important question and I answer it in today’s video.

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

Why Stakeholder Engagement Is Important

Today, I want to talk about the important concept of stakeholder engagement, specifically, how to cultivate those relationships with your stakeholders as a business analyst. When you do this, they tend to be more willing to answer your questions, show up to your meetings, review your requirements document, and your entire business analysis process goes much more smoothly. You want to pay attention to investing in those stakeholder relationships as an area where a little bit of investment has a huge result long term.

We’re going to talk about three different things that you can do to do this. Specifically, this question came from Natasha.  Natasha said, “Hey, I’ve cornered my stakeholder.  What three things should I share with them about business analysis?” Well, I’ve got the answer to that question, Natasha. I think it’s going to be a little bit different than you might think.

Stakeholder Engagement: Step 1 – Share What You Do

The first thing you want to do is share what you do, briefly. So, just kind of let them know,

“Hey, my name’s Natasha. I’m the business analyst on your next project. This is what I do as a business analyst. I’m going to be the one making sure we’re solving the right problem, writing the requirements documents, and facilitating that communication between business and technology.”

That might not be your exact description, but make sure you have a one-liner description about what you do.

Stakeholder Engagement: Step 2 – Ask a Question and LISTEN to the Answer

Now, you might think you want to drill into the detail there. My advice is, actually, different than that. From there, you want to ask a question. Make this a conversation. You don’t want to corner your stakeholders. You want to engage them in conversations. What you’re doing here is demonstrating that as their business analyst, you’re going to ask them questions, and you’re going to listen to the answers, and it starts with that very first conversation.

So, ask them a question.

• What’s your biggest concern about this project?
• Or, what’s the biggest benefit?
• What’s the juicy thing that we could accomplish in this project and what would that mean to you and your department?

Get them talking about the project, and then paraphrase back what you hear to show that you understood their answer.

Stakeholder Engagement: Step 3 – Share How You Can Help

That’s probably going to create an opportunity for you to share something else about what you do, but now you can share in the context of how you can help them with their concern or their project, or their benefit. When you do that, you can now drill in a little bit deeper about what it is you do as a business analyst.

Like,

“Oh, hey, you mentioned that on your last project a lot of things changed at the last minute and the solution wasn’t nearly as effective as you had hoped. One thing I can do when we get to that part of the project is really engage you in the changes that come up and make sure we’ve got our business process documented well and facilitate that kind of communication. Would that be helpful to you?”

Again, you’re asking another question to keep this very conversational.

We talked about sharing what you do, but briefly. We talked about asking questions and creating a conversation, and then following up with another specific example of what you can do and the context of how it’s going to help your stakeholder.

Stakeholder Engagement: Step 4 – Get Commitment for the Next Step

The last thing that you want to do is create an opening for a conversation. Again, we don’t necessarily want to corner people and make them feel like, “If I go to Natasha’s meeting or Laura’s meeting, I’m never going to get out. She’s just going to keep telling me things and asking me questions and I’m never going to get to leave.” You want to get them to engage with you and get what would be called a micro-commitment about the next step.

So,

“Hey, it’s been really great having this conversation. I’m glad we got to connect. I’d love to share a little bit more about what I do or talk a little bit more about the concerns that you have about this project. Can we schedule another meeting to talk about this further?”

or

“My next step is going to be to schedule a group discussion and I want to make sure that you’re involved, so look out for that email if you think you’ll be able to attend.”

You just want to get that next commitment about the next step. You want to commit to following up or acknowledging their time in some way. You can also, then, follow-up after the fact, which is going to demonstrate that you are the kind of person that follows through on your commitments. Through that thread of the conversation, you’re demonstrating a lot of different things about how you’re going to show up for them as a business analyst, and you’re showing them instead of telling them. You’re asking questions and you’re listening to the answers, and you’re showing that you understand.

You are, also, making a commitment, asking for their permission, following up on that commitment, following up on what you said you’re going to do. That kind of approach is going to build a solid foundation for a strong stakeholder commitment.

So, Natasha, you’re in a great spot that you’re thinking about this ahead of time. For anyone else listening in, think about one thing you could do this week to cultivate stakeholder engagement, a better stakeholder relationship, and really engaging those stakeholders in the business analysis process and in your project because it’s going to make your projects run more smoothly. It’s going to make it easier for you to do the things that you need to do and get the decisions made that are going to make your projects more successful.

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

One additional way to engage stakeholders is to be sure you don’t jump right into nitty gritty functional requirements before you understand their business process.

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.

A critical part of preparing for requirements elicitation is identifying a list of questions. You definitely want to avoid securing valuable stakeholder time only to be lost about what questions to ask! Some stakeholders will talk your ear off (forcing you to gently interrupt them to keep the meeting on track), but others need to be led through a structured conversation. 

Regardless of who I’m interviewing, I’ve found that preparing a list of requirements questions helps me keep the conversation on track. 

Here’s a video I recorded about preparing requirements questionnaires. 

This article is about identifying targeted questions for a project that has already been scoped, called a requirements questionnaire. If the scope of your project is not yet defined, you might want to check out “5 questions to ask before starting any technology project” for some generic elicitation questions that work on most any project. 

What is a Requirements Questionnaire?

A requirements questionnaire is a list of questions about the project requirements. Typically the questions are organized by feature (or business requirement or project objective). Essentially each high-level requirement from your scope document should have a list of questions to further refine your understanding.

Investing time in a requirements questionnaire will help ensure you engage your stakeholders, and also that you truly discover and not merely “gather” the requirements.

And while it might seem like this would take a lot of time, the reality is that a well-thought-out questionnaire helps you run a more effective stakeholder meeting and save you time in the long run. One of our course participants reported eliminating several follow-up meetings by using our requirements questionnaire checklists and active listening techniques.

(By the way, we’ve pulled together a collection of feature-specific questions and made them available in our Requirements Discovery Checklist Pack. You can also download a sample checklist absolutely free of charge.)

What Requirements Questions Should I Ask?

When creating a requirements questionnaire, I work through each feature one at a time. I write down what I know about that feature (or what I assume to be true about that feature). Then I go about drafting questions. Most of the time, the questions evolve naturally as I think through the implications of a feature. But sometimes I need to spur my thinking a bit.  Just like a good story, requirements will answer all the important questions. Think about the how, where, when, who, what, and why.

Here’s some generic questions you can use to spur your thinking.

How requirements questions

• How will your stakeholders use this feature?
• Is this feature a process and, if so, what are the steps? Or, what questions can I ask to ascertain the steps?
• How might we meet this business need?
• How might we think about this feature a bit differently?
• How will we know this is complete? Or, what are the success criteria?

Where requirements questions

• Where does the process start?
• Where would the user access this feature?
• Where would the user be located physically when using this feature? Are they at home? In the office? Offsite?
• Where would the results be visible?

When requirements questions

• When will this feature be used?
• When do you need to know about…?
• When will the feature fail?
• When will we be ready to start?
• When does this need to be completed by?

Who requirements questions

• Who will use this feature?
• Who will deliver the inputs for the feature?
• Who will receive the outputs of the feature?
• Who will learn about the results of someone using this feature?
• Who can I ask to learn more about this?

What requirements questions

• What do I know about this feature? Or, what assumptions am I making about this feature that I need to confirm?
• What does this feature need to do?
• What is the end result of doing this?
• What are the pieces of this feature?
• What needs to happen next?
• What must happen before?
• What if….? Think of all the alternative scenarios and ask questions about what should happen if those scenarios are true.
• What needs to be tracked?
• What device will the stakeholder be using when they use this feature?
• What other questions should I be asking? (This is always a good one for yielding unexpected answers!)

Why requirements questions

Why questions are great wrap-up questions as they help confirm that the requirements you just elicited map back to a need you identified when you scoped the project.

• Is there any other way to accomplish this?
• Does this feature meet the business need and solve the problem we’re trying to solve?
• When we implement this feature, what will be true?
• What’s the most important thing about this feature?
• And also, check out these 10 ways to discover what the problem really is.

You Won’t Ask the Questions One-by-One

The last thing you want to do with this list is run down your list of questions one-by-one. That can be a big waste of meeting time and often doesn’t lead to an engaging discussion.

Instead, I typically select a few core questions off the list and ask them to get the stakeholder talking. Then, as they are talking about their vision for the feature, I use this questions list to guide the conversation and ensure we’re discussing the feature completely. I would say I typically only actually ask about half of the questions on the list. The rest the stakeholder typically answers indirectly through conversation.

>>Get Your Free Checklist

Learn exactly what a sample requirements checklist looks like, with one sample from our Requirements Discovery Checklist Pack, which 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 download a free sample checklist

This is the under-the-radar STUFF that very few people talking about. But it’s very much the reality of many of the business analysts I hear from. You absolutely, positively do not need to feel alone if you’ve dealt with this situation before or are dealing with it right now.

I’ll let you check out the video or transcript for the full context, but here are a few of the bullet points:

• Team is new to agile
• Approved BRD with vague requirements
• Expected end date
• Focus on minutia

Whew…that’s a lot, right? What would you do? Listen in to learn about my suggestions for moving forward quickly.

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

The Agile Requirements Challenge

Today’s video is going to be a doozy because we are talking about what to do when your business team is still thinking waterfall, and you are in the middle of this, as a business analyst, needing to define requirements in an agile way and work within an agile software development team.

This question came to us straight from a member of our community. The name is Jean. Instead of me talking through it and embellishing it or thinking that I’m embellishing it, I’m going to read her question verbatim.

Jean says:

I’m working on a very large project and coming in after they’ve had the BRD review. We are new to the agile methodology. I’m trying to write user stories with unclear requirements and little training. So, it’s been a challenge. The chief product owners and business owners are not easily accessed. We are following the chain of command. They don’t understand or care what it’s going to take to get the project done. When we ask questions, they say, “Didn’t you read the BRD?” Got a lot of that one. Or send you to someone else. It’s not that simple, right, when you dive into the vague requirements? I keep trying to find ways to get this done and hit roadblocks, which make me feel very unsuccessful. As part of agile, we’re told to fail fast and fail early, but the business owners are still thinking waterfall. They have an end date, and they expect us to meet it. Plus, I’m co-product and my co-product owner is one that wants to drill into minutia, rather than focusing on the user stories and the product backlog.

Okay, so what would you do?

Getting to the Agile Requirements with Demos

Here’s what I would do. This might sound a little counter-intuitive, but I would take that BRD, the vague requirements that are in that BRD, and I would either demo the working software, if there is already working software. It sounds like there’s not. Or I’d create a set of wireframes. I would create wireframes that essentially model my current understanding of the requirements for a subset of the requirements. Then I would schedule a review meeting with those business stakeholders. You’re doing a few things with this technique.

One; you’re getting out of this. It’s in the BRD. You’re presenting a new deliverable that’s, obviously, taking the project forward. Everybody loves to look at a user interface, and everybody sees any user interface, like what’s missing, or what the gaps are. You have created a tool to get an immense amount of feedback quickly. You’re also modeling an agile practice when you do this. One of the big practices in agile is that you demo your working software.

Usually, it’s a working software, so the tech team would demo whatever they created in the sprint for their business users. But that, it sounds if the requirements are unclear, that could create a lot of waste. You’re dabbling in that practice, but you’re doing it in such a way where you’re creating a very throw away easy to create type of deliverable, a very low fidelity wireframe rather than a full-fledged working software system. You’re getting people into that practice of doing reviews, giving feedback, seeing early software representations, and using that as a tool to clarify the requirements.

Don’t Expect to Get the Wireframes “Right” the First Time

One word of warning on this, it’s going to take a bit of a thick skin because most likely, if those requirements are truly vague, or there are gaps in them, they’re going to be wrong. That is going to feel like, “Oh, I did something wrong.” But any time you’re putting a deliverable in front of a business user to get more information, to get more clarity, that’s what success looks like. Sometimes I like to equate wireframes, or any visual model, to coffee table books.

Do you put a coffee table book on the coffee table because you want your guests to sit and page through the whole thing, read the whole thing? No. It’s there because it represents a vacation you took or an interest you have, or something you found valuable. It’s there to create a conversation. It’s there so the guests may say, “Oh, you’ve been to Stonehenge. I went there so many years ago.” And, then all of a sudden, you’re talking and you’re having a conversation about something that’s meaningful to you both.

Wireframes and other visual models can work in, essentially, the same way. They’re conversation starters to get us out of question asking and critiquing, and this requirement isn’t clear enough and into what can we do to improve this model so that it fully represents what you want out of the software system.

Help Your Waterfall Stakeholders Transition to Agile One Step at a Time

The other thing is, once you have, then, those wireframes, that’s what you can use to create your user stories and your product backlog, and then you might start to see there’s a lot here. Can we prioritize some of these things? That’s that next level of education that you’ll want to do as an agile business analyst about how priorities and estimates work.

Quite honestly, that’s a bit that, as a business analyst, we’re facilitating priorities, and we’re facilitating the engagement in the priorities. But when it comes to the culture change that comes with agile, and the sponsor expects XYZ by X date vs. we prioritize, and we deliver the most important things first, and we’re not clear, or we can’t commit to what comes in by which date, that’s the project management tech team, whoever is leading agile in your organization needs to influence that kind of change in your organization.

You can step in as a business analyst and you can say, “Hey, it’s important now that we’re clear on our priorities because of how things are happening and these new processes we’re using. Let me make sure I understand your priorities and I’m going to help you prioritize this product backlog so that you get what’s most important to you. You can be a partner to the business and working with IT instead of having to feel like you are selling that part to IT. Try to sidestep that whole argument altogether, if you can.

Finally, the other note I had on this specific situation was, it sounds like you are a co-product owner, which that’s awesome. I love that there are two of you. You might be more big-picture thinker, and this other person might be more in the minutia, in the details. Can they be the one? You create the wireframes, maybe the first draft of the product backlog, help with that prioritization and getting things moving, and they can go and flash out all those details in user stories and almost treat you as a first past stakeholder to get some of those details, and then where you need to get more stakeholder involvement from the business as well.

Just a few thoughts for you, Jean. Definitely a challenging situation. Probably not uncommon. I’m recording a video on this because I believe a lot of people probably have this question about agile requirements and how to help our business stakeholders make the transition from this waterfall mindset to more agile, collaborative mindset. I do see so much potential for business analysts and organizations leveraging agile practices. I think it makes what we do as business analysts even more important. That’s why we’re recording a few videos this month on agile business analysis, specifically.

Again, I’m Laura Brandenburg, from Bridging the Gap. We help you start your business analysts career. Thanks for watching.

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.

Want to learn more? Watch this short video! And then register here for the free 3-part video training.

Today we’re taking a question from one Bridging the Gap community member, who gave us this scenario:

“In my company, there are no business requirements meetings. Business requirements are discussed among other meetings that include brainstorming, future feature planning, and the design reviews.  The timeframe is generally one hour and I don’t feel like I have the opportunity to ask the requirement questions I need and want to ask due to time constraints and the many agenda items in that meeting.

Again, I’m told requirements are not being captured completely.  What is a recommendation you can give to improve my performance?”

Listen in (or read the transcript) to learn about my suggestions for improving BA job performance and resolving incomplete requirements.

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

Today, let’s talk about how to avoid incomplete requirements. This is a big one; a juicy topic. It’s important as BAs. This is how we know that we did what we were supposed to do is if we avoid missing requirements.

Let’s talk about it and let’s dive right in.

Before we talk about the tips I have, I want to share the question that came out because I think it’s so insightful. The kind of pressure that we put on ourselves as BAs, it comes out in this question. Here’s the question from this reader.

“In my company, there are no business requirements meetings. Business requirements are discussed among other meetings that include brainstorming, future feature planning, and the design reviews. The timeframe is generally one hour, and I don’t feel like I have the opportunity to ask requirements questions that I need to and want to ask due to time constraints and the many agenda items in that meeting.

Again, I’m told the requirements are not being captured completely. What is a recommendation you can give to improve my performance?”

Big issues here. That pressure of trying to get things done in a short amount of time, feeling like you need to work within somebody else’s meeting, and then being told that you’re not doing a good job. This is not fun.

Let’s dig into exactly what to do here.

The Solution to Incomplete Business Requirements – First, Get Clear on Your Role

The first thing is you want to get clear on your role. Whenever performance issues are at stake, understand what is it that, as a business analyst, that you’re truly responsible for. Not all business analyst roles are the same, and your role might be a little bit different than you expect. The number one reason people have performance issues is because they’re trying to deliver something that people aren’t expecting of them.

You really want to get clear on what those expectations are. Talk to your project manager, talk to your manager, and talk to the stakeholders who use your requirements. Understand what would help them the most and how you can make the best contribution. What gap are you responsible for filling? That’s what you’re looking for here.

The Solution to Incomplete Requirements – Second, Take Ownership of the Requirements Process

Then you want to take ownership of the requirements process. The last thing you want to do is try to fit your requirements process into somebody else’s meeting schedule. As business analysts, we’re typically scheduling meetings, planning out the elicitation and discovery process, planning out the review process of our documentation, which we’re going to get to next. You want to take ownership of that process. Then say,

“In order to deliver on that role that we just clarified for me, these are the steps that I need to take.”

Often, it’s going to be a couple of discussions to discover the information, a couple of reviews, some time to do analysis in between that, and reviews and validation that you’ve got to write. You want to take ownership of that process and say, “This is what we need to do.” And then, schedule those meetings, the time you think you need, probably giving yourself a little bit extra time even, and work to make those productive, effective meetings that move the requirements forward. That’s the second thing.

The Solution to Incomplete Business Requirements – Third, Don’t Skip Reviews and Validations

The third thing is to be sure not to skip those validations and reviews. Just showing up to meetings and asking a couple of questions is not enough. It’s a guarantee that you will miss requirements if you’re only asking questions. You also need to do some sort of walk-through and validation.

Now, this doesn’t have to be five hours sitting and reviewing a 50-page document. I’ve done that. Early in my career, that’s how we validated requirements. It was painful. It worked to a certain extent. There were some flaws in that. It’s not a best practice today. But you have to do some sort of a walk-through. It could be a wireframe walk-through. It could be a process flow diagram walk-through. It could be a use case walk-through or a business process walk-through.

Whatever it is, it’s that validation that the documentation that you’ve created, the analysis you’ve done is complete, and is it missing anything? That’s when you get that “Yes, but” response from stakeholders that leads you to new requirements that you’re going to miss if you’re just asking questions.

The Solution to Incomplete Business Requirements – If You Have Resistance

Then, what’s next? You have to do what we just said. Clarify your role, own the process, and then do the validation process, too, which is where the new requirements are going to come.

You might have resistance to this. If there is a reason that somebody’s giving you only a few minutes on an agenda item, they don’t think that this is what business analysis takes. They feel like you just are going to create the requirements out of thin air. You might have some resistance at first. You want to demonstrate your value quickly and easily. Make sure those first meetings you schedule are productive.

You might start by, instead of the whole thing we just laid out, take ownership of one issue that came up in the meeting and say, “I will schedule a meeting to make sure we discuss that issue.” If an issue is in a meeting that’s going off track and you can tell it’s going to derail the meeting, you can say,

“I’d love to jump in and I can schedule a follow-up with just the people that need to be there. We will handle that issue and make sure we get the requirements defined for that issue.”

Just take ownership of it. Demonstrate that you’re starting to work in a new way, and that you’re ready to contribute, and that you’re able to contribute in that new way. That’s one way to start breaking down the resistance to the process.

Another is when those issues requirements do come up, say,

“This is what I want to do to correct that. I’d like to hold a meeting, go through the requirements document, make sure that this time I haven’t missed anything.”

Really get the stakeholders involved, and use that as a solution to when these performance issues come up. Suggest an alternate approach and use that as a time to get buy-in. You’ve got to overcome it. Until you take ownership of the process and have the space to take ownership of the BA process, you will continue to miss requirements. You’ll continue to feel like you’re scrambling and rushing and not getting what you need. You’ll be reactive instead of proactive.

How can you shift from that reactive, “I don’t have enough time,” to “Here is what I need to be successful as a business analyst, and here’s what I’m going to do.”

Again. I hope that’s helpful. Good luck. It’s a tough challenge. It’s a tough situation. But I know that you can do it and I know these suggestions are going to help you improve your work as a business analyst overall.

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!).

Being the insightful business analyst you are, you realize that this new field does not just impact the customer service team. You get Bob from accounting involved, as well as Samantha, the head of sales.

Bob is excited about the new field and wants it also included in a few of the reports the accounting team uses. Samantha is ambivalent, but insists it be optional and would prefer two fields instead of one. Joy absolutely insists on a single field and says it is required.

As you facilitate the requirements discussion, Samantha and Joy clash regarding what the feature should look like while Bob provides a slew of new feature ideas assuming one or the other version of the field exists. You don’t see any end to the back-and-forth debate, let alone the rabbit hole Bob is leading you down.

These types of conflicts are common, even in the smallest of business analysis projects. Typically the root cause goes back to any combination of the following three issues:

Process

The debate about the field (or feature) has ignored the process (or how and when data for the field will be collected and used). Joy most likely assumes the sales person will fill in this field. Samantha may have concerns about her salespeople providing accurate information. Looking at the end-to-end process for closing and fulfilling a contract could help everyone understand who collects this information, when it is finalized, and if and when it might change.

Terminology

The term contract may be deceptively simple and doesn’t necessarily have one defined meaning. Samantha’s perspective on a contract might be during the pre-sales negotiation period. Joy is probably thinking about a finalized contract her team needs to fulfill. Bob might be thinking about a contract that’s ready for invoicing. Asking everyone to share their interpretation of the term could lead to a more fruitful discussion.

Organizational Issues

Technology changes are almost always tied back to larger organizational issues, otherwise known as politics. Instead of going directly to sales and asking for the information her team needs to do its job, Joy proposes a required field. Samantha’s resistance is actually a very positive response. A less direct stakeholder would allow the field to be required and let their sales people put a ballpark number into the field, which might pacify Joy in the short-term but not solve the underlying problem.

Feature battles are rarely so much about the features themselves as they are about process, terminology, and politics. When you find your stakeholders disagreeing about features, drive the conversation backward to the underlying cause and you’ll be able to guide a much more productive and effective discussion.

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.

Taking ownership of the issues that naturally come up as part of the requirements process prevents unnecessary drama and enables the entire team to stay focused on working through the most important requirements first.

By methodically communicating about new issues, the work you are doing to resolve issues, and when an issue is resolved, you’ll be able to actively manage the issues that naturally surface during the requirements process in a professional way.

Here’s a quick visual map you can use to remember what pieces of communication to send about the issues that come up on your projects.

Click here to download this visual map in PDF format and save it for future use. You also might want to check out our Email Communication Templates for copy-and-paste email templates covering each of the scenarios discussed here.

Now, let’s go through some quick tips for each aspect of managing issues.

Identify an Issue

When you identify a new project issue, you can use email to send a clear description of the issue, the potential impact, and the steps you are taking to resolve it. By communicating early, you get in front of the issue and get to frame it, potentially in a more positive way than someone else would.

What’s more, you aren’t just signaling the alarm. You are also demonstrating that you’ve taken ownership of moving the resolution process forward.

You can take a similar approach when someone else raises a new issue via email. These email chains can get a little messy. By replying and taking ownership of the issue, you’ll prevent unnecessary drama.

Resolve Issue

Most likely the work you do to resolve the issue will not happen via email – you’ll be facilitating meetings, analyzing options, and doing research.

However, email is an important communication tool to keep stakeholders in the loop. If the issue is a visible one, it may be necessary to update key stakeholders as you move through the resolution process with more information and next steps.

What’s more, even while you are using virtual or face-to-face collaboration methods to resolve the issue, a team member may try to resolve all or part of the issue via email. Once a few emails are unsuccessful at closing things off, you’ll want to stop the back and forth from distracting everyone by sending an email letting everyone know you’ll be organizing a meeting to collaborate on the topic at hand.

Communicate About a Resolved Issue

Finally, once an issue is resolved, you’ll want to communicate the end result to all interested stakeholders.

One way to elevate yourself and take more control over the requirements process is to make more decisions and recommendations when it comes to how to resolve issues. For example, instead of sending an email with three options and asking the sponsor to choose one, send an email briefly summarizing the three options your team considered, recommend one option, and seek input only if the sponsor disagrees with the decision.

Other times, there may be only one viable resolution and in this case you simply need to communicate what’s being done to resolve the issue.

In still other cases, you may identify and resolve a smaller issue in the course of your work, but find it prudent to share the decision process with a wider group. For example, if you identify a requirement change that has a minor impact and are able to confirm with the developer that it can be incorporated without a schedule delay, you may opt to jump right to the final stage of the process by sending out an informative notification.

A Quick Synopsis

A constant stream of new and resolved issues is to be expected as part of the requirements process. Professional business analysts take ownership of issues, the work being done to resolve them, and the decision-making process to ensure that issues do not become distractions.

Start with Trusted Email Templates for Managing Issues

When you download the Email Communication Templates, you’ll receive 32 copy-and-paste email templates covering business analyst work scenarios, such as managing issues, that can be handled effectively via email.

Click here to learn more about the Email Communication Templates

As requirements authors and analyzers, it’s really easy to get so wrapped up in the process that you take on more ownership than is prudent. However, when stakeholders do not buy into the requirements, you can expect change requests late in the development cycle and a longer process to put the solution to use.

By methodically seeking feedback at each stage of the requirements process and using email correctly as part of this process, you’ll get critical input on your documentation and ensure your stakeholders embrace the upcoming changes to their processes.

(This is the third installment of a 4-part series going into a little more detail on the things I would have liked to have known before I started my business analyst career.)

Here’s a quick visual map you can use to remember what pieces of communication to consider sending on a project when it comes to the 4 steps to finalize a requirements document.

Click here to download this visual map in PDF format and save it for future use. You also might want to check out our Email Communication Templates for copy-and-paste email templates covering each of the scenarios discussed here.

Now, let’s take a closer look at how we can get the input we need on a requirements document.

Step 1 – Create an Initial Draft

To create a first draft, the business analyst may do independent research or meet with stakeholders to seek their high-level input.

Either way, the first draft is not the final draft – ever. Yet it is sensible to send an early draft out for review, as this can help get questions answered and move the requirements process along.

The important thing when sending out an early draft for review is to emphasize that this is indeed a working draft and that stakeholder input is still required. Highlighting specific questions you have and identifying next steps can help manage stakeholder expectations.

Step 2 – Obtain Input and Answer Questions

Once the first draft is complete, you’ll need to obtain additional input and get questions answered. Most often, you’ll conduct a requirements walk-through.

On occasion, it may be more efficient to receive answers to key questions via email. In this case, send an email with the specific questions you have and attach the draft copy of your deliverable for more background information.

Step 3 – Send a Deliverable for Final Review

Once a requirements document has been reviewed and key questions resolved, you will have a document that’s ready for final review and approval. Email is a great way to manage this kind of task.

Simply attach the document to your email, explain what’s expected of your stakeholders, communicate a deadline by which you need their feedback or approval, and hit send.

Since stakeholders are busy, plan to remind them before the deadline. Including a description of how their approval helps move the project forward can help them carve out time for this task.

Step 4 – Finalize Deliverable

Once you go through the above steps, sometimes multiple times, you’ll have your approved document. This is a step to communicate (and celebrate)!

Send the final deliverable out to anyone who needs to know about the final document, including those involved in implementing and testing against the specification.

A Quick Synopsis

Reviewing and validating requirements takes a lot of work. Using a clear, consistent, and methodical communication process will keep things running smoothly and ensure your stakeholders have clear expectations about what their contributions should be.

Start with Trusted Email Templates for Reviewing and Finalizing Deliverables

When you download the Email Communication Templates, you’ll receive 32 copy-and-paste email templates covering business analyst work scenarios, such as reviewing and finalizing deliverables, that can be handled effectively via email.

Click here to learn more about the Email Communication Templates

Pushy isn’t easy, and it isn’t in our DNA as business analysts. Yet, when we wait around passively for information, we can subject our projects to a whole host of problems.

• I remember a project where I waited weeks for a developer to provide input on the feasibility of a requirement, only to discover that a high-priority business need would take weeks to accomplish instead of days. We had to re-scope the project.
• In another situation, a business stakeholder took their time getting back to me about how their process worked. I made assumptions so I could move forward with the requirements, only to discover that I was wrong. This led to a lot of rework and a missed deadline.

Waiting for information is one of the primary reasons I see business analysts get stuck on their projects and branded as people who cannot meet deadlines.

With experience, I learned not to wait for the information I needed as part of the requirements process.

By the way, if you want to learn my top tips to getting stakeholders more actively involved on projects, Click Here to Download a Free Guide – 10 Tips to Improving Stakeholder Engagement.

Today’s article is about how to follow-up to get the information you need from stakeholders. When you are methodical about your requests and follow-up in a clear and polite way, you can be proactive and professional without being pushy.

(This is the second installment of a 4-part series going into a little more detail on the things I would have liked to have known before I started my business analyst career.)

Here’s a quick visual map you can use to remember what pieces of communication to consider sending on a project when it comes to getting information.

Click here to download this visual map in PDF format and save it for future use. You also might want to check out our Email Communication Templates for copy-and-paste email templates covering each of the scenarios discussed here.

Now, let’s take a closer look at how we get information.

Frame Your Original Request Clearly and with a Deadline

A clear information request is more likely to get you the answer you need. Take care to think through what an ideal answer would look like and phrase your request accordingly.

And while it can feel a little uncomfortable to set deadlines, without one your stakeholder won’t know when you need this information to keep the project moving forward. Providing a deadline is the professional thing to do and it saves everyone time in the long run.

What’s more, a deadline is an important tool for following up. Let’s look at that part of the process next.

Follow-Up on Your Information Request

Stakeholders are busy people and it is not uncommon for a request to get pushed to the bottom of their email, accidentally deleted, or missed completely. Follow-up early and then follow-up again if needed. One or two polite check-ins will often create the result you are looking for.

When a deadline has been established, following up is not pushy. It’s a professional reminder of a shared commitment. It’s a communication you send in the best interest of the project as a whole.

Escalate Information Request

Despite all of your follow-up, there will be times when you simply don’t hear back and you need to escalate. When you do so, be respectful while also clearly describing what you’ve done so far to get the information you need.

Look at it this way – if you don’t escalate when others hold up your work, then someone is likely going to escalate when you hold up theirs!

A Quick Synopsis

Successful business analysts are proactive. They know what information they need, they know who to get it from, and they find ways to politely follow-up until they get it. This skill is one of those areas that tends to fall under the radar and shows up in job descriptions with phrases like “gets things done”, “manages stakeholders”, and “is deadline-oriented”.

You can be proactive without being pushy as long as you manage your information requests and communications in a clear and methodical way.

Start with Trusted Email Templates for Requesting Information

When you download the Email Communication Templates, you’ll receive 32 copy-and-paste email templates covering business analyst work scenarios, such as requesting information, that can be handled effectively via email.

Click here to learn more about the Email Communication Templates

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.

You as the business analyst sit down and write a carefully crafted email with a very thoughtful question and send it off to your very busy stakeholder for an answer.

This email is likely to be met with one of the following types of responses:

• A quick response with exactly the information you need.
• A quick response with the wrong information.
• A delayed response, perhaps a day or two later, with a partial answer to your question.
• A delayed response indicating that they do not have the information you need or do not understand your question.
• No response at all.

The first type of response, which is often what you are hoping for, can be extremely likely, but only if three criteria are met:

• You have a strong relationship with this stakeholder.
• You are working on a project the stakeholder perceives to be high priority.
• Most importantly, you have asked a simple question that is easy to understand and answer.

However, how often are the questions we ask about requirements simple? And how often are they truly, from a stakeholder perspective, easy to answer? Moreover, when is your stakeholder relationship and project priority going to put responding to your email up at the top of your stakeholder’s list of tasks to invest their time into with diligence?

The probability of all of these criteria being met is actually very low, meaning that email is most often not the best way to get answers to your requirements questions.

Email can be preferable to us as business analysts because it feels safe. It gives us time to carefully choose and rewrite our words and thoughtfully phrase our question.

But more often than not, the answers we receive (if we receive them at all) do not have the information we need. And even if they do, we have follow-up questions that now require subsequent carefully crafted emails.

While we might feel productive, we’re actually wasting precious time and energy, writing emails, waiting for responses, and figuring out our follow-up responses. Yet we still have not received information that can help us move our project forward.

If this sounds like a scenario you’ve faced, it’s time to step up and start facilitating discussions to get your requirements questions answered. Face-to-face or virtual meetings provide the time and space for you to present information, clarify questions, and ask follow-up questions. They also provide space for stakeholders to clarify what information is needed, think through (or talk through) their response, and bounce their ideas off of other stakeholders.

Before you write your next email, consider whether you should be picking up the phone or scheduling a short meeting instead. A good rule of thumb is if you can’t write the email in less than 5 minutes, you’ll probably be more effective facilitating a discussion.

Here are a few articles to get you started planning discussions, so you can feel confident and get the most value out of yours and your stakeholders’ time.

How to Create Quick and Effective Meeting Agendas

Facilitate More Effective Meetings: 3 Things to Do in the First 5 Minutes

How I Take Notes and Facilitate the Discussion Without Driving Myself Crazy

Start with Trusted Email Templates 

When you download the Email Communication Templates, you’ll receive 32 copy-and-paste email templates covering business analyst work scenarios that can be handled effectively via email.

Click here to learn more about the Email Communication Templates

In this post, we identify the type of knowledge you need, 11 questions you should be asking, and how to document and synthesize the information you pull together.

Acquiring Business and Systems Knowledge

When working with a new client, I often build my knowledge of the business processes and systems in parallel, but I give priority to understanding the business. Without understanding how the business process works, it can be nearly impossible to understand where it’s going, help plan how to get there, and determine how to build or customize systems to support that direction.

Some aspects of the business can be ascertained by the company’s website, and I spend a fair amount of time understanding the business with publicly available information and explore the product or system as well. But most understanding comes from talking to people within the business, whether during the course of elicitation sessions or in an initial “getting acquainted” meeting.

But when you are working on a new business, how do you know what questions to ask in the first place? Let’s look at some high-level conversation-starting questions that are useful in obtaining a big-picture view of the business.

Understanding the Business Domain

Here are some thoughts about the questions to ask and answer to get a high-level understanding of how a business works.

1. Who is the customer?
2. What is the product?
3. How is the product sold? (online, phone, in-person sales)
4. What is the cost structure of the product? (subscription, pay-per-unit, etc)
5. Where does the money go?
6. How do we fulfill or distribute the product?
7. How do we produce or service the product?
8. How do we support the customer?
9. How do we market the product?
10. What partners do we work with to do business? How do we manage these relationships?
11. What information does the organization manage? Who is responsible for creating, updating, and retiring information? What systems are used to manage the information.

These questions are fairly high-level and they will lead you to obtaining a big-picture overview of the business model. As you work on specific projects, you’ll want to dial in more specifically and get more detailed in your questions. This is when creating a project-specific requirements questionnaire is useful.

(By the way, we’ve pulled together a collection of feature-specific questions and made them available in our Requirements Discovery Checklist Pack. You can also download a sample checklist absolutely free of charge.)

Documenting the Business Domain

As you create the big-picture view, there are a few requirements documents that can be particularly useful to create. Let’s look at how the glossary, business processes, and use cases work together to give you an overview of the business.

• Glossary – This document captures the key terminology that’s used in the organization and can help you keep variations and acronyms straight.
• Business Processes – Business Process Models capture the step-by-step sequence of activities completed to achieve specific business goals. At a high-level, a list of business processes and some simple workflow diagrams is often enough documentation. Business processes identify what the people in your organization actually do to achieve the organization’s high-level objectives.
• Use Cases  – Use cases capture the functional requirements fulfilled by a system in context. They identify what software capabilities are in place to support your business processes and look at technology systems from the view of the end user. At a high-level, a use case list with brief descriptions might be a good starting point. As you dial into the details, fully fleshed-out use cases can be a good idea.

With a clear understanding of terminology, a view of the current business processes, and the identification of the functional or feature areas covered by the organization’s systems, you’ll be prepared to talk the talk of the business and relate any new project work back to the big picture view.

I also find that a short narrative or visual model identifying the customers, products, and supporting processes puts everything in context and is great to refer back to.

Sometimes it can feel like you’ll never stop learning more about a new business domain. That’s a common feeling and it’s not necessary to learn everything there is to know upfront. As you are assigned to projects, you can always drill into more detail and you’ll definitely want to discover the specific business needs driving the initiative and key objectives to be delivered by the project.

>>Download a FREE Requirements Checklist

As business analysts, identifying the questions to ask during requirements elicitation is incredibly important. To help you ask better questions, we offer an absolutely free requirements checklist – this is just one example from our Requirements Discovery Checklist Pack – and you’ll learn what a requirements checklist looks like in the example of Supporting Customers.

>>Click here to download the free checklist<<

This is one of my favorite parts of business analysis – it’s when the analysis meets the people part of the role. And while it can be really challenging, it also tends to be a lot of fun.

In what follows, I’ll share 53 tips for improving your elicitation skills. Use these tips to make concrete improvements to how you discover the requirements for your next project. I guarantee you’ll find something you may have missed otherwise.

Get to the Root of the Problem

#1 – Get Context. Before diving into the details, be sure you understand the purpose and scope behind the project. This gives you context for your requirements development effort and tends to surface new, related questions.

#2 – Ask Why. You will most likely not get a direct answer the first time you ask “why”. Often you have to ask why multiple ways to get to the real problem to be solved.

#3 – Ask Why with Finesse. Most likely, you won’t want to ask “why” directly anyway. Most of the best “why” questions actually start with who, what, when, where, or how. I call this asking “why” with finesse.

#4 – Use Provocative Questions. Provocative questions can encourage lateral thinking, which will lead you to assumptions, constraints, and business drivers you might not discover otherwise.

#5 – Explore All Facets of the Why. The “why” or the business need is actually not a singular piece of information. There are at least 3 facets of the business need to explore – the business objectives, the business problem, and the desired outcome.

#6 – Revisit the Problem. Revisit the problem at the beginning of every discussion. Or, on a large project, revisit the slice of the problem you are addressing in this particular discussion. This helps keep everyone focused and encourages creativity.

#7 – Talk About Solutions. It’s common for stakeholders to bring solution ideas to the table. Some BAs will sideline discussions of any solutions early on. This can lead to tense discussions. Another approach to getting your stakeholders to focus on business requirements is to ask questions about the solution to discover the problem behind it. This is another way to ask “why” with finesse.

(By the way, each one of the checklists in our Requirements Discovery Checklist Pack possible business rationales for each feature, so you can go into a conversion prepared to understand the potential value of any solution idea your stakeholders are throwing at you.)

Looking for more tips on asking better requirements questions? We’ve got you covered with this video tutorial.

Listen, Really Listen

#8 – Be Quiet. While there is a time and place to present your own ideas, keep the focus on listening to get more information from your stakeholders. If you are used to being an active contributor and making your opinions heard, this can take a lot of work.

#9 – Stop Thinking! Listening also means allowing stakeholder needs to drive the conversation. Many professionals that come to BA from a technical background find it difficult to turn their analytical “what’s possible” hat off long enough to understand what the real need is. Sometimes it really does help to stop thinking (not forever, just for a little bit!).

#10 – Use Active Listening Techniques. If your stakeholders tend to repeat themselves, in all likelihood they are not feeling heard. In addition to passive listening, be sure to use active listening techniques so they know you heard what they had to say.

#11 – Ask Follow-Up Questions. Following on the above, follow-up questions help you continue to dig a little bit deeper and not accept what your stakeholders tell you at face value.

#12 -Ask “Stupid” Questions. There is only one stupid question – the one you didn’t ask. Ask your questions. Avoid making assumptions, even ridiculously obvious ones.

#13 – Avoid Audio Recordings. Many BAs are tempted to create audio recordings of their meetings. I think this practice, while well-intentioned, encourages lazy meeting facilitation practices and lazy listening practices. Instead of recording a fast-paced discussion, a better practice is to slow the pace of the discussion down so you and everyone involved can keep up. Don’t let a piece of technology be your ears. If you can’t keep up, someone else isn’t keeping up either and so you are not getting all the input you need.

Use Different Elicitation Techniques

#14 – Consider All Elicitation Techniques. Many BAs rely on one elicitation technique or mix of techniques over and over again. While there is value in repetition, considering the full range of elicitation techniques can keep things fresh and interesting. It can also ensure you are applying the right technique for the right type of project, which will surface more requirements earlier in the process.

#15 – Create Deliverables. Elicitation is not just about talking and interviewing. It’s also about reviewing deliverables. I like to provide wireframes and draft use cases or business process models and even data models to kickstart the elicitation process. (We cover all of these techniques and more in The Business Analyst Blueprint® training program.)

#16 – Conduct Walk-Throughs. As you are getting closer to finding all of the requirements, a requirements review can lead to the discovery of any remaining requirements.

#17 – Avoid Walk-Throughs When Appropriate. But requirements walk-throughs don’t work for all situations. Sometimes focused discussions, process walk-throughs, and selective reviews are better choices. Expand your elicitation skills by choosing a technique based on the needs of your project, not because it “must be done”.

#18 – Keep Moving Even Without Your Stakeholders. While you’ll undoubtedly be talking to stakeholders frequently and getting their input, there are many activities a BA can do in advance of stakeholder availability. Getting started can help you be more prepared when stakeholders are available and ask better questions. Here are 3 elicitation techniques you can do without stakeholder access.

#19 – Experiment With Less-Common Techniques. Don’t forget some of the less-used techniques as well, like brainstorming, surveys, and focus groups. In the right situation, any one of these techniques can engage your customers in the requirements process and expose your team to new ways of thinking about your solution.

#20 – Avoid Shiny Object-Syndrome. Never use a technique just to use a new technique. Focusing too much time on a new technique could leave you with too little time to implement the techniques that will actually work for your project. Always look at what technique will get you the best information given the time you have.

Elicitation is a lot easier when you are clear on what type of requirements documentation to create. This video walks you through the top 5 requirements documents that business analysts need to know.

Prepare, Prepare, Prepare

#21 – Look Ahead. Always be thinking a step or two ahead in the project. Looking ahead will give you the context for what needs to be discovered now to get to that step and will make you more confident and efficient in elicitation.

#22 – Prepare Questions. As you get into the details of a project, use requirements questionnaires to think through a problem and go into a meeting with as many questions as possible thought of.

#23 – Analyze Documents. And remember that not all information comes directly from your stakeholders. Document analysis is an elicitation technique that can help you discover the questions you should be asking. Interface analysis works well too.

#24 – Prepare Possible Answers. Sometimes your stakeholders simply don’t have an answer to a question. Being prepared with possible answers or options can get the conversation going and encourage constructive thinking.

#25 – Accept the Unknown. While preparation is important, the whole point of eliciting information is to discover information that you or the team is not currently aware of. Accept the fact that elicitation, by its very nature, involves dealing with the unexpected.  You won’t be prepared for every possible scenario. Sometimes you’ll have to think and act on-the-fly.

The “When” Behind Elicitation Matters Too

#26 – Elicitation Happens Throughout the Project. A common misconception is that all of the elicitation happens early in the process, before a requirements deliverable is drafted or anything is analyzed. In reality, elicitation happens all through the lifecycle of the project. It’s the BA’s job to discover as many requirements as possible as early in the lifecycle as is prudent (what’s prudent depends on what type of project methodology your team is using). This means that more elicitation tends to happen early in a project. But in general, be prepared to continue to discover requirements even after the initial sweep.

#27 – Be Critical of “Just in Time” Requirements Practices. Even in an agile environment, looking ahead a few sprints or stepping back and looking at the big picture can make a lot more sense than “just in time” requirements practices. Because elicitation involves discovering unknowns, getting just enough ahead can actually help prevent waste and minimize requirements risk. It can also help you avoid being rushed and overlooking obvious requirements that need to be dealt with later.

#28 – No Sweeping! Avoid any tendency you have to sweep new information under the rug. This tends to happen when information surfaces later than you wish (I know, I’ve been there) and what you really want to do is turn back time and ask another question at your kick-off meeting. This will lead nowhere good. Believe me, the information will pop up again sooner or later, and the sooner the better, even if it’s later than you like.

#29 – Be a Sounding Board. Be ready to have an elicitation conversation anywhere. I’ve had them while heating up my lunch, at an employee happy hour, and in the bathroom. I like to think of myself as a sounding board for new ideas. When new information is ready to come out, embrace it!

It’s much easier to know what to do when if you have aa trusted business analysis process framework. Feel free to start with ours!

Know Your Stakeholders

#30 – Find Your Stakeholders. First things first, who are your stakeholders? What do they have to contribute? What do you need them to contribute? Creating a stakeholder list is a good first step to understanding who you will be working with on a project and make sure that you don’t leave anyone out of the elicitation process.

#31 – Build Stakeholder Relationships. Invest some time in building positive stakeholder relationships. Communicate clearly. Keep your commitments. And look for opportunities to prove yourself and demonstrate your commitment to the project and organization.

#32 – Customize Your Approach. Different stakeholders learn and provide information in different ways. Some like to prepare and give you specific answers. Some need you to talk through everything with them. Customize your approach to respond to your stakeholders and you’ll get the most possible information from all of them.

#33 – Avoid Playing Favorites. While there are differences, there is no better or worse. (That is, unless you have an issue you could raise with your human resources department.) All stakeholders have their advantages and their challenges.

#34 – Ask For Feedback. Get input from your stakeholders anytime you can. My stakeholders have given some great ideas that, once I implement, save us all time and energy. Get their ideas about sequencing, questions, deliverables, and how meetings are facilitated.

#35 – Deal With Withholding Stakeholders. When a stakeholder seems to be withholding information, take time to talk to them one-on-one to hear their concerns.

#36 – Deal With Stakeholders Who Aren’t Engaged. Take time to talk to them one-on-one about what you need from them for the project to be successful.

#37 – But if Several Stakeholders Are Not Engaged, Look For Other Problems. When several stakeholders are not engaged or not showing up for your meetings, it’s either something about your approach or an organizational issue. Sit down with a stakeholder and ask for feedback about how the project is going and find out where the distraction is. Confirm the priority of your project with your manager or project manager. See what’s standing in the way of their engagement and respond accordingly.

Looking for even more stakeholder engagement tips? We’ve got you covered!

Increase Your Input with Effective Meetings

#38 – Prepare for Your Meetings. Many of the challenges that surface with elicitation can be eased with a little preparation. Take time to prepare for your meetings. I like to set aside about an hour for every hour I will be facilitating. (And it will be easier to get people to show up for your meetings if you are consistently prepared to run an effective meeting.)

#39 – Create Agendas. Create an agenda so that everyone knows what to expect and what they can do to prepare. Send out the agenda ahead of the meeting. Always. Even if it’s a one sentence description of what you hope to accomplish and two bullet points. Send it out.

#40 – Pay Attention to the Meeting Kick-Off. Begin the meeting by summarizing the project status, confirming the purpose of the meeting, and defining each attendee’s contribution.

#41 – Stay Focused. Many BAs complain that they can’t keep their meeting attendees focused. When a meeting heads off track, you risk missing important information. Everyone’s distracted and thinking about something new, not the requirements for your project. As a BA, it’s important you actively keep the meetings you facilitate on track, by addressing side conversations head on and engaging people where they are at.

#42 – Take Notes. Always, always, and I mean always, take notes. Capture the results of every elicitation session, whether that’s by taking a snapshot of the whiteboard or typing up your notes from the meeting.

#43 – Do Not Allow Bystanders. Avoid having bystanders at your meetings. Everyone should be expected to contribute. Non-contributors throw off the balance of the team and make contributors wary about giving all the information. People who don’t contribute could be withholding information that everyone needs to be aware of.

#44 – Go Small. Smaller meetings are easier to facilitate, keep focused, and get input from everyone. If you are having trouble facilitating an effective meeting, look for opportunities to limit the number of participants or shorten the duration of the meeting.

Facilitating effective meetings is just one of a BA’s necessary super powers. Go deeper with this how-to video.

Don’t Let Virtual Meetings Be the Scapegoat for Lack of Productivity

#45 – Time Differences Matter. Pay attention to time zone differences and schedule your meetings at times when everyone can be awake, present, and engaged.

#46 – Require Contributions on Conference Calls. When facilitating a conference call discussion pay close attention to be sure that everyone has a chance to contribute so you don’t overlook someone’s good idea.

#47 – Give Virtual Meetings Special Attention. Effective virtual meetings require special preparation. Pay careful attention to the focus, duration, and how you’ll get everyone involved.

#48 – Take Virtual to the Next Level. As you get beyond basic conference calls, more advanced virtual meeting facilitation techniques can help you take things to the next level. Think virtual whiteboarding, virtual brainstorming, and break out sessions.

Don’t Forget About Scope

#49 – Break Up Your Sessions. There is only so much information one team or one person can deal with at a given time. Keep your elicitation sessions focused and break them into logical parts. Deal with one part completely and then move on. You’ll get better input this way.

#50 – Capture Out-of-Scope Ideas. In elicitation, it’s likely that new ideas and problems will surface that are out of scope for the current project. Be prepared and have a way to handle these ideas. Some BAs use a parking lot. Others use an issues list. Others will follow-up with stakeholders directly to get new projects in the pipeline. Capturing out-of-scope ideas keeps the creative process flowing and helps keep the discussion on track.

#51 – “In Scope” Can Have Many Meanings. Remember that scope means different things to different people. Use different concepts of scope to drive scope discussions. A business sponsor might see scope as solving a particular problem. A technical stakeholder may see scope as providing a specific solution. A subject matter expert might see scope as their slice of the overall project. A project manager may see scope in terms of timeline and budget. As the BA, you’ll have your own view (and just like everyone else, you’ll be locked into thinking your view is right). Use the different definitions as context for different conversations.

#52 – Avoid Implied Promises. Asking questions and listening to answers can be perceived as agreeing to deliver a solution to the problem being discussed. Take care during elicitation to differentiate between the discovery process and the planning process. This will help you avoid unwittingly making false promises, which degrades your stakeholder’s trust in the requirements process and impacts how forthcoming they are on future projects.

#53 – Don’t Make Promises You Can’t Keep. Unless you are also the project manager, you have no business saying, “that should be easy” or “we can commit to that”. And if you are also the project manager, it’s a good idea to revisit your plan before making promises. Besides, making promises like these can shift the discussion away from discovery and into the implementation plan.

So there you have it! 53 tips you can use to improve your elicitation skills and discover all the requirements on your next project. Take any one tip and apply it on your next project to find requirements you didn’t even know you were missing.

One of the best ways to clarify scope is to start by analyzing the business process. Here’s a complete tutorial on business process analysis.

>>Get Your Free Checklist

Learn exactly what a sample requirements checklist looks like, with one sample from our Requirements Discovery Checklist Pack, which 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 download a free sample checklist

The project timeline is challenging, but you can just about make the deadline…

Then you realise all of your key stakeholders are away at a leadership conference for the next three weeks.

What’s a BA to do?

You know two of them quite well, and they agree to block out 20 minutes one day for a short phone call.  They explain that the vast majority of the stakeholders are keen on the project, and will make time to see you after the conference, but they explain that since this conference has been in the diary for 12 months, it just can’t be moved.  Nor can the stakeholders squeeze any more time for you during the conference, as the schedule is so packed.

As you walk back to your desk, you have that sinking feeling:  “What on earth can I do for the next three weeks?” After all, surely stakeholders are key to requirements elicitation, right?

Well – yes and no.  As BABOK reminds us, there are so many elicitation techniques, and whilst workshops and interviews are used extremely frequently, there are many others that we might choose to employ.  In this article, I will describe three elicitation techniques you can do without access to your stakeholders.  It’s unlikely that any technique will stand on its own, the key to good elicitation is using the right blend, but these three can be particularly useful when stakeholders time is scarce.

#1 – Domain Research / Competitor Analysis

When projects start, particularly when stakeholders are unavailable, it can be useful to ask the question “how do our competitors solve the problem we’re trying to address with this project”.    Depending on the domain, it can be useful to visit their websites,  stores or branches to get a sense of their products and processes.

• What have they done well, and not so well? What type of data seems noteworthy?
• What business rules do they seem to have employed?

The idea here is not to copy or re-use, but to get a sense of the likely requirement areas that might be relevant.

#2 – Document Analysis and Organisational Research

Large organisations often contain hidden information goldmines in the shape of process documents, previous requirements documents,  business architecture diagrams and so on.  It’s well worth asking what existing documents are available about the “as is” picture.

Often documents like this are left languishing on dusty shelves – so they might be out of date – but they can be a useful starting point.  As analysts, they help us to formulate the best questions to ask when our stakeholders become available again.  They might also help us to determine some of the existing process requirements which may need to be considered in any new or updated system.

#3 – Observation

On projects of all types,  it can be extremely powerful to simply go and observe end users or workers, and see how their processes and systems actually work. End-users are normally extremely knowledgeable, yet sadly sometimes they fall into the “high interest, low influence” stakeholder category – they certainly care about the target solution (as they will need to work with it), but the decisions are being made elsewhere (perhaps by the sponsor, subject matter experts, and other domain experts).

When this is the case it’s even more valuable to see how they work, understand their day-to-day pain, and understand how they perceive the problem. This should always be done with fore-warning and permission of their managers, and it’s vital to build rapport and explain why you’re there. As with the other techniques mentioned, observation can help us to gain a greater understanding of the problem which we can refine by using other techniques.

And Then Validate What You Learn With Key Stakeholders

These are just three elicitation techniques you can work through without engagement from your key stakeholders. There are certainly others.  These techniques can be useful when used alongside interviews or workshops.

One final point: the scenario I painted above was one involving temporary stakeholder absence, which is a challenge that we can work around.  If stakeholders are continually unavailable, this might suggest a deeper-rooted problem and may require a different type of intervention by the project team.  This might involve by gaining their buy-in (with the help of the sponsor), or maybe even delaying the project completely (if it isn’t essential to progress it now, and if availability will increase in a few weeks’ time).

In summary: stakeholder involvement is clearly crucial to elicitation, but there are other techniques that we can use too.  The key is to use the right blend at the right time.

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.

What if there were a handy list of questions we could ask in almost any requirements-related conversation to get more relevant information from our stakeholders?

That’s the topic of today’s article. You can think of this list as the questions to ask when you don’t have any specific questions to ask but know you should be asking questions.  (And you should almost always be asking questions.)

Questions to Ask At The Start of a New BA Assignment

What’s Been Done to Solve This Already?

Often we assume (or like to assume) that we’re brought in at the beginning of a project. But very often, that’s simply not the case and this false assumption leads to us irritating our stakeholders by rehashing what they feel is a finished discussion. And even if we’re at the beginning of the project, it’s likely our stakeholders have at least thought about the problem and have some pre-conceived ideas about the solution.

Use this question to figure out the current status of the project and, more importantly, get into your stakeholders’ current mindsets about the project. Simply asking the question also starts the trust-building process because you are indirectly communicating you are not going to bulldoze your way through the project.

What Do You Need (Most) From Me?

We can bring a lot of expectations to our roles – templates we think need filling out, specifications we’d like to create, and models we’d like to draw. But sometimes what our stakeholders need is different from what we want to provide them. And sometimes what they think they need and what they really need are very different.

The answer to this question gets you information about what they think they need so you can either start fulfilling their expectations directly or starting the process of resetting their expectations about what you’ll be doing as the business analyst.

As You Are Getting Into the Details

Can You Give Me an Example?

If you sense you are not getting the whole story, ask this question. Asking for an example or many examples to represent different requirements can help expand the conversation and ensure your requirements cover all the scenarios.

What Problem Are We Trying to Solve?

This question often must be asked multiple times to get to the real answer and it also must be asked with finesse so that it doesn’t generate conflict. Click here to find 10 ways to discover what the problem really is.

In my experience, most conflict and significant stakeholder project disagreements result from either a difference in business goals (which you’ll discover by getting to the root of the problem) or a terminology misunderstanding. And that’s the topic of our next question.

What Does That Mean?

Resolving misunderstandings in terminology is an area where a business analyst can demonstrate strong leadership skills. This question often leads a discussion where stakeholders share their different definitions, begin clarifying each other’s definitions, and offering up examples of negative cases to clarify the definition.  This type of discussion often leads to at least a few “aha” moments – for you and everyone else.

Ask questions about acronyms, confusing terms, and organization-specific phrases. And don’t overlook the obvious and generic terms like customer, order, or issue as often they have the most false assumptions surrounding their meaning. Since these terms seem so obvious, often no one has bothered to ask what they mean in a long, long time.

As You Are Closing a Discussion

Is There Anything We Didn’t Discuss?

Use this question and variations of it whenever you can – between agenda items, at the end of a meeting, and before finalizing a requirements specification. Once your stakeholders get into the habit of you asking them for their questions, they’ll get better at filling in gaps and providing more relevant information.

Is There Any Reason We Can’t Move Forward?

While the previous set of questions are more open-ended in nature, this question creates a sense of urgency that gets your stakeholders to commit to the next step. Used at the end of the meeting or when finalizing a deliverable, this question ensures that sign-off really means sign-off.

>>Get the Requirements Discovery Checklist Pack

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

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!

The clock strikes the top of the hour. The first attendee of three wanders in, checking their smartphone and quickly looking up to say hello. They obviously didn’t bring print outs of the documents you sent ahead of time. You are glad you brought back-up copies.

At three minutes past the hour, your two other attendees come into the room talking animatedly about the meeting they just left, in violent disagreement with the decisions that were made.

You have a big agenda and the meeting is already running late. You decide to get started.

You pass around printouts of your prep material. You open the meeting – explaining why you are here and what you hope to accomplish. One of the latecomers chimes in right away.

“Oh, we can’t talk about that now. In the meeting Bob and I just left we decided this project needed to go in a completely different direction. I think you’d better talk to Amy before continuing on with this meeting.”

If you could have a picture of your face at that moment, you wouldn’t want to see it. That’s an extreme example, but I’ve had it happen to me. Let’s go through a scenario that’s even more common.

Going Off Track a Minute at a Time

Everyone is settled in to the meeting about 5 minutes past the hour. You introduce the meeting topic, why you are here, the research you’ve done to get to this point, what you think about the project so far, and begin talking through your document. About 5 minutes in, you see Bob checking his smartphone. Jessica is reading ahead in the document you gave her. Emily looks bored.

You pause for a moment to get feedback on a particular part of the document. No one says a word. You move on.

Five minutes later, Bob looks up from his smartphone and starts whispering to Emily about an email he just got. You have a lot to cover so you keep talking through your points. Soon Bob and Emily are talking about how Bob should respond. They catch Jessica’s attention. She disagrees and pipes in with a different idea. You’ve officially lost control of the meeting.

What do you do?

I don’t have a silver bullet answer for you, but I do have a few practices that have helped me keep busy, distracted professionals engaged in my requirements meetings.  (In fact, someone once told me that one of my best traits as a business analyst is that I could make boring work fun. I found this interesting as I simply never thought of it as boring! But I digress.)

Engage People Where They Are At

If someone comes into the meeting talking, engage in the conversation. Ask a question and listen to the answer. See if you can’t make a connection between their topic and the discussion you are about to facilitate.

People don’t just switch their attention from one topic to another automatically. We can help create a shift of attention that gets our meeting on track early.

Ask a Question Early

When people are distracted or reading ahead, they aren’t listening to you. To continue talking is pretty much fruitless, even if it matches up with your vision of how the meeting should have gone. Stop talking and ask a question. Listen to the answer. Realize the answer could mean that you need to make mid-stream adjustments to your agenda or your elicitation plans.

The irony is that the more prepared you are for an elicitation session, the more intellectually able you are to reframe the meeting on the fly, but the more emotionally difficult it is to do so because you are attached to your plans. Be aware of these emotions and allow yourself to detach from the outcome of the meeting.

Address Side Conversations Head On

If a side conversation pops up in your meeting, stop until everyone can have one discussion. One of the easiest and non-confrontational ways I’ve handled this is to simply say,

“Bob and Emily, I realize something important has probably come up. I just want to make the best use of everyone’s time and ensure we’re having one conversation. Is what you are talking about something we can talk about as a group?”

If the answer is “yes”, then ask the group for input on the importance of the topic relative to the topic at hand. If the answer is “no” then ask Bob and Emily if they’d rather reschedule this meeting until they have had a chance to address their urgent issue.

Often this tactic reveals the issue wasn’t all that urgent in the first place and the side conversation is ended. This can seem like a risky move – after all your meeting could be derailed completely. But you are actually setting the stage so that your future meetings are less likely to run off track.

>>Get Your Free Checklist

A great way to keep your elicitation sessions on track is to have a list of relevant, engaging questions to ask. Discover exactly what a sample requirements checklist looks like, with one sample from our Requirements Discovery Checklist Pack, which 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 download a free sample checklist

Elicitation can be a tricky activity.  Often when needing to understand the requirements for a particular project, the temptation is to jump straight into facilitating a requirements workshop or holding stakeholder interviews.  The challenge, of course, is getting enough stakeholder time, and knowing which questions to ask with the limited time available.  Understandably, business stakeholders are often too busy running the business to attend meetings, workshops or interviews.

It’s important to come prepared with as much information as possible, and the technique of document analysis can be extremely useful.   It’s possible to use document analysis to gather information about the business domain and/or the problem being solved without taking up too much stakeholder time.

So what does document analysis mean? Well, in essence, it just means “finding out what relevant documentation the enterprise has, and reading/referring to it”.  This is something that you almost certainly do intuitively, but by consciously planning it you can expand the scope of documents you consider.  Here are some document types to look out for:

Forms: If you are examining a process that involves paper forms, ask to see a copy of the form.  This will tell you a lot about the process! It will help you to understand the data that’s collected, and it might even hint at the business rules that apply (e.g. you might find that the form states, “All applications over $3,000 must use a form XYZ2”.  You’d then know that something different happens in these circumstances).

Business Architecture diagrams:  These will often show who does what, where and which business services are in-source/out-sourced etc.  They can give you a macro-level view of your domain.

Process or procedure diagrams:  Often operational areas keep documented copies of their processes.  But beware: They might not be up-to-date, and people on the ground may well be doing something subtly different (so it’s always worth following up with interviews/observation).

User guides/help screens:  If you’re working with an existing system, user guides and help screens can help you to understand the “as is” screen-flows.  They might even hint at underlying process logic and business rules.

Previous requirements documents: Sometimes, you might strike gold and find that a previous BA has produced a full set of requirements for the system or process that you’re aiming to change.  If so, this will be an excellent reference point, but remember that not all requirements get implemented, so it’s worth checking whether anything was de-scoped.

Customer complaints: Sounds strange doesn’t it?  But customer complaints can often give you great insight into where processes have broken down.  If you’re working to fix or improve a process or system, it’s well worth finding out whether there are any related customer complaints.

Defect logs:  Sometimes, business users will keep logs of “pain points” and perceived  defects on systems that they work on.  Sometimes these will be on a central defect management system, but sometimes they’ll be kept informally on Excel logs or in paper files.  Ask for a copy. It’s very useful to understand which parts of the process or system are causing pain.

Product/service promotional material:  Often the marketing material for a product or service will give you an insight into how it works.  For example, if you are working on a project that involves making change to an Investment product, then the existing prospectus/brochure provide a whole range of useful information about the “as is” product.

Document analysis is a great way to quickly gain enough information to ensure you’re asking the right questions.  It can help you quickly get up to speed, and ensures that you’re using stakeholders’ time effectively.   A quick initial 5 minute phone call to ask, “Do you have any of these documents, and if so could you send them to me?” can really pay dividends.

Or perhaps you use the term with a well-read BA or with someone like me who happens to facilitate a course called “Essential Elicitation Skills” and they tell you “elicitation” is the better term. They might even jump down your throat and give you 20 reasons why we don’t use “gathering” anymore when it comes to requirements. (Well, not me, but those other people. I happen to be nice. :-))

But the thing is, we do use the term “requirements gathering.” It turns out we use it a lot more frequently than “elicitation”.

In this post, we’ll take a look at the difference between the terms “requirements gathering” and “elicitation,” analyze a few job postings that use each of the terms, and then I’ll provide my take on what this means for the BA job seeker.

The Dictionary Definitions

Let’s start by looking at the dictionary definitions of “gather” and “elicit”:

Gather:

To bring together: collect.

To reach a conclusion often intuitively from hints or through inferences

And under the synonyms section: “Gather is the most general term for bringing or coming together from a spread-out or scattered state. Collect often implies careful selection or orderly arrangement….”

(Source: http://dictionary.reference.com/browse/gather)

Elicit:

To draw forth or bring out (something latent or potential)

To call forth or draw out (as information or a response)

(Source: http://www.merriam-webster.com/dictionary/elicit)

Which Term is “Right?”

The common argument against the use of the term “requirements gathering” is that requirements don’t just sit around waiting to be picked up and collected together. They must be drawn out by a variety of techniques that get to the true problem to be solved, stakeholder need, and requirements.

I agree with this argument, though in reviewing the definitions there is an element of “gathering” that we do as business analysts. We do bring together information from disparate sources. Some information is sitting around ready to be collected. For example,

• information that is stored in documents (such as process models or regulations),
• systems (such as business rules or as-is functionality), and
• knowledgeable requirements-oriented stakeholders who have already drawn out their own needs and are ready to tell us exactly what they need and want (they are relatively rare, but they exist).

The information that can be gathered together is part of the picture and it’s often what we do before elicitation. In fact, I would argue that it’s part of the Preparing for Elicitation knowledge area in the BABOK.

But gathering is part of what we do, it is not all-encompassing. With all the possible information gathered together, we analyze it, and then go about figuring out what’s missing. That’s where the elicitation starts. That’s when we begin to draw out what’s latent in our stakeholder’s minds. We might invest in discovering the problem to be solved, ask a series of questions, or demo a user interface prototype.

What Do the Job Postings Say?

At this point I want to come back to why I am tackling this question in the first place. Despite whatever we might want the terminology to be, the job postings tell a completely different story.

As I pointed out in my recent TechWell post, instances of “requirements gathering” outnumber instances of “elicitation” as a job requirement by a factor of about 10 to 1. That’s right.

“Requirements gathering” is listed ten times more frequently than “elicitation.”

Let’s look at some sample job qualifications. (I make no guarantee that these are representative language, just postings with the job title of “Business Analyst” that were the most current on CareerBuilder.com at the time of this post being published.)

For “requirements gathering”:

This position will be responsible for translating business requirements into software requirements and specifications; defining and owning the research process and due diligence process; designing, organizing, and leading requirements gathering sessions with internal departments;

Create business process flows, manage changes and provide subject matter expertise for requirements gathering process.

Proven experience and passion for facilitating requirements gathering sessions, designing customer facing interfaces (navigation, look, and feel) for complex web applications and websites.

Gather requirements from business units and translate those to programmers and developers

And for “elicitation”:

Demonstrated experience in Requirements elicitation, setting up and tracking of verification and validation procedures

5+ years experience in requirements elicitation through the use of application design sessions, interviews, document analysis, requirements workshops, surveys, site visits, business process descriptions, use cases, scenarios, event lists, business analysis, competitive product analysis, task and workflow analysis, and/or viewpoints.

Participate in requirement elicitation efforts, including the elicitation and mapping of the AS-IS and TO-BE processes.

Select the appropriate methods to elicit and document requirements

What This Means for BA Job Seekers

While we still have a ways to go in selling the use of the term “elicitation,” that doesn’t mean that employers expect BAs to be “gatherers.” In each of the gathering posts there were additional elicitation techniques listed, such  “interviews” or “confer on business needs” or “evaluate” or “liaise” or a variety of other terms that mean elicitation.

Employers each have their own various ways of asking their business analysts to draw out what’s latent.

No matter what terms you use to talk about this part of the business analysis process, it’s important to realize that you will be responsible not just for picking up the requirements and putting them in a document. Employers do expect you to draw out the requirements using a variety of techniques and they will want to hear examples of how you’ve done this before.

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

The purpose of Document Elicitation Results is to:

Record the information provided by stakeholders for use in analysis.

The purpose of Confirm Elicitation Results is to:

Validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder needs.

Together these two tasks take up a mere 4 pages in the BABOK and they can be quite simple to execute on. Yet they are often overlooked even though they are critical to the success of any project.

Through these two tasks, we are essentially saying a big, “I heard you” (which happens to be a great way to get stakeholders to stop repeating themselves, just in case you have that issue). And, even if the project takes another direction, a stakeholder’s needs go unmet, or their problems are simply not as much worth solving as other bigger problems unearthed during elicitation, at least they know upfront that they had their say.

Most simply, documenting elicitation results takes the form of meeting notes, though it can also include recordings or other physical means of capturing what was discussed (such as a whiteboard, a picture of a whiteboard, or the renderings from a whiteboard session recreated using a modeling tool). Interestingly, in the BABOK, each elicitation technique is coupled with a suggestion as to how to document the results when using that activity. Sometimes reports are captured after the elicitation activity and sometimes, such as during brainstorming or a requirements workshop, the activity itself produces the results.

For example, many times throughout my career, I’ve captured a synopsis of the discussion on the whiteboard. In these cases, the whiteboard itself is the documentation of our conversation and, when captured via photograph, no other documentation is required.

Simultaneously, the whiteboard drawing has also served to confirm results. Confirming elicitation results involves sharing the results with those who participated in the activity to be sure you got it right. This is when the stakeholder feels, “I heard you” or, if you got something wrong, “I wasn’t heard,” Capturing the ideas discussed on a whiteboard documents confirm the elicitation results by giving everyone the chance to make corrections on-the-fly.

Regardless of the elicitation process used, if you are truly confirming elicitation results and not just publishing notes for the sake of checking off a task on your list, your stakeholders are empowered to provide feedback if you misheard what they told you and they need to provide clarification. And therein lies the power. Before we strut off analyzing, prioritizing, and coming up with solutions to requirements, it’s critical to confirm, “did I hear you right?” in the first place. Otherwise, everything else you do is built on the foundation of the wrong information.

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

Some elicitation will, by the nature of what it takes to be a BA, happens without a lot of premeditation. The big chunks of elicitation where we discover the majority of our business or solution requirements will benefit from some careful preparation. And that’s what we are going to consider in this post.

Preparing for elicitation involves clarifying the scope of the selected elicitation technique, gathering any supporting materials, and scheduling all the people and resources.

Prepare for Elicitation – Step 1 – Clarify Elicitation Scope

Before we begin elicitation, we either consciously or intuitively decide what we want to achieve through the activity.

In the best of words, the scope of a phase or session of elicitation is formally captured in a meeting agenda and communicated to all involved stakeholders. You might even create a detailed elicitation plan that includes a stakeholder analysis – identifying who will be involved and what their role is.

At a minimum, you’ll mentally prepare for a conversation before popping your head into someone’s office. (This might sound a bit tongue-in-cheek, and it is! But I also know that perfectionism is a big deal in the business analysis space, and I don’t want you to discount what you do to prepare, even if it’s not incredibly formal.)

Prepare for Elicitation – Step 2 – Gather Supporting Materials

Gathering supporting materials is equally significant. This could involve research into what documentation or artifacts already exist. Or, it could involve completing another task to create a deliverable, such as using requirements analysis to analyze the “as is” process as a starting point for an elicitation discussion.

On one project where I was working remotely as a BA for a very geographically-dispersed organization a wiki was in place as a primary means of sharing information and documentation. In this organization, “supporting materials” often meant creating a skeleton wiki page containing any known information about the project along with links to other supporting documents such as as is processes or wireframes. Stakeholders were sent links to the materials in advance of the meeting.

Another element of your supporting materials will be your requirements questionnaires. A requirements questionnaire is essentially the list of questions you have about the requirements related to the scope of the session.

(By the way, we offer a Requirements Discovery Checklist Pack which includes over  700 categorized and cross-referenced questions to drill into the details behind common business processes and features. Essentially you’ll have everything you need to create your requirements questionnaires.)

Prepare for Elicitation – Step 3 – Schedule Resources

Finally, there is the need to actually schedule the meeting. In a complex stakeholder environment, this is often easier said than done. You might reschedule the meeting multiple times to find a time that works for all the participants. At times when a suitable time cannot be found, I’ve restructured the meeting so I can meet with different parts of the group separately and accommodate various schedules. Scheduling resources also involves nailing down meeting logistics:  the conference room, conference call numbers, securing the projector, etc.

On my first BA project, we had two standing one hour meetings each week called “use case meetings” in which we performed a combination of elicitation and analysis. In this organization, getting a meeting on people’s calendars was a significant task. Having this regular time made scheduling (of both people and tangible resources – we had one projector for 4 BAs and it was often double-booked) easier and created a nice pace for the other aspects of the business analysis process.

Ignore Preparing for Elicitation At Your Own Risk

While at first blush, preparing for elicitation may seem insignificant, in my experience newer business analysts often underestimate the importance of this activity. Then they wonder why their elicitation sessions consistently go off track and they consistently miss deadlines.

When they learn to build in time to prepare for their elicitation sessions, their business analysis work starts flowing much more easily, and they gain significant credibility with their stakeholders as well.

Whether formal or informal, intuitive or structured, documented or undocumented, preparing for elicitation helps put your best foot forward as a BA and helps solidify stakeholder relationships by showing you value the time they spend with you while you are conducting elicitation.

>>Get Your Free Checklist

Looking to improve your elicitation? Discover exactly what a sample requirements checklist looks like, with one sample from our Requirements Discovery Checklist Pack, which 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 download a free sample checklist

Reader 1: As rules are mostly hardcoded and code walkthrough is too time consuming in mainframe systems, what is the best way to extract business rules from legacy systems without using the tools?

Reader 2: In most modern systems, business and processing logic/rules are defined in a separate Business Rule engine; but in Legacy systems it’s the other way as their logic and rules are hard coded or defined in the code itself. So how does a BA who is suppose to work on a legacy modernization project gather the requirements for these rules and logic as he can’t go and see the code and then understand?

Aaron’s reply:

These questions come quite timely as I have just completed a legacy modernization project for one client and have begun another one for a new client.  The one thing I believe is that there is no substitute for the code walkthrough.  The first reader doesn’t want to take the time to do a code walkthrough, but if you want absolute correct requirements, and business rules you must go through the code walkthrough.  Now, I am not saying it has to be a formal code walkthrough nor have several people involved.  The more people you have involved, the more correct your requirements and business rules are apt to be.  The fewer people you have involved to faster the process is likely to go.  I am not sure what tools Reader 1 is referring to, but I am not aware of any tool that can read legacy code and extract business rules; that will take a trained human being.

I actually suggest a two prong approach to legacy modernization projects; technical and functional.  The technical is the code review/walkthrough.  Have a Developer/Analyst, or a team, walkthrough the code and extract the business rules from the code.  The second prong, functional, is having a Business Analyst (BA) interview the business people who interact with system under investigation and extract the functional rules from them.  The business people who use the system every day know how the system acts.  They know the “quirky” things that the system does.  The BA should observe the business people interacting with the system, which could lead to more questions about the system.

The BA and Developer/Analyst can confirm with each other what they learn about the system.  As a Developer who has transitioned into a BA role, I performed both the functional and technical reviews of a legacy ERP system for a client, to draw out the business rules and functional requirements of the system, as the company was preparing to replace their ERP package.

While interviewing and observing the Order Entry business people of the company, I learned that during order entry they would type the word “USUAL” in the ship via on the order.  The system would see that, go to the Preferred Carrier table for that customer and retrieve the name of their preferred carrier and replace “USUAL” on the order with that carrier’s name.  The Order, Invoice, Bill of Lading and other documents would print with the actual carrier’s name.  Being the technical person on the project, I was able to confirm this during the code review, and see exactly how the system went about accomplishing that task.  If I were not the technical person on the project, I would compare business rules with the Developer/Analyst and see if he/she found the “ship via replacement” rule of the Order Entry system.  If it was not listed in their rules, I would ask them to confirm the rule as I received it from the Order Entry business people.

So you have two take-aways from this:

1) Like it or not, there is no substitute for a code walkthrough/review to help ensure you get the business rules correct.

2) Take a two prong approach to legacy modernization projects; technical and functional.

>> Learn to Ask the Right Questions

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

Then the reality hit. Another week, another chapter, another simulated exam. Although the material is new, there is a certain monotony in preparing for an exam. At first, you are trying different study techniques, experimenting with new ways of absorbing information, and exploring new tools. Around every corner surfaces something new and unexpected. Then you land on what seems to be the best way for yourself to study the material, and you become acclimated to the discovery process. And there’s nothing left to sludge on through, using the process you’ve discovered, again and again and again. It’s more like getting on one of those little kid trains that goes a few feet up and down than the Gemini, the Blue Streak, or the Millenium Force. (Yes, I live in Denver, but I grew up near Detroit where boat trips to Cedar Point were yearly occurrences. I remember approaching Cedar Point from a mile or more away and seeing the initial climb of the Millenium Force rising into the air and thinking, “tomorrow I’ll be up there.” But again, I digress. CBAP. CBAP.)

This is where you find me now. Diligently moving forward. Occasionally putting off studying. Doing what needs to be done. The excitement is gone. The passion for the process was really never there so there is nothing to rekindle. But I might be being a bit dramatic here. There have been a few moments of excitement along this otherwise now routine path. A few blips that keep my interest piqued and my intellectual faculties engaged. Most of them have come from interactions with my CBAP study group. And, again, they revolve around this core idea of discovering how what I do is similar or different to what “the BAs of the world” do.

Elicitation results vs. Documenting the Results of Elicitation

This is one of those things you read in the BABOK and makes sense, but then when someone else explains it to you, it becomes more puzzling. The Elicitation knowledge area of the BABOK is split into 4 tasks:

• Prepare for Elicitation,
• Conduct Elicitation Activity,
• Document Elicitation Results, and
• Confirm Elicitation Results.

The output of Conduct Elicitation Activity is “Elicitation Results,” which is an input to the next task, Document Elicitation Results. But in a pattern that emerges throughout the BABOK, the output does not have a prescribed form. Often it’s safe to assume it’s some sort of document and storage of information, even if in the real world that information is captured in a deliverable with outputs from one or more other tasks. But the Documenting Elicitation Results task clearly indicates that meeting notes, meeting recordings, or even picture recordings of a whiteboard fall within its domain. So what exactly is this output from the earlier task? It seems that the Elicitation Results are things that hang in the ether somewhere.

I raised this question in the CBAP prep class I’m taking and was glad to learn that I wasn’t alone at being a little puzzled. Through the chat box, several participants shared possible examples and we had a bit of interaction about the possibilities. I ended up deciding to keep things straight in my mind by thinking of “Elicitation Results” as raw notes, perhaps even those transcribed by hand during the meeting, and the outputs of Document Elicitation Results, which are Stated Requirements and Stated Stakeholder Concerns, as organized notes ready for analysis.

Of course, in the real world, I blend all of this together for expediency and because I can often quickly move to analysis. But I get the separation and think I have the concepts straight enough to answer questions correctly on the exam.

What is a focus group anyway?

It’s always surprised me that focus groups are a technique in the BABOK as I think of them as a marketing activity. And as we talked through Focus Groups in class my perception didn’t shift. Then someone from class asked a question about the difference between Focus Groups and what she has called Breakout Sessions. After the instructor summarized the technique, the student added a bit more context about her Breakout Sessions and how she used them to better understand a problem and stakeholder perceptions of a problem. It seemed that she was probably facilitating Focus Groups in a very different way than I had thought of them before. This line of thinking opened up the possibility that I, too, had used the technique. While the broader definition I now understand isn’t likely to help me with the exam, it does expand my view of my own experience and help me think about the separation between Focus Groups and Requirements Workshops, which might help me plan a few meetings better in the future.

Discovering my primary elicitation practice is 1/3 interview, 2/3 requirements workshop

I made a lot of assumptions about the techniques in the BABOK. It’s funny what you learn when you actually take the time to read the text carefully. I had always assumed a Requirements Workshop was the kind described by Ellen Gottesdiener in Requirements by Collaboration – a full day meeting in which participants collaborate together on requirements deliverables. After reading the BABOK‘s description of the technique, I discovered while the time frame of 1-2 days is referenced, the creation of deliverables is not. In the general way the technique is described, it could include collaborative creation of deliverables. But it could also include group dialog, around a set of requirements, which are captured by a scribe, and then put together after-the-fact by a BA. And this is the type of meeting I typically run. Still, since the BABOK specifically says these meetings typically last 1-2 days and mine typically last 1-2 hours, I say I’m about 2/3 there. And the other 1/3 is captured by the Interview technique which can include interviews of more than one person together.

Interesting?

Where am I going with all of this?

I’ve been reticent to offer advice to other potential CBAPs along this journey, since I know not yet whether my process is going to work and do not have the real experience (i.e. taking the exam) to enable me to reflect on what aspects of my preparation were most useful and why. But one thing that’s emerged so far is that finding a group of BAs to share the experience with might be the most important thing I did in terms of keeping my energy up.

This doesn’t have to be a prep class. It can be a study group or just one other BA to share experiences with. But you have to step through the BABOK with them, share experiences, share frustrations, work out details, and use dialog to absorb the material. I think this group picks you up when you get down (or bored) and reigns you in when you get lost. I’m really glad our instructor treads the fine balance between interaction and focus, allowing us some discussion about the material, and how it relates to the real-world, to ensure we actually get it and then refocusing us back to the BABOK and what we need to understand for the exam. Because sometimes all I need to hear is, “yes, that’s a good point, but let’s be sure we understand what the BABOK is telling us.” This sort of subtle redirection that keeps the energy I have focused on the preparation that will help me be exam-ready.

How about you? Has being part of a group helped you prepare for the CBAP exam?

In a sense, without the right stakeholders involved, you “don’t know what you don’t know.”

So how do you ensure you have the right stakeholders involved? Through stakeholder analysis.

By the way, if you want to learn my top tips to getting stakeholders more actively involved on projects, Click Here to Download a Free Guide – 10 Tips to Improving Stakeholder Engagement.

Stakeholder Analysis Step 1: The Stakeholder Matrix

Stakeholder analysis is the process of identifying stakeholders to be involved in your project and identifying their specific responsibilities.

The first place to start is with a simple stakeholder list. with the following information:

• Stakeholder Name
• Stakeholder Job Title
• Stakeholder Role on Project

A simple Stakeholder Matrix is included in the Requirements Plan Template that you receive when you purchase the Business Analyst Template Toolkit.

You can also choose to capture additional information such as:

• Contact Details (email, phone, IM, etc)
• Availability
• Preferred Communication Method

This simple stakeholder matrix gives you a sense of who is involved in the project and what their role is.

Stakeholder Analysis Step 2: The RACI Matrix

The next step is to determine what stakeholders will actually be involved in what aspects of the business analysis plan. To complete this step, you need to be a bit further along in your business analysis process. This is often completed once the business objectives and scope have been defined, and you are developing your plan of approach to the project.

Your goal here is to define, for each specific requirements deliverable, who will be involved in supporting the development of that deliverable and what their role will be.

The most common way to do this is to create what’s called a RACI matrix. RACI captures who is Responsible, Accountable, Consulted, and Informed about each area of a project.

For example, for a project with 10 use cases, I might have 3 use cases related to customer support functions and 7 use cases related to front-end website features. In this scenario, the primary stakeholder from the Customer Service team may be consulted on or informed of the front-end website features, but accountable for approving requirements on the 3 customer support function use cases.

It’s in creating the RACI matrix that you’ll often find gaps. If no one is accountable for a specific requirements document, then you have a stakeholder gap! You also want to always be asking each stakeholder who is the approver if they will have all the information to make a final decision on a requirements deliverable. If not, ask who else needs to be involved and add that person to your stakeholder list.

Stakeholder Analysis Step 3: Leverage the Results of Your Stakeholder Analysis

Stakeholder analysis is not a deliverable that’s created and then shelved. It’s a collection of living documents that get added to over time. They can also be used throughout the project to help you improve your communication and stakeholder engagement practices.

Because it’s one thing to analyze the stakeholders and figure out who they are, it’s another to actually engage them successfully on a project.

All the work you do in stakeholder analysis is really designed to help you be more effective with your engagement.

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.

>>How to Learn the Foundational Business Analyst Skills

When you join The Business Analyst Blueprint® certification program, you’ll gain real world experience in the industry-standard techniques and business analysis processes.

>> Click here for more information about The Blueprint <<

Faced with the unknown parameters of your project’s “Business Domain” you might check the Organization Chart, but you’re not sure who to dub with the Stakeholder title.  Annual Objectives Statements provide some clue to motivators, but not really an understanding of organizational alliances and conflicts.  What’s needed is something that reveals more than reporting hierarchy and goals.

Identifying all the right stakeholders

Enterprise Analysis has provided the answer for me.   By this I mean building Domain Models – simple relational diagrams, focused on understanding  the ways in which elements of the business connect to each other, What and Why rather than How. I’ve used Domain Models to ferret out missing Stakeholders in a number of ways:

• A new spin on the organizational hierarchy– we expanded the org chart to visualize the invisible organizational lines and informal matrix reporting structures.
• A process decomposition – we grouped activities into their common process objectives to determine contradictions to the organizational structure.
• A goal decomposition– we categorized the hierarchy of business objectives and metrics that the organization used to measure success,  how they align with the project goals, and who was accountable.
• A context diagram – we created a wheel of Stakeholders with the new system as the central hub, labeling directional lines to indicate sources and destinations of different information, treating the system as a black box so as not to get tangled in functionality discussions.
• A stakeholder relationships diagram – we brainstormed stakeholders, labeling directional lines with the expectations key players have of each other, and then filtered out the irrelevant by removing those not impacted by project deliverables.
• A process interaction diagram – this time instead of Stakeholders we took the core processes (top level of a process decomposition) and looked at how they feed each other to determine if there were other impacts to consider.
• A business interaction diagram – we took the stakeholder relationships diagram one step further by slotting the roles and organizations into categories of supplier, customer, competitor, and process participants, allowing us to pinpoint resource inter-dependencies and competing interests that could cause issues for the project if not dealt with.
• A business object model – we identified the components and types of products included in the project scope to study the context of information needs.

The Business Areas that are your sources of domain information may give you some resistance initially, but going through this process of discovering relationships can be cathartic for your business counterparts, increasing their awareness of throughputs and influencing factors.  Documenting this sort of information helps the business areas to visualize what’s really going on, and organize a change plan where needed.

Anticipating the positive impact new stakeholders will have on your projects

To put the results in a project context consider these examples from my project history book where the representation expanded to include new stakeholder perspectives:

• Added key internal Customers and every IT department impacted by a planned Help Desk application with automated ticket routing & tracking.
• Included Underwriters that would be trying to sell the Managed Care partnership being evaluated by the Claims group.
• Added Facilities Management to a planned implementation of a Claim handling workflow and imaging system that had huge impacts on the mailroom, the de facto scanning center.
• Brought Data Warehouse participation into systems design sessions that were repeatedly identifying the warehouse as the best solution option for managing financial, regulatory and customer reporting.
• Internal Audit was added to a migration project and wound up taking responsibility for the process QA due to the complexity of properly mapping financial transactions to Insurance, SEC, Actuarial rules.

Think about being able to suggest to your Project Manager additional participants who will make decision-making easier, or identifying administrators of downstream systems that will become part of the test team.  This recent Project Times article on Detecting Stakeholder Misalignment describes the impact to Project Managers when Stakeholders are overlooked, and by proxy, the  impact to the Sponsors of the project.  By identifying potential conflicts early in the project you’ve saved them both from greater, potentially project-killing battles down the road.  All it takes is the brave Business Analyst standing up and saying so.  Your models could generate what the article calls a “stakeholder consensus audit”, a diplomatic disclosure of conflicting ideals.   The rewards include the Holy Grail – Informed Stakeholders.

Knowing the relationships can improve your own relationships

Through Enterprise Analysis you learn about the things that are important to your project’s Stakeholders and how your project will have an impact. By taking this broader view of business value you also gather some key pieces of information:

• expectations of Stakeholders and the risks of not meeting them;
• triggers that launch activity;
• deliverables between process participants;
• inter-dependencies like supply chain, competition for resources, regulatory constraints;
• work product destinations and Customer demands.

All of this information helps you – the wise new BA on the project – to elucidate the business need and start formulating solutions.  You are alert to project issues, know who you’re dealing with, what they’ll expect and more importantly, what they’ll find issue with.  Others will start to recognize that you are able to take on this type of senior level responsibilities.

Creating success by revealing relationships

Never looking beyond the obvious direct impacts can leave a dangerous gap in your project team’s sources of information and makers of decisions.  An important contribution from the project’s BA is to examine organizational, information, process, and customer/supplier relationships. By understanding your Client’s value chain the solutions to their business problems become more apparent.  Including upstream and downstream Stakeholders enables your Project Manager and Sponsor to take the next important step: ensuring that everyone understands and supports the project objectives.  The more you know about the business domain the more your Client will relax and be confident that you “get it”.

>> Learn the Business Analysis Process

An essential element of succeeding in a business analyst job role is understanding the business analysis process. We walk you through an 8-step business analysis process in the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.

Click here to learn more about the BA Essentials Master Class

It is important to ask the right questions early on. This encourages our stakeholders to approach the problem-space in a thoughtful and creative way hopefully working around any presuppositions, prejudices and assumptions. Asking a balance of logical and also deliberately provocative questions can help us to get a better understanding of our stakeholders’ worldviews, and help us to understand what they value as well as ideas or requirements.

Provocative questions are those that encourage a stakeholder to think creatively and laterally.  They help to uncover any perceived constraints, and can help to evaluate whether those perceived constraints are real or imaginary.  They can help to confirm or uncover the business driver behind a project/requirement, and they promote a level of creative thinking which might not be obtained through purely straight forward questioning.

Thesequestions help to challenge our stakeholder’s preconceptions, and ensure that we understand the business driver behind the project/requirement.  By explicitly externalising these ideas and constraints early in a project’s lifecycle, it is also an opportunity to spot any conflicts or areas of disconnect between stakeholder groups.  This also provides the opportunity to debate and gain consensus on the objective of the project, before moving into discussions over potential solution options.

Here are some examples of some provocative questions you might find useful:

1.  “If there were no constraints (budget/time), what would your ideal solution/outcome look like?”: This is often seen as a dangerous question, as it opens up scope. It certainly needs to be used alongside clear expectation management, however it can get us closer to the real business problem or opportunity that is being addressed by the project.

2. “What is the worst possible project outcome from your perspective, and why?” : This might sound like an abrasive and counter-intuitive question, so it’s essential that you are sure you have built good rapport with a stakeholder before using it. This question is valuable as it helps to elicit values, constraints and tolerances.  For example, if the worst possible outcome is “Late delivery, because the regulator will shut us down”, then you know that time is the key constraint.

3. “Imagine nothing changes. What would happen, and where would the organisation be in 12 months time?”: This question helps to understand the relative urgency of the project, and is also likely to uncover any environmental factors.  It also helps to confirm the business drivers for the project.

4. “If you had to articulate the project objectives in a single short sentence, what would it be. And how will these objectives help the project to deliver financial benefit?”: It can be enlightening to ask stakeholders to succinctly state the purpose of a project, stating how this is of financial benefit.  Often, different stakeholders have subtly different worldviews, and therefore perceive projects differently. For example, an operational stakeholder may focus on efficiencies, a marketing stakeholder may focus on increased revenue. Even when a business case has been drafted, stakeholders tend to have slightly different views on what benefits will be realised (and how they will be realised). This is extremely useful to know, as it will uncover any areas of disconnect early so that they can be resolved.

5. “Imagine if we fast-forward to 2 years after the implementation of this project, what will the organisation look like?”: This question helps gain an understanding of the future state of the organisation, and what it means for the people and processes that run it.  It can be used to get a sense for the size of the change that is envisaged.  For example, does it involve significant organisational restructure? Or is this out of scope?

6. “How do our competitors handle this? Do we want to be the same, or different from them?”: Often, business stakeholders will look to see how a competitor has solved a particular problem, and will initiate a project to replicate this.  In some circumstances, this will be a completely valid approach.  However, a better solution might be to differentiate from competitors, and solve the problem in a new way that increases value to customers.

8. “Is there any other way your business objectives could be met? If not, can you explain why this is the case?”: It is extremely useful to know whether delivering a particular project is genuinely the only way to address the business problem/opportunity that has been identified.  There might be others, and it’s useful to know whether they have been ruled out.  Other options might include:

• Process (rather than IT) changes
• Organisational changes
• Outsourcing work
• Manual workarounds

In summary, using provocative questions is a great way to encourage lateral thinking amongst your project stakeholders.  This will help to surface ideas, values, issues and perceived constraints.  Once these thoughts have been explicitly surfaced, they can be discussed and re-evaluated.

Encouraging lateral thinking helps to uncover imaginary constraints, and helps us challenge the business objectives to ensure they are sound.  I hope that the questions above help you engage with your stakeholders and understand what their projects mean for them.

>> Learn to Ask More Questions

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

Here is how the walkthrough works.

• Each of the departments will work independently, as they will in the new process.
• The project manager puts together a customer package of a closed project – this is the full construction package that gives us the details we need to do our jobs as we walk this through the process.  (This would include maps, drawings, requirements, customer information, approval documents).
• We also have the new process maps, the documentation and an idea of how we want the tools to perform.  This is difficult at this stage as the new systems do not have requirements yet and everyone is wondering what they will look like.

The first team starts out with the customer and gathers information.  As we all wait for the order to arrive in our work queue, we realize how much time is actually spent with the customer – gathering information, using tools to detail maps.  We have a conference bridge set up – and we hear ‘ customer group calling design’ and design answering.

The business analysts are looking for gaps in the process.

• What has stopped the workflow?
• Can we move it again?
• What system trigger do we need?
• Do we need the CRM system to tell us that all customer information is complete and the quote can be created?

Once the status changes to quote accepted by the customer, then the next team is engaged.  They receive their detailed package from the Customer group but once they examine it they are missing key maps of the customer site.  At this point, the run through grinds to a halt and phone conversations start and questions are recorded by the BAs.  This gap is highlighted and logged and the team moves the process on to the next team.

Conversations ebb and flow on the conference bridge.   We find that it is very easy to slip back into current process as the pressure to deliver your piece increases.  Some team members realize that the process is now in current state and try to bring everyone into the future state but it is difficult.  There are a lot of variables and no systems to work with.

The entire day works like this.  We start and stop as gaps are identified.  What really works is having the business owners discuss their handoff process between each other.  They discuss and negotiate to determine what they both need to see.  This becomes the most valuable part of the entire exercise – and what proves to bring the teams together to start understanding each other’s process and have a vested interest in the entire process.  At the end we gather together and talk about the day and what went well and what could be done better. You can feel the positive energy in the room and the beginnings of understanding.

The gaps include the lack of systems, the lack of documents and information to work with, and staying in the future state.  The most successful part of the walk through is the conversations started with each business owner as they look at the hand off documents to the next team and realize the impact they have on each other.  Do their inputs and outputs flow and match?  What would be more effective?  The greatest value is seeing the teams working together and reasoning out how the new process would and should work.  Those conversations are the gems from the day.

>>Learn About Other Requirements Validation Techniques

There are many ways to validate requirements. Read these articles for some variations:

• How to Conduct a Requirements Review
• Have You Experienced Your Customer’s Perspective on Your Business Process?
• How to Get Meaningful Sign-Off on Requirements Without a Walk-Through

“How do people go about collecting report requirements from clients and trying their best to reduce overheads whilst still fulfilling the data needs? I know there has been a big drive recently for Green IT and how companies can reduce their carbon footprint, is this a tactic that should be used?

In addition, how are the report lists maintained and captured – do people have a report book template they can provide. I suppose the best way forward is to persuade clients to consolidate and condense their reports, which will reduce complexity.”

Aaron’s reply:

Remember that the Business Analyst (BA) gathers and documents requirements then makes recommendations.  The Stakeholder, or client, is the decision maker.  So “Green IT…is this a tactic that should be used?” That is for the client to decide, based on their business needs.

You ask a multitude of questions within your question, you asked about reduce overhead cost, fulfilling data needs, Green IT, carbon footprint and report lists. You are asking the right questions and considering more than just report contents.  Every good BA will consider all the necessary components and gather requirements from the stakeholders about all the components, not just the contents of the report.

Report Contents

The data fields contained in the report and how it is formatted is where the stakeholders will want to spend their time.  They usually have a good idea of how they want the report to look.  However, stakeholders may not be aware of technology capabilities that can highlight certain data on the report by changing color, bold, or changing the font or size of the text.  The BA should be aware of these capabilities and elicit the requirements around highlighting certain data on the report.

Report Format

Along with content of the information contained in the report, in what format should it be delivered?  Paper reports are no longer the only option.  Some recipients may wish to reformat or resort the data once the report is delivered; Excel spreadsheet makes a good format for these recipients.  When this is not necessary, yet you wish to go Green, PDF format may be a good option.

Underlying Infrastructure

Consider the infrastructure in place when making recommendations on changing the reporting system of the organization.  Making a recommendation that completely changes the infrastructure, or that the current infrastructure can not support usually will meet with great opposition.  Is the client running a Windows or Linux network, IBM midrange or mainframe system?

Report Delivery System

The days of the large data center with 10 printers that look like washing machines that print reports all day and then someone walks throughout the office delivering paper reports are coming to an end.  You may be able to find this still today in very large organizations, but just like the floppy disc, this too will some day be a thing of the past.

Organizations that wish to reduce their paper usage can consider having reports delivered to shared folders on the company’s network or through the company’s email system.  Both PDF and Excel reports can be delivered either way.

You can further reduce costs by having the application that creates the report deliver it to its final destination in the format desired.  Most systems have tools built within them that assist in accomplishing this task.  There is usually third-party software available that can do this when the system lacks the tools itself to get the job done.

Security

Some reports may have sensitive or proprietary information, such as financial or executive reports, that you will want to limit the access to these reports.  Reports delivered via the company’s email system are delivered to individuals or distribution lists; so you control who gets these reports.  The downside of this method is that if the report was delivered to 10 recipients you now have 10 copies of a sensitive report out there.

Windows network folders can have limited access rights assigned to them.  So setting up folders and assigning limited access rights to them then having reports delivered directly to those folders solves many issues related to delivering reports for the organization.

Report List

Organizations have spent a lot of money trying to maintain report lists.  Keeping it current with additions, removals and delivery instruction changes can be a daunting task.  Sometimes when an application is used to deliver reports, necessary information can be extracted from the setup to create a report list.  If the reports are delivered to Windows network folders, open the folder…there is your list.  Reducing the resources necessary to maintain the report list is another way to save your client money.  So capture it from an application setup or from the network folders to automatically create the list.  Also, if a list is not required, don’t spend the resources to maintain one.

So when working on an enterprise reporting system, remember there is more to consider than how the report looks.

>> Learn What Questions to Ask When Creating a New Report

“Create Report” is one of the 18 requirements checklists in the  Requirements Discovery Checklist Pack, which includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence. I

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.

According to the BABOK stakeholder concerns

represent the business analyst’s understanding of issues identified by the stakeholder, risk, assumptions, constraints, and other relevant information that may be used in business analysis.

Stakeholder concerns are an output of elicitation and can be used in confirming elicitation results, defining assumptions and constraints, assessing organizational readiness, and defining the business case. I would agree, stakeholder concerns are important and something that many senior BAs probably deal with intuitively.

My guess is that most of us probably jump right to documenting risks, assumptions, constraints, etc without documenting the concerns outright. In one informal environment I worked in, where we used a wiki to capture requirements, I began to capture the stakeholder concerns as context for the requirements.

Let me give you an example that has come up recently. As I was chatting with the stakeholder about some new requirements related to search engine optimization, the concern came up that some of the current pages are very well optimized for our target terms. The stakeholder made the point that we didn’t want to fix what wasn’t broken as it might actually hurt us more than help us. This concern resulted in an additional requirement or two.

I knew that when I reviewed this with the developers, they’d push back on this complexity and so I wanted to capture the rationale behind it and also ensure they had this concern in the back of their mind as they were designing the solution. I would suppose in this example, the stakeholder concern became part of the business case as well as a potential risk for the project.

In this example, we have a full wiki page of requirements broken up into sub-sections that organize requirements by feature. When documenting requirements in this way, I often write a one or two sentence intro describing the feature. In this case, I captured the relevant stakeholder concerns in this introductory sentence.

I’m liking this approach because the concerns are relevant in the context of a specific set of requirements. It also ensures that the concerns aren’t overlooked. Without formal project management, we’re not really doing formal risk management or some of the other practices that might elevate risks. Documenting this sort of information in the requirements increases the chances the concern will be seen by the right person. Some stakeholder concerns are really notes to me as the business analyst to follow-up on. Others are relevant to those designing and implementing the requirements. Some, of course, are both.

The risk in this approach is that their is opportunity for ambiguity. What exactly is a developer supposed to do with a stakeholder concern? Does this mean a requirement is missing? Ideally, I’d hope the concern initiates a conversation if the risk proves to be a reality (or a strong likelihood).

Still having the concern documented within the requirements is better than it being buried in meeting notes or in a risk list that isn’t likely to be used given our current practice. At least it’s there for all to see and act on.

>>Learn How to Ask the Right Questions

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

Among the many competencies that business analysts need to develop in order to advance their careers, the ability to manage ambiguity is undoubtedly a critical one. The rapid changes that happen internally and externally to organizations require business analysts to become comfortable acting in an environment in which uncertainty and change are constants, and timely decisions need to be made even when not all the variables are known.

How can a BA improve his/her performance dealing with uncertainty and unpredictability? This is a competency most likely to be developed through informal practices. A good start is to acknowledge that managing ambiguity well typically requires two approaches: working to reduce ambiguity and finding ways to become productive even when uncertainty is unavoidable.

By the nature of their activities BAs plays a crucial role reducing project ambiguity. Typical business analysis tasks, such as clarifying project scope, defining and communicating requirements, and making sure that each business term used is clearly defined in a project glossary, significantly contributes to reducing ambiguity in a project.

In addition to reducing uncertainty in their projects, business analysts are also instrumental in helping the team remain productive amid ambiguity. Examples of steps that a BA can take to achieve this objective include:

• Assisting the project manager in establishing ground rules, roles and mechanisms to foster productive discussions and interpretations of business needs and solutions;
• Prioritizing and organizing issues to reduce the distraction caused by too many unknown factors;
• Making an effort to establish a common understanding of project goals among different stakeholders so conflict is replaced by cooperation.

Finally, BAs can also become more skilled at managing ambiguity by accepting criticism as learning. Leaders who manage ambiguity well understand that they will make mistakes and adopt the attitude that failure only happens if they choose not to learn from the experience. By being open to making mistakes (which are bound to happen in situations that aren’t black and white), and choosing to interpret the criticism as learning, a business analyst can become significant better at managing ambiguity over time.

This post from the website Better Projects talks about how Google is not afraid to fail, and what BAs can learn from the company:

We BAs could learn a lot from that kind of mentality about failure. No requirements document will be perfect on its first (or often even fifth) version. No screen mockup can encompass all the needed functionality and interaction. No use case can cover all possible directions that a user may go. Yet despite knowing the limitations, we should not just toss up our hands when we don’t get it right on the first try. We learn what our customers really need and next time, we get it right. We look for that elusive ‘killer app’ that will win approval from our customers so we have it ready for them, exactly when they need it the most.

This is certainly a good mindset for BAs to adopt while working under highly ambiguous circumstances.

>> Learn How to Ask the Right Questions

Interested in receiving a comprehensive set of questions you can ask in almost any project context to reduce ambiguity on your project? 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

As I’ve read about in a wonderful book called, The Introverted Leader, you can support your confidence in uncomfortable situations through preparation, presence, push, and practice. (This works even if you are an introvert like me.) Let’s look how to apply each of these practices to elicitation.

Step 1: Prepare to Elicit Requirements

The more you prepare, the more confident you’ll be. To prepare for an elicitation session, conduct as much research as you can to inform yourself about the problem and the existing situation.

• Talk to the sympathetic people first. This might be the person that hired you or your designated go-to person in the department.
• Learn the business and explore the system. Obtain as much insight as you can into how the business operates and the system works using the available information and tools.
• Start a list of key terms. If a glossary exists, use it as a reference to find the definitions of terms. Often you will find additional or alternate terms that are not included in even the most up-to-date glossary. Keeping terms straight can help you carve a more efficient path to real understanding.
• Start a list of questions about the system, about the process, the people, and about the project at hand. Think why, what, how, when, who.  Keep this question list handy as you meet with people about the project and use it to guide your discussions.
• If system documentation is non-existent, create models as you learn about the business and the system.

Yet, the nature of an elicitation session means that you will encounter unexpected information. That’s why step 2 – being present – is so important as well.

Step 2: Be Present in your Requirements Elicitation Sessions

Presence relates to how you handle yourself with others. If you are prepared, you should be confident and 100% present in your initial discussions. To create presence in an elicitation session:

• Use your list of questions and agenda items as a guide, but go with the flow. Once your stakeholders start talking, let them speak through their thoughts. While later in the process you make need to practice guiding conversations and even interrupting, your initial meetings should follow the energy of the stakeholders.
• Focus on seeking to understand stakeholder perspectives. Avoid second-guessing the questions you have or what you do or do not know. Keep it top of mind that this is your opportunity to learn more about the project and the stakeholders’ opportunity to unfold their perspective.
• Be an active listener — summarize what you hear and ask intelligent follow-up questions. But don’t be so worried about your next question that you forget to listen!
• Be OK with momentary pauses. Collect your thoughts, review your questions, and continue the conversation.

Steps 1 and 2 will get you started with confidence. Steps 3 and 4 will expand your skills in requirements elicitation.

Step 3: Push Yourself to Become Better at Requirements Elicitation

By pushing yourself outside of your comfort zone, you advance your capabilities and your leadership. You stretch yourself and improve your capabilities.

Some ways to push during elicitation include:

• Find gaps in your understanding and find ways to fill them. This might require involving an additional stakeholder or asking for a demo or observation.
• Seeking out the perspectives of higher level stakeholders. Drop by an executive’s office or take advantage of a chance meeting in the hallway and ask for what they value the most in the project.
• Use a new elicitation technique as part of elicitation. Learn a new way of modeling or a new tool and incorporate that into your elicitation activities.

Step 4: Practice Eliciting Requirements

As an analyst you want to grow into a professional who loses that initial feeling of fear when a new situation presents itself and become comfortable with the unknown. This happens through practice.

Practice is about repeating behaviors, even if they feel uncomfortable at first, until they become part of who you are. Through practice, elicitation will become almost second nature and you’ll be well prepared to handle a wide variety of new and unexpected situations.

Some ways to practice elicitation include:

• Practice asking your questions and listening to the answers with a friend or trusted colleague. You can practice elicitation techniques as a meeting attendee or in a 1-1 conversation.
• Anticipate the types of feedback you might receive and practice responses.
• Keep the momentum going by scheduling elicitation sessions. After every meeting, define the next step and make it happen.

With consistent practice, you will be able to spend less time preparing and more time being present in your elicitation activities. As your confidence grows, you will be able to handle more ambiguity in the initial phases and more dissonance among your stakeholders — i.e. more challenging projects.

Your Reward: Confidence!

By preparing, being present, pushing yourself, and practicing, that uncomfortable feeling will be replaced with excitement and confidence. As has been reinforced for me by Jennifer Kahnweiler’s The Introverted Leader: Building Your Quiet Strength, becoming a better leader is about continuing to invest in your own personal and professional development, increasing self-awareness, building on your strengths, and choosing new challenges.

To pull such a document together, start by listing out all the requests you’ve received. The requests may have come from a document, an interview, forwarded emails, ticket tracking systems, or from an early elicitation session. I like to use a spreadsheet or a chart in a word processing document. This is important because you will be adding columns to further categorize the requests later. Evaluate each request. Is it a business need? A requirement? Is it detailed or high level?

Then begin to look at the requests as a whole. Are there any that relate to each other? If so, how? Are there overlapping requests that could be combined? As you move through this process, you might find you want to group some requests together. You can do this by establishing a requirements hierarchy (one requirement is a subset of the other) or by adding a column to your list to capture a “category”.

Next you want to try to make this list a useful decision-making document. Your stakeholder team will need to decide which items are in scope for the project or release and which are not. (This is step 3 of the business analysis process.) Consider carefully what information would help them make the most informed decision.

I typically start by listing out the business need driving each item. Sometimes the business need can be a brief category (i.e. revenue, efficiencies, etc). Sometimes it is helpful to articulate a full benefits statement and quantify it. It really depends on who is making the decision and how constrained the resources are. The more requests you’ll need to cut, the more you’ll want to understand about the potential benefits of the highest priority requests.

There are some other useful attributes to consider. Here’s a run down of the most commonly used:

• Strategic Fit — how does this request fit in with the organizations strategy or the technology strategy?
• Cost — how much will it cost us to implement this?
• Sizing — in lieu of hard cost numbers, about how big is this request?
• Current functionality — how does this request relate to what the system supports today?
• Requestor — who initiated this request? Be sure to indicate if there are multiple requestors as this can indicate a high-priority feature.
• System — in environments supported by multiple systems, indicate which system this request impacts.

As you flesh out your requests, feel free to add or remove from this list. I rarely use all of the above attributes and I often find myself using an attribute I’ve never used before to meet the needs of a specific situation.

This list of requests will quickly become what I like to call an “in/out” list. In the context of the project or release you are planning, the stakeholder group can decide if a given request is in or out of scope.

Compiling a list of stakeholder requests can yield many other benefits as well. Even when a stakeholder request is not included in the scope of the project, it will often come up again later. Oftentimes as you are getting ready to finalize requirements a stakeholder will say, but I asked for X, did you miss that? You will be able to point back to a document like this and say, yes, I know you asked for X, and we decided to defer it. Without this documented, you tend to re-evaluate scope just when you’d rather be nailing down detailing requirements.

Just as important, the request list serves as a validation tool. You give immediate feedback about what you heard in an interview or other elicitation session before asking them to sign off on scope or requirements. Even if a particular request does not make it into your project scope statement, your stakeholder gets feedback that their request was considered. This is more powerful than you might think. Sometimes people just need to know that their ideas have been heard!

>>Define Your Business Analyst Process

Join us for the BA Essentials Master Class. You’ll learn a step-by-step business analysis process that you can customize to meet your organization and project situations.

Click here to learn more about the BA Essentials Master Class

When regarding which stakeholders should participate in requirements discovery on a project, it’s easy to invite the masses to the meetings. However it’s more important to get the right stakeholders actively involved and the right time. Having more stakeholders than necessary can bog the meetings down in argumentation, conflicting dialog and detail. But overlooking an important stakeholder can result in missed requirements.

By the way, if you want to learn Laura’s top tips to getting stakeholders more actively involved on projects, Click Here to Download a Free Guide – 10 Tips to Improving Stakeholder Engagement.

Who are the Right Stakeholders?

Deciding who should be involved, how, and when in doing stakeholder analyses[sic] is a key strategic choice. In general, people should be involved if they have information that cannot be gained otherwise, or if their participation is necessary to assure successful implementation of initiatives built on the analyses.

— Thomas, J. C. (1993). Public Involvement and Governmental Effectiveness: A Decision-Making Model for Public Managers. Administration and Society, 24(4), 444 -469.

Getting the key stakeholders to participate in a project should not be anoff-the-cuff decision, but rather one that is a result of careful analysis and selection. Stakeholder Analysis is a much written about activity, but the general definition involves the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables. (IIBA’s BABOK(R)  Guide, 2009)

This all sounds pretty simple in essence, but there is actually a lot that goes into identifying the correct participants. Also, skimming over the tasks related to this analysis can put the entire project at risk by not have the proper people involved or not having influencers associated with the project to help guide the project in moments of indecision.

Start with a Formal Stakeholder Analysis Exercise

There are many techniques for performing stakeholder analysis, but the overall goal is to determine who are the persons impacted by a proposed change and to assess their attitudes and influences on various project factors. These attitudes and influences are the drivers behind decision making and project progress in and of itself, as well as against the entire suite of active projects.

There is one critical element to stakeholder identification that often eludes a project’s members. Once formal stakeholder analysis is completed at the beginning of the project, it SHOULD continue throughout the life of the rest of the project. The identification of stakeholders early in the project will often result in the names or persons with manager and sponsorship powers, as well as line managers tied to the business units. These are definitively key stakeholders that have to make decisions about the project’s scope and direction.

Include Subject Matter Experts as the Project Unfolds

However, as the project team delves deeper into the requirement elicitation and modeling of the system, it is possible that the key stakeholder becomes someone more intimate with the inner workings of a department, system or team. Failure to identify additional stakeholder, often referred to as subject matter experts, as the drill-down continues can often lead to products or services that are not deemed usable by the very people that the project is designed to serve.

It’s important for the analyst to not replace the original key stakeholders with yet another set. Rather, the analyst is in a position to re-evaluate throughout the course of discussions whether the correct people are included. This doesn’t require another full stakeholder analysis exercise, because the analyst is not trying to, again, replace anyone. The goal is to get additional impacted persons to the table, perhaps through a subject matter expert interview. Where the focus of the original stakeholder analysis exercise was the entire project, a subsequent evaluation of proper stakeholder inclusion could focus on a granular sub-component of the project, such as an operational unit, system component or the like.

It’s also important to remember that as projects continue through to completion, the political aspects of the organization and its stakeholders are alive and well. Careful consideration to the inclusion of particular stakeholders must be given in relation to the attitudes of existing high-level key stakeholders.

Project failure has as its root cause many possible reasons. Delivery of a requirement set that has input from many potentially impacted stakeholders with thorough discussion and analysis helps to remove from consideration the possibility that the requirements didn’t meet the stated needs because the wrong people were involved in their definition.

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.

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.

• Maybe they are shuffling their papers.
• Maybe they are bored and checking their emails.
• Or maybe they are restless and start finishing your sentences and communicating with that leaned-forward head nod that says “yes, yes, yes” let’s move along now.

I often feel I must bore my unlucky meeting attendees by poring through detail after detail of requirements documentation, issues, and questions, the typical process of a requirements review. Even if it doesn’t seem to be all that enjoyable, what else am I to do?

This is a tough question, because in all reality, a key business analyst skill is to find the details others miss.  It is possible, however, to achieve our quest to document the right details without communicating from the details. This is an important distinction. The result of our analysis and the matter of our discussions can be at two different levels.

Let’s look at an example.

What if you set aside mindless walk-throughs for meaningful requirements sign-off? This applies to use case reviews, wireframe reviews, or any meeting where your purpose is to validate that a specific deliverable communicates exactly what is intended. It’s easy to focus on the details, details, details.

Instead, turn a walk-through into a discussion with a purpose. Not all details are created equal.

• Some details you know for sure you’ve got right.
• Some can be inferred from one another.
• Some need to be asked.

Create a discussion with a purpose by setting a clear goal (often part of your meeting agenda)  that defines what you want to learn–share this goal with your participants. You might also have an internal goal for yourself about what you’d like to document and what requirements you need to validate, but most participants do not need to be explicitly aware of that goal.

Secondly, gauge what details your participants care about.

• Do they care about the minuscule details of the user interface, the emails that are sent, the flow of the site, or what they need to build?
• How do they perceive this value in the context of this project?
  Just as importantly, what value can they add that no one else can?
• How can you leverage this insight to maximize the value of their input?

By considering the unique perspective of the stakeholder, you can set goals that they can and want to help you accomplish.

Finally, gauge how your participants want to learn and communicate.

• Do they like to read documentation and ask questions?
• Do they want you to verbalize the key requirements to set a context and then answer your questions?
• Do they need time to prepare or will they never prepare no matter how much lead time you give them?
• Do they need to see pictures?
• Do they need handouts?
• Will you get their best ideas by getting them to draw on a white board?

You might try out various approaches until you find the right mix that works with your stakeholders. You know you are close if you are getting the feedback you need to move the project forward.

It’s important to remember that stakeholders will come at your project from different levels of detail. By imposing your detail-orientation on them, you make them work harder to provide you the right input and risk the possibility they might never give you the necessary details. You might be their forest or you might be lost in the trees. Considering things from their point of view and meeting them as close to their level as you possibly can get will help you elicit the right requirements efficiently.

The analyst needs to manage the communication that MUST occur between the two operational entities. There are techniques in place to help the BA that are tried and true. As with the attitude issues and resolutions I wrote about in my previous post, technique is only the vehicle to achieve the goal. Willingness, knowing when it is appropriate and being able to cross boundaries to assist who is often considered “the enemy” is the critical skill. Unfortunately, there are times that even though the desire to assist a project partner is evident, the organizational boundaries of ownership prevent that from occurring.

Executive Management, responsible for resource allocation expenditures, may view this as dollars wasted, while not realizing that by helping “the enemy”, the analyst is providing huge value their own team. Very often the psychology and rules of corporate management strictly govern what a manager can or should do with a resource. Briefly to this point, there may be tight guidelines that prevent the formal sharing of resources or a resistance to allow resources to spread their wings for the good of the department. The more they spread, the greater the loss of control. These are ownership constraints that prevent collaboration on projects. It takes a confident manager to overcome these types of obstacles.

A recent project I worked on as an IT analyst is one that comes around twice each year to address market conditions. It’s a revenue producer and is highly visible, cannot fail and is very fast-paced. The last round had a business stakeholder who wasn’t new to the organization, but was new to the project. Things started off fine, but as the complexity and speed of the project grew, this person began to struggle. So here’s the dilemma…do I take time that I don’t have away from my primary duties to help this person out? I bet you’re familiar with a few of these:

• “They’re business. We’re IT. Their own people can figure it out.”
• “That’s their problem, not ours.”
• “If that’s the best they can do, it’s not our problem.”
• “So? We have enough of our own problems. What would you like me to do about it?”

Well, enough of that. Let’s step back here and look at what is going on.

We are seeing the initial arc of the circular relationship between Business and IT. The customer has project (problem/opportunity) that they have funded and IT is working on it for money (getting paid). Continuing this path will maintain the current relationship, but it does nothing to make it a successful one when issues arise and one side or the other cannot fulfill its part of the equation. The second arc brings both sides together in collaboration in which the two rely on each other for success as a whole. Situations like the above are looked at as problems for the “other side” to worry about, but aren’t they REALLY opportunities in disguise to come together?

To continue, the customer and I began to work very closely together. There was much back and forth collaboration, many conversations, lots of hand holding, and paired testing. When this person didn’t know who to contact to answer a question, I provided information. When pieces and parts of requirements were disjointed or missing, I described why it couldn’t be delivered like it was, how to fix it and provided templates and guidance to help.

I spent maybe 15-20 hours in small increments over the life of the project with this person one-on-one. Little stuff like making myself available, answering a few questions, calling to see if I could assist, and providing education made big differences in our working relationship and the deliverables coming over to IT. This isn’t superhero stuff that many teams seem to gobble up; it’s just good customer service. What happened out of all this was a gracious, more confident stakeholder, better deliverables that arrived on time, and a stronger working relationship.

What did NOT occur was that my manager didn’t berate me for “wasting” my time, because there’s a prior proven understanding of the value of this exercise. When IT receives better quality deliverables from a customer or stakeholder, IT struggles less to define what is really needed and is able to meet its own deadlines and produces less defects that require additional defects. That’s important to IT’s bottom line; we’re more productive and more efficient. Customer dollars that may have been spent fixing defects now appear as profit.

If a resource can identify opportunities for improvement, there must be flexibility and autonomy to take advantage of it. There must be management that believes in the value of reaching out to the partner, because the monetary and non-monetary benefits far out weigh the cost. Financial frugality and accountability are important aspects of running a solid business, but ownership has its place. Getting the job done is an activity that any level of manager would defer to, no matter who signs the check.

….and those arcs I spoke above….they’re much stronger when they form a circle.

>> Learn How to Build Stronger Stakeholder Relationships

5 Ways to Earn More Trust

53 Tips for Discovering All the Requirements

How to Give Positive Feedback to Your Business Stakeholders

Within the business analysis community, the debate still reigns about whether how the application will look and how the screens will be laid out is technically part of requirements or design. This debate centers around the wrong question.

The right question is “When is the most effective time to introduce visual prototypes into your requirements process?”. My answer: As soon as it makes sense to do so.

Another good question to consider is “What requirements do a prototype or wireframe represent?” My answer: It depends. It depends on where you are at from a requirements process perspective (eliciting, validating, analyzing, or a bit of each), what types of requirements management practices you have in place, and what level of user interface expertise is available across members of the team.

I’ve worked on teams where the user interface wireframes or prototypes, coupled with some textual rules, formed the main body of functional requirements. I’ve also worked on teams where the prototypes were thrown away or merely used to capture representative screen shots. I’ve also partnered with a UI/UX Designer who creates the CSS/HTML for implementation alongside the functional requirements.

Regardless of where wireframes fit into the requirements package, they can be useful in all phases of the requirements process, from defining the scope to the implementation hand-off.

Using Prototypes During Initiation

During the initiation of a new project, some rudimentary mock-ups can help elicit new requirements and create alignment around project scope. These mock-ups might look nothing like the finished product, but showing one possible solution to a set of high-level business requirements can help get everyone is on the same page. It’s important to keep these wireframes very rudimentary, separating out look-and-feel to focus on the basic concepts to be introduced with the application.

Using Prototypes To Get to Detailed Requirements

As you start to dive deeper into the project requirements, wireframes become more tangible. I often create wireframes for an end-to-end work-flow, leaving gaps for areas that are open to trigger discussion points. It’s not uncommon for me to hold a walk-through and show off wireframes with bright red text and an arrow indicating “how should this work?” or “what should happen if the user clicks this button?” or “what if this rule is true?”.  Walking through a new work-flow using visuals helps elicit hidden business rules, alternate paths and creates good discussions. Taking the wireframes through an end-to-end work-flow also helps drive some analysis. I often find gaps as I try to get from point A to point B to realize we have missed a field or an entire screen and overlooked an important requirement as well.

Using Prototypes to Validate Requirements

In the final stages, prototypes can also be used as a tool to vet the final rules. These rules are probably documented in a separate document, such as a UI specification, use case, or business rules spec. But rather than do a comprehensive document review, I sometimes talk through the rules in reference to the user interface.  An example of this might be in an integrated environment  when you are looking at a screen that is going to feed data to a native application. These rules will likely be documented in a spreadsheet of some kind with all the data mapping details, but instead of reviewing the spreadsheet I’ll bring up the UI screens and visually reference the mapping. So this field will go there…and then if the this field meets this condition, we’ll map it over there…etc, etc.

Interesting in seeing how prototypes can be part of your next project?

Learn to Create Useful Prototypes

Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.

Click here to learn more about Use Cases and Wireframes

Today, teams of resources attempt to work together in high-pressure environments, and project teams must find ways around obstacles that deal with political agendas, communication, collaboration and attitudes toward one another caused by issues in these areas. Failure to do so can produce poor attitudes, incorrect results, frustration, decreases in productivity and increases in wasted time, money and human resources. Experienced IT or business analysts, by thinking and acting across boundaries, can help enhance team cohesion and results.

There are several reasons why attitude becomes an issue that needs resolution. As a business partner that interacts with IT and funds projects, that person is trying to conduct business operations and is reliant on support from IT. Immediately, the psychology of that relationship has the potential to place the business partner into defensive mode, due to a simple inferred trust relationship.

The first encounter between the two teams is where defensiveness can first form. Business comes to IT with a need or problem, and IT is supposed to take it and form a solution. Often, there is a lack of thorough understanding between the two teams, even if the need has been stated. The explanation of the core business need is not understandable for IT to take action on, even though it’s clear as day for business. Why is that?

Let’s look at the opposing perspectives. Business states, “The system must accept online payments.”  That statement, in the eyes of business SMEs is plain and simple. To IT, more information is needed to resolve questions about payment format, payment options, banking options, language options, security configurations, etc… If an analyst has only documented the need and delivered that to IT, questions abound and attitude forms. Taking into account that the analyst should have done a better job, IT perceives the business to be short-sighted and business is put out by having to answer the same question again.

Communication failures breed frustration and frustration forms bad attitudes toward one another. Without a BA skilled in facilitation and elicitation, the level of anxiety for both teams can increase. Whether an IT or Business analyst, that person has an obligation to step out of his or her comfort zone to hand-hold the partner and the communication process until the message is clearly stated and understood. Sure, analysts have techniques to elicit requirements and communication, but the point is that technique may not be enough. Sometimes, the situation requires that analysts step into the shoes of their counterpart and do whatever it takes to build a trusting relationship in order to succeed together.

On a recent project as an IT analyst, I found myself receiving multiple, conflicting change requests from members of a business team regarding data, some filled with mistakes. I soon realized that the business team members were not communicating with one another and not cross-checking the quality of the data requests before they were sent to me. The resultant errors were causing huge problems for IT due to integrated systems all trying to use the faulty data. With permission from the senior business stakeholder, I was able to assemble the business team and explain the issue and the problems. Together, we crafted a better way to ensure the quality of the requests and data.

This was not an IT issue at its root cause, but by working directly with customers and avoiding finger-pointing, IT was able to build a trusting relationship, support our partners (not our enemies) and immediately improve productivity while reducing costs. Additionally, we taught our business peers not only why the issue was so important, but how to do things going forward, thus reducing the potential for future problems. More importantly, the poor attitude from IT toward business was quickly dissipated before it grew roots, because we helped the business help ourselves.

A secondary factor that contributes to attitude is the lack of visibility of what the other side has to do to function. IT has no clear line of sight into the workings of business process and management; and business doesn’t generally understand what makes the technology implementation so complex. The analyst is in a unique position to offer up some simple clarifying communication to enlighten all participants. Here are some very simple things that an analyst can do to enhance communication and collaboration:

As an IT analyst:

• Don’t just define the superficial problem; explain why it’s important that things are done a certain way.
• Introduce the technical team members to the business partners and explain what each role is responsible for.
• Include technical team members in working sessions with business and facilitate that dialog. Doing so will allow for free exchange of ideas and concerns and will allow business partners to understand why certain questions are asked.
• Actively offer customer service support to business team members and all stakeholders to let them know you want them to succeed.
• Pick up the phone and call the business team members and stakeholders to check in with them for no reason. This takes customer service to another level and let’s them know that you are sincere in assisting them.
• Contact the senior stakeholders and inquire about progress, comprehension, team collaboration and anything else that will bring the IT and Business teams together.
• Always approach every communication with a “What can I do for you?” customer service approach and attitude.
• Always remember that you may work for IT, but you are probably the ONLY person in IT to protect the interests of your CUSTOMER.
• Always remember that business dollars make your job possible.

As a Business-side Analyst:

• Insert yourself as much as possible into IT conversations about your project.
• Reach out to IT management to let them know that you desire to deliver what is needed and to call on you for help.
• Proactively inform IT of business-side problems and ask them for ideas on resolution for the benefit of both teams.
• Remember that IT is your CUSTOMER. You are delivering something that they need in order to help you, so by providing quality you are making it easy for them to do so.
• Actively seek feedback from your IT contact to ensure that he/she knows you are committed to doing a good job.
• Always remember that in today’s electronic environment of doing business, IT has the capability to make core business operations successful.

While these suggestions seem trite and corny, they can significantly change attitudes. They go a long way to building a better working relationship with peers on the other side of the fence. That relationship is what will glue both teams together and form bonds that will collectively break down communication barriers, avoid frustrations, and produce success.

Interviewing subject matter experts (SMEs) is part art, part science.  I’ll provide you with some techniques and best practices for rooting out requirements and getting your SMEs to provide you information that they might not even be conscious of knowing.  But be aware that when you are in the midst of interviews and demos, you should listen to your inner instincts about what you are hearing and what questions you should be asking.

Some general practices:

• Always interview the business subject matter experts first.  As tempting as it can be to get into the guts of the system with a star developer, your priority is to understand how the system is used and the business process it supports, not how the system works.
• Establish trust.  SME interviews can seem a lot like that scene from Office Space where high-end consultants were brought in to figure out who to fire.  Explain why you are doing what you are doing and why you need their help.  Taking time to explain how the information will help you can go a long way in creating an open environment.
• Establish credibility.  Maybe the SME has gone through this activity a handful of times before.  Where are the results of those meetings?  Come in with a defined agenda and set of questions wherever possible.  Be ready to show you’ve done your homework and aren’t asking them questions you could answer for yourself.  Always let them know what your next step is so they know this conversation won’t fade into the ether.
• Get your SME to talk.  Ask them to show you how to use the system or explain a business process.  Ask open-ended questions to encourage dialog.
• Let them talk.  If you get a SME talking, don’t stop them. Listen carefully and encourage them to continue.  Ask follow-up questions.

Tips for rooting out requirements:

• As you are listening to your SMEs, try to think in terms of cause and effect.  Oftentimes your experts speak in “effects.”  True gems of system functionality can be found in the causes: How does that happen?  What makes that happen?  Why does that happen?  Building cause and effect relationships as you understand system functionality uncovers gaps in information.
• Be wary of the happy path.  Things go wrong, but not everyone thinks about what goes wrong.  Ask questions like: Does every record move to the next step? Are some records handled specially? What kinds of issues happen here? What are some of the things you look for in this process?
• Be equally wary of those who speak in exceptions.  It really helps to understand the happy path first.  In these situations you’ll need to refocus the conversation with questions like: If that doesn’t go wrong, what happens? Does every record go through that process? How often does that happen? Tell me about a “perfect” record.
• Watch for unexplained specifics, such as “this happens every Tuesday morning” or “I can an email from accounting”.   What’s really going on here and how does the system support that business process?
• Be curious.  Ask why, why, why to the point of being slightly annoying.

Again, this activity is as much an art as it is a science.  Go in prepared, use the elicitation techniques that feel most comfortable to you, and, most importantly, listen.

>> Get More Prepared for Your Next SME Interview

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 subject matter expert interview with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

After exploring the system, you’ll have a surface level understanding that’s documented with a visual map or list, use as a list of use cases.  You will also create a list of targeted questions for your stakeholder interviews.

How to Get Started Exploring the System

When exploring the system, using a test or development environment is a best practice.  Ensure you can manipulate the data and follow your data through the system as this will give you many insights.  If a test environment is not available, you can explore in production, but your freedom will be limited as you wouldn’t want to mess with any public-facing data.

• If you are dealing with a consumer-facing application, such as a website, you’ll want to start as any consumer would.  Think of a goal the website should help you fulfill and start navigating to achieve it.
• If you are dealing with an internal tool, check around for training materials or business process documentation to gauge how a business user might use the tool.
• If no documentation can be found and you are exploring a new business domain, you might want to engage one stakeholder in a brief demo or invite yourself to some training of new hires.  Taking an hour of someone’s time in this situation will get you leaps and bounds ahead and make your exploration of the system much more fruitful.

How to Discover What the System Does

What’s the most important thing to do?  Just start clicking!

Click, review, think, click again.

Jump around the application until you have a general idea what’s there.

It can be really helpful to build a site map as you do this, with notes to yourself about things you want to check out.  Or instead of a site map, consider a features list or use case list, whatever seems most natural to you and the situation.

Once you build this map or list, go back through each function and work through the data flow.  Add a new record, subscribe, do whatever you can to get data into the system.  Then look for this data in other places, checking what you can do with it, or what a user with a different role can do with it.  Watch out for any changes that aren’t triggered by your direct actions as these can indicate automation rules happening behind the scenes.

How to Stop Your Exploration Before it Becomes a Time Sink

Exploring the system involves a balancing act between doing your due diligence and getting lost in trying to figure something out that could be explained to you in a few minutes.

• Stop exploring the application when you’ve gone through every link you can find.
• Stop exploring a specific feature when you find yourself spending more than 10 minutes trying to figure something out with no luck. Clarify what you are hunting for an add a question to your list.
• If you find this kind of thing exciting, you might want to time-box these activities within about a days worth of work.
• If you think this will bore the heck out of you, consider forcing yourself to sit down and do it for at least a few hours.

Each system and project is different, the important thing is to inform yourself without letting this activity become a time sink.  At the outcome of this process, you should have a reasonable list of features with lists of questions tied to each one.

You can always come back to this step during your analysis process, and you likely will.  Your questions and stakeholder interviews should uncover areas of the system that aren’t readily apparent in your first round of exploration.

>> Get Better at Asking the Right Questions

Interested in receiving a comprehensive set of questions you can ask in almost any project context that will help you explore a system with more intelligence and purpose? Want to feel more confident asking questions in a new domain? If you are on our list, you’ll receive a special early pricing on our Requirements Discovery Checklist Pack in late September. (You’ll also get a free career planning course right away and a free checklist before we make the entire Pack available.)

Click here to learn more about the benefits of being a Bridging the Gap subscriber

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

These conversations often occur because participants differ in their opinion of what the problem really is.  The dialog is laden with solutions and each person internalizes how each solution might solve their particular version of the problem.

What Can You Do?

The step you absolutely must take is simple. Simply say:

“I think I might be missing something here. Can you clarify for me what problem are we trying to solve?”

Let the conversation shift as people state their version of the problem.  But you are not done yet.  Many might bring up their solutions as problems.  And some might have trouble articulating what the problem really is.  Reach into your facilitator’s bag-of-tricks for multiple ways to refocus the discussion without sounding irritating and redundant.

1. If we did XYZ, what would happen?
2. What benefit does XYZ have?
3. What would change once XYZ is in place?
4. How does XYZ change things?
5. Why should I care about XYZ?
6. What’s your goal? (or, the goal)
7. How would XYZ impact you? (good technique to shift the conversation to a non-participant)
8. What else do we need to think about if we do XYZ?
9. Let’s talk about what problem we might be trying to solve here. (yea, it’s often necessary to re-iterate, just re-phrase if you can!)
10. How would your day-to-day work change if we did this?

I could go on, but then I’d risk sounding redundant. And I know with this list in hand you’ll be able to come up with your own ideas for asking why with finesse. The important thing is that you be persistent in your pursuit of the real problem and don’t stop asking questions until you’ve got agreement from all participants on what the problem really is.

Two questions to frame up the project:

1. What problem does this solve? Be careful not to describe the solution, but to fully articulate the problem or opportunity.  For a humorous read on this subject, try Are Your Lights On?: How to Figure Out What the Problem Really Is by Donald C. Gause and Gerald Weinberg.
2. What does the solution look like? Describe the potential solution to the problem in as much detail as possible.  It can also be a good idea to get together a small team of people who understand the problem (or better yet live with it everyday) and ask them what they think the solution looks like.

Three questions to evaluate the project.

1. What is the potential upside of solving this problem? What do you stand to gain or save as a result of a successful project implementation?
2. What are the risks? There are many ways to think about risks, so think about what will happen if you can’t implement this project successfully and what will happen if you do.  Could this project have an unanticipated side effect?
3. How much will it cost me to solve this problem? There are a variety of ways to find this answer (sending out an RFP, having internal staff provide estimates, etc). Be sure you think through the costs of managing any changes required to implement the new solution.  For example, upgrading your accounting system will involve revising a few business processes and retraining staff members.

Now, ask yourself, is the potential upside greater than how much it will cost you to implement? And is the project worth the potential risks? And is there anything better we could be investing in?

Let’s just be clear here: Someone who cannot clearly articulate how they will finish their primary task is not likely to be hired into the role.

So, what does it mean to be done with requirements?  There are three basic criteria:

#1 – Alignment:

You have created alignment among your business stakeholders around what needs to be built to drive business value.  The evidence of this alignment is clearly documented.

#2 – Buildable:

You’ve elaborated your set of requirements into a level of detail that an your implementation team can build from.  For example, a software developer can’t build “advanced search” but s/he can build the “ability to search the full-text of the article, where full-text includes the title, summary, and full article content, and present the article titles of all matching results”.

This requirement has a slew of other related requirements as part of a complete system and is probably best documented in a use case, but the requirement itself passes muster in that it’s ready to be built.

#3 – Quality test:

The requirements meet your organization’s test for quality and applicable industry standards.

Inside The Business Analyst Blueprint® training program,  you’ll discover how to review your own requirements against a set of industry-standard criteria, and then provide expert instructor reviews so that you also learn from your own mistakes.

Here’s the deal…

To answer this question confidently and with expertise, you really need to have a business analysis process framework. You need to be able to articulate the steps you go through to take a project from start to finish, so you can clearly define “done”.

The good news is that you don’t need to start from scratch – you can leverage Bridging the Gap’s Business Analysis Process Framework.

And be sure to join the Quick Start to Success as a Business Analyst free workshop for tips on how to leverage this framework to maximize your effectiveness.

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