Horse Sense #64
In this issue:
Happy Birthday to us! Iron Horse is now 17 years old!
The Law of Unintended Consequences
Microsoft put out a patch to plug a security hole on April 3, 2007. However, that patch caused an audio driver to fail. A patch to patch that problem was issued the next day. Adobe has a patch manager that isn't compatible with the new IE7. In our case, the patch management program would never connect to Adobe, but flooded our network with its attempts (which we would never have seen but for our Cymphonix Network Composer. Even something as simple as fixing Daylight Savings Time wasn't so simple. Most of the machines on our network took the update from Microsoft just fine. Some older machines and non-Microsoft equipment had to be manually changed. One Windows XP machine "updated" but never changed to the correct time and running the update again wouldn't fix the problem. It had to be manually changed.
We managed to fix all of these problems in relatively short order, but these patches clearly demonstrate the Law of Unintended Consequences: when you fix something, you may break something else or change its behavior without realizing it. We test lots of security and networking devices here at Iron Horse and find that this law is alive and well. It can be especially hard for companies to test their products in real world environments, and many software products are released with little real testing to meet customer demands for new features.
What can you do to protect yourself against the Law of Unintended Consequences? Give yourself time to deal with the unforeseen. Test exhaustively. Try to buy stable products. Only buy on the bleeding edge if you must have those capabilities. Deal with someone you trust and can work with for the long term. Don't look for products and services. Look for the whole solution to your problem.
Buying from an experienced value added reseller (VAR) of a product is better than buying from the manufacturer. Buying from a VAR/consultant like Iron Horse has many advantages (see Horse Sense 55, http://www.ih-online.com/hs55.html).
Avoiding Costly Computing Errors
Use these tips I've learned from over 20 years in as a computer consultant and dealer when working with your IT providers to save money, time, and grief. If you have a favorite tip or story, please write us about it!
Pay Attention to Return on Grief (ROG)!
Total Cost of Ownership (TCO) and Return on Investment (ROI) are popular business terms, yet in the real world they can mean almost nothing. A better intuitive metric that even works in situations where there is no obvious ROI, like adding security to a network, is Return on Grief (ROG). Once you start thinking in terms of grief, you start thinking of more than money. To do something new, you don't just need a new piece of hardware. You need supporting hardware, software, space to put it in, electricity, time and expertise to install and configure it, time and expertise to manage it, training on its use, allowance for disruptions in your work flow, etcetera. Start looking at what you want as the end product. Think about the obstacles you might have to surmount. Then talk to your salespeople and consultants about how to get there. A large percentage of well intentioned products fail because "soft factors" are ignored. If people don't support the solution, know how to use it, get support and incentives to make new processes work, etcetera, your project will eventually fail. Scope creep, or trying to please everyone, ends up destroying many projects. Put someone in control and give them authority. Encourage them to say "no" to scope creep. Encourage them to listen to all stakeholders and involve them in the process. Pay special attention to how people will be using your new computer solution, because computers are only a tool to get work done, and if users can't use tools correctly, the results will be poor.
Soft Factors Count More Than You Think!
Sometimes I think as Americans we think that a new technical fix or law will solve a problem. Real problems are almost never solved this way. This is also why so many projects fail. Organizations need to look at ROG more closely. Most projects don't fail because there is something inherently bad about the technical fix. They fail because of soft factor breakdowns in policy, procedure, goals, standards, notification, implementation, training, expectations, management, and follow up. If you (a) don't know why you are doing something (policy), (b) don't know the steps you need to go through to get results you want (procedures and goals), (c) don't know the inputs and outputs you expect (standards), (d) don't tell people what you are doing both inside and outside the company (notifications), (e) don't know how to properly install and configure your solution for your organization(implementation), (f) don't know how to use it (training), (g) don't realize the limitations (expectations), (h) don't provide accountability, authority, and consistent support (management), (i) and don't analyze what you've done and refine it further (follow up) your solution will be substandard.
Case in point: A major government agency was greatly concerned about its network security. They needed to show the courts that they were doing something about their security problems, so they bought 13 firewalls from us with maintenance agreements. One year later, we called back to renew the maintenance agreements. They didn't want to renew them as none of them had been installed. They didn't have anyone to install or configure them and no one wanted any downtime on their networks. They filled a check box on someone's list to acquire better security. Instead, they lost money and time and delivered false confidence to others. Later security breaches pointed this out.
The lesson? Money isn't the only factor that goes into a project. Look at what you truly want to achieve and take into consideration the non-monetary factors that will get you there. If you can't make it there, stop and save your money. If you can make it there, then you will have a very positive Return on Grief.
Case in point: A company bought a Barracuda Spam Firewall network appliance from another reseller to filter out spam and viral messages before they went into user inboxes. Months later they called the manufacturer to complain that the box wasn't effectively blocking messages and took an inordinate amount of time to manage. Iron Horse was called in to troubleshoot the problem. They had set up the box to use its least effective spam fighting techniques. They also had some incorrect network settings that made the situation worse. They did not have clear policies, procedures, standards, goals, or notifications in place. They had no help with the original implementation. They had no training on or experience with the product. They, and their management, didn't know what to expect out of the product. Management criticized their technicians actions and results, but did not give them strong support and direction. The technicians were feeling blamed and demoralized. Once Iron Horse's changes were implemented, the detection rate skyrocketed, fewer messages were incorrectly identified as spam, users got much happier, and the time spent babysitting the appliance went from hours and hours per day to minutes per week. However, many of their soft factor problems remain to plague this and other projects.
The lesson? Take into consideration all of the soft factors involved in a project and it will be successful. Realize that many soft factor problems will crop up with every project, but that some can be improved if they are directly addressed.