• Who can do it in the time frame?
• Who can do it within the budget?
• Are the requirements defined?
• Who's got the resources (facilities & equipment)?
• Who's got control of the project?
• Do you need support (after development and implementation)?
• Are there future revision requirements?
• Is the project central to the mission of the company?

Sometimes a task comes along that you can't handle in-house. It's often because you don't have enough personnel available, or the ones you have don't have the experience. Sometimes it's just that the contractor is someone you know can do it better. These are some things to remember:

• Capabilities. You should get some familiarity with the contractor's real (as opposed to claimed) capabilities.
• Oversight. Contracts often involve a liaison on both sides. Details not specifically spelled out in the contract can be worked out between those people. Some of the engineers who contributed to this write-up are hesitant to contract-out a job which needs close and constant monitoring. They may be more comfortable with jobs that can be handled by the liaisons. They may be even more comfortable with a turnkey task, in which the contractor takes the job and does it with minimum interaction.
• Documentation. Establish a reporting schedule up front. And be sure to specify documentation as a deliverable, unless you know you don't need it! Define carefully the level of documentation expected. Otherwise, don't be surprised if you get none!
• Scheduling. Does this project get in the way of daily plant/systems operations? How much hassle is involved with coordinating and scheduling a contractor versus in-house staff?
• Availability. Just as the hiring shop may not have anyone available to handle the job, the contractor's best person may not be available either. Sometimes the contractor will put the best people on the highest-profile jobs (and who could blame them?), and leave lesser jobs to younger or less-experienced or just plain lesser staff. (And they may dangle the best people in front of you as a way to wheedle more funding. I've seen it.)
• Funding. Up front funding versus down the road funding? Can the project deployment rate be altered to suit funding availability?
• Knowledge base. Is this project expected to evolve or is it something static? In other words, how much should we know about this system to be able to work on it? If we're approaching the same level of background the designer would have to know, then there is little benefit to having someone else do it for us.
• Criticality. Can we afford to let something like this work poorly or not at all for long enough to get someone who knows something on-site, or should we keep a staff of people who can work on it available 24/7/365?

Reader Comments

We once contracted out a machining job on a difficult-to-machine alloy. It was a disaster - poor finish and dimensions out of spec. It was cheaper, but you get what you pay for.

Reader Comments Again

To carry a large and complex project to conclusion requires many compromises and much expediting. Feathers get ruffled and people get upset. When the project is complete there will be aspects that are less than ideal and some parts that are simply failures.

It is very disruptive to the smooth operation of an organization to have continual blame-laying, bitching etc. It is best to blame it on all the (absent) contractor. Then the issues get dealt with and life proceeds. What I tell newbies in our business when the client blames us for things that are either out of our control or directly the fault of the client: "They hire us to take the blame."

MORE Reader Comments

This question is asked daily in software development operations. It is easy to argue that it is cheaper to pay a license fee than to pay an in-house developer to reinvent the wheel.

The problem is that you usually get compiled code in return for your fees. If there is a problem, you can't get to it and fix it. Our experience has been we end up paying the developer more to work around implementation problems than we would if he wrote the thing in the first place.

The only problem is that people listen to an outside source more than they do their own people. When I was a contractor, what I asked for I got. When I move into a salaried position, frustration is bound to follow. Thus, if I want to get something done in house, one strategy is to hire an outside contractor to make my case for me. Sort of "the grass is greener" type of thing.

AND...

The problem is that managers are afraid to put the keys of a truly critical system in the hands of a few really smart staff. They're likely to try something crazy. Yes, it probably would work. But in a utility or any other major industrial operation there is too much at stake and the risks are so high, that most managers are afraid to give such people a free reign. So instead, they hire us to construct sophisticated systems which can be used by someone with below average intelligence who seeks the routine and mundane. That way, you get sophistication, but with the safety of knowing your staff isn't creative enough to think of doing anything but what they've been doing for years.

One engineer writes, "Homer Simpson isn't a cartoon; he's documentary!" I wouldn't know about that, but some organizations write contracts -- and design programs -- so they can be Homer-proof!

Homer Simpson is created by Matt Groening, and I *believe* from looking at their Web site that Fox holds the trademark. But this fan artist's conception was created by Robert Graham.