Craig, thank you for a wonderful and thorough elaboration of key points in defining the problem, which is a necessary and often-missed first step that I've been advocating with only partial success for years. I've found that it's a bigger and more difficult issue than your article suggests. Projects frequently are initiated with inaccurate definition of the real problem, which means it doesn't get solved and time/resources/credibility get wasted, generally without recognizing the waste or understanding why it happened. People often confuse problems, causes, and solutions. In my requirements, project management, and ROI practices, I use a powerful tool called the Problem Pyramid(tm) which adds considerable strength and discipline to the methods you described so ably. To help get the problem right, it's important also to identify the measures of the problem now and when solved that indicate the quantified value of solving the problem. Once the problem has been defined accurately, then it's essential to identify its causes and REAL business requirements deliverable whats that will achieve the goal measures and provide value by solving the problem, before getting into the specific proposed solution hows that many people start with. Thanks again for your great article.

In our industry (IT services), screen shots are reasonably analogous to photographing the problem in most cases. The parts that seem to be hardest to train are removing emotion (bias-"that pain-in-the-arse customer is calling again") and "absolutes" ("our entire network is down"), and doing it in a way that is soothing and pleasant for the customer. I've posted this for everyone in our company to read. Thanks!