It’s been a while since I’ve done one of these.  I wish I could say that it was because the bucket was running low, but it’s not.  Unfortunately, most of the examples that spring to mind lately are a tad too personal to vent them in public (right now), but here’s a solid, non-offensive practice you can implement to insure the complete and utter failure of your software development company.

"I need subcontractors.  Lots of subcontractors."

So you have some money in your pocket, and you want to spend it on software development.  You have a few options:

1. You could buy the things your in-house developers have been pestering you about, like chairs that aren’t broken, monitors that don’t flicker so badly that they cause seizures, and "workstations" that you didn’t buy surplus from the government five years ago. 
2. You could hire additional developers.
3. You could actually pay overtime for those "rare" weeks where there seems to be more to do than the team can accomplish during a 40 hour week.
4. You could maintain the status quo a little longer.  If things are tight, the extra money can be used to maintain existing staff and resources for longer.
5. You can bring in consultants and subcontractors.

Let’s weigh the pros and cons of each.  With option 1, the developers get better equipment, but how’s that going to make you money?  It’s not.  The quality of the equipment has absolutely nothing AT ALL to do with developer productivity.

With option 2, you would be bringing on more people, which means you would be spending more money (and that’s good, because you have to spend money to make money). 

Concerning option 3: HAHAHAHAHAHAHAH, yeah, overime, hahahaha, right.

Option 4 is just dumb.  Money is like a hot potato, you want to get rid of it as quickly as possible.

Option 5 sounds interesting.  Again, it would involve spending lots of money, which automatically guarantees making lots of money.  This is actually a better choice than option 2 for two reasons: consultants and subcontractors are (usually) more expensive than direct hires, therefore the quality of their work will be superior.  Second, because they are more expensive, you will spend more money faster, which means you will make more money and get rid of the hot potato sooner. 

So, let’s go with option 5.  You want to find the most expensive subcontractors or consultants that you can.  It doesn’t matter if they are not experienced with the type of software you are building, because consultants are expensive and therefore always contribute a lot of value.  Be sure not to pay any attention to things like previous projects, or even whether or not they are familiar with the tools and languages that your company uses.  Code is code, after all, everything just works when you pile it all together.

Once you have brought consultants on board, it is very important to let them drive the process.  It doesn’t matter if your developers have an existing "methodology" (whatever that is); just do whatever the consultants say!  Remember, you are paying them more than your developers (hopefully more than all your developers combined), so they are smarter than your developers. Be sure not to try to give the consultants any firm deliverables or requirements.  You don’t want to chain these people down, you want to hitch your company to them and let them pull your software development up to the stratosphere of success!

Concluding Remarks

There are situations where consultants and/or subcontractors are very, very useful.  For example, maybe your team needs an installer for a project, but no one on the team knows anything about installers.  Instead of investing effort in mastering a technology that you may not have much use for, it may be better just to pay someone else to build the installer for you. 

However, there are many times when bringing in consultants is the completely wrong choice.  For example, you don’t have much need for them early in a project.  The early stages are to figure out roughly what you’re actually going to build, and consultants (unless they are experts in whatever market the project is targeting) aren’t going to contribute much.  You also don’t want to bring consultants in unless you have a very clear, specific need for them.  Don’t bring them in to do general work that your own developers can do.  If your developers are overworked, bring on additional full or part-time staff, not a long-term consultant or subcontractor.

If you do decide to bring a consultant in, agree on specific deliverables and hold the consultants to them.  Charging a lot of money is not an excuse to under-deliver.  If things aren’t working on, cut ties as soon as you can.  Be careful with how any contracts are worded, too.  You don’t want to get tied in to a relationship that isn’t beneficial to your company.  Keep the scope small, focused, and specific.  Do that, and you might be ok.  Do it not, and you are probably going to have problems.