Leftovers: Eighty / Twenty and the problem with contractors
Several great programmers I know have recently made the switch from full-time employee to full-time contractor… and I understand why. Clients and corporate structure can be a real drag. You have to deal with politics and personalities all while trying to actually get some work done. What I don’t know is whether this is going to be an industry-wide trend or a phase in what is now a very favorable economic cycle for interactive developers. Needless to say, I can understand (and have experienced) the appeal of hourly work and the freedom to be choosy about one’s projects, but it may not be good for the industry over the long term. This shift has forced the business model towards an agency of interactive project managers who contract out work to a sea of growing independents; however, scope changes, waning accountability, and the fragility of an ongoing support relationship can all disrupt the success of your project.
The proposal problem
Proposals aren’t meant to assume the responsibility of a complete requirements specification, but they are meant to illustrate a broad definition of scope. They often list deliverables, dates and process; however, if you’re planning to use a contractor for the development portion of your interactive project then most proposals aren’t specific enough. Contractors often need to schedule chunks of their own time and put together a proposal of their own (based on yours). This all needs to be done while courting the client to ensure resources are in place if the project is a go. Unfortunately, if you write your proposals with hard deadlines and strict penalties, no one will bite, and if you write a complete functional specification, your potential client might just shop it around to other firms; your competition will always have a lower bid because they didn’t need to spend hours fine-tuning a proposal and researching the time required to complete a given task.
The other option is to pull from a pool of developers that charge by the hour and pass that rate through with a margin. In my opinion, this is never fair to the client even if you manage to land one who’s extremely rich, used to slow government contracts and enjoys spending vast sums of cash on prolonged phone calls and meetings with three team members ($150/hr * 3 attendees * 2hr meeting = $$$). In addition, most clients have very little understanding of a project’s scope or the consequences of making seemingly small changes in the middle of development. This always leads to a frustrating client relationship and can compromise a potential referral.
The accountability problem
Most contract software developers have shunned the corporate world for a reason… the amount of non-development energy required to finish a project and make a client happy can be equivalent to the time spent writing code (if one accounts for the time costs of communication, research, training and deployment). It is much simpler to carve out the programming portion and leave the rest to an agency; however, this disengagement will inevitably lead to ambiguities of responsibility, and a higher risk of failure.
Finger pointing (responsibility) can generally be avoided by robust contracts, but this really just takes us back to the proposal problem. The process can also work if you happen to use contractors serious about their long-term reputation. In other words, contractors who treat the agency with the same level of customer service with which the agency treats the client. I’ve seen this work–it’s the epitome of capitalism–but it doesn’t take long for these developers to understand their real value and raise rates accordingly, thus making it ever more difficult to justify their use on “every day” projects.
When working with a development contractor, there is always the risk they will fire you… if the project starts getting difficult, relationships go sour, the time-line changes (when doesn’t it?) or they take a full time position with another company. For all these reasons and more, a project’s risk profile expands as outsourced development is integrated into the process. I’ve seen this successfully managed by extremely talented project managers. Unfortunately, they also tend to realize their true value after a period of success.
The training and support problem
Another consideration is the time it takes for internal development staff to fully understand the code written by a contractor. This can be necessary in order to provide ongoing support at the conclusion of a contract; however, there is little consideration for the additional hours this process takes, not to mention the sour attitude any internal programmer will develop when tasked with leafing through someone else’s code.
One solution is to write perfect software such that your client has nothing to complain about. Believe it or not, I’ve had reasonably good luck with this mostly as a result of working with rock star developers. But, in all likelihood this is the exception not the rule.
Another alternative is to hire a full service development agency (more middle men), and rely on them to handle ongoing support. This can work if your goal is to completely isolate the creative from any of the software development, but I tend to dislike any arrangement that releases ultimate responsibility for client relationships. In addition, these agencies are always at least as expensive as you are, and thus rarely a money-making proposition.
What now?
We’re probably heading for a recession, but it may be that as companies cut budgets from traditional advertising, alternative means of accessing their customer base become more attractive… thus the case for continued growth in Interactive business. It’s usually better to run your agency a little lean, but with the growing demand for interactive work it may be time to stick you neck out there and start to hire.
