Blue Dragon Consulting

These days everyone in IT is a consultant, employs a consultant, or both. I'm a consultant, aren't you? Outsourcing, offshoring, LEAN management, a lousy economy, and covering one's IT butt have led organizations of every type and at every level to look outside for answers to their IT questions and often even to ask those questions in the first place. This has led to the greatest disconnect I have seen between job requirements and apparent internal capability in the 30 years I've been around IT. It's scary. Hardly any organization can get by without using consultants and -- here's the bad news -- most consultants aren't very good. So here is my advice on how to select and use an IT consultant followed by a grim list of the 10 most common lies told by bad consultants.

What led me to write this column were the troubles of a local company here in Charleston -- American LaFrance, the storied maker of fire engines. American LaFrance was last year spun off from Freightliner, the big truck manufacturer, which agreed to maintain the company's computer systems for a few months while the new American LaFrance bought its own systems with the help of a big IT consultant that rhymes with I-B-M. At the time of the cutover the project was months late and millions over budget. The company suddenly had no idea where it stood in any part of its business and today is in bankruptcy likely as a result. The company is close to failure probably because a consultant didn't perform as it promised. The consultant didn't perform as it promised most likely because there was no way to do so and still make money on the contract, which was underbid.

Who does YOUR IT consultant really work for?

So here's my guide to the various types of consultants, what to look for, and how to get the most good and the least bad for your money.

There are generally three types of IT consultants, which I'll simply label A, B, and C.

Type A consultants are hired to do a specific thing -- set up an email system, design and install a network, put in a POS system, etc. Usually the customer knows what they want before they find a Type A consultant to hire.

Sometimes a customer does not know what they want. These customers start with a Type B consultant who is supposed to help them think out of THEIR box, develop an improved business or IT vision, etc. In the early days when finding ways to improve things was easier, good consultants came to a new customer armed with benchmark data. They could look at a company's various departments and give some good guidance on what areas needed work. They'd tell a customer they were spending too much or not enough on xyz. One of the biggest roles of this type of consultant was to help sell the eventual plan to upper management and secure funding.

These days it is doubtful that most Type B consultants can provide any good ideas. They are mostly expert at being salespeople. The solutions they offer are often what their firms have to sell -- not necessarily what the customer actually needs. This can get exciting when it comes time to implement the project, as Type B consultants tend to be very poor project managers. They don't fully understand the technology they are selling so overruns are common.

There is another class of consultants that are mostly project managers, which we'll call Type C. These folks are brought in as contractors to help implement a given project. The good ones are like Attila the Hun and can get things done even in a very uncooperative environment. They don't care about making and keeping friends, just getting the job done. This is both good and bad. Good project management is important, but equally important is the environment. Getting Attila may be a case of treating the symptom and not the problem. Why is it so hard to get things done in your company? Could that be what is really holding back your business?

Far too often projects fail at the requirements phase. That was most likely the case with American LaFrance. The new organization was probably incapable of setting its own requirements and the consultant didn't help.

The next common problem in managing both IT projects and the consultants who usually do those projects is scope. Projects are often too grand by design or by default due to a lack of requirements. In either case you don't know you've bitten off too much until it is too late. This causes many problems and often destroys the ROI value of the project.

Remember that more than 50 percent of big IT projects fail completely with an ROI of zero percent, so while succeeding is good, not failing is even better.

The best consulting efforts are the ones that take a long hard look at the ROI and have a proven track record of making it happen.

The best consultant I ever knew was Christine Comaford-Lynch, who is now an author and a VC and no longer does IT consulting at all. A key part of her success was her requirements gathering process. She turned it into a very effective collaboration effort involving the key people who would use the software. The requirements would be tight, the project would be highly focused, and there would be little or no scope creep. When it came time to implement the project her project managers didn't have to be Attila's -- there was cooperation and enthusiasm. The training and start up of the application was quicker and easier. There were few surprises that needed to be fixed.

The Holy Grail of IT has long been the convergence of applications and databases into a unified environment where everything would work together. The original hope was to use relational databases and base all future applications on them. Next was the ERP wave. Talk about a huge and expensive effort! Putting in ERP was like a Borg invasion. Today we have SOA, which is even more complicated and expensive code that is supposed to be the glue between disparate applications and databases. Most of these approaches follow the classic computer industry business model -- make the customer spend lots of money and invest in lots of consultant time.

There is an easier way to do this stuff. The best consultants are the ones who come with a portfolio of products and tools. Their trick is to have a really good portfolio of stuff that really works, is really good, and can be sold and implemented quickly in a very cost-effective way. So it isn't necessarily a bad thing at all when a consultant offers to sell you tools, as long as they are the right tools and the consultant really knows how to use them.

What's key to my simplified concept of IT consulting is adapting a limited number of very robust and proven products and to do it all in a reasonable amount of time. Having fewer choices is vital because many companies will spend months or years making a decision. And some consulting firms will bill these clients a small fortune as things drag on.

Now to the 10 most frequent lies told by IT consultants. When you hear these lines spoken you have two alternatives: 1) fire the consultant on the spot, and; 2) bring your smartest and most crotchety nerds into the room and make the consultant explain his or her statement to their satisfaction then back it up with some performance guarantee and penalty clause.

1) "This can only be accomplished through a large custom development project."

2) "Of course your data is safe."

3) "We'll need a day or two for optimization and debugging."

4) "Yes, we've done this before. There are several companies using this product (or technology). They really like it."

5) "Server consolidation and virtualization will save you money."

6) "Storage consolidation and virtualization will save you money."

7) "The upgrade (or change) will be seamless and will not affect production."

8) "The upgrade (or change) will be transparent to users."

9) "Yes, we tested this thoroughly before installing it."

10) "If you install Tivoli it will solve all your support problems."