During one of our exercises at the HDI Desktop Support Forum meeting this past June, we discussed whether it was a good idea to hire contractors for projects. It quickly became apparent that we felt that bringing contractors in to assist desktop support in defined circumstances could be very beneficial. Once that was settled, we were able to hash out the set of good practices documented here.
Contractors should not be confused with consultants. Contractors act very much like temporary employees, and the hiring process is similar. Consultants, on the other hand, are brought in “when the company has a need and either isn’t able, doesn’t wish to, or doesn’t know how to take care of it—and doesn’t have the time or desire to figure it out.”
The HDI Desktop Support Forum members agree that contractors can provide value in projects—by adding a skill not present on the team, by providing basic labor for less-valuable tasks, or by “backfilling” the desktop support team’s day-to-day tasks to free team members up for project work—but that they aren’t suitable for all projects. There also needs to be a defined set of tasks, good communication in all directions, and clear courses of action at every stage of the project.
The desktop support manager and the project manager—assuming they’re different people—need to define especially clear roles and communication channels before hiring contractors for a project.
In framing our debate, we made the following assumptions:
- Projects run for a specific span of time (by definition).
- There is money in the project budget to cover contractors.
- Hiring contractors is permitted by the organization.
Types of Contractors
Generally, contractors fall into one of two categories: either individuals (independent contractors or temporary hires from a staffing firm) or companies whose employees will augment your existing staff. If you need a group of contractors with similar skills for your project, bringing in a company is usually the best option, and there are several distinct advantages. Third-party contractors typically wear identifying clothing, such as polo shirts, which visually separates them from your internal staff and can help minimize fallout from any less-than-desirable experiences. And if there is an issue with a particular member of the contractor’s team, a phone call to the company saying, “Don’t bring X with you when you come back tomorrow” is usually sufficient. As with any engagement, make sure that you obtain references from other customers who’ve had similar work done.
Individual contractors, whether independent contractors or from a staffing firm, should be interviewed in a manner similar to prospective employees: Will they be a good fit on the team? If you had a position open, would you hire this person? (Incidentally, bringing in contractors is one way to get a “try before you buy” experience with staff.) Although bringing in individual contractors may require more work on the part of managers (group, department, or project), there are several advantages:
- If your project is currently lacking specific skills, you can bring in individuals that have those skills. In such cases, a method of knowledge transfer should be ready so that a contractor’s skills and knowledge can be retained when he or she leaves.
- If your project requires specific certifications, you can bring in individuals that have those certifications without absorbing additional training and certification expenses.
- If the project entails work at a site or sites not convenient to the internal team, you can enlist contractors near the target location to fill the gap.
- Internal managers will likely have more supervisory control over individual contractors.
Some Projects, but Not All
Not all projects or project tasks are suitable for contractors; some are better handled by staff. The use of contractors is advisable when:
- There is a high volume of low-level work, such as unboxing computers during a hardware refresh
- Specialized skills are needed for the duration of the project
- You need to augment your current staff:
- To release staff for project work while contractors perform day-to-day tasks
- To accommodate changes in workflow (i.e., peaks and valleys in demand) during the project
- To shorten the project timeline
- To cover geographies the staff team can’t reach
On the other hand, contractors are probably not suitable for projects that:
- Require high customer “touch”
- Require or occasion exposure to confidential information
- Require work in mission-critical areas where security, safety, and/or regulatory compliance are of high concern
- Require a deep knowledge of the organization’s culture
As with any project involving multiple groups, clear and defined communication between the group, department, or unit managers and the project manager is essential. Use a RACI matrix to clarify roles and make lines of communication easier to identify and establish.
From the outset, the project plan should define the number of contractors required, the necessary skills, the location(s), the beginning and ending dates for the work, the required tools, the hours of work (e.g., night or day), and the transportation requirements (including any reimbursements for travel). Contractors’ fees or wages should be negotiated or determined by the hiring organization, usually by HR or with its involvement or control. Background checks should be performed. If the contractors are being hired through a staffing firm, that firm should assume responsibility for these checks. Any credentials—such as certifications—should be verified as well.
The onboarding process for contractors is similar to that for incoming employees. The organization must provide all necessary equipment (such as an organization-owned computer) as well as any required accounts (such as email) and access to appropriate internal resources. The organization must also provide whatever training might be required (e.g., safety). Detailed checklists can be used to track the completion of required project tasks, and these should be checked for both correctness and completeness before they’re delivered to the contractors.
Once the work begins, contractors should be closely supervised by staff, and staff should be readily available to answer questions and provide direction. The contractors should be making regular contributions to the organization’s knowledge repository, and they should be providing detailed status reports at defined checkpoints during the project.
Contractors should be debriefed at the end of the project to determine what went right, what went wrong, and what could have been done differently and/or better. Any personnel issues encountered during the project should be documented in writing, and any responses from the staffing firm or the contracting company should also be in writing, if applicable. These issues, if any, should be dealt with as rapidly as possible so as not to derail the project or sow discord among members of the extended project team.
Project progress and outcomes should be reported up to senior managers and out to the extended teams so there is a transparent record of the work, the methods, and the people. Any open issues should be resolved by the end of the project, including any work remaining. It is then the project manager’s responsibility to ensure a smooth transfer out of the project phase and into operation.
The HDI Desktop Support Forum provides desktop support leaders with the opportunity to learn, network, share ideas and experiences, and discuss the latest developments in desktop support best practices. The members provide fresh perspectives on challenges faced by desktop support leaders, and together they work toward improving the people, processes, and technology strategies within desktop support.