E.H. Harriman of the Union Pacific Railroad had a problem. It seems that a large number of trains were being stopped at gunpoint and robbed by the infamous “Hole in the Wall” gang. Anyone familiar with the classic film Butch Cassidy and the Sundance Kid knows what the shrewd businessman did to solve his problem. While Harriman’s staff was presumably quite competent when it came to getting a train from point A to point B, Butch and Sundance posed a security problem beyond the scope of the railroad’s normal expertise. So Mr. Harriman went out and hired an expert tracker and an expert
lawman—both consultants—to step in and solve his problem for a price, which, of course, served as the basic plot for the remainder of the movie.

The entertainment value of western-themed movies notwithstanding, today’s fast- paced IT department finds a much different application for the proverbial hired gun. The growth of IT consulting can be attributed to several factors over the past few years: the outsourcing and downsizing of corporate America in the early 1990s, the explosion of the Internet, and good old Y2K, among others. Go to any of the Internet portals and search for the term computer consultant. AltaVista (www.altavista.com) turns up 70,000 hits; Yahoo! (www.yahoo.com) yields 20,000; and Dice.com (www.dice.com) lists more than 22,000 high-tech jobs with the word consultant in the description. With all of this consultant-for- hire and consultant-wanted traffic, it would stand to reason that there are many consumers of this type of service. But before an IT organization engages a consultant, it should be asking itself why a consultant is or is not needed.

Consultant vs. Contractor

First of all, I’ll clarify some terms used throughout this article. I basically denote two distinct meanings for consultant and contractor. I define a consultant as someone who brings knowledge to the client that it lacks and cannot reasonably obtain in a timely manner. A contractor (such as a contract programmer) provides additional capacity to a company’s existing IT resources. For example, a consultant may be retained to analyze the configuration of a WAN, performance tune the AS/400, or design a firewall to protect a Web site. These tasks may require skills with which the internal IT staff may be familiar but lacks the expertise to completely apply on its own. Alternately, the organization might retain contract programmers with the same general skill set as internal resources to address

a slipping deadline for a new RPG IV-based system. My experience has been that contractors usually have longer assignments at lower hourly or daily rates than their consultant counterparts.

Why Consider the “Hired Gun” Approach to IT?

To carry out a fair evaluation of whether or not to hire an IT consultant, one must approach it as a business decision. That is, will your company’s bottom line improve as a result of this decision? In business school, when studying various topics such as marketing or strategy, it is not unusual to discuss “core competencies.” What is it that your organization does best? What expertise can your company apply better than your competitors? Top companies know the answers to these questions, and they continually focus on their core competencies. Your IT department can—and should—do the same thing. Make a list of the skills, processes, services, and products that only your group can provide. This list represents your IT organization’s core competencies and should become the focus of your department.

However, a particular skill or service of comparable quality obtained from outside your department for a given price is a commodity. And, like other commodities such as paper or toner cartridges, you generally try to determine how to purchase them in a manner that maximizes their value while minimizing their cost. You fulfill a need or solve a problem by purchasing something for less than what it would take for you to address the requirement in-house. One would not normally consider asking a programmer to repair a laser printer, a task beyond the scope of that person’s expertise. Therefore, outsource the hardware maintenance and keep the programmer focused on development.

Unfortunately, it isn’t always a black-and-white decision. A given task might be something your team is highly capable of performing. Under various circumstances, however, it still makes sense to farm it out. For example, suppose a programmer needs to use data communications with a remote system. He might be able to dig through manuals or research news groups on the Internet to find information about communications configuration. On the other hand, the same programmer may call an IBM support line and get the required information relatively quickly for a nominal charge. It may turn out that the internal resource can avoid unnecessary delays in the overall project by outsourcing the specific task at hand.

Likewise, it might be an excellent business decision to bring in a contractor to write conversion programs or perform computer operations. Your staff can then focus on tasks that do benefit the organization when completed in-house. For example, during the Y2K project, many companies chose to bring in contractors for the Y2K repairs to minimize the distraction to their internal development resources.

Most companies must adapt and position their organization to survive in a real-time, global economy. Businesses are challenged to respond to competitive forces more quickly than ever. Furthermore, companies must not only overcome competitors’ threats but also counterattack with a sustainable competitive advantage of their own. The shortened cycle time of these strategic attacks and counterattacks often places the burden squarely on the IT organization. The application of technology becomes the competitive weapon of choice. Therefore, the IT department must behave like a business in and of itself. It, too, must focus on core competencies and should consider pushing all nonessential functions out to a partner who can address a given function as that partner’s core competency. This leaves the IT department’s internal resources free to address the real business at hand.

For example, suppose there is a project that requires extensive analysis of a particular business process. The IT department may wish to focus on documenting the current business flow and working with various levels of the company to design a new workflow. Perhaps the IT department’s strengths lie in the areas of analysis and design. The company could choose to turn the development over to consultants and contractors whose expertise lies in the areas of software development and project management.

Managing the Hired Guns as Valuable Resources

If the consultants and contractors are going to be deployed in an optimal manner, it is important that the work be planned and managed carefully. It is easy to allow the consultants to function as high-priced employees by letting them get involved in issues that are beyond the scope of their assignment. Remember that the contractor is a “hired gun” retained to address a specific problem. Define the problem as clearly as possible and make sure the consultant is qualified to address it. Then make sure the consultant remains focused only on that issue.

That said, there are some situations in which contractors may be specifically retained to provide general, day-to-day support. This is an excellent alternative so long as it is established as the primary goal of the contracting assignment. For example, when one company acquires or merges with another, it is not uncommon for one IT department to take over responsibility for both entities. The acquisition might result in layoffs or redeployment of one department’s staff, creating a short-term gap that requires contractors to provide coverage.

In the same scenario, outsourcing a project to contractors may also be the right answer if a large amount of data must be converted from one platform to another. This makes a finite, one-time process in which you are not necessarily interested in retaining any expertise used in the conversion project.

Software Conversions

Another common circumstance calling for consultants is implementation of a software package. Many companies use consultants or contractors to install new applications or upgrades or to undertake conversions to new applications. This is a case in which a consultant can bring knowledge of the software into the project without the delay of training employees. Similarly, hiring experienced contractors who are familiar with the design and architecture of a new package can shorten the timeline needed to make customizations. Again, this is an example of not having the resources in-house or the time to reasonably acquire them.

Avoid Biased Assumptions with an Outside Consultant

In the early 1990s, a multi-billion-dollar company engaged two consulting companies to oversee a business process reengineering project. One of the consulting companies was responsible for facilitating focus group discussions about the existing procedures and business requirements. It contacted key employees at all levels of the organization to identify critical success factors. Next, these consultants carried out several days of interviews with subject matter experts and follow-up interviews to confirm or clarify information. The deliverable work product from that consulting group was a requirements document and a gap analysis demonstrating the difference between current system functionality and the stated business requirements. The second consulting group was responsible for using the gap analysis to identify potential solutions and assist in the evaluation of alternatives. This process might have been difficult to accomplish using internal resources. Just as it is tough for programmers to test their own code because of preexisting assumptions, the same might hold true when designing or completing questionnaires.

Another approach is to hire an external consultant to design the interview process, assist with the interviews, and prepare an analysis of the data. The chief technology officer and upper management remain responsible for compiling the list of solutions. The consultant in this scenario maintains a more distant, “arms length” perspective.

Retaining internal control over the solution identification process can be an important advantage in some cases because consulting firms sometimes have a vested interest in the selected alternative. Some consulting firms sell software packages in addition

to providing consulting services. Not surprisingly, it is not unusual for their package to turn up at or near the top of their list of recommended alternatives. This is not meant to imply that their packages are without merit, but it can suggest a potential conflict of interest when the consultant represents the interests of the client as well as those of the software vendor. This arrangement can be effective, but the client must be willing to address any such concerns at the outset for the project to succeed.

One must also consider the impact on morale when making the decision to hire a contractor. It is not uncommon for full-time IT professionals to be paid a flat salary, with no compensation for overtime. Contractors are often retained on a “time and material” basis, in which they are paid hourly. And that hourly rate is usually significantly higher than the full- time worker’s base salary (when converted to an hourly amount). This does not take into account all of the other types of compensation that are added to the full-time figure. Nonetheless, full-time employees may resent contractors earning two or more times their own hourly rate.

Another major difference between contractors and employees is that contractors get compensated for every hour worked, so they are, in effect, getting paid for additional hours worked, while the salaried employee is normally not compensated for extra time. Furthermore, in some slipping project schedules, contractors are encouraged to work as many hours as possible. This only widens the gap in compensation between the contractor and the full-time, salaried employee, who might also be putting in long hours. The IT manager must be aware of the potential for a negative impact on morale under these circumstances.

IT managers should consider the morale implication of assigning new development projects to contractors while delegating maintenance, support, and research tasks to staff. This difference in the class or nature of the assignments—perceived or real—can lead to resentment of the contractor, who is perceived to be getting the new, fun, and challenging assignments.

Morale issues can be addressed by open communication. It is important to include the full-time team in assembling the plan to use consultants and contractors, if possible. Clarify the need for the additional resources and identify what function they will serve. Involving staff in the discussion before decision-making will help manage the expectations of the team members. Prior discussion also provides an open forum to air the issues and assumptions. Some objection to the use of contractor labor can be reduced by emphasizing the limited role and tenure the consultant or contractor will have in the organization. Some projects will find contractors and full-time employees working closely for extended periods of time. In this situation, it might be appropriate to include the full-time employees in the interview and selection process and make sure the fit is right. Sometimes, after starting out as a contractor, it makes sense to convert the person to a full-time employee. Doing so after working with the person for a period of time allows both sides to get a feel for the relationship and lowers the contractor’s risks in joining the company. If the organization feels that such a transition might take place in the future, it would be even more prudent to address the fit between the contractor and the full-time employees during the interview process.

When the Smoke Clears

If the project plan calls for an end to the consulting or contracting assignment, it is important to identify the criteria for ending the assignment. The original agreement should include a specific exit plan. Lacking such an element might lead to resistance from the team as the project draws to a close. With the seemingly never-ending project backlog rearing its ugly head, it may be difficult to decrease the amount of resources available by terminating the consulting engagement.

Politics

The exit plan might require as much or more political attention as the original retainer process. Full-time workers might grow anxious about who will assume the additional workload after a consultant’s departure. This assignment uncertainty might generate additional anxiety and speculation about financial solvency or job security. Some workers might view the termination of a contractor as a loss of a valuable knowledge base and resource. Again, the ending of a consulting engagement may require the project manager to address employee concerns head-on and ameliorate the impact on morale.

There are several other cases in which hiring a consultant or contractor makes good business sense. The important thing is to determine if, after the smoke clears, there will be a more positive impact on the bottom line by bringing in the consultant. It may take some creative analysis of the intangible benefits to support the decision.

If, and when, you decide to engage a consultant or contractor for your project, I hope you will enjoy the same success as E.H. Harriman.