Getting Clueful: Nine Things CIOs Should Know About Computer Consulting and Contracting

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.

2. Few consultants generate wisdom the first day.

Your company probably has an orientation process for new employees. They’re added to the All_Developers e-mail distribution; they’re introduced to people in other departments whom they might need to rely upon, and so on. But many enterprise IT departments drop a contractor into the office with no orientation whatsoever—either in assigning-a-desk logistics or in technology ramp time. Yet, management expects the consultant to offer brilliant suggestions on the first day, even though she’s had no introduction to the IT organization’s specific challenges or to the company’s broader business goals.

Consultant Brian Marick says it’s impossible to hit the ground running when no one has planned for your arrival. “The first half day or more of my week at their company is spent discovering that there’s no meeting room for an introductory session, no place to pair, a key person is out for a dentist appointment, no one’s downloaded tools yet, etc…. I’m not the only person whose time is being wasted,” he says.

Clients need to organize an onboarding process for consultants that’s similar to the experience for new employees. Management consultant John Lowe says, “I cannot make an effective contribution in a vacuum…. I need to get up to speed somehow on complex issues. I need data and inputs. Brief me. Dump data. Send me files. I don’t care how. Just recognize that the beginning [of the engagement] will be a learning phase. Pushing for solutions before I understand [the problem] just leads to mistakes.”

Let’s repeat that: Few consultants generate wisdom the first day.

Companies have unrealistic expectations of consultants because of a common myth, says Gloria Willadsen, a freelance UNIX and Linux applications developer. Since the consultant is an expert, the client believes she therefore does not have to do any research; she can just walk through the door, sit down, and implement the very specialized solution the company needs, says Willadsen. But, she points out, “A consultant always needs time to assess the problems and test the various solutions.”

When you brief a new consultant, include the big picture. Consultants believe they can do a better job for their clients when they are given insight into the purpose of the IT project as a business driver. Willadsen says many businesses believe that consultants have keyhole vision into the project, and can therefore only work on very specific, narrowly scoped tasks. This is not only false, she adds, but also leads to a self-fulfilling prophecy. “If you choose not to expose your consultant to the entire business model and all of its problems and intricacy, you debilitate your consultant and prevent them from making the best design and development decisions,” she says.

In contrast, the more transparent you are about your business with your consultant, the better able she’ll be to create more reusable, more versatile code, and the better equipped she’ll be to contribute to the creative process of helping your business model flourish, says Willadsen. “The more information the consultants have about your field, the easier it is for them to draw on their experience with tried and tested parallels in other fields. This will save you time and money on testing and prototype phase development and get you a better solution faster.”

3. If you hire a subject matter expert, pay attention to her advice.

Managers who don’t understand basic technologies are a nightmare for consultants to work with because they can’t articulate the problem that needs to be solved or the work that needs to be done. Everyone is best served when the IT manager has a teensy-weensy idea about the subject the consultant is hired to address.

Ignorance costs money, says Bob Reselman, an application architect and test-driven development evangelist in Los Angeles. He’s seen it firsthand. Reselman worked for a manager at a client company that believed that a significant, highly customized subsystem of its customer relationship management (CRM) system could be upgraded for $10,000 by purchasing an off-the-shelf package. In reality, says Reselman, even if the client could identify a package, the client would incur additional costs for integration and subsequent testing. “What seemed to be a simple $10,000 expense turns out to be much more. The C just didn’t know enough to understand the true costs involved,” says Reselman.

If you don’t know the knowledge domain, consultants urge, don’t try to insist on the right way to solve a problem, shove a solution down the specialist’s throat or decide how long the project should take. Don’t make pronouncements and estimations based on what may be very optimistic—or uneducated—assumptions. They’ll only come back to haunt you.

Another problem with technology-ignorant managers is that they are more likely to pull in consultants to do something that could be accomplished by someone already on the staff, says Der.Hans, an independent consultant who specializes in UNIX and free software system administration and development. And that’s a waste of money.

4. Think about tomorrow.

It may surprise you to realize that the people you bring in for short-term help give a great deal of attention to benefiting your company over the long run. They’re not all just in it (solely) for the money.

Before you turn to consulting as a solution, make sure that the external skills you’re acquiring benefit your company in the long run. George Dinwiddie, a solo consultant and coach with 20 years of experience in professional software development, owns iDIA Computing. He points out that a company’s long-term success is more likely to result from investing in its own capabilities, and any business that primarily depends on external help for core development functions will be left begging when times are hard.

“By all means, bring in outside contractors and consultants to help where needed, but bring them into your organization in such a way that your employees learn from them,” says Dinwiddie. “Those you bring in should not only increase your capacity while they’re there, but leave behind an increased capacity after they’ve gone.”

If you want the consultant’s solution to continue to benefit the enterprise long after the engagement is over, establish better lines of communication between departments. Lack of enterprise-wide standards and planning is the key irritation for Ish Singh, a systems architect and integration consultant who provides IT strategy and enterprise application integration (EAI) advisory services. He explains, “I have seen many organizations start multiple projects side by side without any interaction or knowledge sharing among the project teams and without implementing any common or enterprise-wide standards. In almost all cases, this results in duplication of effort and inefficient systems that are harder to maintain and do not work with each other.”

5. Scope creep is sometimes unavoidable.

Managers bring in a consultant when they want the specialist’s expertise in defining, implementing or fixing a project. Usually, the manager has a fixed idea of the nature of the solution (i.e., the software requirements, as expressed in the contract’s “statement of work”) and the project plan (i.e., budget and time). Often, consultants feel that managers don’t have the right idea about application scope, project length and the mutability of software requirements—and that’s a recipe for conflict. The consultant, as subject matter expert, may identify real problems, but managers (who have an innate distrust of anyone who has additional services to sell) can be tied too closely to the original project plan.

Also see: Five Things IT Managers Should Know About Software Requirements

Statements of work are necessary elements, particularly in project definition and negotiation. However, points out Terrence Gargiulo, president of MakingStories.net, statements of work should be treated as living, breathing, evolving documents that reflect a collaborative relationship between the consultant and client. Otherwise, he cautions, “Projects can too easily turn into an ‘us versus them’ dynamic in which no one wins.”

Scope creep is sometimes unavoidable. For example, search engine optimization (SEO) efforts are dogged by constantly changing search engine algorithms, competitor behavior or unethical trickery—things that can change the initial assumptions about the project, explains SEO specialist Ash Nallawalla. However, part of the consultant’s expertise should be in estimating the time necessary to resolve the situation once it’s identified. “Don’t accept delays without full explanations,” suggests Nallawalla, and remember that some delays are the fault of neither party.

6. Be clear about expectations—in the contract and in person.

Good contracts prevent disagreements and hard feelings. When a contract clearly lays out what happens in a given situation, there are no disputes. (Hard feelings, maybe, but no disagreements.) Contract problems ensue when the paperwork doesn’t address an issue—and then each party has to define the best option (for himself) under stress.

Consultant Jeremy Singer says parties to a contract need to be clear about their expectations, and they need to deliver on those expectations. According to Singer, the contract should define the expected working conditions (e.g., number of hours expected, on or off site, materials to be provided, deadlines), the expected products of the engagement (e.g., specs, programs to do something, advice, encouragement) and payment (When does the consultant bill? How does the consultant bill? How soon is the consultant paid?).

It ought to go without saying that enterprises should honor the contracts they sign. Unfortunately, that isn’t the case in the real world. Consultants complain about late payments, changes authorized by the client that then demands a refund because the project went over budget, and not paying for something or changing the terms and conditions to suit the client’s need of the week.

Late payments during a project—or with an ongoing consulting gig—are a major problem for the service provider. If the client company’s accounting department decides to let a consultant’s invoice slide, the consultant faces a dilemma: Should he turn off the client’s service? When? Ten days late? Probably not. Sixty? Definitely. But what about after 25 days? The point is, if you want good service from your consultant, don’t nickel and dime him.

7. There’s a relationship between a consulting rate and the individual’s value. Any manager wants to hire the best people for the lowest possible cost. Professional consultants, however, want to be paid fairly for their expertise. Sure, you might be able to find a consultant who’ll work for pennies, but the professionals insist, you’ll get exactly what you pay for.

Usability consultant and Healthcare Chairman for World Usability Day 2007 Theo Mandel says that he’s bombarded with requests for usability experts from recruiters yet told the client is unwilling to pay his rate. “If they want an expert in the field, they need to understand they won’t get an expert by offering rates appropriate for low- to mid-level skill and experience in the field. If they really want an expert, they need to expect to pay an appropriate rate,” he says.

Your own staff is highly differentiated in their skills and compensation; you should view contractors similarly. Christopher Lawson, an Oracle performance consultant, says taking the cheapskate approach is oftentimes the most expensive way to run a project. Lawson recommends hiring the best consultants you can find for complex tasks because they’ll work more efficiently and they’ll know the right answers off the bat. Finding the most qualified candidates means offering top rates, he adds. It also means that your subject matter experts on staff must be involved in interviewing key candidates for consulting positions to help vet their expertise, since many consultants talk a very good game.

When thinking about consulting rates, keep in mind that the job shops take a hefty percentage off the top. If you pay an independent consultant $75 an hour, you may or may not get someone who is worth $75 an hour. If you pay an agency $100 per hour for a contractor, you are most certainly not getting a $100-an-hour person because of the middlemen’s markup. The middlemen obviously make more money when they find a contractor who may not be up for the challenges of the assignment but will take a lower pay rate. The enterprise probably doesn’t get a price break.

8. They bill by the hour. Don’t expect work for free.

If you want a contractor to spend any time on your behalf, be prepared to pay for it. “Every hour worked is billable,” says consultant John Bland. And that includes hours spent working outside the office.

“For every hour that I am visibly working on a project, two to three hours have been spent doing unseen work,” says Chris Mague, systems administrator at Danger Inc.

You may not be aware of the investment your consultants make in learning the technical (and not-so-technical) details of your assignment. Rudy Limeback is a SQL consultant who has been self-employed for six years. “An hourly consultant will bill not only for time spent actually producing a deliverable, but also for time spent becoming familiar with the client situation in order to make a recommendation. This includes meetings, e-mails, phone calls and reading of background material. Allow the consultant lots of leeway here,” Limeback recommends.

Consultants are typically paid differently than contractors. Where contractors charge by the hour, consultants invoice per project. If you intend to hire a consultant, do not ask her to bill you by the hour, advises Scott Barber, president and chief technologist at PerfTestPlus. “As a senior person with expertise in an area in which you (or your team) lacks expertise, a consultant had better know what they are doing,” he says. “As such, it is not their time that you are paying them for, it’s their results.”

9. Treat ’em like people.

Treat contractors and consultants with respect. That means including them in key meetings, providing them with good equipment and offering them comfortable working conditions.

Some managers intentionally give contractors less-than-ideal working conditions because they want to appease their full-time employees, who are often sensitive to any superior treatment the contractors might get. After all, the contractors are frequently retained to develop new applications on new technology while employees are stuck supporting the old software. To compensate, managers give contractors old computers, stained chairs, rickety desks, tiny workspaces, limited parking facilities and even reduced access to the company cafeteria.

Some clients go too far in the other direction: They treat contractors like employees by commanding them to attend a company picnic (unpaid) or to go on a golf outing. Consultants want to be paid for their time, and they aren’t motivated to create lasting business relationships when everyone knows the consulting engagement is temporary.

Of course, you’re unlikely to respect consultants if you don’t care about your existing employees. All too often, a consultant’s opinion is given far more credence than the opinions of people who have been working on the problem for months. For example, at one minicomputer company (which is, thankfully, long gone), I was asked to evaluate the QA system for the firm’s many language compilers. I asked the employees for their input, who were happy to share their wish lists. I also did some technical analysis of the process, but that was minor. When I presented the “here’s what needs to change” data, the managers acted as though I had discovered fire when the information had been available to them all along. Message to CIOs: If you want to keep the working relationship between your full-time staff and your consulting staff constructive and positive, treat each with respect and realize that some of the genius ideas your consultants are presenting may be coming from your own people.

For many IT shops, consultants and contractors are a fact of life. If you apply these nine suggestions to your business, you’re sure to get more productive work from happier people and save money to boot.

Esther Schindler is senior online editor at CIO.com. Before her descent into computer journalism, she supported herself as an IT professional and computer consultant. As a contractor and consultant, she optimized compilers, wrote customized add-ons for accounting applications, was an OS/2 network administrator for a utility company, trained corporate users on desktop publishing systems, and installed far too many operating systems on small business computers. Her first online community position—long before becoming BlogMom for CIO’s Advice & Opinion section—was as sysop of the CompuServe Computer Consultant’s forum. As a result, she finds it impossible to discuss this topic with brevity.