Monthly Archives: August 2013

Better Business Analysis Through Problem Statements

NOTE: As part of a BA discussion group at work, we were discussing different ways to encourage a focus on defining the root cause of the problem before a solution is specified. We had all had far too many experiences with a business partner saying “the problem is that the system does not …. (have a drop-down here, have this extra screen, a button for this, etc.)”, where the problem is defined as the lack of the solution they have already decided upon without any investigation to ensure that the problem has been correctly identified. I brought up the use of Problem Statements, and was asked by my peers to write up my ideas in more detail. I ended up writing it in article format so that it could be shared ahead of time, and it was deliberately written to generate some discussion. I hope you find it useful as well.

 

Introduction

A problem can be defined as “a difference between the expected state affairs and the actual state affairs”. And according to Wikipedia a problem statement “is a concise description of the issues that need to be addressed by a problem solving team and should be presented to them (or created by them) before they try to solve the problem”. [1]

Problem Statements are a common aspect of Project Management. They are frequently included in a Project Charter, with the Problem Statement identifying what problem the project is focused on solving and the Business Case identifying why the problem should be solved (usually in the form of some specific benefit(s) to be gained).

However, problem statements should also be used in the Elicitation and Requirements Analysis aspects of Business Analysis work.

Continue reading