A TOOLBOX of techniques that you can pick and choose from, based on the needs of your project and team.
A FRAMEWORK that guides you step-by-step what to when.

At Bridging the Gap, we provide an organized, streamlined, and practical toolbox and framework in the form of The Business Analyst Blueprint® – it’s both a framework for approaching business analysis skill development and the name of our flagship, online, practical business analyst training program.

And it looks like this (and keep reading below for a break-down of what each part is and what it means):

The Business Analyst Blueprint® Framework is Organized Into Analysis & Communication Techniques

The first thing you’ll notice about The Business Analyst Blueprint® is that the techniques are organized into Analysis Techniques and Communication Techniques. The Analysis Techniques are the models and templates we use as business analysts to analyze and think through the requirements.

Requirements do not get created in a vacuum. We must elicit or discover them from our stakeholders. This is why knowing the right Communication Techniques to use as a business analyst are equally important.

The key Communication Techniques for collaborating with stakeholders are:

• Discovery Session – to discover information related to the process or requirements from business stakeholders, so the requirements represent their needs.
• Requirements Review Session – to validate the requirements that have been captured are clear and correct.

We also consider the glossary and user stories to be communication techniques, because their primary purpose is to capture and communicate requirements-related information to various stakeholder groups.

Here’s a video all about user stories – if you want to explore how to leverage them as a communication tool on an agile team.

The Business Analyst Blueprint® Framework: Multiple Levels of Technique Help You Avoid Missing Requirements.

The second thing you’ll notice about The Business Analyst Blueprint is that there is not just one set of analysis techniques. We miss requirements either when we don’t involve the right stakeholders (i.e., apply the right communication skills) or overlook key areas of requirements because we are only looking at one view.

When you use multiple techniques, particularly powerful analytical and visual models, you will find that you naturally see gaps that others gloss over and identify the downstream impact of a change or new solution.

The Business Analyst Blueprint® framework includes 3 key levels of analysis that are important to fully understanding a problem and solution domain, when software is being implemented as part of the solution. These are the business-level, software-level, and information-level.

Let’s look at each of these separately.

The Business Analyst Blueprint® Framework: Business Process Level

The Business-Level articulates how the business work flows operationally. When you have a clear understanding of the business process, you will be able to clarify the business problem to be solved and ensure the technical solution delivers actual value to the business.

At this level, the analytical techniques include:

• A Business Process Flow diagrams which is a visual model showing the end-to-end flow of the steps a business user (or group of business users) take to accomplished a desired outcome within the organization.
• An accompanying Business Process Document which is a textual model providing additional details like business rules, exceptions, entry and end points.

Analyzing a business process is almost always a great way to start figuring out what problem needs to be solved and getting stakeholders on the same page about the key issues to be addressed by a project. Often you can solve a lot of problems just by clarifying the “as is” or current state process, so this is a really productive set of techniques to have in your toolbox.

Learn more about creating process flow diagrams, or process maps, in this video:

The Business Analyst Blueprint® Framework: Software Level

The Software-Level captures how the software system supports the business workflows. When you analyze your functional (software) requirements in use cases and visually model them in wireframes, you create the perfect combination to get your business stakeholders and technical implementers on the same page about the requirements more quickly.

At this level, the analytical techniques include:

• Use Cases which is a textual model that describes exactly what the software needs to do, and capture the requirements in a way that is clear to both the business and technology stakeholders, so that the software development team can build what the business actually wants.
• Corresponding wireframes show what the screens on the page might look like, and make it easier for stakeholders to visualize the requirements and provide meaningful feedback.

Use cases also help you generate a lot of high quality questions to be asking, because missing pieces and requirements pop out pretty quickly with a good set of use cases. What’s more, you can use them for both new software development as well as configurations or customizations of COTS or SaaS projects.

Learn more about use cases in this video:

The Business Analyst Blueprint® Framework: Information Level

The Information-Level addresses how data and information are stored and maintained by an organization. Data modeling is critical on all kinds of projects, but especially data migration and system integration projects.

And while data modeling can seem quite technical, the way we teach these techniques at Bridging the Gap is from a business-focused approach. And using these modeling techniques can help you earn credibility with your developers, since you’ll be able to talk in their language (even when you don’t know how to code or write SQL).

Key data modeling techniques include:

• Entity Relationship Diagram (ERD), which bridges gaps between business concepts and technical database design using a simple visual format that really engages stakeholders.
• Data Dictionary, which shows you how to organize and drill down into the detailed data requirements. You will also take away the essential concepts you’d glean from an introductory SQL class.
• Data Map, which shows you how to visualize the information flows between systems and clarify boundaries that speeds up the scoping and elicitation process.
• System Context Diagram, which shows you how to visualize the information flows between systems and clarify boundaries that speeds up the scoping and elicitation process.

This video is a great place to start diving into data modeling:

The End-to-End Business Analysis Process in The Business Analyst Blueprint® Framework

The next thing you’ll notice about The Business Analyst Blueprint® Framework is that there is a foundational framework underlying the techniques. This is the business analysis process, or the end-to-end approach you apply to be successful and effective on a typical business process improvement and software project.

Having a structure and trusted approach gives you credibility.

The business analysis process leads you step-by-step through how to approach a software project as a business analyst and covers:

1. Get Oriented – Start actively contributing as quickly as possible.
2. Discover the Primary Business Objectives– Ensure the right business problem is solved.
3. Define Scope– Gain agreement from stakeholders on the scope of the project.
4. Formulate Your Business Analysis Plan– Identify the deliverables, stakeholders, and timelines for a comprehensive solution.
5. Define the Detailed Requirements– Establish an efficient and collaborative rhythm.
6. Support the Technical Implementation– Ensure the technical solution meets the actual business objectives.
7. Help the Business Implement the Solution– Support business stakeholders so that the solution ultimately delivers the intended result.
8. Assess the Value Created by the Solution– Assess the ROI of the solution.

As you leverage this process framework, you’ll gain increased recognition for the value of business analysis, and you’ll start to get pulled into more interesting projects, and be engaged earlier in the process. Here’s a video about the business analysis process framework.

Leverage the Power of The Business Analyst Blueprint® Framework

When you leverage a framework like The Business Analyst Blueprint®, you’ll be able to shift from being reactive to proactive. You’ll have a toolbox of techniques to use in just about any situation you find yourself in as a business analyst, and you’ll know exactly what to do when!

Business analysis can feel so fuzzy and mystifying, but it certainly doesn’t have to be that way.

Join The Business Analyst Blueprint® Training Program

Click the image below – or visit this link – to find out all about The Business Analyst Blueprint® training program – our practical, results-oriented program designed to help you achieve more success in the real-world as a business analyst.

I hope to see you in class!

With data mapping, you can take control of your projects from the very beginning, setting the stage for successful implementation.

In this video, Laura will guide you step-by-step through the process of creating a data map, without needing any type of coding language or SQL knowledge.

Once you understand data mapping, you’ll be empowered to tackle data migration and system integration projects with confidence!

In this video, you’ll discover:

• A data mapping sample
• The key components of a data map
• Resolving potential issues with data modeling
• Finding data mapping issues in the data model

As a business analyst, you need to have the ability to showcase how data seamlessly flows between information systems ensuring smooth operations and avoiding the headaches of data inconsistencies and mapping issues. With data mapping, you can take control of your projects from the very beginning setting the stage for a successful implementation. That’s why in this video, I will guide you step by step through the process of creating a data map, all without needing any type of coding language, or even SQL knowledge. Once you understand data mapping, you will be empowered to tackle data migration and system integration projects with confidence. So don’t click away.

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 on business analysis, tips and techniques.

A Data Mapping Sample

Essentially, a data mapping specification will analyze on either a field-by-field basis how to move data from one system to another. Here is a sample data mapping template and an example that you can use to see how this works in action.

This is a hypothetical example, assuming that we’re sending a data feed from the Bridging the Gap article repository to a search engine.

In this scenario, I would want to map the key attributes of an article, such as the title, the category and content to the attributes specified by the search engine. This analysis exercise would ensure that each piece of information ended up in the most appropriate place in the target repository.

For a little context, by the time that you are at this stage of the project, this is definitely not the first technique that you would be using most often.

By now you have analyzed the business process, you’ve defined the functional software requirements, you have an overall vision of the project scope. You’ve also done some high level data modeling, like creating an ERD or an Entity Relationship Diagram, and a system context diagram. Now you are looking at how data is going to flow specifically from one system to another at a very granular level of detail to achieve those bigger picture business objectives.

The Key Components of a Data Map

To achieve this goal, let’s just talk about the key components of a data map.

• It’s going to contain a list of attributes. For the original source of data, often that additional information comes from a data dictionary.
• Then it’s going to have a corresponding, or mapped, list of attributes for the target data repository, again, with additional information from your data dictionary.
• Then it has translation rules defining any data manipulation that needs to happen as information moves between the two sources, such as setting default values, combining fields, or mapping the values from one example to another.

Data Mapping is About Resolving Potential Issues

In its essence, data mapping is about resolving potential issues. Creating a data mapping specification like this requires discovering and resolving potential issues prior to the mapping being implemented. You don’t want to get to the point where you’re trying to move the actual data between systems and all kinds of errors are popping up or the users are looking at the data and feel like so much data is just missing. We lost the data. You want to prevent those problems by doing this analysis upfront. In a data migration or an integration, there are any number of differences between how the data is stored and where it goes can cause that data to be lost or misrepresented in some way that looks really significant, especially to a business user.

For example, it might be that the source data has a text field and your target data repository uses an enumerated list. Without analyzing the data and providing some logic for how to map those text values to the values in that enumerated list or the list of potential allowable values, or doing some sort of data cleanup before that happens, you’re likely to experience a lot of errors in the system migration.

Even in our simplest data mapping exercise here in this example, there are multiple mapping issues that we had to work through.

• For example, the article title contains HTML in the source data. Not uncommon to have some sort of code that would then in another system show as code versus automatically be filtered out.
• Also the source data can have multiple categories while the search engine has a single text field. You might want to have logic for turning multiple values in the category field into a comma or semicolon separated list in that text field.
• Another example is that the article truncated to 4,000 characters. While there’s no limit in the source data, the same with the URL.

In each of these cases, as the business analyst, you want to use your knowledge of the business process to identify how to handle that mapping issue or collaborate with the business stakeholders to really discover their needs and their desires and what they’re willing to invest in potential data cleanup and manipulation and organization and scrubbing before the migration or the integration happens.

It’s really important. I know I keep stressing this, but it’s important for this to happen before the actual development part of the data migration starts so that these issues can be found and then direction can be provided to the database developers who may not have the same in depth knowledge of the business that you’ve developed as the business analyst.

It’s also not uncommon to need the business to do actual data cleanup before the migration. Often that best happens in the source system because you have all the data there versus trying to get over what you can and doing things in the new system or the target system.

Finding Data Mapping Issues in the Data Model

Data mapping is going to help you get really, really clear on how the data is going to flow from one system to another. However, mapping issues can be even more significant than like how one field maps to another.

Often when you’re moving between systems or relationships. In the data model itself that are different between systems. For example, if our article system happened to have a concept of a newsletter or a group of articles that wasn’t maintained by the target system, we could lose a lot of value in how our content was organized during that migration.

These sorts of data modeling differences show up when you’re creating an ERD or an entity relationship ship diagram. An ERD is an incredibly useful tool to use before you do more detailed data modeling like this so that you can get a sense of the big picture of how key concepts in your business relate before you dive into the details.

If you’re not familiar with what an ERD is or how to construct one, we have a free sample and a tutorial that you can download.

>> Click here for free download <<

Additionally, another critical data modeling technique for system integration and migration projects is called the system context diagram.

If you want to learn more about that, watch the video below and I’ll tell you more about that next. I’ll see you there.

No, you don’t have to be a UX designer to even aspire to be one.

In today’s fast-paced world, getting everyone on the same page about software functionality is crucial. That’s where wireframes come in!

They are the secret weapon that saves time, improves collaboration, and ensures clarity in software requirements.

Wireframing is a technique that any business analyst can master, and in this video, you’ll discover:

• What wireframes represent
• The different levels of wireframe fidelity
• How to create a wireframe
• How to get business stakeholders feedback on wireframes
• Challenges to watch out when wireframing

Say hello to the System Context Diagram, your secret solution to project scope!

In today’s world, projects are only becoming more and more complex, and even the tiniest tweak can send ripples through numerous systems.

A System Context Diagram is an elegant solution and visual powerhouse that will have your business and technical stakeholders nodding in agreements as you confidently navigate the intricacies of scope.

In our new video, Laura will guide you through the creation process and unveil the three primary parts of its syntax. You’ll also discover practical examples and insider tips that’ll get you comfortable with utilizing a System Context Diagram.

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.

• What documents should you create to capture those crucial requirements?
• How can you ensure you’re fulfilling your role as a diligent business analyst?

The path to success lies in understanding the power of documentation. In this video, Laura shares examples of the five types of requirements documentation that every business analyst needs to start using, including:

• Scope Statement Specification
• Business Analysis Plan
• Business Process Documentation
• Functional Requirements Documentation
• Information or Data Requirements Documentation

Throughout this video, Laura mentions various free resources we have that will give you a jump start in your requirements documentation, you can download those at the links below:

>> Click here to download Business Process Template <<

>> Click here to download Use Case Template <<

Imagine this. You’re ready to do a deep dive into a new project as a business analyst, but amidst the sea of information and tasks at hand, you find yourself at a crossroads. Which documents should you actually create to capture these crucial requirements? How can you ensure that you’re fulfilling your role as a diligent business analyst?

The path to success really lies in understanding the power of documentation, not just as a create all the documents type of tool, but as an analysis and a thinking tool, and a helping the business make better decisions type of tool. Today I’m going to cover five types of requirements documentation that every business analyst needs to be aware of and start using on most of their projects.

Hi, I’m Laura Brandenburg from Bridging The Gap where we help you start, succeed and excel in your business analyst career.

Scope Statement Specification

We’re talking about five types of requirements documentation today. The very first one I want to talk to you about is the Scope Statement. This is the very first type of document that you want to create on just about any type of project. It defines the scope of the project.

This specification might also be referred to as a business case or a vision document, or a Business Requirements Document, although in practice, BRDs typically include many additional sections that would include functional requirements. I’m going to classify that as a separate deliverable. We’ll talk about that in a little bit.

In this requirement specification, the scope statement, you’re essentially answering the following questions:

• What problem are we solving?
• What’s the business need?
• What is the scope of the solution to that problem?
• How in a high level view are we solving that problem?
• What does the solution look like?

Then you’re really using both of those questions to get to this final question, which is:

Is the investment in solving that problem worth it? Is there going to be a positive ROI, or return on investment, in this project?

Now, in an agile environment, those sorts of questions might be answered in an epic format, but regardless of what format, what document, what type of methodology you’re using, you want to get clear on what problem you are solving and what the solution looks like at a high level so that you’re scoping that project and getting buy-in that you need from senior level stakeholders to move forward.

Business Analysis Plan

Once you have the scope, the next type of requirements documentation is the Business Analysis Plan. A business analyst will typically create a plan that outlines the elicitation, the requirements analysis, and the validation and verification efforts as well as clearly indicate who is responsible for what within the context of the business analysis effort.

The business analysis plan will often be driven by the organization’s business analysis or software development methodology. Again, that might be formal or it might be really informal. If you don’t yet have a methodology, you can start with the eight step business analysis process framework that we teach at Bridging the Gap. I did an entire video outlining this framework step by step. Be sure to watch that after you finish this video.

Business Process Documentation

With the scope defined and your plan in place, you know where you’re headed, it’s time to start digging into the details. Although there is always a temptation to jump right into the software solution or functional requirements, it almost always makes sense to first start with analyzing the business process.

• Part of analyzing the business process is a process flow diagram, which is also sometimes called a workflow diagram or a process map. It shows the big picture of how the overall process flows from a stakeholder or end user perspective. This is a type of visual model that’s a great way to elicit a lot of information and create a shared understanding of both your current state and your future state process relatively quickly.

Here’s an entire video on creating a great process map:

• To accompany your process flow diagram, you want to use this textual business process document. We teach this technique of textually modeling a business process in our online business analysis training courses at Bridging the Gap because it helps you capture more details and analyze the process in more depth. Often, a process flow diagram is a great way to get the big picture, but you’re going to overlook some nuances and some details that a textual template will help you think through. Often those issues or inconsistencies are really easy to glaze over with just a workflow diagram, and you are going to catch them when you do the more in-depth analysis using a business process template like this.

>>Click here to download the full template<<

• To help you in that process, we have a really valuable resource for you available at Bridging the Gap. Our business process template is designed to help you capture and analyze the intricacies of your business process. By using this template, you can uncover all of those hidden issues and gain a deeper understanding for your workflow. Click below to claim your free business process template download.

>> Click here to download Business Process Template <<

What’s really important in this third type of documentation, the business process documentation, is that you are getting a business perspective of both the current state, or as is business process, and your desired future state, or to be business process. This is going to help clarify, in even more detail, the specific problems that you need to solve using technology.

You can learn more about as is and to be business processes in the following videos:

Functional Requirements Documentation

Next up on the list, our fourth type of documentation, is functional requirements documentation.

If the solution is a software solution, not all solutions are, sometimes you can just update the business process to solve the business problem. We don’t always need to use technology, but very often we are leveraging technology as all are part of the solution. In that case, the business analyst is going to specify the functional requirements for the project. These are also known as the solution requirements, the software requirements, sometimes the technical requirements, or the system requirements.

Functional requirements identify what the system does, how it functions, and they are typically written at the level of what a given user, like an actual end user, a person, can get the system to do. It’s what they see in their interaction with the system that is a functional requirement.

There might be a lot of additional things happening behind the scenes. Those would be more technical system design type of requirements. A functional requirement would be something that an end user could experience in interacting with that software system. They can be captured in a wide variety of different requirements deliverables.

• The very first one that we love to teach, it’s one of my very favorite requirements modeling techniques, are called use cases. These are a very common way to capture a functional requirement. We teach use cases at Bridging the Gap, using the template that you see here. We do this because we find that use case analysis helps the BAs, again, identify otherwise missed requirements by getting really clear on that system user interaction. It’s a really key technique.

>> Click here to download Use Case Template <<

• To assist you in this process, we offer another great resource at no cost to you, which is our use case template. You can download the exact template that you see above. This is specifically designed to help you capture and document use cases effectively. By using this template, you can ensure that no requirement is missed and gain a lot of clarity on the interactions between the system and its users. Click below to claim your free use case template download.

>> Click here to download Use Case Template <<

• Other times use cases are captured together in a different type of document called a software requirements specification, or SRS, or a functional requirements document, FRD, those may also include non-functional requirements. They’re more of a list of requirements. The use cases though, because of the way they show the user system interaction, are really powerful analysis tools that help you think about what requirements you might otherwise miss.

• In an agile environment, functional requirements are typically captured in user stories, which are organized into a product backlog. You might still analyze the requirements and use cases to make sure you’re kind of keeping the thread of how all those user stories fit together in your product backlog.

You Don’t Need a Technology Background to Analyze Software Requirements

One thing I just want to mention here, for those of you who don’t have a technology background, this is the level at which you need to learn and understand how to talk intelligently about technology. It’s about what the system can do for the business, not about how the system is built. Even if this level of understanding technology systems is not appealing, you are probably better off focused on more business process focused business analyst roles.

I just want to highlight, you don’t need to understand how to code, how to run SQL queries, how to design the systems in order to get to this level of clarity that really gets business and technology users on the same page. This is more of an analytical thinking capability than a technical ability.

Throughout my experience, I’ve noticed that functional requirements can still be really challenging for many business analysts. There’s a layer of specificity that you need to get to, to really be effective at getting these right. That’s why I created a comprehensive video tutorial specifically on this topic. I highly recommend watching that video as well to gain valuable insights and clarity after finishing this video. You can click below to watch that video. It’s an excellent resource to deepen your understanding of functional requirements.

Information or Data Requirements Documentation

One fifth and final type of requirements documentation, and that is to capture the information or data requirements. In addition to the user facing functionality of the software, the business analyst may identify elements of the information model as well. There are a few common types of data requirements documentation.

• One of the very first is the glossary. This is used to define a common language and terminology. You were going to use this to get really crystal clear on what terminology your business is using, making sure that the way you use a term like “customer” or “account” or “order” in your business process, in your use case, is consistent and that all of your stakeholders have the same understanding of what that term means.

• The next really common data requirements model is an entity relationship diagram. This shows those key concepts that might end up in your glossary and how they relate to one another, what details are captured in the information system about each concept. For example, if you had an order, are you getting the order date? Are you getting links to specific products? That would be a relationship to another entity called a product. You’d have the order time, the shipping address, things like that. And where are those captured? That’s what your entity relationship diagram is showing. These can look really technical, but you can also do them at a very business abstract level view so they really show the business concepts and the business understanding of the information domain.

• The last thing I want to show you is called the data dictionary. It also fits into this category of data requirements documentation. It will go into the details then about the specific fields or attributes, such as how long can that field be? What type of information does it hold? Are there any validation or business rules?

• When you combine, you can elaborate and combine data dictionaries from multiple systems to show how fields from one system will map to another, either for a one-time system integration or a system migration project that would be one time where you’re moving data from one source to another. Or we’re using something like an API to show how the ongoing system integration works and how those fields map to one another. This is called data mapping. I’ve got an entire video on data mapping.

Again, while all of this data modeling stuff can seem really complicated and technical, the way we teach it at Bridging the Gap is very business oriented. In The Business Analyst Blueprint training program, you would learn each of these data modeling techniques as well as how to use system context diagrams to show the overall information or data flow for your project.

To get you started with an overview of data modeling, we also offer a free data modeling training course, which is a portion of our full-fledged data modeling training module.

Key Practice: Choose Your Requirements Documentation Intentionally

We just listed five categories of documentation and multiple different types of specifications you might use within each of those categories. By no means does a business analyst create every one of these specifications for each and every project. Most business analysts will pick and choose the most appropriate specifications given the nature of their project, and they’re going to customize those templates based on the stakeholder needs and project considerations.

You want to look at what is happening in your project and what is really needed to make the next decision. What’s even more important is that you have a clear and focused business analysis approach that enables you to be more strategic and proactive in terms of how you approach the project.

We’ve got a wealth of content dedicated to providing valuable tips and strategies and insights for business analysts like yourself to help you really be strategic and proactive as possible. We have new videos releasing here every week, but you’re going to have to subscribe to the BTG YouTube channel to stay in the loop with all of our new content.

Remember to claim our free use case template by clicking below. And f you don’t have a business analysis methodology nailed down yet, that is really the very next place to start.

Make sure to watch our eight step business analysis process framework video by clicking the video below.

I’ll see you over there.

Download Your Use Case Template Today

If you want to get started with your requirements documentation, I invite you to download our Use Case template (it’s free). You’ll learn the key elements that go into a business process model, and be able to kick-start your requirements documentation process.

>> Click here to download the Use Case Template <<

In this video, I’ll cover how to avoid the most common business analyst mistakes, so you can make smart project decisions that earn the appreciation of your stakeholders and open up more opportunities in your business analyst career.

One of the mistakes I mention in the video is not engaging stakeholders early enough. We’ve created a FREE guide full of practical tips, real-world advice, so you can discover how to work more effectively with stakeholders to achieve better project outcomes.

In this free download, you will:

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

 >> Download 10 Tips to Improve Stakeholder Engagement <<

As a business analyst, you want to create the best requirements documentation and models possible. But what if I told you that focusing too much on perfecting those documents is actually a big mistake. Not only does it waste your time when you do that perfection too early in the process, it can also damage your credibility and delay the business analyst timeline.

In this video, we’re going to cover this mistake and four others that every business analyst should avoid. Stick around to learn how to add more value to your projects and avoid these common pitfalls.

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

Business Analyst Mistake #1 – Making Assumptions About Your Role

The number one mistake I see business analysts make on a new project is to make assumptions about the business analyst role that lead to overlooked responsibilities or areas of requirements. And I can point the finger at myself here more times than I would like to admit.

• I have unknowingly trampled on other team members’ roles because I just thought that’s what a BA was supposed to do.
• I’ve failed to deliver what was actually expected of me while working with incredible diligence towards deliverables that no one actually wanted me to create, and therefore went undervalued and underappreciated.
• I have followed the job description I was given to a T only to the learn that my team really needed something additional from me that wasn’t explicitly asked for.

There is so much dialogue out there about what the business analyst role is and what it’s supposed to be, and these jobs vary widely among different companies. Even within the same company, they can vary depending on what project team you’re on or what stakeholders you’re working with or what that team makeup looks like.

Correcting this mistake is really simple. Take time to clarify your role. Confirm your understanding and ask questions whenever anything is not clear. A lot of business analysts feel like they need to make assumptions because they shouldn’t be asking and asking for clarity about their expectations, that they should just know. But just knowing often leads us to deliver the wrong thing to the wrong people.

Let your manager and team know what you’re planning to do. Ask for their feedback to make sure you’re on the right track, and then deliver on your promise. Do this not just once, but again and again throughout the project as new information surfaces, or as new stakeholders get involved, or as you start to see an expanded view of how you can contribute. Re-clarify over and over again.

Wanting to learn more about the business analyst role? This video on the typical day of a business analyst is a great place to start!

Business Analyst Mistake #2 – Not Engaging Stakeholders Early Enough

Now, mistake number two is not engaging stakeholders early enough. When we start to move forward without getting all of the stakeholders on board. And sometimes the stakeholder is like lurking in the corner, not like literally in the meeting room, but they’re lurking somewhere, but they’re not really engaged. Sometimes they’re just too busy to meet with us. Other times there are reasons that we don’t want to meet with them, so we try to work around them. But it’s really important to get all the stakeholders invested upfront.

• On a project with new stakeholders, it’s your role as the business analyst to really invest extra time in getting to know who they are, what they care about and how they work best. It’s also a great time to clarify your role.
• If you are working with stakeholders that you already know and trust, a new project is a great time to deepen that relationship establishing ground rules to correct for past problem areas and really reengage since you’re working on something new together.

Even when you are facing that pressure to just move forward and get the requirements done already, you absolutely must ensure there is engagement each step of the way. Otherwise, you are simply setting yourself up to have to rework the requirements later, which is going to damage your credibility as a business analyst.

If engaging stakeholders makes you a bit nervous or you just want to get better at it, it’s one of those areas we can always get better at as a business analyst. I’ve got an absolutely free guide that’s called 10 Tips to Improve your Stakeholder Relationships.

> Download 10 Tips to Improve Stakeholder Engagement <<

And here’s a video with lots of great tips on engaging stakeholders too!

Business Analyst Mistake  #3 – Perfecting Documents Too Early

Now, the third mistake that I see is business analysts spending too much time perfecting documents and models too early. This is often related to not engaging stakeholders and it’s a great procrastination tactic. We can feel incredibly productive. We’re working really hard to get all our lines lined up and everything looking really beautiful, but it’s not actually capturing what the stakeholders want. You’re not in a collaborative information sharing type role where you’re learning more about the actual project or the domain.

While it feels really productive to sit behind your computer and tweak the language in your requirements or get all of your lines straight on a visual model, like an entity relationship diagram, you’re not going to really create real value from that documentation until you bring them to stakeholders and work towards creating a shared understanding.

If you happen not to be familiar with an entity relationship diagram, or ERD, I did do a full video tutorial on that model that you can check out after this video by clicking on the video below. If that’s something you want to learn more about, we’ve got all kinds of content on that.

My challenge to you is to put your together rough drafts of documentation and use those to guide productive working meetings with your stakeholders. You’re going to learn so much more from the discussion and the project is going to move forward more quickly.

Business Analyst Mistake #4- Focusing Too Much On the What and Not the Why

That brings us to mistake number four, which is focusing too much on the what and not the why, or really like focusing too much on the what too early and not using time early of the project to really focus on the why. This can lead to misunderstandings and misaligned expectations between stakeholders.

This is especially common, again, when we’re faced with those aggressive requirements deadlines and people just want us to get the requirements done so that the implementation can start, or when our stakeholders just seem so clear about the solution and they really just want us to help get the details down on paper.

Handling tight deadlines is more art than science, and here’s a video with some strategic approaches to navigating expectations without losing credibility.

As a business analyst, it’s really important to understand the underlying business goal and the objectives that drive that project, and to ensure that all stakeholders are on the same page regarding why the project is being funded in the first place and what the benefits are that it’s expected to deliver. This involves not just documenting the project requirements or all the things that the software needs to do, or even what the future business process is going to be, but also getting that understanding of the why.

What’s the problem that we’re trying to solve here? What is the end result we want to create for the business? What are those business objectives? By getting clear on those, you’re going to help keep your project on track and avoid unexpected delays, increased costs, and ultimately deliver a solution that does not deliver the expected benefits.

Business Analyst Mistake #5 – Allowing Scope Creep (and Straying from Focused Business Outcomes)

That really leads us to the fifth mistake I see, which is somewhat related to the previous mistake, but there’s a nuance that’s really important that I wanted you to grasp, and that’s really allowing scope creep or straying from these focused business outcomes. This means that the solution sort of gets bigger and bigger and bigger the longer the requirements process goes on. It strays from that original focus of the project. This will often happen when the business analyst is what is considered too business oriented.

And yes, that is a real thing. A business analyst can be too oriented or focused on the business in the sense that they don’t hold boundaries or constraints or keep things in check for the business. In fact, I did a video on this concept a while back that you can check out after this video.

It can also happen because as we build trust with stakeholders, we start to become really empathetic and they really start to open up about the problems that they have and we want to solve those problems and help them. We’re a helper kind of profession. Again, the scope just grows and grows. We can include that little thing and that little thing and that little thing. And, no, it’s really not what we’re supposed to be here for, but I can see how much value that it’s going to add for you.

This really damages our credibility with the project team because we build a reputation as somebody who comes in and takes maybe a small project or a medium-sized project and makes it way bigger than intended, and then people in other roles, like the project manager, are forced to arbitrarily cut scope to get the project done on time and on budget.

The solution to this is to always keep the desired outcomes of the project or the why, the problem that we’re solving, top of mind in ourselves, in our stakeholders, and for our sponsors. And as you get into the details of those requirements, make sure that each requirement is absolutely necessary to solve that business problem or achieve the business objectives of the project.

As an aside, if this means you’re smacked dab in the middle of a project and you haven’t done that work that we talked about before of understanding the business outcomes, the most important work you have to do is to bring that kind of clarity to the project, and to do it sooner rather than later.

Move Forward, And Do Your Best in Business Analysis

We’ve covered quite a few mistakes here that I see business analysts make. The last thing I want you to do is leave this video feeling more afraid of making mistakes than of moving your project forward. Any action you take in the direction of creating alignment and clarity and positive change for your organization will move you forward, will move your organization forward, will move your project forward.

You will make mistakes, and that’s okay. Just keep learning from them. How do you think I could put this video together? Because I’ve made the mistakes and I’ve learned from them, and I’m trying to share them with you so that you hopefully don’t have to make the same mistakes I did.

But maybe you’ve made one of these mistakes. Maybe you found something else, or you’ve learned from these and you make something new. That’s great. It’s a great learning opportunity. Keep moving forward instead of worrying about the mistakes. I’ve published tons of content here at Bridging the Gap about how to become a better business analyst and excel in your career, mostly leverage for all the mistakes that I’ve made in my career.

One great insurance policy against making mistakes is having really strong stakeholder relationships. The more your stakeholders respect and trust you, the easier it’s going to be to cover up when you eventually do slip up here and there.

We’ve created a new free guide, relatively recently, that gives you 10 tips to improve your stakeholder relationships. You can claim that free download right now by clicking below.

>> Download 10 Tips to Improve Stakeholder Engagement <<

Engagement is key in any role, but it’s especially important for you as a business analyst where you are constantly communicating with stakeholders and making important decisions.

I’d love to see you at another video that I’ve recorded specifically on how to build more confidence in your role, and I’ll see you over there next.

If you’re not using some type of diagramming tool in your business analysis job, you may be missing out on a powerful tool that can help you gain clarity quickly and effectively communicate your ideas to stakeholders.

As a business analyst, creating visual models like process flow diagrams, wireframes, or entity relationship diagrams can really speed up the requirements process and provide clarity. However, many BAs avoid creating visual models because they feel like they don’t have access to the right tools.

In this video, I’m sharing 5 diagramming tools you can afford, most even have free trials, so you can get started with your visual modeling right away.

To help you get started with visual modeling, we’ve created a FREE entity relationship diagram sample download that will give you an idea of how these diagrams can be used to represent complex relationships within entities.

>> Download the Entity Relationships Diagram Sample <<

Did you know that using visual models can improve communication, reduce misunderstandings, and facilitate collaboration in business analysis projects? If you’re not using some type of diagramming tool in your business analyst job, you may be missing out on a powerful way to help you gain clarity quickly and effectively communicate your ideas to stakeholders.

Stick around for this video where I’ll cover some of my favorite diagramming tools and visual models that are not only affordable, but also user friendly. You don’t have to be a designer or tech savvy to use them.

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 on business analysis, tips and techniques.

As a business analyst creating visual models like business process flow diagrams, wire frames and entity relationship diagrams can really speed up the requirements process and provide a lot of clarity. However, many BAs just avoid creating these models because they feel like they don’t have access to the right tools. These tools even have free trials, so you can get started with your visual modeling right away.

Diagramming Tool #1 – Visio (If You Have It)

The first diagramming tool is Visio. This is the one that’s used most predominantly by business analysts. Many organizations have licenses to Visio, which is why I wanted to bring it up first. It makes it a logical first choice for many of you.

While an individual license is not cheap, if your organization already has a license, it’s often easier to get access to it than to make the case for a separate investment in one of the other tools. It is relatively easy to use and there are a lot of online tutorials. It has out-of-the-box shape sets from many common modeling notations like UML and BPMN.

If you don’t already have access to it, it is one of the more pricey options. The last time I checked it was $589 US dollars for a professional license, but there is a 60 day free trial that you can download. If you are job searching and you see Visio coming up in your job descriptions, download that trial and get familiar with the tool. Otherwise, I’m going to share some more affordable tools that will serve your basic diagramming needs.

Diagramming Tool #2 – Gliffy

The second option is Gliffy. Gliffy is an online diagramming tool that allows you to create everything from basic workflow diagrams to BPMN and UML diagrams. It has out-of-the-box shapes from most of the common modeling needs. It costs $8 per month per user, and discounts are available if you pay for an entire year up front. There is a two week free trial. Gliffy was my go-to tool for a long time for everything except for wire frames.

Diagramming Tool #3 – LucidChart

My go-to tool these days is Lucidchart. I pay less than $100 a year for an online subscription. I’ve used it to create swimlane diagrams for our marketing processes and an entity relationship diagram for our ACBA registration information model, which I’m going to show you on the screen now. If you are not familiar with what an ERD is, this is a great example.

We also have a free sample that you can download by clicking below.

>> Download the Entity Relationships Diagram Sample <<

I also did a video tutorial on entity relationship diagrams that you can check out after this video.

Lucidchart has a free trial that allows you to create up to three editable models with up to 60 shapes. This is a great way to experiment with a visual modeling tool and not lose access to your diagrams after the free trial’s over. Either Gliffy or Lucidchart are really great ways to experiment with new modeling techniques, even if you don’t have Vizio.

And here’s the thing, when you are familiar with either of these tools, Vizio is not going to have that steep of a learning curve, as all the tools are relatively similar. It’s more about the conceptual understanding of how to put a diagram together. That is the thinking and the learning. The tool itself, is about finding where the right shapes are and making sure you know how to line up the lines and kind of put things together. But the tools themselves are relatively simple.

Diagramming Tool #4 – Balsamiq

Okay, so the fourth tool I want to talk to you about is Balsamiq. So Balsamiq is a rapid wire framing tool that captures the look of a hand drawn wire frame, but in an electronic format. Here I’m going to show you an example of a sample wire frame from our course materials showing the screen to log into a system. These hand drawn wire frames are effective because they don’t give the false impression that what’s behind the wire frame has already been implemented. One of the worst things that can happen as a business analyst is you show a really pretty user interface wire frame and people are like, great. It’s already built. Go make that happen. And you’re like, no, nothing works. Nothing’s clickable. But it looks so good. They think it’s already built when there’s a lot more structure in code that needs to be put in behind the scenes.

It’s also because it looks hand drawn, it’s easier for your stakeholders to provide feedback because it doesn’t yet seem complete. They’re not going to be like, “Oh, I don’t want to talk about this piece,” or have you move something because it’s very obvious that it’s a tentative or you’re throwing that out as a low fidelity or sort of a working model.

Within Balsamiq, there are several elements that you can drag and drop into your wire frame and like Gliffy, it’s online, so you don’t need to download any software. A single user license to Balsamiq starts at $9 a month and discounts are available for volume packs. They also have an extensive program offering for free versions to classrooms and open source projects and nonprofits. If you qualify for one of those, definitely reach out to them. They also have a 30 day free trial so that you can experiment with the tool and start to see how it works.

Diagramming Tool #5 – Axure

The fifth tool I wanted to share with you is a tool called Axure. So it’s been a long time since I used Axure, and so I’m not up to date on the latest functionality, but I just wanted to share it with you because it’s a totally different type of tool. It’s a prototyping tool that allows you to create wire frames, site maps, prototypes, click through prototypes, mobile prototypes, and flow diagrams. It allows somebody who does not have coding ability, who’s not a technologist, to create prototypes where stakeholders can actually click a button and see something functionally happen as a result.

I’ve had a lot of success using those sorts of click through prototypes to have stakeholders review and validate requirements that were diagramed that way. It does require additional work for you. It’s not as easy as putting together a Balsamiq wire frame. With even more work, you can integrate some data into that prototype as well. Then you’re getting really good end user feedback of how they would actually use the system.

It does come with a higher price tag because it has a lot more functionality. It starts at $25 a month. There’s also a 30 day free trial, so it’s something you can experiment with.

Diagramming Tool – BONUS! – SmartArt in Microsoft Office

And then finally, last but not least, I wanted to share about Smart Art in Microsoft Office.

Smart Art is a built-in feature for Microsoft Word, Excel, and PowerPoint. You can use it to create simple process flows or images that represent the pros and cons of a decision. You can show hierarchies and relationships of information. I have used it to create really clunky looking wire frames of how a screen might look in a PowerPoint slide.

There are ways you can use it to show information and incorporate information into simple diagrams that you might include in your scope document or a slide deck. It is not the most efficient way to create models, but it is an option. We’ve had course participants create workflow diagrams using the out-of-the-box shapes in Microsoft Word. And so it’s a great way to practice modeling, learn that tool set, and put something together electronically to share with your stakeholders even if you don’t have access or want to bother with any of the tools mentioned above.

What Will Your Diagramming Toolset Be?

So my question for you is, what will your tool diagramming tool set look like?

The tools we’ve covered in this video are simple and for the most part, relatively affordable and accessible. With one or two of them, you’re going to be able to create everything you need as a business analyst. But remember, the most important thing is to know how to leverage those visual models to clarify business processes, to get users on the same page about software requirements, to model your data and information appropriately.

To help you get started with visual modeling, we’ve created a free entity relationship diagram sample download that will give you an idea of how these diagrams can be used to represent complex relationships between entities. You can claim your free download by clicking below. However, remember diagramming tools are just one piece of the puzzle. To excel as a business analyst, it’s essential to know how to leverage visual models to clarify business processes and software requirements.

>> Download the Entity Relationships Diagram Sample <<

One of the must know models for the business analyst is the process flow diagram. We have an entire video on how to create a process flow diagram. If you click the video on screen now, I’ll see you over there.

While it’s important that a business analyst has a conceptual technical understanding as it helps you analyze the problem to be solved and communicate with technical stakeholders, you don’t need to be able to write code or run database queries.

In this video, I share the technical skills you do need to know and how they will help you position yourself more strongly in the job market and hold up your side of the conversation with developers.

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

Today we’re here to answer a question from Monica. She asked, “What are the top three to five technical skills a business analyst with a business background needs to have?” Specifically, she asked this around wanting to be able to make sure she could have good conversations with the technical people on her project teams.

Here’s the thing about technical skills in BA jobs – you’ve heard me say it before and you’re going to hear me say it again – you see them as job requirements a lot of times in business analyst roles. And a lot of times those requirements are extremely misleading.

You can, of course, to become more technically minded as a business analyst, learn how to write code. You could go take an introduction to programming and a sequel course and learn a bunch of technical skills that you may never, ever want to use in your career. You could do that. Or you could learn some requirements models that allow you to have those very productive communications and conversations with technical professionals and understand more about how the technology is structured and give you insight into what questions to ask than the technical skills, themselves, actually do.

What I’m going to talk about here, in terms of technical skills, are three requirements models or three types of requirements models that you might want to look at if you feel that you’re not “technical” enough to be a business analyst. I will finish with one closing bonus skill that might catch you by surprise.

Let’s talk about these three models.

Technical Skill 1: Use Cases for Functional Requirements

The first is use cases. Use cases are a textual description of how a business user or a user of a software application interacts with a software system. They force you to get really specific about what function or feature that system needs to have in order to meet the business needs. Underlying that feature is often a piece of code that a developer has created, customized, or integrated to make that function work.

But what you need to be able to specify as a business analyst is what that software needs to do, and the condition under which it needs to do it. A use case is the perfect model to get familiar with that business user system interaction. It’s much more detailed than a typical business process model, and it’s much more specific. You get into those specific technical requirements even though you don’t know how to write the code that underlies it.

Technical Skill 2: Wireframes for Visual Requirements

The second requirements model that can be helpful in expressing technical requirements like this is wireframes. Wireframes are visual descriptions, or visual renderings, of a user interface screen. Essentially, when I go to a software application as a user, what does it look like to me?

Not, specifically, what are the colors, what are the buttons, and how are they; circle or square? That is important at a certain point of a project, but a wireframe can be much less specific than that. It can use general buttons and not be specific on colors. Use grayscale. You’re trying to show this is what the user interface screen might look like to a potential user.

Again, you’re getting to that level of detail of what that software system needs to be able to do and look like, again, without having to write the code behind it. There are a lot of tools today that people, like me, who don’t have coding backgrounds, are able to use that just drag and drop those features into a wireframing tool so you can create them without having to know how to code.

Technical Skill 3: Data Models for Data Requirements

The third set of models are data models, such as entity relationship diagrams, system context diagrams, data flow diagrams, data dictionaries. There are a bunch of different models included in the data modeling area.

Essentially, all those models allow you to understand how the database is structured, how information is stored, what information needs to be stored. So, if you’re looking at a business process and there are different fields on a form coming in through some sort of an input:

• How is that information stored in your software system?
• What are the rules that need to be applied when that information is stored?
• How do the different pieces of information that come in through different business processes, how do those relate together?

Different data models allow you to look at that information model in different ways. This is how you, essentially, learn how to model a relational database or express data requirements without knowing SQL.

A not very well-kept secret is that I’ve never learned how to write SQL. I did learn how to do a little bit of coding in a very proprietary database language that was very specific at the very beginning of my career, but I’ve never learned SQL. I’ve never used that skill to move forward as a business analyst. I’ve done a lot of work with data requirements and data modeling and helped a lot of teams figure out what those data requirements and databases should look like by using some of the core data modeling skills.

And One Bonus Technical Skill…Asking Questions

I promised you one bonus.  Our three models are use cases, wireframes, and data models. What’s that bonus skill? The bonus skill is something that you’re probably already good at if you’re a business analyst, and that’s the ability to ask questions.

When it comes to technical questions, it’s like the ability to ask that question that you really feel like you should know. You should know the answer to this and you don’t. It’s asking questions about how things are organized, what are the capabilities of the technology, what are things that you might not think of. You’re using that so you can understand the possibilities of the technology and how the system is designed without knowing how to do it yourself.

In my experience, you could spend a lot of time learning how to build these systems and write code. That could have a measurable impact on your career. Or, you could spend time learning these core skills that you’re going to use forever in your life-long career as a business analyst.

They’re going to give you a more advanced level of understanding of the potentials of technology than you would get from learning how to line-by-line create the code because they’re going to enable you to work in any sort of situation as opposed to just the coding language that maybe you learned. There are dozens of coding languages out there, dozens of different technical environments. So, you’re never going to become the expert on all of them unless you want to be the expert and the doer of that kind of thing. If you’re a business analyst, I’m assuming you probably don’t.

Again, use cases, wireframes, data models, and having the courage to ask questions and get the answers to those questions so that you really have a good technical understanding in your environment. Those, to me, are the skills that you need to succeed as a business analyst with a business background in today’s technical environment. They will take you far as a business analyst without getting you lost in the weeds of learning specific technical coding skills.

>>How to learn these key technical business analyst skills

When you join The Business Analyst Blueprint® training program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

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

Are you unsure if your skills qualify you as a subject matter expert or a business analyst?

If you have proven yourself as a subject matter expert, a career as a business analyst could be a great next step for you and allow you to break into more interesting project work to steward lasting changes in your organization.

In this video, I’m sharing the difference between a business analyst and a subject matter expert and how you can potentially move from one to the other.

If you are interested in learning more about what it looks like to be a business analyst, you can sign up for our completely free workshop, Quick Start to Success, where you will:

• Get specific action steps to advance your career.
• Receive immediate access to the self-paced online workshop.
• Discover how to be more effective on any project.

>> Sign up for our FREE Quick Start to Success Workshop today! <<

Are you exploring job roles and wondering about the difference between being a business analyst and being a subject matter expert? Are you possibly a subject matter expert and wondering if you could actually be a business analyst or vice versa? A career as a business analyst can provide opportunities to somebody who has proven themselves in a subject matter expert role and can help you break into more interesting project work and have the opportunity to steward lasting changes in your organization. So keep watching to learn the differences between these two roles and how you can potentially move from one to the other.

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 on business analysis tips and techniques.

The Subject Matter Expert Role

The subject matter expert. Those are individuals who possess in depth knowledge and expertise in a specific industry or field. They are often considered the go-to person for information and advice on a particular topic. On a typical project, the business analyst will engage with many subject matter experts to understand the current business process and how the software solution that exists today is supporting that business process.

The SME, or subject matter expert, may also provide input into the challenges that they’re facing with their current processes and the solutions that are in place, and they may advocate for specific changes that they want to have put in place to support them in their department. The SME may also take on a leadership role with their department throughout the project training other department members on the new processes and technology and being the facilitator of change within their team.

Now what is the business analyst role? And we’ll talk about the business analyst role and then we’ll talk about the differences between the two and how to move back and forth.

The Business Analyst Role

Business analysts, on the other hand, are professionals who help organizations identify and solve problems. They analyze data and use various tools and methodologies to identify areas for improvement and to make recommendations for changes. At Bridging the Gap, we help business analysts who literally “bridge the gap” between business and technology stakeholders. This means they help ensure that the software solutions actually do what the business needs them to do and solve real business problems.

A business analyst doing this kind of work would use a technique like business process analysis to understand that business workflow and the problem to be solved. They would use use cases, wireframes, and user stories to analyze and define the software or functional requirements.

They would also use a variety of data modeling techniques to define how information is stored and flows through all the various software systems. This type of business analyst starts out a project by defining the needs or outcomes, takes it through to scope, defining the detailed requirements and collaborating with the business and technology teams to ensure a successful implementation of the requirements.

How Business Analysts and Subject Matter Experts Work Together

Now, how do these two roles work together? As a business analyst, you are going to work really closely with your subject matter experts across multiple departments to discover, analyze, and validate those requirements.

• The business analyst is typically responsible for leading the entire business analysis process for preparing requirements documentation, and managing change.
• The subject matter expert would review those requirements and may have a role in validating and approving the requirements documentation. They also provide a lot of input into the early stages of when the business analyst is gathering information about how processes work and how the systems work today.

It’s not uncommon, as a business analyst, to include a subject matter expert or many of them in your weekly meetings so that they are current on where the project is, and then maybe meet with them through one-on-one sessions to validate documentation and answer any questions that they might have about what’s coming.

SMEs provide incredible value to business analysts. I can’t emphasize this enough. Because they can provide in-depth information about how a department or a process works and can often bring up subtle nuances that a business analyst might not be aware of if they were not also a subject matter expert in that particular domain.

Many Business Analysts Get Their Start as Subject Matter Experts

As you grow in your business analyst career, you might start by being that expert in that domain. But as you grow, it’s important to grow into new areas. You need to be able to work with SMEs to kind of gain on the project expertise, so to speak. This is why many business analysts get their start as subject matter experts. Because you have a detailed understanding of the current business processes and systems, and it’s common as an SME to move into a more formal business analyst role.

In fact, many business analysts report falling in to a business analyst role after being assigned as a subject matter expert to a major IT project. Usually these are those big system migration projects, like moving from one accounting system or one customer management system to another, and you have a big role that takes up a significant amount of time and kind of co-ops your responsibilities for a while. In these cases, the role of SME and business analysts can get a little bit blurred, especially if you’re in an organization that does not have a formal business analyst practice, which is still common today.

Over time, the SME may become like the go-to person for the tech team when they have questions about the process or requirements. They might take on leadership and change management roles within their department and kind of be more of a liaison to the tech team than the doer within their department that got them into that role in the first place.

Also many business analyst job roles require specialized expertise in a business process and solution area. And that further creates confusion between these two roles. But there are some really key differences between a business analyst and a subject matter expert.

Key Differences Between a Business Analyst and Subject Matter Expert

While SMEs tend to focus on their field of expertise, their domain, the work that they do within the company, or have historically done within the company, a business analyst will focus on the organization or project as a whole and the role of the business analyst, as we’ve discussed. SMEs are often contributors to projects and might be brought in for their input, for reviews, for problem solving on a temporary basis during a project. The business analysts own that requirements process for the entire project, which may impact multiple different departments and have multiple different subject matter experts, and then typically fulfill that business analyst’s role. That is their full-time role or their contribution to the company.

Another difference is that once the project is done, the SME would typically go back to their “regular job” using the systems or executing the processes that have been defined. The business analyst will go on to work on a different project or initiative as a business analyst.

Moving From SME to Business Analyst

If you are an SME, or subject matter expert, and you’re looking to move into the business analyst role, here are a few quick tips that can help you get started. And these come right from my book, How to Start a Business Analyst Career. There’s a whole section in here on how to move from a business focused role into more of a business analyst role. And for those of you who might be techies, there’s also a whole section on how to move from a more technical focused role to a business analyst role because we see people come from both of those backgrounds.

So just a few of the things that I share in the book are to share your career intentions with the business analyst you work with, and offer to support them in business analysis activities, like capturing meeting notes, documenting requirements, or updating their requirements or engaging with your department. Just, “Anything I can do to help, just let me know. I’d be happy to support you.”

Also we’ll be looking at starting to analyze your department’s processes, even if this is not needed for an active project. Look for opportunities to analyze, document, and then improve the business processes. You could often do business process work outside of a project with no software improvement aspect.

Often significant improvements do come through software, but you could take ownership of what can we do just within our department in terms of how we work with other departments and how we are efficient with the tools that we have. So you don’t need to “get IT involved” to start doing business analysis.

A third opportunity is to lead a project in your department from beginning to end. And one other thing I want to add here is to look for opportunities to be outside your department because your ability to be successful as a business analyst is going to come from your subject matter expertise at first, but also your ability to understand the bigger picture of what’s happening in your organization and be able to represent other departments that you aren’t necessarily an expert in and at least understanding how your work within your department affects other departments and how that flow works is a first step. But really gaining any exposure outside your area of the company will be a great step just to having that more global perspective that will make you a great business analyst.

Start YOUR Path to Success

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

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

Imagine being able to expand your thinking, create draft documentation with ease, and streamline your work as a business analyst.

This is all possible with ChatGPT, and despite the industry-wide fear of AI replacing business analysts, I think a better question is “how can we use these tools to increase our efficiency and effectiveness as a business analyst?”

In this video, I’m sharing how to use these tools to expand our thinking and make our job as business analysts way easier!

I share my experience creating a Use Case with ChatGPT, in the video, which includes many of the same sections that we have in our free Use Case Template, but not all.

You can download our Use Case Template for FREE. The best part is that when you learn to analyze requirements in use cases, you can look like the smartest person in the room by avoiding these common challenges:

• Validating that the use case reflects true end user needs.
• Describing system and user steps at the right level of detail.
• Ensuring your software requirements are clear and complete

>> DOWNLOAD FREE USE CASE TEMPLATE <<

You’ve likely heard about open AI and, specifically, the currently free tool Chat GPT. Imagine being able to expand your thinking, create draft requirements documentation with ease, and streamline your work as a business analyst. This is all possible with this tool, Chat GPT, despite the industry wide fear of AI and artificial intelligence somehow replacing business analysts.

I think a better question is,

“How can we use these tools to increase our efficiency and our effectiveness as business analysts?”

There’s immense potential for these tools to expand our thinking and make our jobs easier. If that’s sounds like something that you’d like to do, just stick with me and I’ll show you exactly how to do that.

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 on business analysis tips and techniques.

About OpenAI and ChatGPT

Chat GPT was originally released back in June 2020, which feels like a lifetime ago at this point. It was an open source language model developed by Open AI. Open AI is a for-profit AI research laboratory. I think that’s just a really important piece of context to keep in mind. Sometimes when free tools are available, it can just feel like they’re from non-profits or sponsored by the government or whatever. But this is a for-profit company that’s released this tool for, most likely, a limited as a free resource to the community, and it’s in an exploration stage with how that tool is going to become part of its business model.

In November 2022, specifically, this is when the GPT Chat bot was launched as a prototype, and that is when it enabled anyone to register for a free account and start using the tool with natural language chats. As of this recording, in February 2023, Open AI has announced making a version of this tool available for $20 a month that would provide more guaranteed access. Sometimes when you go today, it’s like our systems are too busy because everybody’s using this tool to help be more efficient in their work. So that subscription, as I understand it, would enable you to have VIP or primary access to the tool.

It’s clear this is just the beginning. The current tool and AI generally, these are powerful resources for us as business analysts to use. From everything from drafting requirements models, to brainstorming questions to ask your stakeholders. I’m going to show you how to do that. So, let’s go ahead and see how this could be used to draft a use case.

Example: Using ChatGPT to Draft a Use Case

I am going to type in the question here, “Please draft a use case titled Combine Accounts.” And then we get to wait for a moment, and here you go.

One of the things, while it’s generating this response that I want to share is that one of the limitations of this tool is it’s using information from pre-2022, and it’s compiled that together, and as it’s doing this, my understanding is it’s creating unique content from the available information. It’s being written and regenerated in real time, always using a different perspective. I did this before, as a test, before I did this video, and this use case now is different than that one that was generated before.

So let’s just take a look at what’s going on here.

There’s a description. The combined and accounts use case allows users to merge multiple separate accounts into a single account. Makes perfect sense. This is useful for individuals who have created multiple accounts over time and would like to streamline their account information.

We’ve got the actors, the pre-conditions, some user system interactions that seem to make pretty good sense, prompts the user to log in credentials, verifies those credentials. That’s interesting.

I would often put “login” as a separate use case. That’s kind of typically considered a best practice, that a pre-condition would be the user being logged in versus how they have it here. A user logging in, you know, has their credentials. There are different nuances on how different people handle use cases, but typically a pre-condition is something that the system can actually verify. The system can’t verify that the user actually has their login credentials.

The spin on the use case here is maybe slightly different than a typical use case that I personally would write. Some of that is personal organizational preference, though. Just throwing that out there.

Then there are some really good steps here. The system merges those selected accounts. But again, it’s kind of missing those details. As an individual writing this use case for your organization, you will need to figure out what are those details, often through a data map, that need to be merged and what overwrites what? What’s the primary account? There are some business rules that are specific to your organization that you’ll need to fill in. And then finally the user logs out. Again, I would put that as a separate use case. But some of that stuff is preference.

Let’s look at what we are receiving here, because this is a really great draft. If you were sitting down and were like, “Oh my goodness, we have this feature to combine accounts. I have no idea what I should be doing.” This would be a great way to give yourself a start and to start thinking about it. But again, we can see your critical ability, or thinking ability as a business analyst is still really important in making sure that this reflects what is used for your business.

One of the things I wanted to note, too, is this use case does include most of the sections that are available through our free use case template download.

Example: Using ChatGPT to Identify Requirements Questions

Okay, so let’s take this a bit deeper. This was a great draft of the use case. I could work with this as a starting point. I’m going to say, well, you know, I’m going into a stakeholder meeting. Can you please give me 10 questions I could ask a customer service representative? A very specific role in the organization, about this feature. This is another challenge that business analysts face. I’m going into this meeting and I know I’m supposed to have an agenda. I know I’m supposed to be asking questions. What questions should I be asking?

We actually have a whole product for this called our Requirements Discovery Checklist Pack. But I think it’d be great to use Chat GPT for this as well.

These are great questions. How do I combine my accounts? Is there a limit to the number of accounts I can merge? What happens to the information from the accounts that I discard? Can I undo an account merge once it’s complete? These are great, great questions to getting through to the root cause of the features and the full business rules. Let’s just take this yet another step deeper.

Example: Breaking Down a Use Case Into User Stories

What we teach in The Business Analyst Blueprint® training program is a strategy for extracting user stories from your use case. So your use case includes the big picture of that user system interaction and how the whole feature flows. The user stories might have specific parts of that feature that are going to get implemented in different development cycles.

Could you please, notice my politeness? I’m always like, “please.” I’m sure the machine does not really care, but it just still feels like the right thing to do, break this use case down into user stories? Here we’re getting those user stories. As a user I want to be able to do something. As a user with multiple accounts, I want to be able to combine my account so I can streamline my account information. Different user stories that are covering this whole feature of how do I combine accounts. The specific pieces that might be implemented piece by piece.

As an aside, there is a lot of debate about the difference between use cases and user stories. I share my perspective in this video.

Limitations of ChatGPT – And Why Business Analysts Are Still Critical

That is an overview of Chat GPT and kind of how it can work to improve our efficiency as a business analyst. I think it’s a great starting point here creating user stories. There’s quite a few. That’s a great starting point for us, and there are a lot of limitations as well.

One of them that I already mentioned, is it’s only data from pre through 2022. If there’s a new feature or a new capability or something that is relatively recent with your functionality, it’s not going to have the information, it’s not going to be training to use that kind of information to generate a response that would be meaningful for you.

It’s also really unable to determine what’s important and what’s not from a…there are no ethics in humanity involved in this. It is trained on the data set, so it is as good or as weak as the data set that it’s been given. This is a really important piece to keep in mind as we think about AI tools in general is like where’s the human ethics aspect of it? In this use case of combining accounts, that might not be very relevant, but in general, when we’re asking it questions, it is not going to bring through our norms of how we want to handle diversity and inclusion or how we want to be a proponent of social justice or other values that may be important to us or to our organizations. That is not going to come out through a data set or a generation like this. We really need to bring that to it.

It’s really unable to determine as well, what is important to your business and your stakeholders. We’re not mining information specific to your company and it’s definitely not helping you get your stakeholders aligned on what this feature should look like. It’s giving you a starting point, a set of questions to ask, and it’s not going to be specific to your business at all, although you could definitely drill in and say, like, if I’m running an insurance company, what would this merge account feature look like? And it will give you another version of that that would be much more specific to your domain.

The sense that I want to give you here is that AI, it’s a powerful tool. It’s an efficiency creating tool, but it’s not an end all and a be all. It’s going to give you a draft, it’s going to give you a starting point, but not your final product, and it’s not going to help you, it’s not going to create alignment and clarity among your stakeholder group.

The key message I want you to receive is there is no substitute for the thinking you do about the requirements and how they impact your business as a business analyst.

Limitations of ChatGPT – In Succeeding as a Business Analyst

Now, let’s just talk about, also, some of the limitations to you when it comes to succeeding as a business analyst. Because as you saw, I started to kind of pick apart exactly how that use case was structured. And so you need to know what a use case is, how to evaluate the results that were generated, what are best practices in terms of how your organization organizes use cases and functional requirements. And if you’re not already familiar with that or you need a refresher, I did a full video on what a use case is and how to write one, and you can watch that video below.

I’ve also found, often, that this tool will put me into a little bit of a spin. So I have used it to flush out outlines for videos on social media posts, and it gives me a lot of great ideas. Often, it gives me almost too many ideas. And so I need to do the work to filter out what’s really important from my audience and the point that I want to get across. And so just taking the outline as it is and copying and pasting it, or even allowing this tool to write an entire video script, it’s totally possible. But if I did that, it wouldn’t come across as me. It wouldn’t be the kind of content you’re used to getting from Bridging the Gap.

The same thing is true as you’re using it to draft requirements. It’s your starting point, but you need to really bring that flavor. And if it’s putting you in a spin and a bit of overwhelm, a lot of business analysts really struggle with imposter syndrome. And so seeing a tool create a draft of a document in seconds when it takes you hours the first time through, or hopefully within time you’re creating something like that within 20 to 30 minutes as a rough draft. It can be a real mind bender to see a tool just spit it out just like that.

It can also have a sense of authority of like the tool knows better than me. This tool, they put “login” in there. Why am I not doing that in my use case? Or, “Oh, this tool has it done this way and left out these sorts of details. Why am I not doing that?” You are still in control. You are still the authority. The tool is a resource to help you. It’s a really important mindset to keep in mind as you’re using a tool like this.

Just being aware that it could send you off on tangents that your business rationale and goals do not support. You want to be really careful that your use of Chat GPT doesn’t give you scope creep that your stakeholders aren’t even asking for. We already have that problem within our project. We don’t need more.

This is just a side note. This is where access to coaching and mentoring and training really remain critical for you and your mental game. In our programs, our instructors are still doing real live reviews of your actual work and documentation because we know how important that is in cultivating your competence. Having that kind of review cycle and that training cycle is still incredibly important.

The Future of AI Tools and How They Impact Business Analysts

With all of this said, I think it’s also important to remember these tools are still relatively new and we’re just starting to see the shimmer of their potential and how disruptive already this technology has been just in the last few months.

They are going to continue to expand and evolve. They’re going to continue to improve. They’re going to get better. We could see a future where these sorts of tools identify and merge duplicate requirements, show requirements conflicts for us automatically, and map the information resources of your organization to be used to identify requirements and project impacts. These tools can be a great thinking and analysis ability. Even that is just probably the beginning.

Given that these tools will continue to get smarter and will continue to increase in capability, how can you position yourself?

There’s no point, really, in being afraid of the tool or just trying to push it down or put your head in the sand, which honestly is what I was doing for probably the last few years. Instead, this is the time to dive in, embrace and learn how to leverage the tool set to increase your efficiency. Bring these ideas to your team and into your projects. Free up your time right here and now for the capabilities that are not replicated by machines. Those capabilities are your ability to build relationships, your ability to bring people together, creating alignment and clarity, gaining buy-in, ensuring the requirements you write actually meet the business objectives, and that your team can deliver them and that they achieve real business value.

How do You Use ChatGPT as a Business Analyst?

With anything, these tools are here to support us with the more limited sort of menial work of a business analyst so we can shift our energy and attention to the more meaningful aspects of our work. We are just beginning to see the power of these types of tools in terms of supporting our workflow.

If you have used Chat GPT in your workflow as a business analyst, I would love for you to drop me a comment below and let us know, how are you using this tool? How has it helped your effectiveness as a business analyst? What are your wins? What are your questions? What are your fears around it? Where are the places that you get stuck? Where has it helped you and where has it left you wanting more.

Remember, the tool has a lot of limitations, but there is also so much more to a use case than that AI generated version. Just like AI is not going to replace business analysts, its output won’t replace human insight, creativity, customized problem solving to the needs of your specific business. And you need to know why each section of that use case is important and how to think through it so you can validate that information with your stakeholders. That’s why our use case template is so valuable and will help you do just that.

>> DOWNLOAD FREE USE CASE TEMPLATE <<

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.

In this short video, you’ll discover a simple 4-step process to manage change requests so they don’t derail the success of your project.

My number one tip when it comes to change requests is: Manage change or it will manage you. Outside of the four tips I share in the video, I highly suggest a Change Request Form that you can use across your organization.

My go-to Change Request Form is included in the Business Analyst Template Toolkit, which is one of our most popular digital products. When you invest in the Business Analyst Template Toolkit, you’ll receive:

• All 12 templates fully annotated in Word or Excel format and fully usable and editable by you. Customize them to meet your organization’s unique needs and share them within your organization.
• All 12 corresponding work samples so you can see what a fully completed template really looks like. These work samples are direct from the Bridging the Gap Redesign Project – they are completely new and you’ll get a peek behind the scenes of our business model.
• A 10-page guidebook walking you through the business analyst approach to a project, what templates are useful in each phase, and how to use the Toolkit to increase your effectiveness as a business analyst.

>>Click here to learn more about the BA Template Toolkit<<

Do you find that unexpected changes just pop up and take your projects off course? Or has someone just requested a change for your project and you’re wondering what you should do with it? As a business analyst, you can make a huge difference in how change is managed and really save your teams a lot of rework while also neutralizing the negative energy that’s often associated with change.

Stay with me and I’m going to show you a four step process that you can use to do this.

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 analyst tips and techniques. If you’re not subscribed yet, make sure to do so and hit that notification bell so you can stay in the loop with all of our new videos.

Today, we’re discussing a simple four step process to manage change requests so they don’t derail the success of your project because we know you’ve put a lot into the success of your project to get to the point where you’re at now.

Step 1 – Determine the Scope of the Change

The very first step is to determine the scope of the change. A change request could be related to the business requirements, the stakeholder requirements, the functional requirements, the data requirements. Any aspect of the project. Or it could impact all of those aspects. Obviously that’s a much bigger change. Here you use all of your business analysis skills and elicitation, and analysis, and validating the scope of the change with your stakeholders.

Along with identifying what that change is, you’ll want to identify the benefit of making a change or the business need driving that change. So you ask, “Why?” Just like we do for new requirements, we do that for changes as well. This is going to help your change approval team determine whether or not the proposed change is really worth the effort.

Step 2 – Determine the Scope of Incorporating the Change

Step two is determining the scope of incorporating the change. But before that happens, before you get to the change approval team, you want to make sure you understand the scope of incorporating that change into the project. This typically means identifying the impact of the change on the technical design, possibly on the project schedule, putting together a high level implementation plan and determining the level of effort to make the change.

With this information in hand, I often will document in a change request form, so you can see all of it together. You will be able to articulate whether the change impacts the project, the budget, the schedule, the scope. What aspect does it impact? And by the way, my go-to Change Request Form is included in our business analyst template toolkit. It’s one of Bridging The Gap’s most popular digital download products.

Sometimes there are multiple options for incorporating the change. For example, one approach could be trade off, like including the change and letting go of a lower priority requirement so that we’re not impacting the schedule or the scope.

Another approach could involve delays to the schedule in an increased budget, but keep the original scope intact, plus the change. Often during this step, there’s at least one, if not multiple, business stakeholders who are involved in evaluating the tradeoffs and the solution approaches. The goal in this step is to present the information to your change approval team and what they need to make an informed decision about whether or not to approve the change.

Step 3 – Gain Approval or Rejection of the Change

Step three is gaining approval or rejection of the change. You have the scope of the change, you know why it’s being requested, you have information about what it will take to implement it, perhaps a few options. Again, you can use the change request form to present all of that information to your team.

One thing to keep in mind is that most organizations have various levels of approval. So hypothetically, a change requiring just an hour of work might just be approved by the project team or the business sponsor, or the development lead, whoever’s in charge of that team. Maybe a change requiring a week or more of work might be approved by a mid-level management team who can authorize changes that have minor impacts to other projects on your company’s roadmap.

A change to a primary business requirement requiring maybe a month or more of work might be approved at the executive level because it could have impacts on other organizational initiatives and the whole strategy for the year. While those are realistic, they’re really hypothetical examples. More mature organizations are going to have specific criteria in place outlining what stakeholder group can approve what kinds of changes. More informal organizations, quite honestly, will just figure this out as they go along. It’s often up to the business sponsor to decide who needs to be involved in approving this change if they don’t have the authority to do.

Step 4 – Communicate and Implement an Approved Change Request

Provided the change is approved, it’s time to act on the implementation plan and communicate the change throughout the project team. That’s step four, which is to communicate and implement that change request.

Once the change request is approved, the project team needs to be notified. Probably there are project deliverables that need to be updated. So consider not just your requirements documents. That’s an important piece, but it’s not the only piece. At this point you might have technical design documentation. You might have test plans, project schedules, training documentation, any business process documentation for the future state that you’ve already completed as well.

Often these updates are facilitated by a formal change notification process where the project manager, or the business analyst, notifies the project team of the change, and each document owner then incorporates the adjustments into their deliverables.

Manage Change or It Will Manage You!

My final tip is to manage change, or it will manage you.

Often change is thought of as like a dirty word in the project circles. The reality is that change happens for legitimate business reasons.

In today’s fast moving and competitive marketplace, it’s really unrealistic to expect stakeholders to have perfect knowledge of what they want or need to achieve the business objectives.

Yes, we want to avoid drastic changes that are not tied to business objectives. We don’t want to change just for the sake of change. But we also don’t want to do so at the expense of ignoring real opportunities to deliver more value for the organization. The most important thing is that a very informed decision is made about if and how to incorporate the changes, and that there’s a really clear communication with everyone involved about why that decision was made.

As a business analyst, you really have an opportunity here to elevate yourself and your role within the organization by taking initiative. Ensure that steps one and two are completed before a change is brought before a decision maker. Again, that change request template we include in our Business Analyst Template Toolkit is going to give you a structure for pulling this information together.

One last thing I’d like to note here is that changes are often more frequent when you jump right into analyzing the software requirements and not starting by analyzing the business process and understanding the problem to be solved first. There is a lot more to analyzing a business process and it’s a critical business analyst skill that can really set you apart and establish your credibility.

We’ve got several other videos on business process modeling, and I invite you to watch the one below.

>>Save Time Creating Your Change Management Form<<

For a starting point for approaching common business analyst work scenarios, such as managing change requests, check out the Business Analyst Template Toolkit. All of the requirements templates in the toolkit are fully annotated and editable by you, giving you a great starting point for starting your next business analyst project or formalizing your work samples.

>>Click here to learn more about the BA Template Toolkit<<

In this short video, you’ll discover:

• The definition of a To Be Business Process
• How to analyze a To Be Business Process
• Where to start in your analysis
• What type of collaboration to expect

Download Your Free Business Process Template

At Bridging the Gap, we are all about helping you succeed as a business analyst, no matter where you are in your career. That’s why we’ve created a Business Process Template you can download for FREE.

In this template, you will discover how to:

• Help business users from multiple departments clarify their actual step-by-step workflow
• Avoid wasting money on software solutions that don’t solve the right business problems
• Help new business analysts figure out what questions to ask when starting on a new project

> Click here to download <<

Now, Let’s Dive Into Mapping the “To Be” Business Process

Is your organization rolling out a new technology that impacts the business or developing a new product or service that your organization needs to figure out how to deliver? If so, as a business analyst, it’s your role to analyze the To-Be business process and help your stakeholders define exactly how work will flow once that new solution is in place.

Stay with me and I’ll share exactly how to do just that.

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 on business analysis tips and techniques.

Today we’re going to be discussing the To-Be business process and how business analysts can analyze different organizational processes to help improve the business operations and provide more clarity to all members of the organization.

Definition of a “To Be” Business Process

First, let’s start by defining what a To-Be process is. A To-Be business process defines the future state of a business process in an organization.

Typically, the analysis goal in putting together the future state process is to clarify how the business process will work at some point in the future once changes have been made in the organization. And those changes could be business changes or technology changes.

How to Analyze a “To Be” Business Process

So a To-Be business process contains all of the sections in a typical business process model – a description, a list of rules, a list of steps and exceptions, a process map, perhaps even some business rules. To get a rundown of these elements, you can download our business process template. It’s absolutely free.

When it comes to defining the future state, it’s really important for you, as the business analyst, to bring some structure to that business analysis process. Often these discussions can really start to go all over the place without a defined structure. When we’re talking about the To-Be, it’s like anything goes and conversations start to fly all over the map.

Getting ALL the Stakeholders Involved is Key to Success Process Definition

To start defining the To-Be process, you’ll want to start by involving all of the key stakeholders that are involved in the process today, or that you anticipate will be involved in the process in the future. You should have at least one stakeholder representing each functional area or role impacted by the process.

Most often it makes sense to start by analyzing the As-Is business process so that the entire team is aligned around the current state before defining the future state. I did a video recently on the As-Is business process that you can watch below.

If, today, your team is using a spreadsheet and email communication to manage a process and in the future we’re hoping to use a tool or some sort of software system, you want to get clear on how that flows first. How does the spreadsheet and email communication flow and who all is involved as a starting point so that you know exactly what to automate.

To Analyze a To Be Process, Start with Why

Next, you want to be clear on what problem you are trying to solve by updating the process.

• What is the “why” for the project?
• What’s the desired outcome?

For example, your sponsor may want to make the process more efficient, reduce errors, or take advantage of efficiencies created by new technology solutions that could automate all aspects of that process. With the right stakeholders involved, the current state understood, and your desired outcome or where you’re headed defined, it’s actually defined what this future state process is going to be.

Again, this is a collaborative effort between the business analyst and the stakeholders. As a business analyst, you never have all the answers. You can suggest ideas, you can propose solutions, but you really need to involve your stakeholders in the process of defining the process. It’s a little Meta.

If you are having trouble getting stakeholders engaged, here’s a video with a lot of tips on building stakeholder engagement.

To Discover the “To Be”, Use the “As Is” as a Starting Point

As a business analyst, you may want to bring in that As-Is business process documentation as a starting point or maybe even just the high level process map and mark it up with some suggestions and opportunities. This way everybody has something to start from. It helps keep the meeting focused on what the desired outcome is.

For a Truly Brand-New Process, Start with the Goals for the “To Be” Business Process

But if this is a completely new process, you would start by defining the beginning and the ending of the process.

What’s true when this process starts and what needs to be true when it’s done or complete?

That way you’re really clear on scope and then you can just start visually mapping out the steps in between.

Often you need to get to that fully fleshed out business process template. But you would start with a process map so you’re just looking at the high level and starting to map in those pieces in those steps. You can then rework it and move it around.

Often what happens, there’s a lot of rework and splitting apart and breaking things apart into multiple processes or combining them back together as you go through that process.

If you are looking for some tips on process maps, specifically, I also recently recorded a video on that topic, and I invite you to watch it.

Expect a Fair Amount of Collaboration When Analyzing a To Be Process, Including Technical Stakeholders

Now, one thing to note is if your To-Be process is heavily technology dependent, you may need to have a technical stakeholder available to explain how the technical system works and what opportunities there are, what the potential configurations are, and what’s really possible given the technology solutions you have.

This is not always just a business-focused activity. Often we need to have a technology expert as well. And this is why you will often see business analyst roles include some sort of technology requirements, like expertise in a specific software system, because they want you to be able to bring that expertise to the meetings as you meet with your business user.

But if you don’t have that expertise, you just need to bring it into your team by involving a technology stakeholder. Not your whole technology implementation team, but somebody who can speak to the possibilities of technology.

Your To Be Business Process Lays the Groundwork for Software or Functional Requirements

Now, you’ve completed the analysis of the future state, or the To-Be process when you, as the business analyst, have thought through all the implications of that future state, and your stakeholders have approved the updated documentation essentially saying, yes, this is how we want the process to work.

Then you are ready to define any software changes in terms of the functional requirements that are needed to support that To-Be process and start building organizational assets that will support the new process, like templates or training.

Analyzing functional requirements is an entirely separate topic, and here’s a video introducing the key concepts:

If all of this seems like too much, again, don’t worry, you don’t have to start from scratch. We have a free business process template that you can download today to help you get users from multiple departments on the same page about clarifying their desired workflow. This download can even help new business analysts figure out what questions to ask when starting on a new project or a new domain.

For more details on how to use this template to fully analyze a business process, check out this video for a complete tutorial:

In this short video, you’ll learn the definition of an As Is Business Process, as well as how and when to analyze an As Is Business Process.

The best news is that you don’t have to start from scratch. When you download our free Business Process Template, you can:

• Help business users from multiple departments clarify their actual step-by-step workflow
• Avoid wasting money on software solutions that don’t solve the right business problems
• Help new business analysts figure out what questions to ask when starting on a new project

Thousands of business analysts are already using this free template– add this tool to your toolbox today!

>> Click here to download <<

Are customers getting frustrated with your organization’s level of service? Are business users confused about what the right process is or what steps they should take in what situations? If so, as a business analyst, it’s your job to analyze the as-is business process and help everyone get on the same page. So stick with me and I’ll share exactly how to do just that.

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 on business analysis tips and techniques.

Today I’m discussing the As-Is business process and how business analysts can analyze different organizational processes to help improve business operations and really provide more clarity to all members of the organization.

Definition of an As Is Business Process

An As-Is business process defines the current state of the business process in an organization. Typically, the goal when putting something like this together is to clarify exactly how the business process works today, flaws and all. So mistakes, errors, redundancies, whatever that is.

How to Analyze an As Is Business Process

Now, the As-Is business process contains all of the elements of a typical business process model – the description, the list of roles, a list of steps, exceptions, and a workflow diagram or a process map. To get a rundown of all of these elements, you can download our free business process template.

And here’s a video with all the details on process mapping:

Now, when you’re putting together an As-Is process, access to the business stakeholders who perform the business process is key. Business analysis never happens in a vacuum. You need access to stakeholders so you can actually understand what they are doing.

Secondarily, access to business stakeholders who understand the process, such as a manager or a subject matter expert can be helpful as well even if those individuals don’t routinely perform the business process. Often they can provide another perspective on what the business process should do, and they might be really surprised to learn what is actually happening. So often it’s important to have people who are actually doing the process involved as well as management or people who have the idea of what the outcome of that business process should be, and how they believe it should be performed.

What’s really important, though, is that you’re going to need at least one stakeholder to represent each role in the process.

If you are having trouble getting stakeholders engaged, here’s a video with a lot of tips on building stakeholder engagement.

For example, for a process describing how a new customer gets set up, you might need a representative from sales, from customer service, and from fulfillment, maybe even accounting, if that’s part of the process as well. Once you determine who needs to be involved, you can elicit information about the current state using a variety of different methods. Interviews and observation tend to be the best elicitation techniques for understanding the current state and then you’re able to put a draft together and then review that or do a document review that can confirm your understanding and fill any knowledge gaps.

We’ve done a great video on elicitation, and I invite you to check it out if that’s something you want to learn more about.

When to Analyze the As Is Business Process

One of the most frequently asked questions we receive is whether or not you always have to do the As-Is. We’re actually going to improve this process. Can’t we just start with the future state or the to be or the desired state process?

I find that it almost always makes sense to start with the As-Is because this brings a lot of clarity and it gives your team a solid foundation to build from. There are some scenarios, though, where the As-Is is particularly necessary and I would say really a non-negotiable in your analysis process.

• For example, if there are known issues with the current state process such as order is not getting processed or customers being frustrated with your organization’s level of service. Often the clarity that comes from a good business process document is going to help you identify the gaps that are causing those issues in the first place. The analysis helps you define what your future state, or to be business process, should be.
• Also, if you find that business users are confused about what the current state process is or what steps to take in current situations, it makes sense to start with the As-Is so you can get everybody on the same page about what they should be doing currently. It avoids a lot of disagreements and confusion and back and forth discussions about trying to define a future state when we’re really not already on the same page about what we should be doing right now.
• Finally, if your organization wants to automate or streamline the current processes but, again, that current state is not well understood or documented, you need to start here. By analyzing the current state, you are going to discover redundant steps and opportunities for automation.

Here’s a Starting Point for Your As Is Business Process Mapping

If all of this seems like too much, don’t worry. You don’t have to start from scratch. We have a free business process template that you can download today and that will help you get business users from multiple departments on the same page and clarify their actual step-by-step workflow.

This download can even help new business analysts figure out what questions to ask when starting a new project or working in a new domain.

Click the image below to claim your free business process template.

There’s a lot more to mapping a business process, and I have another video that goes into this technique in more depth.

The cornerstone of a user story is a single statement in the following syntax:

“As a [user], I can [do something] so that [perceived benefit].”

Discover the benefits of user stories and how they fit into the BA workflow by watching the video below.

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about user stories and how to write user stories and be really effective with this technique as an agile business analyst.

User stories are a way of capturing requirements that is commonly used on an agile software development team or a team using the agile methodology of some sort.

Benefits of User Stories

There are some really key benefits to managing requirements with user stories.

First of all, when you’re using user stories to manage your requirements, you’re often organizing all of those stories into the product backlog. That allows you to rank prioritize the requirements, which is a very agile focused technique, as opposed to like a big document where everything is “priority one.” That rank priority makes it incredibly clear which requirements are the most important and most valuable to the business. You, as the business analyst are focusing on the most important requirements and the development team is also focusing on the most important requirements.

And now the other piece that I really love about user stories is the very syntax of how they’re written, which we’re going to go through in just a minute here, links each functional requirement to the anticipated business benefit, and that makes it much more difficult to just sort of add in or sneak in requirements in a big document or even in a use case. I love use cases, and we’re going to talk about how to incorporate those into your user story development process a little bit at the end.

What I have found when I only write use cases is they can get a bit bloated with extra steps and alternate flows and all kinds of exceptions, and all of a sudden something that seemed really simple becomes really complex and that becomes very obvious when you are breaking down the requirements from a use case into user stories because then you have to prioritize each of those independently.

And then the final thing I really love about user stories is that they create this powerful link between your requirements work and your development work which helps us, again, guard against unnecessary scope creep, or projects that really become more intensive without actually creating more value. That’s a great position to be in as a business analyst, making sure you’re paying attention to value.

User Stories Defined

So what is a user story? The cornerstone of a user story is a single statement in the following syntax. As a user, I can do something so that whatever that perceived benefit is of that feature. And then you include whatever accompanying details or supplemental materials you need to make the user story clear and implementable.

Often these are detailed in acceptance criteria or the conditions the software must satisfy to be accepted by a user, a customer or a stakeholder.

An Example User Story

Let’s go ahead and look at an actual example, which I think will make this much clearer.

This is an example that we include with our use cases and wireframes module of The Business Analyst Blueprint training program®.

As you can see up here, the title for this is The Username Doesn’t Exist. This is a component of a bigger use case that would be logging into the system. That use case has multiple different features and exceptions and alternates. This is just one little piece of that. What happens if the user tries to log in and that username does not exist in the system? Up here we have a, as a user. I can be notified that the username I provided does not exist so that I can provide a different username or try to log in again.

Here we have our different acceptance criteria. They’re written in this given when/then format. So given this happens, then this happens. Given this happens, then this happens.

Now what we’ve also included here is a wireframe. And what I have found as a business analyst, it’s often really helpful to have not just the acceptance criteria detailed out in words, but to have some sort of supporting documentation. In this case, the wireframe made the most sense. Other times it might be a workflow diagram. It might be the use case that this user story is a part of. It might be a data model, if it’s data intensive. It could be a data dictionary or a glossary of terms, or an ERD, like a piece of the ERD. Those are all examples of what you could include as supporting documentation. In this case, we have a wireframe.

So that’s an important piece to keep in mind. There’s some specificity to user stories, like guidelines, and how to create them. But I think there’s also a lot of judgment as a business analyst of what actually is going to communicate these requirements in the most effective way to my software development community.

Wireframes are super common. Here’s a video explaining how to create a wireframe if you want more detail on this business analysis technique:

How User Stories Fit into the Business Analysis Workflow

I think another thing that we really need to keep our mind wrapped around is how these user stories fit into our workflow as business analyst.

One area that often gets overlooked in agile circles, even still today, is how the development of the user stories fits into a business analyst process framework.

If you aren’t familiar with what a business analysis process framework can look like, here’s a video tutorial on that:

Agile is a Software Development Process, Not a Business Analysis Process.

Agile is a software development process. It is not a business analysis process.

Most agile methodologies, whether they explicitly do this or not, there’s some sort of assumption built in that the details of what goes into a user story are fairly well known or easy to figure out, and just a matter of the business analyst sitting down with a user and really figuring that out and having one quick conversation with them.

The reality is that often as a business analyst:

• You need to be collaborating with multiple stakeholder groups to rank and prioritize and estimate those user stories.
• You might need to gather information from multiple different stakeholders groups to build out that acceptance criteria or to gain alignment on what the software actually needs to do.
• You might need to dig in and figure out what the business process is before you even start defining what those software requirements are.

There could be a lot of background kind of upfront work that even though we want to be more agile, we also want to be thinking things through.

As a business analyst, when I’m on an agile team, I’ve found it a good practice to work ahead at least by one or two sprints, and that’s if things are relatively simple.

If you’re dealing with something much more complex where there’s a big business process focus, you might need to work even further ahead than that kind of doing some of that business process work before you get into the sprint part of the development process.

What that means is that I’m always prioritizing the product backlog that will be developed in the next month or two. That gives me time to refine those requirements, to get all the necessary stakeholders on the same page about those requirements, and to detail out those acceptance criteria so when we go into sprint planning, I’m ready with the good draft of what the requirements are for this user story, and then we can have dialogue with the technical team. I can go back and clarify things if I need to or add to them or supplement them.

But I’m not doing the heavy lifting of getting all the stakeholders on the same page while the developers are trying to build that feature. I’ve done that before under the pressure of agile. What happened is we built one thing and had to change it and build it again and nobody was happy, especially me, especially the developers as well. .

When Focused on User Stories, It’s Easy to Lose Track of the Big Picture

The other thing I want to say is that when we are focused on these little user stories, especially like that example of “the username doesn’t exist,” it’s a little tiny piece of functionality. It is really easy to lose track of the big picture. And when you lose track of the big picture, it’s common to miss requirements because you’re focused on this one little piece. As a business analyst, you need other techniques to maintain a view of this big picture.

What we teach at business at Bridging the Gap is use cases because we find that use case thinking and the semantics and the logic of a use case helps business analysts uncover otherwise missed requirements. And if you are a great agile business analyst, you’re like, “Laura, I write user stories all the time. I don’t ever write use cases,” that is totally possible. I’ve done that too, but it’s because I had that use case thinking background in my head and I was thinking through the use cases, even though I wasn’t writing the use cases and I was using that use case thinking to hold together and think through how all these user stories fit together.

And so it might be that use cases or use case thinking has become so intuitive to you by now that you don’t actually have to write the use cases if you’re new and struggling with how to make sense of this big glob of user stories that you might have on your plate. You might want to actually put them together into a use case or a business process model, or a process map, or a workflow diagram to help you think through that bigger picture view before you dive into each individual story.

Download our Use Case Template

If you’d like to go further on the use cases specifically, I do have a free template for you that you can use to walk through with some guiding text. It’s absolutely free. You can just use that link below.

And again, that technique is going to help you avoid missed requirements and think through the big picture of how your user stories fit together.

Again, user stories are an incredibly important technique. We need to know them as business analysts, especially if we’re working on agile teams. Mastering use case thinking is going to make you a stronger business analyst who can weave those user stories together in a meaningful way to ensure that the team delivers a solution that’s truly valuable to the business.

Again, my use case template is available through that link below. We’d love to help you take the next step with this skill in your career.

I’m Laura Brandenburg with Bridging the Gap and we build our profession one business analyst at a time. Success starts with you. Thanks for being here.

<<Click here to download free template>>

Use Cases Are One Way to Analyze the Functional Requirements

If you are looking for more guidance on use cases, here’s a video tutorial to go through:

Use Cases and User Stories Can Work Together

You can also learn about how use cases and user stories can work together here:

One of the great things about process mapping is that they are often intuitively understood by our stakeholders. They are also extremely powerful communication tools because they allow us to get great feedback on the process early in the requirements process.

Discover the 7 Steps to Diagram a Workflow or Process Map in the video below.

Process Map Defined

I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about how to draw a process map in seven steps.

A process map is a visual model that shows how a collection of activities are sequenced together to accomplish work in an organization. Super simple. Other terms for a process map are process flow diagrams, workflow diagrams, swim lane diagrams, or simply a process flow, or simply a process map. Lots of different terminology often referring to the same exact technique that I’m going to show you an example of today.

Benefits of Drawing a Process Map

Now, one of the great things about process maps is they are often really intuitively understood by our stakeholders. They’re relatively easy technique to pick up as a business analyst as well, and they are super powerful communication tools.

They allow us to get feedback, really impactful feedback early in the process and before we start writing software requirements, which makes that process go so much more smoothly and easier.

They are also a really strategic technique that helps us as a business analyst discover their true problem to be solved before we dig into the details of what the software really needs to do to support the business. If you’ve been feeling like you’re kind of cut out of that early phase of the process, or not really understanding why the software or why the requirements are what they are, a great technique to pull out of your toolbox is this process map or a business process model.

7 Steps to Creating a Business Process Map

Let’s talk about the seven steps to create a process map or to draw a process map.

Step 1 – Identify the process you are mapping

Now, the first is to actually identify a process. A process captures any repeatable set of steps. It is different from a project in that a project is a set of work that needs to be completed a single time to achieve a specific result.

A process is repeatable. Look for work or activities that happen again in your organization or are a part of the repeatable work related to the software that you might be identifying requirements for. Identify what that process is.

Step 2 – Name the process map

And then you want to give it a name. This might seem like, “Laura, let’s just get to the visual modeling and start drawing it out.” That is step five. We have a little bit of pre-work to do here because I find that the pre-work really helps you get clear on what that process is and makes the visual modeling part go a lot easier. Naming your process is really important.

We teach, in our online business analysis training at Bridging the Gap, to start with a verb. So it would be, “Collect past due payments,” versus “The past due process.”

When you start with a verb, it’s much more clear and specific. I see a lot of times we see in our program participants really want to just use a broad name like, “The email management process,” or “The collections process.” But, as we’ll see in the next step, that leads to all kinds of problems and is really too vague to give you a crystal clear idea of what that process is.

Step 3 – Identify a clear start point and end point for your process

The next way to get clear on what the process is, is to identify the starting point and the ending point for the process. The most commons mistake we see in participant deliverables is that they don’t have a clear starting or ending point.

(If you’d like YOUR work to get this kind of official review, check out our flagship offering – The Business Analyst Blueprint training program.)

Visually, this leads to models that have boxes off to the side and are not integrated into the process map. So ask yourself:

• What’s the very first thing that needs to happen or the very first activity that needs to happen and what must be true before the process can start?
• And then what’s the last activity that happens? Or what signals that the process is complete?

This creates your container, your scope, what this process is.

Step 4 – Identify your purpose for the process map

And then the final piece of pre-work that you want to do is really consider what your purpose is for creating this process map.

• Are you trying to show a lot of opportunities to a high level stakeholder group?
• Are you trying to get really specific and granular with a specific team of business stakeholders?
• Is this something that will eventually be shown to your software development team as context for why they’re doing the requirements or implementing the requirements, specific requirements?

Once you understand that purpose, it’s going to help you know what level of detail to get into because you can do these process maps at various levels of detail that will give you a different view into either a really big picture process or a more specific, almost procedural level process.

Getting clear on your purpose will help drive better stakeholder engagement, which is critical to getting the details we’re going to go into next. Here’s a video with lots of tips on stakeholder engagement:

Step 5 – List or draw out a series of steps in a process map format

With that context, we are on to step five, which is to actually draw your process map. I’m going to go ahead and share an example with you because pictures speak louder than words here. What we have here is just a simple workflow diagram. This is done using swim lanes, which is a great technique to make it really clear who is doing what.

You’ll see each of these swim lanes here has a role. Contributor, communications manager, reader. That makes it really clear who’s doing what. If you’re not using swim lanes, then you need to include the clarity of who is doing what inside each of these boxes, which is your activity steps. Just using a rectangular box, really simple logic here. Simple, as often best, a lot of times is more complex, different shapes, different colors. They just confuse your model unless you are very clear and have a key for how to do them and what they mean. Here, we’re just very simple steps and no colors. It’s very clear. Each step or each box has an activity step. This would be the actual steps of your process.

Diamond is a decision diamond, so this means that there’s more than one outcome from that step. In this case, a yes answer leads to another decision diamond, a no answer leads to a specific step. That can help when there are alternative paths through your steps.

Then, finally, these little icons here are often used when there’s some sort of a creation of a document or a deliverable or an update to a database. I think the document is what they’re usually called in most tools.

And then, of course, you’ve got these arrows flowing all the way through. That is to show the flow and how the process actually flows and where it flows through.

Then the final thing I want to point out here are these activity boxes that have the little lines on them. That’s just a standard that’s used to actually represent a subprocess. That allows you to look at a high level view and to show that there’s way more detail behind this step that you’re not seeing here. You would have then a separate process flow diagram or a separate process map to show the steps in those sub processes. It just allows you to present certain information in certain ways. That’s, again, why it’s so important to know your purpose. Why are you creating this process map, and who is your audience?

Step 6 – Look for exceptions or rules to the process

You’re still not done. I’m going to go back and show that again because your next step here is to look for exceptions or rules. You might, at first, when you diagram this out, as I often recommend don’t get out a diagramming tool like this is built in, draw it out on paper. Because then you might say, well, does this step always happen the same way? And if not, that’s where you end up with these decision diagrams or decision diamonds. That, in this case, is this question answerable via a blog post? If yes, we send the blog post. If not, we do something else. We might consider it for a future blog post.

You want to look for those exceptions and those rules, and you want to ask your business stakeholders do things always happen this way? What tends to go wrong? And add that information to your model. Often it’s those exceptions and rules and alternative flows where the confusion happens. You can bring a lot of clarity, as a business analyst, by figuring out those rules and eliciting those rules from your stakeholders.

That’s step six.

Now, onto the final step. This is optional, but highly encouraged, is to create an accompanying textual business process model.

Step 7 – Why Process Maps Need Corresponding Textual Process Models

Process maps are great and they can help us get clear really quickly and kind of the overall scope of the process, but they often are not quite enough detail to fully understand a process. In our courses, we teach a corresponding textual model called the Business Process Template. We use that template and we teach that template and you can actually download that template completely for free using the link below. This helps you fully flesh out the business process to understand, to ensure that you are leveraging best practices in terminology, and that you’re actually structuring the language of each step. There’s a section in there for roles and responsibilities, so it’s really clear who was doing what.

You can upload and put your process flow or your process map into that template as part of it. It’s like the visual description of it, but the text just goes into a little bit more detail and covers some additional elements that really help bring a lot of clarity. This is really useful if you find yourself missing steps or overlooking key components of your process. Sometimes going into the textual model will help elicit that additional information and give you more questions to ask your business stakeholders to make sure that you’re really clarifying what their business process is.

Asking lots of questions is a key business analyst skill, whether you are analyzing a business process, functional requirements, or data mapping! But a lot of business analysts get stuck wondering what questions to ask. Here’s a video with a ton of guidance around figuring out what questions to ask.

So that’s it. Those are your seven steps.

And then to help you create process maps that truly improve project communication, that solve real business problems and help you move forward in your business analyst career. This is a technique that’s going to position you as a really strategic thinker and somebody who understands the business perspective, which is super, super important.

Again, feel free to download our business process template today. It’s completely complimentary.

Process maps are great because they help us get clear really quickly, but they’re often not fully detailed enough to truly understand that process. And you want to use a template like ours to get to those details.

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

Download Your Free Business Process Template

When you want to get analyzing a business process, download our Business Process template (it’s free). We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

You’ll discover the key elements that go into a business process model, and be able to kick-start your analysis of the business process.

>>Click here to download the Business Process Template<<

Learn More About Analyzing a Business Process

To dig deeper than a process map, and explore the full textual business process model, check out this video:

In this video, I am going to walk you through possible solutions, why we use them, and what kinds of requirements techniques are important for you as a business analyst.

Whether you are working with SAP, Microsoft SharePoint, Salesforce.com, Archer, Service Now, or another tool, these requirements will help you leverage these powerful tools to lead a successful project.

I’ll be sharing specific techniques for business process analysis, use cases, and data modeling, as well as success stories from our participants in The Business Analyst Blueprint training program.

COTS Requirements are Critical to Project Success

Hi, I’m Laura Brandenburg from Bridging The Gap, and today we’re going to talk about how to specify requirements for COTS and SaaS projects. COTS being commercial off the shelf, and SaaS being software as a service.

The vast majority of projects these days are delivered using some elements of these prebuilt solutions and it can feel like, well, do we really need requirements? Do we really need business analysts? I see a lot of projects going through our Blueprint program as well as through my work with my husband who implements Salesforce, and I can tell you that the projects that are successful still leverage business analysis capabilities and specific business analysis skills and techniques to make sure the requirements, the COTS requirements, are actually in place. Because many of these options are highly configurable and customizable. We need to do the work of figuring out even if we’re going to use the solution as is, how it fits within our business process and how we get data into it.

In this video, I’m going to walk you through what the solutions are, why we use them, and what kinds of requirements documentation are really important to pay attention to. It’s going to be a little bit of a longer video, most likely, because I want to walk you through these examples, give you some visuals so you can see what they are, as well as share some success stories from our program participants on how they’ve actually used these techniques on their projects, doing COTS and SaaS type requirements work.

Let me go ahead and share my slides.

COTS and SaaS Defined

Now, the first slide I want to bring, just to kind of revisit these actual definitions and make sure we’re clear. COTS is commercial off the shelf or a solution that’s usually deployed internally. It’s where you license a software or install a piece of software on either a centralized server within your organization or maybe on specific computers that employees are using.

SaaS is software as the service. That’s in the cloud. You are not actually hosting it as an organization. The service provider is hosting it. You might still have quite a few customization and configuration options depending on the solution.

Just to be really clear, the kinds of requirements you do from a process and functional requirements basis are very similar regardless of what kind of solution you’re using. You don’t really have to worry too much about that from a functional perspective as a BA.

Examples of COTS and SaaS Systems

What are some examples of these types of systems? We’ve got SAP, Microsoft SharePoint. Salesforce.com is huge. Lately, we’ve seen a ton of people come through the Blueprint program, The Business Analyst Blueprint – our business analyst training program –  and work on Salesforce.com projects and go on to become experts in Salesforce business analysis. I’m going to share a couple of their stories.

And then Archer is another one. We’ve got document management tools. We’ve got ServiceNow. I’m going to share an example of that. All these types of tools are, software as a service or COTS tools, and they all need requirements if you’re going to implement them successfully at your company.

One example I want to give you from my career where this didn’t work, it actually was a project I came into after the fact as a business analyst, was a document management system. They had implemented this document management system, just kind of put it in place, and the whole goal of the project was to reduce the amount of paper used and make the process more efficient.

The users at this other location hadn’t been trained on how to use it. Their workflow hadn’t been well understood, so they were given a solution that they didn’t think worked for them. And instead of printing a document once and then kind of handing it around the office using their old workflow, they were actually printing it and uploading it multiple times at each step of the workflow. It was more labor intensive and used more paper. It was actually a negative return on investment. That’s what happens if you just put a tool in place and don’t actually understand what your business process is or how to use that tool successfully within your organization.

COTS Requirements: Business Process Analysis

Let’s just share the first technique that’s really critically important, and that’s a business process or a business process flow diagram.

You need to understand how the business works today. It might be using spreadsheets; it might be a paper process. It might be using another system that you’re migrating away. You need to understand how that process works so that you can understand how it’s going to work using your new system. There tends to be a lot of flexibility right in how those solutions work, so you really need to understand what that process is so you can figure out what you need to implement.

You also need to understand the constraints of the software so that sometimes it’s actually easier to adjust or tweak the business process versus adjust and tweak the software. It gives you a more maintainable system with more longevity. You might need to understand how the software works so that you can adjust the business process, and your to be process actually changes to work better with the software that you’re implementing. Either way, you just need to understand what that business process is. And a process flow diagram like this one is, is really important as well as a detailed process textual template.

I’ll leave a link below for our free template that you can use to articulate your business process. We also have videos on that technique as well as creating a process map like this one. There are other videos here that you can check out as well.

Now as an example of this, Manuel Ninapaitan was in QA work when he joined our Business Analyst Blueprint program. And he was specifically doing QA work using an application called Service Now. He took it upon himself, as part of understanding the business process, to really look for opportunities to be more efficient. He also updated his email signature to have the job title of Business Analyst. This is why I wanted to share this story with you. It might be intuitive of how it works for you as a business analyst. It also can work if you are not yet in a business analyst role because it will give you opportunities to understand the process, to ask questions about how the process works. Bring that business analysis mindset to whatever role you’re in, because often these solutions do get deployed without business analysis. We see a lot of Salesforce administrators, for this reason, becoming somewhat de facto business analyst because their role is to administrate the system, but in order to do that work, and in order to meet the user needs, they have to start understanding the business process so they can make the little tweaks that they’re able to make.

An admin role is a great way to progress into business analysis. A QA role is a great way to progress into business analysis, and you can do that starting by understanding and analyzing the business process. Again, if you haven’t already downloaded that template, it’ll help you get started with that technique.

> Click here to download the Business Process Template <<

Learn more about business process analysis in this video:

COTS Requirements: Use Cases

Now, another technique that’s really important is use cases, or some way of analyzing the functional software requirements. This is not required for every feature. You wouldn’t analyze the login use case for your COTS tool because most likely you are not going to be customizing that. And if you are, there’s got to be a really specific business case for that. You might want to push back on that one. But there are going to be features where there’s maybe a lot of configuration options, or you do need to customize it to work within your organization’s business model, and that’s where the functional requirements are. Here we have a sample use case as well as a wire frame are incredibly important.

Now, an example of this was Jamie Moore. She had a particularly challenging feature, and there were multiple ways it could be used or implemented using Salesforce. There were different ways that it could happen. And so she wrote a use case to decide to show how different areas of functionality could actually be leveraged in Salesforce to accomplish the end user objectives. She got this great feedback from a senior level stakeholder. I’ve never seen it done this way before. And it’s absolutely fantastic.

Wouldn’t you like to receive that kind of feedback? Often we can feel like we’re presenting tools that are new to our community and that maybe that can be a little scary. Like, oh, I don’t know. Nobody’s asking me to write a use case for this. But you can see the indecision and the uncertainty and the lack of clarity about what that feature’s actually supposed to do. There are tools in your toolbox that you can pull out to use in those scenarios. And a use case can be a great one if you’re trying to figure out how a feature could work or what you need to configure or customize and how that can work because it gets really specific about how the user interacts with the system and what the system needs to do to support that business user.

Again, if you do want to go back, I’ll just show you that use case again, and that’s probably a little bit hard to read. But we also have an absolutely free download for the use case template where you can go ahead and have this template fully at your disposal to start using right away in your work as a business analyst. And again, that’s another free download and we’ll leave a link for that below.

> Click here to download the use case template <<

You can learn more about use cases in this video:

COTS Requirements: Data Modeling

Okay, so third element of COTS requirements is data modeling. I would say data modeling is always important. Data is everywhere these days. It’s kind of a buzzword in a way, but as part of a COTS project, it might be one of the areas that you need to pay the most attention to. Maybe the second to only the business process.

What happens is often you are either migrating data from one system to another, maybe a legacy system to your COTS system, or maybe even spreadsheets to your COTS system and you need to migrate that data. That’s considered a one-time move.

And then the other example would be if that COTS system is actually integrating with another system. It could be your legacy system. It could be two COTS systems integrating together using an API. It could be any multiple number of things. But in that case, data is moving back and forth. In both of these scenarios, understanding the data dictionaries of both the source system and the target system, where the data is now and where it’s going to, as well as how those data fields map together is really important because often there’s logic. If your target system only allows 20 characters for company name and your source system allows 25 and people are often filling that in, it’s going to get truncated and you want to figure that out before you move data over and then people are saying the system is broken. You analyze these requirements with a data map.

It could be that there are fields that are broken apart in different ways or combined in different ways, or that are labeled the same thing, but actually used differently by the business. That’s where the business process layer comes in. You really want to understand what that data is and how it has an impact or how it’s going to flow.

One of our participants, Stephanie Belhomme, she is now an independent contractor as a Salesforce business analyst. She really learned to see how critical data modeling was as a tool that she could bring to her clients.

She says as a contractor, my clients are paying me to bring my best, to bring tools. It’s really important that I can do that. The Bridging the Gap program really helped her elevate her skillset.

But particular to data modeling, she realized that past projects she hadn’t really gone into that level of detail. There are always project pressures. Just like get it out there. Often, this was a great way to have a bigger impact for her clients and to make those projects go more smoothly as well.

To learn more about data mapping, check out this video:

Your Business Analysis Skills Can Make You a More Valued Contributor on COTS Projects

One other final thing I want to leave you with is about, just in general, how business analysis skills can make you a more valued contributor on COTS projects.

The example here is Tammy Schlador. Tammy was and is an expert in SAP. It’s another system. We’ve talked about multiple different systems here. She found that she was getting job offers that were very like SAP, developer or administrator focused because she was emphasizing her SAP skillset on her LinkedIn profile and her resume. And then when she would interview for a business analyst job, a new job she would find that she would do great at those SAP questions and she would fall short or felt like she was falling short at those business analyst questions about how she would actually work with users and end users, and how she would actually make sure the requirements reflected the process that was needed.

When you’re thinking about moving from one industry to another, which you may be just wanting to, think about, well, where is my career going to go? Am I always going to be in this one industry with this one domain and have a lot of expertise, both in the technology and in the business?

Probably not. Probably you’ll switch that multiple times over your career, and that’s going to give you a lot of opportunity to explore new opportunities. And in Tammy’s case, she moved from the steel foundry industry to the pharmaceutical industry and earned a 20% salary increase as a result of being able to shift industries like that. And it was because she had learned the business analysis skillset. Even though she had, I think it was like 20 years of experience doing business analysis on SAP, it was the. understanding and the grounding and the skills that we’ve just talked about that enabled her to move into a new job in a new industry. She actually had a recruiter contact her based on the updates she made to her LinkedIn profile, both to emphasize her business analysis skill set and add her training.

Just another example of how having a breadth of business analysis skills is super important and it’s really seen as valuable by your stakeholders as well, and by your hiring managers.

There we have it. A really good, detailed rundown of COTS requirements, the kinds of requirements that you need for these types of projects. Be thinking about your business process, your use cases and wire frames, your functional requirements. Definitely don’t forget those data requirements. A lot of people overlook them.

Also, this might seem like a lot to focus on, but realizing what’s in it for you is a much more longevity in your career and much more transportability of your skill set.

You’re not cut down or constrained by one area of expertise in either an area of software or an area of business domain expertise. You start to build a skill set that you can take with you anywhere, and that’s what we want for you.

Again, lots of resources that will further cover these concepts in other videos as well as the free business process template and the free use case template. Go ahead and download those if you want to get started right away.

Again, 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.

>>Improve Your Requirements Analysis Skills<<

When you join The Business Analyst Blueprint® training program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

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

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.

And that’s why we resist requirements prioritization. If you’ve been told you are “too business oriented,” this is an area you want to focus on – helping your stakeholders get clear about their priorities and what is really, truly important.

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

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

Today, I want to simplify requirements prioritization. If your experience is anything like mine, when you ask your stakeholders to prioritize their requirements, you just hear groans of “Nooooo. Everything’s important.”

When you think about even asking them to prioritize their requirements, you probably go, “No.” Maybe you feel like everything is important, or maybe you feel like it’s just hard to ask what’s most important from your business stakeholders.

And if you’ve been told that you’re too business oriented – this is feedback that some business analysts receive when they are kind of a doormat for the business – and just say, okay, you want everything. Let me put everything into the requirements.

If you’ve been told that, that you’re too business-oriented, or something along those lines, prioritization is an area that you need to focus on and get clear on and start adding to your toolkit in how you work with your business team.

Let’s talk about some simple and easy ways. This does not have to be complicated.

Requirements Prioritization Get Easier When You Know What Problem You Are Solving

The first thing to know is what problem are you solving? I say this again and again and again. I’ve been saying it a lot in videos lately, but it’s such a critical part. If you don’t know what problem you’re solving, you don’t know what requirements are most important. It’s simple as that. That is the information you need.

If you know that you’re solving XYZ problem and your business objectives are to increase sales or improve retention, or make a specific thing more efficient, then you know what requirements are most important because you can look at what requirements are in surface to that business need.

As we’re implementing our new learning management system, the most critical business problem for us is to streamline the participant instructor interaction and eliminate the manual pieces in between that are slowing the process down.

They’re also making it difficult to scale that process as we serve more customers. Everything that we’re doing is coming up against that problem. Is this feature helping us solve that problem? Very clear filter.

Requirements Prioritization Gets Easier When You Make It Simple

There are a lot of sophisticated tools out there for prioritizing requirements that you can try and experiment with. We focus on practical real-world simple best practices at Bridging the Gap, and so, the two ways I suggest prioritization are either 1, 2, and 3.

So, you give every requirement a 1, 2, or a 3; 1 being high priority, 2 being medium priority, 3 being low priority or a nice-to-have. That is pretty simple. The challenge is that everybody wants everything to be a 1.

You have to go back to what problem are we solving – 1’s are the things that help us solve this problem in the most impactful way, 2’s might be like they could add to the problem, but they’re not essential to solving the problem, and 3’s are related things that we’d like that came up but probably aren’t going to see the light of day in this project. You’re clear, then, on your 1’s, 2’s, and 3’s.

The other idea is to rank order. So, 1, 2, and 3 would be every requirement is a 1, 2, or 3. Rank ordering would be like there is a 1, a 2, a 3, a 4, a 5, a 6, all the way down the list. You’re saying #1 is more important and #2 is more important than #3 and you’re rank ordering the priorities.

That’s a strong way to prioritize that’s used on agile software development teams to rank the product backlog. There’s no ambiguity about what is more important than what. There’s no sense of like there are 20 things that are #1 and we can only do three things in this sprint. What are the three of those 20? “Oh, we’ll do 1, 2, and 3. And then the next sprint we’ll do 4, 5, and 6.”

I find that combining the techniques works well because if you have a product backlog that has 20, 30, 50 items, ranking 1-50 starts to feel like is there much difference between 45 and 46? Does that matter?

While we’re still working on numbers 1, 2, and 3, using 1, 2, and 3 to chunk out that backlog and then ranking the ones that are our 1 priority can be a way to sift through it and not have to rank everything on that backlog, which would get to be a tedious task that’s adding less and less value as you get further down the backlog.

Requirements Prioritization Gets Easier When You Understand Timelines and Costs

The other final tip I want to share with you in terms of making requirements prioritization easier is that it can help to understand the time and the cost involved in implementing that requirement.

How this is coming up for us in the learning management system is I did the 1, 2, 3 and we had some 3’s; we had some things that were non-essential, but if they weren’t there already that would be great. But if we have to do anything to make them happen, not going to happen.

Then the 2’s, the rule that I set out for the 2’s – the 1’s were essential; they were essential to solving the problem, and they were essential to how we deliver the courses and deliver our business. We had to have the 1’s. They were essential in order to release this product to our community.

The 2’s were really good stuff. They weren’t just like, “Oh, it would be nice to have that.” They were good features that were going to add a lot of value to our business. I wanted to make sure that we could keep the scope of the project tight to get it done in the timeline that we had and use the tools that we had, and to manage the budget that we had available.

With 2’s, I said, “If it’s a configuration,” if it’s just a matter of somebody setting something up and configuring it, or maybe less than an hour of work, let’s do it. If a 2 is going to require custom development or a new tool that we don’t have or not available out of the box, we’re not going to talk about it for the scope of this project.

It made it clear what that 2 meant, and it became easier to prioritize as we understood what was the time and cost available. Then we could look at the 2’s that were potentially in scope based on knowing how they could be implemented. It takes a little bit of analysis, a little bit of collaboration with your team to give a gut check on each of those requirements and say, “How much would this take?” “How much would this cost?”

You can find your stakeholder priorities tend to shift a little bit. Sometimes something you thought was important, like a 1, you’re like, “Oh, that’s two weeks of work?” It’s not a 1; maybe it’s more like a 2 or a 3.

And you see people when they understand the time and the scope and the budget that goes into implementing that requirement, then, they start to get more comfortable with the prioritization because it has more meaning. It has an actual value assigned to it that’s not just, “Hey, as long as I can ask for everything, I’m going to ask for everything until you tell me that I have to pick and choose to fit within a budget.”

Requirements Prioritization: Keep It Simple

Those are my three tips. You’re focused on keeping it simple. It doesn’t have to be a complicated process. More than likely, if you’re trying to make it a complicated process, it’s because you don’t understand what problem you’re solving and it’s not clear who is in charge of making decisions for this project.

You’re using a more complicated technique to try to, under the hood, facilitate between the stakeholders who are just not getting together and agreeing, and instead, we should be focusing on those core conversations that they’re having about what problem they’re solving and what the end result of this project needs to be.

And getting a clear direction and clear decision on that, which is going to make our whole project go easier, and going to make prioritization quite apparent once you get into the details and provide people with the information they need to make a good decision.

I’d love to hear how you prioritize requirements, or what challenges come up for you as you do this. It’s simple, conceptually. In the real world is where the fun happens. I’d love to hear what’s coming up for you on this topic.

Again, this is Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

>> Get Your Quick Start to Success as a Business Analyst

At Bridging the Gap, we help mid-career professionals build the foundational business analyst skills they need to thrive in a variety of business analyst roles.

If business analysis is a career that you want to excel at, the absolute best next thing to do is to join my free Quick Start to Success workshop. You’ll learn how to avoid the most common pitfalls faced by new business analysts and the step-by-step business analysis process to create predictable, consistent project success.

>> Click here to register for the free workshop today <<

>>How to Learn the Foundational Business Analyst Skills

When you join The Business Analyst Blueprint® training program, you’ll gain real world experience in the industry-standard techniques and business analysis processes. You’ll create work samples with the opportunity to have them vetted by experienced instructors.

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

Here’s a scenario you may have run into: You receive a short request from a stakeholder about a new project. It’s been given top priority by your manager and so it’s the next project you’ll begin looking into.

Before you can even schedule the first meeting with the business sponsor to get some more information so you can start requirements estimation, and building a business analyst timeline, your project manager swings by your desk and asks you how long you think this will take. Not sure? He thinks that 40 hours sounds like about enough time, so shall we move forward with that estimate?

Your blood pressure rises slightly. You take a deep breath. You re-read the stakeholder request.

You have no idea what it even means let alone how long it might take you to define the detailed requirements documentation for this project. In fact, this is a new stakeholder group and a new system you aren’t familiar with, and the last time you heard, the developers on that team expected the business analysts to get pretty technical with their requirements.

A headache begins to emerge.

What do you do? What can you do?  In 40 hours?!?!

You can’t provide a requirements estimate and timeline until…

What I would do in this situation is first be clear with the project manager that I can’t provide a reasonable estimate and timeline until I understand a few more things about the project – most notably the scope of the stakeholder request and some expectations about what my role will be for this new team. Then I’d give a set of steps and a target date for obtaining this information and providing a plan.

This isn’t an answer, but it’s a reasonable deferral. There is still a lot of work to do.

Following the business analysis process framework that we teach at Bridging the Gap, I’d schedule a meeting with the primary business stakeholder to ask a few questions about the request, identify who the stakeholders are, and gauge how he’s worked with business analysts before. I’d also ask the lead developer on the system to lunch and discuss his relationships with previous BAs and share some of my concerns about getting technical with the requirements.

I’d confirm my stakeholder list with the project manager, taking time to also update him on my progress and if my target date for a real estimate was still reasonable, and then schedule a meeting to discuss the primary business objectives. I’d confirm what I heard from the stakeholder about the project with the PM to make sure I wasn’t getting off track.

But I still wouldn’t have my estimate. That 40 hours might be hanging over my head still and in fact, it might be a quarter of the way used up at this point.

But I am getting closer.

Starting to get closer to a reasonable requirements estimate

After the business objectives discussion, it’s clear there is a pressing and narrow need. I’m feeling better about the project. Everyone seems to be on the same page. I meet with the lead developer to discuss the problem and he comes up with a few possible solution approaches. I also confirm what requirements package will work best for the developer and how he’d like to be involved going forward. It turns out he’s fine taking on the technical specification as long as I get the functional requirements down clearly.

We’re cranking.

The next meeting is to discuss the pros and cons of each solution approach with the business stakeholders. They are motivated and choose the least complex option. I have everything I need to draft a scope statement. Since time is of the essence, I start working ahead a little and drafting a BA plan. An estimate and timeline begin to emerge, but I’m not ready to make a commitment until the business stakeholders confirm the scope document. That happens in the next meeting and…

We’re off!

And actually turning the requirements estimate into a business analyst timeline

Of course, the project manager doesn’t like my estimate, which is about 100 hours to define the detailed requirements on top of the 25 hours I’ve invested to get to this point. Given my other project priorities and stakeholder commitments, that will take me about 5-6 weeks to complete.

(Be sure to watch the video above for a walk-through of our business analysis planning template that helps you put together a requirements estimate and business analyst timeline.)

While my project manager might not like my estimate, now we can have an actual conversation about deliverables, expectations, and my availability and make adjustments from a place of information, not assumption.

My headache is gone. My blood pressure is down. I’m still breathing.

>> Get Your Quick Start to Success

If you are looking to define credible timelines for your business analysis work, and do the planning you need to do to push back against unreasonable timelines, you’ll want to learn more about the business analysis process framework.

In our free Quick Start to Success workshop, you’ll learn how to avoid the most common pitfalls faced by new business analysts and the step-by-step business analysis process to create predictable, consistent project success.

>> Click here to register for the free workshop today <<

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

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

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

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

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

#1 – Build an Individual Relationship

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

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

#2 – Understand their Current Business Process

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

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

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

#3 – Focus on Their Problems

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

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

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

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

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

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

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

#4 – Share Wins

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

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

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

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

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

#5 – Secure Higher-Level Support

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

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

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

Not All Resistant Stakeholders Will Change

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

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

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

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

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

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

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

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

Download Your Free Guide – 10 Tips to Improve Stakeholder Engagement

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

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

Simple enough.

Boring enough.

But valuable enough that it just simply has to be done.

All too often I’ve seen this important step in the requirements process skipped, often to the detriment of the project as a whole and especially to the detriment of getting all the stakeholders on the same page about the scope or details of a project.

Common Objections to Doing a Requirements Review

But I email the document out for review, that way everyone can do this when it works for them and I get better input. Let’s get honest here for a minute. In today’s workplace, people have competing priorities and are constantly multi-tasking.  Opening up and reviewing that document is not the most exciting or probably the most pressing the most pressing task on their list. Few stakeholders will provide their best input in this manner.  Those that will are probably conscientious enough to read the document before your meeting and come prepared.

I want an email sign-off because it’s traceable. Nothing about the requirements walk-through precludes an email sign-off.  But if your reason for using email is to get a passive sign-off and cover your you-know-what, not to actually create the alignment that the sign-off actually entails, then you are doing your technology team a disservice.

My stakeholders don’t have time. Then one of two things is wrong–either you’ve identified the wrong stakeholders or you’re working on the wrong project.  Either of these issues might not be your fault.  But if the people benefiting from and contributing to the project can’t spend 2 hours in a room finalizing what exactly that project is supposed to do, there are larger issues at play.

When you sit down to review a requirements specification in a meeting, you know that people are actually reading it. You also will find that one comment leads to another and that can help discover new requirements before it’s too late. Besides, a review meeting cultivates a certain accountability – if you ask your stakeholders to look you in the eye and confirm they are ready to take the next step with the project.

We’re agile. Then reviewing the requirements with your business stakeholders prior to sprint planning is even more important! Instead of reviewing bigger documents for the full project, you’ll often focus on reviewing lists like the list of ranked product backlog items for the next few months, or the details of the user stories for the upcoming sprint.

How to Facilitate a Requirements Review Session

1. Set the stage.  Send out an email/calendar requirements with the document and a description of how the meeting will go.  Let everyone know that their role is to provide any feedback on the requirements and ultimately sign-off on the document.  Re-iterate this message at the beginning of the meeting.
2. Be prepared.  Have a few extra hard copies.  If possible, project the document onto the wall using an LCD unit.
3. Lead the walk-through section by section. Give everyone an appropriate amount of time to read and consider the requirements in that section.  Ask for comments, clarifications, and questions.  Ensure the discussion focuses on the requirements, not how to build them or what tasks need to be done or the marketing plan.  As the review group agrees to updates, note these on your hard-copy or make them electronically where everyone can see them.
4. Ask for sign-off.  Say “I’ll make these edits and distribute an updated copy.  Provided I get all these notes incorporated, is everyone prepared to sign-off?  Are there any lingering issues or concerns?”  Look at everyone in the room for a visual cue.

Some of the More Common Requirements Review Issues

Doing the requirements walk-through too early. As BA, do your homework first or you will be wasting everyone’s time. Vet out the big issues in small teams. Meet individually with the stakeholders to make sure you understand their needs.  Recognize and elevate conflicts in requirements so these are resolved.  By the time you do the walk-though, requirements should be almost ready to sign-off and the purpose is really to make sure everyone is aligned and to trigger any last gotchas.

Reading every requirement aloud. I’ve done this and it worked, but it was inefficient and I wouldn’t suggest it. Instead, review the requirements in meaningful sections that people can read through in the meeting.

Not including the right people. Ideally, your review should include one person from every area of the business impacted by the requirements, good examples include marketing, operations, product management, customer service, and IT.  Often times you’ll need more than one person from a group because of the decision matrix within that group.

No one says a word.  Be prepared with some questions to get discussion going. (And if you need help coming up with questions, download our the Free Requirements Checklist example to get the idea. Often people don’t have something to say but don’t want to appear to be critical of your work. Even throw a few mistakes in to make sure people are paying attention. Then you can point out your own mistakes, a practice that can often trigger similar responses from others.

The business uncovers a fundamental flaw in the project.  No matter how diligent you are in ensuring your stakeholders are ready for this meeting, someone can have a middle-of-the-night insight the day before your meeting and blow it to pieces.  Take a deep breath.  Ask the group if they feel this issue has to be dealt with in order to finalize the requirements for this project.  If they say yes, you have two choices: you can refocus the meeting to deal with the new issue or disband the meeting and work out a plan to deal with it ASAP.

Download a Free Requirements Checklist

Part of preparing for a requirements review is knowing what questions to ask. 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

Nothing could be further from the truth. Here’s exactly why agile teams need business analysts.

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

Many business analysts feel like their role is not needed in agile. We hear that agile teams, they don’t want requirements. Then we assume that they don’t want us as business analysts. Nothing could be further from the truth.

I’m Laura Brandenburg. I’m the creator of Bridging the Gap. Today, we’re going to talk about why business analysts are absolutely essential to agile teams.

Recently, one of our community members commented that in his early meetings with agile practitioners, he felt like something was off, something was missing. He wasn’t quite sure what it was. After going through our free training, he discovered it was the business analysis part of the process.

Where did those requirements come from for those users come from for those user stories?  What was that working software supposed to do?  That information comes from us, the business analysts.

One of my mantras is that on every successful project, you’ll find a business analyst. That’s true, even if they don’t have the title of Business Analyst.

Agile, as wonderful as it is, it’s not a business analysis process. It’s a way of developing and delivering valuable working software to the business. Agile teams, they need business analysts.

• They need us to discover what the business users need and want and determine what changes will have the most value to the business, so we can effectively use agile software development practices to deliver it with maximum efficiency.
• They need us to collaborate with business users and sponsors across the organization, and to gain alignment on what is wanted and needed and ensure that those items in the product backlog and those details in the user stories represent true value to the business.
• They need us to take a holistic view of the product backlog and find all those inner related requirements and inter-dependencies and make sure that the pieces of working software delivered are, again, going to deliver value in the context of that end-to-end business process.
• On that note, they need us to discover and analyze what those business processes are and help the business users implement the changes necessary to fully leverage that new software. That is supposed to make their jobs easier.
• Last, but not least, they need us to keep the backlog well organized. To keep it groomed and prioritized, and add those estimates and filter through it, remove things, and add things so that the team can easily see what needs to be done in the next sprint, and the sprint after that.

Agile practices and business analysis actually deliver tremendous value to organizations when they are leveraged effectively together. Let’s stop questioning why we need business analysts in agile, and let’s start looking at how we can all work together to achieve the most possible value for our organizations. Things will be so much easier when we’re all working together as a team.

I do have some more resources for you on how to be an agile business analyst. There should be a link to this video or go to bridgingthegap.com/agile-business-analyst. I’ve laid out exactly how to apply the business analysis process we teach at Bridging the Gap, and in agile software development environments. Be sure to check that out.

I challenge you. What will do to be a better partner to your agile team today?  How will you help your organization be more effective?  How can you leverage the combination of agile practices and business analysis to deliver even more value more quickly to your business community?

Leave me a comment below. I’d love to hear about your success.

Again, I’m Laura Brandenburg from Bridging the Gap. Thanks for listening.

The Agile Business Analyst: 4 Crucial Strategies for Success

To follow-up from this video, let’s look at 4 crucial strategies for applying the business analysis process in an agile environment.

Agile Business Analyst Strategy #1 – Resist the Temptation to Skip Steps 1-3

Most agile practices make certain assumptions about what information the business stakeholders can provide and how quickly they can make decisions. These assumptions are valid inside steps 5-7 of the business analysis process. But steps 1-3 (Getting Oriented, Discovering the Primary Business Objectives, and Defining Scope) are still important.

As an agile business analyst, these decisions you help stakeholders make in these steps provide the foundation you need to effectively and iteratively deliver the requirements in step 5.

• The current capabilities assessment completed in step 1 will help you and your team discover simple, quick wins that can add value quickly.
• The business objectives discovered in step 2 will help your team prioritize the product backlog to put the highest value items first.
• The scope decisions made in step 3 will help your team stay on track and make meaningful adjustments to expectations.

Most often, these steps will start before the “agile” part of the project and it’s prudent to make time for them even as an agile business analyst.

(By the way, we cover each of the 8 steps of the business analysis process in our BA Essentials Master Class.)

Agile Business Strategy #2 – Create an Agile Business Analysis Plan (Step 4)

When it comes to step 4 – creating your business analysis plan – this is where it’s important for the agile business analyst to integrate the business analysis process into your organization’s version of agile.

Here are some specific questions you’ll want to answer as you work through your planning:

• How long are sprints scheduled for?
• What happens inside a sprint? Is there time for elicitation and requirements work or is the sprint all about developing and testing?
• What is the desired outcome of a sprint? Production-ready code is the typical standard but ready-to-test code is also a common deliverable in partially agile teams.
• How does the project team decide what to work on inside a sprint?
• What state does a product backlog need to be in before a sprint?
• What state do the user stories need to be in before a sprint?
• Who is responsible for the product backlog and user stories? While these are natural responsibilities for an agile business analyst to take on, your project team may have a different way of doing things.
• What requirements work will happen inside the sprint?

Essentially, you want to figure out exactly how to fit your detailed functional requirements work into the agile process of your software development team.

Agile Business Strategy #3 – Plan for Multiple Iterations of the Detailed Requirements and Team Support (Steps 5-7)

Fundamentally, agile is an iterative development process. On the best agile teams I’ve been a part of, we developed a pattern of requirements, design, development, and testing that flows continuously so that everyone is always working on something meaningful. And this means the agile business analyst might be working on requirements that are developed and tested next week, or even tomorrow.

In the BA Essentials Master Class, we discuss specific ways to develop the detailed requirements iteratively in step 5. And it is important here to be sure you are eliciting, analyzing, and finalizing the requirements in an iterative, continuous fashion, so your product team has a steady stream of work for each sprint.

What’s more, while you are finishing requirements for the next sprint, you are also supporting the technology team during the current sprint (step 6). And you might also be supporting the business in implementing the changes from the previous sprint (step 7).

So steps 5-7 all happen, but they happen at the sprint level instead of at the project level, which means that in reality, you are working on all 3 steps at once.

In my experience, this is the biggest shift for us to get used to as agile business analysts, because this pattern of work requires us to manage our time extremely well and make sure we are working on only the most important tasks with each step. There is no time here for endlessly tweaking models or finessing the phrasing of requirements. Instead, we should be collaborating, reviewing, and getting all of our work “good enough” to take the next step.

Agile Business Analyst Strategy #4 – Regularly Assess Value in Step 8

Step 8 in the business analysis process involves assessing the value created by the solution. And here is where we as business analysts can start to fall in love with agile methodologies. In a more traditional, waterfall environment we might wait months or years to see our requirements implemented and the value intended by those requirements realized.

In an agile environment where production-ready code is delivered regularly, we might see slices of value realized within weeks. And that means we can also be assessing the value of those changes earlier, and communicating about the value already delivered by the project team before the team is even done with the project.

This kind of celebration and communication can create a lot of positive momentum inside our project teams and across our organizations. What’s more, as we see the initial changes deployed, we’ll often learn even more about what the next set of valuable functionality is, generating new ideas for new projects and backlog items, which will require regularly grooming the product backlog. Instead of staying stuck on what was originally in scope, it is important to leverage this learning and make adjustments.

An Agile Business Analyst is Still a Business Analyst

Although we might apply the business analysis process differently in agile, it’s just as important as ever to be a tried-and-true business analyst in an agile environment. In fact, if we try to skip over steps just because we are doing agile, we are likely to face more challenges inside our projects.

If you are a business analyst on an agile team, consider how you demonstrate leadership within your own domain of business analysis by applying these crucial strategies to increase your effectiveness.

Learn More About the Business Analysis Process

To learn more about the 8 steps business analysis process, sign up to receive this recorded webinar training – 8 Steps to Being an Effective Business Analyst. (It’s complimentary.)

You’ll learn about the 8-step business analysis process that you can apply whether you are in an agile environment or a traditional one, whether you are purchasing off-the-shelf software or building custom code, whether you are responsible for a multi-million dollar project or a one-week project.

Click here to register for the complimentary training

There is a Lack of Awareness of How to Do Business Analysis

Let me just say that I know what it is like to feel that you constantly have to be paving a path for how to do business analysis, and guiding your stakeholders through the business analysis steps.

I also get the pressure you feel to just get “things” done without the proper time and analysis. I’ve succumbed to it many times in my career – and always to my ultimate regret. 

It’s incredibly difficult to always be the one pushing back, and it can be wicked hard to keep asking questions when it feels like everyone else has things figured out.  

(Spoiler alert: They don’t.) 

But you and I – we also know, deep in our souls, that we’re doing our projects, our teams, and our companies a disservice if we don’t do the right analysis and keep asking questions. 

When self-doubt creeps in, you need a structure to fall back on. A business analysis process framework to guide you forward and re-affirm that you are on the right track. 

And that’s what the 8-step business analysis process framework that we teach at Bridging the Gap is all about. 

By the way,  I cover these 8 steps in more detail in our free Quick Start to Success Workshop.

Now let’s look at each of the 8 business analysis steps in more detail.

Business Analysis Process Framework Step 1 – Get Oriented

Often as business analysts, we are expected to dive into a project and start contributing as quickly as possible to make a positive impact. Sometimes the project is already underway. Other times there are vague notions about what the project is or why it exists. We face a lot of ambiguity as business analysts and it’s our job to clarify the scope, requirements, and business objectives as quickly as possible.

But that doesn’t mean that it makes sense to get ourselves knee-deep into the detailed requirements right away. Doing so very likely means a quick start in the wrong direction.

Taking some time, whether that’s a few hours, few days, or at the very most a few weeks, to get oriented will ensure you are not only moving quickly but also able to be an effective and confident contributor on the project.

Your key responsibilities in this step include:

• Clarifying your role as the business analyst so that you are sure to create deliverables that meet stakeholder needs. (To better understand the BA role, be sure to check out our free workshop – Quick Start to Success as a Business Analyst.)
• Determining the primary stakeholders to engage in defining the project’s business objectives and scope, as well as any subject matter experts, to be consulted early in the project.
• Understanding the project history so that you don’t inadvertently repeat work that’s already been done or rehash previously made decisions.
• Understanding the existing systems and business processes so you have a reasonably clear picture of the current state business process that needs to change.

This is where you learn how to learn what you don’t know you don’t know, so to speak. This step gets you the information you need to be successful and effective in the context of this particular project.

Business Analysis Process Framework Step 2 – Discover the Primary Business Objectives

It’s very common for business analysts and project managers to jump right in to defining the scope of the project. However, this can lead to unnecessary headaches. Uncovering and getting agreement on the business needs early in a project and before scope is defined is the quickest path forward to a successful project.

Your key responsibilities in this step include:

• Discovering expectations from your primary stakeholders – essentially discovering the “why” behind the project. (Our BA Essentials Master Class covers 7 different business analysis techniques that can be used as part of this discovery.)
• Reconciling conflicting expectations so that the business community begins the project with a shared understanding of the business objectives and are not unique to one person’s perspective.
• Ensuring the business objectives are clear and actionable to provide the project team with momentum and context while defining scope and, later on, the detailed requirements.

Discovering the primary business objectives sets the stage for defining scope, ensuring that you don’t end up with a solution that solves the wrong problem or, even worse, with a solution that no one can even determine is successful or not.

Business Analysis Process Framework Step 3 – Define Scope

A clear and complete statement of scope provides your project team the go-forward concept to realize the business needs. Scope makes the business needs tangible in such a way that multiple project team participants can envision their contribution to the project and the implementation. 

Your key responsibilities in this step include:

• Defining a solution approach to determine the nature and extent of technology and business process changes to be made as part of implementing the solution to the primary business objectives.
• Drafting a scope statement and reviewing it with your key business and technology stakeholders until they are prepared to sign-off or buy-in to the document.
• Confirming the business case to ensure that it still makes sense for your organization to invest in the project.

Scope is not an implementation plan, but it is a touchstone guiding all of the subsequent steps of the business analysis process and tasks by other project participants.

Business Analysis Process Framework Step 4 – Formulate Your Business Analysis Plan

Your business analysis plan will bring clarity to the business analysis process that will be used to successfully define the detailed requirements for this project. Your business analysis plan is going to answer many questions for you and your project team.

Your key responsibilities in this step include:

• Choosing the most appropriate types of business analysis deliverables, given the project scope, project methodology, and other key aspects of the project context.
• Defining the specific list of business analysis deliverables that will completely cover the scope of the project and identifying the stakeholders who will be part of the creation and validation of each deliverable.
• Identifying the timelines for completing the business analysis deliverables.

In the absence of defining a credible and realistic plan, a set of expectations may be defined for you, and often those expectations are unrealistic as they do not fully appreciate everything that goes into defining detailed requirements.

If you are facing unrealistic requirements deadlines – here’s a video with more detail on exactly how to respond.

Business Analysis Process Framework Step 5 – Define the Detailed Requirements

Detailed requirements provide your implementation team with the information they need to implement the solution. They make scope implementable.

Without clear, concise, and actionable detailed requirements, implementation teams often flounder and fail to connect the dots in such a way that delivers on the original business case for the project.  

Your key responsibilities in this step include:

• Eliciting the information necessary to understand what the business community wants from a specific feature or process change.
• Analyzing the information you’ve discovered and using it to create a first draft of one or more business analysis deliverables containing the detailed requirements for the project.
• Reviewing and validating each deliverable with appropriate business and technology stakeholders and asking questions to fill in any gaps.

Effective business analysts consciously sequence your deliverables to be as effective as possible in driving the momentum of the project forward. Paying attention to the project’s critical path, reducing ambiguity and complexity, and generating quick wins are all factors to consider when sequencing your deliverables.

Defining the detailed requirements requires a broader toolset of business analysis techniques and business analysis skills. You can learn more about the skills required to be a business analyst here:

Business Analysis Process Framework Step 6 – Support the Technical Implementation

On a typical project employing a business analyst, a significant part of the solution involves a technical implementation team building, customizing, and/or deploying software. During the technical implementation, there are many worthwhile support tasks for you to engage in that will help drive the success of the project and ensure the business objectives are met.

Your key responsibilities in this step include:

• Reviewing the solution design to ensure it fulfills all of the requirements and looking for opportunities to meet additional business needs without increasing the technical scope of the project.
• Updating and/or repackaging requirements documentation to make it useful for the technology design and implementation process.
• Engaging with quality assurance professionals to ensure they understand the business context for the technical requirements. This responsibility may include reviewing test plans and/or test cases to ensure they represent a clear understanding of the functional requirements.
• Making yourself available to answer questions and help resolve any issues that surface during the technical design, technical implementation, or testing phases of the project.
• Managing requirements changes to ensure that everyone is working from up-to-date documentation and that appropriate stakeholders are involved in all decisions about change.
• When appropriate, leading user acceptance testing efforts completed by the business community to ensure that the software implementation meets the needs of business end users.

All of these efforts help the implementation team fulfill the intended benefits of the project and ensure the investment made realizes a positive return.

Business Analysis Process Framework Step 7 – Help the Business Implement the Solution

Your technology team can deliver a beautiful shiny new solution that theoretically meets the business objectives, but if your business users don’t use it as intended and go back to business-as-usual, your project won’t have delivered on the original objectives. Business analysts are increasingly getting involved in this final phase of the project to support the business.

Your key responsibilities in this step may include:

• Analyzing and developing interim and future state business process documentation that articulates exactly what changes need to be made to the business process.
• Training end users to ensure they understand all process and procedural changes or collaborating with training staff so they can create appropriate training materials and deliver the training.
• Collaborating with business users to update other organizational assets impacted by the business process and technology changes.

This step is all about ensuring all members of the business community are prepared to embrace the changes that have been specified as part of the project.

Business Analysis Process Framework Step 8 – Assess Value Created by the Solution

A lot happens throughout the course of a project. Business outcomes are discussed. Details are worked through. Problems, big and small, are solved. Relationships are built. Change is managed. Technology is implemented. Business users are trained to change the way they work.

In this flurry of activity and a focus on delivery, it’s easy to lose track of the big picture. Why are we making all these changes and what value do they deliver for the organization? And even more importantly, are we still on track? Meaning, is the solution we’re delivering actually delivering the value we originally anticipated?

Nothing creates more positive momentum within an organization than a track record of successful projects. But if we don’t stop and assess the value created by the solution, how do we know if we are actually operating from a track record of success?

Your key responsibilities in this step may include:

• Evaluating the actual progress made against the business objectives for the project to show the extent to which the original objectives have been fulfilled.
• Communicating the results to the project sponsor, and if appropriate, to the project team and all members of the organization.
• Suggesting follow-up projects and initiatives to fully realize the intended business objectives of the project or to solve new problems that are discovered while evaluating the impact of this project.

Business analysis creates tremendous value – and you can learn all about how to position your value in this video!

Knowing the Business Analysis Steps Cultivates Confidence and Credibility

As you leverage this process framework, you’ll gain increased recognition for the value of business analysis, and you’ll start to get pulled into more interesting projects, earlier in the process. 

I see BAs resist having a process because it seems like every project is different but without a process, you really feel like you have to make things up as you go along. While there are nuances of each project that are different, this is a framework you can fall back on to guide you. 

It’s both structured AND flexible. 

I invite you to start applying this process. 

If you want to learn more, join my Quick Start to Success workshop, where I teach you the ins and outs. We also do a deeper dive into each step of the process in our online business analyst training programs.

And, again, this is about you increasing your effectiveness, and finding the confidence to do what’s right for your project and your team, even when there can be pressures to “just get things done.” 

We build our profession one business analyst at a time, and success starts with you. 

Let’s Get Started!

Now that you understand the business analysis process framework, the very first step to get started on just about any project involves analyzing the business process. Here’s a great video to help you explore this essential business analysis skill set in more depth!

(By the way, if you are looking to learn more about Entity Relationship Diagrams, be sure to check out our FREE ERD Sample + Bonus Tutorial)

Essentially, a conceptual or logical ERD will visually show how the terms in your glossary relate to one another. They are especially helpful in clarifying information models for relational databases and helping business users understand database structures at a high level and without details. 

(This might surprise you as typically ERDs look almost ridiculously complicated. That’s because most ERDs are automated output from physical database designs, not carefully crafted abstractions of business concepts.) 

In this tutorial, you’ll learn what goes into an ERD and how to create one from a more business-focused perspective. 

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

What is an ERD (Entity Relationship Diagram)?

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about ERDs, or entity relationship diagrams, and specifically how to do them from a business perspective, and why they’re really valuable for business users and business analysts. What is an ERD? An ERD is a data model that describes how entities or concepts relate to one another. So, those are two concepts with a line to create.

We’re going to show you a model, an actual example, before I close the video so that you’ll have more than my fists with a line between them. But that is essentially it. We over-complicate them because what often happens is the first ERD we ever see is a messy spider web of boxes and arrows and lines and details and stars and all kinds of things. We’re like, “This is crazy complicated. It makes no sense.”

The reality is that most of those, if not all of those, are automatically generated output showing the physical details of a database, as opposed to carefully designed abstractions of concepts that help us conceptualize, talk about, and realize how business concepts relate to one another. It’s the same exact syntax and semantics and modeling technique, the same modeling technique, but it’s done in a very different way. We’re going to talk about how to do it from a business focused way that looks at the very high level business concepts and the relationships between those.  

Really what you’re doing in an ERD is you’re showing logically how concepts relate to one another and what the key data elements are that you need to know about a concept as a business user. It’s a tool to help really communicate how information is stored and how the business thinks about relationships.

What would a business concept be, just as an example? It could be customer order. Customer order is a good one. Can a customer have multiple orders, and can an order have more than one customer? Usually not. Usually a customer can order multiple times.

That’s awesome, but usually an order has to have one, and only one, customer. That’s what we mean by relationship.

It could be could job seeker, another example we use pretty often. A job seeker and their résumé that they can use to apply to a job. Then a hiring manager looks at that application and decides to contact them. Some of that got into flow, but how does a hiring manager and a job seeker and a job posting and a résumé, how do those concepts relate to one another? Can one job seeker have more than one résumé? In some systems, yes. In some systems, no.

It’s a question. Maybe there’s a one-to-one relationship between a résumé and a job seeker. Maybe there’s a one-to-many relationship, and then when they go to apply for a job, they have to decide which résumé they’re choosing to submit for that application.

Those are the ways that we’re talking about. What are those core business concepts, and how do they relate together? This is what an ERD will show from a business perspective. 

Now from a data perspective—let’s just talk about that for a tiny little bit—this is not the way that we teach them at Bridging the Gap, and it’s not the way that most business analysts need to create them, but it’s going to show, at a very detailed level: what are all the tables in the database, what are the relationships between those tables? Again, it’s the same exact idea of what we just talked about: one-to-many, one-to-one, many-to-many. What are the relationships between those tables, and what are all the fields that are included in all of those tables?

It’s the physical—it’s actually how the database is built, the physical structure of the database, which is important. We need that, but we don’t always—there’s a lot that goes into the physical structure of a database that is implied or not relevant from a business perspective, and when we show all of those details to our business users, we get, “That’s a messy spider web I know nothing to do with,” versus if we can winnow it down and show a very intelligent, thoughtful abstraction of that information, we can get some really important business input and clarity on business concepts that will help us build the database that will actually serve them better.  

Key Elements of an ERD (Entity Relationship Diagram)

So what’s included in an ERD? We’re going to show the visual model here, and I’m going to talk you through some of the key examples. First are the entities. The entity is the thing, the concept. It’s the box on this model that you’re looking at. In business domain terms, it’s a concept. In relational database terms, it’s going to be the table. 

Then, there are the relationships. They’re the relationships that connect those boxes. This is where the real insight from this diagram comes because we see how those entities relate to one another. How does the job posting relate to the résumé? How does the job seeker relate to the résumé? Relationships are really those verbs or the numerical relationship that links those nouns together. 

Finally, we have attributes. Attributes are the details within each entity, and there can be more than one attribute. They provide detailed information about the concept. If we’re having a job seeker, we need to know their name. We need to know the date they joined, maybe. We need to know their current employment status. Some key attributes or information that we would store in this concept of job seeker. 

By the way, you have this sample here. I’ve also included the sample and the Visio swipe file of this along with twenty-one other actual visual models in our Visual Model Sample Pack.  It has twenty-two visual samples, one of which is the swipe file that you’re looking at here. There are other swipe files in Excel and PowerPoint and Visio. Then we also, along with that, have a guide for how to create each model. It’s not just a swipe file. It’s: why did I create it? How did I create it? How do you create it? When would you use it? Why is it important as a business analyst? Lots. A “how-to” practical crash course type information in these things. 

How to Create an ERD (Entity Relationship Diagram)

But I want to talk a little bit more about that here, specifically on the ERD, or the entity relationship diagram. How do you actually create this thing as a business analyst? What do you do?

Usually, I will start with the glossary that I have, if I have a glossary. If I don’t, I’ll start pulling the nouns out of my use cases, pulling the nouns out of my business process documents, or pulling the nouns out of any requirements document that I have, and pulling those together and putting them in boxes on the page.

I don’t often do it right in Visio. I, more often, will start on a blank sheet of paper and draw because it’s really messy, or I’ll do it on the whiteboard and start to piece these things together because you’re going to do it, and you’re going to redo it. Then you’re going to look at it, and you’re going to have lines crossing, and you’re going to need to move things around. If you’re trying to do it in Visio, there’s so much to figure out in Visio that it takes away from the headspace you need to figure out, “What are the concepts that I need to cover, and what are the relationships that I need to cover between those concepts?” 

So, I just start with those nouns, piecing them together, and then start looking at, “Does this one have a relationship to this one? If so, what is that numerical relationship? Is it one-to-many? Is it many-to-one?” I talk myself through that relationship, then I put the line in with the appropriate notation to cover that relationship. There are two notations. I didn’t mention this before. There’s the crow’s foot notation, and there’s the multiplicity syntax, which has a numeric value. Crow’s foot represents that visually with crow’s feet at the end or one line, where multiplicity shows it in numbers. You can use either one. We include examples of both because it’s really a personal preference. Whatever your organization uses, be consistent.  

Then, I would piece it together. I would get a draft together, and one of the more powerful experiences I had reviewing an ERD and using it, not just to be like, “Hey, look at me! I have this ERD,” but to actually say, “We have a fundamental challenge on this project of how we’re going to realize what the business wants in our physical database model.” We had this disconnect, and everybody was like, “It’s impossible to do what they want in the physical database.”

We were just going back and forth, and the use cases weren’t getting to enough detail, or they weren’t getting these relationships. We were looking at one slice here and one slice here, so I took a holistic view of all the concepts and all the relationships that we were trying to model and realize in the system.

Then, I sat down with my primary business subject expert and our primary development expert, and I gave them a printout of what I’d been working on, but I was like, “This is just an idea. It’s just a draft.” I asked the developer to withhold, step back from what the database does and step in to a space of understanding what the business wanted. I said, “I realize this might be tough. It might be infeasible. We might not ever be able to build this, but just for the purposes of this next hour or two (it was probably a two-hour meeting) please just suspend that attitude and show up to just understand what they want. Then, we’ll worry about the solution later. I promise I’m not painting you into a corner here, but let’s just get aligned on what we actually want.”  

Then we proceeded to redraw this on the whiteboard, and it was beautiful. The model I created was complete crap at the end of this, but it was a talking point that helped me prepare because I was the least knowledgeable person in the room about this domain.

So, it helped me prepare to create that model, and it helped me make sure we covered everything. By having that draft put together, it helped them see where I was going as we were drawing things on the whiteboard. Ultimately, the whiteboard represented a completely different set of concepts. Not completely different a very different view, and it was a complete view where everybody could look at that and be like, “Yes. This is what we want the system to do.”

The magic of that is that within hours, or maybe even days, or maybe even in that meeting, the developer was like, “This is how we can do this, and this is how we can model this. We just need this little tweak here and to adjust this relationship here. It’s really not a big deal.”

It went from being this huge problem on the project to being, “It’s really actually not a big deal.” That model helped us get over that intellectual hurdle in that project, and it was an ERD, and it was a business-focused ERD.

This is why we use them as business analysts. This is a tool, and it’s really useful, even to just help us think through these concepts so when we’re writing a use case, we’re thinking about the steps. Does that align with our ERD? Does the data model, the information model we’re asking for actually support what we want the system to be able to do? Are there variations in the business process? These all go together, in terms of different views to look at the requirements. 

Again, I invite you if you’re interested, download our swipe file. It’s part of our Visual Model Sample Pack. You’ll get the ERD plus twenty-one others.

Thank you for watching. Thank you for taking the initiative to create one of these ERDs yourself. They are not scary. I promise. Again, I’m Laura Brandenburg at Bridging the Gap, and we help you start your business analyst career. 

>>Learn More About Entity Relationship Diagrams

If you are looking to learn more about Entity Relationship Diagrams, be sure to check out our FREE ERD Sample + Bonus Tutorial

• If you have a business background, a use case will help you define what the software needs to do, even if you don’t have much (or any) technology/coding knowledge.
• As a technical professional, a use case will help you communicate about what the software does using less “tech speak”.

In this use case tutorial, you’ll learn exactly how to apply use cases in your analytical work. I’ll also share favorite use case template, with detailed annotations and descriptions so you know exactly what goes into each section.

>> Click here to download the use case template <<

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

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about how to write a use case. I’m super excited because these cases are my absolute favorite analytical technique. Hopefully, as I share this tutorial of how to actually put one together, you start to see why and are encouraged to start experimenting with them, as well, or maybe have a takeaway if you’ve done them before about you can make them a little bit better. 

Why Write a Use Case

First of all, why would you write a use case? What is this for? Why do you need to do it? As a businessperson, you might be concerned about how to actually communicate the technical requirements or the software requirements to a—I don’t even know what those are, first of all. How do I communicate with my software developers to make sure I get what I want out of the software system?

That’s one of the great tools or reasons to use a use case is that they are really a connection point. Both business and technical users should be able to really understand them and provide feedback on them. As business analysts, we use them as a communication tool, really, to literally bridge that gap or really connect people together, in terms of a common technique, common language about what the software will do. 

As a technical person, you might be looking for a way to communicate with your business stakeholders, build stakeholder engagement, and get rid of that “text” speak, less about how the system does it and more about what the system does. That really is going to help speed up the communication and clarify and make sure you’re building what the business actually needs and wants when you sit down and work on the code. 

What is a Use Case? 

What is a use case? How does it solve these problems for us as analysts, as technical people, as business users?

• A use case is a textual description that captures the interaction between a user and a system to achieve a specific goal.

This is really important. It’s the interaction between the user and a software system.

It’s different than a business process, which might capture all the things that that user would do to achieve a bigger picture goal or outcome in the organization. Use case is very specific and dialed in, in terms of how that user actually interacts with that software system to achieve a goal. This is a more granular goal.

Use Case Examples

Some example use cases include:

• Purchase Course
• Watch Video
• Subscribe to Free Training
• Download Template

Use cases represent specific and concrete things that a user can do with the software system, and it captures all the ways that that user and system can interact.

The details of the use case include all the exceptions and variations and what happens if you go to purchase a course, and your email address is invalid or your credit card’s not valid or something like that. All those variations of what can go wrong in variant paths in the scope of the system only. This is what allows us to get at the software requirements.

Use Case Template + Step-by-Step Tutorial

What is included in a use case? I’m going to go through the common sections that are in a very traditional use case template.

You can take notes if you want, but you can also download our template.

It’s one of the thirteen templates we include with our Business Analyst Template Toolkit.

How to Name a Use Case

You want to start with a name, and just like with a business process, you want that name to be verb-noun. So, “Purchase Course,” “Subscribe to Free Training,” not just “The Free Training Use Case.”

You want to know: what is the action that user is taking that’s going to be described in the use case?  

Writing a Brief Description for a Use Case

Next is a brief description, and one of the things I really like to include in my brief description is a sentence that really gets clear about the scope. “This use case starts when…” and “This use case ends when…” because what happens when you start to write all those steps is you find all these variations.

Then, all of a sudden, your use case is all over the place, and you’re like, “Laura, this isn’t a sequence of steps. It’s a web.” It’s usually because you’re going off track, or exploring alternates in too much detail, or really are just not staying within the scope of the steps that need to happen for the specific goal of that use case.

Get clear on your: Starts when / Ends when.

Big tip. 

Define Use Case Actors

The actors: who are the users, or the roles, or the types of actors that might use the system? It’s not job title; it’s actor.

Multiple people can fill that role with the system. It’s what the system can identify about you.

Are you a purchaser?

Are you an administrator?

Are you a reporter?

Something like that. 

Define Preconditions

Preconditions: what must be true before the use case starts?

This, again, is a very system-level. What can the system know to be true before the use case starts?

Write the Basic Flow of the Use Case

Then, you get into the Basic Flow, and I like to think of the basic flow like ping pong. The user does one thing, the system does another thing. The user does one thing, the system does another thing. “Ping pong, ping pong.” It’s not always that clear-cut. Sometimes it’s like, “Ping, ping, pong, pong, pong. Ping pong.” It doesn’t have to be just one back-and-forth like that, but thinking about it as ping pong really helps make sure that you’re getting that user-system interaction.

What we see very commonly among our business analysis course participants is that those with more of a business background are like, “Ping, ping, ping. User, user, user, user, user, user.” System does one thing. Really, the system is doing things all along, they’re just not seeing it because they’re not used to looking for what the system does to support them, and because they’re the business user, they’re thinking about all the things that are happening in the business. So, they’re not seeing.

That’s part of the way that the use case is such a powerful tool. It really dials you into, as a businessperson, what the system is doing to support you and what those requirements actually are of the system that you might not see otherwise. It becomes very important when you’re just like the, “Ping, ping, ping, ping. User, user, user, user.” 

On the flip side, a more technical person will often say, “The user does one thing in a ‘Boom, boom, boom, boom.’” It’s like, “Pong, pong, pong, pong, pong.” It’s all the technical details of what the system is doing, which is way more depth than what the business actually cares about because you just lose them with “text” speak of, “Oh, the system executes this sort of procedure, and updates this data, and sends this to this API, and updates the web form,” and all this technical detail. That’s not what goes into the use case.

Instead, explore data modeling techniques such as a data dictionary, system context diagram, and data map to be sure you have a full understanding of the data requirements.

The use case is not a technical specification. It’s not a system specification.

You want to the requirements, or what would go into a functional specification. This involves what’s the observable piece that the system, that the user can see the system doing and experience the system doing? Not how the system is doing all that. I realize there’s a lot of magic and juicy stuff that happens there; it doesn’t go in your use case. Ping pong. Sometimes, “Ping, ping, pong,” but not all one or all the other. Otherwise, you really have a different kind of document, not a use case.

Break out Alternate and Exception Flows in a Use Case

Then, alternate flows and exception flows. These are the variant paths. Sometimes—Let’s just see an example. For “Watch Video,” you might have “Pause.” You can pause the video. You can end the video (please don’t do that!). You can do different things. You can “Like” the video. You might have—Sometimes it might not fit within the scope of that use case but all the different things you can do. These are the alternate flows.

An exception flow might be: what happens if your Internet connection cuts out and the stream ends? How does that get presented to the user? Things that go wrong and keep people from, stopping reaching the end goal or the end of the use case. 

Finally, decide on Post Conditions

Post-conditions are what are true after the use case is over. If there’s any information that needs to be stored or outputs that need to be generated, those all need to have steps in your use case, and you can capture them as post-conditions, as well. Again, you don’t have to remember all of these details. Be sure to download our use case template, which will give you an annotated template, all these sections, a quick synopsis of what’s included. Again, that’s just one of the thirteen templates that we include in our Business Analyst Template Toolkit. 

Use Cases Do Not Require Technical Knowledge 

One thing I want to cover—and I’ve alluded to this as I described a use case, but we still get a lot of questions about it—is: doesn’t that use case require technical knowledge? “What do I do if I don’t know the tech? How do I communicate with developers, and how do I do things like requirements? It seems like I’ve got to know all this technology, and I have to know the business analysis.”

Really, you’ve got to think of the use case as a tool that allows you to communicate about what the technology needs to do without actually knowing how it’s built because you’re not doing all those “Pong, pong, pong, pongs.” You’re not seeing all of the different pieces of the tech that happen behind the scenes.

You’re saying, “As a user, what is my observable functionality? What do I see the system doing for me?” We should be able to be very clear about that as a business analyst. That’s part of the clarity we bring to the table.  

Use Cases Help You Ask Smart Questions

That’s why use cases are such a great tool; they help us ask really, really smart questions that uncover gaps in thinking and understanding and requirements.  

As an example, say we’re talking about “Purchase Course.” We have a step for the user choosing a course, a step for the system presenting the order form. Then, the user fills in the order form; the user submits the order form, the shopping cart checks credit card details. I’m probably missing a few things here, but you’re going to have this back-and-forth between the user and the system.

If you watched my business process video, you know that there’s a course participant registration that happens automatically. How does that actually happen? What’s the output that enables that to happen? Behind the scenes, there’s a—I don’t know the technical term—but there’s a data ping, likely specified by a data map, that’s sending that credit card information. That would be really important, the user information from one system to the other, so we can automate that setup and get people their course registration details as quickly as possible.  

Interested in learning more about a business process? Here’s the full video:

As you detail out the use case to fulfill this business process, you would see the gap. Like, “Well, wait. We see this thing happening here. We have this thing happening here. We don’t actually know what the steps are to get from point A to point B. It’s not clear to me.” We’ve had people ask that question that are new to our business. “How does that actually happen?”

They’re using their use case thinking to think it through and to find the gap.

It’s way easier when you’re actually writing the use case and getting all to the steps to where the last step is that the user receives their course registration email. You’re like, “Wait a minute. That’s not coming from the shopping cart. Where does it come from, and how does it get there?” That’s the kind of step-by-step thinking that you want to be doing in your use cases and that you want to bring to the table. It really helps you understand the technology without having to build the technology. 

I hope that is both a tutorial on how to create a use case and a lesson in why they’re so fun and important, and why I love them so much, and how they are such a powerful analytical tool for you to be using to really get clear on the requirements to bridge the gap between your business and technology stakeholders, bring everyone truly on the same page about what the software needs to do using a communication tool and an analytical tool that helps you uncover gaps and communicate with people who are both technical and non-technical. 

Download Your Use Case Template Today

Thank you for watching.

Again, download that use case template here.

This will give you a great starting point to writing your first or next use case, and save you so much time gettings tarted. It even has instructional text to guide you ever step of the way.

As always, we build our profession one business analyst at a time. Success starts with you.  

Thank you for being here. Thank you for watching. I’m Laura Brandenburg from Bridging the Gap, and we’ll help you start your business analyst career. Happy modeling! 

Use Cases Are One Way to Analyze the Functional Requirements

Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.

Use Cases vs. User Stories

Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.

A Business Process Model is a commonly used business analysis technique that captures how a business process works and how individuals from different groups work together to achieve a business goal.

Let’s look at what a business process model is, how you’d go about creating one, and why it’s important to model your process, both visually and textually.

>> Click here to download the Business Process Template <<

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

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

Today, I want to share a really important technique with you on our business process modeling and how to analyze a business process because when you’re trying to figure out what problem you’re actually solving as a business analyst, it’s really important to know what the business process is. It helps you look at what the need is, what the scope is, and what problem we should even be solving with this process. You want to do this in both a visual way and a textual way, and we’re going to talk about how those work together.

Now, you might not be a business analyst yet. We help a lot of people get started.

• If you’re in a software development role, this is a great technique to use to understand the business perspective of the technical or the software that you build. How does the business actually use this software in the bigger picture? What are all the steps that they might do before they use your software, and what are the steps they might do after? It helps you see how your software fits into their day-to-day workflow.
• If you’re a subject matter expert or somebody who’s hoping for technology improvements to the work you do every day, using this sort of analysis can really help you fully articulate what you do day-to-day and how that work flows, so that when you’re talking to a developer or business analyst about the enhancements you want to a system, you can be very clear about how that process flows today. You might find opportunities to improve it, even just by analyzing, as well, which is always a win-win.

In this video, we’re going to talk about what a business process is, as well as what the key sections in a template that we teach at Bridging the Gap in terms of how to document and analyze a business process in a very clear, very complete way.

What is a Business Process Model?

Just to lay the groundwork, a business process is just a step-by-step sequence of events that is performed by a business user to achieve a specific goal. You want to know: what’s the desired outcome? What’s the goal? What’s the thing that happens at the end of this process?

Then, you back engineer. What are the things that have to happen to achieve that goal? All of those steps go into your business process.

Some of those steps could be manual. They could be in a spreadsheet. They might be on a sticky note on the user’s computer, the business person’s computer.

They might be using software. Those steps are not limited to what the software sees on a use case, which is very limited to the software. It’s very all-encompassing. What are all the things they need to do? Even if that’s getting up and walking over and talking to somebody at the desk next to them, that’s the kind of information that you want to capture in your business process.

One more important thing is that they can have variations and exceptions. We’re not always doing the same sequence of steps. One way that comes up for us at Bridging the Gap is when you register for one of our courses online, when you go through our online shopping cart, the system automatically will create a course registration for you and send you an email with that course registration information and your login details so you get access right away.

That process works beautifully for a majority of the registrations we have, which are one person paying for one course at a time. Every once in a while, we have teams invest in our business analyst training courses, or a manager who wants two or three people on their team, or a business analyst who gets the person next to them to join with them, which is awesome, and they’ll pay for multiple course seats at once. Then, the system doesn’t work so well. We actually have a manual process that’ll work around so that you send us the names and emails of those people, and then we will, within a day or two, set up access to all of those course participants.

So, an example of when you have a main process and then variations. It’s the same goal with the same outcome. Each individual course participant is getting their registration information, but there’s a variation to it when something triggers that variation. We’re going to talk a little bit more about that when we go through the sections.

You don’t have to take notes. You can if you want, but you can actually download the template we have for free, and that will walk you step-by-step through each of these sections we’re going to talk about so you can get started right away plugging your own information in about your business process. If you want to get that, that’s at bridging-the-gap.com/bptemplate, and don’t forget those hyphens in Bridging-the-Gap. There should also be a link below this video, as well, for you to grab that.

The Key Elements of a Business Process Model

Scope

The first section of our template is our statement of scope, or our purpose. This is: what is this process? You want to name your process, and you want to start your process name with a verb. It’s not “Our Course Purchasing Process” or “Our Course Participant Process.” It’s “Purchase Course Process” or “Give Access to Course Process.” It’s very specific on the outcome. You want to identify the scope of the process really clearly. You want to identify when that process starts and when it ends.

Desired Outcome

Then, you want to talk about the desired outcome of the process. It’s a little different than the purpose because there are a lot of reasons that we can execute a process. We can get really engrained in how we do it here. “That’s just how we do it.” Why are we doing this process? For Bridging the Gap, we have a course registration process because we want to help people improve their skills and because we are a company.

We’re a revenue-generating company, and those two things go hand in hand. That’s our “why” behind the course registration. If we did not have course registration online, we would have it through the phone, or we’d have it through fax way back in the day. It’s an essential business process to delivering the value we’re here to deliver, as well as receiving the revenue that allows us to be a profitable company that expands and grows and helps more people.

So, what’s the desired outcome of the process that you’re considering?

Activity Descriptions

Then, you’re going to go step by step through the process or activity descriptions. Step by step, what are the things that a business user does? Sometimes you’ll have multiple business users, so then you want to be clear about what the handoff is and who is doing what by using different actor or role names.

Exceptions

After that, you have the exceptions. As I mentioned, we have a primary path for when a course participant just purchases one, and then we have an alternate path, or an exception path, if multiple registrations come through at once. You want to be able to handle those sorts of variations and specify exactly what happens differently when you have a variation.

Business Rules

Another thing you might have is business rules. For us, a business rule is when somebody purchases more than one course registration at once, we will have them set up with access within two business days. Often, our team is amazing, and often, it happens within hours, but our business rule is two business days. You can have a business rule that a business user has to support. A lot of times we have business rules that are built into our systems that our system actually enforces for us. In a business process, you could talk about either of those kinds of rules.

Entry Criteria and Inputs

The other thing you have in a business process is your entry criteria and your inputs. Entry criteria are what must be true before the process starts. In the course of our course registration, you must have access to an online system. You must have a valid credit card. All of those things must be true.

The inputs are a little different. The inputs are what you have in place. What are you tangibly bringing to the business process? So, actually, valid credit card would be more of an input. You’d have an input of a credit card or maybe if you were buying a course and getting approval on your company, you might have an input of an approval document of some sort that allowed you to use that credit card. Something like that. It’s a tangible input. Our sales material and our marketing material for our courses could be considered an input for that process.

Exit Criteria and Outputs

On the reverse, you have the exit criteria and the outputs. What is true, or what has to be true when that process is complete? The process is complete when the course participant is set up and has access. Then, what’s the output? In our case, the main output is that email that gets sent to the course participant with their login information. That’s an output of the business process.

Process Flow Diagram

Finally, you might have a process flow, or a workflow, diagram. This is that visual model, and often you will have the visual model that accompanies your textual process.

All of this information that we’ve just been talking about can be modeled both visually and textually. It’s really important to look at it both ways, and you want to have those two types of information, essentially, side by side so you can see the visual. Often that visual is going to be a little bit higher level of information. Then, see the text, which has more detail.

Again, you don’t have to remember all of these details. We have, for free for you, the business process template. It’s below so you can start using this right away, getting started without a lot of roadblocks.

It’s one of the thirteen templates that we include in our Business Analyst Template Toolkit, and we’re just happy to give it away for free. The toolkit also has corresponding work samples and a guidebook. So, there is a lot more in that, as well, but the template we can give, for free, to you today.

Why Text + Visual Is Needed To Get a Complete View of the Business Process

I just want to talk a little bit more about this difference between the textual model and the visual model because one thing we see with our course participants is that they’ll just send us in the visual model and be like, “This is it, right? This is all I usually do.” A lot of business analysts really only do process flow diagrams or workflow diagrams, and they consider those complete business process models.

What happens, though, when you start going through the text is that—and especially start applying some specific guidelines about how to phrase those activity descriptions, what goes in the entry criteria versus the inputs. It really forces you to think through the process at a more granular level and dig deep. This is how you don’t miss steps. This is how you uncover, “The stakeholder jumped from here to here.”

When you’re winding that up on a process flow diagram, a lot of times, it’s easy to just skim over the fact that that connection actually doesn’t make sense. When you’re writing it out using the template, often you’ll say, “Oh, wait a minute. There’s a gap here that I didn’t see,” or, “I don’t know who the actor is,” or, “I don’t know this piece of information.”

The template helps. The textual view really helps you dig a little deeper as a business analyst and uncover gaps and ask really smart questions, which is what we all want to do: look smart. Even though we don’t actually know the process ourselves, it helps us ask really smart questions.

That’s why I’d encourage you, if you haven’t before, to check out how to actually document the business process textually, in addition to that visual model that goes along with the textual model.

Download Your Business Process Template Today

When you want to get started with that, go ahead and download our template totally free. We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

>> Click here to download the Business Process Template <<

Again, I’m Laura Brandenburg from Bridging the Gap. Happy process modeling!

(By the way, real-world samples of each of these visual models are included in our Visual Model Sample Pack.)

While it will be unnecessary to use every model for every project (the samples are drawn from experience across 10 years of BA work in 6 difference companies), the more models you know, the more likely you’ll be able to apply the best model to keep the requirements process moving faster in the situation you find yourself in.

#1 – Activity Diagram

What They Do: Activity Diagrams break the process down in detail and are great for being sure you don’t miss any steps. They are good complements to use cases since they provide a visual picture of the text describing the basic, alternate, and exception flows.

What They Look Like: An Activity Diagram illustrates the steps a system undertakes to deliver an outcome and the procedural logic required to proceed through those steps. Activity Diagrams can be completed as a workflow diagram or in a more formalized version in UML notation.

#2 – Business Domain Model

What They Do: Business Domain Models clarify the information created and managed by an organization without diving deep into the database structures. Creating and walking through a model like this can often clear up misunderstandings and get everyone speaking the same language.

What They Look Like: In a Business Domain Model, each key concept gets a box. Important attributes for each concept are listed within each box. Lines connecting the boxes show the relationships between concepts.

#3 – Competitive Comparison Matrix

What They Do: Competitive Comparison Matrices compare the current state or a potential future state of a product or system to that of an organization’s competitors. This kind of understanding can help significantly with prioritization as it clears up what requirements are important to gain a competitive advantage or simply catch up in the marketplace.

What They Look Like: Competitive Comparison Matrices can be presented in many different forms. They often include a list of competitors on one axis and a list of features on the other. Then each box in the matrix is filled in to identify the competitor’s offering for each feature. In the real-world sample provided in the Pack, we developed a matrix/roadmap combination that fits easily on one PowerPoint slide.

#4 – Data Flow Diagram

What They Do: A Data Flow Diagram illustrates how information flows through, into, and out of a system. They are especially useful when evaluating data-intensive processes and looking at how data is shared between systems or organizations.

What They Look Like: Data Flow Diagrams show the data sources, data processes, and data stores. The BABOK® Guide identifies two formal notations for representing data flow diagrams: Yourdon and Gane-Sarson. It’s possible to create an informal data flow diagram as well, which typically takes the form of a workflow diagram.

#5 – Data Model

What They Do: While the Business Domain Model illustrates a high-level representation of the information managed by an organization, a Data Model goes deep into the database structure. Mapping data and creating new tables or attributes often has a direct impact on reporting and other system functionality. Even while this is a more technical model, your business stakeholders often have many relevant concerns.

What They Look Like: Most Data Models contain a matrix of attributes that helps your development team know exactly what data fields to create, along with their associated data types and allowable values. In other situations, a Data Model includes a mapping from one information source to another.

#6 – Evaluation Criteria and Recommendation Summary

What They Do: Evaluation Criteria and Recommendation Summaries are useful when evaluating off-the-shelf software, comparing potential vendors to engage, or even in preparing to interview job candidates. They will help you gain clarity on what your options are and make decisions from the information instead of untested opinions.

What They Look Like: Evaluation Criteria list specific ways that a potential solution will be evaluated to determine if it’s desirable or acceptable to stakeholders. A Recommendation Summary provides supporting detail to back up a recommendation, ideally made based on previously agreed to Evaluation Criteria. Both Evaluation Criteria and a Recommendation Summary are often organized visually for ease of scanning, review, and comparison.

#7 – Feature Brainstorming Mind Map

What They Do: You know that early stage of the project when everything is fuzzy but you absolutely need to get something down on paper? You need a way to keep ideas organized while keeping it easy to add new ideas and other relevant information. That’s a perfect scenario in which to create a Feature Brainstorming Mind Map – this visual model captures ideas from your stakeholders when it’s not yet time to invest in a detailed scope statement.

What They Look Like: A Feature Brainstorming Mind Map contains a central node for the project or product under discussion and a branch for each high-level area of exploration. Ideas, concerns, and feature requests can be captured and linked back to each branch.

#8 – Feature Matrix

What They Do: Have a complex set of features to track against? Looking for a simple requirements tracking tool to manage your BA work? A Feature Matrix can be used to analyze, rank, and assess the architectural impact of multiple features, or track other attributes that are important to your project.

What They Look Like: A Feature Matrix lists each high-level feature in a row of a spreadsheet. Then, columns are added to capture critical pieces of information, such as a feature description, priority, state, and risk. Each box is filled in with appropriate information for each feature.

#9 – Feature Prioritization and Stakeholder Matrix

What They Do: Oftentimes different stakeholders are needed for different parts of the project. They may also have competing priorities that need to be reconciled. A Feature Prioritization and Stakeholder Matrix is a specific type of Feature Matrix that addresses both concerns.

What They Look Like: For this type of Matrix, each feature is listed as a row in the spreadsheet with columns for each corresponding stakeholder and individual priority assessment. An additional column can be used to roll up priorities and with a simple calculation you’ll have useful information for establishing an organization-wide priority assessment.

#10 – Feature Roadmap

What They Do: A Feature Roadmap can be used to show how your project investments have and will yield demonstrable value to the business. They are useful for high-level summaries given to top executives and boards of directors.

What They Look Like: A Feature Roadmap contains 4 boxes – one for your past state, one for your current state, one for your target future state, and one listing the benefits of attaining the future state. Each box contains 2-3 short bullet points. Graphics can be added to emphasize key elements.

#11 – Navigation Map

What They Do: A Navigation Map helps you keep the big picture perspective on how the user interface flows. I often review a Navigation Map before starting a wireframe for a new screen. With stakeholders, a Navigation Map is a useful tool to set the stage for user interface or use case reviews.

What They Look Like: Essentially, each screen in the system is represented by a box. Lines with arrows connect the boxes together and show how the user can navigate through the screens.

#12 – Organizational Chart

What They Do: An Organizational Chart represents the organizational hierarchy in place for an organization or a part of an organization. Organizational charts can be used as part of stakeholder analysis or to model new work groups to be created as part of responding to organizational change.

What They Look Like: Organizational Charts typically contain a box for each employee. Lines are used to connect managers to direct reports and show the functional hierarchy in place within the organization. Organizational Charts can be created at multiple levels of granularity and may show departments, teams, functions, or individuals filling specific roles.

#13 – Performance Report

What They Do: A Performance Report shows the results from a project, project phase or business activity. Looking at past data can help stakeholders make faster and more informed decisions about next steps, ensuring that the organization is learning from its own activities and results.

What They Look Like: Most typically, a Performance Report is captured as a matrix. Each line represents an important element of the project, phase, or activity. Columns are used to identify appropriate metrics. Boxes are filled in with measures for each element.

#14 – Process Flow Diagram

What They Do: Process Flow Diagrams are an intuitive way for stakeholders to understand the organization’s fundamental processes, get clarity on how work gets done, and appreciate how value is delivered. They also put other requirements activities in context. For example, a business process diagram can help facilitate more effective use case reviews by providing context for how the system functionality will support the business process.

What They Look Like: Like Activity Diagrams, Process Flow Diagrams exist in multiple forms. Most BAs create simple workflow diagrams that show the end-to-end business process.  A smaller subset of BAs use BPMN (Business Process Modeling Notation) to create more formalized diagrams. (We’ve included examples of both in the Visual Model Sample Pack.)

#15 – Process Improvement Progress Report

What They Do: When we improve a business process, we expect to see results. But how do you communicate the changes and results to executives? Commonly, a list of bullet points is created to identify changes and improvements. Taking a more visual approach, a Process Improvement Progress Report visually shows improvements made to a business or technical process as the result of a project.

What They Look Like: A Process Improvement Progress Reports contains models of the past, present, and target future states of the process and uses visual cues, such as color codes, to show the changes.

#16 – Scope Model

What They Do: The fundamental question to answer in many projects is what is in vs. out of scope. A Scope Model is a visual representation of the features, processes, or functionality in scope for a specific project, solution, or system.

What They Look Like: Scope models can take many forms and how you decide to put one together is typically driven by what project factors are driving scope. Technical integration requirements are typically represented by a System Context Diagram (more on that below).  Business needs are typically represented by a high-level business process. Feature-driven projects, such as a product for an end user, are often accompanied by a visual representation of functionality.

#17 – Stakeholder Map

What They Do: A Stakeholder Map is a visual diagram that depicts the relationship of stakeholders to the solution and to one another. Stakeholder Maps visualize the temporary structures put in place for a project to show who is responsible for what and how different artifacts get reviewed, approved, and ready for implementation.

What They Look Like: A Stakeholder Map is a lot like an Organizational Chart, except that it lays out the temporary team structure put in place to run a project instead of a permanent structure to run an organization. It can be very useful in clarifying stakeholder roles and responsibilities and identifying gaps in your business analysis plan.

#18 – SWOT Analysis

What They Do: When stakeholders are stuck figuring out how to solve an issue, whether that’s a minor issue in the project or a strategic issue facing the organization, a SWOT (Strengths, Weaknesses, Opportunities, and Threats) Analysis can clear the air and pave the way toward improved decisions.

What They Look Like: A SWOT Analysis contains 4-boxes, one for each of the four elements (Strengths, Weaknesses, Opportunities, and Threats). Within each box, bullet points are used to list appropriate information.

#19 – System Architecture Diagram

What They Do: A System Architecture Diagram identifies the system components and how they interact as part of the solution. This can help you figure out how to best organize the detailed requirements. It can also help you communicate the constraints of the solution to business stakeholders or help them see why particular requirements need to be addressed.

What They Look Like: A System Architecture Diagram contains an element for each key piece of technology. Lines are used to connect interconnecting or integrated components. Visual hierarchies can be used to link technical components to user-facing features.

#20 – System Context Diagram

What They Do: In today’s world of integrated components, it’s difficult to work on one system without impacting others. A System Context Diagram is a useful tool for confirming scope with business and technical stakeholders and ensuring you address all necessary integration requirements in your analysis.

What They Look Like: A System Context Diagram contains a central box for the primary system and additional boxes or circles for each potentially impacted system. Lines are drawn to identify integration points and specify what type of information is passed from one system to another.

#21 – Use Case Diagram

What They Do: A Use Case Diagram is useful on a project with many use cases to get the big picture of who is using the system and what functionality they can execute. The diagram can be used to establish context before an individual use case review meeting or to confirm the functional scope of a system.

What They Look Like: A Use Case Diagram is a UML (Unified Modeling Language) diagram that shows the actors, use cases, and the relationships between them. Actors are represented by stick figures, use cases by ovals, and relationships by connecting lines.

#22 – User Interface Wireframe

 What They Do: A User Interface (UI) Wireframe is a visual rendering of how a specific screen to be implemented as part of a software solution will be laid out. They are useful in generating “yes, but” conversations and eliciting information stakeholders don’t think of until they see what an application might look like.

What They Look Like:  UI Wireframes, also often called Prototypes or Mock-Ups, can vary in fidelity, or the degree to which the presentation of the UI is intended to be realized in the final application.

• A low-fidelity UI prototype may show the general layout of the screen but not the specific UI elements.
• A medium-fidelity UI prototype will show the UI elements on the screen but may not represent the actual look.
• A high-fidelity UI prototype, often called a rendering, will represent exactly how the UI should look and feel once implemented.

Which of These 22 Visual Models Can You Use Right Now?

While you wouldn’t use all of these visual models on any given project, hopefully, you’ve noticed a few that look like they can give you immediate, practical value on the project you’re currently working on.  Bookmark or print this page for easy reference at the beginning of each new project you start, and you’ll set yourself up for a faster requirements process.

These visual models are invaluable tools for establishing context, addressing communication challenges, and creating clarity – so the next time you feel your requirements process screeching to a halt, consider what visual you might use to speed the process back up again.

Download Samples of All 22 Models

The Visual Model Sample Pack contains 22 real-world visual model samples covering everything from UML diagrams to whiteboard drawings shared from the files of a working BA. You’ll be able to more easily incorporate visuals into your requirements process and get the process moving faster.

Click here to learn more about the Visual Model Sample Pack

In this video, I demo 3 different diagrams that can easily be added to your BRD. And while a full-text transcript is available, you’ll want to check the video for an insider peek into our 3 examples from the Visual Model Sample Pack.

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

Today, we’re here to talk about three diagrams that you can add to your business requirements document because BRDs can be long and difficult to understand.

Business Requirements Documents Can Be Text Heavy

While I personally no longer create BRDs, and our template toolkit does not include a BRD template, instead, we have a three-page statement, and then models for business process documents and use cases that are separate.

I know many of you do and you had a question about how your organization, or if your organization requires you to use a BRD template, how can you make it more user-friendly by adding some visual models to it?

Today, we’re going to demo a couple of diagrams. These are from our Visual Model Sample Pack. You can easily add to a BRD to make it more clear.

Add a System Context Diagram to a Business Requirements Document

The first one of these diagrams is called a system context diagram. This shows the central system under design and the primary ways information flows into and out of the system.

You see, here, we have a portal, and then we have the accounting system, internal system, email server, document management system. These are all showing how information goes back and forth between the central portal, which was the system under design, and then the other related systems. This is useful in the BRD because it can help you to show the big picture of the system and how it fits together with everything else in your organization.

It’s included in our three-page scope statement template that we offer at Bridging the Gap, and it’s included in a lot of different diagrams. It’s common diagram for business analysts to use because it brings a lot of clarity very quickly.

Add a Business Process Diagram to a Business Requirements Document

The second model you might look to create, and this one you might be familiar with is called a workflow diagram, or a business process flow diagram, or business process model. While you can create them at a low level of detail, this one is relatively detailed and dialed into a specific business process. You can also create them at a very high level to show the big picture of how the process related to the requirements in your BRD.

You can have a big picture high-level map in your BRD, and then, maybe, some supporting ones. If your BRD is comprehensive and includes all the requirements, you might include a workflow diagram for each key section of requirements that, essentially, is showing how those requirements fit together.

If you’re a higher level, then you could just have one that shows the big picture, and you can drill into those more detailed requirements than a business process model.

Add a Scope Model to a Business Requirements Document

The third thing that I would include is called a scope diagram, or any sort of diagram that shows, functionally, how you decompose or organize, the requirements.

The technique from A Guide to the Business Analysis Body of Knowledge^® (BABOK^® Guide)  is called functional decomposition. You might have more of a hierarchy than we have here, so, you could also show this as more of an organizational chart view where, maybe, job seekers have key functionality. You want to show the hierarchy between job seekers and applications, and resumes, and search. Things like that; employers, and reviewing applications, and what all the key functions employers do.

You could break this down in a hierarchy. Here, we were just showing the really big picture of what are the key features in the product platform. What are the key areas that we’re looking at and how do they…we weren’t even showing how they, really, together, we could, but we just chose to be abstract to get the big picture.

What’s inside the product platform, and what’s outside? There was a system context diagram field to this as well, even though it’s not modeled as system context diagram.

This, I would use to organize each area of my requirements. If I had a section on requirements for employers, and then a section on requirements for partners, this would be that visual model that shows the big picture, how is this document organized? How are the requirements in this document organized?

You want to look for a way to functionally organize your document and show how the business requirements or functional requirements fit within that and decompose the overall structure of your documentation.

Check Out the Visual Model Sample Pack for 22 Visual Models

These are swipe files. What you’re seeing here is the PDF. In our Visual Model Sample Pack, we have swipe files in the native format of each of the models. We have 22 different models covered. I’ve just been focusing on the visual here because it tends to be the most interesting. But inside that pack, you also get an overview of the model, a link to the BABOK^® Guide, and why I created the model. All of these were created in my real-world work as a business analyst.

A description of the different elements of that model, different terminology that can be used, and how this fits in with business analysis techniques and terminology, when you would use it, and the step-by-step guide on how to create a similar model, and finally, what to watch out for.

These are common mistakes people make with this model and how that trips them up in their business analysis work.

Again, you can download the Visual Model Sample Pack from our website. It is a paid product. It’s $97. You get 22 of these PDF documents along with the actual source files that you can use right away to start creating these in your own business analysis work.

To recap, if you’re looking to add to your BRD, the three models I would suggest paying attention to make it more user-friendly are:

• The system context diagram.
• The process flow diagram to show either that high level or maybe several of them to show a lower level detail for each area of your business requirements document.
• Then the scope model, or something that shows, in general, how this document is organized and how are the requirements in this document organized.

Those are going to take you a long way to making a clearer document that’s easier for your stakeholders to understand, easier for you to review with your stakeholders, and get lots of buy-in on that as well.

Again, Laura Brandenburg from Bridging the Gap. Happy modeling.

Click here to learn more about the Visual Model Sample Pack.

Yes…and, well, no.

Watch this short video to learn how to respond to this kind of feedback.

Key points include:

• Appreciating technical and project constraints that impact what can feasibly be accomplished.
• Understanding the true business problem to be solved.
• Helping the business stakeholders prioritize their requirements.
• Collaborating with the technology team to present possible solutions.

To learn more about the business analysis process and handling sticky requirements challenges like this, check out our free Quick Start to Success workshop.

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

How is it possible to become too business oriented, as a business analyst?

Here’s a question I’ve received a few times – BAs coming up to me and saying that they’ve received this negative feedback in their job and they’re not really quite sure what it means. That feedback is that you’re “too business oriented.”  They say you tell us all the time that we need to really engage with the business and understand what they want, what they need. How can I, as a BA, be “too business oriented?”  How does that work?

It’s interesting feedback.  As business analysts, we do start with the business. We do want to help shepherd in their requirements and solve their problems, but can we go over the top?

Feedback always tells us both something about ourselves and something about the person giving the feedback. What this says about that situation is that the person giving the feedback has a big appreciation for the technical and the project constraints.

It might be that you’re doing a great job of understanding what the business wants and the business needs, but not understanding that we have three months to do this project and what you’re offering would take us six years or three years or a year, whatever. It’s not feasible in the constraints of the project or the budget we have, or the timeline. We have to think that is what typically is meant.

I have done this before. I have gotten to the point where I’m really passionate about either a specific aspect of my business community, or a specific business need that I’ve taken over almost as a sponsor. When I start to do that, I start to forget that this has to get prioritized against other things, it may not be the most important thing to the business, it may not be the most important thing organizationally. I’ve got to shuffle this in and fit this in with all these other priorities. But I kind of get dialed into this one thing. I almost go to bat for it all the time and feel as though I’m constantly fighting to have this project, this thing, this idea receive some resources. That is what it feels like, I think, when you’re too business oriented.

How do you overcome the challenge of being too business oriented?

What do you need to do? Part of this is understanding that being a business analyst is not just receiving information from business stakeholders and putting it into the requirements. That is our job, but it’s not our job.

Our job is to help them truly solve their business problem. It may not be the thing that they come to us with in the first place. It may not be the 10 things that they want. It might be the one most important thing that they want.

If we’re going to bat for 10 things and only one or two of those things are important, we’re not going to get the most value out of implementation resources we have, the changes that we’re able to make. We’ll be working on these bottom feeder things that are not really adding a lot of value to the business. We won’t really have done our jobs as business analysts which is, really, to maximize the value that we get out of the implementation of the technology and the business process change; all the changes that go into our projects.

By the way, knowing all the ways you add value as a business analyst is really important, and this video provides a complete ROI model for business analysis.

How do you make sure you are maximizing value?

First, you’ve got to understand that real problem to be solved. You’ve probably heard me say that before and you’re going to hear me say it again. It’s so important to what we do.

Then you’ve got to help the business prioritize what they want.  If they come to you with a list of 10 things, not all 10 things are equal. Let’s rank them. Let’s sort them into three groups of high, medium, and low. Let’s do something so that we know what’s most important and then help them advocate for the things that are truly, truly important in their business to solve that problem.

But you can’t advocate for everything that they may want or desire or think would be a good idea. If you do that, that’s where that “too business oriented” comes from. You’re not helping us add more value; you’re just telling us all the things that the business wants.

You’ve got to realize that there are technology constraints and project constraints here as well. We can’t do everything for everyone. We’ve got to focus on the most valuable pieces. That’s where the BA starts to become part of the negotiation and the facilitation process. Really helping your stakeholders prioritize is a big part of it.

Next, you’ve got to get in the middle of facilitating those discussions between the business and the technology team.

In my last video, I talked about what to do when a developer pushes back or when the tech team pushes back on you. It’s kind of the same thing. Part of it is understanding their constraints. There are legitimate true constraints around the project.

• What’s feasible?
• What is possible?
• What are some of the possible solutions to this problem?

When you start to do that and you start to be on both sides of the conversation, not just the voice of the business – jamming the requests down the throats of IT – that’s when the magic happens and that’s when we really start to show up and add a lot of value as business analysts. Now we’re part of all the conversations, not just the business side of the conversation, but the business, the project, the tech team, the QA team. We’re facilitating that and we’re making sure the most valuable work gets done with the limited time and resources that we have.

If you’ve received that feedback, I hope this video helps you understand why you might have received that feedback and what actions you can take going forward to be both business-oriented and solution-oriented.

To learn more about the business analysis process and handling sticky requirements challenges like this, check out the BA Essentials Master Class and also this video proving an overview of the 8-step business analysis process framework we teach at Bridging the Gap.

(By the way, to learn more about use cases, be sure to download our free use case template.)

What’s your take? Leave a comment below.

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

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

At Bridging the Gap, we teach use cases as a technique to analyze and document functional or software requirements. We get a lot of questions like, “What about user stories?” User stories are important if you’re on an agile software development team, you probably know what I mean, and you’ve probably created user stories before. You’re wondering what’s all the noise about use cases. Why are people still using use cases?

Use Cases Versus User Stories – Thinking Versus Communicating

Use cases have been around for, literally, decades. If you gave me one tool, stranded me on a desert island and made me choose one business analyst technique, I would choose use cases. They are the very first tool I learned, the first technique I learned, the first way I learned how to analyze and document functional requirements. I really think I’m a stronger business analyst because of the focus I had and how many use cases I wrote early in my career.

That doesn’t mean in an agile environment I don’t also write user stories, and sometimes even write lighter use cases. Let me talk more about how they work together and why I think use cases are so important.

When you work through a use case and think through a use case, you’re thinking through how the user and the system interact together. You’re also thinking through exactly where variations can occur, where exceptions can occur, what has to be true before the user can even start the requirements in the path, has to be true after.

In the process of mapping that out and using the right language, it’s important to avoid passive voice, avoiding before and after; getting the steps and the sequencing clear and using very clear language, consistent terminology in your use case. In the process of going through that, often you discover questions that you don’t think about when you’re writing a requirement here, and a requirement here, and a requirement here, or when you’re writing a huge, long list of requirements.

It’s the thinking process that’s critical, especially as a newer business analyst. Trying to figure out what should I put in my user stories? Are these complete? Does this have enough? How do they thread together? It can be overwhelming when you sit down and try to look at this big, long list of product backlog items and figure out what requirements and what acceptance tests, and what acceptance criteria should go in each of those.

That’s the value of the use case and why I think it’s so important, even as we move towards more agile software development environments, especially as new business analysts, to learn the skill.

Side Note on Use Cases:

If you aren’t familiar with use cases, here’s my deep dive tutorial on how to write a use case, step by step:

Side Note on User Stories:

If you aren’t familiar with user stories, here’s how to start using them:

Use Cases Versus User Stories – Do I Really Need to Write Both?

It’s interesting. As a senior business analyst, a lot of times they’ll be like, “Well, Laura, you don’t actually suggest that I write my use cases and then break them all apart into user stories.” Yeah, as a senior business analyst, if you’ve written hundreds of use cases, like me, you probably don’t always need to actually write the use case. You’ve done it so many times you can think through it, almost, unconsciously.

As you’re writing your individual user stories from that thread of functionality, you’re thinking in use cases and you’ve got it all covered because it’s all in your head. That works once you’ve done this for a while and once you’re confident in your techniques and have other ways of managing that kind of information.

It’s hard as a new business analyst to sit down and drop yourself into that state. That’s why we still teach use cases skills at Bridging the Gap, why I think it’s so critically important, and why we see people have the a-ha’s of like, oh, this is how I need to specify software requirements. This is how I come up with the questions that I didn’t even know I needed to ask. This is how I can be confident that I haven’t missed or overlooked requirements. Those are important areas of confidence and skills to have as a new business analyst. That’s our focus on use case thinking.

It doesn’t mean that user stories aren’t important. I do think that in a lot of environments today, if you’re working with an agile software development team, you’re going to break that use case apart into user stories. Just recently, we’ve re-released our Use Cases and Wireframes course (which is now part of The Business Analyst Blueprint training program), and we’ve added a lesson on user stories to talk about that process.

Whether you’re an experienced business analyst who writes the use cases and the user stories, or whether you think in use cases and write the user stories. Or rather, you’re still just in a more traditional iterative environment that’s not quite yet agile. You’re just writing user stories which, hats off to you, it’s all good too, as long as you’re staying in that more iterative responsive collaborative mode and not waterfall, one step, then the next step, then the next step, and the hand-offs, and the throwing things over the wall. That’s a great way to be more collaborative and iterative with your team, and make sure everybody is on the same page about what the software requirements are.

Just wanted to share my thoughts on use cases and user stories. I would love to hear your thoughts. Below, there’s a lot of debate about this topic within the business analysis profession, as well as within the agile community. It’s an important topic. I think we need to talk about it, we need to understand it, we need to understand why we’re teaching different techniques, and how they work together.

Not just to facilitate an efficient software development process, but also to facilitate the right business analysis process that ensures that everyone understands the business problem we’re trying to solve.  And how we’re solving that with technology, and has a set of tools that the business community can understand, validate, review and approve in a meaningful way so that we’re building what the community needs and will benefit from with the software.

Again, I’m Laura Brandenburg from Bridging the Gap. Whether you write use cases or user stories, hats off to you for being a business analyst. Thank you for being here.

Download Your Use Case Template Today

Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.

We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

>Click here to download the Use Case Template<<

Use Cases and User Stories Are Only Two Ways to Analyze the Functional Requirements

Discover how use cases and user stories are just two types of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.

What’s Important – Get Clear on Your Business Analysis Process

Whether you are using use cases, user stories, or some other type of requirements documentation, what’s important is to get clear on your business analysis process and ensure it’s integrated with the practices of the other members of your team.

If you don’t have a business analysis process, feel free to start with ours. Here’s a video outlining our 8-step business analysis process framework:

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

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

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

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

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

Definition of an Introverted Personality

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>Looking for More Support?

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

Click here to learn more about the Effective Conversations Template Collection

If you find yourself in a business analyst role on an IT project, it’s likely that at some point you’ll need to create a functional specification – and these can take many different forms depending on the methodologies in place at your organization. But what is a functional specification? Why do you create a functional specification? And, perhaps more importantly, what goes into a document like this?

Functional Specifications Take Many Forms

• Functional Requirements Document
• System Requirements Specification
• Business Requirements Document (contrary to the name, they commonly do not include only business requirements but also functional, software requirements)
• Use Cases and User Stories, which is what we teach at Bridging the Gap.

Whatever template is in place at your organization, the purpose of the functional specification is to capture what the software needs to do to support a business user. Often it is reviewed and approved by both business and technical stakeholders. The business users confirm that yes, this is what they really want the system to do. The technical users confirm that, yes, these requirements are feasible, implementable, and testable.

The Functional Spec is Where Business Meets IT

What Actually Goes Into this Spec?

I’ll share examples of a use case and user stories. But first, let’s discuss the longer documents – FRDs, SRSs, or BRDs.

• In an FRD, SRS, or BRD, functional requirements are typically represented as ‘system shall’ statements. You’ll typically have a list of ‘system shalls’, often organized in tables by feature with a priority identified. For example, “The system shall enable course participants to submit a question.” or “The system shall enable the course instructor to view all course participant questions.”
• In a Use Case, functional requirements are typically represented as a series of steps. The use case puts a collection of functional requirements into the context of user action, which typically eliminates a lot of ambiguity that makes its way into an out-of-context list of ‘system shalls’. For example, “Course participant selects to submit a question. Course participant provides their name, selects a question category, and provides a textual question. System sends an email to the course instructor containing the information provided by the course participant.”
  • You can use the link below to download my use case template – it’s absolutely free.
• In a User Story, functional requirements are typically captured in the following syntax: “As a {user}, I can {do something} so that {I receive some benefit}. When used appropriately, the user story syntax is brilliant at capturing user goals, functional requirements, and business benefits altogether in one concise statement.  For example, “As a course participant, I can submit a question so that I get my concerns about the course materials addressed” and “As a course instructor, I can view all course participant questions so I can respond in a timely manner.”

Each of these ways of capturing functional requirements has its pros and cons.

• ‘System shall’ statements are easy to track in requirements management systems but difficult to implement and test as they are often presented without context.
• Use cases provide great context which helps get the right functional requirements approved and implemented, but it’s also easy for the scope inside a use case to expand while meeting user goals (which may not align to business goals) or for individual requirements to get lost in larger use case documents.
• User stories link together business benefits, functionality, and user goals and are often at the right level of detail to facilitate easy planning, but it’s easy to lose track of the big picture if you focus on user stories alone.

The approach you choose will often be dictated by organizational standards. In the absence of standards, you get to define your own. It’s a good idea to start by asking the business and technical stakeholders what they’d like to see in a spec, as this can help you avoid a lot of issues down the line. Believe me, I know from some personal, painful experiences.

The Importance of Use Case Thinking to Create Good Functional Requirements Specifications

And no matter what specification format you use to document your functional requirements, ensuring you get the right requirements requires use case thinking, often with corresponding wireframes.

When you think in terms of the interchange of a user and system interaction, you will get to the right level of detail in your software requirements and often discover requirements that otherwise will often get missed.

This is why we teach use cases as a core foundational skill at Bridging the Gap.

And if you want to learn more about that and get started right away, again you can download my absolutely free use case template below.

We build our profession one business analyst at a time, and success starts with you.

Download Our Free Use Case Template

And if you want to learn more about that and get started right away, again you can download my absolutely free use case template.

>> Click here to download the use case template <<

• Clear requirements are less likely to be misunderstood by business stakeholders and technical implementers.
• Clear requirements require fewer review cycles to confirm and validate them.
• Clear requirements lead to insightful questions, that show your power and value as a business analyst.

But what does “clear” really mean? And, more importantly, how do I know if my requirements are clear or not?

In this video, we cover 3 ways you can ensure your requirements are clear.

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

Hello, this is Laura Brandenburg from Bridging the Gap. Today, we’re here to talk about how to write clearer requirements. Writing clear requirements is a foundational business analyst skill and is a foundation of writing good requirements.

When you write requirements in a clear way, you are making sure that they’re going to be properly understood by your business and your technical stakeholders. Clearer requirements tend to have fewer review cycles and validation cycles because you’re focusing less time on, what does this requirement mean instead of what do we want it to mean, and what do we what the requirement to be, which is how we should be investing our time and meetings as business analysts.

This is the important one  ̶  when you write clear requirements and you take that time to make sure they’re clear, you’re going to come up with more questions…insightful questions that you can ask your business and technical stakeholders. This is going to showcase your power and your value as a business analyst.

Let’s jump right in. I’m going to share three ways that business analyst can write clear requirements, and how you can avoid mistakes and ambiguity.

Clear Requirements Tip 1 – Use Active Present Tense

The first tip, and the first thing to focus on is to write your requirements in what’s called active present tense. We have a tendency, sometimes, to use passive voice. We use passive voice when we are missing a piece of information that’s critical to the requirement.

For example:

1. Job posting details are entered.
2. Job posting details are saved.

That “is” and that “are” are indicators of passive voice. We want to avoid those like the plague in our requirements. Because it’s not clear who’s responsible for each step. I’m going to read you the alternative.

If I were putting these in a use case, I would write these two steps:

1. Job poster enters job posting details
2. The system saves the job posting details.

Now we’ve added a “who” or a “what” that clarifies who’s doing that action, which was missing before in the passive voice. We’ve replaced that “is” or “are” with an action verb that clearly describes the requirement. It’s much clearer as a result.

Clear Requirements Tip 2 – Use Terminology Consistently

The second way that we tend to be unclear about our requirements as business analysts is when we use terminology inconsistently. This can sneak into our requirements just by small variations of terms where when you have a community of people that are all familiar with the domain, they can read between the lines and they kind of know what you’re talking about.

But then, suddenly, you bring in a new developer, or you hire another person on your business team who’s sitting in on the requirements sessions, or you scale your team and some of that work is outsourced, or a new business analyst comes in and they’re trying to pick up the requirements where you left off. Those small variations are all going to create doubts. Are these really the same thing?  Is a job poster and a job posting agent the same?  Is job posting details the same as job details, or are they different?  Somebody who’s really looking at your requirements with a fine-tooth comb could either have questions or they could make assumptions that aren’t actually true.

You want to go through and make sure that you’re using terms consistently. Take the time to define them in a glossary or a business domain model, and then as you write your business processes and your use cases, or however you document your processes and functional requirements. You want to make sure you’re using those terms consistently throughout as well.

Check out this quick video for more tips on using terminology consistently.

Clear Requirements Tip 3 – Avoid Combining Requirements

The final tip I want to share with you today is to avoid combining requirements. Often, words like “and,” “or,” “before,” and “after” mean that you’ve lumped multiple requirements together. It’s easy when you have that kind of lumping together, to focus on one part of the requirement and not the other and have either the business stakeholder miss validating part of the requirement, or the technical stakeholder and tester miss implementing part of that requirement. I’m just going to read you an example and see what you think.

“Job poster enters job posting details and reviews them before saving.”

Is that a clear requirement?  There are a lot of active verbs in there. There’s not passive voice, but there are three requirements in that statement. I’m going to read it again. “Job poster enters job posting details and reviews them before saving.”

There’s a requirement for entering the job posting details. There’s a requirement for reviewing them. And there’s a requirement for saving them. Before saving, there’s this whole other requirement that kind of got tagged at the end with those two words.

If you were discussing that for implementation, some of those requirements would be likely to get missed. There’s a lack of clarity in our requirements. When we break it out in separate requirements, it’ll be much clearer.

Make Your Requirements Clearer Using These 3 Simple Checks

What I want you to do as a next step is use these three checks. I want you to go and look at your most recent requirements document, whatever kind of requirements document it was, and see if you can find any corrections to make.

As a bonus step, this is where your career starts to take it to the next level, see if you can find another business analyst in your organization or outside your organization, go to your local chapter meetings and collaborate, connect with another BA, and review each other’s documentation. What’s going to happen as you do that, is you’re going to learn a lot more. It’s harder to see our own mistakes. It’s easier to see other’s mistakes.

This is why we offer instructor reviews as part of our virtual, business analysis training courses because people will go through the courses, go through these detailed checklists we provide, and they still don’t see their own mistakes, and then an instructor can point it out. The switch flips, and they’re able to make that correction.

You can do this on your own by doing peer reviews within your company or outside your company. You’ll learn a lot when you review somebody else’s as well because you’ll see what doesn’t come across as a clear requirement, and what kinds of ways that you need to improve your documentation to make sure it’s clear as well.

I want you to go ahead and do that. Please comment below any aha’s you’ve had from this lesson, any takeaways, any action steps that you’re going to take to review your documentation and share that with others.

Again, my name is Laura Brandenburg from Bridging the Gap. We help you start your business analyst career.

>>Improve Your Requirements Writing Skills

When you join The Business Analyst Blueprint® certification program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

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

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.

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

Some notes:

Virtual Meetings Are a Huge Opportunity

Opportunity #1 – Strengthen Your Communication Skills

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

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

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

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

Opportunity #2 – Shift to Virtual Work

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

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

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

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

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

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

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

Virtual Meeting Best Practice #2: Verbalize Body Language

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

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

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

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

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

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

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

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

>> Start YOUR Path to Success

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

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

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

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

Thanks for being here.

>>Looking for More Support?

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

Click here to learn more about the Effective Conversations Template Collection

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

The answer might surprise you…

To learn more about the 8-step business analysis process framework, click here to register for our Quick Start to Success free training.

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

Starting a Business Analysis Career without a Process Framework

Hello, this is Laura Brandenburg from Bridging the Gap. Today I want to talk a little bit about our business analysis process framework. Before I dive into that, let me just tell you a little bit about how I got started as a business analyst and what that looked like.

The brief story is before I was a business analyst I was a Quality Assurance professional.

I asked so many questions in those requirements meetings as a QA analyst that they eventually said, “Why don’t you come over on to the other side and help discover and analyze these requirements yourself?” That is the briefest story (read the elaborated story here), but I was doing a lot of business process analysis, a lot of test case creation and planning as part of that QA role that set me up for that business analyst role.

Not Too Much or Too Little: Building a Business Analysis Process Framework that Makes Sense in the Real World

In that business analyst role, I definitely felt in way over my head and I was lucky to have a mentor. We didn’t have a process. We had some templates that we used and some basic structure for our project. We didn’t have a step-by-step of how to approach our work. We didn’t realize that there were other people at other companies doing work like us. We thought we were special and unique and in this role that was only applicable in our organization.

A lot of BAs in the world today, maybe even you, have felt like this until you stumbled across IIBA® and the fact that there’s a title for the work you do as a business analyst or business systems analyst or business process analyst, whatever you want to call it.

What I learned as I moved from company to company and started the switch industries and then eventually built a team of business analysts and project managers and quality assurance professionals, and then by becoming a contractor and being exposed even more companies and methodologies and industries and realized that I didn’t have to make this up as I went along. There was more the same than there was different.

My work on the project was different. The templates I used in one organization were often a little bit different than another. The questions I asked were very specific to that to mean that I was intuitively following a set of best practices and a best practice approach. I was what you might call an unconscious competent. I was very competent and successful as a business analyst, but I wouldn’t have been able to teach someone else about it.

Fast forward a little bit and I did start to train other business analysts through Bridging the Gap all the way back in 2008. At that time I still didn’t think I had a process. I’ll just be totally honest there. I started teaching the techniques first.

We taught business process analysis and use cases and wireframes and data modeling. Those were the first courses I developed because I knew how I could apply those techniques and we always use them on our projects. But I didn’t have an intro to business analysis or how to get started as a BA, we just focused on the techniques.

I kept seeing this burning need and people were asking me, “Why approach a project?” “What do I need to do to be effective?” “What does it look like from point A to point Z?” “What is the 1, 2, 3 look like of business analysis?”

There were a lot of other options in the industry, but quite honestly, my perspective on those is that they were quite heavy. Heavy meaning they required more time and more formality than most of us had in our real-world work.

A Business Analysis Framework Created from Successful Projects

When we’re in an organization that doesn’t go by the book and needs us to be successful anyway, and so what we needed as a profession was a very simplified process, one that would be both thorough but flexible and that focused on the core essentials of what it took to be successful and effective as a business analyst. And one that would save business analysts’ time rather than creating a lot of extra busywork. Kind of mind-blowing.

On the other hand of our industry, we had too much formality and then we had agile approaches. We still have agile approaches today. Agile is amazing as a software development methodology in practice. Agile is not a business analysis process.

In fact, the success of an agile team depends on so much business analysis happening before we get to a product backlog.

• What problem are we solving?
• What is their key goal here?
• Who is aligned around the scope of this goal and how we’re going to move forward with this goal?

And what the requirements need to be.

We assume that this business analysis has happened before we start, what is covered in a traditional agile approach. We needed, as BAs though, to be cognizant of this and we needed to simplify our process and focus on the essentials. What happened is I saw one of the biggest mistakes that BAs would make when they would be faced with an agile transformation or their organization was going agile.

This is the biggest mistake besides just digging in and resisting it. We know that doesn’t work. The other mistake, once we didn’t dig in and resist it, we would throw away all the important bits and pieces that would truly make us successful as business analysts. We would focus on the agile techniques and lose out on the business analysis techniques that made us successful.

When I sat down and thought through my most successful projects and what I had done and how I had created those successes, what came from that was the business analysis process framework, and it’s really a middle ground. It’s what you need to do to be effective and how to make decisions about what’s important and what’s not important and how to connect our business analysis practices with whatever methodologies, software, project management are in place in our organization. It’s important to be a great partner with everybody else on the team.

I combined what I had done with what I had seen working from our participants all across the globe and hundreds or lots and lots of industries and from that evaluation came the BA process framework.

Since that time, we’ve helped hundreds of business analysts learn and apply this process. It does help people from not even yet a business analyst to even a more senior business analyst. Let’s talk about how it applies in those different situations.

Newer Business Analysts Leverage a Framework to Exceed Expectations

A newer business analyst, they might not know where to start or what expectations to set. They often get into a BA role and feel like they’re going to sink or swim in a situation and nobody’s telling them what to do, but everybody has extremely high expectations of them. They get to avoid a lot more of the more common pitfalls that, quite honestly, most of us need to learn through experience, or most of us had to learn through experience.

How about somebody with a bit more experience who’s learned a few of those lessons and has a fairly consistent track record of success? What I find is that we still have a couple of key challenges that we face again and again in our projects. Or we get into a new environment and we’re not quite sure what to do because we’re that unconscious competent.

So those common challenges, they often come back to just one or two steps of the framework we’ve been skipping. That isn’t needed in my organization, or that doesn’t work for me. We can’t make that work because. When they fill in those gaps, their projects move forward much more smoothly.

They also start to elevate their role as a business analyst in their organization. One of our participants, Amelia McHenry, participated in our full The Business Analyst Blueprint® program first and then joined the BA Essentials Master Class where we teach the business process framework.

Amelia reported going into a rather new role. She was a newish BA at the time. Had quite a bit of professional experience, but it was her first real official business analyst role. There were senior BAs who had a lot of experience that she was working with but she brought out the questions from Step 2, which is discover business objective, and she asked those in a meeting.

She used those to help understand what problem are we trying to solve here? What is the ideal solution look like? The people in that meeting, which were pretty high-level stakeholders, were super impressed. They were like nobody’s asked us these questions before.

This is great business analysis. We need more of this in our organization.

Her credibility in that organization went from the new somewhat having some business analysis experience, new in the organization, new to the domain to top level. This is the person who’s bringing that next level of capabilities to our organization.

There’s a lot that comes from your personal credibility, especially as a more intermediate BA when you start to apply these learnings and these teachings and have the courage to ask the questions that you should be asking.

More Senior Business Analysts Leverage a Framework to Train Others Successfully

How about a more senior business analyst? What I find and what my personal experience was, even as a manager of a BA team, I knew intuitively what made me successful. I knew how to be successful, but had a lot of trouble setting that up in terms of a structure for my team because I hadn’t sat down and created this process framework yet, and quite frankly, I didn’t believe it actually could exist.

I wish I could go back and change that for my team and for myself, but when we do teach a more senior BA to go through this process and they start to see how it’s worked for them in so many of their successful projects, then they could also effectively mentor and train other business analysts.

Instead of being able to maybe be the go-to person that BAs come from for guidance or you’re kind of always in the mix of all the projects because nobody else can do things like you can do, you develop this ability to clone yourself by training other BAs to handle any situation. That’s a next level skill set and it sets you up to be more of a leader and a manager or just get out of the day-to-day grind of having to be everything to everyone.

Even Aspiring Business Analysts Can Leverage the Framework to Increase Their Confidence

Finally, let’s talk about people who aren’t not yet BAs and what happens for them.

Thomas Clarke was one of our participants who was a research assistant when he took the BA Essentials Master Class. Then soon after moved into a project management role within his company doing a lot of business analysis work; a lot of finding the problems and figuring out the solutions and overseeing the solutions to those problems.

What he said is it just gave him an approach. He didn’t know where to start. A lot of “not yet” BAs are scared of getting their first BA position because they don’t know what they’re going to do when they get that first position.

Learning the approach and realizing there is a step-by-step process that they can go through gives them more confidence that when they’re in that situation they will have an approach to follow. They will have handouts and questions and next steps and be able to drive the process forward and they won’t have to make things up as they go along.

If you want to learn more about the process framework, what it is, what the steps are, how it might work for you, I invite you to click here to register for our Quick Start to Success free training and learn more. I’d love to teach you about the business analysis process framework and help you be more effective as a business analyst because we build our profession one business analyst at a time and success starts with you.

Again, I’m Laura Brandenburg with Bridging the Gap. We help you start and succeed in your business analyst career.

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

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

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

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

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

Effective Meetings Tip #1 – Create an Agenda

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

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

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

Effective Meetings Tip #2 – Prepare Deliverables

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

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

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

Effective Meetings Tip #3 – Set the Stage

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

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

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

Effective Meetings Tip #4 – Keep the Meeting On Track

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

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

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

Effective Meetings Tip #5 – Close with Next Steps

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

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

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

To Recap…

Those are my five tips. Just to recap:

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

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

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

Download Your Free Business Process Template Today

> Click here to download the Business Process Template <<

>>Looking for More Support?

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

Click here to learn more about the Effective Conversations Template Collection

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

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

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

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

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

Building Confidence #1: Get Clear On Your Purpose

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

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

Building Confidence #2: Learn from a Trusted Resource

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

Sometimes it’s trusting yourself.

Building Confidence #3: Take Action Before You Are Ready

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

The confidence comes when people take action.

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

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

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

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

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

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

Building Confidence #5: Celebrate the Small Wins

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

Success creates more success. Confidence creates more confidence.

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

Building Confidence Tip #6: Take Responsibility for Mistakes

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

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

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

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

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

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

>>Looking for More Support?

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

Click here to learn more about the Effective Conversations Template Collection

But how do you actually make sure your solutions are cost-effective? In this video, you’ll learn 3 ways to use your analysis skills to find more cost-effective solutions.

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

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

One way that business analysts add value is by exploring and finding more cost-effective solutions to business problems which will save their companies time, and resources, and free up energy to work on other projects as well. A lot of times we think we need a really big solution where a small change might be just as effective.

Other times, we really do need to make very substantial systems updates or deploy new systems, but we kind of tend to lop on a bunch of fluff that doesn’t end up serving the business in the most impactful way.

And, so, in both of those situations, good business analysis can help reduce the overall cost of the project and find more cost-effective solutions to the true business problem.

I want to share three ways that we can find more cost-effective solutions as a business analyst.

#1 – Find Cost-Effective Solutions by Solving the Right Problem

One is by focusing on solving the right problem. We take time as business analysts to understand what the problem truly is. That gives us the information we need that sparks creative ideas to finding more effective solutions.

For example, we are updating our learning management system right now at Bridging the Gap. It’s the system we use to deliver course materials to our participants, and that we envision enabling more communication directly between our participants and instructors.

Right now, there’s a middle administrative piece to that that’s creating unnecessary time lags at times and, also, just unnecessary work from an administrative perspective in terms of funneling emails and forwarding them back and forth and assigning them to people. We know that there’s a more cost-effective solution out there, and also, that we can solve some key problems.

The main problem that I was focused on solving when we started this initiative was eliminating that administrative overhead because, honestly, the way that we’re scaling and growing and able to serve more people, we are at our limit for how far we can scale that system. It’s at its breaking point.

I’m sure you’ve seen processes that worked really well when the business was at one level, but then as you grow and expand, you realize this process doesn’t scale super well. That’s where we are with that process.

As we started exploring that problem, we realized there was also a huge opportunity to deliver more value to our customers. A lot of our instructors, because they’re full-time business analysts, actually do their coursework, support our participants over the weekend.

Our customer service team, because they’re customer service, is their full-time or their main job with Bridging the Gap. They work Monday-Friday. Requests would come in on Saturday morning, and the instructor would be checking in to answer them, but that email hadn’t been forwarded yet, so they didn’t know that work was there. There could have been an immediate response and feedback loop, if we didn’t have that manual step in place.

We realized we could solve both problems at once, both delivering more value to our customers, and eliminating an administrative process that wasn’t scalable.

That’s what I mean. Focus on, “What problem are we trying to solve?” That became the guiding light as we started this learning management system.

#2 – Find Cost-Effective Solutions by Exploring Business Process Changes

The second way that you explore more cost-effective solutions is to explore business process changes. You know your problem that you’re trying to solve. That often triggers new ideas. We had some brainstorming and came up with some ideas of how we could solve that problem.

Along the way, we explored business process changes as well. We knew it didn’t have to take a lot of technology, even though we started looking at how we could use technology to solve that problem.

Our customer service team had already implemented some spreadsheets to do some tracking and some ways that she adjusted the emails when she forwarded them to instructors to make that more streamlined.

We could have also gone down the road of hiring a different support person who would have checked the email box over the weekend to funnel along anything that came over the weekend. That would have been a manual solution to serve that goal of quicker turnaround time.

As we started exploring the features, it was interesting. We were talking through what the workflow would be and we ended up going down the road of a very customized solution on top of a course delivery platform. We were talking about, “Oh, we could do this,” “We could make this forwarding feature. We could do this.” We had to dial it back to what are the core things that we need. This is when you understand the problem that you’re solving, you can eliminate that fluff.

We took this big system and we made sure that we were honing in on just the requirements we needed from the beginning. That’s what we do as business analysts is focus on the problem we’re solving, and the business processes that can solve that problem. That meant, in some cases, that we were keeping manual processes even though we could “automate.”

One of the examples is issuing the certificate of completion. We’re still evaluating, to the degree to which that will be automated vs. manual. It might mean that an instructor has a task for the administrator to go in and check that off and deliver that certificate of completion.

It could mean there are ways that we could automate the whole process, but it’s pretty technically complex and it would cost a lot more money, and that’s not where the pain point is right now. We understand the problem that we’re trying to solve. That piece isn’t necessarily critical to solving our current problem.

It might be a problem we have to solve a year or two down the road as we scale even further. But right now, I could see how we could get around that through a manual business process.

And, so, being open to not having to have the technology solve every single part of the workflow in order to deliver value. That’s how you eliminate that extra fluff that weighs your project down and gets you off focus.

We’re doing that now, but I could see if we decided to do that, it could be months from now. We haven’t even implemented the solution because we’re still trying to figure out the certificate of completion requirement, or something like that.

That’s what happens to technology projects that just kind of go on and on and on.

#3 – Find Cost-Effective Solutions by Leveraging Available Tools

The third way is by leveraging available tools. Always want to look around in your business, like, do we have a tool that can do this now or even partially do this now?

It doesn’t always have to be building something new, and it doesn’t always have to be licensing or buying something new. Often, you can use the tools you have to add on.

One of the ways this is coming up for us in this same project is we realize after going down through all the different aspects of the project that, a help desk or a support ticketing system was going to be the best system to manage this instructor/participant interaction and help us manage that workflow in a more automated way.

We had been going down the road of a course delivery platform thinking that was going to give us those messaging capabilities, and it didn’t. So, we’re looking at how can we integrate that help desk system into our current course delivery platform to solve this very specific problem first while we simultaneously look at upgrading the course delivery platform as well.

It’s not to say we’re not going to do that, but we might be able to approach those two parts of the project separately. We’re going to leverage the existing tool we have in our way of communicating/add on a different way of communicating.

The other piece about the help desk is as I started looking at those tools, there is other functionality that they have like chat features and we can use them for all of our customer support, not just the course participant piece.

I started to see how this one investment in a tool now, even though we’re going to focus, still, on our main problem to be solved, will not work everywhere. But I could see how this one tool we could leverage it in the future to add additional value to our business and streamline other areas of our business.

And, so that got me excited thinking about this tool as being an investment that we could build upon. It makes projects in the future more cost-effective. Not because we’re implementing those requirements now, but because we’re thinking about them as we choose this tool.

Those are just some ways as business analysts, that we could explore more cost-effective solutions. That is going to help us achieve a better ROI in our project. It pays our salaries. If you can think of it that way.

Every time you eliminate a big chunk of software that’s needed, or a big chunk of solution implementation that’s needed, and replace that with something that’s more simple and elegant, that has just paid your salary and then some.

That’s how you establish your reputation as somebody everybody wants on their project because I know that they’re going to help me get the most possible value out of the investment I have to make.

We’re going to free up resources for the next set of changes, and the next project and be able to move more quickly and in more agile ways in the organization.

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

Be thinking about how you can explore more cost-effective solutions in your projects. I’d love to hear your suggestions. Go ahead and leave a comment below.

What do we do if stakeholders keep changing their requirements? How can we ever be done? And how can we ensure we are maximizing the return on investment for our projects?

That’s the topic of this video.

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

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

Today, I want to talk about requirements change because we know that one of the ways that we add value as business analysts is by reducing the rework and the requirements churn that happens in a project where somebody isn’t managing the requirements and communicating and collaborating about the requirements effectively.

As business analysts, we get everyone on the same page about what “done” means, and what a successful project looks like. We help facilitate the communication of how multiple people contribute to that solution and can fill their role to make sure that solution delivers the value in the end.

But what if requirements keep changing and stakeholders keep changing their mind about the requirements? What do we do? That’s what we’re going to talk about in today’s video.

The first thing, I’m going to share 3 tips, really simple tips, about how to manage and reduce unnecessary requirements change on your project. A super important way that we add value as business analysts.

#1 – Minimize Requirements Changes by Solving the Right Problem

The first way is that we understand the problem that we’re solving and we make sure we’re solving the right problem. You hear me say this again and again, but it’s so important, it’s so fundamental. And in our business analysis process that we teach at Bridging the Gap, it’s steps 2 and 3 of the process. Step 2 is defining the business objectives, and step 3 is defining the scope.

When we skip those steps, which we’re often tempted to do because it’s like just start coding or just start writing the requirements. Don’t worry about those business objectives. Just tell me what I need to build. Get me the requirements as quickly as possible. Big pressure that we feel.

When we skip steps 2 and 3, and we’re figuring out all these detailed requirements, that’s when they tend to change the most. All that time we saved not figuring out our business objectives and getting alignment from our stakeholder community around scope, is essentially time that gets re-purposed in churning through the details requirements again and again. Because we’re trying to hit what feels like a moving target.

One day we’re solving the sales problem, and the next day we’re solving customer retention, and the next day we’re solving a sales problem again. And our requirements keep changing because the problem that we’re solving in this project isn’t understood clearly by our business community, isn’t understood clearly by us, and so we have a challenge of shaping the requirements to solve that problem. Number one; way easy. If you do nothing else, do that, and it will help reduce requirements change.

#2 – Minimize Requirements Changes by Reviewing and Validating Your Requirements

The second tip is to think about your review and your validation processes. Do you have all the right people in the room in that process? Are you walking through the requirements in such a way that your stakeholders can truly understand what they mean and how they’re going to impact them and their business?

Often, we might, historically, have a long list of functional requirements or, in current day, have a long list of user stories. So, you’re like reviewing these individual pieces one at a time. Okay, do you want this? Is this good? Do you want this? Is this good? It’s hard to keep track of the big picture, and it’s hard to see once I have all these individual requirements, is this what I want as a business user?

Thinking about how to include more analytical models and more visual models is why we do business process models, use cases, wireframes, process diagrams, and entity relationship diagrams, context diagrams showing how the system is going to work, and helping people see their role in that system is a more useful way of doing that validation. When you’re getting the requirements approved, people know what they’re approving and how that’s going to impact them.

#3 – Minimize Requirements Changes by Communicating Implications of Change

The third tip that I want to share with you is to be clear about the implications of change and what it means to actually approve requirements. We could say, “Oh, you’re signing on the dotted line.” So, what? I can change my mind. We’ve got a change request form. How do we change? There’s always going to be room for some change in projects, but clearly identifying what the cost of that change is.

One example, my very first agile project, they were like, “Laura, we need the requirements by Monday. We’re going to have our sprint planning meeting. Please just do your best and get them to us in the best possible form. If we have to change them later, it’s no big deal.” This is what the developers told me. I was like, okay, it’s agile. Change isn’t a big deal anymore. I drank the Kool-Aid. And then it comes two days, and I had one stakeholder that I couldn’t get time on their calendar to confirm the requirements.

And, so, I knew that the requirements were not validated the way that I would have liked. So two days into that first sprint was a two-week sprint, I got time on that person’s calendar. We walked through and we made some changes, and I had the adjustments to those requirements, those user stories that they were building from. I was like, okay, now I’ve got them final. They were like, “No, no, no, we’re going to wait until the next sprint to make those changes.”

Then, when I went into the next sprint planning meeting with the updated requirements that they just had two weeks implementing, they weren’t super happy with me as their business analyst because they were like, “Well, we just spent two weeks implementing something and it was the wrong thing.” I was like, yeah, that was the cost of me not being able to confirm those requirements ahead of time and the pressure that we had.

Being clear with your business community about the implications of the change, as well as your development community, if they’re pressuring you to have the requirements “done” before you’ve done the validation that you know you need to do, those are both ways that we need to step up as leaders, as business analysts, and we need to say, “This is when we know the requirements are done. This is what it means, like to our business users, this is what it means to be done.”

Somebody is going to go build this. If you want them to build it again, it’s going to be another sprint, which will either delay other requirements that you have, or it’s going to add costs to the project. Making sure that kind of message is getting in front of the people that actually are in charge of the costs, or are in charge of the scope and so they understand the implications of what change means from that forward.

You’ll find, when you start to have that conversation with people they’ll be like, “Oh,” and they’ll start dialing in and paying more attention to the walk-throughs because they understand there’s a downstream impact if they make a change after that point.

That doesn’t mean that there’s no change. It just means that you’ve done the best work you can as a business analyst to eliminate and minimize unnecessary change, which is change that just comes up because people aren’t paying attention, they’re not reviewing the documents, and they’re not understanding the documentation. They’re not communicating clearly about what they want.

So, you’re still going to have some change in projects. Project environments will change, business goals will change, things outside your project will impact your project. You’ll see what’s been created and you’ll discover new needs and wants, and those will get reflected as changes into your project. There’s always going to be some change. You want to reduce the unnecessary change that just comes from, quite honestly, lazy business analysis.

That’s my tip for you today. Please leave a comment below. What adjustment are you going to make to your requirements process to reduce unnecessary changes to the requirements?

Again, I’m Laura Brandenburg from Bridging the Gap. We help you start your business analyst career.

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

And missed requirements cause unnecessary rework on software development projects.

While use cases aren’t always the best business analysis technique, they are a perfect choice more often than not. And in this video I share the 3 situations in which they are absolutely the perfect tool for your work as a business analyst.

Download the Use Case Template

You can download our Use Case Template for FREE. The best part is that when you learn to analyze requirements in use cases, you can look like the smartest person in the room by avoiding these common challenges:

• Validating that the use case reflects true end user needs.
• Describing system and user steps at the right level of detail.
• Ensuring your software requirements are clear and complete.

>> DOWNLOAD FREE USE CASE TEMPLATE <<

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

This is Laura Brandenburg from Bridging the Gap. Today, I want to talk about when to write a use case. Because I love use cases. Not everyone does, but they are a useful analysis tool and I can guarantee you, if you’re writing software of functional requirements today, and you’re not at least thinking in use cases, you are missing requirements.

What are the scenarios that we need to be either writing a use case, or making sure we’re thinking strongly in use cases?

Use Cases Defined

First, let’s talk about what a use case is.

A use case is a textual document that outlines the system functionality in the context of user actions.

Think of it like ping pong. A user does this, the software system does this. A user does this, the software system does this. Back and forth, back and forth until a goal is accomplished for that user.

That goal is pretty discreet. It’s something that a software system can do. Not like “better life” or “improve your process”.

Goals like:

• Find customer
• Generate report
• Deliver document.

Something very specific, very concrete that the software can do.

That’s what you’re documenting in a use case. You’re getting specific about the software functionality and the sense of what software functionality is visible to a user, not what’s happening underneath the hood, not how the technology is designed, but what does the user experience with that software.

If you aren’t familiar with use cases, here’s my deep dive tutorial on how to write a use case, step by step:

What are the situations when we’re documenting functional or software requirements like that where we would use a use case?

#1 – Utilizing Use Cases to Document Existing System Functionality

The first one that comes to mind is when we’re documenting functionality of an existing system. Systems tend to grow up and they get messy and complicated.

One of the jobs I was in, they had a document delivery system that had been in place for 10 or 15 years before I started there as the business analyst, and they never did full testing or requirements or analysis of what they were building, and they just kind of kept adding on pieces. Software systems have this, especially legacy ones like that, get to the point where you’re duck taping pieces together to make things work.

It seemed like every time we went to enhance that system, or add on to that system, or introduce a new capability, something over here would break, and we wouldn’t know why because it was challenging to do the analysis about how that system worked because we didn’t have a full set of documentation about how that system worked.

One of the things I took it upon myself to do is to go and start to work with a developer and the business sponsor to understand the capabilities of the system and the logic that was happening behind the scenes, not in terms of the technical, how is it built, but things were getting routed in very specific ways and flowing through the system. I did this so that we could start to see the big picture of how that system actually worked so when we were analyzing requirements to add on and enhance that system. We could better gauge the impact that we were going to make and look at the impacts of new requirements on that full system instead of just the piece we were focused on improving.

It ended up adding a lot of value and made that system, even though it was still difficult to maintain, easier to update and improve upon, and definitely easier for new business stakeholders who were getting involved in the business to understand the scope of what it did and think through the implications of the requests and the requirements.

Use cases are great tools to analyze existing functionality.

#2 – Document Functionality for New Systems in Use Cases

The next thing to think about is functionality for new systems. Say we were going to replace that system. We would need a new set of use cases that define the requirements and capabilities and the user actions that could be supported in that new system.

Sometimes, today, we are using COTS systems and SaaS systems – Commercial Off The Shelf and Software As A Service Systems – are definitely getting much more prevalent, but there are still cases where we’re building custom code existing systems from the ground up inside our organizations.

In that case, every single feature that you want to build, and that you’re building from scratch, every user goal needs to have a use case defining what those requirements are. That’s what your developers can use to build from and your testers can use to test from, and your business stakeholders can use to wrap their mind around what the system that doesn’t exist yet is going to do from them, and how does it fit into their business process. That’s a big part of it. It needs to go together.

Use case is much more defined and discreet than the business process itself. That’s the second time is when you’re creating a new system from scratch. Definitely want to be analyzing that and thinking through that in use cases.

#3 – Specify Updates to Existing Systems in Use Cases

The final case is what if you’re updating an existing system? A lot of us have existing systems today and we’re making those little tweaks like I talked about in the first scenario. Let’s just update that and add this here, and add this here. It’s a great opportunity to also create a use case, especially if you don’t, if you can combine where you’re analyzing what exists today and what’s the incremental change that we’re making to what exists today.

This helps you think through that impact of all the places that requirement might affect until you put into a use case or thinking, oh, we’re just adding this little field to this page. And then you put a use case around the goal associated with that, and any related goals, and you start to see, oh, added that field affects this thing over here, and it affects this report over here. It helps you start to think through some of those implications.

When you’re updating that functionality, one tip of what I like to do, I like to color code my use case so that the current state functionality is represented just in general black/white documentation and then color code enhancements or the changes so that it’s clear what we’re changing, what we’re retiring, what we’re adding on to, and that can make it easy to break that apart into specific design tasks for user stories, if you’re using user stories to implement your requirements, or to manage your software development process.

Yes, agile software development teams can most certainly benefit from use cases! Here is what Dave Gallant had to say about applying use cases and user stories on an agile team.

Bonus – Design Customizations and Configurations of COTS/SAAS Systems in Use Cases

Related to this enhancing new functionality, a lot of us, today, aren’t actually enhancing the functionality in our company systems; we’re enhancing the functionality of systems that we’ve licensed or bought from third party vendors. That would be the COTS or the SAS system like I talked about before.

You can still use use cases, then, to talk about what those customizations would be, or even like an area that’s going to be heavily configured, you can think of that as an addition to existing functionality. Maybe out of the box the system does one thing and you can configure all of these different ways. It’s mind-bending, I think, to try to jump into what are all the configurations we want out of the box solution.

It’s difficult for a business stakeholder to think what all the configurations are I want. I don’t know. I know when I sit down, and I use the screen I want it to look like this. I know when I go from here, to here, to here, to here, these are the things I need to accomplish. Putting that functionality together in a use case, as opposed to a list of configuration options, can be useful as a way to walk through what that system will be like once those configurations are made, or once any enhancements and customizations are made as well.

Jami Moore did this for an area of functionality on a Salesforce project, and look at the feedback she received:

Use Cases – a Beautiful Way to Get to the Functional Requirements

There are just three scenarios to be thinking about applying use cases in your projects. Again, they’re focused on the functional or the software requirements. The software that’s delivering value to your business users. Use case is a great tool that business users with a little bit of training and walk through can understand and dig their teeth into to understand what the software is going to do from them, and then your technical stakeholders can use to design and build the system, and your testers can use to generate all kinds of test cases. The test cases almost just like fall out of the use cases. It’s kind of a beautiful process.

Be thinking about where you could be using use cases in your environment. What are the tricky project challenges? That functional requirements list just isn’t working for you anymore. I hope this helps you think about where you might introduce my favorite requirements tool, the use case, into your business analysis process.

Again, I’m Laura Brandenburg, from Bridging the Gap. We help business analysts start their careers. Thanks for watching. Thanks for learning more about use cases.

Download Your Use Case Template Today

Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.

We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

Click here to download the Use Case Template<< 

Use Cases Are One Way to Analyze the Functional Requirements

Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.

Use Cases vs. User Stories

Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.

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.

So, you’ve heard the news – your organization is going agile. Or you are looking for jobs, and every single one requires agile experience.

What does this mean for you, your career, and business analysis? How do you leverage your skills and experience in more traditional, waterfall environments to succeed as an agile business analyst?

That’s what we cover in today’s video.

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

Agile is a huge opportunity for you as a business analyst.

I’m Laura Brandenburg. I’m the creator of Bridging the Gap. Today, I’m going to share exactly how you can move forward as an agile business analyst with a waterfall background.

First of all, agile teams definitely need business analysts. We give the requirements and the insight that help that agile team be successful. This is a huge opportunity for you as a business analyst.

Waterfall to Agile Tip #1 – Ground Yourself in Core Business Analysis Practices

The first thing to do, it’s important to just ground yourself in core business analysis practices and why they are important. This doesn’t mean you get to stick to your old way of doing things and kick and scream about how essential you might feel it is to create a BRD, a business requirements document, or an FRD, a functional requirements document, or whatever type of document you are used to creating as a business analyst.

This means you have the opportunity to look at why you create that document.

• What value does it provide?
• What do you find most helpful about it?
• Where would the team fail if you took it away?

I believe that business analysts create clarity and eliminate ambiguity. Your existing documentation is likely one tool for analyzing the requirements and doing so with clarity. There are many tools that you can use to do the same thing. So, understand your value. Your why. What you do and why it’s important. That’s your first step because you want to go into the agile team with that inner confidence and that inner self of value and personal power.

Waterfall to Agile Tip #2 – Let Go Of Your Existing Templates

Second, it’s going to be the hard one, let go of your templates. All of them. Poof. Just let them go. They’re gone.

You’re on a new project.

• What are you doing now?
• What questions are you asking?
• What decisions are you driving?

Take a moment to visualize if you let go of everything you do today, what would you do, what would you truly need to document and why? This can be a thought experiment. You don’t have to throw away all those templates and all that work. But can you trim it down significantly?

In our Business Analyst Template Toolkit, I provide my very streamlined shorter templates. They’re great alternatives to traditional BRD or FRD you might have been used to creating in a waterfall environment.

Waterfall to Agile Tip #3 – Collaborate with Your Agile Team

Talk to your agile team. What would help them the most? I’ve been on several agile teams and they all wanted different things from me on different levels of detail.

• What information are they expecting to have in place, and when do they need it?
• What deliverables will help them the most?
• Do they want to see wireframes, or data models, or use cases, or user stories?

They might not know. And if so, you can provide some examples and ask for feedback. They might have a very specific set of expectations.

When shifting to agile, it can feel like a lot of our traditional tools just get thrown out the window. I can remember my first agile project. I knew I had to trade my beloved use cases for user stories. I didn’t know what that meant. And so, it turned out that I still needed all of my use case thinking skills, and the user stories nearly became another way to package and communicate those functional requirements.

My core business analysis skills – that gaining clarity, that discovering needs and requirements for business stakeholders, clearly documenting, and analyzing, all of that was absolutely, positively essential to my agile team. Agile didn’t replace them and, actually, augmented the need for them. Even though our skills are important, we do need to shift some aspects of our work, so we can deliver the most possible value and earn the respect of our agile teams.

In the three steps I walked you through – thinking of your “why,” owning your value, discovering why it is you do what you do, at least going through the thought experiment of just throwing your templates away and coming up with what is essential to your success as a business analyst – and then deeply and intently, and consciously collaborating with your agile team.

Learning enough about agile practices, like user stories and product backlogs, and then going to your team with some ideas and getting their feedback along the way to make sure you’re creating requirements and documentation that help them deliver working software more quickly.

You do these three things, and your transition from waterfall to agile might not be easy; there might still be a few kicks and screams, but it’s going to happen with more ease and grace, and you’re going to come out on the end, probably, appreciating some of the positive changes that you can experience, and your teams can experience, and your organization can experience when they transition to agile. I know I did.

It was a lot of fun getting to work on an agile team and getting to see my requirements become more closely modeled in reality and becoming a closer partner with the tech team than I had in more traditional environments. It’s a great way to accelerate my career and see more positive change happen more quickly for organizations.

I hope you had a lot of fun with it. I hope that it helps you grow your career. I’d love to hear what’s coming up for you as you go from waterfall, or traditional approaches, to more agile business analysis practices.

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

Thanks for watching.

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

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

So, without further ado – Trick or Treat!

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

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

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

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

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

Trick #1 – You Didn’t Get This Right

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

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

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

Trick #2 – Hearing Crickets

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

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

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

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

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

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

Trick #3 – That’s Impossible

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

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

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

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

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

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

Have a happy Halloween! Talk to you soon.

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

And that might leave you wondering what exactly you should do when your organization is running a cloud implementation project? While specifying requirements at a detailed functional level tends to become less important, as most tools are not infinitely customizable, and therefore you run the risk of excluding potential vendors or creating nearly impossible implementation plans.

3 Types of Requirements are Essential on Cloud Implementation Projects

Yet, there are still some very important areas of requirements to consider. In this video, I walk you through the 3 categories of requirements that will make for a more successful cloud implementation.

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

Today I want to talk about an important shift in the software industry that’s impacted the business analysis role, and that’s the introduction and the acceptance of more cloud based solutions or software as a service, otherwise known as SaaS solutions.

Lisa asked a question, “Knowing that the industry and many companies now are opting to license these sorts of solutions rather than build custom software in-house, how does this affect the level of detail that I need to go through as a business analyst? It seems like I should be able to be a little bit less detailed about my requirements.” Lisa is correct. Let’s talk about what the requirements process looks like on these kinds of projects.

The Requirements Process on Cloud Implementation Projects

Lisa is totally right. It’s not necessary to get as detailed about the functional requirements of the software system because you’re licensing something that’s already been built. You don’t have to specify, in exact detail, of what that thing needs to be. It’s already built. That’s part of what you’re buying as an organization. To invest a lot of time in specifying those details wouldn’t make a lot of sense.

However, there are still some important requirements deliverables and pieces to put together. They allow us to add even more value as a business analyst.

We’re going to talk about three models – business process models, configuration, and customization requirements, and then, finally, data models.

Cloud Implementation: Business Process Models

First, let’s talk about business process models. When you are implementing that new system, it’s probably replacing something that exists today or giving your organization functionality that it doesn’t have today. That’s going to impact your business processes.

When we implemented a new shopping cart, we got some integration with our email management system which allowed us to eliminate a bunch of manual processes that were in place before (or our As Is Business Processes). There were a few things that we had to do a little bit differently because of the way the orders were coming in. We had to go and update those business processes, or create To Be Business Processes.

Cloud Implementations Provide Great Opportunities to Introduce Efficiencies

We had to eliminate some business processes, which is also a great thing from an efficiency standpoint. But if you never go back and do the work to figure out what you can eliminate, business users will continue doing what they’ve always done and you won’t achieve that ROI on the project. Looking at how that business process is impacted by the new software is important. There are new features that you’re buying from that software that are going to add value to your organization – making sure your business processes are in place, and actually use those features and receive that value in your organization.

A great way to start analyzing a business process is by creating a process map – here’s a video tutorial on creating a process map.

Cloud Implementation: Configuration and Customization Requirements

Most of the larger more competitive tools available today offer some level of customization. It’s not like just one thing and you have to use it as is. You can add some custom feels or customize some workflows, choose how you link things together or display things on the user interface.

It’s important to walk through and understand the capabilities of that tool. Usually, side by side with your business processes, look at the tool and discuss those configuration options to make sure that you’re configuring the tool to receive the most possible benefit from that tool for your organization.

The Difference Between Configuration and Customization Requirements

• Configuration is what that tool enables out of the box.
• Customization is what you would add, new functionality that would be specific to your organization.

Usually, you’re going to pay for customization. Not all tools enable you to do that kind of customization. In that case, it’s just the same process as when you build new software. In your organization, you’re going to need those more detailed functional and visual requirements to make sure you’re clearly communicating what you want that new system to do.

You can model configurations and customizations in use cases. Here’s a video tutorial on analyzing software requirements using a use case:

Cloud Implementation: Data Migration Requirements

Finally, let’s talk about data modeling requirements. These are extremely important when you are going into the cloud for a set of functionalities.

There are two sets of data requirements to be aware of. The first is the data migration requirements. Is there any data that your organization manages today that might be in a software system, might be in a spreadsheet or somebody’s Access database? Who knows where that data is. That’s part of the analysis process, to figure out what data do we want to pull into that new system, and how does that map over?

Often, that starts at a very high level, like, we want our customer data to map over, we want our order data to map over. Then you get very granular. We need the customer name, the customer ID, the customer address. Here are the specific fields that it’s going to map to. You want to look at those data migration requirements, or data maps.

Cloud Implementation: Data Integration Requirements

The second piece is once that system is in place and running in your organization, are there any other systems that it needs to talk to? That is called data integration or system integration requirements. You want to look at the system you’re using today.

• Does that talk to any systems?
• If so, how do you replicate that using the new system?
• Is there just an efficiency to be had by implementing an integration?

When we built our new shopping cart, we got that integration with our email management system. That enabled us to eliminate a lot of manual business processes, but we also had to make sure we configured things to get that right. That was a big feature that we were choosing the shopping cart for, the ability to do that. We really paid attention to make sure that integration point was implemented correctly.

You want to look at those things as well. Sometimes you’ll have to replace integrations that already exist today. Sometimes they’ll just have to be updated to make sure they’re working with the new system.

Data mapping is a next-level skill for a lot of business analysts, and it’s absolutely essential for cloud implementations. Here’s a data mapping tutorial:

Cloud Implementation – Don’t Overlook Important Selection Criteria Early On

What we didn’t talk about in this video are the selection criteria that you might use to choose one of these systems in the first place. In many cases, it’s not like there’s just one solution. There are dozens of solutions out there and you want to make sure you’re choosing one that meets your business needs, your security requirements, is going to work within your work flow, have the key functionality you’re looking for, and integrate with your systems. It’s a whole other topic about choosing the right vendor or choosing the right tool.

What we talked about today is once you’ve chosen a solution, what are the requirements analysis deliverables that you need to work through to make sure that you can implement that solution and deliver real value to your business.

Just to recap, those are business process models, configuration and customization requirements, and data models.

Cloud Implementations – Frequently Asked Questions

What types of requirements should I analyze for cloud implementations?

You’ll want to pay special attention to business process models, configuration and customization requirements, and data mapping requirements when specifying requirements for a cloud implementation.

What kinds of requirements do I not need to analyze for cloud implementations?

When you are implementing a cloud solution, you don’t need to specify the detailed functional requirements for the software that already exists. Focus only on the configuration and customization requirements.

What’s the most common requirements mistake in cloud implementations?

Overlooking the business process and failing to analyze how business users will use the new system. Comprehensive business process analysis is necessary to ensure a seamless transition.

A second common mistake is failing to do a detailed analysis of what data will be migrated into the new system, and ensuring that data fields are mapped appropriately to support the business.

How can I learn more about data modeling?

We have a free data modeling tutorial walking you through the most common data modeling techniques, and how to apply them on a real-world project.

In this video, I share exactly what to do in this situation.

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

Today, we’re going to talk about a common challenge that business analysts face and that’s what to do when you’ve created your business analysis plan with a forecasted date for finishing the requirements, but your project manager ignores it and sets a different deadline for you anyway.

Well, this happens more often than we would think as business analysts because project managers also face aggressive deadlines, but also because we often tend to want more time as BAs. And, so, we can forecast dates that really aren’t supported by the project manager of the business.

So, what do we do? Let’s talk about it and dive right in.

These tips are from Lesson 4 of the BA Essentials Master Class. There are a 5 shifts you can make to shift your requirements deadlines.

Requirements Deadline Shift #1 – Make Sure Your Deadline is Realistic

First, you want to make sure that your requirements deadline is practical and realistic. We have a tendency, as I was mentioning, as BAs, to get a little bit perfectionist about our thoughts about what’s going to happen. We can be a little bit of, worst case scenario thinking. We can see all the things that could happen in our projects to go wrong, like stakeholders not turning up to our meetings, or new requirements surfacing late in the business analysis process. We tend to bank all those things that could go wrong and the time it takes to be perfect into that original deadline that we set for ourselves.

In general, the better stakeholder engagement we have, the faster the requirements process will unfold.

Requirements Deadline Shift #2 – Evaluate Best Case versus Worst Case

Does your project manager want the worst-case scenario or the best-case scenario? Often, they’re probably looking for the best-case scenario. So, the date that they gave you might have been thinking more best case rather than worst case. They want to handle those things that could go wrong as assumptions, risks, or constraints on the project that are managed separately from the timeline.

So, really, understand from your PM, do they want the best case or the worst case, and then encourage yourself to think about that best case. That’s how you get a little bit more realistic and practical about what is it really going to take to do the requirements. What’s the best that you could put forward in terms of a deadline?

Requirements Deadline Shift #3 – Provide 2 Dates

The other thing you can do is give them two dates. You can give them your best-case date and your worst-case date if all the things that you’re probably expecting go wrong, you’re going to be right about some of those. So, you want to, maybe, give them the second date. If some of those things do go wrong, what would the date be? That could add value to manage expectations as you go through and implement the project.

Now, often, just this kind of simple tweak and how we talk about deadlines and how we put our deadlines together can solve issues. That might bring your project manager’s deadline more in alignment with your deadline, and that might get you to close enough to move forward. But it doesn’t always work out that way.

You might really, truly be doing a very practical best-case scenario for your timeline and your project manager might still say, “Oh, I need it two weeks earlier” or “two months earlier.” Some significant time earlier that just is truly causing you to freak out. What do you do then?

Requirements Deadline Shift #4 – Create a New Plan that Cuts Scope

You could just get started and say it’s not going to work and see when we get to that deadline that I’m still working on the requirements. But another option would be to offer a new plan. This time you want to cut scope from your business analysis effort of the plan, or you could make changes to the plan that introduce additional risks to the project.

Some of the things that you might consider when you cut scope or introduce risk is not meeting with a group of stakeholders. Or instead of meeting with multiple stakeholders from every department, you just pick one that’s a subject matter expert and move through the requirements quickly without giving them, necessarily, time to collaborate with their team. So, you’re getting a more isolated set of input on the requirements that would allow you to move more quickly. You might miss requirements when you do that. It’s not perfect, but it could be a realistic way to try to achieve that timeline.

Wondering about the difference between business analysts and subject matter experts? This video lays out the different roles – as well as how to collaborate together for maximum impact.

Requirements Deadline Shift #5 – Eliminate Requirements Deliverables

You might eliminate certain requirements documents from your plan. Say you were planning to do business processes, use cases, wireframes, and a data model, all courses that we teach, all important techniques that have their time and place in business analysis.

Here’s an entire video on the top requirements documents you want to consider creating as a business analyst.

Maybe it would be possible, though not ideal, to skip the business process step and jump right into the use cases, which is going to give the development team what they need. Maybe you can circle around later and do that business process step for the business team. Just another idea.

Essentially, you want to offer a solution to achieving that deadline, achieving that date, and then be clear about the risks and the assumptions that you’re making so that when those things do surface and you do have to slip on that timeline a little bit, it’s because one of those things happened and you can communicate that and be managing expectations around that.

Those are just some ideas for what you do when your project manager hands you a requirements deadline that you feel doesn’t work. You really want to make sure your deadline is realistic and practical, and eliminate that perfectionism and see if you can meet them halfway, and then educate them about the business analysis process as you go

And, again, remember to join us in the BA Essentials Master Class for a practical, real-world approach to applying the business analysis process.

Navigating Deadlines is Easier When You Have a Business Analysis Process Framework

And if you don’t have one, feel free to start with ours!

In this video I share the 3 things you should do first, that will set the stage for an effective requirements process.

How Can I Start a New Project as a Business Analyst Most Effectively?

These 3 steps will get you started on a new project as a business analyst in the most effective way possible.

• Get context about the project, particularly whether this is a new project or one that’s been worked on before.
• Meet with key business stakeholders to start building relationships.
• Understand the key business objectives for the project, and each stakeholder’s perceptions of those objectives.

(For an end-to-end project approach that will help you be more effective as a business analyst, check out my FREE Quick Start to Success workshop.)

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

Today, I wanted to talk about three things that you really should do when you’re assigned to a new project as a business analyst and you wanted to get started quickly and effectively – just three things to keep in mind on your next project or maybe the project that just landed on your desk today.

Start a New Project as a Business Analyst – Step #1 – Get Context

The first thing to do is to get context. It’s not unusual for you to just receive an email about a project and go make it happen, and go start writing the requirements. You really want to take a step back and just get a little bit more context.

• Is this a new project or is it a project that’s been worked on before?
• What kind of stakeholders have been involved and how have they been involved?
• What systems and processes does it impact?  Like if there’s that level of detail around it so far.
• What’s the context of the team like?
• Is there a specific methodology that you’re supposed to be using or is that something that you’re going to have to come up with from scratch?

So, first, get context. Figure out where you are and where to jump in, because if you jump in and start writing requirements not really know about the history of what’s happened before in a little bit bigger picture detail, you could get started quickly, but in a super wrong direction.  So, quickly, but not really effectively.

Start a New Project as a Business Analyst – Step #2 – Meet with Key Stakeholders

The second is to meet with any key stakeholders. Typically, it’s going to be that person who sent you the email. Again, to get a little bit more context and establish a working relationship. But it might not be somebody you’d met with before. So, you do want to introduce yourself, share what you know about the process and the project, and just get to know them and start that positive working relationship.

Cultivating relationships is absolutely key to engaging stakeholders effectively, and building stakeholder engagement is key to effective business analysis. Nothing you do happens in a vacuum.

In a lot of projects, it’s not just one sponsor that you’re responsible for working with. Usually, there are a couple of key business stakeholders. So, take some time and meet with each of them.  What you really want to be asking about, which is the third thing to do on the start of the new project, is partly the context that we talked about before, but also, what are the business objectives?

Here’s a video with some great strategies on building engagement with stakeholders:

Start a New Project as a Business Analyst – Step #3 – Understand the Key Business Objectives

“Business objectives” is just a fancy word for, “Why are we doing this?”  What you’ll find, especially if you have a couple of different key stakeholders, is often, their sense of the business objectives is a little bit different from person to person to person.  By meeting with them and understanding what’s important to them about the project and why they feel like it’s an important thing to do here, you’re going to start already creating that bridge.

You want to create a shared understanding and context for the project so that when you do start jumping into defining the scope and holding requirement solicitation sessions, you are going to know what they want to have achieved through that project.  You’re going to know what differences to expect among those stakeholders.  You’re going to be able to plan more effective meetings to make sure that we’re getting everybody on the same page quickly and effectively.

Facilitating effective, working meetings is such a critical aspect of business analysis. This video is loaded with quick and easy tips to make your meetings more effective.

Quick Recap on How to Start a New Project as a Business Analyst

Those are the three things to do before you jump into writing requirements or even before you jump into writing a scope statement for a project.

To review:

• You want to get a little bit of context about why this is happening, what’s been done before – if it’s new or if it’s something that you’re bringing up. Or if it’s been revisited before, but then it was put on a shelf.  Context is all about your team and who you’ll be working with.
• You want to meet with those key business stakeholders and start building those relationships that you could leverage over the course of the project.
• And, finally, you want to understand why we, as an organization, are investing in this project.  And what is each key stakeholder’s perception of that “Why?”

Those are three things to do before you jump in and just start writing the requirements that are super important. And even though they take a little bit of time up front, they’re actually going to help you move more quickly and effectively to getting clear requirements, to creating meetings that truly get work done, and to really shine in your role as a business analyst.

>> Start YOUR Path to Success

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

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

Amplify Your Effectiveness with the Step-by-Step Business Analysis Process Framework

Once you get started, you are ready for an end-to-end business analysis process framework.

This video covers the framework in depth. Leveraging a structured process like this will set you apart as a business analyst, and help you add more value and create credibility within your role.

Here are a few key points:

• Re-frame what the developer means by “that’s impossible”…everything is possible, given unlimited time and budget.
• Be sure to understand the true business need, and not present a business solution.
• Collaborate to find possible solutions to the real problem, which may not even involve technology changes.

To learn more about the business analysis process and handling sticky requirements challenges like this, check out the BA Essentials Master Class.

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

I wanted to jump in and talk to you today about what to do when we hear from the development team, “That’s impossible.”  I know I’ve heard that my career.  We actually just had it come up with a course participant last week that she had this beautiful business need that had come out, a really exciting way to help the business.  She brought it to the developer and he’s like, “No, we can’t do that.  It would require re-engineering the whole database. It’s way too big.”  “Impossible” is what he said.

In the reframe on that, we’re going to talk about three steps that you can take and three things to think about when that happens.  The reframe is that everything is possible. It just maybe isn’t feasible given the budget that you have, the timeline that you have, and the current technology you have.

#1 – Define “Impossible”

“Impossible” really means we may have to spend three months reworking the database to solve the problem in the way that she presented the solution to that developer.  That could be true.  That developer may be thinking, “I know I have 10 other things on my list and nobody is going to approve this.” And that really is what impossible often means.

The first thing you want to do is unpack what does “Impossible” mean?  It’s never that it’s not possible; it’s usually that it’s not feasible given a certain set of assumptions.  The more you understand that, the better that you can do as a business analyst to come up with a feasible solution to the true business need.

#2 – Clarify the True Business Need

That’s the second thing you want to do is clarify what the true business need is.  In this case, it’s not so easy to do.  The business came up with a solution.  They say, “We want these specific data elements removed from our process.”

The developer responds, “We can’t do that.  Those data elements are connected to all kinds of other things and it has an impact on reporting, and it has an impact on other parts of the application that aren’t even touched by those business stakeholders.”  It has this broader impact when they were just saying, “Well, let’s just remove those three fields on the screen and then our problem is solved.”  That isn’t really the business need.

What was the business need driving the removal of those fields?  That was how they were setting goals with the clients.  There’s a deeper need there.  Their work performance was being tracked based on something that they couldn’t control.  That’s a huge thing.  There are a lot of factors that go into resolving that, not just the technology.

That is the first lesson. Look at the true business need so that you can understand the true scope of the solution which may or may not be just the technology.

#3 – Reframe What Impossible Means

The third piece we talked about, reframing what impossible means.  First, you find out that true business need so you can go back to the developer with a business need instead of a business solution to the problem.  The next piece is to figure out a way to collaborate to move forward.

What needed to happen from there is to get a couple of the key business stakeholders together with that technology stakeholder.

• Maybe there are some other people to be involved and talk about that business need and brainstorm together possible solutions to this problem that aren’t, necessarily, to remove those fields completely.
• Maybe they can be disabled.
• Maybe different content can be captured in those fields.
• Maybe they can be made optional.

All kinds of different possibilities exist.  At least give the group the benefit of having some time to talk through that and to come up with possible solutions that may or may not be what the business originally presented.

Oftentimes, our best developers are going to come up with creative solutions once they understand that true business need.  Our jobs as BAs is to be in the middle of that process so that we’re communicating, helping our business stakeholders understand what their true need is and not just what they see the solution as.  Then helping the technical stakeholders come up with solutions that meet those underlying needs.  This is what we do as a business analyst.

“That’s Impossible” is an opportunity to step up as a business analyst

When that example came up in class, I was so excited.  I was like, okay, this is where the juicy stuff happens that we get to deal with as BAs.  This is a normal thing to have happen.  The course participant was a little frustrated.  “Why did this happen?  I finally had this great idea and it just got brushed aside.”

No, it’s an opportunity for us to step up, for us to engage, for us to really facilitate solving the true problem to be solved there.  It’s not the time to step back, it’s the time to step in, but to step in in a much different way than, “Really, you can’t do this?”  Let me show you how it’s possible. It’s not stepping in or forcing the developer to a specific solution.  It’s stepping in to facilitate that collaboration process so that the most possible value can be delivered from the technology in the best possible way.

That’s a lot of what we do as business analysts.

To learn more about the business analysis process and handling sticky requirements challenges like this, check out the BA Essentials Master Class.

Here is a list of 65 business analysis techniques that are useful to know about. Not that you would use every technique on every project (though some of these are definitely my tried-and-true, go-to, techniques), but so you have a toolbox of ideas to refer back to when your business analysis process isn’t flowing like it should, so you can get your project unstuck and moving forward again.

**If you’d like to expand your business analyst toolbox, take a look at our business analyst templates. At $97 for each toolkit (or $347 for the Bundle of all 5), these provide an affordable way to bring a wider variety of techniques to your business analysis work.**

And please feel free to add a business analysis technique in a comment below. Just be sure to include a description so we know what it is and/or link to an article that shares more detail about it.

1. Active Listening – A communication technique that involves paraphrasing back what you heard during a conversation to confirm understanding.
2. Agenda – A document containing the pertinent details for a meeting, including an objective and list of topics to be discussed.
3. As Is Process Analysis – Defines the current state of a business process in an organization.
4. Brainstorming – A spontaneous group discussion designed to generate ideas without initial critique or evaluation.
5. Business Analysis Plan – Document that summarizes the business analysis approach, list of deliverables, and schedule for completing the business analysis deliverables.
6. Business Domain Model – A visual model that logically represents the business concepts to be fulfilled by the system and how they relate to one another.  It should not be confused with a data diagram, which represents the actual database design or architecture.  Although they may look similar, a business domain model should use terms that are in the business domain.
7. Business Process Model – A step-by-step description of what one or more business users does to accomplish a specific goal. Those steps can be manual, paper-based, or software-based.
8. Business Process Modeling Notation (BPMN) – A standardized notation for creating visual models of business or organizational processes.
9. Business Rules – A statement that defines or constrains some aspect of business.
10. Change Request – A document or collection of information summarizing a change to be made. Often associated with a formal approval process.
11. Competitive Comparison – Document or matrix comparing the current or potential future state of a product or system to that of an organization’s competitors.
12. Conference Call – A meeting conducted via a conference bridge, with multiple participants joining from different physical locations via a phone line.
13. Data Dictionary – Also called a Data Definition Matrix, provides detailed information about the business data, such as standard definitions of data elements, their meanings, and allowable values.
14. Data Feed Specification – A document containing the business and technical details involved in exchanging data between organizations. Can be used as part of managing API integrations or other types of ongoing data feeds.
15. Data Flow Diagram – Illustrates how information flows through, into, and out of a system. They are especially useful when evaluating data-intensive processes and looking at how data is shared between systems or organizations.
16. Data Mapping – A specific type of data dictionary that shows how data from one information system maps to data from another information system. Creating a data mapping specification helps you and your project team avoid numerous potential issues, the kind that tends to surface late in development or during user acceptance testing and throw off project schedules, not to mention irritating your stakeholders.
17. Deliverables List – A list of deliverables to be created as part of the business analysis effort for a project or initiative.
18. Document Analysis – The process of analyzing documentation to discover information related requirements.
19. Entity Relationship Diagram (ERD) –  A data model describing how entities (or concepts or things) relate to one another. When created by business analysts, ERDs can be used to understand the business domain, clarify business terminology, and connect business concepts to database structures (see Business Domain Model above).
20. Feature Map – A visual representation of multiple features, often user stories on a product backlog, that shows their relationships.
21. Given When Then Statements – A formula for writing acceptance tests for a user story. Given (some context). When (some action is carried out). Then (description of observable consequences, or requirements).
22. Glossary – A deliverable that documents terms that are unique to the business or technical domain. A glossary is used to ensure that all stakeholders (business and technical) understand what is meant by the terminology, acronyms, and phrases used inside an organization.
23. Grooming the Product Backlog – A process for reviewing new product backlog items for clarity, estimation, and priority, prior to or during sprint planning.
24. Interface Analysis – The process of analyzing an interface, such as a user interface to connect between two software systems, to discover information related to the requirements.
25. Interview – A session with one to multiple stakeholders to ask and answer questions related to any aspect of the problem, project, or requirements.
26. Issues List – A document or repository that contains a list of all issues relating in any way to the requirements for a project.
27. Meeting Notes – A document capturing the essence of topics discussed during a meeting, along with any resulting decisions and action items.
28. Mind Map – Suggested by Bola Adesope, a visual model with a topic in the center that shows a hierarchical relationship between different concepts and ideas. This is a great tool for brainstorming.
29. Observation – The process of observing people using a system or executing a process, often in their actual work environment, to discover information related to the requirements.
30. Organizational Chart – A visual model representing the organizational hierarchy in place for an organization or a part of an organization.
31. Performance Measurement – Process of collecting, analyzing and/or reporting information regarding the performance of an individual, group, organization, system or component.
32. Performance Report – Document or model showing the results from a project, project phase, or business activity.
33. Portfolio Management – Process for organizing, prioritizing, and showing relationships between multiple active and proposed projects for an organization.
34. Problem Definition – The process of discovering and defining the actual problem to be solved by a project or solution.
35. Process Improvement Progress Report – Visual model showing the improvements made to a business or technical process as the result of a project or initiative.
36. Process Walk-Through – A working session in which subject matter experts walk through a future state process to validate it.
37. Product Backlog – List of all requirements under consideration (written using a user story syntax), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization for an agile software development team.
38. Project List – A single list of prioritized projects under consideration by a team or organization.
39. Prototype – A functional visual model that shows the user interface of a not-yet-built software system. Often prototypes allow for some limited interaction based on sample data.
40. Requirements Questionnaire – A list of questions about the project requirements. Typically the questions are organized by feature (or business requirement or project objective).
41. Requirements Review –  A meeting gathering stakeholders together to walk through the requirements documentation, page-by-page, line-by-line, to ensure that the document represents everyone’s complete understanding of what is to be accomplished in this particular project.
42. Retrospective – The process of reviewing a work completed (often for a project or segment of a project) to discover and bring forward lessons learned.
43. Root Cause Analysis – The process of analyzing a problem to discover the underlying causes, or true issues, creating the problem.
44. Scope Model –  A visual representation of the features, processes, or functionality in scope for a specific project, solution, or system.
45. Stakeholder Analysis – A document defining who is part of the project team and what they are responsible for.
46. Stakeholder Map –  A visual diagram that depicts the relationship of stakeholders to the solution and to one another.
47. Stakeholder Request List – List of requests related to a project or solution prior to defining scope.
48. Survey – A series of questions posed to multiple stakeholders in an asynchronous format, such as an online questionnaire. Useful for gathering lots of information from multiple people.
49. SWOT Analysis – A visual model showing information about the Strengths, Weaknesses, Opportunities, and Threats an organization faces.
50. System Architecture Diagram – Visual model that identifies the system components and how they interact as part of the solution and can help you figure out how to best organize the detailed requirements.
51. System Context Diagram – A visual model defining the primary system to be addressed during a project or initiative and the relationships between the primary system and other systems.
52. To Be Process Analysis – Defines the future state of a business process in an organization to clarify how the business process will work, at some point in the future, once changes are made.
53. Traceability Matrix – Suggested by Nikkita Nguyen, this document is used to map business requirements to functional requirements.
54. Triple Constraint – A model showing the balance between project budget, schedule, scope, and quality.
55. Use Case – Use cases are a type of textual requirements specification that captures how a user will interact with a solution to achieve a specific goal. They describe the step by step process a user goes through to complete that goal using a software system.
56. Use Case Diagram – A UML (Unified Modeling Language) diagram that shows the actors, use cases, and the relationships between them.
57. User Acceptance Testing – A validation process in which business users use a new solution, often before it’s deployed, to confirm it will meet their needs.
58. User Interface Specification –  A document defining the rules of engagement for a user interacting with a specific page on a website or screen within an application.
59. User Story – A short document capturing a description of a software feature from an end-user perspective. User stories are often written in the following syntax: As a ____ {user}, I want ____ so that ______. User stories are often coupled with acceptance criteria (see Given When Then Statements).
60. Video Conferencing – An expansion on a web conference, where participants are also able to share video of themselves.
61. Vision Document – A document describing the business objectives and scope of a project.
62. Web Conference – A meeting held via a webinar, online meeting, or combination of screen-sharing software and conference bridge, with multiple participants joining from different physical locations via an internet connection being able to all see one visual screen and talk to one another.
63. Wireframe (Also called a Mock-Up, Related to a Prototype) –  A visual representation of a user interface screen, typically one that is fairly low-fidelity.
64. Workflow Diagram (Also called Activity Diagram) – A simple visual model that captures the steps, decisions, start point, and end point of a functional, technical, or business process.
65. Workshop – A meeting in which real-time collaboration on one or more work products, such as requirements deliverables, occurs inside the working session.

What business analysis techniques do you use most often? Do you have a favorite technique that’s not included on the list? Please share it via comment below and be sure to include a short description to define what it is and when to use it.

And, if you’d like to expand your business analyst toolbox, take a look at our business analyst templates. At $97 for each toolkit (or $347 for the Bundle of all 5), these provide an affordable way to bring a wider variety of techniques to your business analysis work.

I vividly remember my first project. I’d be flying along, thinking that this whole new BA role was so fun and amazing. Then an unexpected issue would pop up. I’d feel like I was taking 5 steps back as we muddled through balancing business desires within technical constraints.

What I needed were some touchstones to gauge if I was really on the right track or not. Having gone through dozens of projects as a business analyst, I now have some touchstones that ease my concerns, even when it feels like everything is incredibly messy.

Here are some questions you can ask yourself week to week, which will help you feel more secure in whether or not you are doing this right, or whether it might be time to invest in some training or engage a mentor to help you out.

• Is my work moving the project forward in understanding? What are some of the concrete decisions we’ve been able to make based on the analysis I’ve done and the discussions I’ve facilitated?
• Am I receiving questions from my stakeholders, showing that they are really understanding the requirements and working from them? Silence is not golden! Silence often means you are out of the communication loop, which means your work is not being seen as essential.
• Do I see people taking action around the requirements? Action could be design, code, testing, or even research. Any sort of resulting action is a sign that you are on the right track and your work is having an impact.

Of course, even when you are moving forward and doing things right, issues will come up. No matter how well it’s done, business analysis does not happen in a perfectly linear way. Click the link below to read an article from our archive with quick tips for managing requirements issues:

http://www.bridging-the-gap.com/quick-tips-for-managing-requirements-issues/

As always, I wish you the absolute best success as a business analyst, and I look forward to helping you in any way that I can.

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.

Sound portfolio management enables key business executives to make informed decisions about project priorities and enable a more focused project delivery process. Many organizations are able to transition away from barely managed chaos as a result of implementing simple portfolio management practices.

With a portfolio management process in place, you will:

• Clarify organizational priorities.
• Allocate organizational resources towards the top priority projects.
• Actually finish the most important projects on the list!

This might sound complex, but it’s actually quite simple. Watch the video for more detail.

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

Hello. This is Laura Brandenburg from Bridging the Gap. Today, I want to talk about barely managed chaos. How do you know if you’re working in barely managed chaos? Here are some of the complaints that we receive from our community all the time.

• First, you might be in a big picture meeting or in a big project, and requirements keep getting added and added to that project and there’s no container for those other requirements. That project gets so bloated that it never gets off the ground. You’re doing a lot of work, but not a lot of implementation.
• Another scenario is you spend a little time here, a little time there, you’re constantly experiencing shifting priorities, new requirements popping up, new projects that are more important than what you’ve been working on, and you go from one project to the other without ever actually finishing anything. Again, it comes to getting it done and getting it ready for implementation.
• You manage to get some requirements that are pretty close to implementation, but now your developers get pulled off. You’re ready to go on this strategic important initiative, and they got pulled away from your meeting or your review, or even the project altogether to work on some top priority project for a very influential executive.

Do any of these sound familiar?

The solution to this kind of challenge is a project list. It’s relatively simple in theory. Inside my Project Prioritization Organizer, I share my template for the project list, as well as some supporting process documentation and guidance about how to put this kind of process in place in your organization.

Today, I want to share some of the simple practices and ways that you need to set this process up to ensure success.

Project Portfolio Management Tip #1 – Everything goes on the list

When you start managing all of your organization through a project list, one of the big rules is that everything has to go on the list. You can’t have some stuff on the list, and some stuff not on the list. It ALL has to go on the list, otherwise, the list loses its value; it loses its authority.

You have to keep line items for any project that’s pulling the business analysis team, that’s pulling the business stakeholder team, that’s pulling the development team; you’ve got to keep it all on one list. That’s the first key. If it’s not all on the list, then it’s going to become a distraction and it’s going to create chaos in your nice, organized environment of the list.

Project Portfolio Management Tip #2 – Update the list every week

The second thing, in order for this to work, that list needs to be updated routinely, often, every week. That means new projects get added to the list. That’s okay. We’re always going to have new ideas. If there are fire drills, they need to get added to the list. If something new, top priority, comes up, it needs to get added to the list.

That is this constant process of adding to the list, and removing things from the list, either when they become irrelevant, or not a priority, or when they get done. We get to celebrate and update the list as things get done as well.

Project Portfolio Management Tip #3 – All key stakeholders regularly review new items

The next thing is that all stakeholders must regularly review the new items. This isn’t all the stakeholders, but all the key stakeholders. You need to have all the different business areas represented so that nobody feels like their work is cut out, and everybody has a chance to negotiate for their items on the list to get attention, to get resources, and to get prioritized.

That’s an important point. That list is not just a list of all the things; it’s a prioritized list of all the things. It shows what things we’re working on, and what things we’re not.

Project Portfolio Management Tip #4 – Be sure the delivery team honors the list

This is a really important one. I’ve seen a lot of organizations do all this work to get their business team aligned and negotiate priorities and decide what’s the priority and what’s not, then their delivery team doesn’t honor the list. So, the delivery team has to honor it as well.

That means if super influential VP stops by developer Joe’s desk and asks you to start working on something else, or if you, as the business analysts, get asked to work on something else, you say, “Where does it fit on the list?”  Or, “It’s going to take away from my work on this other thing that is a priority on the list. So, could you make sure that this gets aligned and you make some decisions about those priorities as a stakeholder group?”

Everybody has to respect the list and respect the priorities. As soon as people start not respecting those lists and those priorities, that’s when the chaos comes back in because now we’re pulling all this attention away from what our business team had set as top priority.

Project Portfolio Management Tip #5 – Align projects on the list to strategic objectives

A final thing, which is not necessary, but is super helpful, is that you align what’s on the list to the strategic objectives of your organization. This happens every year. Your organization comes out with this big picture objective and all these things that they want to have done, how they fit together in the big picture, and then your team sets off to work on other things.

We want your project list to align to those strategic objectives and show how you’re making progress against those objectives. It will be a lot more powerful tool that way. If your organization doesn’t have strategic objectives, don’t worry about it. Just start with a list and it will help surface information about those objectives.

I’d love to hear what you think about this idea. Leave a comment below. How do you see a project list helping your organization?

Again, this is Laura Brandenburg with Bridging the Gap. We help you start your business analyst career.

>>Learn More About Managing a Project Portfolio

Our Project Prioritization Organizer provides a complete set of processes and templates to get out of barely managed chaos and start managing project priorities in a nice, neat project list.

Click here to learn more about the organizer.

Use cases are a valuable requirements tool for capturing functional requirements in the context of user actions. Along with their super-powerful side-kick, wireframes, they can be a tool to finally get everyone on the same page about software requirements.

But some very common use case mistakes make use cases difficult to understand, and can actually create more ambiguity about the requirements.

You can avoid a lot of pain and suffering for everyone on your team by being sure you don’t make some of the most common use case mistakes that lead to ambiguity.

(These are real mistakes that I see again and again in the first drafts of our business analysis course participants, but not in their second! And if you are ready to get started writing a use case, be sure to download our free use case template today.)

Download the Use Case Template

You can download our Use Case Template for FREE. The best part is that when you learn to analyze requirements in use cases, you can look like the smartest person in the room by avoiding these common challenges:

• Validating that the use case reflects true end user needs.
• Describing system and user steps at the right level of detail.
• Ensuring your software requirements are clear and complete.

>> DOWNLOAD FREE USE CASE TEMPLATE <<

Use Case Writing Mistake #1 – Include User Interface Details

By far the most common mistake we see in use cases is that they use the language of the user interface to talk about the user behavior. For example, instead of  “Actor X creates a new account” they read as “Actor X clicks the new account button (or tab, or whatever).”

Using user interface details leads to ambiguity.  This is counter-intuitive because “clicks the new account button” seems much more specific than “creates an account.”  However, sometimes the name of the user interface element doesn’t clearly identify the action the user is taking and so it creates ambiguity about the actual step that we need from the user for the system to be successful. (Moreover, if you happen to change the name of the button or the tab, you could have a lot of use case updates to make. Talk about a maintenance nightmare!)

But, we’ve gone on for awhile about this mistake. Let’s get to the others, because there are plenty!

Use Case Writing Mistake #2 – Not Specify a System Response to a User Action

The next most common mistake we see, especially from individuals without a lot of exposure to information technology projects, is that the use cases are very business process-oriented. The use case is crystal clear about all the steps the user needs to take, but it is missing the corresponding system action that needs to happen in response to each user step.

In a use case, just about every user step should have a corresponding user response or action. If it doesn’t, your development team isn’t clear on what the system is supposed to do to hold up its part of the bargain. This leads to assumptions being made or questions being asked during implementation.

This one is such a big deal, I recorded an entire video about it:

Use Case Writing Mistake #3 – Include Technical Details

Another common mistake, and this one tends to come from more technically-focused professionals, is that the use case includes technical details that are not required to understand how the user interacts with the system.

Common examples of technical details include:

• Specific data elements or data tables.
• Names of system components that wouldn’t be visible to an ordinary end user of the system.
• System-triggered processes or procedures that need to run.

Including too many technical details can clarify things for the technical team, but breaks the flow of the use case and makes it difficult for your business stakeholders to understand and your testers to test. These details are best saved for a technical design document.

When it comes to data elements, a best practice is to use a data dictionary or data map to analyze the data requirements.

Here’s a video explaining how to create a data map:

Use Case Writing Mistake #4 – Inconsistent with Wireframes

While use cases can stand alone as a requirements document, often they are created along with wireframes that show either the flow or one possible flow through a set of screens to realize the use case.

It’s very common for the use cases and the wireframes to get out of sync. For example, there could be a sequence of steps that’s not represented in the wireframe or the wireframe could lack the buttons and triggers necessary to fully realize the functionality in the use case.

Inconsistency in final deliverables creates confusion because it’s not clear which deliverable should be the true source of requirements. (And when there is lack of clarity, developers tend to choose visuals because they are easier to consume.)

Here’s a video explaining how to create a wireframe:

Use Case Writing Mistake #5 – Unclear Where Alternates and Exceptions Branch Off the Main Flow

One of the useful elements of use cases is that they enable you to focus on the basic flow or “happy path” independent of all the variations that can occur along that path. These variations are called alternate and exception flows.

Here’s an example for “Remember me” functionality in a Login use case:

2a – Remember Me

• The system detects that the user’s computer has a saved username and password.
• The system bypasses steps 3 and 4.
• Continue with Basic Flow, Step 5.

When detailing an alternate or exception flow, it’s preferable to identify a specific step in the basic flow where the alternate or exception begins or is triggered. Similarly, when the description of the flow is complete, you should indicate the step in the basic flow where the flow picks back up.

This habit makes less likely that you’ll miss steps in your basic flow. (Often when I notice these mistakes, there is no appropriate step in the basic flow to branch off from, which often means a system check is missing.) It also clarifies for your reader exactly when and how the alternates and exceptions get triggered.

Use Case Writing Mistake #6 – Include Out of Scope Steps

A use case should be fairly discrete. It should describe the sequence of steps (and all necessary variations) for accomplishing one specific user goal, such as creating an account or sending an email or generating a report.

A common mistake is to include steps that happen before the pre-conditions, after the post-conditions, or are otherwise unrelated to the user’s goal in the use case. This mistake is an indicator that the use case needs to be split into more than one use case.

This mistake leads to missing requirements because the more you try to cover in a single use case, the more likely you are to overlook steps and alternate paths through it.

Here’s

Use Case Writing Mistake #7 – Inconsistent Terminology

A final mistake that can cause significant confusion is when BAs use terms inconsistently. For example, it’s common for a use case to describe a flow of steps to process a specific type of information.

Let’s just say in this scenario, we’re talking about creating a new article to publish on this website. If step 1 refers to an article as a “blog post,” step 3 as an “article,” and in step 5 there’s a reference to a “published content item,” it’s unclear as to whether these are all the same concepts or different concepts.

Not knowing the business jargon, your technical stakeholders will most likely assume that there are three different concepts that need to be implemented with different data elements and then have questions about how one ties to another.

And while it might seem like a lot of work, investing in creating a glossary to clarify terms and their definitions can save a lot of time and confusion in the long-run.

If you want to go deeper into how to check for inconsistent terminology and train yourself to find it, check out this video I recorded on the topic:

How to Avoid These Mistakes When Writing Use Cases

If you are making any of these use case writing mistakes, you could be losing the opportunity to create clear and concise functional requirements specifications that are easy for your stakeholders to understand, provide feedback on, and implement.

Review your latest use case for each of the mistakes mentioned and work to correct it. Better yet, trade use cases with a peer and review each other’s work for evidence of these 7 mistakes. Often an outside observer can see what we don’t.

Download Your Use Case Template Today

Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.

We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

>Click here to download the Use Case Template<<

Learn How to Write a Use Case

Want to back-up and learn step-by-step what goes into a use case? Watch my full use case tutorial below:

Use Cases Are One Way to Analyze the Functional Requirements

Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.

Use Cases vs. User Stories

Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.

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.

Personally, I used to receive “fly-by assignments” from my boss. And he always seemed to be on his way to a really important meeting with no time to explain what he was asking me to do. So instead of asking clarifying questions, which is always a good idea when you receive an ambiguous assignment, I’d complete the first small bit of the task and review it with him for input.

As business analysts, we often work independently and without direct supervision. But we can also face mistaken assumptions about our role, confusion about job requirements, and overly optimistic beliefs of how much we can accomplish in a certain amount of time. That means it is important for us to set expectations early and often.

(This is the first 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 setting expectations.

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 the 4 aspects of setting expectations.

1 – Start a New Project

Setting expectations at the start of a new project can alleviate a lot of problems further on. Specifically, clarify your role, what you know about the project, and even the roles of the stakeholders.

This type of explanation is especially important when you are taking over a project from another analyst, or picking up a project that’s been on hold for a time.

2 – Clarify Assignments

Since it’s impossible to know what all of your responsibilities will be inside a given project up front, it is also important to clarify new assignments as they come up.

When the person giving you the assignment has trouble answering your questions, presenting an early work sample for feedback and input can confirm you are on the right track and enable you to course-correct before investing too much time.

Finally, as you grow in your career, there will be times when you take on work that is a bit outside your comfort zone. Seek out specific help to ensure you are successful at new tasks.

3 – Manage Your Workload

There will be times that you will have too much to do. When this happens, you can work a lot of overtime, deliver poor quality work, or request help prioritizing your assignments so you can deliver your best work on the most important projects.

Obviously, the third option is the best choice, but it does mean you will have to communicate about missing a deadline. What’s more, sometimes instead of shifting work out time-wise, it’s necessary to shift work away, and that means declining an assignment that is not yours to do.

4 – Provide Status Reports

One of my mentoring clients had his contract end early. It turned out his manager was in a different location, had little visibility into his work, and mistakenly decided that he wasn’t doing his job in the right way.

When you are working without direct supervision, it’s important to be proactive in your communication. A weekly status report is a simple way to inform others about what you’ve accomplished, what’s on your plate for the following week, and voice concerns about any issues you are facing.

A Quick Synopsis

While it can feel a little uncomfortable to set expectations, doing so shows you are proactive and professional. What’s more, as you start to communicate more clearly in each of these areas, a lot of the angst inside the work of being a business analyst dissolves, freeing you up to do your best possible work on the things that really matter.

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 setting expectations, that can be handled effectively via email.

Click here to learn more about the Email Communication Templates

Part 5 – where we  look at how the BA process applies to agile, because despite what you might be reading out there, agile environments absolutely, positively need business analysis.

Two Locations, Two Perspectives

Let’s start at the beginning. When I landed this consulting engagement, I wasn’t hired because I knew about agile. (I didn’t know much at all about agile as it was just becoming a “thing” at that time.) I was hired because I was experienced with use cases and customer-facing web applications.

Despite this perception of expertise, this was one of my very first projects working with internal users and on the systems they used as part of their day-to-day work, and that brought some fresh challenges into the mix.

Let’s dive right in.

The organization is geographically split. The primary executive stakeholders are here in Denver, along with the technical project manager, and the primary business stakeholder, and me. The primary business subject matter experts, those that deal with the key processes day-to-day, are over in the Eastern time zone.

Although the vision from leadership is clear, we don’t have a detailed insight into how the business process actually works. To resolve this lack of understanding, the three of us visit the second location to meet with the experts early on in the project, just about the time I’m finishing up the first draft of the 8-or-so page scope statement.

The primary business stakeholder does a beautiful thing and I’ll always be grateful for what I learned from her. She keeps the discussion focused on their problems and their needs. She speaks to the goals of the executives in ways that matter to these experts.

And then she does something even more beautiful. She suggests we adjust the scope of the project to address some of their primary concerns. She essentially goes to bat for them to the executives back here in Denver and renegotiates scope and expectations.

(In step 2 of the business analysis process, it can be important to help stakeholders from different levels and parts of the organization get aligned on the business objectives to be addressed.)

With this action, she essentially creates the circumstances for a successful project. You see, the experts don’t trust anyone – not us, and definitely not the executives. They are engaged in the project only to the degree that they need to be to avoid being insubordinate. With this one move, the project manager shifts their perceptions and gets them more fully engaged. She essentially paves the way for me to have a much more effective elicitation and analysis process.

Start Planning, and Then Re-Planning

With a scope that has more stakeholder buy-in than we could have expected at this point, we begin fleshing out the requirements. Traditionally, this organization has created use cases, so I do the logical thing. I create a use case list and begin mapping out a plan to put the use cases together.

Then we have our kick-off with the development team to discuss the solution approach in more detail. It turns out that the development team is an agile shop. They don’t want use cases. They want user stories.

Hmm…

User what?

User stories.

I get a 5 minute tutorial from the technical lead and am sent on my way.

Create us a product backlog, they say. Then we’ll start designing and implementing the system.

Hmm…

For a few days, I am stopped in my tracks. I am in a learning frenzy trying to figure out what’s expected of me.

I finally start breaking down my use cases into what seems to be a reasonable set of user stories as a way to get the product backlog going. We review it as a team and there are head nods of approval, so I feel like I’m generally on the right track.

Getting Something Ready for Sprint 1

But now, I’m under time pressure. Sprint 1 is supposed to start in less than a week. We select a few user stories for the first sprint. Because I’ve been so worried about how to specify the requirements, I didn’t allocate enough time to actually elicit and analyze the requirements. I hit a snag and learn we need to engage additional stakeholders to confirm a few requirements.

I really need a few more days to get the requirements complete and validated (all part of step 5 of the business analysis process), but we don’t have it. Instead, I’m told by the team that change is fine. Give us something and we’ll work with it. We can always change it later.

So I do.

Two days into the sprint, I’m able to finalize the requirements. And yes, as expected, they’ve changed. I email the developers summarizing the changes, expecting them to incorporate the changes into the sprint.

It’s a no go. Instead, they say they will build off the original requirements and incorporate the changes in the next sprint.

This response made no sense to me. I’m beginning to think there is something wrong with this whole agile thing.

But being new to the process and somewhat of an outsider, I played along. I dutifully went into sprint 2 with a list of changes to what had been developed in sprint 1.

At this point, the developers didn’t seem so excited about changing what they’d just invested two weeks of work in.

That’s when I learned an important lesson. There is a difference between your process supporting necessary change and personally embracing the impact of unnecessary change. Because I didn’t hold fast to the fact I needed more time to validate the requirements (something we talk about how to do in the BA Essentials Master Class), I enabled a situation where our team had to deal with unnecessary change.

The silver lining is that because of this rework, I was able to get just enough ahead so that this problem didn’t repeat itself again.

Getting in Sync and Making Good Progress

From sprint 2 on, consistent progress was made. Every two weeks I saw what the developers had completed. Every two weeks, I prepared new requirements for them to work with.

Within the first few sprints, we developed some productive working rhythms organized around our bi-weekly sprint planning meetings:

• I met with the technical team once every two weeks to review new stories, scope them using story points (a way of estimating), and build my awareness of technical opportunities and complexities.
• I met with the business sponsor every two weeks to prioritize new stories and confirm the next set of stories in the product backlog.
• I worked forward one or two sprints to elicit and analyze the details for the upcoming stories, build wireframes, and write out acceptance criteria.

Overall, we ended up finishing the bulk of the project in 8 or 9 sprints, plus a couple of extra sprints at the end to fix bugs.

By the end of the project, I was a stronger a proponent of agile methodologies. By and large, they worked.

What I liked most was that the requirements were integrated right into the development planning process. Disconnects I’d witnessed on past projects between use cases, project schedules, and technical design documentation disappeared.

Of course, keeping the requirements aligned with the development plan did take a lot more time from me as the BA. It was necessary to package and repackage the requirements based on the implementation plan. But in the end, this alignment led to a much cleaner product.

Despite the wins, there is one issue that we didn’t get to discuss yet, and that was losing track of the big picture.

Losing Track of the Big Picture

To support planning, prioritization, and development, user stories tend to get broken down in a fairly granular way. As a result, you can lose the big picture of how they all fit together. By the time we got to sprint 6 or 7, it became increasingly difficult to prioritize user stories or present a clear picture of what had been implemented vs. what remained to be done. We had well over 60 user stories and it was simply too much information to keep present of mind.

To address this issue, I ended up creating what I later learned was a lot like a user story map. It was essentially a visual flow of how the user stories worked together to deliver on the business objectives and features in the project.

This was valuable in our final prioritization efforts as we were deciding not just what user stories would be next, but what would get into the final release and what might not make it. We could see if we had missed any critical threads of functionality and decide how to group the user stories together for maximum business benefit.

The lesson here is to not be afraid of adding a new visual model to the mix, even late in the cycle, especially if there’s a decision that’s difficult to make or a set of information that’s difficult to understand.

This picture solved a lot of problems for those of us entrenched in the project day-to-day, but it didn’t do much good for our experts over in the Eastern time zone. Let’s take a look at how we engaged them next.

Getting the Experts to Use the New System

First, I documented the updated business processes to be used by the users, taking care to frame the processes from their perspective, not a functional perspective. We walked through this process documentation while demoing early versions of the new system, still in development.

Then, I stepped in to lead a user acceptance testing effort. Since the business users weren’t super technically savvy, I mapped out scenarios and test cases. I visited their office so we could run through them together as they each took a turn using the new system.

This approach had many benefits. With this one activity we witnessed their first-hand reaction to the new way of doing things, validated the system worked for the business process, and trained them on the new business process.

Once the system was live in production, I was on hand to answer questions, but things worked pretty seamlessly and I moved on to other clients.

Looking at Lessons Learned

Let’s look at our take-aways:

1. Expect the unexpected and be flexible. No matter how well-thought-out your business analysis plan, projects face unexpected changes in circumstance. In this case, the development team brought a methodology we were all expected to work within. Being flexible afforded me the opportunity to learn a new skill set.
2. There are different types of change. At first, I too fully embraced the agile rhetoric and allowed incomplete requirements to go to implementation. This backfired, luckily in a small and easy-to-recover from way. Distinguish between necessary change, which happens when external factors require you to rethink requirements, and unnecessary change, which is the result of incomplete analysis. Agile makes it easier to deal with necessary change. Unnecessary change still costs unnecessary money.
3. You are not done until the business gets it. While working in product environments, I had very little exposure to real users. By getting involved in user acceptance testing and business process modeling, I got a much better perspective on how system changes directly impacted the business users. I started to see the BA role as much broader in scope than I had previously. It’s not just about getting the software system deployed. It’s about getting the users to use that system successfully. (This is why step 7 of the business analysis process helps ensure the business community is prepared to embrace the changes that have been specified as part of the project.)

Here we are, all the way at the end of the last installment in this Behind-the-Scenes in Business Analysis series. I hope you’ve enjoyed the content and learned something new that makes you more effective.

You can also check out the BA Essentials Master Class, where you’ll learn how to navigate the 8-step business analysis process to handle any project like a pro.

Part 4 – where we look at what to do when the business stakeholders have already told the developer everything they think he needs to know and, more generally, how the business analysis process still applies on changes that take less than a week to implement.

Learning a New Business Domain

Once upon a time, I got called back for a repeat engagement with a client. The first project had been one of those big, strategic initiatives that changed how the organization did business. It was also agile. (We’ll actually talk about this initial engagement in part 5, so I don’t want to get ahead of myself now.)

The second time I got called back, all I knew going in was that there were some communication issues between business and software development in a different business unit than I’d worked with previously. And wouldn’t I please come in and help clear it all up?

Yes, of course! That’s exactly the kind of situation where a business analyst can add a lot of value.

I spent the first two days getting a detailed demo of the existing process and system from a very nice fellow on the business team. He is and was one of those subject matter experts that gets pulled in 20 directions because he knows just enough about everything to solve all kinds of interesting problems.

I don’t know how he spared 3 hours of his work day on 2 consecutive days with me, but he did. And I was grateful.

Without any process or system documentation, this series of demos was my grounding or “getting oriented” into the system and the business process (which just so happens to be step 1 of the business analysis process). I took copious notes and followed up these demos with my own exploration of the system.

Lesson learned: When you can get access to the right business subject matter expert (or sometimes experts) you can learn about the current state very, very quickly.

Clearing Up the Communication Issues

But there are changes to make to the system and that’s really what I’m here to figure out. The project manager organizes a short meeting to introduce me to the rest of the business stakeholders. They speak vaguely of the meeting they had 2 or 3 weeks back to discuss a set of changes they still haven’t received from development yet. They want to know the status.

The PM says the developer (we’ll call him John) is waiting for information. The business says they are waiting for John to deliver.

The problem becomes clear. I volunteer to talk to John to see what he needs. I need to get to know him anyway to understand his perspective on how the system works and how I can help him from a process perspective.

It turns out that nothing has been done since the meeting a few weeks back. John has been waiting for the business to clarify what they want and he senses that what they need is actually something much bigger than what they asked for.

My BA alarm bells start going off. I’ve seen this situation before. Lots of discussion. Lots of ideas. No commitments. And most importantly, no accountability and no meeting notes.

Being the Bearer of Not-So-Good News

I go back to the business and let them know we need to have the discussion about what they want, again. Yes I talked to John and John says he doesn’t have a clear understanding of what you want.

I get a very typical response: But he was writing down notes? Perhaps, I say, but he doesn’t have all of the information he needs to ensure he solves your problem. I know it’s going to be painful, but I think the fastest way forward is to start from the beginning and have you share with me what you want. I promise to write it all down and make sure it gets to John so he can get started as quickly as possible.

When you have these discussions, it’s important that everyone gets to save face. I was careful not to damage John’s reputation while also being careful not to make the business stakeholders feel like they screwed up. Even though I am here to rescue the team from this miscommunication issue, I’m not going to be making any friends if I start playing hero. Instead, I am apologetic for the situation they find themselves in, and clear about what I think I can contribute.

We have the meeting. It’s clear in the first 5 minutes that John was right. The 3 primary stakeholders, each representing one business team, all have different ideas. Even though I don’t know the system all that well, it’s obvious their ideas don’t fit together.

We go back even another step – what problem are we solving here?

Ah, that gets the answer we need. Fundamentally, this is a reporting issue. But we’ve been talking about changes to the business process and what data fields are available to log specific kinds of issues. I start to see the big picture and know that I can lead them through this.

The lesson learned here is that even if there is a project history, if everyone can’t share a consistent story, it makes sense to start right back at step 1 of the BA process, even when it’s a little painful.

Getting to the Root Cause of the Real Problem

The end result of all of this discussion is a collection of development work that takes John maybe a week. Within three weeks of my arrival on the scene, we are able to deploy the change into production.

Luckily for me and my salary, the business needs don’t stop there, or this would have been a very short contract. For the next 6 months, we continue to make small changes and deploy releases every 2-4 weeks. I invest most of my time getting these same three stakeholders to see each other’s perspectives and figure out how they will work together.

The fundamental source of all of their problems is that they deployed a business intelligence reporting system without fixing their business process. They have fancy, I mean very fancy reports, with up-to-the-hour data that give them the wrong information or no information at all. We are fixing that situation one small step at a time.

A nice little side lesson here is that if your data is the output of a flawed business process, it’s not going to tell you much “intelligence” about your business. This sort of situation typically comes about when you focus on the technology part of the solution to the expense of the actual business problem to be solved.

But I digress. Let’s get back to our story, because there is a bit more learning I’d like to share with you.

Validating Requirements (Here’s a Bit of BA Heresy)

Typically, when I validate requirements, something that’s covered in step 5 of the business analysis process, I ask stakeholders to walk through written documentation and approve the words-as-requirements. I tried this approach 3 or 4 times with this business community before I set it aside.

Even if I printed out a half page document and put it in front of them, they wouldn’t read it! It was maddening. Here I was investing time in getting the words right, and they preferred to talk amongst themselves and go in circles about how everything was going to work.

Finally, I realized my approach wasn’t working and wasn’t likely to work any time in the near future. I also realized, that even this lightweight formality wasn’t really necessary. These were very small changes and I could take a few shortcuts without introducing much risk.

I noticed that when I put together a wireframe and projected it up on the screen, the stakeholders were engaged and we had much more focused discussions. So I started putting together a wireframe for each and every request and then structured my written requirements around the wireframe.

Here’s the part that’s a bit of heresy in BA circles. I stopped sending the business stakeholders the written requirements. They never saw them.

• I created them – for myself and the developer.
• I printed them out for my own use during the meetings.
• I spoke to them to generate feedback.
• I updated them based on input.
• I uploaded them into our development tracking system and they were used to provide implementable requirements to John.

But the business stakeholders never actually saw them.

Because the changes were small, we could use the wireframe to talk through them. In fact, often the wireframe brought up issues and impacts I hadn’t expected, so we actually got further faster without the written specs being the cornerstone of discussion. Of course, this approach did put a lot of burden on me to make sure I translated everything I heard verbally into written requirements.

I wouldn’t recommend this approach for a large project or large piece of functionality, but it worked really well for the tweaks and adjustments we were making. It’s something you might keep in your back pocket for a similar situation.

Looking at Lessons Learned

Let’s look at some lessons learned:

1. When rehashing a discussion, show results as quickly as possible. No one likes to do rework. Often stakeholders already perceive time in meetings as wasted time. Still, scheduling yet another meeting to discuss something that’s already been discussed can be necessary. When you find yourself in this position, take care to over-communicate your next steps and get to some tangible result as quickly as possible. You’ll build personal credibility that will drive the project momentum forward.
2. Be flexible with your business analysis approach. The requirements documentation approach that ended up working best for this stakeholder group was not something I’d recommend as a global best practice. But it worked, really well, for this particular context. I figured it out through trial and error and iteratively incorporating feedback until we found a way that worked.
3. The business analysis process applies to small changes. Even though each change we discussed took on average 2-5 developer days, we had to go through the 8-step business analysis process. We figured out the business need, the solution approach, and the detailed requirements. Because the changes were small, we sometimes were able to do this all in 1 or 2 meetings. Some aspects of the process, like getting oriented and planning out the BA approach didn’t have to be repeated for every small change, as the work done for the initial set of changes extended to future changes.

That’s all for part 4!

In part 5 we’ll be looking at an agile project. In fact, it’s a project I worked on that switched to agile seemingly out of the blue. As a business analyst, you must always be ready for kinks and surprises. This project had both.

In the meantime, you can check out the BA Essentials Master Class, where you’ll learn how to navigate the 8-step business analysis process to handle any project like a pro.

Part 3 – where you get to learn how to survive – with grace and dignity – when everything around is looking very, very dismal.

Looking at What “Everything Going Wrong” Looks Like

A lot of projects die a passive slow death of non-use. Few projects prove so lacking in value to the organization that the code isn’t even worth maintaining on a server somewhere.

Within 12 months of finishing this project and leaving this organization (along with the key executives sponsoring the project), I learned that the servers had been reformatted and re-purposed, some perhaps even sold.

I told you it would get a bit ugly, didn’t I? Not lying, people! This is the real deal.

Let’s Start at the Beginning (or Duct Tape and Hair Ties)

It’s my first day at a new BA job. We have $1M+ in funding and big aspirations to change the way scientists search for information.

There is a business case that proves the market potential of this brand new product. I’ve never seen a business case before and spend a few hours poring over it, figuring out what we’re doing and why.

I meet with stakeholders across the organization to learn about what we do. Everyone but the product manager for this project cares about one thing – the existing business, which is making money but not fast enough, and the existing system, which is running on duct tape and hair ties.

But I’m not here to fix that system. My manager makes that perfectly clear. I’m here to build a new product that will only touch that system in very small ways – the smaller the better.

No Challenge Is Too Big with a Glass of Wine and a Big Piece of Cardboard

I set about doing what I know how to do best. I create a functional specification that contains every item the product manager can envision ever including in this new system. We pore over it for days, making sure it’s clear and complete.

The product is so big I can’t quite wrap my head around it. We have no existing technology architecture – except for the one pieced together with duct tape – and I can’t see how we are possibly going to build this.

There ends up being a rather fun solution to this problem, which gets us past step 3 of the business analysis process.

One work day, I go home a little early and pour myself a glass of wine. I get out a piece of cardboard as big as my kitchen table and some index cards. I write down features, components, and key elements of the navigation. I start piecing the project together bit by bit.

I start to see what we’re building with clarity – at least from a functional perspective. (The lesson to learn here is that the pieces are nearly always there, sometimes you just need to step outside of your preconfigured boxes to see how they fit together. In the absence of a technical team to collaborate with, I chose wine and cardboard. If you’ve ever collaborated with difficult technical stakeholders, you might be envious of my choice here. Just keep reading – you won’t be envious too much longer.)

I recreate the model in Visio (much, much later I learn that this is an example of functional decomposition) and copy it into the spec. (By the way, the Visio version of this model is included in our Visual Model Sample Pack.) It becomes a guiding light holding together the pieces and parts of the project and organizing what’s quickly becoming a mammoth specification.

Going From Concept to Solution

By this point in the project, we have hired a project manager and a technical lead. We begin to evaluate key vendors and products to help us build the technology.

The visual model I created with a little help from wine and cardboard transforms into an actual solution approach, with component names and integration points.

As an aside, sometimes it makes sense to interview vendors early in a project to learn what’s possible. Each vendor we interviewed provided some important aspect of the functionality we were looking for. Many revealed new possibilities we hadn’t thought of. The functional requirements provided a touchstone from which to analyze each vendor, and each vendor provided a strong dose of reality from which we could piece together our approach.

Evaluating vendors was all part of our discovery process and eventually we decided on a handful of tools to use as part of the solution approach.

Getting Ready for Detailed Requirements

I start writing use cases to dive deep into different layers of functionality. The product manager hires a user interface designer to help us present the complex layers of functionality in an intuitive way. I work side-by-side with him to hone the design and tweak the use cases.

We’re all set to go from a requirements perspective except for one thing. We don’t have a development team.

To make matters worse, the person filling the technical architect role leaves. Before he does, he gracefully recommends a consulting organization he’s worked with before. We hire them. We are ready to start the detailed design and start working with a new technical lead from the consulting organization.

(In retrospect, I suspect the technical architect saw the upcoming train wreck and decided to jump off the train before it got moving too quickly. But I digress.)

To keep things moving, I’ve been making a few critical assumptions up to this point.

1. The development team will work from use cases.
2. The requirements are feasible.
3. The requirements are complete.

#1 plays out. #2 and #3 do not. While the use cases articulate what the business stakeholders want, as we get into the technical walk-throughs we end up making many adjustments so they are implementable and add new elements to ensure completeness. Many of the adjustments have a ripple effect through the use cases, so one new insight leads to many changes…and that means a lot of rework for me and the business team.

The lesson to learn here is about not making promises when you can’t control the outcome. We had gotten into such a pattern of “approving” use cases and there was so much urgency driving our progress, that I lost sight of how the functionality would be implemented. This is another unintended consequence of the so-called luxury of time we learned about in part 2, and can happen easily when you don’t have technical stakeholders fully engaged in step 5 of the business analysis process.

The second lesson is that there will be project factors that are outside of your control and impact your success. Looking back, I still think I did my best possible work given the project conditions. However, on future projects, I was much more vocal about when I needed a technical expert assigned to my projects and could speak with more confidence about the risks of not having them involved.

But Here’s Where Things Really Start to Go Wrong

We were able to recover from all of the issues we’ve talked about so far. But as we actually started to implement, things started to get ugly.

As we begin processing content, new and unexpected technical issues start coming up. At the pace we were processing content, it would be 5-10 years before the product would be ready for testing, let alone deployment.

Yet we continued to figure out user interface details for the product that will present all of this processed content to the end user. And write more use cases. And solve some complex problems about how the new system would talk to the old one.

And that reminds me of one of the more complex requirements challenges we worked through – getting the new and old systems to talk to each other. I learned firsthand how you can facilitate a technical problem solving discussion without understanding the technical design. Both teams used coding languages and database technologies I’d never been exposed to. And of course, they were both different so there was a lot of turf protecting going on.

I learned that asking the obvious questions and keeping the focus on functional needs (even in a deeply technical discussion) could create clarity and break down barriers.  I also learned that just by staying engaged, I could absorb information about the technical architecture. This became useful as I worked on requirements for related functionality.

I also earned the respect of both technical teams, an asset that helped me expand my responsibilities within this company and could have led to a job opportunity with the consulting organization, should I have chosen to go that route.

Getting back to our main issue, the technical team does finally figure out how to get content into the product. Then we notice something just as problematic. The search is insanely slow. You click. You wait. (Wait as in get a cup of coffee wait.) And then you might see the results. You narrow. You wait again. The whole point is to have an interactive application that enables discovery. Even scientists don’t drink this much coffee.

At this point, I’m done writing new requirements. The only priority is to get some meaningful subset of the massive body of requirements I’ve written deployed so we can pre-sell this product to the customer.

The Value in Stepping Outside the BA Role…and the Project

There being no need for more requirements and the challenges being largely technical, I take over managing the daily work of the off-shore-test team who is submitting bugs at the rate that mosquitos propagate on a hot summer day in the Midwest. Luckily 80% of them are duplicates and I’m able to filter them down, prioritize them, and work with the technical team on solutions.

I also start helping the other areas of the business update their duct-taped-together system. These are small changes; you might not even think of them as projects, but because of the complex business rules and fragile nature of the system, each change requires intense analysis. I’m able to help speed up these mini-projects by applying BA principles.

(In part 4, we’ll go into detail about how to add value by applying BA principles to small changes.)

The lesson here is that finding a way to add value leads to career advancement and opportunity. Before I moved on from this organization, my decision to step into these roles proactively led to a promotion and an expanded set of responsibilities, despite the fact that this project didn’t turn out as expected.

But let’s finish our main story. The technical team releases something saleable. It’s still slow and buggy and partial, but it works according to some standard of success.

One person buys it. Not one organization, but one person. Expecting organizational customers, we didn’t even have a way to set up a single user in the system and had to create a work-around for him.

I think that is the only sale ever made. I don’t know what happened to his license when they dismantled the servers. By then, the train had slowed down enough for me to jump off too.

Looking at Lessons Learned

Let’s look at what I learned:

1. Engage with the technologists, even after the requirements are “complete.” Although it was tough to rework use cases, add new deliverables, and be part of tense technical discussions, my continued support of and engagement in the process helped the team work through many tough issues and ensured that the decisions made represented the business objectives.
2. Pitching in can be a strategic career move. Even though much of the work I took on was outside my core BA responsibilities, it helped position me for new opportunities and create lasting personal connections, some of whom I’m still in touch with to this day.
3. System expertise is not a pre-requisite for success. Every piece of technology we worked with was brand new to me. Still, I was able to contribute by focusing on the business needs and desired functionality, and being open to learning about new technologies, capabilities, vendors, and systems.

Luckily for me, I survived this project and went on to develop a much stronger career in business analysis. Sometimes, we simply must learn from our own mistakes.

In part 4, we’ll switch things up a bit and look at how to apply business analysis principles to smaller initiatives – so small you might not even consider them projects.

In the meantime, you can check out the BA Essentials Master Class, where you’ll learn how to navigate the 8-step business analysis process to handle any project like a pro. Of course you can always learn from your own mistakes, but wouldn’t it be better if you didn’t have to?

Part 2 – where you’ll learn why more time for analysis is not always a luxury, and how to engage new stakeholders even when it feels mighty uncomfortable.

Jumping in as a Brand-New, Just-Hired Business Analyst

Once upon a time, I was a new business analyst, fresh off the “just hired” presses and transitioning out of my quality assurance role. After a few months impatiently shadowing a senior BA on our team, writing up her notes, and updating her documentation, I was finally assigned to lead a project.

I was so excited I could barely stop myself from digging into drafting the requirements spec over the weekend.

A project!

Of my own!

Woot!

Then something kind of crazy happened. As I started reading background material and learning about the objectives, I realized that this project had the potential to be the biggest project I’d ever seen at this company. (As a QA engineer, I’d worked on over 30 projects, so I had a diversity of experience to draw from.)

There were at least 3 new significant features that I’d never seen done on our platform. And, well, the product represented an entirely different business model than our other offerings.

Looking at this project through a technical lens, I couldn’t help but wonder if this was all really doable and how it would work on our existing platform.

My head started spinning.

And did I mention I was a brand new business analyst? Although I had critiqued many requirements documents and now updated a few, I’d never actually written one before. Come to think of it, I had never discovered information about the scope of the project before, or sat down 1-1 with a business sponsor, or kicked off a scope discussion with a technology team…

Or.

Or.

Or.

But over ten years later, this product is still in use. So I say we did something right in putting the first phase out into the marketplace.

Let’s look at how this project unfolded.

Receiving the Mixed Blessing of Time

Most BAs crave more time for discovering and analysis and as a new business analyst, I was no different. I had well over a month to meet with the sponsor and deeply understand everything she wanted the product to do.

Looking back, I see this as a mixed blessing because while I had time to get oriented around the project before being on the hook for a deliverable (that’s step 1 of the business analysis process), no technologists were engaged. The meetings were limited to understanding what was wanted, not what was possible.

To make things worse, I still had half of a technology hat on and I had trouble moving forward without seeing how this would work. So I did something that felt incredibly smart. I put together a solution approach.

You see, in QA, I’d learned how the systems worked. Since this product would be built on those pre-existing systems, I thought I could figure out the technical design too.

Big mistake.

Jumping forward to the project kick-off, I had a first draft of a 50+ page requirements document and a technical approach mapped out.

When it came time for me to talk about scope, I talked about the solution. And, well, the developers weren’t so keen on my ideas.

We had no choice but to take a step back.

Finding the Solution Approach

As a project team, we independently looked at each feature the product manager requested. In the end, after a lot of discussion, brainstorming and decision-making, we came up with a solution approach that was very, very close to my initial idea.

You might think that I felt validated, but I actually learned a very important lesson I’d like to pass on to you.

My ideas didn’t matter if the team didn’t embrace them. As a business analyst, it wasn’t really my place to tell the technology team how to solve the problem, no matter what kind of expertise I had.

My rookie mistake was to analyze too far forward before getting the technical team involved, a challenge we’ll see me face again in part 3 of this series, but handle in a different way.

Technical approach in hand, I began to analyze the detailed requirements in a large body of use cases. I established a rhythm of two meetings each week and we were making consistent progress. In the end there were more than 40 use cases in total, covering two different systems.

That reminds me of another kink in the requirements process for this particular project.

Making Sure You Discover All of the Impacted Systems

Traditionally, my business analysis team worked on the customer-facing aspect of the product – how our end users searched, retrieved, and used content online.

But for this project, we needed an entirely new business model. Even with my newbie hat on, I sensed this was a big deal and not something I could skirt over in the requirements process.

In the end, we ended up touching systems I didn’t even know existed at the start of the project, and touching them in a bigger way than any project my BA team had worked on in the past.

I decided to form a small side team to work on this aspect of the requirements. We began plugging away at identifying the key requirements, figuring out the solution approach, scoping the detailed requirements, and finally, designing the system.

To ensure success, I also needed some very high-level stakeholders and this was mighty uncomfortable at first. Here I was, a very new and very young professional in this organization inviting the VP of I don’t remember what to a meeting to talk about the Siebel system I’d never even seen before.

I couldn’t get a sense of the current capabilities because the details of this system were undocumented and access extremely restricted.

Typically, this VP dealt with an entirely different side of the business. She had no idea how my team worked, let alone what I was responsible for.

• I learned to facilitate meetings even when I felt unprepared with people I didn’t know and use those discussions to focus on discovering information, since there was no background material available.
• I learned to focus on what capabilities we needed and step aside from understanding every aspect of how those capabilities would be addressed.
• With coaching from my project manager, I learned how to break down an unknown into a sequence of steps I could take and forecast a reasonable timeline, even when I knew very little about what I would discover.

(All of these learnings have made it into the 8-step BA process we go through in detail in the BA Essentials Master Class.)

In the end, we successfully implemented the new business model by touching at least 3 different systems owned by technology teams that were not used to working with each other.

But even then, my job as a business analyst was not complete.

Seeing Things Through, Changes and All

As the development team began working in earnest, there were changes – lots of them. Functionality that seemed feasible when they approved a use case proved not to be so.

Most of the changes were just big enough to merit input from the business sponsor, but not so big that there was a lot of contention about how to resolve them. Ideally the technical team would have thought of these issues before they approved the requirements. But as we know, the real world is not often a good match to the ideal world. We were all doing our best work.

Although small, the changes did need to be analyzed, decisions needed to be made, and, most importantly, decisions needed to be communicated. By being involved in the decision-making process, I saved a lot of wasted time due to miscommunication that could have extended the timeline or further reduced the scope.

This is why the business analysis process does not stop when the requirements are defined and approved. As a BA, it almost always makes sense to be engaged after the requirements are complete. But how to stay engaged differs from project to project. In lesson 6 of the BA Essentials Master Class, you’ll learn all the ways you can stay engaged so you can choose the ones that make sense for your particular project.

And, by the way, the launch went out without a hitch while I was on vacation in Seattle and Portland.

Looking at Lessons Learned

So what did I learn from this project?

1. Avoid figuring out the solution approach on your own. Project team members need time to absorb the key requirements, allow their creative energies to work on the problem, and be involved in the brainstorming and decision-making process. Going forward, I took a much more collaborative stance from the very beginning, even when I thought I knew what system design would work.
2. You are never too new to be successful. I was lucky to have a trusted set of templates and business analysis approach to follow, the support of two strong mentors all the way, and work in a mostly collaborative organization. But in the end, I was able to make a very solid contribution, one that I’m still proud of, and that’s because I was constantly investing in doing my absolute best work.
3. Time is not always a luxury. With too much time and too little involvement from other project team members, the business analyst risks getting ahead of other project team members and losing the value of a collaborative approach. (I’ve experienced this in multiple phases of the project, not just the initial phase.)

So that’s my first project. I made some rookie mistakes but I’m darn proud of what I accomplished. Stay tuned – in part 3 I’m going to talk about a project where external factors made survival, not success, the primary goal.

It will get a little ugly because, well, real projects do get ugly sometimes and we all learn best when we learn from our mistakes. I’m going to let you learn from mine. (And I’m still here, so I’d say I survived.)

While you are waiting, you can check out the BA Essentials Master Class, where you’ll learn how to navigate the 8-step business analysis process to handle any project like a pro.

Part 1: The Project Where I Didn’t Get My Way

Learn how to collaborate with other team members, break bad news to a vendor, and visually model different solution approaches.

Part 2: How to Recover from Newbie Mistakes

Learn why more time for analysis is not always a luxury, and how to engage new stakeholders even when it feels mighty uncomfortable.

Part 3: How to Survive a Project When Everything Goes Wrong

Learn how to survive project failure with grace and dignity. (You could learn from your own mistakes, but why not learn from mine?)

Part 4: Applying the Business Analysis Process to Small Initiatives

Learn what to do when the business stakeholders have already told the developer everything they think he needs to know and, more generally, how the business analysis process still applies on changes that take less than a week to implement.

Part 5: A Project That Switched to Agile in the Middle (That Was Fun!)

Learn how the BA process applies to agile, because despite what you might be reading out there, agile environments absolutely, positively need business analysis.

If you’ve enjoyed this series, you may also want to check out the BA Essentials Master Class, where you’ll learn how to navigate the 8-step business analysis process to handle any project like a pro.

Part 1 – the project where I didn’t get my way, but I learned a lot about how to collaborate with other team members, break bad news to a vendor, and visually model different solution approaches.

Getting the Call

This project ended about two days before Christmas. I was doing some final shopping and the salesperson for a vendor I liked very much called to ask about the status of her contract.

My heart stopped for a minute. My manager, the CIO, was supposed to call her days earlier to break the bad news.

I thought this vendor’s product was the best thing since, well, something even better than sliced bread.

But my team didn’t and my team won.

This salesperson, who had invested months in working with us in a very reputable and non-pushy way, was going to find out from me just days before Christmas that she wasn’t getting her commission.

I sucked it up and shared the news.

But let’s start back at the beginning, because this conversation, while uncomfortable, had been months in the making.

Envisioning a Consolidated Technology Platform

Months back, we started envisioning a shared technology platform to support all of our business units in delivering core features. We had already done our due diligence in terms of understanding the current state of each unit’s technology capabilities and core business processes. We found significant overlap. We also found a lot of common issues that would be expensive to solve in 5 different technology systems.

The vision was simple: One technology platform that could be customized by each unit and would replace the existing 5 separate technology platforms.

Search was a key feature so we started exploring solutions in that area almost immediately.

We started by digging deeper into the functional requirements provided by each of the 5 existing technology platforms and pulled them together into one massive list. We engaged subject matter experts from each business unit to confirm their current requirements, as well as provide input on what they would like their future search feature to work like.

We developed a list of key requirements and skeleton use cases to confirm those requirements. Knowing that it wouldn’t make sense to build our own search engine, we began comparing products from various vendors against our search requirements.

There were demos.

Then questions about feature sets.

Then customized demos.

Then detailed technology questions.

Then technology due diligence.

And finally, there were pricing discussions.

Along the way we discovered that to select the right search tool, we also needed to figure out aspects of our content management and taxonomy management strategy. For a few weeks we went down that rabbit hole and looked at yet another set of technology components we’d eventually need to invest in.

Finding a Solution Approach

After a mountain of analysis work, we came up with two feasible solution approaches, part of step 3 of the business analysis process.

• One approach involved committing solely to one vendor whose product provided about 90% of our core requirements. We had the option of integrating in a taxonomy component later to meet the rest of our requirements. The benefit of working with the first vendor is that we’d receive 90% of the functionality we needed already integrated together.
• The second approach involved integrating three different components to meet 100%+ of our core requirements right away. The second approach also gave us unexpected functionality that we could envision leveraging in the future. It was available at a lower price point, but it involved significant in-house development to make it all work.

The decision about which solution approach to move forward with crystallized with an impromptu whiteboard session. The Lead BA and I were talking through the options (not yet having come up with clarity on what those were). The architect floated in. We drew components. We drew circles around different approaches involving different components. We highlighted business benefits, costs, and risks.

Together we began to see the two options clearly. The architect strongly favored #2. I favored #1. It became clear we were going to present our final decision as a result of this discussion, so we called in two other key members of the technology team and the project manager.

Getting Alignment on the Go-Forward Approach

We talked through our options and clarified the pros and cons of each.

The result was beautiful and utterly incomprehensible to anyone who walked into my office without context. I left the drawing on my whiteboard for over a month and explained the visual model to anyone who asked about it. It proved to be a great tool to let others know how carefully we had made such an important decision.

This picture is still in my memory as one of the best white board drawings I’ve ever helped create, and one of the best examples of collaborative decision-making I’ve ever been a part of.

I’m glad I have this good memory because I still wanted solution #1. But everyone favored solution #2 – except me – and their reasons were good.

In the end, the completeness of the solution, the flexibility we’d have in integrating them together, and the lower price point were the team’s rationale for suggesting solution approach #2 to our CIO, who took the team’s recommendation and signed the appropriate contracts.

Looking at Lessons Learned

Let’s look at what I learned:

1. Visuals communicate more clearly than words. We had been discussing the decision for weeks and not getting anywhere. The whiteboard drawing finally enabled us all to clearly communicate our concerns, perceived benefits, and have a meaningful conversation around the options.
2. You don’t always get your way. The collective intelligence of the team supersedes your individual intelligence. If you’ve made your case to the best of your ability and it’s not convincing people you trust and respect, sometimes it’s better to let go of your opinions and align yourself with the team.
3. Technical solutions must be considered against business objectives. When we were only looking at technical options, the solution picture was incomplete. It wasn’t until we were able to visually overlay the business objectives, features, and solution components together that we were able to make an informed decision. (The business analysis process asks you to define your primary business objectives before your solution approaches for a reason.)

That’s where we’ll end today’s story. Next you’ll receive Behind the Scenes #2, which will look at how to recover from some very common business analyst mistakes.

In the meantime, you can check out the BA Essentials Master Class, where you’ll learn how to navigate the 8-step business analysis process to handle any project like a pro.

When the data isn’t in the right places, it does appear to a business user like the entire system is broken. Defining data migration requirements is a key aspect of successful business analysis.

In this article, we’ll look at the business analyst role on a data migration project and how to plan the data migration so that potential data mapping issues are discovered before they derail the project.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

Data Migration: The Business Analyst’s Role

System migration projects involve migrating functionality supported by one system to a new system. In today’s technology climate, often organizations are migrating legacy technology systems, such as those that are proprietary and custom to a single business, to commercial off-the-shelf systems that are supported by third-party vendors. For example, an organization could replace their homegrown lead and customer management system with Salesforce.com or SAP.

Another scenario is when an organization is moving from one third-party system to another. For example, at Bridging the Gap, we’ve changed email marketing software, shopping cart software, and online course deliver software. All of these required some sort of data migration work.

A business analyst can take on many different roles in a data migration.

• At a minimum, the business analyst should be involved in clarifying the business requirements for the data migration, and helping answer such questions as what types of data will be migrated from one system to another. (For example, when we moved shopping cart systems, we migrated our products but not the order history.)
• The BA’s role can greatly expand to include analyzing all aspects of moving data from one system to another, without actually doing the technical work of migrating the data itself.

Data Migration Projects Bring Up Lots of Questions

While the actual loading of the data is a technical process, there are important business decisions to be made, such as:

• Do we bring over all data or recent data?
• For any two fields, do they actually mean the same thing? Or, is there logic in either system that will impact how we want the data brought over, based on our understanding of the business process and functional system flow.
• Do all fields have a home in the target database? And vice versa?
• And so on and so on.

Without a business analyst proactively planning the migration, it’s not uncommon to have a client-side database developer provide a recent dump of data and have the vendor-side database developer sort through how to import it into the new tool. This approach can lead to data issues surfacing late in development, potentially throwing the project off course.

Let’s take a look at the data modeling techniques a business analyst can use to clarify these types of requirements.

Data Migration Technique #1: Model Data Flow with a System Context Diagram

In the early stages of the project, while you are still clarifying scope, start by clarifying the high-level data flow. What systems are impacted? How is data flowing or migrating from one system to another?

A System Context Diagram can be useful here to show how the current systems support the business process, or how data flows through those systems. Here’s a video with more details on a System Context Diagram.

Data Migration Technique #2: Get Clear on Business Concepts with a Glossary and Entity Relationship Diagram

Another early analysis step is to understand the the business perspective on the information model.

• A Glossary is a useful technique to identify and clarify business terms and concepts.
• An Entity Relationship Diagram will show the critical relationships between business concepts.

When you move data from one system to another, it’s incredibly common for there to be shifts in the information model, or how the business manages information.

For example, if your current system has a way to associate one customer with multiple sub-accounts and the future system does not, this issue likely impacts a wide range of business processes and even how your stakeholders will think about the requirements for the new system.

I consider ERD’s a critical BA skill set in our current data-oriented world, even if you don’t want to code and don’t know SQL. Here’s an ERD tutorial so you can learn more about this foundational skill set.

(Yes, it is totally possible for a BA to create an ERD, even if you don’t know SQL and don’t consider yourself technical. In fact, this is a great technique to help facilitate better communication with technical stakeholders.)

When I create an ERD, I like to start with the business’s perspective and model how information is organized conceptually by the business. Then, I work with the development or database design team to present this understanding, explore how to reconcile it with the existing database design, and discuss potential adjustments and customizations.

This understanding is essential as I evaluate how to transition business processes and even consider functional system enhancements.

Data Migration Technique #3: Get Specific with Data Dictionaries and Data Maps

The next step is to get really specific and identify how each individual field or attribution from the original system will get loaded into the new system.

• A Data Dictionary for each database will identify key fields and business rules, such as how long the field can be and whether the value is chosen from a list or typed in free form.
• A Data Map identifies how each field from the source database maps to a field in the target database, and any translation rules or data clean-up that’s needed for a successful transition.

It’s not uncommon to map a free form field into a multi-select field or a field with a longer character count to a shorter one. Instead of waiting for these issues to surface during testing, upfront analysis and business involvement can streamline the entire data migration project.

It’s really tempting to leave this work to the database developers – and it’s very likely they will need to augment and update your data maps in order to do a complete data import. As the business analyst, you can bring the business perspective to this analysis, since you’ll understand not just what data is in the field, but how that information is used as part of the business process. That’s key information that not everyone has access to.

Expertise from both the business and technology teams, as well as both the source and the target system, is needed as part of the mapping, so typically there is a lot of collaboration. Here are some of the issues you can expect to work through:

• For mapped fields, you’ll be looking at whether they actually mean the same thing in both systems or whether there is logic in either system that will impact how the data should be migrated over to the COTS product.
• You’ll also want to be sure that all of the important data has a home in the target database, or that they are comfortable letting go of that data or creating a separate back-up.
• You’ll want to evaluate the data source has all the data needed to populate the new system in the format that’s required. Otherwise, a data clean-up project may be required prior to the data migration.
• As you work through these decisions, the team will need to decide where any clean-up and translation rules get implemented, whether in advance of the migration or as part of the data migration process.
• Finally, you’ll have decisions to make about what data to bring over. It’s not uncommon to archive older data and only bring over recent or active data, as this helps expedite the data migration process.

As you can see, there is quite a bit to think about for a data migration project, and we’ve only dug into the details specific to the data migration. A data mapping specification will help you identify the potential issues before the migration happens, creating a smoother transition to the new system.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In this article, we’ll look at how data models are easier to change than databases, why data models are easier to review than database designs, and consider how data modeling principles will help you succeed in a wider range of software projects.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

#1 – Data Models are Easier to Change than Databases

There is a big difference between putting together a skeleton spreadsheet of a data dictionary or data map and putting together a relational database design to meet real or supposed business needs.

A spreadsheet is easy to change.

• You don’t need this field? Let me delete it.
• This isn’t a text field? Let me put a new attribute type in that column.
• You need to split these fields apart? Let me add that in.

In a database that’s already been designed and perhaps built, you may be a little more reticent to make these types of changes, meaning that you unconsciously push back on what the business wants just because it will be more work for you.

Yes, your technical skills can help you move into more of a business analyst type of role, but it’s imperative that you also learn to appreciate business needs, wants, and requirements as part of the analysis process.

While it’s conceivable that you are a super hero and willing to do whatever it takes to meet the business needs, no matter how much work it means for you, let’s look at another reason to work on data modeling before database design – it’ll save you a bit of time too.

#2 – Data Models Are Easier to Review than Database Designs

While you can output versions of just about any entity relationship diagram or data dictionary from your database development, these models aren’t necessarily ready for review by the business. They tend to contain an overwhelming about of information for a business stakeholder – a lot of information the business doesn’t care about.

Business analysts create meaningful abstractions that help business stakeholders make decisions. These are easier to review and provide feedback on. While you could simplify automated output to create such an abstraction, it’s likely to be more work than just creating the abstraction in the first place.

Finally, if you are looking at a long-term business analyst career, there is one more reason to focus on data modeling over design.

#3 – Data Models Will Help You Succeed On More Projects

While on today’s project you might understand the database technology in place in your organization, perhaps because you’ve built it, tested it, or maintained it, as you grow your business analysis career, your technical skills will fade into the background.

Let me give you an example. You don’t hear me talk much about the data querying I’ve done because I only ever learned to use a proprietary search engine syntax called CCL that has since been replaced at the only organization in which it was ever used. You also don’t hear me talk about the programming I learned, because it’s limited to a PASCAL class in high school.

These are extreme examples because I left my pursuit of technical skills behind long, long ago. But picture yourself 10, 15, 20 years in the future. If you continue to focus on your business analysis skills, any one of the following situations could be true:

• You’ll be in an organization that won’t let you have access to the physical database.
• You’ll be working on a project using database tools you are unfamiliar with.
• You’ll find yourself without the time to dig into the deeper design details of putting the database together.

In any one of these situations, you’ll still need to communicate data requirements, you just won’t be able to do so using your typical technical tools. And you’ll be glad you learned how to use data modeling techniques from a business analyst’s perspective.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

In this video, we’re going to pick apart the difference between data modeling and data analysis, and give you a clear view as to when each skill set is required as you plan out your business analysis career path.

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

Today I want to talk about data analysis and data modeling in business intelligence roles and data related requirements in business analysis roles. So, it’s a big topic, but we’re really just going to hit the key points.

We’ve been receiving a ton of questions at Bridging the Gap about how to define a career path in business analysis. Is data analysis required? Is the role being overcome by business intelligence roles? And, really, the key to interpreting what’s happening in the job market, as well as defining where you want to go in your business analysis career, comes down to the distinction between data modeling and data analysis. Let’s talk about what those mean and then look at what it means for you in your business analysis career.

If you looking for more guidance on building a business analyst career path, check out this video:

Data Analysis Evaluates the Data Itself

First, is data analysis. Let’s talk about what that means.

Data analysis is evaluating the data itself. It’s doing things like running reports, customizing reports, creating reports for business users, using queries to look at the data, merging data from multiple different sources to be able to tell a better and more informed story than when you look at each source independently. That kind of skill set definitely takes some business acumen. You have to understand what the data means to the business.

But it also takes a lot of technical skills. You need to know whatever database system your organization uses, you need to be able to use those queries. A lot of times, somebody in that kind of role is using a data warehouse or business intelligence system to run those reports. So, you would need to know the ins and outs of that system to use it effectively to tell a story with the data.

Data Modeling Evaluates How an Organization Manages Data

Data modeling evaluates how an organization manages data. On a typical software project, you might use techniques in data modeling like an ERD (entity relationship diagram), to explore the high-level concepts and how those concepts relate together across the organization’s information systems.

Here’s a tutorial on ERDs:

You might create a data dictionary that details, field by field, what are the pieces of information we need to store in this database to meet the software requirement features or to implement this business process change.

You might create a data map that shows how we’re going to move data from one system to another, or how we’re going to integrate and make those systems talk to each other on an ongoing basis to make a feature or business process available to our community.

Here’s a tutorial on data maps:

Data Modeling Can Require Some Data Analysis

Here’s where it gets tricky. Data modeling requires a little bit of data analysis. In order to say this field is going to map to this field in a systems integration project, you probably need to look at the data and understand how the data is put together. This is why we see some job descriptions requiring concepts or technical skills like SQL because if you know SQL and can query the database, it’s a little bit easier to be able to research that information and figure it out for yourself using a little bit of data analysis to inform your data models.

However, there’s a lot of technical professionals, or a lot of business analysis professionals, myself included, who don’t know SQL or don’t use it regularly. You think maybe they know it but aren’t granted access to the database. That comes up too. You have to rely on some other skills to get that information.

For me, it’s been a lot about collaborating with the technical professionals asking questions. Sometimes asking for sample data so they can create a dump of some of the records in a spreadsheet format that I could review and look for so I could find potential data mapping or modeling issues. I’m able to analyze the data without having to know how to analyze the data in the database itself. That’s where we start to see a little bit of the overlap, and there’s some confusion.

It’s Not Uncommon to Find Combined BI/BA Roles

A reason there’s some confusion is because there’s this increased abundance of roles that are really combined business intelligence experts with business analysis roles. The competencies that we just talked about, while they are separate skill sets, they really do go hand-in-hand. If you can model the organization’s data and analyze that data to create more intelligence inside the business, that’s a powerful skill set. We’re seeing a lot of roles pull those two things together sometimes.

You can learn more about business intelligence analysis roles in this video:

A lot of times these roles also have the business analyst job title, which just adds to the confusion. You’ll look at it and it’s, “Oh, it’s a business analyst.” “Oh, wait, this is more of a business intelligence analyst. Why isn’t it given the business intelligence analyst role?” That’s just because business analyst job titles are used in multiple different ways, not just here, but in particular here in this area where it can be really confusing when you’re first looking at job descriptions.

For more insights on the business analyst job titles, roles, and skill sets, check out this video:

It is a very popular growing field to have a business intelligence area of expertise. It doesn’t mean that you have to have it to succeed as a business analyst. We’re still seeing a lot of more general functional business analysis roles out there, and, so, it’s a choice you can make if you are really into that kind of thing for sure. Business intelligence is a ripe field with a lot of career potential. But if you’re not, there are still going to be opportunities for you.

Regardless, data modeling is an important competency to have because you need that if you’re working on a business intelligence project. You need it if you are implementing any kind of software or business change to make sure those information systems are really capturing and storing the right data to meet that end business need that you’re trying to get to with your project.

So this has been a crash course on some different data-related skills and why we see some confusion in the business analysis job marketplace.

>>Learn More About Data Modeling

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

For Long Lists of Fields in Use Cases

A use case captures how a user interacts with a software solution to achieve a specific goal. One of the most frequently asked questions from our use case course participants is what to do with long lists of fields that find their way into a use case.

While a certain amount of data information can be incorporated into a use case, once a list spans longer than about 5 fields or starts to include supplemental information about each field, a data dictionary is a better choice.

Connecting these two models is simple. If there is a step inside a use case referencing a collection of fields, simply refer to your data dictionary or a section of your data dictionary from inside the use case.

For Data-Entry Elements in User Interface Wireframes

Similar to use cases, user interface wireframes often contain many data components, often when data is being added or updated. For example, the wireframe screen for creating a new account would contain a user interface element for each piece of data supplied by an end user to create the account.

When this happens, it can be tempting to annotate the wireframe with a lot of data-related rules. Instead, like with a use case, break apart the data elements from a wireframe into a data dictionary, which is specifically designed to handle these rules.

For Data-Related Steps in Workflow Diagrams

Business analysts create workflow diagrams, or models visualizing the steps of a process, to show how business or technical processes flow. Close cousins of workflow diagrams are state diagrams, activity diagrams, and data flow diagrams, which are more specific ways of capturing technical processes. Value stream mapping is a special way of modeling a business process, focusing on the activities that generate the most value to the business.

An activity step in a workflow diagram could involve creating, updating, saving, validating, archiving, or deleting data. Since with workflow diagrams you don’t have a lot of visual room to expand the details of any given step, referencing a set of attributes from a data dictionary is a great practice.

Business Analysts Blend Techniques

While data requirements can be captured using use cases, wireframes, or workflow diagrams, none of these models is designed specifically to help you analyze and organize data requirements. If you find yourself forcing data requirements into a different kind of model or struggling to see the big picture of how all the data requirements relate together, it’s a good sign that a data dictionary would be a useful supplemental specification for your project.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

Here are 10 articles to help you get started with data modeling. These are perfect if you want to brush up on data modeling or get fresh ideas to improve your business analyst work.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

But onto the articles!

• How to Data Model Without Getting Too Technical (or the what and the how)
• How Data Modeling Fits Into the Business Analysis Process
• When it Works to Create a Data Map and a Data Dictionary at the Same Time
• What Software Tools Business Analysts Use for Data Modeling
• 6 Things You Can Do When Your Data Dictionary Gets Messy
• You Are Not a Magician (Or Maybe You Are)
• How to Blend a Data Dictionary with Use Cases, Wireframes, and Workflow Diagrams
• The Difference Between Data Analysis and Data Modeling
• 3 Reasons to Data Model (Even if You Can Design Databases)
• How to Approach the Data Migration for a COTS (or Saas) Project

If you already know something about data modeling, take a look as you might find some fresh ideas.

And here are articles describing four of the core data modeling techniques that we cover in our in-depth course – Data Modeling for Business Analysts – because they can help you solve tricky project challenges:

• Glossary – for clarifying terminology and simplifying data modeling.
• Entity Relationship Diagram – to visualize relationships between key concepts.
• Data Dictionary – to communicate data requirements in a well-organized way.
• Data Mapping – to resolve data issues for data migration or integration projects.

>>Learn EVEN MORE About Data Modeling

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In this article, we’ll discuss the types of tools used to generate different types of data models, and then specifically look at how you can use tools you are most likely familiar with to do data modeling.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

Database Tools Can Generate Complicated-Looking Models

Most database models we see are physical-level models representing the actual database structure. The good news is that no one is manually creating these models. Most often, they are generated output direct from the database software itself.

This also happens to be one reason they are so difficult to read from a business perspective. These models do not represent meaningful abstractions designed to help business stakeholders make decisions about data requirements. They simply show us what exists today, in all its wonderful and gory detail.

(Luckily, as a business analyst, you won’t be creating these models, although you may need to review them to understand the current state. If you haven’t already checked out this article on how to data model without getting too technical, be sure to do so. We define the difference between physical, logical, and conceptual data modeling there and draw a line in the sand regarding what type of data modeling is typically done by business analysts.)

Business Analysts Use Tools Like Visio and Excel

When we are updating existing data models or communicating the requirements for creating new database designs, we don’t have automated tools to generate these specifications. So, yes, we do need to create the models from scratch…manually.

Here are 3 tools commonly used by business analysts to complete conceptual and logical data modeling.

• For creating ERDs, Visio is a common choice. It’s a full-featured software tool that many organizations already have. (Microsoft also offers a 60-day full-featured free trial of Visio, making it easy to practice using it even if your organization doesn’t have a license.)
• Alternatively, if you don’t have access to Visio, there are many web-based diagramming tools offering similar functionality to Visio. Gliffy is my favorite because it’s simple and easy to use. You can also create and save up to 5 diagrams for free.
• For a data dictionary or data mapping, Microsoft Excel is a common choice. Sometimes Excel can get a little messy and so it might be better to bring your matrix over into a Microsoft Word table, which will make it easier to add more formatting and narrative.

(In the Data Modeling for Business Analysts course, we’ve included templates and samples in these formats so you’ll be able to get started right away.)

More Sophisticated Modeling Tools Can Generate Code

When it comes to software tools and data modeling, there is one more practice you should be aware of. There are a collection of visual modeling tools that can be used to automatically generate code or databases. These are used by developers and simplify the process of programming.

If you are modeling using one of these tools, you are definitely treading outside the boundaries of a business analyst role. If you are not a developer and not responsible for designing and building database structures, you shouldn’t need to use these tools. Or, if you do use them, your models should be considered drafts for a technical design to iterate from when implementing the technical solution, not final models designed to generate code.

When in Doubt, Keep it Simple

Data modeling is complex enough without worrying about learning a lot of new software too. When in doubt, choose a piece of software that’s readily available or that you are comfortable with. Focus on communicating the data-related business requirements in the best possible way, and you’ll be achieving exactly what you need to do as a data modeling business analyst.

>>Learn More About Data Modeling

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In a certain set of circumstances, they can be done simultaneously as one stream of analysis activity. We’ll talk about when and how that works in a bit, but first let’s clarify the difference between the two deliverables and when to create each of them.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

The Difference Between a Data Dictionary and a Data Mapping Specification

• A data dictionary defines the data elements, meanings, and allowable values, often for a single data source.
• A data mapping specification defines how information from one system or data source maps to a separate system or data source.

In order to create a data mapping specification, you need to understand the data dictionaries for each of your data sources. In fact, your data mapping spreadsheet will take key pieces of information about the attributes of both sources and present them side-by-side. This allows you to evaluate how the data will flow from one source to another and what translation rules are required.

When to Create a Data Dictionary

You’ll create a Data Dictionary for the following types of projects:

• Updates to existing databases or information systems
• New databases or information technology systems
• Any project where multiple systems are using a single data source

You can create a current state dictionary to understand the data requirements for an existing data source, or a future state data dictionary to spec out the key data requirements for a to-be-created data repository.

When to Create a Data Mapping Specification

You’ll create a data mapping specification for the following types of projects:

• When source data is migrated to a new system as part of a data migration
• When source data is sent to a target data repository on a regular basis as part of a data or system integration

The type of system doesn’t really matter, they could be Commercial-Off-the-Shelf, Sofware-As-a-Service (SaaS), or in-house proprietary systems. If data is moving from one system to another, a data mapping specification will help you model those requirements.

Again, a data mapping specification can be created to model an existing data integration. But most commonly you’ll create them to model how a new data migration is supposed to be handled or a new data integration needs to work.

When to Do Both Together

Now, to the question of if and when these two documents can be created together.

Data modeling can be a complex activity that requires a lot of intellectual activity for a business analyst and a lot of collaboration with business and technical stakeholders. One reason to keep these two deliverables separate is simply to break apart the analysis into interim steps and keep things moving smoothly.

If you are working on a significant data migration project with hundreds of fields and you jump right into a data mapping exercise, you are likely to get stuck. And stuck = frustrated. One way to get unstuck is to back-pedal and create a separate data dictionary for each data source or even an ERD (entity relationship diagram) modeling out the whole project.

That being said, here are some scenarios when it could work to do the exercises together.

• You are updating the data mapping specification for an existing data integration.
• You are creating a new data model by evaluating a pre-existing data model, and so the mapping exercise is a tool for requirements discovery.
• You are working on a data migration or integration that touches a relatively small number of attributes.

It’s also likely that your data mapping exercise will require changes to one of your data models, so data mapping can lead to data dictionary updates.

When it comes down to it, as long as your data map helps you discover and resolve all of the data requirements, you’ve done what you need to do as a business analyst. If you are new to data modeling, data dictionaries and data maps will be easier to apply as discrete activities. And since they will not always be done together, you get to add two data modeling techniques to your BA toolbox.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In this article, you’ll learn what data modeling techniques to consider in specific project contexts so that you can leverage your business analyst tool box in the best possible way on any given project, making you more effective and part of driving more successful project outcomes.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

A Case Study in Selecting Data Modeling Techniques

This can start to get a little theoretical, so let’s start by looking at a sample project, why I chose each technique, and how they fit into the business analysis process. This particular project was a customer-facing information management system that was designed to replace a forms-based paper process.

• I chose to start with data mapping because I needed to understand how the information flowed from the paper-based forms to the existing information technology system. (This happened at the beginning of the project, as part of defining scope and understanding the current state.)
• Then I created a conceptual entity relationship diagram (ERD) because we needed a way to blend our new business concepts into our pre-existing database structure. (This happened in the middle of the project, as part of transitioning from requirements analysis to technical design.)
• Finally, I got into the details with a data dictionary because we were working from one data source that needed to support two separate systems. (Although I could have started the data dictionary earlier, alongside my wireframes and user stories, it was actually completed more as a wrap-up deliverable towards the end of requirements, during technical design and implementation of a future state system.)

In this particular project, I happened to use all of the techniques. However, I’ve worked on several projects throughout my career that applied only one or two of these techniques, and a few with none at all.

Different Projects Call for Different Techniques

The project you are working on will inform what techniques are appropriate. Here are some general guidelines you can use to help you decide what techniques to consider for your project.

• On a data migration project, you’d optionally start with an ERD, move on to creating current state data dictionaries for both systems (unless they already exist), and then create a future state data mapping specification to show how data moves from one system to another. If changes to either data source are required, they could be specified using a future state data dictionary.
• For a relatively small change to a pre-existing system, you might make a small update to an existing data dictionary, glossary, or ERD, but it would most likely be unnecessary to recreate all 3 of these models from scratch to represent the current state.
• For a system integration project, you might start by creating a system context diagram to map the flow of data from one system to another, move on to creating data dictionaries for each data source, and finally, if needed, create a data mapping specification. (You’d only need a data mapping if data is actually moving from one system to another, which is not always the case. More often, system integration projects, like the one mentioned in the case study above, are using a single data source.)

But again, data modeling is not required for every project. For example, a change that only impacts the user interface or flow of the application and does not actually touch the data model would not require any of these data modeling techniques.

What’s more, if you are working with a data architect or analyst, it may be that your involvement in more detailed specifications like a data dictionary is in more of an input and review capacity than a creative one.

Data Modeling Adds to Your BA Toolbox

Most business analysts think of the set of techniques they know more like a toolbox and less like a process. The techniques get swapped in and out depending on the needs of the project. Most of them can be used independently but each tool you bring out builds upon the others.

The bigger tool box you have as a business analyst, the more types of projects you’ll be able to handle successfully.

Given today’s emphasis on information technology systems, reporting, and data intensive applications, you can safely assume that you should be at least evaluating the data modeling techniques in your toolbox to see if any of them would be relevant to your project. And then you want to double check that someone with a business perspective (not technical expertise) is paying attention to them. If no one suitable comes to mind, that person is most likely to be you!

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In this article, we’ll look at the 3 different levels of modeling, describe how detailed business analysts typically get in data modeling, and look how relevant technical details get filled in.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

The 3 Different Levels of Data Modeling

Data models can look very complex, but they can also be completed at different levels of abstraction.

Let’s take a quick look at the 3 different levels of modeling:

• Conceptual Models – Represent business concepts and ideas with no consideration for the technical design. Conceptual models definitely fall under the umbrella of what the business wants.
• Logical Models – Make the business concepts theoretically implementable in a database design, but still may not include all of the details of the physical database structure. Logical models fall right in the intersection of what the business wants and how the solution team will implement it.
• Physical Models – Specify the actual database tables and fields that are created as part of the database. Physical models are under the umbrella of how the database will be designed and implemented.

Business Analysts Stick to Conceptual and Logical Models

Any of the data modeling techniques can be completed at different levels of abstraction. As business analysts, we’re most likely going to stick to conceptual and logical models. And when creating logical models, we’re most likely collaborating with more technical professionals.

For example, while ERDs can be created to model physical database structures and indicate exactly what tables to create, what primary keys to validate, and what attributes belong to each table, those details typically fall to a database architect or developer. However, a business analyst may indeed create a conceptual level ERD to visually show how business terminology, the set of terms that would be included in a glossary, relate to one another.

Similarly, when creating data dictionaries, business analysts commonly create logical models, not physical ones. A logical data dictionary would leave out many attributes and attribute details required by the database design that have no relevance to the business. (We’ll look at exactly how this works in the next section.)

How the Technical Details Get Filled Into a Data Model

While you as the business analyst may not be responsible for technical details, or the how, the project team definitely needs them. Let’s look at how a project team might evolve a conceptual or logical model into a physical database model, using the example of a data dictionary.

First, the business analyst could identify the following types of information:

• Attribute names for attributes required by the business. These are likely to surface in your  functional requirements
• Attribute types, assigned at a high level, which may or may not be the exact type assigned in the physical database
• Whether each attribute is required or optional
• And finally, any notes or additional information important to the business stakeholders that could influence the database design

At this level of detail, it doesn’t really matter if your data requirements will be built in Oracle, SQL, or some other database or data structure.

After reviewing this level of a data dictionary collaboratively with the business analyst, a database developer might identify the following types of information:

• Primary keys and unique IDs required to create a structurally-sound relational database
• Database field names that meet organizational and best-practice technical standards
• Specific attribute types, given the type of database system in place in your organization
• And perhaps a whole lot more that is rather invisible to us as business analysts

A similar process can be followed for any type of data modeling technique, with the business analyst discovering, analyzing, and validating the higher level details and a technical stakeholder fleshing out the complete design.

Let the Business Perspective Guide You

While it’s possible that the tool or technique you are using could theoretically be used to create a physical data model, that does not mean you are responsible for capturing all of the physical level, or technical how details. Whether you create conceptual what models or logical what-how models, you’ll be helping your business make better data-related requirements decisions and smoothing out the technical design process.

At the end of the day, as a business analyst the most important thing you can do is ensure the business perspective informs critical technical decisions. You are responsible for discovering the what and collaborating to help define the what-how, whether we are talking about data modeling or any other technique.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

• Entity Relationship Diagram – A handy tool that helps visualize relationships between key business concepts to encourage business-focused database designs.
• Data Dictionary – A spreadsheet format that enables you to communicate to business stakeholders clearly and in an organized way, eliminating long lists of fields inside use cases or other requirements document.
• Data Mapping – An essential template for a data migration or data integration project that will ensure any data-related issues are discovered and resolved ahead of the last-minute data crunching that often derails big projects.
• Glossary – Along with encouraging more effective communication among stakeholders, clarifying your requirements documents, and helping you learn about a new business domain, a glossary will make the rest of the data modeling techniques easier, as you’ll be working from a clear and unambiguous collection of terms.

Take a look through all 4 of these articles and make yourself more adept at both data modeling and handling tricky project challenges.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

While creating a glossary can take a bit of time and attention, doing so will generate many benefits, such as:

• Facilitate learning about a new business domain, by keeping terminology variations and acronyms straight.
• Clarify your requirements documents, by providing clear definitions of the important terms used inside them.
• Save time in requirements meetings, since stakeholders will be using a common language.
• Encourage more effective communication among stakeholders, by resolving terminology disagreements.
• Pave the way for data modeling and database designs that accurately reflect true business requirements.

As we’ll see, creating a glossary is the first step to achieving these benefits. The second is encouraging the use of the glossary terminology. You’ll receive tips for both steps in this article.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

The Key Elements of a Glossary

In its essence, a glossary is a list of terms, with accompanying definitions, and is not unlike a dictionary. However, unlike a dictionary, a glossary contains only terms that are unique to a business domain or uniquely used within that business domain.

For example, although “customer” is a commonly used word, it might also be a term in your glossary as it’s not uncommon for different business stakeholders to have different definitions of what a customer is.

Let’s look at the key elements of a glossary:

• Terms – This is the unique words or short phrases that are part of business conversations. Typically terms are nouns – or persons, places, or things.
• Definitions – Provides the exact meaning of a term in an unambiguous way and clarifies the boundaries of when the term can appropriately be used in communication.
• Alias – A word, phrase, or acronym that is used interchangeably with the primary term in your glossary.
• Related Terms – References to separate terms in your glossary which are similar to, but not interchangeable with, your primary listed terms.

Often business analysts focus on documenting lengthy glossaries that capture all possible terms used inside an organization. While hefty, these documents are rarely as useful as they feel (although they can help the business analyst tremendously in getting up to speed in a new business domain). Next let’s consider some tips for using a glossary to clarify communication.

For a quick view of why this is all so important, check out this video on the challenges created by the inconsistent use of terminology:

Using a Glossary to Clarify Communication

If we agree that the purpose of a glossary is to encourage consistent use of terminology by stakeholders and clarify requirements, then we’ll quickly realize that the glossary is only the beginning. A glossary is your reference tool and a way to capture terms, definitions, and variations as they come up in your requirements meetings.

Just as important, however, is that you encourage the consistent use of terminology. Here are a few tips for doing so:

• Use the terms consistently – absolutely consistently – in your requirements specifications, as even small variations can cause confusion. (Out of the hundreds of requirements documents I’ve reviewed, inconsistent use of terminology is one of the most common mistakes I see.)
• During requirements meetings, clarify unfamiliar or new terms before moving on. Doing so will often save lots of time resolving other requirements-related conflicts between stakeholders, as often these boil down to varying definitions between terms.
• Encourage the use of business terminology in data models by bringing forward business terminology into your ERD (Entity Relationship Diagram and Data Dictionaries. Often these documents use technical language that is confusing to business stakeholders, and technical terms can be helpfully included as aliases in your glossary.

With persistence and consistent use of glossary-based terminology, your stakeholders will start communicating more effectively, your requirements specifications will be better understood, and your data modeling will be easier.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

Essentially, a data dictionary provides a tool that enables you to communicate business stakeholder requirements in such a way that your technical team can more easily design a relational database or data structure to meet those requirements. It helps avoid project mishaps such as requiring information in a field that a business stakeholder can’t reasonably be expected to provide, or expecting the wrong type of information in a field.

What’s more, if you’ve been wondering what to do with long lists of fields inside use cases or other requirements documents, you’ll be happy to learn that they have an ideal home in a data dictionary.

Alternatively, if you’ve been creating spreadsheets to organize data-related information, you might be surprised to learn that you’ve been creating a form of a Data Dictionary. For a long time, I simply referred to these types of specifications as “content specs” or a “data matrix,” only to discover I’d been creating Data Dictionaries for over 10 years of project work.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

The Key Elements of a Data Dictionary

A Data Dictionary provides information about each attribute, also referred to as fields, of a data model. An attribute is a place in the database that holds information. For example, if we were to create a Data Dictionary representing the articles here on Bridging the Gap, we’d potentially have attributes for article title, article author, article category, and the article content itself.

A Data Dictionary is typically organized in a spreadsheet format. Each attribute is listed as a row in the spreadsheet and each column labels an element of information that is useful to know about the attribute.

Let’s look at the most common elements included in a data dictionary.

• Attribute Name – A unique identifier, typically expressed in business language, that labels each attribute.
• Optional/Required – Indicates whether information is required in an attribute before a record can be saved.
• Attribute Type – Defines what type of data is allowable in a field. Common types include text, numeric, date/time, enumerated list, look-ups, booleans, and unique identifiers.

While these are the core elements of a data dictionary, it’s not uncommon to document additional information about each element, which may include the source of the information, the table or concept in which the attribute is contained, the physical database field name, the field length, and any default values.

Example of a Data Dictionary

You are probably wondering how all of this comes together.

Here’s a look at a simplified example data dictionary that contains the attribute from our Bridging the Gap article example, along with critical information about each attribute.

As you can see, a data dictionary defines critical information about each attribute in a business-focused way. It also organizes information that might otherwise be scattered across multiple different documents and specs, making it easier for your database developer to design or update a database that meets business requirements.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

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

Participants who complete Crafting Better Requirements may have very different educational and professional backgrounds, but they all have one thing in common: they leave the course with a unique set of strategies to successfully communicate requirements to the various audiences of their requirements documents.

Let’s look at the improvements a few selected course participants have made. It may be that in reading their stories, you find your most common mistake and can benefit from their feedback as well.

Issue #1: Using “User”

Take Tina*, for example. In her first attempt to capture functional and non-functional requirements for an online web store, she did a great job creating precise requirements, but repeatedly made the mistake of using the generic term “user” to refer to very different types of users of the web store application. All her requirements started with, “The user will be able to…”  While for business stakeholders this may not be a problem (since they implicitly know what actors are expected to have access to specific functions in the system), for the development team this could be a source of misunderstandings that might delay the delivery of a usable solution. With the feedback provided during the course, Tina was able to quickly improve the way she was capturing requirements, starting to use specific actors to identify who would be able to perform each function described (“the customer can add products to cart”, “the webstore manager can run daily reports of online orders”, and so on).

Issue #2: Vague Requirements

Bob*, on the other hand, already had the habit of identifying the correct actors, but was used to writing vague requirements that elicited lots of questions from the development team. For example, as part of the requirements for a keyword-based search, he would write, “Search engine should return search results fast to customer.” But  what does “fast” mean? The business could be thinking that it means returning results in less than 2 seconds, while the development team is assuming 10 seconds or less (because it would already be a challenge to retrieve the results in this amount of time using the existing IT infrastructure). QA would not have enough information to create test cases in order to ensure this requirement had been fulfilled. Once this weakness was identified, Bob was able to train himself to look at his requirements from the viewpoint of the people who would need to implement and test them (rather than just from the perspective of the stakeholders who will benefit from the solution, and thus know what the expectations are). By always asking, “How would I test if this requirement is correctly implemented?”, he was able to increase the level of detail of his specifications and substantially reduce the number of questions he got from the development team to clarify requirements.

Issue #3: Poor Organization

Jane* was always trying to get her manager and colleagues to look at her requirements to find areas for improvement before she shared her specifications with technical and business stakeholders. However, her manager wasn’t trained in requirements documentation, and the other BAs on her team didn’t have time for more than a cursory look at her documents, so the feedback she’d get was insufficient to surface the problems with her specifications. Only during the final review would the stakeholders give their full attention to her requirements, and ask questions that required Jane to go back and make a series of updates in the documentation before getting the necessary approvals.

During the course, Crafting Better Requirements, Jane finally had a chance to receive in-depth feedback for her requirements statements, and identify the flaws in the way she was documenting them. She learned some useful strategies, such as grouping requirements by functional area and user type to make it easier to spot missing requirements. Using her new set of strategies, she was able to decrease the number of review sessions required to get sign-off for her requirements documents.

* Names have been changed for privacy.

How to Leverage Feedback for Improvement

In these and other success stories collected over the years since the launch of Crafting Better Requirements, the main benefit the participants received from the course is the ability to focus on their own specific weaknesses, rather than follow a predefined curriculum. Based on the identified areas of improvement, some participants will spend most of the time practicing writing requirements statements to make them more concise and less ambiguous, while others may dedicate more cycles to creating diagrams to augment their requirements using visual representation, or learning how to create more effective acceptance criteria for their user stories. Instead of standardized teaching, they are able to experience customized learning based on individual feedback and personalized instruction and assignments which, in the words of a participant, “drastically reduced my learning curve.”

As a result of the customized feedback provided throughout the course, and the opportunity to use deliberate practice to overcome their individual weaknesses, these business analysts not only acquired new valuable skills, but also increased the value they provide to their organizations. The benefits for the companies these BAs work for include shorter requirements cycle time, less back and forth with developers to clarify requirements after sign-off, and fewer change requests submitted during user acceptance testing due to incomplete or incorrect requirements.

Those new to BPMN understandably find it overwhelming. There are flow objects, connecting objects, swim lanes, and artifacts. And that’s just the categories within the notation. Overall, there are over 40 different elements, each with rules about when it can and cannot be used.

(In contrast, our quick list of workflow diagramming elements in the Business Process Analysis course contains the 5 elements that are used by the majority of practicing business analysts.)

If you are new to business analysis, looking at the skill set for models completed in alignment with the BPMN standard might stop you in your tracks.

As it should.

For all of us, new to business analysis or not.

(Before I forget, be sure to download our free business process template.)

When to Use BPMN

In my experience, there are only 3 good reasons for using BPMN notation.

1. You find yourself stuck using the handful of most commonly used workflow diagram elements to represent a concept. In this scenario, it makes sense to selectively draw from BPMN to model the process.
2. Your organization requires you to use it. If this is the case, the application of BPMN should be tied to a larger organizational objective. It also typically means you are completing more formal modeling that is implementable in business process management tools.
3. You are applying for a job you are otherwise qualified for that requires knowledge of or experience with BPMN notation. By all means, learn the techniques and create a few work samples using the notation.

Unless one of these 3 reasons applies, using BPMN for the sake of doing BPMN can do more harm than good.

Risks of Using BPMN

And there are many risks to using BPMN, when it’s not expressly needed.

• The models we create are more difficult for our stakeholders to understand, potentially leading to business processes that include incorrect information.
• It’s more complex for us to create models, meaning we need more analysis time to deliver the same amount of value, unless the use of the notation is specifically tied to other business objectives.
• We’re more likely to make modeling mistakes, which decrease rather than increase the clarity of our process flows.

Like any analysis tool in your business analyst tool belt, choose BPMN with care. And if you are just starting out as a business analyst, it’s probably going to make more sense for you to pursue business analysis jobs requiring workflow diagrams and process models rather than those requiring BPMN techniques. BPMN is an advanced technique and you can learn it once you’ve mastered the more fundamental skills of a business analyst.

>>Download Your Free Business Process Template

Get started analyzing a business process today, with our complimentary business process template.

• Help business users from multiple departments clarify their actual step-by-step workflow;
• Avoid wasting money on software solutions that don’t solve the right business problems;
• And even helping new business analysts figure out what questions to ask when starting on a new project or domain.

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.

Click here to download your free business process template today

Choosing the best deliverables for a project situation is a necessary skill to be an effective and valued business analyst and sometimes use cases are simply not the right choice. In certain project contexts, choosing use cases means creating way too much documentation. In other contexts, the use cases make it difficult to highlight the most important requirements so they can be easily implemented. Other times, they are simply not an appropriate tool for the type of requirements you are creating.

That being said, I do have my own love affair with use cases, the latest installation of which is facilitating a virtual course called Use Cases and Wireframes. Love affair or not, use cases are not always the best choice.

Let’s look at 3 signs you shouldn’t be writing a use case.

Sign 1: You Are Not Specifying Software Requirements

Use cases are ideal for specifying functional requirements in such a way that shows how the user interacts with a software system to achieve a specific user or business goal. If you are not documenting requirements for software, then you shouldn’t be writing a use case.

If you are not specifying software requirements, you are most likely defining requirements for a business process change. If so, consider a business process model.

Sign 2: Software Changes Are Not Interactive or User-Driven

A use case is an ideal choice for providing context to user-driven or interactive software features. Because each functional requirement happens in response to a user action, there is a flow to a use case that makes them easy to understand and review. However, it’s possible to specify software changes and requirements that are not particularly interactive.

For example, let’s look at reporting requirements. Typically when you write reporting requirements you are working from an existing reporting system. The functionality already exists for selecting a report, selecting criteria, and generating the report. A typical small project will add a new report to the existing system. It might be tempting to write a use case to describe the report, but unless the report itself is interactive (for example, if you click on a data row, then filtering is applied) there is not much value in writing a full-blown use case to capture these requirements. Instead a detailed wireframe (perhaps with an accompanying user interface specification) or sample report would be better choices.

Of course, if you are building a new reporting system or updating the flow of an existing reporting system, then a use case could be entirely appropriate. For instance, if users are going to be able to generate their own reports for the first time by specifying criteria and choosing from a list of report types, then a use case could be a very logical choice for detailing these functional requirements.

Sign 3: Your Team Prefers Another Form of Documentation

No matter how much we like one business analysis technique, it’s important that we customize our business analysis activities to meet the need of our stakeholders. When it comes to functional software requirements, the needs of our technical implementation stakeholders in software development and quality assurance are of primary concern.

They might prefer a functional specification so that all of the requirements are included in one document. Or, if they are using agile methods on their project, they may prefer a collection of user stories with a few selected visual models to tie the requirements together. In light of your team’s preferences, you might choose not to write use cases even if they’d be a logical and appropriate choice otherwise.

(On the flip side, if your technology team has been asking for a simpler solution to a functional requirements spec, you could run a few use cases by them and see if they work better than your current process. Or, you might find that you do your best analytical thinking by writing use cases and so create some working drafts that do not become part of your final work product.)

How to Choose Your BA Deliverables Wisely

There is no one type of business analysis deliverable that must be created in all situations. Smart BAs make smart choices based on the type of requirements they are specifying and the needs of the project team. Make a choice that you can defend and start with it. Seek feedback and iterate until you find a deliverable mix that works for you, your business stakeholders, and your implementation team.

When in doubt, remember that it’s not likely your project is destined to fail if you choose a technique that’s not a perfect fit. You’ll have many opportunities to course correct as long as you pay attention to feedback and keep an eye on your project’s scope along the way.

Learn How to Create Use Cases
(and Wireframes Too)

Interested in learning how to write a use case? 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.

Let’s take a look at some of the circumstances that slow the requirements process down and how visuals can create breakthroughs that help you get things done faster.

Speed Up Requirements Discovery With A Clarifying Model

First and foremost, the time I turn to visual modeling is when stakeholders are failing to understand each other. While clarifying language and asking good questions can clear up many ambiguities, sometimes it’s simply not enough to talk through a problem or issue.

For example, on one project we were figuring out how to provide customer access to a collection of information previously restricted to internal users. The way the customers thought about the information was very different than how the system that had been created 10+ years earlier stored the information. Every time we started a conversation, stakeholders would be talking in a mix of customer terminology and database fields and everyone would be so confused that we didn’t get very far.

I decided it was time to take a step back. I created a very rough draft of a business domain model in the customer’s terms and we walked through it step-by-step, making adjustments as we went along. For the purposes of the discussion we ignored the database fields or how the information was actually stored. The meeting took nearly 2 hours but at the end we had a working set of language from which we could discuss actual requirements and the requirements process started moving briskly. The visual model was critical to help everyone see how the concepts related and learn to use a shared language.

(By the way, this is a scenario we dive into more deeply in the Visual Modeling Guidebook included with the Visual Model Sample Pack.)

Break Down a Complex Problem Faster with a Diagram

A second scenario where visual models can speed up the requirements process is when there is a complex problem to analyze. I can’t count how many times I’ve stared at a blank sheet of paper or requirements template only to not have any clue what goes where. In these cases, starting a diagram, often on a sheet of scrap paper, helps me think better and analyze the problem more completely.

For example, I drew and redrew the process model version of the BA Career Roadmap at least 5 times before using a tool to capture it electronically. Then and only then did my designer start working to bring it to life as a roadmap.

Drawing the process was not academic. I was working through different aspects of the process and rethinking how to present the information. It was much faster to draw new versions of the process model than, say, write up a formal textual model or narrative. Those elements were important and they came later, once I’d worked through the most complex issues.

While I don’t always share these rough diagrams with my stakeholders, sometimes I do, and that brings me to the next scenario.

Accelerate Requirements Reviews by Providing Context

Just like you can get stuck staring at a blank template, your stakeholders can get stuck reading a filled-in document.

• What does this requirement mean?
• How does it fit into the other requirements?
• Is it right or is it wrong?

Requirements reviews can create a lot of anxiety for stakeholders. On the one hand, they know they need to provide good feedback to get what they want. On the other, they may not fully understand what they are reading.

Diagrams can help speed up their understanding and help stakeholders feel more comfortable with the business analysis process. Diagrams like workflow models put processes in context. Diagrams like business domain models clarify complex concepts in business terms. Diagrams like a wireframe provide an idea of what the requirements might look like on the screen, making it much more clear how the details fit together.

And all of this means that you get better feedback on your textual requirements earlier in the process.

Recapture Time You’re Losing Now By Using Visual Models

The time you spend creating visuals has an immediate payoff – so while they do take time to create, you recapture the time you would have spent in meetings wrangling concepts that the visuals easily explain. Just like good cooks get all their ingredients prepared in advance and good painters prep the walls and trim with tape and paper, good analysts prep visual models so they get as much as possible right the first time.

As we consider what the industry is asking us to do as business analysts – digging further into discovering and delivering value, paying attention to business outcomes and increasing  stakeholder involvement – getting good at visual modeling gives us an edge that people notice. It’s one of the tools in our tool belt we need to hone because it helps us think more clearly and communicate more easily.

I’m excited to be able to help you learn to use visual models on this part of your BA journey. The Visual Model Sample Pack contains 22 real-world visual model samples covering everything from UML diagrams to whiteboard drawings shared from the files of a working BA. You’ll be able to more easily incorporate visuals into your requirements process and get the process moving faster.

Click here to learn more about the Visual Model Sample Pack

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.

I had a template, a big one in fact. It had 20, maybe even 30 sections in it. And my discipline led me to believe that putting something in each and every one of those sections was the best way to be effective as a business analyst.

After all, someone wouldn’t have added it to the template if it wasn’t important, right?

So, what could go in this particular section?

If I didn’t have an idea, I’d ask the project team. After all, that’s what I’d seen the other BAs do when I was sitting in on their requirements meetings.

So I’d ask. And wait. And think. And struggle a bit.

And by now we are all feeling a bit squeamish and uncomfortable. That hot-head architect is just dying to take a pot shot at me and start a discussion about the template itself and completely derail my meeting. I can feel it coming.

“Oh! What about this?” says the product manager.

{collective sigh of relief}

Yes, that works, a few people nod.

I write a note.

We move on.

Of course, I know that we’ve already captured “this” in another section and I’m crossing my fingers under the conference room table that the uber-smart architect doesn’t call me out on it. But since it also fits here, I can decide how to handle the duplication when I get back to my desk. For now, I’m quickly moving on to a more interesting part of this particular requirements review meeting before anyone else notices.

{fast forward a few years}

I switch organizations and am responsible for starting a new BA practice-of-1. One day while working on a draft of my requirements specification, I realize that I own this. No one at this organization has ever seen this template. No one. They won’t know if I just remove a section or two or three or (yikes!) four and let it die a slow and painful death on my PC.

I think about the pros and cons of this decision.

• I realize that I’ve been letting the templates be my master instead of mastering them.
• I realize that as safe as it feels to fill in every section of a trusted template, it’s not safe at all, especially if no one is reading the thing.
• I realize that I can choose a better way.

My business analysis life starts afresh. I will do better. I will write better. I will serve better. Over the course of the next several years, a transformation happens.

• Instead of thinking big, I start to think small.
• Instead of thinking fill in the blank, I think about decisions and next steps.
• Instead of thinking about an abstract sense of completeness, I think about usefulness.

It all starts with losing my dependence on the long, laborious templates that felt very, very safe. Somewhere along the way I shed my greenness and while I keep my discipline, I apply it using a different set of principles. Somewhere along the way, my requirements start to get just a little bit spunky.

From time to time, I still look back.

I wish that way back when I had the license to cut up my templates so that my documentation would have been shorter and relevant and my meetings less painful.

I wish that way back when I had a more concise starting point so that my documentation would naturally be more readable.

I wish that way back when I was told to add if needed instead of play a game of fill-in-the-very-large-set-of-blanks.

I can’t get back the hours I wasted and the spunk I sucked out of those early requirements documents (and their meetings). But I can give you a simpler starting point.

And that’s exactly what I’ve done with the Business Analyst Template Toolkit. The templates are short and you are welcome to add or subtract. The Toolkit also includes work samples so you can see exactly how the template works and what it helps you accomplish in your requirements documentation. And a guidebook walks you through my approach so you can use it as a starting point for your next project.

I wish I had a lighter starting point way back when, so I wouldn’t have had to learn how to streamline my documentation in a much more painful way. And that’s why I’ve annotated my templates and am sharing them with the business analyst community.

>>Learn More About Templates and Requirements

Click on one of the links below to learn more about how we approach templates and requirements:

• I’m Letting Go of the Big Thick Requirements Document, Are You?
• How to Present Yourself as Capable of Doing Requirements Specifications (Even If You’ve Only Created Informal Documentation)
• Requirements Templates: What To Do When You Must Start From Scratch

Well, you’ll find plenty of answers out there about the one “right” way to do business analysis, but that’s never been the message here at Bridging the Gap. Here we know and believe that there are many right ways to do business analysis and what’s right for one project, one stakeholder group, and one organization may be completely wrong for another.

When you think about it, that makes sense, right?

Yet this doesn’t give you much to go on if you are a new business analyst on your first project or an aspiring business analyst beginning to look at what you’ve done using the filter of business analysis.

So let’s dig into this a little deeper and talk about how a business analyst approaches a software project.

When figuring out my approach to a project, I break my work up into three phases that I find to be particularly useful buckets in which to think about business analysis.

Here they are the three phases:

• Initiate the project,
• Elaborate the details, and
• Support the implementation.

In what follows, we’ll look at each phase in more detail, look at examples of what techniques and specifications you’d create in each phase, and define what it means to be done with each phase.

Initiate the Software Project

Initiating the project involves identifying the problem to be solved and establishing enough about what the solution looks like that a definitive go/no-go decision can be made about whether to fund the project.

This is the time that we bring together the stakeholders and kick off the project and ensure that we have all the information that we need to make an informed decision about the project direction. If you are working in a new business domain this phase would include understanding the key terminology, which is often captured in a glossary or domain model, as well as the organization’s current capabilities.

The deliverable from this phase of work is often a Scope Document (or vision document or business requirements document). And a Requirements Development Plan can prove very useful as well. And if the current business process is unknown, you might do some business process analysis as part of initiating the project too.

In my early days as a business analyst, this phase included a 50+-page functional requirements document. Over time, I realized that there was so much redundancy between the functional requirements document and a body of use cases that formed implementable functional requirements (we’re getting to that next), that I cut this document back significantly and save loads of time. I essentially replaced the list of detailed functional requirements with a high-level list of features (that’s what you’ll find in our Business Analyst Template Toolkit) and have never looked back.

Once you’ve got the go-ahead to move forward with the project, it’s time to elaborate the details. Let’s talk about this next.

Elaborate the Details of the Software Project

Elaborating the details is really the meat of the business analyst role, and it’s probably the piece that you think of most when you think about business analysis.  This is where we get into analyzing the requirements and ensure the implementation team has all of the details they need to build or implement the solution. Often this phase involves working with multiple stakeholders across the organization to ensure their knowledge and needs are incorporated into the detailed decisions about what will actually get built.

In a more traditional or waterfall environment, this phase is combined with initiating the project and that means the decision of whether or not to fund the project may not be made until all of the functional requirements are detailed out. In my experience, that tends to be a bit late in the game, after a lot of stakeholder time and trust is absorbed into the project by then, not to imagine weeks or months of analysis time. More often than not, the cost estimates you can get from a high-level features list are more than adequate to support high-level scoping.

This is part of the reason I stopped doing functional specifications up front, streamlined my scope document template, and replaced the functional specification with a set of use cases and wireframes. (On an agile project, I’ll replace the use case list with a product backlog and the set of use cases with user stories.) Depending on the project, you may need a data specification or model as well.

Regardless of how you choose to specify it, this phase is complete when your stakeholders have signed off on what will be implemented and your developers have what they need to design and implement the software solution. In many organizations today, this part of the project is approached in an iterative fashion. That means that the BA prepares the functional specifications in phases, which are approved by the business and then designed and implemented by the software development team. Use cases and user stories are much more naturally suited to this iterative approach than a single functional specification.

As a certain set of requirements is ready for development to start, the business analyst role typically shifts from an active one to a reactive one.

Support the Implementation of the Software Project

Supporting implementation is when BAs are involved through the end of the life cycle.  BAs are not typically involved directly in implementation unless they’re holding additional roles on the project.  But they are typically brought in if issues come up during implementation that cause some new requirements to be addressed. This could involve facilitating a problem-solving meeting to discover how a particular business need can be met given newly discovered technology constraints.

For example, when redesigning this very website, we had made an assumption about how the author profiles would work. Then we discovered that WordPress no longer supported the functionality we needed. We revisited the author profile page and came up with a simple and elegant solution.

As the implementation is completed, sometimes business analysts do have a more active role. You might be asked to help the business accept the solution that’s being implemented. This can take the form of “to be” business process models that analyze how the business stakeholders will use the new solution to complete specific tasks and activities. It can also include training, user documentation, or user acceptance testing.

It’s becoming increasingly common for the business analyst to continue to be involved in the project through this stage, and this phase is complete when the software is released to a production environment and the business stakeholders are able to use it successfully to do their jobs.

Of course, during the process of implementing the solution, new needs and requirements may be discovered, and the business analyst might pick up new projects to initiate…and the cycle continues.

Find Your Approach

These phases are useful because they give you a simple framework to look at what stage of analysis you are in and decide what milestone you need to move your project team towards next. You can start analysis at any phase and sometimes you’ll find yourself moving backward and forward or cycling through the phases.

When in doubt about what step to take or what deliverable to create or what technique to use (no matter how experienced you get as a BA, you have these doubts), identify the phase you are in and determine what next step will move you closest to completing the phase.

Interested in Learning More?

Click here to read about the Requirements Specifications a Business Analyst Creates

In this article, we’ll discuss what these terms mean, as well as provide some examples that you can use to match up your own career experience.

But first, a story.

My husband and I have taken to watching a lot of Jimmy Fallon lately. (We love to laugh and Jimmy is great, especially when replayed on the DVR at 8:30 pm. :-)) In one show, Jimmy had someone on his show with a plastic 3-D printer. These have been around for years, but now they are affordable outside of big scale R&D organizations.

That’s a fairly interesting development, don’t you think?

For a few thousand dollars and some extra garage space, I could print out plastic prototypes of physical objects. If I was designing a physical product, I could actually hold that product in my hands before investing in producing the real thing.

Have you ever held a pen that didn’t feel right in your hand while scribbling down meeting notes?

Did you wish someone had let someone like you try the pen before they produced it?

With prototyping, this becomes an economically viable expectation.

And prototyping is a relevant technique when creating IT systems too. Except it’s not about printing plastic. But it’s still called a prototype. Well, sometimes. Other people call it user interface mock-ups. You’ll also see them called wireframes.

Each of these terms has their own formal and closer-to-“right” definitions and we’ll get to those below. But the reality is that the terms can almost be used interchangeably. What’s more, depending on who you are talking to they can mean very different things (or the same exact things). This means that when any one of these terms are used in a job posting, it’s best to clarify what exactly is meant. (And especially to do so before saying, “I’m not qualified to do that!” because you may very, very well be qualified.)

The General Definition of Wireframe, Mock-Up, or User Interface Prototype

Let’s look at the collection of activities that might be considered relevant to anyone using prototype, wireframe, mock-ups, visual renderings, or any other variation on these terms.

In short, any of these visual renderings is a representation of a graphical user interface (GUI), or any interface that allows a user to interact with a device using images and clicks rather text commands.

• This web page and any other you might browse is a GUI and so are the apps you download to your iPhone.
• The TV programming screen where we select the recorded Jimmy Fallon episode with the highest potential to make us laugh is a GUI.
• If your organization has a proprietary software system, whether it’s web based or deployed on employees’ desktops, it probably has a GUI.

As a quick aside, I once worked for a company that called their internal system simply the “GUI”. As they replaced a phone based information management system, their consultants told them they were building a GUI and the application never got a more specific name. GUIs are everywhere. But I digress.

Let’s get back to the visual representation of the GUI, because that’s the part you might work on as a business analyst. The representation can include one or more screens or pages, show the navigational elements on each page, and sometimes show the navigation between pages.

We cover this in more detail in The Business Analyst Blueprint® certification program, where you can earn your Applied Certification in Business Analysis.

What a Mock-Up or Wireframe Typically Looks Like

For example, here’s a visual rendering I created for Bridging the Gap.

(This type of rendering is closest to what would typically be called a mock-up or wireframe, because it’s low fidelity, and I would typically create one to accompany a use case. It was created with a tool called Balsamiq which is available for less than $100. The tool is much more powerful than what you see here. If I had invested more time, I could have made this look a heck of a lot better. But I tend to take shortcuts when wireframing so that I don’t get bogged down in the process.)

What a Higher Fidelity Visual Rendering, or Prototype, Looks Like

And here’s an example of what a designer created to turn this conceptual rendering into a higher fidelity visual rendering.

Starting to look a bit more beautiful, eh?

(This type of visual model is close to what would typically be called a rendering, because it is showing the exact intended look or what’s called high fidelity. And because my designer chose to create this rendering in a web framework, it is actually more like what would most commonly be called a prototype, because I could click around and get the experience of the new website, just like I could hold a plastic pen in my hand and pretend to write.)

Let’s talk a little bit more about prototypes, shall we?

In general, like the WordPress prototype my designer created for Bridging the Gap, a prototype is functional in nature. And that means your user can actually click things and have something reasonable pop up as a result, which helps them provide a great amount of feedback in the elicitation process. (I’m expecting that any day now my designer will stop being so gracious about my feedback and adjustments!)

Without any coding knowledge, I’ve created similar, albeit less visually pleasing prototypes (again, I love those shortcuts), using a tool called Axure.

Here’s an example of a a pretty ugly prototype that ended up being the a really, really old home page here at Bridging the Gap. (This is a screen shot from a click-through prototype created in Axure – those yellow icons indicate clickable buttons.)

Have You Created Wireframes, Mock-Ups, or Prototypes?

If you’ve ever created anything along the lines of what you see above – or significantly less beautiful (such as a hand-drawing or whiteboard drawing) or significantly more beautiful (such as a rendering created in Photoshop) or significantly more functional (such as working code that was intended for a demonstration), you have relevant experience in this area of business analysis.

At the end of the day, it’s not about the technology you used. What “counts” as relevant experience is the putting something visual and tentative in front of people who will actually use the finished product and getting their feedback.

Essentially, you allow your users to hold a plastic pen. Now I’m going to head back to watching the next promising Jimmy Fallon episode.

How to Learn More About Wireframes (and so much more…)

If you are looking to gain more confidence in wireframes, along with the other foundational skill sets that are key to success as a business analyst, check out  The Business Analyst Blueprint® certification program.

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

Business processes are everywhere and most of any typical organization’s processes are largely unmapped. And that means there are many BA opportunities ripe for the plucking, whether you are employed as a business analyst or not.

But what processes should you or could you map? Let’s look at five processes that are almost always worth documenting.

#1 – Process to Implement Software Changes

You might think that if you come from the IT side, you don’t have much in the way of business processes. However, the business includes the information technology team, and there are many processes within the technology team that could often benefit from being documented and clarified.

One of the most valuable processes to get a handle on tends to be how software changes are implemented. The Implement Software Changes process could include the following steps:

• Identify and approve the change, which could involve many decision-makers with varying levels of influence and authority. 
• Create the software code to implement the change.
• Test the change and validate the new code works as expected.
• Fix any defects or deployment issues.
• Release the change to a test and/or production environment. Again, this can often involve many decision-makers and gate-keepers and include sub-processes for each system component involved in the release package.

At a high-level, you could capture your entire release as is process. Alternatively, any one of these steps could be a process in and of itself, which leads us to our next opportunity – the process to test a software system.

#2 – Process to Test a Software System

This one happens to be my personal favorite – the test process – and that’s because this is the process I conquered before moving into my business analyst role. Typically the test process is documented in a test plan. If you are in QA and look closely at your test plan, you might be surprised to find the seeds of a process flow within it. When I was a QA engineer, my test process included:

• A set of preconditions determining that the system was ready to test.
• The business users to get involved in the test process and the criteria for identifying them on a new project.
• Specific areas of the software application I needed each business user to evaluate.
• The steps for anyone testing to submit a defect for resolution.
• The communication path from me to the development team about the defect (and then back to the business user as a resolution was found and made).

Whether or not you have the title of Quality Assurance Engineer, if you are involved in the validation of software (or any other validation process for that matter), the process you use to test the system, communicate the issues you find, and follow up to ensure those issues are resolved is worthy of a business process model.

And if you are not part of the technology team (which is the case for many of our Business Process Analysis participants), I think you’ll find processes to map everywhere you look. Let’s look at a couple of the most common processes for which mapping efforts can be particularly valuable.

#3 – Process to Resolve Support Issues

Do customers, clients, users, or even members other departments send you issues that need to be resolved? How are these handled? Issue resolution is one of the most troublesome processes for nearly any organization or team. And that’s because issues often need to be bounced around between team members and departments until all the right information related to the issue is discovered, organized, and acted upon.

This process might be called Support Customers, Resolve User Queries, Deliver on Service Level Agreements, or Manage Support Requests. It could involve any of the following complexities: