Engineering and management consulting share a core aspect in that each discipline tends to be very problem-solving oriented. In engineering, one may be posed the problem of trying to figure out the optimal circuit or filter for removing or minimizing noise from a radio station transmission. There are structured, mathematical ways for doing this. As another example, management consultants may be posed the problem of trying to figure out the market opportunity and business strategy for a company to extend its product line for a portion of a client's customer base. There are common business methodologies for addressing these types of problems too.
To pick on consulting for a moment, sometimes it's very tempting to disappear and run off and solve the problem that's been articulated in the statement of work signed with the client. But I think that it's also important to have a good client relationship and regular communication structure that enable the problem statement to be adjusted and refined with the client. As an example for some of the engagements I oversee, I ask consulting teams to write down the problem statement in their own words near the beginning of the project (which may sometimes be a list of key questions in paragraph form that the customer has asked plus the objectives of the project) and refine the problem statement to a finer level of detail throughout the project. The end result of these efforts often culminate at the final executive presentation where the consultant can put the refined problem statement as either slide one or two of the slide deck. The problem statement reaffirms the need for the project and consultant.
So while at the beginning of an engagement, a problem statement might be something like, "Purpose of project will be to determine the technology strategy for XYZ", in the end, the refined problem statement might be "Purpose of the project is to address the following: 1) determine the business attractiveness of A, B, and C services in XYZ market, 2) identify technology options for approaching the market and tradeoffs, 3) perform full financial assessment of options, including worst case/walkaway price for auction PDQ, which is prerequisite for one of the options, and 4) determine optimal business model for approaching market, which includes consideration of leasing and buy/own models with respect to CBA.
By both breaking the problem statement down to a lower level of granularity and repositioning the statement for accuracy, it becomes easier to determine whether the team is solving the right problem and to divide the problem in such a way so as to let numerous big brains attack the pieces.
Although I'm not much into social commentary, I was in part motivated to write this post based on what is going on in Iran with nuclear fuel and the interests of both Iran and the United States. From the perspective of the US (though I'm no expert) it seems as though some have articulated the problem statement as being, "how do we prevent weapons-grade nuclear fuel from getting into the wrong hands?". Just for argument's purposes (since this may not be the right problem statement), what if the problem statement was rearticulated to be, "how do we help countries to achieve their nuclear energy goals while preventing weapons-grade nuclear fuel from getting into the wrong hands"? With a refined problem statement, one might think of more tailored approaches for addressing each issue, such as supporting or even funding nuclear energy goals, while requiring monitoring for process control purposes.
The real point of all of this rambling is that rearticulating problem statements can often lead to better outcomes, stimulate creative ideas, and offer opportunities for teams to get around roadblocks.
Update (4/12/07): I wanted to elevate the visibility of an excellent point made below by Michael Stein. He writes "the problem statement is often different for different stakeholders, and to articulate a statement that encompasses the entire picture may be in itself a major step towards a solution."
