Learn the Vocabulary

I think this is one of the most critical things a business analyst needs to do.  As I’ve mentioned before, a business analyst is more than someone who writes requirements or runs meetings.  They are also interpreters and trainers and this is where the vocabulary comes in.  For example, a short sale means something different to a real estate agent than it does to a stock trader.

Your clients are very busy and they are not going to have the time to have you always answer your questions.  There is always a learning curve and you may never know everything but the more and sooner you learn how the processes and vocabulary the more valuable you will be.

So how to you learn the vocabulary.  I do the following:

  1. Make a cheat sheet.  Whenever I start with a project, I create an Excel document and start putting definitions and acronyms as I come across them in it.  That way I can update it as necessary and refer to it when needed.   I use an Excel document because it’s easy to sort and keep everything in alphabetical order.
  2. Ask the client if there are any good websites to go to for reference information.  For example, when working with traders I have found Investopedia to be a good resource.
  3. Training materials.  Go through the training materials that the clients go through.  That will help you understand what the clients sees and understand the issues that they experience.  I also create my own step by step guide so that I know exactly what I should be seeing each step of the way.  Note:  If you are working with calculations or numbers, ask the client for some valid numbers (and some invalid ones).  This will give you some quick reference material when you need to do testing.


Business Analyst Knowledge and Experience

A reader recently asked me the following question: “In your opinion does a Business Analyst need High Level IT experience? or general data analytical skills in addition to business knowledge”  That’s an interesting question, I’ve mentioned before that I think one of the roles of a business analyst is as an interpreter.  I think a lot of companies struggle with that question too.  I’ve been on a number of projects where there was already a business analyst on the project and I was assigned as the IT business analyst.

So what level of IT experience should the business analyst have?  My opinion is that the business analyst normally DOES NOT have to have a high level of IT experience BUT it does depend on the project.  It really depends on a number of things such as the type of project, the time frame of the project, or even the relationship with the development teams.  The fundamentals don’t change.  You still need to ask the Who, What, Where, When, How, and Why.  The business analyst needs to understand what the business wants.  The difference is that now the BA has to translate it what the business wants into what the developer can understand.

How do you do that?  This is where experience, not specifically IT experience, but overall experience comes in.  You have to know how to drill down and ask the appropriate questions.  That means asking for more details surrounding the process and requirements.  The more details you have the easier it will be to tell the IT teams what you want.  They can then tell you, the business analyst, what additional information they need.

That being said, I think there are times when it is important to have an IT and/or Database business analyst.  There is a level of expertise that will be required that a regular business analyst wouldn’t necessarily know.  When this occurs, I think the business analyst becomes more of a subject matter expert for the team, while the IT and/or Database analyst can ask more specific information so they can have a more complete picture of what is needed.  Eventually, you learn the questions and type of information that you need, but that only comes from experience.


I’m going to go a little off topic today to talk about the MBA.  I’m talking about that because today I will be graduating with my MBA from Elon University.

So what has going after an MBA done for me?  A number of things.

  1. It gave me a challenge, a goal to attain.  Getting the MBA isn’t easy.  It’s running though an educational gauntlet.  While your job or life experiences may make some classes easier than others, there are always a couple of classes that drive you crazy.
    • For me, Economics and Managerial Accounting were the big challenges.  Economics because the professor focused more on calculus than economics, and let’s face it, not many people use calculus on a daily basis and I barely passed that when getting my undergraduate degree.  Managerial Accounting was tough, well because its managerial accounting.
    • The classes that were easier for me were the communication and strategic thinking.  I think that is because of my experience as a business analyst.  I communicate everyday and sometimes have to think outside the box.
  2. It helped to think differently.  You broaden your thought process.  If you’ve read any of my previous posts, you know that I advocate asking the Who, What, Where, When, How and Why questions.  While pursuing the MBA, I not only learned the value of these questions, I learned about tools to help me expand on them.  For example, using tools like the Business Model Canvas and Porter’s Five Forces, when I look at a problem I know to ask more than just who.  I now ask Who are the Key Stakeholders, Who are the Clients, and Who is the Competition?
  3. It broadened my personal horizons.  I don’t know what I am going to do with this MBA.  I may use it as a stepping stone to another career such as teaching or corporate training, use it to ride the corporate ladder, or even try something totally different.  The MBA has given me the tools to succeed, I just have to find the path I want to follow.
  4. Finally, it gave me a permanent, double shot of confidence.  A lot has happened since I started the MBA program.  I lost my father, had a knee replacement, sold my family home, and got married.  There were a lot of challenges along the way to complete this and knowing that I drove myself through to the finish line gave me the confidence to go forward.


Today I want to talk about drive.  What does drive have to do with a business analyst?  Everything.   It’s ultimately what makes the difference between a successful business analyst and an ordinary one.

The first thing we have to do is define what drive is.  I believe that drive is that hidden motivator that makes us keep things moving when things aren’t going smoothly.  It’s what makes us do what it takes to get the job done.

So how does drive help a business analyst?  Many times, the business analyst does more than gather requirements or provide expertise.  The business analyst often has to play other roles such as project manager or quality assurance tester.  All projects have timelines.  All projects have to have a leader.  Most projects have delays or hiccups.  It’s often the business analyst that keeps things moving.

So how does that happen?  Well, like the old saying goes “when the going gets tough, the tough get going.”  The great business analyst, in addition to continuing to ask questions and learn what is needed by the business, begins to work on a project plan, continues creating the requirements documentation, starts working on test plans or test scripts, organizing test data, etc…

Just because a project has slowed down or stalled, doesn’t mean you should forget about.  I’ve seen too many projects get stalled only to rise up again with an even more accelerated time frame.  When that happens, the information that you created will be invaluable and will make you look like a genius.


The Business Analyst…An Under-Utilized Asset?

Today, I want to talk about expanding the role of the business analyst.  I believe that the many under-estimate or under-utilize the business analyst.  It often seems that many people think of the business analyst as the person who writes business requirements or user stories, asks tons of questions, and helps with testing for specific projects, which have a short time frame or multiple phases.  The business analyst isn’t brought in to look at long term solutions and ideas.  The business analyst isn’t usually involved in the strategic planning, they are usually told “here is what we want to do…go forth and conquer….by the way we want it yesterday.”  Why is that?  I think it is because the value of the business analyst is under-estimated and under-valued.

As I’ve discussed previously, one of the key duties is to ask questions and identify the who, what, where, when, how, and why.  Two key tools taught in MBA classes are the Business Model Canvas and Porter’s Five Forces.  I will talk about these items more specifically at a later date, but just to give a brief heads up as to what they are.

The BMC looks at the customer segments, value propositions, key partners, key activities, customer relationships, channels, cost structure, and revenue streams.  See a familiar trend here?  It looks a lot like Who, What, Where, When, How, and Why.  It’s just broadened a bit.

For example, you ask yourself:  Who are our key partners?  What are our revenue streams?  What costs are most expensive?  How can we improve those costs?

Porter’s Five Forces does something similar.  Porter asks about rivalry, buyer power, supplier power, threat of substitutions, and threat of new entrants.   Again, you are looking at a problem and breaking it down into the Who, What, Where, When, How, and Why but from a slightly different perspective.

For example, when thinking about the Threat of New Entrants, you can have the following questions:  Who are the potential competitors?  Why would they enter the market?  How would they enter the market?  What in their incentive?  When would they enter the market>

When you think about it, it all comes down to the fundamentals doesn’t it?  It’s just the type of questions that need to be asked.  The business analyst is using these skills each and everyday for every project.  But it goes further than that.  If you have a good business analyst, they have already established relationships with the groups that would be involved.  They have a good understanding of what the current processes are and where the gaps are, or where improvements can be made.  The business analyst is your connection to your “boots on the ground” and should be a natural addition to any strategic meeting.

I’m going to leave with one final thought for today.  Do you utilize your business analyst to their full value?

What Makes One BA Better Than Another?

What makes one BA better than the other?  What really makes any of us better than the other?  I think it comes down to a two things:  Experience and personality.

  • Experience.   Experience is invaluable and covers a lot of ground and I would like talk a bit about a number of key drivers.
    • Organizational experience.  You know the people/groups you need to bring in on a project.  You know what groups may provide roadblocks to your project and the best ways to communicate/work with them.  These are things you learn from working in past projects within the company.  These are things that a good BA can easily learn and prepare for by asking other BAs in the company, their manager, or other contacts on the project team.
    • Event experience.  This is when or when problems have occurred in the past and how were they dealt with.  You also know what people or groups who are likely to be slow in responding to emails or giving sign offs or asking for last minute changes.  These are highly frustrating things but experience teaches the BA what to expect and how to deal with it.
    • Vocabulary.  A lot of times the client doesn’t know exactly what they what or how they want something to work and sometimes the client knows just enough to be dangerous.  The BA becomes an interpreter between the business and the IT teams.

      I’ve found that the best way to solve this is to create a data dictionary.  When I work in a Waterfall methodology, I put a glossary at the beginning of the document I’m working on, whether it is a project charter, business requirements document, High level document, or Low level document.  I also include any acronyms that may be used.

      When working in Agile, I typically do two things.  First, I create a spreadsheet with all of the definitions and acronyms and keep it where I can link to it when necessary.  Second, when I write the user story I try to put either the definition in the story or link to the data dictionary.  The type of story, the application we are creating the user story in, and the agreed procedures usually dictates how I do this.  One thing I have noticed about Agile is that EVERY group does Agile a bit differently.

  • Personality.  I think personality is a given, really, with anything you do.  People feed off of the people that they work with and when they work with someone who is confident, trusted, and well-liked, then you are more likely to have success.  Let’s face it, no one wants to work with someone who is always miserable, cranky, argumentative, or untrustworthy.  It makes for really long meetings.

When you are a BA, you have to manage ALL of those people, you CANNOT be one of those people.  Everyone has a bad day.  Everyone has days that they don’t want to be on the meetings.  I believe that the BAs personality drives the project.  Another key thing to remember is that the BA NEEDS input and help from all groups.  You don’t get a lot of help when people don’t like you.


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.