Tuesday, July 6, 2010

The challenge of contracting out

When discussing application development and support services with vendors, sometimes you see them think “I like to do this, but rather not that” while they know you require the full package. Their mind is going wild assessing the possibilities to provide the service while they know that they do not have all the required resources and skills in-house. Or alternatively, the requested service model does not align with their business model. This becomes even more apparent when specific scarce skills are required part time.

Vendors for application development and support services have their business model usually aligned according to two or three varieties. The first one is the traditional body shopper. They have a pool of resources and provide these people to the client on a time and material basis. In essence the client maintains responsibility over the work performed. The other model is where the vendor takes over the responsibility for the deliverable and the client does not have direct influence over which people work on the project. As a client, I usually refer this to as “I care about the person and don’t care through which company I contract the person” versus “I care about the company and don’t care which people work on the activity”. (Though this is of course not really true; you always want the best people to work on your projects and you also care about good employment context for your contractors.)

You hit a third variety where you want support from a software vendor where they have resourced their staff primarily around pre- and post-sales support. They will assist with system implementation but only for those parts that relate to their software and can run into limitations to do the full project. If skills in the market around their software is very scarce or sometimes almost completely absent, you will rely on the software vendor for the project and ongoing support unless you built expertise in house. I found that they are often reluctant to provide a good outsourced support service. When you buy software for which there are limited skilled people in the market, you will have to pay a premium price for support regardless of how you will resource this.

Some vendors mix models. That can be good if you need both types of services, but I also found it can create problems.

I recall the dilemma’s that a vendor can go through very well from my previous life as part of the pre-sales role for our professional services organisation. When you sit down with a your colleague of sales with a potential client to convince them to award you the project, you sit there thinking “Who will I put on this project?”. You know that your sales colleague will say that Mary and John are available. But you know that Mary does not have experience with the relevant technology and John … Well John is not really the person to drive this project to a success. And then considering that just a few days ago, the ideal resources were still available but the body shopping part of the company decided to contract those people out to another client, leaving you with less qualified people available for your project. You said that you wanted to keep those people for this new project opportunity, but the conservative voice in the company went for the low risk option.

Outsourcing of a project is one thing. You can allocate resources full time to the activity and once the project is finished, they become available for other projects. In that sense the model is relatively simple.

But when a vendor starts specialising in support services, they need to have enough resources and enough work for those resources. Support usually comes in bits and pieces. It is therefore important that the total amount of work coming from all clients requiring the skills can be spread out evenly over time and over the available people. If you have peaks and troughs, you have moments that you cannot provide the required service level and moments that you don’t have enough work for your people. Both these aspects impact your bottom line negatively unless you assure you have enough people to take care of the majority of the peaks and let the clients pay for the troughs.

When looking for a vendor to outsource to, this is one of the key aspects to consider. Will the vendor have a solid customer base such that they can guarantee an even spread of workload for their resource pool? This is important so they can provide timely services (you don’t want to hit a critical incident during one of their peaks) and can provide you with cost effective services (you don’t want to pay for the troughs).

Sometimes the skills are very scarce and you might want to opt for a premium price, just to assure that you have quality support.

The biggest challenge I have with all this is to explain the associated costs to business managers. They see the rates or total costs in combination with the allocated support hours and challenge you on the costs. They do not always understand the variety of unique technical and business skills required and also do not always understand the consequence of outsourcing. Too often they think that buying IT services is as simple as buying a loaf of bread in the supermarket.

I always prefer permanent staff, provided that there is continuously enough work. This is always cheaper. The continuity they provide is also important to cover those areas where much business specific or implementation specific knowledge is required.

However when you have much start/stop work or require a broad range of common skills that requires little business specific knowledge, outsourcing can be a good option. Outsourcing is quite often also the only choice to ascertain support that requires very specialised skills.

To cover peaks in projects, I prefer to in-source from body shoppers simply because I prefer to keep project control as much as possible in-house which creates flexibility and better hand-over of knowledge to the internal team. Even better, I prefer to use permanent staff to drive my projects. They will think twice about taking short cuts, because they know they will have to deal with the consequence later.

Quite often, I keep some of the contracted people after the project to provide the first period of support and with their built up knowledge of your environment they are the ideal candidate for the next project.


  1. Good read...so your conclusion for scarce IT skills? If you have to contract a partner the associated risks (such as IP loss) are a necessary evil?

    Nick Hadlee

  2. Nick, yes. The loss of knowledge is always problematic. That's why I try to keep contractors as long as possible and move them from one project to another.
    Luckily I worked over the years with a great bunch of people and was able retain some contractors for many years or was able to get good people back in again.


You are welcome to leave any response or thoughts that you have as feedback.