Murphy’s Law states that If something can go wrong, it will. It dates back to 1949 and was forged at Edwards Air Force Base in California. Since then, this law has been widely evoked in the IT world, like a mantra.

Captain Edward A. Murphy was an engineer working on a project to test how many sudden decelerations a human being could sustain in an accident. Legend has it that Captain Murphy blamed one of his technicians for the faulty wiring of a transducer, saying of him: If there’s a way to do something wrong, he’ll find it.

Since then, Murphy’s Law seems to arise so often in IT that computer scientists should have some reflexes to deal with it. Here are 10 examples of the manifestations of Murphy’s Law in the IT, and suggestions for dealing with them.

1. Your PowerPoint presentation to the Steering Committee does not work

Leading companies present their products and strategies with PowerPoint. And a lot of times it doesn’t work. This is particularly awkward when it is the CIO who presents his IT strategy (and the budgetary needs that go with it) to the board of directors.

To deal with this specific manifestation of Murphy’s Law, always keep a manual adjustment of your slides handy. This allows the presentation to continue and your audience (who have probably been victims of this type of incident themselves) will retain their sympathy for you.

2. A major project depends on a contributor… who has influenza

This is a tricky Murphy’s Law scenario, but you can reduce the inconvenience by relying on the project documentation, making it easier for someone else to take over the project’s continuity.

It is also possible to keep a few reliable consultants up your sleeve to call on at the right time. Please also include contingency planning in your projects to identify who is critical and what you will be able to do without them if this happens.

3. Someone produces the wrong version of the software patch, and the application crashes

You think your software management methodology is foolproof… But when Murphy’s Law gets in the way of downloading a software patch, it can stop the application while proving you wrong.

The best way to solve this problem is to quickly get in touch with the users of the solution and alert them to the presence of a technical problem. Then uninstall the wrong patch, and upgrade to the correct version. A post-mortem examination to assess how the error occurred and how you can improve your process in the future must follow.

4. Datacenter is flooded

You are not in a flood zone and it only rains 10 centimetres of water per year in the area where you live. Nevertheless, Murphy decides to flood your data center with an unexpected monsoon. Or water from the internal cooling system invades your servers.

Here are two cases where the prior development of a disaster recovery plan comes into play. If you can switch your operations to another location, or even to cloud services, this is preferable, rather than putting all the eggs in the datacenter in the same basket.

5. Your digital champion leaves you

Negotiating with purchasing on IT issues has always been a delicate exercise, but as long as Jean-Paul was there to plead the users’ case, you could move forward. Now that Jean-Paul has won the Euromillion and is moving to Tahiti, you are alone with uncooperative, even hostile interlocutors.

The best approach is to contact the purchasing manager immediately, preferably over lunch rather than in a formal meeting (you could even invite him/her). The idea is to take stock together of the difficult history of your relationship, consider a new working relationship, and move forward.

6. You have tested all the apps in a software suite except one that is rarely used. And she’s the one who brings down the server

Application suites should never be put into production until every application and sub-program is thoroughly tested. But when deadlines are immediate, project managers are known not to test or have tested the apps they consider minor. In order to meet the tight schedule. They make these decisions by measuring the likelihood that an application will or will not be used. If the answer is “rarely” or “probably never”, then they will not check the entire suite.

That’s when Murphy comes in. An end user defies all predictions by using this application, the application crashes, and the whole system crashes. The best way to avoid this situation is to request an extension of the application delivery date to allow for extensive testing. If your end users absolutely refuse to grant a new date, or if there are business circumstances that leave you no choice, alert stakeholders and users of the situation so that they avoid using the untested application until you have the opportunity to close the project.

Another good practice, which will depend on how the software delivery is architected, is not to deploy the suspect application during the initial deployment and add it later, when it is ready for production.

7. Your supplier is absorbed by one of your former suppliers, with whom you are angry

Changing IT providers is painful. That’s precisely why you try to avoid that, unless there’s a radical change in pricing or in the proposed technology. Or that the relationship with your salesperson becomes so acrimonious that you no longer want to collaborate with him or her. When this happens, you make your little deal to find a new supplier. Unfortunately, two or three years later, Murphy may show up, and this new supplier may be absorbed by that acrimonious former supplier. Your business is stuck again.

The best way to protect yourself in this situation is to write a change of direction clause in your contract with the new supplier. This clause will specify that if there is a change of management at the supplier, you will be able to terminate your contract.

8. Your supplier contact leaves his position

This Murphy scenario happens all the time. One of your suppliers is absorbed by a larger structure. And heads are falling, including that of your sales contact with whom you have established a solid relationship of trust. The replacement proves to be incompetent, and much less positioned in the company hierarchy to have the latitude to negotiate contracts as before.

You can avoid this situation by stipulating in your contract with the supplier that you reserve the right to approve and accept contact changes on suppliers’ customer accounts.

9. The result of an online marketing campaign is much more positive than you imagined

Your marketing manager is amazed at how quickly a product sold in your online store is adopted. In fact, order taking explodes your order processing system. Unfortunately, you have undersized your processes and storage, based on your history. Your customers are seeing that, too, and sales are falling off. In short, the marketing campaign is turning into a Murphy nightmare. How can we avoid such a situation?

One way to be prepared to put additional resources in place if your operations are not successful is to provision computing, storage, and network to cloud providers. These resources can be consumed on demand and paid for out of the profits made on these fortunate sales increases, and then reallocated when demand decreases.

10. Your cloud provider crashes

You put a critical system in a provider’s cloud because it has a reputation for reliability. Then the seller fails to deliver the service correctly, causing your users to log off. This obviously has a catastrophic impact on the company’s business.

Here you can bypass Murphy’s impact by developing relationships with multiple cloud providers. So that you can switch to another supplier if the first one fails. Also, try to avoid contracting with cloud providers that do not have their own data centers.

(Source illustration: K.anh.eya.191 / Wikipedia)