Years ago, a vendor of a well-established vertical application flew me to their offices to get my recommendations on how they could update the "look and feel" of their application's user interface. I spent a day talking with their programmers and looking at their existing code, as well as finding out from their salespeople what their customers and prospects wanted. At the end of the day, the President called a meeting with all of the people involved to hear what I had to say.
My recommendation involved taking a path that I knew without a doubt would work well for their case, but it would take quite a bit of code modification. Nevertheless, the task was easily quantified, so they should have been able to plan out the project pretty reliably. The programmers didn't object to the amount of work involved, yet they protested, "We'll all have to learn this new technology!" as if that were fatal.
It occurred to me to ask why they hired a consultant if they didn't want to learn anything new, but I refrained. Apparently, they expected me to fly in like Tinker Bell, sprinkle pixie dust over everything, and send them soaring on their way to Neverland without so much as a pilot's license.
Dealing with an innovation impasse
Have you ever run into this kind of tension between the client's desire to move forward vs. their discomfort with having to adopt new practices and learn new technologies?TechRepublic member Glen Ford, a frequent commenter in the IT Consultant blog, reports that in his area the requirements for obtaining an engagement often involve knowing existing practices and sticking with them. If the client is just looking for someone who can do what the client has always done, do they really need a consultant? Consultants are supposed to provide insights into the wisdom of adopting different strategies, but in this case, it sounds like they've got the strategy all sewn up. Maybe what they really want is mindless contract labor.
Many times I've seen software companies whose goal was to remove the need for brains when developing software — and I suspect the same holds for running an IT department. It comes from lofty motives — you should want to standardize to insure consistency and automate repetitive tasks where possible (that's what computers are for, after all). But when you go too far with that goal, you lock out innovation. Riding along the monorail of "how we've always done things" you can build up quite a head of steam — until something goes wrong and you can't change directions quickly enough.
Finding a balance
If your client is in a highly competitive market, they may need to evolve at a pace that is uncomfortably rapid. On the other hand, a company with a captive user base may not need to change anything until right before their users figure out an escape plan. If you try to move your client forward too quickly, they could get in over their heads and the project could fail. If you try to move your client forward too slowly, they could fail to meet their objectives. Both you and the client need to weigh the potential benefits and risks associated with the options before you. But first, you must dispel any notion that you can just work your magic without any effort on their part.
A happy ending
What happened with my client, you ask? After I reiterated the reasons for my recommendations, the President said, "Let's do it!" He then engaged me to help train his staff and to write examples and utility functions to get them started. The project was a huge success, and they remained my active client for several years. The programmers (who had been the most vocal opponents of change) became excited about the new technology once they were given the time to learn it. Programming was fun again, and their resumes looked better too. Soon after the new product shipped, they were able to absorb their toughest competitor. Many of those involved remain my personal friends to this day.Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.