An ‘External’ on IT Outsourcing
Helmes Partner Eliis Väert separates fact from fiction when it comes to worries about outsourcing your company’s IT.
As a Helmes partner who often meets with prospective clients, I’ve heard a lot of arguments concerning why outsourcing IT to externals is a risky business. But from an external’s point of view, let me articulate the most popular arguments and explain why or why not they may be valid.
The in-house IT option
I often hear that keeping IT in-house is the most fool-proof option. In-house might sound ideal, but in practice it really isn’t. In the perfect world we would actually outsource everything that isn’t our core business competence to a partner who’s an expert in that particular field.
Take for example the hospital which is my client. Good information systems are a requirement to serve its patients, but to build those systems properly would require an in-house team of 10 to 20 full-time employees with solid IT expertise.
If the doctor who runs the hospital decides to do everything in-house, how should he know he’s chosen the right manager and if the team assembled is capable and efficient? The truth is he won’t know, and if IT isn’t your expertise then doing everything in-house is an act of blind faith. Businesses run on blind faith tend to fail, and unless you’re running a genuinely big business, then the in-house option for IT is generally not an efficient one.
Even big companies go outside
Two Helmes clients, both global companies, literally employ thousands of developers, yet both still turn to Helmes to help handle their IT needs during peak software development seasons.
The first client is a global transport and logistics company which employs over 80,000 people and has an annual turnover exceeding 10 billion euros. Helmes uses approximately 20 people in four teams to serve this client.
Even though they’ve been our client six years now, this client is clear that our relationship may not be forever, and all our agreements are for one business quarter with five days’ notice for cancellation. In practice, the client has always given us several months’ notice, and work peaks have lasted six months to two years, and the biggest period of time we’ve gone without work is three months. But we understand their need for a contractual safety mechanism which limits their risk.
Our second global client is an insurance claims innovator. They required 20 Helmes team members to serve their needs during the first year they outsourced peak work to us. Today, 10 years later, their IT needs have grown, and recruiting IT workers has become more difficult for them. To serve this client Helmes uses a team of 120 people, many from our office in Minsk, Belarus. The solutions we produce for this client help their customers manage motor vehicle-related claims and are used in Australia, the US, Switzerland, Spain, and many other countries.
Personally, I don’t mind these maybe-not-forever business relationships. I love the honesty, and I respect my clients’ desire for absolute clarity. I know the risks and can plan for them.
Some clients fear sending work out of house means they lose control. But the irony here is that technology enables an amazing degree of transparency and allows a client to retain whatever degree of control is desired.
If a client wishes, we have the ability to show him what every member of his Helmes team is doing at any given moment. Beyond the weekly meetings with team leaders, the client can monitor Jira boards and watch daily stand-ups where every team member reports.
We even offer the possibility for the client to work in our office – he may even bring a few of his own team members.
There isn’t the risk of running over budget, because client approval is required to do so. And on some fixed-price contracts, we’re required to take responsibility for any overages.
It often happens that a company gets a new CTO who wants to bring IT in-house. But I find that CTOs who do so in the name of control usually end up coming back to us. They sometimes discover they don’t have the in-house capacity they thought they had, or they’re unable to recruit the right team. There are a number of reasons for it, but they do often end up returning.
There’s absolutely nothing wrong with worrying about keeping control. Clients often have very good reasons for wanting to keep development in-house. If you’re a tech company and you lack an in-house development team, this may reduce the company’s valuation. But for most companies in most situations, loss of control isn’t an argument for avoiding outsourcing.
The idea that externals are more expensive than internals is widespread but it’s usually false. Going out of house simply does not generate savings.
Can you really make a business case for building an in-house team and then letting a part of that team go when the larger part of a project is finished? In most countries in Europe, letting employees go is extremely expensive. Also, what will this do to your company’s morale? What will workers who remain think of a profitable company firing people? Also, what about holiday pay and covering the costs of employee sick days? It’s important to make sure that all the costs of an in-house team are factored into your analysis.
Let me suggest an approach for determining whether going out of house is expensive: Ask both Helmes and your internal team to bid on a project. Once you have both proposals in front of you, we’ll help you examine the two to make sure you’re comparing apples to apples. I think you’ll be surprised.
What else may surprise you
To be among the top in the world we all have to focus on our core business. Over time, you’ve likely invested millions to make sure your company is the very best at what you do.
Helmes is no different. IT is our core competence. On a per person level, it’s highly likely we’ve invested far more in our IT people than your company would be able to justify investing in yours. And since software development is what we eat and breathe, we’re probably better at it than you are.
- First, keep in mind that we’re also running a business. A bad project for us means not only a financial loss – it means a demotivated team. And in the software world, the team is everything!
- Second, know that we’re aware that if you’re not successful our relationship won’t last. We’re always asking ourselves: Are we doing the right thing to address the business need? This is our biggest worry.
Finally, know that we truly do live vicariously through our clients’ success: it just feels great when a business takes off and flies.
Three Helmes approaches, their plusses and minuses.
The full Helmes service model
In this model the Helmes team takes full responsibility of the development scope, the solution delivery, and post-launch support. All team roles are fulfilled by Helmes and the team works at Helmes’ premises. This model is our preference, because the deliverables are in our control. Our work model is highly refined and proven to deliver on time and on budget. It allows us to work in what we call the Helmes Way, and it’s the reason great people come to work for us.
In this model Helmes becomes an extension of our customer’s teams. A customer may have three developers, we’ll add three of our own, and work with the same agile routines, common sprints, and goals. This model isn’t ideal for all, but for some it’s ideal. We work with OECD Paris in exactly this fashion.
The Quickstart model is a good way to launch a project. We take our senior people to the client, work together to define their needs, and attend workshops to learn their business. Trust is built quickly which allows us to work at the fastest possible pace. This is done at our expense and is an investment in our client’s business, but it is a transitional model, which is intended to quickly shift to one of the other models mentioned above.