In this KnowledgeKnugget™, you will learn how to do Problem Analysis and identify hidden requirements as well as potential solutions. Working with a list of problems, you will learn how to distinguish real problems from symptoms and solutions. In addition, reducing your problem list to the core problems makes sure that all the factors and elements that hinder an organization from achieving its objectives may be understand and resolved at the root cause.

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.

… [end of excerpt]

Past How-to Posts About Problem Analysis

Problem Statement DFD Overlay: Discovering the Source of Business Problems

Walkthrough of Problem Analysis using a DFD

Problem Analysis Using a DFD: A True Story