Chia sẻ qua

Checklists and Mnemonics

  • Bài viết

Dennis Groves here....

The most common list is the to-do list, and it is the one we are all most familiar with and so the real value of a checklist is often very misunderstood. Aviation and medicine make heavy use of them. Computer programs are basically a sequential list of operations to for the computer to perform. In computer science; the linked list is considered to be a fundamental data structure.  However, its most basic component is the list. In fact there is an entire computer language that is composed only of lists. And an entire branch of mathematics. The list is such a fundamental tool that most of us take them for granted and think nothing more of them. And yet we would be doing ourselves a great disservice to dismiss the usefulness.

Mnemonics are a kind of list used to recall important information. Recently I read a brilliant post by Adam Arndt about "SOAP"

The SOAP method involves putting all data concerning a problem into a “SOAP Template”, that is to say that all data should be entered underneath one of 4 headings (the first letter of each heading spells out the acronym “SOAP”):

Subjective, Objective, Analysis (or “Assessment”), Plan

Subjective information is filled out first and should contain subjective, qualitative information about the problem.  Examples: “The network is slow”, “Outlook “hangs” when I try to send an encrypted email”, “I feel sick”.

The Objective information is filled out next and should contain verifiable/verified quantitative information that provides further insight into the Subjective information that the customer/patient has provided.  Examples: Event ID’s from event viewer, errors displayed on the user’s screen, log files, packet captures, version information about software, programming languages used in code, functions used in code, % CPU utilization, blood pressure, body temperature, and heart rate statistics.

Analysis This is where you use your brain and analyze the Objective data that has been gathered and attempt to find root cause.  One result of the initial analysis may be that you do not have enough Objective information to solve the problem so you ask the customer for additional Objective information that you need to continue the Analysis.  This is an important part of the case documentation process as it should track any actions that have been attempted/investigated so that if another engineer must take over the T-shooting process the same actions are not performed multiple times.  The final output of the analysis phase should be the discovery and documentation of the root cause of the issue.

Plan A list of possible mitigations for the problem.   A list of possible ways to resolve the issue with their pros and cons laid out. (In some situations only one solution may exist.)  The customer will then choose which solution to implement (we’re just consultants, not their business decisions makers we don’t make decisions for customers, we just inform them of their options and the pros and cons and they must choose which one works best in their environment), this decision should be handed off to the customer’s Release Management process and, especially when we’re doing consulting for the customer we should make sure that the customer understands the Operational Impacts surrounding that change.

The utility of such a pattern in problem solving is really amazing. For example lets say your worried about saving for the children's university education? SOAP to the rescue. Subjective: your fear you don't have enough money. Objective: look in the bank; have you started a college fund? Analysis: Not enough money for their education. Plan: Set aside money for the children's education every paycheck. Wow! That is a really useful pattern. And yet this was ostensibly invented to reduce medical malpractice law-suits by getting doctors to collect information in a consistent manner so that nothing was forgotten in times of emergency.

I find these kinds of patterns to be useful and exciting; as does my friend J.D. Meier who has a blog devoted to the documentation of such patterns and insights.

Comments