Skip to main content

5 Things I Wish I’d Known When I Started as A Business Analyst

I found myself in a reflective mood this weekend – driving from Iowa to Arkansas and back again to deliver a horse tends to do that.

One of the things I reflected on was the lessons I learned in my career and how knowing them would have been helpful when I started as a business analyst. Here are five things that I would tell my 1998 self, assuming I would listen.

Your Job Is Not to Elicit and Document Requirements

Yes, business analysts elicit and document requirements, but those activities are a means to an end. Analysis is about understanding your stakeholders and their needs, identifying the best solution for satisfying those needs in your particular context, and then building a shared understanding of that solution. Requirements play a part in that work, especially around describing the need, but they are certainly not the end product.

Related Article: 10 Characteristics of an Awesome Business Analyst

When the teams I worked with thought that the BA’s sole responsibility was requirements, my role was diminished and I lost the ability to make sure the project was delivering the right thing. On the contrary, when I stepped up and sought to understand why the project existed in the first place and then made sure everyone on the team had the same understanding of why, the project tended to go better, I enjoyed my work a lot more, and found I had much more influence on that project and in the organization.

Projects Tend to be Described in Terms of Solutions

The common advice repeated so much it’s almost become a cliché is that you must understand the need you are trying to satisfy first, then identify the solution that best satisfies that need. Yet, most projects are still initially described in terms of a solution, such as “Redesign the cover sheet for the TPS Report.” Why? Because it’s easier for people who are facing a problem to voice how they will solve it rather than to reflect a bit and describe the problem they are trying to solve. (This is where I resist the temptation to reference an overused Henry Ford quote about faster horses).

If you want to be effective at business analysis, learn how to drive to the real need in a way that makes your stakeholders eternally grateful that you came along. Your stakeholders are certainly experts in some things, but they may lack expertise in the capabilities of technology. They fall back on solutions they have seen in other contexts that may not apply to their current need. Bringing in other perspectives (i.e. the delivery team) can provide several other options for addressing the need in more effective ways.

Just Because You Can Satisfy a Need, Doesn’t Mean you Should

Sometimes when you uncover the real need, you realize that it could be satisfied, but that it doesn’t make sense to do so. Either the viable solutions cost more to implement than would be realized from satisfying the need, or the need is not that wide spread and your team’s time is better spent on other things.

A dysfunction I have seen is that organizations do not know how to determine constructively what they will – and more importantly will not – work on. This is apparent in the organization’s project portfolio which contains more things than the organization has the capacity to do within the identified timeframe.

This is a problem that stretches all the way up to the decision makers in the organization, but business analysts have a part to play in this. Although you as a business analyst may not make decisions about what projects get done or not, you certainly can influence those decisions, and even make sure they happen, by asking probing questions and driving to understand the real reason for projects. It’s not easy, but it’s better to raise the questions and drive some influence rather than keeping silent and not having any impact.

Learn as Many Techniques As You Can

There are several different techniques that are helpful for business analysts and BA Times is chock full of articles about how to do them better. With so many techniques available, it’s very helpful to be aware of as many techniques as possible and to really understand why you use them and when they are most helpful. There are enough great resources out there that you can pick that up when you need to actually use the technique. I’d much rather have a broad understanding of a wide range of techniques and when they are applicable then to be an expert in a few techniques. I find I’m much more flexible in my response to different situations and more useful on the projects on which I work.

People Don’t Want You On the Team Just Because You Are A BA

Throughout my career, I’ve had the opportunity to work in several different organizations on many different projects. When I started at a new organization, I was on a project because that project needed a business analyst. After that, I worked on future projects because of what I did and how I did it which included, but was not limited to, business analysis. Those experiences led me to the conclusion that while all projects need business analysis, not every project needs a business analyst.

I don’t think that rules requiring every project to have a business analyst help. Projects require a different amount of analysis. Let the business analysts work on those complicated projects that require a little of analysis, and coach people on the projects that are more straight forward.

Conclusion

There’s a lot more baked into these lessons that I didn’t have room to share here. In my subsequent posts, I’ll dive into more detail into each of these lessons and share a bit more about how you can apply each of these lessons learned. I’d also be interested in hearing what lessons you have learned, and if your experiences have been different than what I’ve described above.