The first step is to gain agreement on the definition of the problem to be solved . One of the simplest ways to gain this agreement is to simply write the problem down and see whether everyone agrees .
As part of this process, it is often helpful to understand some of the benefits of a proposed solution, being careful to make certain that the benefits are described in the terms provided by the customers/users. Having the user describe the benefits provides additional contextual background on the real problem. In seeing the benefits from the customer's point of view, we also gain a better understanding of the stakeholder's view of the problem itself.
The Problem Statement
You may find it helpful to write your problem down in a standardized format (Table 5-1). Filling the table in for your application is a simple technique to help ensure that all stakeholders on your project are working toward the same goal.
Spending the time it takes to gain agreement on the problem being solved may seem like a small and insignificant step, and in most circumstances it is. But sometimes it is not. For example, one of our clients , an equipment manufacturer, was engaged in a major upgrade to its IS/IT system, which provided invoicing and financial reporting between the company and its dealers. The theme for the new program was to "improve dealer communications." As such, the team had embarked on a significant new system development effort.
Table 5-1. Problem Statement Format
An exercise in gaining agreement on the problem being solved was enlightening. The development team “defined solution envisioned a powerful new system that provided better financial reporting, improved invoice and statement formats, online parts ordering, and the like. And oh, by the way, the team eventually hoped to provide the capability for electronic funds transfer between the company and the dealer.
During the problem statement exercise, company management had the opportunity to provide input. Management's vision was substantially different: the primary goal of the new system was to provide electronic funds transfer that would improve the cash flow of the company . After a raucous discussion, it became clear that the first-order problem to be addressed by the new system was electronic funds transfer; other dealer communication features were considered simply "nice to have." Needless to say, there was a substantial reorientation of the objectives of the new system, including a new problem definition that identified electronic funds transfer as the problem being solved. This reorientation also triggered the development of a different system architecture than had been envisioned, complete with the security capability consistent with the risks inherent in electronic banking.