A Brief History of Time

I hope Stephen Hawking does not mind me alluding to the title of his great book. Today, I would like to talk about the importance of time. Time is extremely relevant in IT Service Management as it helps you understand when a particular event occurred or will occur. Understanding when something is going to happen is vital to effective Change Management. It facilitates creation of forward schedule of changes.

The changes need to be placed in time. So the point is, a change is never just approved, but it is approved for a particular time slot. People need to know when it is going to be implemented in order to see potential collisions with other changes. As you can see, ITIL Change Management and astrophysics have something in common -- they both make use of space-time continuum.

Actually, the same can be said about Problem Management. In order to deal with problems efficiently and proudly report solid KPI results, people need to get to a good start. One of the most vital things is to establish the timeline of incidents related to the problem. You need to know when each event took place. The accurracy you want to achieve depends on your particular environment; Problem Management in NASA probably needs "a bit" more precision than in a retail chain.

Such a simple thing as timeline can reveal surprisingly much about the problem. You will want look for patterns; incidents happening at similar intervals, or lasting for similar periods. Frequently, you will find such a pattern and it will be one of your biggest leads during problem investigation.

Establishing a timeline can be a daunting task. But do not give up. Think of yourself as a police detective. Everyone wanted to be one once upon a time, right? Or maybe you like one of the "CSI" TV Shows? It is the same! You need to dig through a lot of incident records, frequently reading descriptions put in there by time-pressed engineers, who just wanted to get it over with. Some of the dates might not be accurate, and you will be correcting them based on various other leads from the incident history.

Finally, after hours of work, you can generate your report and take a look at everything that happened from A to Z. It pays off, because a lot of the times simply looking at the sequence of events will either give you a potential root cause, or get you one step closer to it. And even if you only see total randomness in all those incidents, it tells you something as well. It helps you get closer to the root cause by means of deduction. By eliminating the impossible, you get to the only logical conclusion.

Good luck mastering time!


Post a Comment