Jonathan Kupersmith

Kupe Kupersmith, President, B2T Training, possesses over 14 years of experience in the business analysis profession. He has served as the lead Business Analyst and Project Manager on projects in the utility, television and sports management and marketing industries. Kupe is a Certified Business Analysis Professional (CBAP) through the IIBA. Kupe is a trained improvisational actor and performed for years in clubs around Atlanta.  He is a big believer that we can work and learn while having fun. Kupe is a connector and has a goal in life to meet everyone!

AddThis Social Bookmark Button

Business Analysis May Be the Problem

Kupe_Sept14I recently ran across this quote from Marilyn Kennedy a leadership coach, "It's better to be boldly decisive and risk being wrong than to agonize at length and be right too late."

Taking a look at her site it appears she is not speaking directly to business analysts, but I can tell you this quote should speak to you as a business analyst. When I read the quote the first thing that popped in my head was "analysis paralysis".

Often BAs struggle with determining when enough is enough.  Even with the great work many of us are doing to help improve project success and business improvements, the need for the right level of business analysis can be a tough sell. In our field, I believe the "Great Perception" is still alive...we don't need analysis, we need development.  The quote got me thinking of a reason why this perception exists.  

The problem partly stems from our name.  We are business analysts and we perform business analysis.  Is that the best name to describe what we do?  My BA colleagues everywhere and friends at the IIBA® are probably rolling their eyes...please hear me out. In my opinion the word analysis is kind of fluffy.  A Merriam-Webster definition of analysis is, "an examination of a complex, its elements, and their relations". I see why discussions continue about not needing business analysis.  Uninformed about the value of business analysis, managers and executives don't want an examination of their problem or opportunity.  They want solutions.  The definition of develop according to Merriam-Webster is "to create or produce especially by deliberate effort over time". That's what I want.  That's why development is a must. It sounds more concrete. Analysis alone is not concrete.

I suggest we describe ourselves as Business Advisors.  An advisor is someone that recommends, gives advice, and informs. My comparison is a financial advisor vs. a financial analyst. For my retirement fund I don't want a financial analyst...someone that analyzes the market and trends.  I want a financial advisor.  I want someone who will analyze my current portfolio (AS IS), work with me to define how much I need to retire (TO BE), and then recommend options to fill the gap.  Doesn't that sound like what we do?

Barring a major change like the IIBA® renaming itself to the international institute of business advisors, what can you do to change the perception? When working with team members and business partners that may not know the value of business analysis, you need make it clear that you are in the advisor or solution business. The best way to recommend solutions is to do the right level of analysis first.  This way they know why you are asking the probing questions.

In addition, this is a big reason I advocate for business analysts developing a business analysis work plan.  If you lay out what, why, when and how you will be taking on the analysis effort for a project, you now have a negotiation tool with real data to negotiate the necessary time and stakeholder involvement. Your work plan should include a:

  • stakeholder communication plan
  • list of deliverables
  • detailed task list
  • time and cost estimates for you and other stakeholders

By discussing your plan with your manager, project manager and business partners you can discuss how these activities will help develop recommended solutions that address the problem or opportunity the business is facing.

What do you think?  Are you an advisor?   

Happy Advising,
Kupe

Don't forget to leave your comments below

Comments (15)Add Comment
...
written by David Wright, September 15, 2010

I am, also known as a consultant - "One who gives expert or professional advice."

I actually had the title Systems Consultant once, as an employee.

And I agree, the Work Plan is crucial. Doing analysis is work like anything else, it takes time and resources, so it has to be planned like any other work.
...
written by Kupe Kupersmith, September 15, 2010
Consultant is correct too. I was trying to keep the "A".
...
written by Leslie Shearer, September 15, 2010
While we refer to a Business Analyst "role" at my organization, the title is "Solution Analyst" which I prefer. I believe there is truly a distinction between the two functions. In my mind Business Analysts are in place to be engrained in the business for the purpose of understanding and defining the root causes of business problems/frustrations as well as the business cases for new things that want to be done. Separate from that Solutions Analysts are in place to gather information from BAs and craft solutions design to solve the problems and meet the business case objectives. Both roles are covered within the art of Business Analysis and the scope of the BABOK, but individuals are often suited to play one role over another and organizations would do well to clearly delineate between the two different kinds of work.

On your topic of work plans, we are in the process of doing just that. It is considered a Requirements Gathering Approach document and challenges the BA to document the techniques that will be used in order to elicit requirements, the specific stakeholders they need to interact with in order to elect requirements, and the amount of time that it will take to elicit the requirements. Other peripheral information is also covered such as known dependencies, constraints, etc. Some groups are piloting the form now and I'm curious to see the impact it I'll have in building credibility and awareness within the organization.
...
written by Kristofer Lundin, September 16, 2010
That's a great idea!

The word "analyst", highlights on one of several "BA" tasks, and it will not energise managers and executives.

They want RESULT and they might even have IDEAs of how to achieve it.

Even though they surely know that to achieve a result you will need to bring the ideas in to more details before recommending one, they are not interested to constantly be reminded of HOW you do this.

They will surely be more confident to pay an Advisor providing basis for desicion enabling the result to be achieved one way or another.

...
written by Kupe Kupersmith, September 16, 2010
@leslieshearer - Thank you for your comment. It seems like your org has two roles for what many companies have combined in one. I like the solution analyst name! Keep us posted on the success of the Requirements Gathering Approach.


@kristofer... Totally agree that the analysis is part of what we do. I believe the perception is that is all or most of what we do. Thanks for sharing your thoughts!
...
written by John Foft, September 16, 2010
Kupe, I agree, but I think it's important that the "analysis" function come before the "advisor" function (I suspect that Leslie's company morphed to their current state specifically to arrange the two functions). It's important not to craft a solution before fully analyzing current state and identifying desired future states.
...
written by Kupe Kupersmith, September 16, 2010
@jguy69, I agree analysis comes first. But we do analysis for a result...a solution. BAs need to make sure all stakeholders understand the reason we are doing the analysis.
...
written by Kupe Kupersmith, September 16, 2010
All, I just found another quote that I wanted to share. This is similar to Marylin's.

"I have always found that if I move with 75% or more of the facts, I usually never regret it. It's the guys who wait to have everything perfect that drive you crazy."
-- Lee Iacocca, executive
...
written by Jorge Henriques, September 16, 2010
I completely agree with this. We are, in a sense, developers. After we do our analysis, we have a system that solves the problem, albeit defined in a "pseudocode" mix of the English language and other supporting documents.

That Lee Iacocca quote reminds me of the OODA loop concept by John Boyd - Observe, Orient, Decide, Act. This concept can be applied to any decision processes, but was defined by Boyd as a result of his experiences as a fighter pilot. His key insight into it is to get "inside" your opponent's OODA loop. The application to business processes means to do proper analysis (Observe, Orient), define the solution (Decide), and then produce your product (Act) but to do it quicker than competitors, or in a manner that you can predict customer needs and be ready for them.
A lot of people think Business Analysts are involved in just the first two stages - or even worse, some think it's just about documenting what others decided. We have to show that our biggest impact is in that we are key to 1) Making the Observe, Orient stages go quicker, & 2) Defining the proper solution that will enable success -- the one that minimizes the risk of being wrong.
...
written by Kupe Kupersmith, September 16, 2010
I love OODA. Thanks or sharing.
...
written by David Wright, September 16, 2010
Ah, the "A" in BA, I see it. Of course, I always thought the best title was Requirements Analyst, but people would would say "but we do more than requirements!" Maybe so, but if you don't do the Requirements part, the rest isn't worth doing. However, I have given up on that being a widely accepted title, but many companies I work with are looking at it internally to clarify what they expect from the role, define skills and training and so on.

I do get a little ansty about the BA as the "decider" of the solution. Many, many factors come into play once you consider a solution: there could be many to choose from; the technology standards of the shop could limit things; do you bleed, lead or follow; budget and time available; and so on. Once all those factors come into play, you may not have much choice; but if you do, then you can at least use requirements to evaluate which solutions still on the mat meets them best.
...
written by Faras, September 19, 2010
business advisor would be applicable to senior BAs, rather than all. I would say if you define and prioritize activities which are commonly sought after in a BA, requirement analysis would be one of the primary ones.
...
written by Doug Goldberg, September 20, 2010
Great perspective Kupe. The ongoing issue of defining how our role provides value to the organization is well captured here in your comments. If one wants to understand what we do, I suspect that just the word analyze leads some to envision a never-ending activity that doesn't have a solid value point to define, much less a clearly understood point. I actually like your idea of Advisor as our new name; it captures much better the essence of what we do. To David Wright's point about requirements being at the core, I'd agree with that. However, we do requirements for a reason, and that reason is to fulfill a solution that we are advising the stakeholder to employ. I don't see us either as being the decider of really anything. I've not been on a project yet where the BA is working alone in crafting a solution, though it often times feels like we are doing everything no one else wants to do.

Thanks again

Doug
...
written by Kupe Kupersmith, September 20, 2010
Thanks for jumping in Doug. On a LinkedIn group a discussion was started around this post and the point you raised about us being the decider came up. I agree with you that we are not the ones making the decision. But we work with the team to come up with solution options.
...
written by Holly Martin, October 05, 2010
Love it, Kupe! Why do I think you're reading my mind all the time???

"Advisor" is definitely more how I see myself than as an "analyst". I definitely analyze stuff, and love doing it, but I do it with the intent to provide some kind of recommendation. To provide advice to my internal customers on how to approach a problem (and whether it actually is a problem worth solving).

@leslieshearer - I like your suggestion for "Solution Analyst" as a title. My only concern with this is half the time the context of what I provide is not a solution. I joke with people that I'm really the "Project Killer", but in a freaky way it kind of makse sense. I will sometimes provide a recommendation that there isn't an IT solution for a problem.

I many cases I may recommend changes to business process or further training & communication to address an issue, but if my stakeholders walk away from a discussion with me wtthout an "IT solution" they will think I didn't provide them with a solution. It's like going to the doctor and he/she tells you "there isn't a magic pill for this, what you need to do is make some lifestyle changes". Ha! When that happens do you walk out of the doctor's office thinking that visit was worth your $20 copay? Probably not. But actually the doctor is doing you a favor. Throwing more medications into the mix may not address the underlying problem. Perhaps I should start advising my customers that "lifestyle changes" are what's required. I'll experiement and see how that flies.

Write comment
We love to see comments! However, please do not market or sell any products. Your comment will be removed immediately!
smaller | bigger

busy