A Basic Business Problem Analysis Technique

How does your organization decide which projects to fund? When a project is done, how do you know if it was successful? Business problem analysis is a set of techniques that identify and evaluate areas in which stakeholders are unhappy with an existing situation. These techniques help you understand the business problems and their context sufficiently to isolate the real pain points, manage a problem backlog, establish a basis for measuring success, and initiate basic cost-benefit analysis to help you make the right decision.

Business Problem Analysis:

• defines the scope for projects
• ensures common understanding of purpose of projects
• establishes foundation for funding of projects
• creates basis for development of test strategy and plan
• sells a project to all stakeholders
• facilitates cross-project risk-based management decisions
• avoids marginal-value add-ons

When Should You Analyze Problems:

Ideally, business problem analysis should precede the development of the solution. However, any time decision makers cannot communicate what problems the project will solve (regardless how advanced the project is) is the best time for business problem analysis.

Who Should Analyze Problems?

Business analysts, product owners, project leaders, managers, and virtually anyone working on the project need to understand the business and technical problems that the project will solve

Agile Problem Analysis

To avoid wasting money developing the wrong business system, you need to understand what business problem your project solves. The challenge is how to get a legitimate, well-expressed problem statement that facilitates developing the best possible solution for your project — and get it done quickly. There is a simple, “agile” approach to identifying “real” problems and creating well-expressed problem statements for your project charter. As a prerequisite for problem analysis, you need a “problem backlog” that you have gathered from all of your project stakeholders. Once you have this list of potential problems, your team of cross-functional stakeholders needs to make four fundamental decisions to identify the “Real” problem (or problems).

Is It a Problem?

Does the statement express something that is wrong with the current situation from one or more stakeholders’ perspectives? Quite often in the process of creating the problem list, items slip in although they are not really problems per se. They may be simple statements of fact, such as

“It takes 23 minutes to fill out the form requesting insurance coverage.”

Is 23 minutes a problem or a speed record? You need to restate items like this to express a problem (i.e., “We are losing applicants because it takes 23 minutes to complete our on-line application form.”) or remove the items from your list before you start. Otherwise, you will waste precious time debating and discussing them only to discover that many are irrelevant anyway. Put the items you remove on a list called “Irrelevant items” and distribute it to your peers and managers to see if anyone else is interested in them.

Can You Solve It?

If the statement is a problem, can anyone on your team do anything about it? If no one on the team (including the project sponsor) has the authority or means to do anything about the situation the statement describes, it is OUT OF SCOPE for your project even if it is a problem. Move these statements to a separate list entitled, “Out of Scope Problems”. Give this list to your manager or someone who can take charge of it. Perhaps other projects are already involved in doing something about that and they might be grateful for your contributions.

A Problem Analysis