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.

Relationship Building

Relationships are another key to the successful business analyst.  It is important to establish trust with the partners you work with (ie: QA team, co-workers, project managers, developers, etc…), the client(s) you are working for, and the management team that you are working with.  Quite often, especially if you are working as a contractor, you will walk into a project blind.  Meaning you aren’t going to know the details of the project, the timeline, or the process.

Trust is vital to establishing a good relationship.  The trick is how to do that.  Here are some things I have done to try to establish trust.

  1. Learn as much as possible as quickly as possible.  That may seem obvious but here me out.  No one expects a business analyst to come in right away knowing everything, even the most experienced business analyst has knowledge gaps.  But when the other team members know that you are learning, asking good, solid questions, it builds trust and they will be willing to help you.
  2. Show respect.  This should go without saying but it is so true.  I have yet to be on a project where everyone agreed on everything.  We all have different viewpoints, ideas, and personalities.  How you treat everyone goes a long way toward forming others opinions about you.  A business analyst can’t do his job well without the help of others.  If you are bossy, irritable, untrustworthy, or don’t show people respect you are not going to get the help you need.  Always remember the golden rule, “do unto others as you would have them do unto you.  If you don’t show people respect, you can’t expect them to show you respect.
  3. Be willing to help and follow thru.  This is all about being a team player.  This is a character trait and you are either good at it or not.  There is a lot of “all about me” in the world, but when you are willing to help someone, do it, and do it well, it says a lot about you and it gets noticed.

    For example, at one job I would often get into work around 7am.  Our development team in India would be ready to go home about that time.  They knew that I would come in early and would often ask me to test something for them so they could go home.  Doing these tests wasn’t part of my job, sometimes it wasn’t even my project, but I did it because it helped the team.  This helped build a level of trust with the development team, the QA team, and when I would need some help they were willing to help me.

    There is an old adage, “what goes around comes around”.  This is so true in the business world.  A good business analyst is always aware of this.

  4. When there is a problem, work the problem.  Don’t panic.  Stuff happens.  It never fails.  How you react to the problem and how you work the problem says a lot about you.  If you scream, cuss, and blame people, then you are creating more problems.   Just focus on the problem and then worry about the repercussions later.
  5. Take the blame when you are at fault.  This may seem obvious but take responsibility when you screw up or you think you screwed up.  If you do this, then people are more willing to help you dig out of the hole than if you were to go around accusing others.  A sure way of getting yourself fired is to try to cover up a mistake or put it off on someone else.  Sometimes it is tempting but it’s never a good idea.

Understanding the Business

When trying to understand the business, and the business needs, it is the responsibility of the business analyst to make the business think about what they want and, when necessary, pull the information out of them.  Quite often, the business does NOT always know what they want or need, what is truly involved, or completely thought the whole issue through.  They may know that there is a gap but they need help identifying where and what exactly is needed.

The number one thing to do is ask questions.  I’ve found that the key questions to ask are Who, What, Where, When, How, and Why.  When preparing for your first meeting with the business, I have found it best to look to clarify each of these questions as completely as possible.  You may not ask each of these questions in the order that I have them and you may (will) go back and forth between these questions time and time again.

To help put things into perspective, the questions below are questions I would ask if a group said they needed to gather some specific information.

  1. Who? It’s important to understand who the key stakeholders are and who the users are.  Who has the information you need?  Who will use the information gathered?
  2. What? What does the business do on a regular basis?  What does the business want to accomplish with the information?  What are the timelines?  What is done with the information?
  3. Where? Where does the information need to go?  Where is the need for the information?  Where is the project going to take place?
  4. When? When does the project need to be completed?  When does the information need to be received?  Is there a specific time each day?  Each week?
  5. How? How does the group need to receive the information?  How will the   information be handled?  How will the information be protected if it has private information?
  6. Why?  This question is the kicker.  This is the question that makes a great business analyst.  It is the annoying question, especially when you ask it multiple times.  But it is the question that helps you find the root of the problem or need.  It helps you understand what is really going on.  The question “Why?” makes everyone think.  It gets you past the “well, that’s how we’ve always done it” answer.  As you start asking the Why question, people start asking “do we need this step?”  “is there something missing?”  “can we do it better?”

These are the fundamental questions any good business analyst needs to be willing to ask.  The willingness to ask these questions makes the difference between a great BA and a mediocre BA.