How to Avoid These 5 Business Analyst Mistakes!

Many business analysts are perfectionists by nature and want to do everything they can to avoid making mistakes. But it’s not uncommon for our perfectionism to actually be the root cause of the challenges we face!

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.