In my last post I discussed the differences between incidents and problems and the relationship between them as well as why ITIL distinguishes between the two. I promised to give a real-life example of the difference between incidents and problems in this follow-up. This post will describe a real-life situation that fits the ITIL model of incident management.
An Incident Story
When I was a teenager, my father purchased a car for me. I was just over 16 years old at the time. I had recently earned my license and was starting to drive. This was the summer of 1986. The car that my father bought cost about $300 and was about twelve years old. It had been sitting in a field for a couple of years prior to our purchasing it.
As you can imagine, a vehicle that’s already twelve years old and has been sitting in a field for a couple of years likely has some problems. When one purchases a car in that condition, the problems may or may not surface in the form of incidents, which may result in the vehicle failing to operate or an impairment to normal operation. In the case of this car, my father insisted that we do a couple of things before I was ever allowed to drive the vehicle. The first thing we did was spend an entire Saturday putting new brakes on the car. Brakes on cars of that age are nothing like modern-day vehicles. Suffice it to say I didn’t particularly enjoy spending a Saturday putting new brakes on the car. Second, we had a new set of tires put on the car.
Once those two things were complete, my father deemed the car safe and I was allowed to drive it. The purpose of the car was to get me back and forth to school and to an after school job that I had at a grocery store.
I began driving the car daily, and it worked fine for about two weeks. Then one day I was driving the car home from school, and, suddenly, the engine started sputtering and losing power. After thirty seconds of the car lurching down the road the engine quit running. I drifted to the side of the road.
I grew up around cars and motorcycles and various machinery and equipment, so even at sixteen I had a good idea about how to troubleshoot automobiles. The first troubleshooting activity I did was to attempt to start the car. As I drifted to the side of the road I turned the starter. I noted two things; first, the solenoid was clicking, which indicated that the starter was receiving electrical power from the battery, and second, when I turned the key the starter turned over, which was indicative of proper functioning.
The next troubleshooting activity that I did was to look at the fuel gauge. According to the fuel gauge the car had three-fourths of a tank of fuel. I was fairly sure that the measurement was accurate, so I knew that I wasn’t out of gas.
At this point I was certain that I had fuel and that the electrical aspect of the car was working properly. With cars, one of the next items to check is the airflow. I stepped out of the car and first checked the tailpipe. I looked to see if the muffler was damaged or if something was preventing the exhaust from leaving the car. I thought this was unlikely, but it was easy to check. Sure enough, there wasn’t an issue with the tailpipe. Continuing to check the airflow, the next thing I did was open the hood to ensure that airflow into the engine was not impeded. I checked the intake and the air filter, and everything looked fine. There was nothing that prevented air from reaching the engine.
At this point I was a bit puzzled. Everything looked fine. The next possible item that I thought of that could have affected operation of the vehicle was the fuel flow. I searched around the engine compartment, and I noticed the fuel line and how it was routed. On this car, before the fuel line reached the carburetor, there was a small stainless steel fuel filter. I decided that disconnecting the fuel filter and ensuring that it wasn’t impeding fuel flow was an unlikely, but easy to check item.
I removed the fuel filter. It was hot and it glistened in the Texas sun. I shook it vigorously, and only a small amount of fuel exited from the filter. Then (and I don’t recommend this) I took the fuel filter, put it in my mouth, and blew into the filter as hard as I could. As I did this chunks of dirt and rust escaped from the filter. When that happened I realized that I was on to something. I shook the filter again to loosen more sediment. For posterity’s sake I gave it another hearty blow, and more dirt and rust issued from the fuel filter.
I reconnected the fuel filter, closed the hood on the car, got back in the car and restarted it. You can probably guess what happened… the vehicle started, and I drove home. It seemed like everything was fine.
Until exactly two weeks later, when I was driving the car, and the exact same thing happened again…
When the car stopped running I experienced the equivalent of an outage of an operational service. In ITIL terms we call this an incident.
I owned this car for exactly one year. The incident that I described above happened like clockwork every two weeks. To the readers of this blog, I pose a simple question: If I owned this car for one year, and this incident happened every two weeks, how many incidents did I experience?
In next week’s installment of this series I will discuss some of the answers to the question above, as well as the problem aspects of this scenario.