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 JRP/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.

Advanced Training for business analysts

VIL411 : How to Manage Changing Requirements

Foundation Training for business analysts

CIL310 : How to Elicit (Gather), Write, and Analyze Business Requirements

CIL620 : How to Model, Analyze, and Improve Business Data

VIL311 : How to Elicit Business System Requirements

Overview Presentations for Management

WEB510 : Business System Analysis in the 21st Century

Other Products and Services

Requirements Management Office

Tailored Training

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 Productive JRP/JAD Sessions

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

	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 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.