Earlier, I wrote about my thoughts surrounding what is essentially outsourcing of a given function…thoughts that were firmed up after I had been reading Joel On Software.

I’m pleased to see Richard Jonas follow it up in his Internal or External posting. I have to agree with Richard’s comments, the decision to “in-source” or “out-source” on a project-by-project, or function-by-function, basis has to be made using all the information available (I can’t think of situation where this wouldn’t be true, although we all see such decisions being made without such consideration). And, it is important to note that some projects/functions are inherently meant to be outsourced.

My original posting was prompted (apart from via Joel), by a letter in Computer Weekly dated 20th September 2005 on the subject of “Do contractors offer better value for money?” The author notes that contractors rates of pay are typically twice that of permanent employees. He goes on to state that hidden costs such as bonus, pension, employer’s national insurance, recruitment fees, cost of human resources, accounts, payroll, taxes, holiday and sickness actually make a contractor better value of more flexible. Are these costs really hidden? Surely most businesses know exactly how much it costs to have an employee sit at their desk carrying out their function? No? All these hidden costs, the opportunity cost of having somebody else sitting at the same desk carrying a potentially more profitable function, etc. Surely? Clearly there are two sides to scenarios like this, the author of this letter sits on the side of contractors, whereas I seem to sit on the side of permanent employees…

On the premise that hiring a contractor is analogous to outsourcing a project/function, let’s follow that notion for a while…

Are contractors better value and more flexible? Insofar as the contractor doesn’t [usually] get embroiled in the internal politics that some many permanent employees do (although not through choice I might add), the contractor is free to focus on the task in hand, they can spend 90%+ of their working day on the project/function. Therefore, on the surface, they appear more productive that permanent employees. They’re getting the job done faster, possibly better, but not necessarily cheaper – twice the cost remember, folks will see that as being “more expensive”, unless they are able to understand that the contractor may have taken less time to complete the piece of work (although the work is unlikely to be completed in 50% of the time it would take a permanent employee to complete).

Unless the contractor is able to “hit the ground running”, it’s very likely that some mentoring will be required. Mentoring is often a service delivered by a permanent employee…their costs must be factored when assessing contractor value. Indeed, there’s often an element of re-work involved if a mentor or supervisor is involved. Despite best efforts, I’ve seen the work of contractors being “finished off” by permament employees. Similarly, I’ve seen mentors/supervisors grimace at how long recently in-bound contractors take to complete a known to be simple task (this is more obvious where the mentor/supervisor would normally have performed the job the contractor was brought in to do).

Where the function/project involves the development of a piece of software, it’s very rare (in my experience) that the ultimate end customer actually uses the software the day they are issued with it. The day that they are issued with it may well be the contractor’s last day, in which case who fixes the customers snags? This is less of problem where the customer has wanted to or has been involved in the development process all along, something which is very desirable but rarely happens in traditional software development shops. Often the mentor has to “pick up” the customer’s snags and fix them. This is a double-edged sword. The mentor is nowhere near as familiar with the code-base as the contractor. This will lead to increased start-up time, i.e. the snag will take longer to fix. It will also lead to reduced quality, the mentor may think that they have fixed the snag without realising their fix may have repurcusions elsewhere (yes, practicing test-driven development and having a suite of tests would help, but we’re talking about traditional software development, not agile!)

Contractor flexibility is evident as a suitably qualified/skilled contractor will lend themselves to any platform, any language and their curriculum vitae will be a work of honesty, not fiction. However, the business may find itself paying a contractor to learn a new skill that puts the said contractor in a more marketable position for their next contract. Not good. Similarly, the said contractor completes the function/project then moves on to a new contract. Whatever the contractor had to learn in order to complete the function/project was a skill that went with them…that may well have been a potentially proprietary skill that would have been better value if it remained “in house”.

I’m standing by my original thoughts: if a piece of work, a function or project is considered “core” to your business, subject to the decision making process noted above and in Richard’s post, it should be kept in-house, i.e. internal. Proprietary intellectual skills that give you a business advantage, give you a means of adding value, give you the edge, should remain in-house.