As a business analyst, you wear a lot of different hats and not everyone sees what you do. They do, however, see that big document you produced or that ticket you created. This is partly why business analysts get pinned as “that person that writes documentation.” That’s true, but it doesn’t represent the full body of work from a BA.

Related: Three steps to planning and providing value to your projects.

In reality, the BA is creating value throughout the project. You might be removing roadblocks for someone else, asking questions that no one else thought of, providing clarity (in the documentation!), or making sure everyone is aligned on an approach.

Solving problems through documentation

Some of this obviously is highlighted through the documentation, but it’s the conversations, the research, and problem solving that happens early on that leads to the documentation actually being a valuable piece of the project. For the business analyst, the challenge is making sure that the true value that you’re providing to the team is being communicated and bubbled up to the surface.

Here are three ways you can surface the true value that you’re bringing to a project.

Transparency

The key to transparency in documentation: Start with your communication.

Start with your communication. If you’re being transparent in what you’re doing and communicating that information to the rest of the team, that will ensure that the full team is aware of the issues at hand—it also helps to showcase all the items you’re working on and addressing. This doesn’t mean to list out everything you’ve done all week, but if you’re calling out potential issues or notifying the team that a known problem has been resolved, people will start to notice the value you’re creating.

Be Responsive

It’s the little things that make a difference. If your project manager or anyone else on your team is constantly waiting on you, their level of confidence starts to drop. If you turn that around, and you’re providing information before you’re being prompted for it, the team’s confidence in you starts to rise. Think about it. Someone gets asked a question on your project and their response is, “well, I’m waiting on the business analyst to get back to me.”

If that’s always the situation (and sometimes it’s a valid response), you’re being associated with a delay or a bottleneck. However, in that same situation, if the answer to the question is “the business analyst sent that over last week,” all of a sudden, you’re the person with all the answers and you’re not slowing things down, you’re actually enabling the rest of their team to keep working without any delays.

Don’t Leave Questions Unanswered/Tie Up Loose Ends

Ambiguity is the arch nemesis of a business analyst, and yet it happens.

This seems obvious. Ambiguity is the arch nemesis of a business analyst, and yet it happens. Maybe you’ve rushed through something and didn’t have time to answer all the questions you know will be asked. Maybe you made an assumption that someone else had the information. Whatever the case may be, it’s up to the BA to be the subject matter expert on the project. That might require spending a little more time doing some research. It might also require putting yourself out there to simply ask the question, “what are we doing with this?” In either scenario, you’re ensuring that you are the expert and you can answer any questions that come up.

When your next project kicks off, think about the first person that you might look at removing from a team when times are tough. “Well, we don’t need documentation”—that’s how agile works right? </sarcasm>. Then think about how you’re positing yourself on the team. If you’re viewed solely as that person that writes documentation…or worse yet, if you view yourself as the person who writes the documentation, what value are you really providing?

But if you’re shining a light on all of the items that you’re addressing, all of a sudden you’ve been positioned from the person who just writes the documentation, to the person who makes everyone else’s life easier—and that’s someone that everyone wants on their team.

So, don’t just document the project, solve problems!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments