A good problem statement lists symptoms, suggests the problems likely causes, and estimates the resources needed to solve the problem. It serves to communicate to the user, to management, and to the technical people the analysts understanding of the nature of the problem and an initial sense of the problems resource implications.
A well-written problem statement is an effective means of communicating the analysts understanding of the problem and its causes to the user, technical personnel, and management, thus helping to ensure that the right problem is solved. The focus on symptoms, objectives, and scope supports high level verification.
The problem statement is, by its very nature, preliminary. By itself, it does not represent a sufficient base for selecting, designing, or implementing a specific physical system. In particular, the scope should be viewed as a ballpark or order of magnitude cost estimate. Common mistakes include suggesting possible physical solutions to the problem rather than logical objectives for solving the problem, treating the preliminary estimate of system scope as a serious cost estimate, and writing a problem statement that includes too much technical detail.
The problem statement often serves as a charter, or formal authorization for the information gathering and problem definition phase (Part II). The problem statement is often based on a limited number of preliminary interviews (# 8) or observations. The detailed system requirements defined at the end of the analysis stage (Part IV) often reference the objectives in the initial problem statement. Detailed cost estimates, schedules, and budgets are typically based on the requirements and prepared before the design stage begins.
Once a problem is defined, a sense of its causes and its likely resource implications must be communicated to the user, to management, and to technical personnel. Generally, this communication takes the form of a written problem statement, sometimes called a statement of scope and objectives, a user needs assessment, an operations concept document, or a mission statement.
The precise form of the problem statement varies from organization to organization. The ideal length varies from project to project. No matter what format is used, however, a good problem statement includes the following elements (Table 12.1):
|Table 12.1 The Contents of a Good Problem Statement|
|A. The problem||A list of measurable symptoms.|
|Examples:||Inventory value is $100,000 too high.|
|Our competitor can process an order in one day but we need three.|
|B. The objectives||The likely cause or causes, usually stated as measurable objectives that, if achieved, are likely to contribute to solving the problem.|
|Examples:||Reduce average stock time by two days.|
|Reduce inventory cost by $100,000 by eliminating obsolete inventory.|
|Reduce inventory cost by $100,000 by reducing safety stock to a level sufficient to cover expected reorder time plus five days.|
|Reduce sales order processing time by one day by improving paperwork flow.|
|C. The scope||A sense of the problems magnitude, often stated as a preliminary cost estimate.|
|Examples:||The estimated cost of this system is $10,000 plus or minus 25 percent.|
|Preliminary estimates suggest that a team of three analyst/programmers will need six months to solve this problem.|
The first step in verifying the problem statement is to compare the symptoms to the objectives. Each symptom should be addressed by one or more objectives, because orphan symptoms are not likely to be corrected. Each objective should address one or more symptoms, because orphan objectives suggest overlooked symptoms or superfluous features.
Comparing the scope to the symptoms allows the user to judge if solving the problem is worth the cost. Comparing the scope to the objectives allows the technical personnel to judge if they can achieve the objectives given the scope. The scope, by itself, allows management to determine if adequate resources are available. The combination of the symptoms, the scope, and the objectives allows users, management, and technical personnel to independently determine if the problem is worth solving.