“We cannot solve problems at the same level of thinking with which we created them.” Old adages like these stick around because they’re true. And in a post for PM Hut, Paul C. Donehue demonstrates how challenging yourself to think at a higher level enables a whole new strategy for solutions in IT risk management.
The Problem Statement
The ultimate use of this wisdom lies in the creation of a problem statement. A thorough, written problem statement ensures that all participants have a shared understanding of the problem, that the organization can give the problem the priority and urgency it deserves, and that the team can measure solutions against an agreed upon baseline–in addition to creating a basis for testing for the existence of root causes and their solutions. In all, Donehue identifies four practices that lead to an effective problem statement.
The Four PS Tips
- Write it down.
- Include a quantification of waste.
- Specify your metrics.
- Omit assumptions about root causes.
Writing things down is a very definite way to clear up ambiguity. It is an excellent way to hedge against willful ignorance and frustrated expectations. As we’ll see, it also lays the foundation for the additional three tips. For instance, the J-word, “justification,” comes into play here. Even if you’re aiming to improve something, you must prove that the cost of improvement is less than the value gained. Quantify the waste. Make it clear that problem elimination is actually a value ($) addition.
Third, it’s difficult to judge an improvement by an unstable idea of what constitutes the problem. Be sure to put your situation into numbers. That way, when a solution finally does arrive, it too will be quantifiable, and more importantly, it will be a genuine solution.
The final tip involves bias. We all have it. And to ignore our own biases is to invite disaster upon our problem-solving efforts. Moving forward on the basis of assumptions may seem like a time-efficient strategy, but it ultimately leads to wasted time as we try to back ourselves out of dead ends later on.
Read the original post at: http://www.pmhut.com/the-impact-of-defining-a-projects-problem