|
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.
|