I recently gave a webinar on deferred maintenance and how you can learn to “escape” the risks of postponing routine maintenance activities from one of the great masters of escape, Harry Houdini. You can listen to the webinar on-demand here.

First, a little Houdini background. Harry started his career working the local nightclub and circus circuits, where he developed both his act and his showmanship skills. He then went to Europe, where he utilized his mastery to get longer bookings and build his reputation as an escape artist. Once he established mastery over one type of escape (for example handcuffs), he would add elements to that trick to keep his material fresh and extend his reputation. He moved on from handcuffs to chains and straightjackets, then to jailbreaks, underwater escapes, etc. Each time he re-invented his routine, mastering each of the individual aspects of the entire performance. Now you may be asking how a magician from the early 1900s can offer any insight into how to keep your modern, 21^st century IT platforms healthy and available. Well, through my own version of creative magic, let me show you…

 

Let’s define deferred maintenance to start. Simply put, it’s the delay or suspension of the execution of the routine tasks required to retain the full functionality of a system, platform or application. Maintenance is not repair, and the difference is important to this conversation. Repair is to return a system, platform or application to its previous state of functionality. This makes the assumption that the device has moved from its desired state to a lesser state.

Here are some examples of deferred maintenance in IT, at least IMHO. You can certainly argue otherwise with some of these…

Updating firmware on a hard drive, versus replacing a failed one. Performing patch management. How about removing temporary files, disk defragmentation, or extending warranty / vendor support coverage before they expire.  If you wait for them to expire, then you can state that while the device is not in a lesser state of functionality, it may take longer to acquire parts or get a technician on the phone for assistance, and that would impact repair time.

Ok, so let’s agree the lines can be a little blurred between what is and what is not considered maintenance.  But I don’t think there is a lot of room for debate on what the outcomes of deferring that maintenance can be.  When you defer, you can impact system availability, impact your ability to update other systems, extend the length of critical event management, and even extend your time to market support for the business. You can also state that deferring maintenance increases your risks and can increase your maintenance costs when you do catch up.

So, how does the story of Houdini provide a guiding hand in how to escape from this reality? If you look at how Houdini created his act, built his reputation, and maintained his status over a long career, the secrets are there to be discovered.

The first element he employed is that of research. Houdini spent much of his time researching all methods of escape both before and while incorporating them into his performances. It made him more effective over time and allowed for improvements to process and execute.  In this way, Houdini provided a roadmap for all similar artists to follow. He would spend hundreds of hours in this mode in order to perform a trick that may take minutes to execute.  Why so much time?  It was what allowed him to discover singular ways to solve different challenges. Following his example, we can also say that the more research you do on the best and most efficient ways to perform maintenance activities, the more successful and cost effective they become.  If they are successful and cost effective, then they are much more likely to be repeated and not deferred.

The second way Houdini became a master was leveraging advanced planning and preparation. He often visited jails prior to his jailbreaks to map out the layout, determine the locking mechanisms, and where best to conceal his “tools.”  Likewise with his underwater escapes, he installed a large bathtub in his home to allow himself to practice holding his breath. This allowed him to perform feats others saw as impossible. You can do the same with maintenance. Planning and preparation will enable you or your team to feel comfortable with the process, deliver it with consistency, and feel good about the outcome.  With maintenance, that is half the battle.

The third aspect of Houdini’s success was repetition. Houdini would perform the same act hundreds of times in order to reduce his escape time.  That allowed him to add elements of danger, like doing it underwater or while “buried alive.”  Now, I would not recommend that you perform your maintenance tasks while handcuffed underwater, but the repetition of the tasks can lead to interesting outcomes.  Efficiency for one, and consistency for another.  When you reach this level, you can start looking at ways to extend your maintenance into other areas, further improving your systems availability, health and stability.

Lastly, Houdini employed the concept of continual improvement to his performances. He was not satisfied when he mastered a particular escape. Part of his genius was in recognizing that he could push the envelope further, be more daring and dangerous. And this is how he became an international star.  Often his “new” escapes were nothing more than a combination of things he had already mastered, with just a new wrinkle or different angle explored. Again, this is similar to you maintenance plans. Once mastered, you can re-evaluate them on a regular basis to see if there are new methods, technologies, or partnerships out there that could provide further economies or better results.

This all sounds good, but what if you are already behind? Houdini had an answer for that one too.  Occasionally, he would be put on the spot and asked to escape from something without prior knowledge or an ability to research or plan. Yet, most often he was still successful.  How?  Well, because he was never truly surprised. Even if he did not know the request was coming, he was prepared if it did.  And that also applies to maintenance. Create a mindset where all aspects of IT change include a maintenance component. Consider maintenance as critical as the initial implementation or upgrade. What will be the impact?  Can I leverage my current process and tools?  Will it extend my maintenance windows?  In this way you can stay ahead of any challenges to your maintenance procedures.

Proactive maintenance isn’t fun, and it won’t make your career.  But it may help you avoid being “handcuffed” in supporting your organization’s objectives and from being “buried alive” by a backlog of deferred tasks and operational impacts.

 

To hear more on this topic from Geoff, download his recent webinar where he goes into more detail around deferred maintenance. 

By Geoff Smith, Senior Manager, Managed Services Business Development