Sunday, December 19, 2010

Implementation is More Important Than Product Selection (Part 1 of 2)


Far too often, I see IT professionals invest a significant amount of time evaluating products for a specific solution. Vendors are drilled on the capabilities of their products. Engineers fire off questions they hope will make them look smart in front of their bosses and point out holes in the vendors' solution; “So, you're saying your firewall appliance doesn't support an enterprise wide CORBA bus!” Never mind the engineer knows perfectly well they're company doesn't have a CORBA bus, doesn't plan to use such an architecture, and nobody else does either. Demo units are brought in, tests are haphazardly conducted, the field is narrowed to top industry leaders, fiscal year-end concessions are made by a vendor, someone goes on a golf trip, and finally; a product is selected.

After five months of meetings and evaluations, the money has been spent. Management wants the shiny new product in use immediately. “We didn't spend blah dollars on this solution to have it sit around on a shelf. We need it in production now!” Because the local folks aren't experts yet, the vendor supplies a professional services contractor (probably a sub contractor from one of their resellers) to “install, configure, and perform knowledge transfer” with the team.

The PS guy shows up and is guided to the conference room that's been reserved for the whole week so the team can watch and learn how to perform installation, configure the device, and receive knowledge transfer. Four hours into day one, the local folks are pulled off to fight some IT fire. The PS guy forges ahead, begs for business requirements, completes the work as best he can, writes up some documentation, and flies out early on Friday.

The implementation is finished.

At this point, the company relies heavily on a piece of equipment their own people don't understand very well. The device is in the critical path of business operations; therefore, it's “hands off!” Changes are approached timidly with fingers crossed instead of confidence. Over time, the poor understanding leads to unintentionally poor configurations. The device begins to act unexpectedly. It begins to develop a negative reputation because it's “unstable” or “unpredictable” or “doesn't support feature x”.

Of course, nobody suggests it's being managed poorly -that the people don't know what they're doing. That might hurt somebody's feelings. Besides, they know they have good people. The folks have a good attitude, work long hours, and put out a lot of fires. “That piece of junk is causing us all kinds of headaches. It needs to be replaced!”

And the whole cycle starts over again...

Next Post: Is there a better way?