Consultant canons
CTOs should know how to use consultants, but it’s a long way from lip service to implementation
I’VE SPENT A lot of time in recent weeks thinking about the role of consultants in IT and business in general.
Every CTO has one and usually several stories about an enterprise software product or custom integration project that began with a slide show that pushed the very limits of PowerPoint. The solution looked good in the demo, all business and technical questions were answered satisfactorily during the sales process, and the sales engineer was sharp and seemed to get it. Everything seemed perfect and the deal was inked.
Then the project failed miserably and everyone was left scratching their heads. “What did we do wrong?” they wonder. It’s usually not as much the consultants at fault as it is the company’s rationale for hiring them in the first place.
Whereas patriotism is the last refuge of a scoundrel, as Samuel Johnson said, hiring consultants can be the last refuge of an ill-prepared strategist. The problem is that with the tight economy, very few companies selling consulting services are willing to tell you that you are not ready for them yet, so you have to figure that out for yourself. Working with consultants and professional services teams in various projects has taught me a few lessons, from which I have developed a few rules.
First, don’t let the consultants come on site until you’ve figured out what you want them to do. Some of you are thinking, “Of course you don’t bring consultants in without figuring out what you want them to do!” But it happens all the time.
The story usually goes like this. An important but somewhat nebulous project comes along and existing staff are too busy to free themselves from their usual operational tasks. But the project is deemed so strategic that it must begin immediately. An executive finds and sponsors a qualified consultant who will get the project moving and optimism abounds — the consultant will save the day.
Then the consultant arrives and immediately has trouble getting busy executives to define exactly what is supposed to be done and why. Several weeks and thousands of dollars later, nothing has happened, the goals of the project remain nebulous, and the consultant mysteriously disappears — which leads to my next rule.
Don’t hire consultants to own your basic business strategy. Conventional wisdom suggests that you should outsource functions that are unrelated to your core competencies, and I agree with that approach. At InfoWorld, we outsource the printing of the magazine and Web hosting, for example, both services that are purely operational.
But as I mentioned in the first rule, executives often go to consultants for strategy because they are too busy running the business. And I think that’s a mistake. Without the high-level and consistent participation of management, an outside consultant is fighting a losing battle and your business is, too.
Consultants should be hired to help execute business strategy, not to own it. Business strategy is the primary job of your company’s executive team, not high-dollar consultants with no long-term commitment to your business.
Lastly, don’t outsource innovation and risk to consultants. Consultants are useful in well-defined projects with clear goals and objectives, but true innovation and progress sometimes requires a little stumbling in the dark as new ideas are tested, discarded, refined, and tweaked.
This kind of experimentation is best done by in-house staff who have a fundamental commitment to the business. It is also more controllable from a cost standpoint and your staff makes any fundamental business change. Consultants can be a great resource, but you have to know when to use them, and most importantly, when not to.