I have written about technical competence in the context of Software Engineering Practices. This article will shed some light on a different aspect of technical competency. Outsourcing it.
A number of companies I have worked for have started a large project based on a technology they are not competent in, or even completely unfamiliar with. This fits very nicely in the outsourcing strategy most of them have regarding IT. But does this makes sense?
In my opinion, having technical competence (and excellence) in your organization has never been as crucial as it is today. Creating a technology strategy that allows you to not only deal with but take advantage of the increasingly rapid pace of change separates the successful organizations from the obsolete ones.
Some observations I have made when your organization is not competent in a technology that is used for a big initiative:
> Your IT architecture team is dependent on external consultants for creating an architecture. You can have luck with your external consultants (honest, competent, independent), but I have seen the opposite more often (not competent, driven by sales, vendor lock-in). Unfortunately, when you have no competence in your organization you have no way of judging before it is too late.
> The cost of implementing new features (your business requirements) are determined by external consultants and/or vendors, and you have no way of judging if these are reasonable or not.
> The decision if certain new features are possible or not are made by external consultants and/or vendors, and you have no way of knowing if these decisions are justified or not.
> You have no healthy team atmosphere during the project. Internal employees always have to ask external ones for their opinion and input. This gives a very strange team dynamic where externals are making all the decisions one way or another (direct or indirect).
> You are not able to support the implemented solution after go-live without help from external consultants and/or vendors. This makes you very dependent, even after the project is finished
> It makes it very hard to switch vendor or implementation partner, because all of the knowledge of the solution is with them, so when you want to switch because you are not happy you have to work a while in parallel with two different companies. Besides the costs, this will give an even worse team dynamic.
> Your best external people can leave the project on a whim because you have no influence on keeping them there. Supplier priorities may not be you, or they just leave your supplier.
In general I am the opinion that when a company is deciding on a certain technology for a big initiative the first thing they should do is hire two or three of the best people they can get, make them internal employees and give them key positions in your project setup (architect, QA, technical project lead).
Leverage their experience by not making beginner mistakes, get second opinions on cost and feasibility estimations and get a judgment of skills of external consultants. This will put your organization in the driver seat instead of being driven by others.
Yes, your headcount goes up, and yes they do not work for free, but trust me on this one, this is money well invested and far much cheaper as not doing it.
In a nutshell: Having technical competence (and excellence) in your organization has never been as crucial as it is today.
PS: Although this was written based on a new technology decision, all the above is true for starting a project with a technology you know. When your internal employees are not familiar with modern software engineering practices like Unit Testing, Test Automation, and Continuous Integration, get people on board that do. You will never make a lasting change in your organization by outsourcing these.
