Expanded Incident Bike

The most important step in the major incident process is what I call the Harrison step with relates to the timelines. Harrison was an 17^th century scientist who solved the problem of how to calculate longitude for shipping by using time, when prevailing wisdom dictated that the solution was in the using of astronomical charts. Harrison was able to design an accurate watch that could be carried on board a ship.

In the major incident process, timelines are the most important aspect of the process to do right. The reason is that it is the best source of data for problem management, which oversees the process from a quality viewpoint. Deviations from the norm are clear indicators of underlying issues.

The timelines in the major incident process are aligned with ITIL processes. These timelines in ITIL are referred to as the Expanded Incident Lifecycle.

The Expanded Incident Lifecycle has a path of Incident -> Detect -> Diagnose -> Repair -> Restore -> Recover. The times of each of these events should be diligently recorded as well as the time of when a workaround becomes available and is implemented.
For many IT people the times are confusing as they misunderstand the naming of the terms in the Expanded Incident Life cycle. To better explain these terms, we'll use an analogy, of riding a bike.

I am riding my bike. It is a nice Sunday morning ride in the country side. The Incident happens, the rear wheel experiences a puncture. This is the time of the Incident. As it is the rear wheel I do not notice it immediately, and only detect the incident when the road starts to feel extremely bumpy. This is the detection time. I stop my bicycle and dismount. My mates with me also do the same. We discuss the issue. It is clear that it is a puncture and it was caused by a small nail which is clearly visible. We can remove the nail, and the tire will still be usable but we need to either repair the tube or replace it. I have a spare tube in my saddle bag, and we agree that replacing the tube is the quickest and best way to continue on our journey. This is the time of diagnosis. We decide that this is a good time to have some water and cool drink before we start replacing the tube. We also notice that the incident has happened at a very scenic location so we take a few pictures. Finally, we start removing the wheel. This is the time of repair. We remove the wheel, remove the tire, replace the tube and reattach the tire. We put the wheel back on the bike. This is the time of restore. At this point we all decide to answer the call of nature. We then mount our bikes and continue our ride. This is the point and time of recovery.

If we analyse the time lines, in the incident above, we will notice a deviation from the norm in two time periods, i.e. time to repair and time to recover. This is the time where we had some drinks and took a pit stop. In the context of our ride this wasn't a big deal, but if we were in a competitive race we in all probability would have skipped those actions. In a actual IT incident the same principals are applied, and maybe the Expanded Incident Bike will help in recalling these time points.

• Data Center
• ITIL