Should you recruit an in-house developer for your CRM system?

May 2, 2018 Richard Boardman

I’ve had a few conversations in recent weeks with organisations who are considering recruiting an in-house developer for their CRM system, rather than use, or solely use, the services of a third-party implementer.  Please note I’m referring to the in-house developer implementing a commercial CRM application such as Salesforce.com or Microsoft Dynamics, rather than a custom system development (an approach I will discuss in a future post). So here are my thoughts on the pro’s and con’s of in-house CRM developer approach.

Pro’s

Cost – In principal the effective day rate for an inhouse CRM developer will be a lot cheaper than for an external resource. So, if we assumed a fully landed cost (i.e. factoring in employers national insurance, benefits, and other employee costs) for a developer of £60,000 per year, the day rate equates to around £260.

By contrast an external implementation company is generally going to be charging in the region of £800 – £1,000 per day, so, on the surface at least there’s quite a potential saving.

Harmony – I think one of the big potential pluses of having an in-house development resource is that it’s generally easier to work with them than an external development company. The relationship between the client and the implementation company can often become pretty fraught as each seeks to protect its commercial interests.

By contrast the internal developer is already paid for, and this can create a more cooperative, harmonious environment, which may be the difference between getting a project over the line or not.

Responsiveness – If you’re paying the developers salary, in principle you’ve got the option to use their time as you want. If an urgent requirement crops up, you don’t have to wait for the implementation company to assess the requirement and assign a resource – which might potentially take days or weeks depending on their workload – you can simply reprioritise their work. This can be an important consideration, particularly if the system is mission critical to the operation of the business.

Better fit – Because an in-house developer’s salary is a sunk rather than variable cost, there’s considerably less friction involved in making use of the resource compared to using the services of an implementer, where you may have to seek quotes, get the work signed off, issue purchase orders etc. This means that in-house developed systems tend to be better tuned to the needs of the users because it’s easier to get, particularly minor, tweaks and enhancements authorised.

Con’s

Do you have the work? – Employing an in-house CRM developer is only going to be a cost-effective approach for larger projects. The £260 per day rate I mentioned earlier is based on around 230 days of development per year. If the development requirement is actually only 100 days per year, the effective day rate becomes £600 per day, or if it’s only 50 days the rate becomes £1,200.

It’s worth also worth noting that people tend to overestimate the amount of pure development time involved in the typical CRM system implementation. The reality is that a CRM system implementation involves a broad spectrum of skills, such as business analysis, project management, system administration and training. Development time may actually be a relatively small sub-set of the total.

This is less of an issue if the developer is multi-skilled and can take some or all of these other areas on, but, in my experience, these are pretty rare beasts. As a result, I’ve seen a lot of situations where in-house developers are clearly heavily under-employed, and, from a cost perspective at least, the employer would do better to work with an external implementation partner.

You take on the responsibility – If you’re employing the developer, then you’ve got limited come back if things go wrong. If an implementer messes up, they’re generally going to be liable for sorting things out. If the in-house developer proves incompetent, loses the plot, makes a major error, then you have to live with the consequences. This is a particular risk if you don’t have the skills or experience in-house to effectively manage the developer.

Overengineering – One of the side-effects of having a potential abundance of development resource is that it can result in overengineering, particularly if this involves lots of custom development work. This can result in a system that’s difficult to upgrade, and complex to support, without necessarily adding significant value to the system itself.

Overall, I’d say the cost argument for recruiting in-house developers is generally weak, given that there needs to be a big development requirement to make the sums work. If it’s a mission-critical system, you could certainly argue the case that an in-house capability may be more responsive to issues and new requirements, and that the easy access to resources may produce a better tuned system. But there’s a lot of risk involved with the approach. Hire the wrong person and these potential benefits could evaporate very quickly.