Dangers in IT-management: how outsourcing seemed like a good idea at the time …

You don’t hear ICE-T singing about how ”management ain’t easy” , but maybe you should. Maybe that could convince the future generations of aspiring managers to not to think human systems as simple and optimize things based on remote case study results or faulty logic. I have been busy doing implementation work in one project, but still haven’t been unable to hear current stories about misaligned IT efforts and how initial cost cutting measures through outsourcing eventually have turned into expensive dead ends — from which companies had to reverse their way out.

Outsourcing itself is not a bad idea. There are numerous places where economies of scale and ability to use shared expert resources are smart thing to do and drive unit prices down, which in turn can be a way to cut down costs. Outsourcing can also be used to gain access to expensive skills and scale of resources not reasonable to keep full time in house, but then again it will not be cheap.

These expensive outsourcing misadventures were all related to outsourcing something core to the company, namely their core product development. There is nothing nothing wrong in working like that, as long as you know the risks associated with it, can transfer required domain and tacit information and can align external operators to your business’s goals.

And that can be easier said than done.

Actually. Getting rid of your in house technical team which has good set of basic skills, capabilities to learn new things, long time investment in the domain knowledge as well as tacit knowledge of the organization – to replace them with outside consultants with great skills in new technologies, but very limited or no exposure to your domain nor to the organization sounds like something from a Dilbert-strip. Especially if you thought that it would be cheaper.

Creating something new is always hard. To get something great built, you need to have talented and motivated team or teams, whose goals are aligned with the business goals – and with whom you can communicate and collaborate efficiently. Unfortunately there are no shortcuts or magic recipes. And you can fail even with the most expensive outside consultants as you can succeed with moderately compensated in house teams.

One thing I have always wondered is why on earth companies are willing to pay ridiculous amounts of money to outside consultants, instead of originally hiring and compensating exceptionally well a really good in house development team?

I mean there are good reasons why talented developers choose consultancy-work over steady in-house positions: better compensation, ability to play with new toys and changing clients can be a good thing in terms of keeping your ideas and interests alive. But then again at the same time I do know really talented developers, who would prefer to work in one company and to solve big problems there… but only if companies would also compensate for their work better. Going to work for one company would mean choosing much more boring environment, bureaucracy and lower pay – nice deal, eh?

I honestly believe that there are still possibilities to create really cool, interesting and inspiring in-house development opportunities and recruit top talent to work on those interesting problems as internal employees – not as external consultants. It is just tragically funny that I haven’t seen traditional companies try to reach out and recruit people to do cool stuff and change the world ( and to pay accordingly for the job ). If you try to recruit a cog into the wheel, you get just another cog in the wheel…. And then it is left up to the consultants to bring in all the cool stuff and fresh ideas.

But it doesn’t have to be like that.

Luckily these days there are also companies that seem to be learning and seem to understand it might not be a smart thing to do outsource everything. They have learned the hard way that there are aspects of IT where in house development and deep domain knowledge can be used to create competitive advantage with competitive cost structure. In those situations companies also get much more benefit out of the usage of consultants, who work alongside internal team(s) – as deep domain knowledge and technical knowhow meets with fresh ideas and experience from the outside.

I am going back to the IT-consultancy business in december.

Kategoria(t): business, technology. Lisää kestolinkki kirjanmerkkeihisi.

2 vastausta artikkeliin: Dangers in IT-management: how outsourcing seemed like a good idea at the time …

  1. daviding sanoo:

    @huima You’re going back to IT consultancy? I guess it’s a cycle, in and out. Sometimes, it’s not about the talents of the individual developers, it’s about the team. Something goes awry in the company — the orientation of management or unexpected environmental factors — and the high performance professionals get frustrated and/or leave. In the interim, external resources can get the organization over the hump. You’ve pointed out the challenge when a short term fix becomes the long term practice … with some feedback control as external resources are considerly pricier than internal resources.

  2. Niklas sanoo:

    Nice post. Some reflections from my own experience of outsourcing developers to another company. In this case the biggest fallacies behind that decision were:
    1. Development needs fluctuates greatly and thus an IT consultancy is better equipped in balancing the load and correspondingly you are not tied to expensive fixed costs.
    2. It is not important to have developers, architects and product managers in the same location, in fact it so irrelevant that communication with developers can be reduced to a specification and a little bit of steering done by software architects
    3. In the short term cost level will be the same, but we gain the immediate benefit of having more scalable resources. In the long term the costs will be reduced by increased usage of developers from low cost countries.

    I guess the first of those assumptions comes from some experiences before outsourcing where the business units’ demand for developers who knew certain technologies increased suddenly and the PMO was unable to provide any or, worse, ended up allocating people to multiple projects. As I see it, the core reason for this situation was too little developer cross-functionality and no foresight to invest in increasing it. Be that as it may, the developer demand was never zero – there would have easily been enough constant demand for at least one development team per each of our three business units. So rather than outsourcing all developers, some core teams could have well been kept inside our company.

    Moreover, those surges in demand for developers who knew certain technologies were practically always related to platforms and applications that were very specific for our company – it is a leap of faith to think that the outsourcing partner would proactively increase the pool of know-how for such technologies when that know-how cannot be sold to other companies. A more likely scenario is that you are resourced with someone who will start learning those technologies when you need them, so you anyhow end up paying for building the resource pool for that technology.

    As for the second assumption I don’t know what to say. I used to think that no one with extensive software development experience any more believes in waterfall, but clearly I have been wrong.

    The third assumption could be true and in our case partly was. But not for costs. Here the big problem was not outsourcing per se, but the used development model. Firstly, the overhead increased as we had project managers on both sides. Secondly, trying to run traditional waterfall decreased the project productivity easily three-fold, but probably more than that.

    Thirdly, the goal was to have fixed cost targets based on were precise specifications. Not only did this slow down the development because of this extensive specification writing, the specifications were anyhow never precise enough, so the outsourcing partner included significant risk premiums. The first project that went through this process received a five time higher offer for development than was our internal estimation by a very seasoned project manager. In the end we planned two further months together with the outsourcing partner and then started the project on a target cost basis.

    Fourthly, bureaucracy was increased as the project steering group was not allowed to increase project spend by more than 10% and duration with more than one month (scope changes weren’t allowed). Any other changes to the project were to be escalated to the project portfolio management which gathered every second month. There were constant change requests that were rubberstamped in the portfolio meeting.

    The costs were also directly increased because of the outsourcing. The hourly fees were more or less the same as our internal rates which include “all costs”, but in practice we didn’t for instance rent any less office space after the outsourcing and at least some of developers still needed our company’s computers.

    To be fair, there were also some better assumptions about the decision such as that the transferred employees would like working in a full-blown IT company and that it is important to have only one development partner to ensure that same people can be constantly utilized and thus deepen their domain know-how related to our business. Nevertheless, all in all the exercise has been a disaster and at the moment we are, as you say, reverting back from an expensive dead end.


Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:


Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out /  Muuta )


Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )


Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )


Muodostetaan yhteyttä palveluun %s