What is a business analyst?

In order to be a good business analyst, you first have to understand what a business analyst is. A good business analyst is a listener, a negotiator, an interpreter, a tester, a project manager, and at times a baby sitter. In other words, a business analyst is a jack of all trades.

Listening: Listening is the key fundamental function of a business analyst. It doesn’t matter how well you write or how well you do anything else, if you don’t listen to what the client is telling you they want then you will not be a good business analyst. This is so important because, quite often, the client either does not know what they want…or they know just enough to be dangerous. If you don’t listen to what the client is telling you, then it is very possible that you will either give them something that doesn’t work or doesn’t want. This is especially true when you are working with databases or technology.

For example, I once had a client that wanted an Excel spreadsheet with a bunch of information. I asked the “why” question and their response was that they needed to import that data into another spreadsheet so they could do the calculations. After learning more about their processes, I was able to tell them that not only could we give them the information they wanted, we could provide the calculation results as well. By asking the who, what, where, when, how, and why questions and listening to what they were saying, I was able to save them a lot of time and effort.

Negotiation: Being able to effectively negotiate is a vital asset for a business analyst. There are project deadlines to meet, documentation to write, sign offs to get, etc…and the business analyst is involved in all areas of the project. After almost every meeting, you will have to-do items and people are going to want to know when they can expect them. You have to know yourself and give people realistic timelines on when you can have your deliverables ready. You also have to be able to hold other people accountable for their items. There are times when deadlines are unrealistic and you have to stand up and defend yourself as why you need more time.

For example, I was once on a project where the upper management wanted our group to change over to a new programming language. We were given three months to do it. Our development team said it wasn’t long enough but the management team wouldn’t accept that. I created a project plan that showed how long it would test each item we needed to provide and allotting only one minute per test. The project plan said it would take almost a year. Six months if we did hired someone. After I showed that to upper management, they gave us more time and allotted more funds.

As people gain trust in you, and your abilities, they will more readily accept what you say. But ALWAYS be ready to back up, or prove, what you need.

Interpreter: I love this one. This is particularly true when you are working as an IT or Database business analyst. It is your job to take what the client wants and communicate that to what the development or database people understand. You are going to be working with groups who have different vocabularies and do not understand what the other is saying. You have to bridge that gap. You have to be able to effectively break things down into its simplest form.

For example, an investment banker may want to a webpage that shows the rate of return for a set of stocks. The development team will, most likely, not have any idea what that is or how to calculate it. The business analyst will need to give explain what it is and how to calculate it.

Tester: Yep, you get to test too! 🙂 You wrote the requirements, who better to test than you? There is a point, after all the requirement have been signed off on, when you are out of the loop. That point of time is when the development team is writing their code. You are hoping the development team has completely understood your documentation. During that time frame, you want to be writing your test scripts so that you can verify what was done. Before you let the client see the product, you will want to ensure that they customer is getting what they asked for.

Project Manager: A lot of projects will have a project manager assigned to it, but not all of them. Usually, only the projects with the highest exposure or risk get a dedicated project manager. However, the same fundamentals apply and guess who often gets to keep the project on track and provide the status reports? That’s right the business analyst. When you have smaller projects, its not a big deal but it is an extra layer of responsibility you have to prepare for.

Baby Sitter: No, I’m not joking. Because the business analyst plays such a central role in the project, you hear from everyone. The business doesn’t like something, the testing team keeps finding bugs, the development team saying that the testing team is testing something they aren’t supposed to, sometimes will complain that they need more time….it goes on and on. Sometimes you just need to be a sounding board, sometimes you have to handle the situation, and sometimes you need to pass it onto someone else. But because you are involved with each of the groups, you will hear it and have to work with it.

Business analysis is a great job. You learn a lot about people, the business you support, and make a lot of great friends and relationships but it is NOT an easy job. There is a lot more involved in being a great business analyst but if you follow these steps you will be well on your way.