Murphy's Law ("If anything can go wrong, it will") originated in 1949 at Edwards Air Force Base in California. It has been a widely invoked mantra in IT circles ever since. The law was named after Captain Edward A. Murphy, an engineer working on an Air Force project that was designed to see how much sudden deceleration humans can stand in a crash. As legend has it, Captain Murphy came across a transducer that was incorrectly wired. He grumbled about the technician he held responsible, saying, "If there is any way to do it wrong, he'll find it."
Since Murphy's Law seems to crop up so often in technology, all IT'ers should have some Murphy coping mechanisms in their bag of tricks. Here are 10 modern manifestations of Murphy's Law of Failure in IT—along with suggestions for how you can manage your way through them.
1: Your PowerPoint presentation to the board fails
The most elite of companies have delivered PowerPoint presentations on their products and strategies, only to have the presentation technology fail. This is especially embarrassing if you are the CIO and you're giving a PowerPoint presentation on IT strategy (and budget needs) to your board of directors when such a failure occurs. For this particular Murphy manifestation, always keep a manual set of your presentation slides on hand. It keeps the presentation going and your audience (who have probably been on the victim side themselves) will be sympathetic.
2: A major project depends upon a single contributor... who gets the flu
This can be a difficult Murphy scenario, but you can make it less so by insisting on project documentation (which enables someone else to take over more easily) and by maintaining a cadre of reliable and highly skilled outside consultants you can call upon when you need them. Also be sure to include contingency planning in all your project plans so you can identify critical people (and what you will do without them if you have to) as well as critical task paths.
3: Someone loads the wrong software patch or release and the system fails
You think that your software management methodology is ironclad... but then Murphy loads the wrong software patch or release to bring down the system and prove you wrong. The best way to deal with this is to immediately get in touch with your users, alert them that there is a technical problem, back out the erroneous patch or release, and reload the correct one. A post mortem review to assess how the error happened and how you can further improve your process in the future should follow.
4: The data center floods
You're not in a floodplain and the area you live in gets only 10 inches of rain per year— but somehow Murphy decides to flood out your data center with an unexpected monsoon—or the water problem originates internally from a fault in a cooling or plumbing system. This is where a strong disaster recovery and failover plan comes in. If you can immediately fail over your operations to another data center location, or even to a cloud-based version of your data center, it is better than putting all your eggs in one central data center basket.
5: Your champion user in a key business area leaves
It's always been an uphill battle to deal with your purchasing department when it came to IT services, but as long as Freddy was there as your user advocate, you could push through new IT initiatives. Now Freddy tells you that he has won the lottery and he's moving to Maui. You face an uphill road with a group that (except for Freddy) has been uncooperative and even hostile.
The best approach is to immediately get in touch with the department manager, preferably over lunch or some kind of venue that is more relaxed for a meeting. The two of you should face head-on the difficult issues that have plagued your relationship in the past and figure out a new working relationship you can both buy into.
6: You've tested every app in a software suite except for one that is rarely used—and the app blows up and brings down the system
Application suites should never be placed into production until every app and subroutine is thoroughly tested. But when hard deadlines arise, project managers have been known to make calls as to which apps they feel they can "let go" to meet the fixed cutover date. They make these decisions by weighing the risk of how much an app is likely to be used. If the answer is "seldom" or "likely never," they might opt to skip a thorough checkout of the app to meet the cutover date.
Murphy steps in when an end user defies the odds by using the app, the app fails, and it bring the entire system down. The best way to avoid this situation is to request a revision of the application delivery due date to allow for thorough testing. If your end users absolutely refuse to look at a revised date, or if there are business circumstances that are so immovable you're left with little choice, alert stakeholders and users to the situation so they will avoid using the app until you have the opportunity to complete testing. An even better practice, which will depend upon how your entire software delivery is architected, is to leave the app out of the initial deployment and add it later when it is ready for production.
7: Your vendor gets acquired by a former (and hostile) vendor
It is painful to change IT vendors. This is precisely why you try to avoid it unless a dramatic change occurs in pricing or technology—or a relationship with the vendor become so acrimonious that you no longer want to partner with them. When the latter occurs, you go to the market to look for a new vendor. Unfortunately, if Murphy steps in one or two years later, and the new vendor gets acquired by your former vendor, your company is stuck again.
The best way to protect yourself in this situation is to write a "Change of Management" clause into your contract with the new vendor. The clause will state that if there is a change of management at the vendor (such as the vendor being acquired), you have the right to terminate your contract.
8: Your key vendor account person leaves
This is a Murphysism that happens all of the time. A company gets sold on a new IT offering. Part of the appeal is the friendliness and knowledge level of the account rep from the vendor who is assigned to onboard the company onto the new solution. Unfortunately, as soon as implementation is complete, this stellar rep from the vendor is replaced with a new rep who isn't as knowledgeable or as helpful. Especially if you are embarking into a new IT area, it's vital that you have a strong relationship with a single contact at your vendor who is both knowledgeable and friendly-responsive. You can avoid being passed off to a lesser rep by stipulating in your contract with the vendor that you reserve the right to approve and accept any account rep appointments/changes.
9: The response to an online marketing campaign is greater than you had ever imagined
Your marketing manager is amazed at the rapid uptake of an item you're promoting in an online sale. In fact, the number of new order transactions hitting your order processing system is unparalleled. Unfortunately, you sized your processing, storage, and communications resources in this year's budget based upon historical usage data. Your customers are seeing this, too, as they are abandoning transactions because the system can't keep up. Alas, the marketing campaign is beginning to turn into a Murphy nightmare. How do you avoid a situation like this?
One way to be ready with extra resources for good news events is to provision additional compute, storage, and communications from cloud-based vendors. These resources can be purchased on demand and paid for with the increased revenues from the promotion, and then deallocated when the sales demand has passed.
10: Your cloud vendor fails
You consign a major system to a cloud-based vendor because the vendor has a reputation for being reliable and best in class—then the vendor has a failure that puts all your users offline and has a dire impact on the company's business. You can sidestep the Murphy fallout in this situation by developing relationships with more than one cloud vendor so you can effect a failover to another vendor if one goes down. Also, try to avoid entering into IT agreements with cloud-based vendors that don't own their own data centers. You have no leverage with the third-party data center provider your vendor is using.
No comments:
Post a Comment