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.

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

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

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

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!

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.

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Little did I know this task had a special place in the BABOK – Maintain Requirements for Re-Use. The purpose of this task is:

“To manage knowledge of requirements following their implementation.”

OK, so a lot more goes into understanding the capabilities of legacy systems than reusable requirements, but reusable requirements are the primary output of this initiative.

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

There is significant value in maintaining requirements for re-use. The activity can save future business analysts significant time in rediscovering requirements. It can also help speed up the requirements development process for future initiatives by helping provide ready-at-hand answers to questions about business rules, logic, and even, “Why did we do that?” (provided your requirements are documented with some context).

However, even slightly out-of-date requirements quickly lose their value. If you can’t trust the information you find in the requirements document and need to confirm it, the requirements become merely one more source of information, not the authoritative source of information.

Yet, often we do not have time during or after our projects to update requirements specifications or create “as is” system documentation. And, the requirements for one project tend to supersede those of the last one, meaning that project documentation is not necessarily the best way to capture this information.

I’ve started initiatives to have a central repository, much like Adriana describes in part 2 of her article on knowledge sharing strategies, in a few organizations. In one case, I slowly built a repository of use cases, taking each project assignment as an opportunity to discover system functionality in related areas and add it to the main source of requirements documentation. A couple of years later, I was surprised to learn that someone had picked up this documentation and used it as the starting point for a strategic project, which I felt validated the effort I’d put into the materials! While it was likely that some of the content was out-of-date, the structure I’d created for the requirements (another topic we’ll address from the BABOK perspective) proved useful in understanding the system functionality.

In another organization a BA I worked with, started a collection of wiki pages to capture key requirements and business rules. In another, I delegated this effort primarily to the test team, where their first task in supporting a new organization via our quality assurance process was to build a set of functional areas to regression test that were eventually elaborated into specific regression tests.

>>See What These Requirements Documents Look Like

Would you like a starting point for approaching common business analyst work scenarios? Along with work samples so you can see what a typical requirements document looks like? Check out the Business Analyst Template Toolkit – all of the requirements templates are fully annotated and editable by you, giving you a great starting point for starting your first business analyst project or formalizing your work samples.

Click here to learn more about the BA Template Toolkit

That’s why it’s no surprise that there is a discrete task in the BABOK for planning business analysis activities. Its purpose is to:

“Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables.”

This task is where we determine exactly what it is going to take to develop the requirements for a particular project.

Most often, I have done this by creating a list of deliverables to detail the scope of a project. For example, if requirements were to be detailed in use cases and user interface specifications, I’d create an Excel spreadsheet listing the names and descriptions of each use case and user interface specification along with other important information such as status and, when needed, an estimate. Then, this list was incorporated into the project manager’s schedule, at which point I would assign target start and end dates based on my estimates and the stakeholder resources I had access to. For most projects I’ve worked on, a spreadsheet of deliverables and a project schedule with timelines has been enough to track progress.

The BABOK reminds us that this task typically occurs more than once to address changing business conditions. I agree. In my experience planning, even in a relatively waterfall-like project, is an iterative process. As you develop requirements, you learn more about the scope and often need to revisit what’s possible within the constraints of the project.

I’ve also had shifts in methodology or approach change the plan. On one project, I began with a fairly RUP-based process. I had created a scope document and was part-way through drafting a list of use cases to organize the project requirements. Then we met with the third-part development team who proposed (er, demanded) we use their version of an agile methodology. Over the course of the next week, I reconfigured my plan, learning about how to create a product backlog and create user stories. I readjusted my estimates, although they were even more tentative now that I was working with a new-to-me methodology.  Once again, I found myself planning to plan.

Don’t Start Your Plan From Scratch

My Business Analyst Template Toolkit includes a Requirements Development Plan and Use Case List Template that can help kick-start the planning process for your next project (without going overboard and investing more in the plan for the plan than well, the actual plan).

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

Perhaps even more than planning for elicitation, planning the business analysis approach will set a mature business analyst apart from the crowd. The purpose of ‘Plan the Business Analysis Approach’ is to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted and informed of the approach, and the rationale for using it.

Although the BABOK is not a methodology, that doesn’t mean the BA is off the hook for creating a methodology in the context of their project or organization. And this is the task where that methodology, more generally called an approach, is put together.

First, BABOK distinguishes between plan-driven approaches and change-driven approaches, noting that most methodologies are somewhere in the middle. Plan-driven approaches focus on minimizing upfront certainty – we might think of “pure waterfall” (if such a thing even exists anymore) as a pure plan-driven methodology. Change-driven approaches focus on rapid delivery of business value in short iterations. The most visible example of a change-driven approach is agile, though continuous process improvement initiatives such as Six Sigma would fall under this category as well.

An important note is that the BA methodology does not live in isolation – it is either part of or integrated with the methodology for the project, which will cover many other aspects of delivering the project in addition to the requirements development effort. By the time you’ve defined your BA methodology, you’ll have a good idea of the role of the BA for this project, timing of BA work, formality of BA documentation, approach to requirements prioritization, change management process, business analysis planning process, and any requirements management tools you’ll employ.

This is quite a lot of decisions to make! My formal experience in this area is somewhat weak. The reality is that I’ve done individual pieces of BA planning often, such as choosing a prioritization scheme. Others I’ve done informally, such as timing the BA work with the project and choosing a level of formality that suits the project.

Instead of upfront planning to figure this out, I often approach timing and formality through trial and error. Sure, I’ll start by asking about expectations and look for guidance, but instead of starting from scratch, I’ll leverage something from my repository of templates (which I’ve now made available in the BA Template Toolkit), ask for feedback, try something different, rinse and repeat. I have also worked in many smaller environments where we are building the BA practice from scratch and my stakeholders just don’t know what they don’t know about what they want from a BA. So instead of diligent planning,  eyes-open trial and error tends to lay out an approach most efficiently.

There is one story I have to share where I truly did complete a much more rigorous plan. I’ve written a few times about my role in helping consolidate technology systems from 5 disparate organizations. In this position, I hired first one BA, then a second to help support the project. With more than one BA on the same project, a defined approach became essential. We developed some common templates and set expectations about the level of granularity of requirements within each template. We defined some common ways of working with a very large stakeholder group and prioritizing requirements. We explored potential tools to store and manage requirements, first using Excel spreadsheets and a SharePoint site, then exploring DOORS and other configuration management tools. This was one area that we iterated through several times throughout the project and modified as plans for delivering the solution changed.

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

Kick-Start Your BA Methodology

The Business Analyst Template Toolkit includes a set of fully annotated business analysis templates you can use to develop your BA methodology or plan for your next project.

Click here to learn more about the BA Template Toolkit

When working as an agile business analyst, I’ve learned to stay at least one step (but only a step or two) ahead of the development team to maximize our productivity. Let’s look at what the process of grooming the product backlog looks like and how it improves productivity.

Requirements Drive Planning in Agile

In agile, requirements (or user stories) drive planning. Requirements are managed in a product backlog of user stories. The user stories are ranked by priority and the highest priority items are detailed out.

There are differing opinions on what should be done prior to sprint planning vs. what should be done within sprint planning.   On the teams I’ve participated in, we focus sprint planning sessions on understanding a handful of user stories in detail and planning the tasks it will take to complete the stories.

This means that prior to planning I have prioritized the backlog, detailed out the user stories with conditions of acceptance, and collaborated with the development team on an estimate for each story. In many cases I found that estimates actually helped the business prioritize, so we estimated early and we estimate often.

There is definitely a different requirements cadence when grooming the backlog versus finalizing a set of use cases or functional specifications.

Meet Regularly with Software Developers about New Stories

I meet regularly with my software developers to talk about new stories and requirements that are being considered. In these discussions, we estimate the story if we have enough information. I also ask questions to understand the constraints. Oftentimes I’ll come away with information about how we can constrain a story to keep it small or what detailed requirements would require additional work. If there is not enough information to estimate the story, I come away with some open questions I can follow up on so we can estimate it the next time.

Sometimes these discussions reveal that something I thought was fairly small is actually a larger story and needs to be broken up, or what you might call an epic. All of this information helps me create a backlog that the developers can work with during planning.

Prioritize the Product Backlog

Most SCRUM and agile books will tell you to rank prioritize the entire product backlog. In my experience, this practice creates an extremely large amount of overhead. The value in rank prioritization is really with the product backlog items that might be addressed in the next few sprints. As such, I tend to break product backlog items up into releases or group them together in a general priority. Then, for the items that we have the capacity to address in the next few sprints I help the business rank prioritize.

Detail out the Highest Priority Backlog Items

As we head into sprint planning, I ensure that the highest priority product backlog items have detailed requirements behind them. These detailed requirements are captured in user stories. Along with the requirements for the story, I draft conditions of acceptance or the tests that need to pass in order for the story to be considered “done”. During sprint planning, we review the requirements in detail and often adjust them for clarity or to answer questions that come up. During the sprint, if the developer discovers a new condition or rule, we’ll often continue to adjust the user story so that the entire team has a shared concept of “done.”

To keep up with the sustained momentum of an agile development environment, grooming the product backlog for the immediate future is often the most important task a business analyst can do to help make the development team successful.

>> Learn More About Agile Requirements

Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.

Click here to learn more about Use Cases and Wireframes

Given that this is a common challenge, I thought I’d share a bit on the way I approach project situations with little to no processes in place or templates to use.

1. First, I get my head around the scope of the project and the need for documentation. Documentation should fill a need.  The more I know about how my documentation will be used, the better I will be able to provide the right documentation.
2. I evaluate what stage the project is in. Is there a budget in place and a development team ready to start? Is there a need to evaluate off-the-shelf solutions? Do we need to start with a scope document to support a go/no-go decision on project funding? I make sure whatever my first deliverable is helps drive the next project decision forward.
3. I often hunt around in my archives of past work for something I’ve done to fill a similar need. After a few years, I’ve got a repository of everything from a 100-page requirements monster to a 1-page epic to a data feed specification to a user interface specification to a 10 page project scope document. I’ve also started building a repository of templates to use with my favorite sections, questions, and gotchas. (If you don’t have the advantage of an archive of past work, you might be interested in my Business Analyst Template Toolkit where I’ve annotated my most useful templates so you don’t have to start from scratch.)
4. If I’m approached with a new situation, I do a few internet searches to see if there are any suggested practices out there. I also pull out my favorite books for ideas. I might reach out to a few colleagues or contacts for help. As a side note, asking for help with requirements challenges is a great way to stay in touch with your professional network.
5. I create a preliminary plan of what deliverables will best serve the project. Sometimes this is a full-fledged requirements management plan. Other times it is simply a plan to get to the next decision.
6. Finally, I discuss some options with the project leadership and document consumers. I seek out their input on what would help them take the next step.

I’m probably a bit unique in that I never fully trust a template, which is why it took me so long to annotate mine and finally make them available. A template is a good starting point, but you also need to apply your own independent thinking and seek input from your stakeholders about what works for them. Every project is a little bit different and needs some special TLC.

Don’t Start From Scratch

Check out the Business Analyst Template Toolkit – my repository of editable and annotated templates you can use so you don’t have to start from scratch on your next business analyst project.

Click the link below to learn more:

http://www.bridging-the-gap.com/business-analyst-template-toolkit/

We’ll briefly talk about what the issues list is, then look at how to track issues in the list, and finally spend most of our time going through practices that ensure it’s effective at managing issues.

In a nutshell, this document or repository contains a list of all issues relating in any way to the requirements for a project.

Issues List Template

Here’s why my Issues List Template looks like:

(While you can recreate this yourself in Excel, you might like to know it’s included ready-to-go in our Business Analyst Template Toolkit.)

The point of this list is to describe the issues as succinctly as possible, identify an owner, and capture decisions to refer back to later.  Priorities should be dictated by an issue’s impact to the progress of requirements or the project as a whole.  The format doesn’t really matter.  Microsoft Excel^TM works perfectly fine.  If you have access to a web-based tool that you can easily customize to suit your needs, even better.  Just don’t make the mistake of thinking that because the issues are on the web you don’t have to manage them-you do.

How to Track Issues Using the List

There are a few basic guidelines for submitting issues to be added to the issue tracking list.

• Anyone can submit an issue.
• The BA owns the list itself, but not every issue on the list. You’ll go insane if you try to own everything and no one will pay attention to the list.
• The owner is accountable for resolving the issue.
• The entire team is made aware when an issues is resolved. This is best when it happens in a face-to-face setting, such as a regular requirements meeting. Since not everyone is involved in the resolution of an issue, often the decision one subset of the team makes impacts other aspects of the project. Often resolving one issue opens another.

How to Ensure the Issues List Results in the Effective Management of Requirements Issues

A list or tracking mechanism alone does not get your requirements issues resolved. You have to manage the list. Here are the guidelines I employ when managing an issues list.

• Putting an issue on the list does not table the issue. I have seen way to make teams say “take this offline” or “we’ll discuss that later” only to have the issue surface weeks later as a show-stopper for some aspect of the project. The issues list must be living and breathing. It’s how people interact with the project requirements.
• Don’t box your list. Issues don’t have to be just about requirements. Often a developer can’t sign off on the requirements until some aspect of the design is complete and he knows the requirements are feasible. If this is the case, by all means include the design issue in your list.
• Own the list. Add to the list and publish it often. I find that actually bringing up the list in a meeting and adding the item while everyone can see it on the projector breeds consensus around the list itself and also the description and priority and ownership of the issue.
• Capture decisions. You are failing if you allow the team to rehash old issues unless there is an extremely valid reason. Just forgetting the decision was made is not a good excuse.
• Prioritize issues based on project dependencies. You should have a plan for your requirements and know when this issue is going to keep you from moving forward. Prioritize accordingly.
• Understand every issue on the list and its potential impact. If you don’t understand it, clarify it with the team. Resolving ambiguous issues is a waste of everyone’s time.

It Seems Too Simple. Does an Issues List Really Work?

This tool is powerful because it creates accountability.  High priority issues should be looked at in every meeting…keeping these issues in the forefront of everyone’s mind ensures they get resolved.  I’ve seen issues get resolved simply because someone had a great middle-of-the-night idea, most likely spawned by that issue getting pushed into their consciousness often.  The tool also enables decisions to be made in small groups but published to larger ones and provides an avenue to get people outside the core team involved in the issue without having to involve them in the team as a whole, saving their valuable time.

This tool is part of your requirements management strategy and can often be a powerful meeting management tool. When you are conducting requirements reviews, you can’t stop to discuss every issue in detail because people begin to lose the forest for the trees.  But you also don’t want to lose important project insights.  Active management of these issues on a list like this contributes to successfully managed requirements and projects.

>>Get Your Issues List Template

My issues list template, including embedded guidelines for managing the list effectively, is included in the Business Analyst Template Toolkit. The Toolkit also includes my requirements specification templates and business analyst planning and work aids. All of the templates in the Toolkit are fully editable and annotated, giving you a great starting point for your next project. And all come with accompanying work samples so you can see what a filled in template would look like.

Click here to learn more about Business Analyst Template Toolkit