In this KnowledgeKnugget™ you will learn how to gather a list of potential business problems relative to your IT project that will help you discover more business requirement. A good business problem list is a prerequisite to any problem analysis.

Start Problem Analysis by Building a Business Problem Backlog

If you are working on a project and do not know what business problem the project will solve, you have no way of really knowing when you are done whether the project was successful or not. Worse, you have only limited ability while you are on the project to decide whether it is moving in the right direction or not. Business Problem Analysis is a phenomenally powerful technique for ensuring that your project is the right project and that it is delivering the right product. Business Problem Analysis identifies the “real” problem, related symptoms, and creates a more complete list of requirements for your project from the beginning. Before you can do it, however, you need a list of potential “business problems” that the project might solve.

As a pre-requisite, let us assume that someone (presumably the project sponsor) defined the project scope in some manner. You need the project scope to get folks focused on what kinds of problems they should be identifying. Actually, the project sponsor would be a great first person to ask what problem(s) this project will solve. By simply documenting the answers, you have initiated a business problem list! Do not attempt to analyze their problems just yet; simply capture them.

Once you have your sponsor’s answers, the idea is to expand your business problem list by getting input from all stakeholders on the project. You might use email to solicit their business problems related to your project or have a meeting (virtual or in person) in which the group can present their answers. Ask each stakeholder that you identified: “What’s wrong with the way things work today”. Your goal is to collect “problems” from the different perspectives of identified stakeholders. Again, ignore the urge to analyze until you have sufficient material to analyze.

Communicate the Problems Via Email or Face-to-Face?

I highly recommend the meeting over email because the discussion around each other’s perceived problems:

• is a great team-building exercise
• generates additional “problems” from other stakeholders, and
• presents ample opportunity to start to identify potential solutions to the problems.

Generally speaking, there is no lack of the latter in a meeting you called specifically to discuss problems. That is fine; do not ignore the solutions. Capture them as someone presents them.  Under no circumstances, however, should you assume (or indicate) that that solution might actually be what your project will deliver. It is much too early in the process for that.

A Well-Structured Problem List

For each “problem” identified by a stakeholder:

… [end of excerpt]