Explaining Business Analysis to Laypersons, Including Ourselves

It is time to start explaining BA to everyone, not just to each other and a few PMs (ironically, unless you are a BA, or a few PMs, this is inside writing and may not make sense to non-BAs, or most PMs). It has occurred to me that BA is new enough that we are ALL laypersons, learning to explain a newly defined (even if it is the eighth oldest) profession (after gathering, hunting, theft, sex, cooking, preaching and counting came “figuring out what other people should do” – also known as kibitzing.)

When Einstein released his theory of general relativity, Sir Arthur Eddington (a great physicist and explainer who wrote a number of articles which announced and explained Einstein’s theory of general relativity to the English-speaking world) was told that there 3 people in the world who were able to understand it. His response was to ask who the third person was (Wikipedia).

Can you explain BA? What is BA? The BABOK tries to make it easy – BA is the 32 tasks, performed using techniques included (but not limited to) chapter 9, with personal skills listed in chapter 8. Makes sense to me, who has studied and taught BABOK for years.

Unfortunately, the BABOK is BAs explaining BA to BAs. Like my blog, only way better. The BABOK (sort of)* characterizes solution approach as “change your business (resources, policy, procedures) and/or your technology use (Implement Existing vs. Build vs. Buy). This doesn’t help me with stakeholders, who have already decided what they are going to implement, build and/or buy, based on some golf course tip, or a personal preference for IBM, or maybe even just looks over capabilities (remember OS/2?)  

If you disagree, please explain the difference between solution approach and solution scope**, and explain why so many IT professionals laugh when I say “Fire, Aim, Ready” without further explanation (next time you see a stressed IT PM, try it and see if it gives any relief).

AND, WHAT is the difference between solution scope and solution requirements? If you think this distinction doesn’t matter, then you have not experienced the “rush to solution”. If you have experienced the “rush to solution”, you might want to think about how to explain the distinction. Not to me, to laypersons.

Bonus question- when does it matter? Is it OK to “rush to a solution” and if so when? When not? What distinctions could work better than BABOK’s “implement build or buy”? Yes, better than BABOK – how else can we improve)?

I’m willing to wait – learning is always a self-effort, not merely a read. I’m figuring this out as I write – try it, it’s fun!

Use the comment section at bottom – go ahead and try an explanation before looking at my effort. Then you can go back and critique and compare yours to mine, (both might be needed, or they might merge) and now we understand each other better.

If we can explain to each other, we will revel in our navels. If we can explain to the larger society of laypersons (including ourselves), we will impact the larger conversation. Keep it simple.

Einstein once said “If you can’t explain it to a six year old, you don’t understand it yourself.”

I can’t, and I don’t, but here it goes.
.
.
.
.
.
.
.
(…….. no peeking )

OK, now I will give it a try. Let me know how it can be replaced or improved. Remember, less is more.

Choosing solution Requirements before Scope before Approach is like…

Envisioning a penthouse

Deciding your architect and contractor are too expensive and slow

Then buying a helicopter and living in it at 1200 feet

It can be done, but don’t you want to live in the penthouse instead?

OR

Stealing a piece of candy from a butcher …

It looks good, and is sweet

And it goes down quick

But it causes craving, weakens your teeth, and may kill access to needed protein.

OR

Show ‘em an example:

Business Goals, Objective, Needs (yes, that is first):

• Control costs – Increase productivity of field personnel 10%
• Reduce customer loss – Increase customer satisfaction from 80% to 95%
• Continue sales growth at 10% per year under a hiring freeze
• Increase profitability from 5% to 7%

Capability Gaps (yes that is second): Field personnel are giving too much time to:

• Travel arrangements (5% of time)
• Customer demographic data acquisition (10% of time)
• Follow-up on customer emails (15% of time)

Solution Approaches (yes approaches, we are choosing later)

• Make changes to all three areas vs. pick one or two only
• Provide assistance to field personnel from regions
• Provide assistance to field personnel from headquarters
• Provide automated tools for travel and research
• Stop giving out field person email addresses
• Accept impact that ignoring emails would have on ALL customers
• Accept impact that ignoring emails would have on SOME customers
• Provide automated assistance to regions/HQ in supporting field personnel
• Increase sales while reducing demographic research effort
• Be the first in our industry to respond to emails in less than one second
• Etc

Solution Scope(s): (we still get to pick and choose from the following)

• Focus will be on handling customer email, freeing field for more sales
• Headquarters will provide super trained service specialists
• Headquarters will automate customer email service and tracking
• Regions will provide level 1 service and HQ will provide levels 2-4
• Customer service is important enough to develop our own software
• In the short run we can use commercial software and service providers
• OUT OF SCOPE we are seeking email response times of < 1 second
• In the long run, we do want:
  • Relevant / useful email responses in under a minute for 50%
  • Complete email responses (where possible) in under an hour for 90%
  • Phone service by end of the hour (when needed) for remaining 10%
  • Satisfied customers at the rate of 95% in all cases

Solution Requirements:

• 50 new head count for service / support
• New comm contracts to increase reliability and allow “smart” forwarding
• Purchase “best of breed” service software that also has interfaces for custom
• Staff of statistical computer software and language processing experts
• Integration of service work stats with existing ERP system
• Improved forecasting / sales estimating software for field personnel
• Improved reports allowing metrics on productivity and sales by team

The above is necessarily more vague than I would want (hey, real requirements take real time), but is meant to show some distinctions (level and specificity distinctions, to be exact). The BA mantra remains “Some of these things, belong with the others, some of these things are not quite the same”.). Feedback welcome – maybe I mixed levels in your mind or mine.

Since CBAP certification in 2006, I have noticed that words don’t mean what they mean (have you ever heard folks argue over what IS a requirement or ISN’T)? Now that we BAs have a standard set of concepts and best practices, it is up to us to instill new concepts into our “requirements culture”.

Don’t do what you might be tempted to do, when you hear statements like “It’s a requirement because X said so”, and “It’s not a requirement – no one asked for that” and “The Product Owner is responsible for requirements, we don’t need a business analyst.”

Do what Einstein might do (if he had been me, of course, if you are sure you know what he would say, well, tell the rest of us too) upon hearing the comedian Lou Costello say:

“They also laughed at Einstein and his theory of relativity. Now everyone has relatives.”

Say “YES!” write it down, and respond with your analysis, modeling and audience appropriate language, not with your BABOK definitions and insider knowledge.

Insider knowledge has its place of course. Here is a free BA insider joke (these, of course, must get much better, give it a try yourself)

Kevin Brennan and Julian Sammy were told that there were only three persons in the whole world who really understood the upcoming BABOK 3.0. “Who is the second one?!?!!” exclaimed both in response.
———————————————————————————————–

From the IIBA BABOK® Guide, Version 2.0

* BABOK examples of Solution Approach given in 5.3.2:

Some possible approaches include:

• Utilize additional capabilities of existing software/hardware…available…
• Purchase or lease software/hardware from a supplier
• Design and develop custom software
• Add resources to the business or make organizational changes
• Change the business procedures/processes

**BABOK examples of Solution Scope given in 5.4.2:

The solution scope includes:

• The scope of analysis (the organizational unit or process for which requirements are being developed) which provides the context in which the solution is implemented.
• The capabilities supported by solution components, such as business processes, organizational units, and software applications.
• The capabilities to be supported by individual releases or iterations.
• The enabling capabilities that are required in order for the organization to develop the capabilities required to meet the business need.

***BABOK practice generates Solution Requirements first in 6.3.2:

Specifications and models are created to analyze the functioning of an organization and provide insight into opportunities for improvement. They also support a number of other objectives, including development and implementation of solutions, facilitating communication among stakeholders, supporting training activities and knowledge management, and ensuring compliance with contracts and regulations.

Don’t forget to leave your comments below.