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.

Define the Process

  1. Define the current process. Once you understand what the business is looking for, the next step is to create a flowchart showing the current process.  A good, clean process flow diagram helps you understand where information flows, where decisions are made, who makes the decisions, who does what.  It helps you visualize where they are gaps or redundancies.   It helps you see where improvements can be made.
  2. Define the new process.  This is where all of the questions that business analyst has been asking pays off.  This is where the business analyst puts what they have learned about the business into practice.  You have identified and plugged in the gaps.  You have eliminated the redundancies.  You have identified all of the changes that need to take place.  A good business analyst will think outside the box and will try to look for additional improvements that the business may not have thought of.

So how to you define the process?  I have found two ways to be very effective.  Flowcharts and Step by Step Bullet Points.

Step by Step Bullet Points

When I’m trying to define the process, I usually start with bullet points.  Why?  Because it helps me understand each of the steps that are being followed.  Quite often, especially when you are a contractor, you come into a project without a real understand of the process or what the user/group is ultimately doing.

I want to walk thru the process and understand the tasks involved so I not only get to see each of the steps that are being followed, I can start to ask or develop questions.  Every task has a purpose and I believe that it is important to understand theWho, What, Where, When, and Why for each task.  For example, I can start developing questions like Why do you do that?  What do you do with the information?  What formulas do you use?  What level of access is needed?

Tip #1:  Don’t ask too many questions at this point.  You want to understand the entire process, if you ask too many questions at this point you may not be able to get thru the entire process.  You also don’t want to overwhelm the person talking you thru the process.  Sometimes the most important questions don’t come up until you’ve digested the information.

Tip #2:  I’ve already mentioned that I like to ask Why, multiple times so I can get to the root of the problem and/or understand the process.  The second question I like to ask is “how long does it take?”  You don’t always know this and it isn’t always appropriate but if the goal of the project is to find efficiencies, then it is an important question to ask.

Flow Charts

After I get the step by step bullet points, I use Visio to start creating my process flows.  The process flows give me visual representation and help me figure out where there may be gaps or inefficiencies.  Typically, I start with drawing out the process from the notes I’ve gathered while going thru the step by step process.

There are two styles of flowcharts I use: standard and swimlane.  The first is a standard flowchart.  This is usually the flowchart I start off with.  It’s simply putting each step in order.  If the process gets complicated, or mulitple groups are involved, I will use the swimlane style.  The swimlane allows you to break the process up and visually see where there are potential hold ups.

What Makes A Good Business Analyst?

The first question you have to ask is “what is a business analyst?”  Quite simply, a business analyst is a person who works with business owners to understand and help improve the business.  Since every type of business has its own nuances, many business analysts have specialties.  For example, a financial business analyst will know specific items, such as financial formulas, that the normal business analyst does not know.  This knowledge can help the business analyst get a jump on understanding the business needs.

It’s important to know that the business or group that the business analyst is supporting does NOT always know what they want.  This is particularly true when it comes to information technology or databases.

A key requirement is the willingness to ask questions.  A good business analyst must be willing to ask the stupid question as well as the hard question.  You are working people with different levels of knowledge than you and if you are afraid of asking questions then the job isn’t for you.  You will never understand the business if you don’t ask questions.

One of the other key requirements for a good business analyst is communication.  They must know how to effectively communicate between groups who have different levels of expertise.  You must also be able to calmly and effectively communicate via different communication channels whether written or oral.

A final requirement is relationship building.  As a business analyst, you will run into all types of people. Some people will not mind answering your questions, while others will fight giving you the information you need.  It takes patience, ingenuity, and good people skills in order to be a good business analyst.

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.