How to Structure a Business Analyst Team

This question came to us from our Facebook page. When you have multiple projects and multiple business analysts, how do you structure your team and work assignments?

Like so much in BA, it depends. The best answer to this question has to come in the context of your organization – what projects are you working on? How big are those projects? And what are the skill sets of your business analysts?

In this video, I talk through the pros and cons of the various options and give you some important tips for structuring your business analyst team.

 

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 a question that came to us from our Facebook community. That is:

“How do you structure a business analyst team? If I have multiple business analysts, should I be putting them all on each project in different roles or different stages of the process, or should I be giving them each their own project?”

Of course, like everything in business analysis, it depends, and it depends on a lot of factors. There are a few options to consider, and I’m going to talk about the pros and the cons of each.

Business Analyst Team Option #1 – Splitting Roles Among Projects

The first option for structuring your team is to split roles among projects, meaning that each business analyst has their own project or often their own set of projects that they’re responsible for when they’re filling the entirety of the business analyst role on that project. This is a good option if you have a strong team, people with similar capabilities. A mid-to-senior level business analyst, they want their own project.

This is part of the independent fulfilling work that drives us as business analysts, is that ability to own the project, own the requirements for the project, negotiate with the stakeholders for that project. See that through to completion. It’s a good sense of ownership to have if you have a team of strong, capable, business analysts that works well.

It’s also a good thing to be thinking about if you do have more junior business analysts to be creating a path to bring them up. Maybe they’re shadowing and supporting a little bit at first, and then they’re eventually transitioning into their own projects as well. But that’s not the only way to do it.

Business Analyst Team Option #2 – Splitting Roles Between by Stage of Analysis

Some teams also split the roles by stage of analysis. There are a couple of different ways this can happen.

One could be that you have a more business-focused business analyst, and a more technical focused analyst. Sometimes that’s the business analyst and the systems analyst. Those job titles are used inconsistently. Don’t go looking for those job titles as a sign of what type of role you necessarily have.

In that, the split works well in complex environments. If you have a complex set of business stakeholders and that business-focused analyst is figuring out how to process flows through multiple departments and working with, perhaps, dozens of stakeholders to figure that out and negotiate those business needs. And then if that system is complex as well, and so the systems analyst knows how all the systems work together to achieve that business process, and how to specify the different changes that need to happen to all the different systems to make a project happen. Having somebody focus on the business side and focus on the tech side can make a lot of sense when there is complexity on both sides.

Other times we’ll see the split happen more from a stage level. A more senior business analyst might be responsible for a whole collection of projects that, and they’re doing that initial business needs and scoping work and putting a high-level plan together. The more junior business analysts are defining all those detailed requirements within the scope of that plan. That senior level business analyst will still be involved in all those projects throughout, but not in all the details, and the more junior level business analysts would be fleshing all that out.

Now, junior level is relative there because, on a bigger complex project, there’s still a lot of responsibility and analysis work to do and things like that. So, that’s not necessarily just like an entry level, junior level role, but a way that you might see business analyst partner when there are varying skill levels in your organization.

It also creates a path for that more junior level analyst to get involved in the early parts of the projects as well.

Business Analyst Team Tip: Look for collaboration opportunities

No matter how you structure your team, I just wanted to share a few tips for collaboration because it can start to feel like there are walls. Like, “Hey, I’m a senior BA. I only work here. I don’t do these things here.” Or, “Hey, I’m the business process BA. I don’t do the tech stuff.” You want to avoid creating walls. As business analysts, we bridge gaps in communication. We create collaboration. We don’t want to put up walls between ourselves and our own roles. What are some of the ways that you can make sure that your business analysts are collaborating?

Sitting in on meetings is one, cross-training each other, maybe the technical business analysts have. So, much to learn as you train about new systems and the business, focused business analysts talk about the business processes in the department. In the context of a project, there’s got to be a lot of that happening, but it can also happen more globally as well.

Peer reviews. So, doing reviews of each other’s documentation. Even sitting in on each other’s meeting and assisting with meeting notes. The technical BA could take meeting notes while the business BA is facilitating the session, and then the business BA could take meeting notes while the technical BAs are facilitating their sessions. There’s some cross collaboration there. It’s an area of mutual respect and support. That can work, as well, if your BAs are all similarly leveled and have their own projects.

Also, look for opportunities. One of the first things I did in my first business analyst role is I created a peer review meeting. There were just four of us. It wasn’t a huge meeting, but we were all on different projects. We had no visibility into what each other was doing. Every other week we would meet, and we would review a couple of documents for each other. Not everybody had each something reviewed every week, but we would review some documents and give each other feedback. It was a great way to get consistent about how we did things as a business analyst team. We’d see variances. “Oh, I don’t put things like that in a use case. I do it this way.” We would discuss what we thought was better and agree on a go forward approach.

You’d also start to learn about the other projects that were happening in your organization. We could start to see overlaps in terms of the actual functionality and the business needs that were being addressed as well. That just made us all more aware and stronger business analysts, and able to start to contribute a little bit more strategically in the organization as well.

Always be looking for those ways to get your business analysts collaborating regardless of how their roles are defined in making sure that they don’t end up in their own silos and own boxes. That’s the exact opposite of what we want to do as business analysts.

How Do You Structure Your Business Analyst Team?

I would love to hear how you structure your business analyst team. Do the skills that people have play a big factor? Do the types of projects you’re working on play a big factor? What was the factor that drove that organization, or is it just sort of what evolved? Maybe this is a good time to re-evaluate and think about what would be best for the environment that your organization is in right now.

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

Thanks for watching.