Contractors (short-term hourly workers) can lend help on a project that is understaffed or bring specific knowledge that the team does not currently have. It is possible to have too much of a good thing and the overuse of contractors can spell doom for a project. How can contractors be managed to maximize their benefit to the project without them becoming too much of a good thing?

It is important to realize that professional software development really is a knowledge-management activity. The primary asset in a software development organization is not the software that is produced but is the developers and the knowledge that they used to create it. Most software requires a certain amount of domain knowledge, and all software requires a large amount of knowledge of the specific product and its requirements. Software is never completely finished. As long as a piece of software remains comercially viable there will be bugs to fix and new features to add. Therefore the software itself loses value over time; it depreciates quickly. The real value lies in the developer’s ability to fix the bugs and add the new features.

This is where the value proposition for contractors starts to weaken. If your project is saturated with contractors, then when they leave and take their knowledge with them the team is left wanting again - moreso then when the contractors were brought on. You end up with solutions, algorithms and code that the remaining members of the team don’t understand and cannot maintain. In a worst-case scenario that code will have to be rewritten by the long-term members of the team; which not only negates the original value of bringing on a contractor, it introduces new costs and new risks.

What follows are a few tips to make sure you get the most bang for your contractor buck.

1. Have a clear understanding of what you need from the contractor.

You are bringing in a contractor for a reason, what is that reason? If you answered “because we need help” then you need to stop and think this over a little more. All developers need clear goals, but a contractor needs them even more. Make sure that you have a clear set of goals before you even interview contractors.

2. Hire the right person.

Decide ahead of time what areas of the code the contractor will work on and determine which skills will be necessary to meet your goals. Now you can focus on those areas when interviewing contractors. Contractors can be expensive, so make sure the skill set you hire matches your needs.

You also must be able to communicate with your contractors. This encompasses everything from language barriers to poor communication skills. Developers are not well known for their people skills, but you must be able to communicate your goals to the contractor and have them describe their solution to you.

3. Manage your contractors.

It is often very tempting, especially with expensive contractors, to turn them loose on the project and not provide good management. Contractors must report to someone who understands what is needed from them and can manage them appropriately.

4. Develop a knowledge transfer strategy.

All too often the assumption is made that it will be sufficient for a contractor to spend their last few days on the project transferring knowledge. In practice, this almost never works. Knowledge transfer needs to happen throughout the lifetime of the project. In fact, it needs to start when the contractor walks in the front door.

A good way to ensure that the contractors knowledge is spread across the entire team is to use Extreme Programming’s Pair Programming practice. This is a very efficient method of knowledge transfer, especially if the contractor is occasionally paired with a new team member.

Code and design reviews are also a good knowledge transfer strategy if they are held often enough and take seriously. It is very easy to skip reviews at crunch time with the excuse that there isn’t enough time and the review can be held after the deadline has been met. Reviews are most important during crunch time since they reduce the risk of making costly mistakes, and a review after the project completed usually results in no change and most often doesn’t even happen. A good adjunct to regular reviews is to hold regular lunchtime learning sessions where the contractors impart some of their specialist knowledge to the entire team.

One method of knowledge transfer that almost always fails is written documentation. Code documentation comments are good and necessary, but they often do not convey intent and the underlying thinking that went into a particular algorithm. Documentation outside of the code that is written purely for knowledge transfer reasons usually fails to accomplish its goals. It is a very inefficient compared to pair programming and reviews mostly because there is no guarantee that what the contractor chooses to write about is what the team really needs to know.

5. Keep the long term developer to contractor ratio high.

A team that is dominated by contractors cannot successfully perform the knowledge transfer necessary for success. Once the contractors go, a significant portion of the expertise required to build the product will go and those who are left behind will not be able to maintain it. There should be 3 long term developers for every contractor on the team, and no fewer then 2. If the contractors out number the long term developers, the project is in serious trouble.

6. Be prepared when the contractor shows up.

When the contractor walks through the door, the following things should be ready:

1. A place for the contractor to work and a computer to do the work on.
2. A document describing the company’s coding guidelines.
3. Architecture and design documents that describe how the product works.
4. An initial task list.

Tags: contractors, management, projects, teams