Subcontracting: A Middleman's Perspective

As a technical consultant, I have worked with several contracts over the course of a few years. In all these cases, I was working directly for the client. However, during a discussion with one of my networking groups last night, we talked about the issues of subcontracting, and the problems they solve and create.

A client, who I’ll call Small Business, needs a custom inventory management system, which links to their website for processing orders. Not being technical, he hires a Consultant who is an expert in inventory management systems, but has no experience with building websites. The Consultant takes the entire job, requiring him to provide both the software and the website. The Consultant puts out an ad and recruits E-Commerce Developer to build the site.

From the perspective of Small Business, he has managed to contain all his technical needs within a single contract, and can keep his maintenance costs down by retaining a single contract instead of two. From the Consultant’s perspective, he has landed a large contract of which he is only doing a portion of the work, and retaining a finder’s fee for the remainder, plus a maintenance contract. The E-Commerce Developer was unable to get the contract on his own, and so is happy for the work, and does not need to deal with the client for payment.

It looks like everyone wins.

However, there are problems with this model. The Consultant, not being a web developer, cannot provide accurate estimates of the costs of that component, leading to possible cost overruns. As well, by acting as a middleman for the Small Business and E-Commerce Developer, the chance of miscommunication has been increased. This is compounded by the fact that any communication between E-Commerce Developer and Small Business must go through Consultant, which means it is slow and inefficient.

The model that we came up with during last night’s meeting aimed to remove these obstacles.

A small group of individual contractors would band together and move into a small office. Each person would have their own office, with some shared resources (meeting rooms, kitchen). The office would share phone lines with an internal automated switchboard and internet access. As well, technical resources would be shared within the group, including access to legal documents, tax advice, graphic design, and a developer pool. Each partner would contribute a fixed sum per month for the upkeep of the office, plus some extra for renovations and unexpected expenses. (An office can be rented for less than $4000 per month including utilities, which, in a group of 10 partners, is only $400 per month for an office with meeting rooms and shared resources.)

The developer pool is what would make this system work. Partners in the group are people who are looking to establish clients and to bid on projects. Each is technically proficient, but they bid against one another for projects, or join together to bid for projects. When a project is deemed too large for an individual, they turn to the developer pool to get the work done. The developer is brought in on the project, and communicates directly with the client for requirements and specifications.

Developers in the pool are people who are looking for occassional work, but do not desire the overhead of dealing with clients and searching for projects. By being in the pool, they can see which projects are available for work (indicating that one of the partners has won a contract and requires particular skills) and which they would like to work on. They will then be able to deal directly with the client once approved by the partner, using standard rates from within the group and paid by the partner (not the client).

We are still in the planning stages, and nothing has been cast in stone yet. But the model is in place, and we are looking to tweak it over the next few months. If you have any ideas or suggestions, please let me know. I’d love to hear from you.