Think Thru The Problem

I’ve been doing some thinking over the past few days about the phrase “Think outside the box.”  What does that really mean?  Is that a buzz phrase or do people actually understand what that means?  I believe that it is buzz phrase and when people say that they are really saying that they want to think in a different way.  That means, slow down, look at the big picture, and look for the not so obvious answer.  The problem is that many people want to find the easy answer, the easy answer is seldom the correct answer

In this month’s Harvard Business Review is an article called Linear Thinking In A Non-Linear World”, in the article talks about slowing down and thinking things through.  There is a great question in the article “Which scenario do you consume more pizza?  A 12 inch pizza or two 8 inch pizzas.  The obvious answer is two 8 inch pizzas, but that is wrong.  The area of a circle is π(r2) that means that the correct answer is the 12 inch pizza.   (Harvard Business Review, May-June 2017, p 131-139)

There are alternative ways to look at every item.  A lot of it comes from your background, your experiences, and your perspectives.   So how do you get to the alternative answers?  Think thru the problem.  Ask questions, research the problem, find the viable alternatives.  The more questions that you ask, the clearer things appear or the more alternatives can find.  In looking at the HBR problem, most people don’t remember the formula for the area of a circle so you can figure that out but by asking questions or doing a little reasearch, you can find the problem.

The next time you come across a problem, don’t jump to an immediate conclusion.  Stop, think thru the problem, ask questions, research, and then come up with the right answer.

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.

MBA

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.

Drive

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.