Skip to main content

Panic..Panic..Panic..

Here I am, a day late with my blog, and I haven't a clue what topic I will write about. (Or at least that's what I want you to think.) Yet here I am.

British Petroleum has found out the hard way what the consequences are of not having all of your contingencies accounted for prior to finding out that Murphy is going to hit you where you are weakest. (There's no need to add a link there, since you can throw a stone and hit 20 news websites with articles on the Gulf disaster.) I have also discovered this on a few occasions - most notably this week with my blog (see? I wasn't necessarily fibbing after all) - and I can assure you that losing control of the situation is never fun, especially when the situation wasn't fun to begin with.

My wife says I have "control issues." I counter with the statement that I simply don't like not knowing what to expect.

In ITIL (which is, for those of you who aren't familiar with it, a collection of business processes that have been refined over the years so that businesses can get the most of their investment in IT), Business Continuity is the collection of processes that help you recover from a calamity of any sort. In my own words, there are five primary parts to this.

Develop your recovery plan. When 9/11 occurred, Morgan Stanley very quickly had their operations moved to another facility before the stock market opened that same morning. This quick turnaround time would not have been possible if they hadn't already determined what their recovery plan was.

Document those plans. Another key component is writing down every detail around your recovery plan that is necessary. The litmus test for the effectiveness of the documentation is in the answer to this question: "could someone fresh out of college read these plans and get our business up and running in a relatively short time?"

Be prepared. Morgan Stanley moved to a base of operations on Varrick Street, something that would not have been possible in the short time period if they had not already established this location as a backup center for their operations. I don't know the specifics of the equipment that was already in place before 9/11 but you can easily imagine that they had enough IT assets (including computers, phone lines, etc.) to resume critical business operations with the "turn of a key."

Practice your plans. Disaster Recovery, as it is sometimes called, requires quick execution to prevent (to the greatest degree possible) loss to the business (whether revenue, customers that go to competitors, etc.). This requires that everyone knows their role in such a situation and can simply execute their role with little direction.

Refine your plans. IT is not a static operation. With many moving parts, it is constantly changing as new technologies are incorporated into the business. Periodic review and refinement of your recovery plans is a necessity to ensure that they are in lock step with the current state of the business.

Here's the "big deal" moment. While this all sounds like something that many of you will not have to deal with, a "personal recovery plan" is still an essential component to any successful professional. More specifically, I will make the claim that there are many variables in the business world that make navigation a treacherous activity at times. Corporate politics, the effect of the economy, changing management, etc. can all have an effect on your ability to evolve in spite of the fact that you may be the best at what you do.

Consider the following (with specific names removed for obvious reasons): at a large company last year, the head of a particular division was laid off in spite of the fact that they were quite good at their job and were well respected by everyone reporting to them. The reason, they were told, was that there was someone in their organization that could do their job (although they didn't have benefit of nearly two decades of experience like this individual had) with almost the same level of proficiency but at half the cost. The loss of expertise / experience was more than made up in the salary savings the company experienced. What did this person do wrong? They fulfilled their responsibilities quite well, but at the end of the day it became a financial decision only.

So what is your backup plan? Do you even recognize the need to have one? Once you have this on your radar, you will easily see the benefits of extending this concept to even the finer details of your professional life. Questions such as "How do we continue moving this deal forward if we lose John's sponsorship of our product?" or "How will our [cyclical] business continue to survive if this economic downturn lasts longer than expected?" will be easier to answer with a little forethought and proper planning.

Popular posts from this blog

"Ni jiang yi yang de hua ma?"

Last week, I wrote about the necessity of having a clear message . Because this topic is so important I decided to follow-up with another entry on this general subject. This week we will approach it from another angle. (For the curious, the title says " Do you speak the same language? " in pinyin, which is a transliterated Mandarin Chinese.) Recently, a good friend of mine (who is Chinese, ironically) and I were playing pool. He had to bank the 8-ball in the pocket to win the game, and since it was an informal game and bank shots are my area of expertise, he asked me for advice. I told him, "you just need to strike the cue ball with medium speed so that it hits the 8-ball right in the middle." He didn't believe me so we marked the positions of the balls, and then he took his shot only to watch the 8-ball sail past the pocket. "A-ha!" he exclaimed. "I told you it wasn't that easy." But when we reset the positions and I made an attemp

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While that

Is No/Low-Code the Key to IT Nirvana?

 Unless you've had your head in the sand for the past year or so, you've seen the phrases low-code  and no-code  bandied about quite frequently everywhere you look.  You've probably wondered if this is something new that's here to stay or just a "flash in the pan."  Although the terms have been in the fore of the IT trade publications recently, Low Code Development Platforms (LCDP) (and the corresponding No Code Development Platforms) have been in existence since 2011.  Their roots can be traced to the 90's with 4th generation programming languages and GUI-assisted programming paradigms, e.g. IBM VisualAge for Basic, which was discontinued in 1998. For those of you who aren't familiar with either, the premise is that these platforms allow someone to quickly build applications using a WYSIWYG interface and a "click and configure" paradigm to Isn't this the source code to Roblox? rapidly build full applications with little or no coding requ