CIO — Consultants and contractors can provide specialized technical or business expertise, additional bodies to help lift an IT project's immense weight or—at worst—another bucket to bail water out of a sinking ship. However, most CIOs and IT managers have horror stories about consultants gone bad: consultants who didn't deliver what they promised on time, gave bad advice, fought with (or fraternized with) the full-time employees. Usually, these problems result from a lack of understanding between the two parties and their divergent business interests. Surely, someone has advice to share about how to get the most out of consultants and contractors?

Settle down and get comfortable, as you're about to get a load of very frank feedback. In several online forums, CIO.com asked these IT service providers what one thing they wished IT managers understood about consulting and contracting. This article presents their most fervent desires, including technology ramp time, project scope and long-term project planning.

In this article, I sometimes use the terms "consultant" and "contractor" interchangeably. Many practitioners make a distinction, however. Generally, a contractor is someone hired on a short-term basis (such as three months or to finish the Web forms) and works on a very specific project. Consultants often have more latitude, examining and enhancing systems or processes rather than an individual application. They're also paid differently. Contractors are billed by the hour. Consultants submit invoices per project.

1. Be aware of—and honest about—the reasons you're bringing someone in.
Many managers imagine that their motivation in calling a consultant is purely technical: The application is broken, the server is hiccupping, the project is late. Savvy managers—and experienced consultants—know better.

"Almost every problem that I've been asked to solve has, at the core, been a people problem, not a technology problem," says David Moskowitz, principal consultant at Productivity Solutions in Bala Cynwyd, Pa. "Even if the immediate symptom appears to be a technology problem, someone made the decision to adopt, purchase, code/implement, create the schedule, include (or exclude) a requirement, include the wrong stakeholders, exclude the right stakeholders, didn't consult the stakeholders, etc."

And that's how conflicts between IT managers and consultants arise: The CIO or IT manager thinks the problem at hand is technical, and so hires consultants to solve a technology problem. But when the issue is one of personalities and politics, a consultant can't do much about it. The consultant's business is service, so he wants to help (and to make some money); he does his best, but really can't solve the core problem. Six months later, the problem hasn't gone away and the IT manager has much less money in the budget. Tensions flare.

IT service providers advise IT leaders to get clear on the problem at hand, why they're bringing in consultants, and what kind of consultants they need. Independent consultant David Cressey says CIOs must understand the difference between seeking a contractor or consultant for staff augmentation versus adding expertise that isn't part of the company's core knowledge set.

There are legitimate reasons for both endeavors. But, cautions Cressey, the two situations affect the way you vet the agency and the individual consultant, the terms and conditions you should seek, and the amount you should expect to pay. "If you don't know which you are doing, you are likely to either pay too much, or hire a person or an agency that just isn't up to meeting your needs," he says.

Continue Reading