We often tout the virtues of intuitive thinking as a powerful tool when coming up with creative solutions. However, having a hammer doesn’t make every problem a nail. Often times, thinking creatively to problem solve a complex, high-stakes technical issue can be downright damaging. Structured (or convergent) thinking can organize a flood of information to reveal suspicious gaps in data, bringing efficiency and speed to problem investigation. Using a consistent approach focused on critical data coupled with a visual representation of this thinking tremendously improves communication and collaboration. Besides significantly advancing the search for true root cause.
Here is an example of information that was recorded in a typical, freeform field:
DPM application is not available at both DC & HQ sides, but 80% or more of the data has not updated for 0 to 4 hours at 1 or more DC’s IMOD was not informed about this issue until after 4 hours elapsed. Informed Incident Manager for Distribution.
Here is the same information using a structured thinking approach:
Which one is easier to read and to analyze? More importantly, which format tells you what we know AND what we need to know?
In a freeform text field we naturally tend to do one of two things: a) We input as much information as possible to fill the blank space—whether the information is relevant or not—to show all the work that was done; b) We leave it blank. This is not only a problem for proper root cause analysis (RCA), but it is a communication problem for transferring information, for trend analysis and for linking problems back to incidents and vice versa.
The format shown above describes a portion of the ITIL®-recognized Kepner-Tregoe approach we call “problem specification”. The problem statement (at the top) and eight buckets of IS/IS NOT information allow us to see, at a glance, what we know and what we don’t know. It drives critical thinking, provides structure and facilitates communication.
The importance of a quality problem statement cannot be understated (and it’s not the same as the case title). In our work with global support organizations, we have found that getting the problem statement consistently right will reduce the average time to resolve by 18% or more. A quality problem statement is pivotal to everything that follows in the RCA process.
Consider these italicized problem statements of varying quality:
- Server issues – This has an unclear object and potentially addresses multiple issues.
- Database server down – This is an improvement, but we can be more specific. Which server is down? And do we already know why it is down? We want to continue to ask why until we don’t know the answer anymore.
- Inventory Database Server Is out of storage space – This statement further specifies the problem and sets us up for a focused root cause analysis. The statement is specific, involves a single object and defect, and cause is unknown. This is where our problem analysis can begin.
A note about documentation:
Documentation is nobody’s favorite activity, but it is important. None of us like to spend a lot of time documenting, but without it, there is no reusable knowledge for our colleagues in the organization, no audit trail and no organizational learning. The important piece is to focus on the most critical information. As far as knowledge management software is concerned, the key is to model the tool after the process… and not the other way around.
A commitment to structured, clear thinking brings quality results that drive critical IT stability and produce real cost savings as we stop solving the same problems over and over and over again.
