We Build Business Analysts
RSG Logo

RSG Noiseletter

8/5/2008 10:07:53 AM

In This Issue

The Purpose of Problems

The Prince’s Problem

The Problem Proposition

The Origin of Opportunities

Editor's Note: Change of Practice

Recorded Webcasts

Introduction to Business System Requirements
Recorded on 4/7/2008, Duration: ~ 1 hr.

Introduction to Business Process Analysis
Recorded on 3/17/2008, Duration: ~ 1 hr.

Introduction to Modeling and Analyzing Business System Data
Recorded on 6/2/2008, Duration: ~ 1 hr.

Introduction to Business Use Case Documentation and Modeling
Recorded on 4/7/2008, Duration: ~ 1 hr.

Introduction to Preparing and Facilitating JAR/JAD Sessions
Recorded on 3/24/2008, Duration: ~ 1 hr.

Introduction to Planning, Preparing and Executing User Acceptance Testing
Recorded on 4/7/2008, Duration: ~ 1 hr.

Business System Analysis in the 21st Century
Recorded on 12/30/2007, Duration: ~ 1 hr.

Requirement Gathering JAD Sessions in the 21st Century
Recorded on 12/30/2007, Duration: ~ 1 hr.

Business Analysis and the Unified Modeling Language (UML)
Recorded on 12/30/2007, Duration: ~ 1 hr.

System Development Life Cycles (SDLC) in the 21st Century
Recorded on 3/26/2008, Duration: ~ 1 hr.

Scheduled Seminars

2-30 How to Discover and Develop Use Cases
Sep 9 - 10, 2008, Chicago, IL

1-50 How to Become Agile in Business Analysis
Sep 23 - 24, 2008, Portland, ME

2-30 How to Discover and Develop Use Cases
Sep 25 - 26, 2008, Portland, ME

Virtual Workshops

How to Discover and Develop Use Cases
Aug 18 - 20, 2008

How to Model and Analyze Business System Data
Sep 10 - 12, 2008

How to Prepare and Facilitate a Successful JAD Session
Sep 15 - 17, 2008

How to Plan, Prepare, and Execute User Acceptance Testing
Sep 29 - Oct 1, 2008

How to Write Effective Business Requirements for IT Projects
Oct 7 - 8, 2008

How to Gather, Analyze, and Define Business System Requirements
Oct 14 - 17, 2008

How to Model, Analyze, and Improve Business Processes
Nov 10 - 13, 2008

How to Discover and Develop Use Cases
Dec 8 - 10, 2008

How to Write Effective Business Requirements for IT Projects
Dec 11 - 12, 2008

How to Plan, Prepare, and Execute User Acceptance Testing
Dec 16 - 18, 2008

Noiseletter Archives

Recommended Reading

Are Your Lights On? : How to Figure Out What the Problem Really Is
by Donald C. Gause, Gerald M. Weinberg

Technique Tips

Basic Problem Definition
can find important requirements

Contact Us

Voice:  (813) 319-5851
Fax:  (813) 864-0131

Email:
training@requirementssolutions.com
Internet:
www.requirementssolutions.com

The Purpose of Problems

The Purpose of Problems

I was teaching a seminar at a customer site (name provided upon request) recently when I noticed a quote from Winston Churchill, to wit, "A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty." As a business analyst, that got me thinking (occupational hazard, you know). One of the major reasons organizations initiate projects is to solve problems. I once read a statistic that 95% of all information technology projects are initiated to solve problems (which conjures up another Churchill quote, "Never trust a statistic you didn’t fake yourself.", but that is a different topic).

Statistic or no, in my experience the major reason companies decide to undertake an information technology project is because someone is dissatisfied with the way things work today – either the technology does not do what they want it to do, the business process takes too long, the data is not up-to-date, or some such issue. Some so-called optimists might insist that there are no problems, only opportunities (or challenges), but I think that is just a silly attempt at spin that focuses on motivating people in a positive sense – something else I have long viewed as suspect. As a so-called pragmatist, I would maintain that problems and opportunities are simply two different perspectives of the same situation. Neither fundamentally changes the situation, but the perspective we choose will fundamentally change how we act.

The Prince’s Problem

Let me give you a concrete example of what I mean. There is a story (myth, fable, whatever) about a soldier in the old days (i.e., before we invented weapons of mass destruction) who broke his sword in a battle. Discouraged, he dropped the sword and retreated (a.k.a. deserted). A Prince who had fallen off his horse (good old days, remember?) and lost his sword stumbled across the broken sword the soldier had abandoned. Inspired, the prince picked up the broken sword and defeated the enemy single-handedly (O.K., I took some literary freedom with the story, but you get the gist of it and I am sure you have heard it before).

Personally, I have never been able to figure out why this so-called Prince was able to fight better with this broken sword than he had with the presumably whole sword he previously lost, but I guess that is just my geekdom showing. At any rate, of course this Prince is the hero of the story because he saw an opportunity where the soldier had seen only the problem. But, wait! What would have happened if that soldier had not abandoned his broken sword and left the playing field (excuse me, deserted the battlefield) so willingly? We would have had no prince, no hero and presumably the battle would have been lost which inevitably means that we would also have no fable (history is written by the victor, remember?) and you would not be reading this article. (Wow, there is a case of deductive reasoning ran amok!)

In my rewrite of the fable, I have the Prince scouring the countryside, leaving no stone unturned, looking for the soldier who had abandoned his weapon. When he finds him (cowering behind a keg of rum in a run-down tavern in the worst part of town no doubt), he thanks him profusely for creating the problem that became the opportunity that the Prince so aptly capitalized on. As a reward, he pardons the deserter and promotes him to Prime Minister or President or some such thing, thus ensuring that the country will have ample problems in the future that someone (presumably the Prince, of course) can then turn into opportunities.

The Problem Proposition

Far be it from me to become the problem bigot, but I do like to give credit where credit is due. If we did not have problems, we would not need analysts to analyze them and they could then be busy increasing the average intelligence of the unemployed – thus creating another problem to be turned into an opportunity by a future Prince of some kind.

There are a ton of publications on how to take advantage of so-called opportunities (list provided upon request), starting with the "Carpe Diem" enthusiasts up through every get-rich-quick scheme on the planet. Problems, on the other hand, have always been considered bad. One could say that we have a problem with problems in not wanting them, not cherishing them, doing our best to rid ourselves of them. But consider this: if we had no problems, we would have no opportunities. Without problems, there would be no progress. If Og or Ag (whichever it was – I never could keep them apart) had not tired of eating raw food, we never would have tamed fire.

The Origin of Opportunities

As a business analyst, problems are your allies. Your job is to find business problems, to ferret them out, to track them to their source, and then to define business requirements that express how your organization would like to solve them. There are a variety of tools and techniques at your disposal to aid in this quest, things like Gause-Weinberg Problem Definition, Aristotelian Problem/Symptom Reduction, Root Cause Analysis, to name a few (list provided upon request). None of the named techniques helps you solve the problems, you realize — their purpose in life is to help you find the problems. Once you have found the problem, finding a solution gives you the opportunity to become a Prince (or Princess, whichever you prefer).

The purpose of a problem, then, is to be the opportunity waiting for you to seize. As in all good fables, there is a happy ending: the job security for the business analyst inherent in this perspective. Since every solution creates its own set of problems — which are the opportunities for the future — you’ll never be out of work. So sally forth and find those pesky business problems. Define the right business requirements and you, too, can become the hero of the day and create the solution that will become tomorrow’s problems.

Hmmm, does that statement brand me a pessimist or an opportunist?

Editor's Note: Change of Practice

To address a timing problem that our readers have reported, the Requirements Solutions Group has decided to make our recorded webcasts available to the general public. This allows you to view these pertinent topics at your leisure and eliminates the necessity for having to schedule them on our time. You can see a list of the recorded sessions in the left panel of this month’s Noiseletter.

We trust that this change is to your advantage. If you have any questions, suggestions, ideas, opportunities, or other thoughts you would like to share with us after you have viewed a webcast, please let us know. We are always happy to help you solve your business problems.

 

Tom Hathaway and Dan Myers
Managing Partners

Future Feature: "The Evolution of Tools for Business Analysts"

© Copyright 2008 by the Requirements Solutions Group, LLC.