Analyze Business Problems

Seminars and Services We Offer to Perform this Process
Other Steps (Activities) We Can Help You With

We can:

		teach you how to do this activity
	with our in-house or public seminars and e-learning

		show you how to do this activity
	with E-Coaching

lead your experts
through this
activity in a Facilitated JAD Session

Problem analysis is a set of techniques that flush out and define areas in which the end users are unsatisfied with an existing solution. These techniques help you understand the business problems and their context sufficiently to avoid introducing negative side effects with your solutions. It is also your best insurance against solving the wrong problem.

Business Problem Analysis
		enables early scope definition for your projects

		avoids marginal-value add-ons

		ensures common understanding of purpose of project

		establishes foundation for funding of project

		creates basis for development of test strategy and plan

		sells the project to the outside world

		facilitates cross-project risk-based management decisions

When should you analyze problems?

Problem analysis should precede the development of the solution. If, at any time during the project, the decision makers can not communicate what problems the project will solve, problem analysis is a good idea.

Who should analyze problems?

Business analysts, system analysts, customer liaisons, project leaders and managers from impacted business areas need to understand the business and technical problems that the project will solve.

Core Training for Business Systems Analysts

1-10 : How to Gather, Analyze, and Define Business System Requirements

1-11 : How to Capture and Tame Business Requirements

1-40 : How to Manage Changing Business Requirements

1-50 : How to Become Agile in Business Analysis

Core+ Training for Business Systems Analysts

2-20 : How to Jump-Start Requirements Gathering with User Stories

2-40 : How to Manage Small Projects

Overview Presentations for Management

5-30 : Business Analysis and User Acceptance Testing

Supplemental Training for Business Systems Analysts

3-30 : How to Prepare and Facilitate a Successful JAD Session

Other Products and Services

Requirements Management Office

Outsourced Business Analysis

E-Coaching

JAD Facilitation

Tailored Training

Skills Assessment

The Small Project Guide



	Under Time Pressure?

	Learn how to run an efficient, effective JAD session that does this activity faster. How to Prepare and Facilitate a Successful JAD Session

	Our e-Coaching offer is a cost-effective alternative for small groups to learn these and other business systems analysis techniques at their own workplace or for follow-up after a training seminar


	your business analysis skills

	Gather Prioritized Requirements
	Model and Analyze Business Processes
	Model Business Data
	Design Business Architecture
	Develop Quick Fixes
	Engineer Business Processes
	Evaluate Potential Solutions
	Engineer Test Data
	Execute Tests
	Plan Testing Activities

Requirements Solutions Group offers training as well as web-based and on-site consulting services to support a wide range of activities within the system development life cycle all targeted exclusively to the Business Analyst, Requirements Engineer and the Subject Matter Expert.

You can also visit our bookstore for the newest publications in the business systems analysis field

Basic Problem Definition

Step 1

Step 2

Step 3

Get a written list containing 5 - 9 answers to the question:

"What is the problem?"

from each involved party.

Define who wants to solve each problem, who cares how it is solved and who might resist the solution.

Identify the players by role or job title, not name.

Separate the "real" problems from the symptoms and proposed solutions.
A "real" problem has multiple potential solutions. A good solution will cause all related symptoms to disappear.

If necessary, apply problem/symptom reduction.

Problem/Symptom Reduction

STEP 1: Ask each involved party,

"What is wrong with how things work today?"
Capture the answers as a numbered list of potential problem statements expressed as complete sentences.

STEP 2: For each problem statement on your list, ask,

"Can anyone involved with the project do anything about it?"
If not, move it to an "out of scope" list to be reported back to management.

STEP 3: For each problem statement on your reduced list, ask,

"Can anyone on the project identify multiple (different) solutions?" If there is only one solution, the statement is an implied requirement. Rephrase the statement and move it to the requirement list.

STEP 4: For each problem statement on the remaining list, ask,

"If this problem were solved, would any other problem go away?"
A "problem" that disappears when you solve a different problem is a symptom. Associate the symptom with the related problem.

Any problem statement that is still on the list is considered a "real" problem. These are the problems that any solution needs to address while making sure that all of the identified symptoms disappear.