Customization in the general sense has a very positive connotation. Whether it be a tailored suit, or that new motorcycle you have been building in your mind for 20 years, the concept of a custom fit undoubtedly tugs on the heartstrings of any lover of bespoke things. However, in the world of software systems, customization quite often falls short of customer expectations.
Throughout the 1980’s and 90’s, custom software systems were the go-to choice for IT departments. They provided 100% flexibility, and with very limited off-the-shelf products available there was not much of an alternative. Over the last few decades, with companies such as Salesforce.com leading the way, there are now many off-the-shelf products IT departments can choose from that are feature rich and significantly more affordable than custom systems, while still maintaining high flexibility.
Most industries have shifted to purchasing these standard products vs. custom building an application, however in insurance there is still sometimes a desire to purchase a custom application.
In this blog we will explore the hidden costs of custom software systems in insurance and how they have inundated the industry for decades. But first, we must explore the very meaning of a custom system.
The true definition of “custom” in software infers that programmers are building/coding an application to specifications provided by the customer. For example, Carrier A determines that they want feature X, detailed requirements are then written, programmers build/program the functionality, QA team members test it, a project manager oversees them, and after successful testing, the new feature is promoted to the application. This happens again and again for every feature the customer requires.
To provide a comparison to off-the-shelf products, instead of the user having to define all the features they want, the product comes “off-the-shelf” with a set of features which can be customized through easy-to-use tools such as drag/drop functionality – (picture how you upload photos to Facebook today by dragging them over, vs. if you had to write a programming script to take photos off your phone and upload them online.).
The one advantage of custom systems is that they provide users 100% exactly what they’re looking for, however there are quite a few risks/cons from cost overruns and time delays which we will discuss further here. More people are referring to custom systems as the ‘iceberg’ model, due to the fact that quite often the majority of the cost of a custom system is unknown/unseen initially.
Let’s untie the main areas where cost can be hidden in a custom software project:
This is typically the largest cost associated with a custom system. You have been sold on the system of your dreams because anything can be built (but cannot always be delivered). Annual costs seem minimal and when you look at your 5-10 year total cost of ownership this model seems mightily appealing. Most costs are in Year 1 as the system is built, but in Year 2+ costs are projected to be very low, due to an assumption that nothing major will go wrong. However, as any pioneer that has gone where no person has gone before can tell you; there will be setbacks, there will be the unexpected. The unexpected (in this case referring to bugs, defects, functionality not originally thought of, etc.) is impossible to quantify and adds a huge element of risk and cost to your project rollout, not only in terms of capital but also in terms of time.
Consider the below stats:
- 68% of IT projects are ‘improbable’ in terms of successful completion.1
- Project failure, unplanned work, and rework account for a global yearly waste of $980 billion.2 (Only 15 countries in the world have an annual GDP higher than this3).
- On average, IT projects of considerable size typically exceed their budgets by 45% and their schedules by 7%, while delivering 56% less value than originally predicted. 4
It’s also important to recognize the cost of internal resources that are working on this project. Your time is valuable, and many times on a custom project you are sucked in to spending 25%+ of your time thinking of features you want, defining requirements, helping test, etc. This is time that is being taken away from your primary focus, which can also have negative effects on your day job.
Unfortunately, this time commitment is typically not for just a few weeks either. Instead, custom projects in insurance typically run well over 1+ years and sometimes turn into multi-year projects when originally projected to be 6-9 months.
Ongoing professional services:
Once a system is built and being used in production, it is common to require changes from time-to-time. Unfortunately even minor items (adding a new field, changing a template, etc.), are not something you have access to do on your own, and it requires you to go back to the vendor who built the application. The bug you didn’t identify during implementation. The use-case you didn’t anticipate during your requirements-gathering process or GAP analysis. The limitation you were not made aware of during the sales cycle. These things happen and they are expensive. Inherent to the custom software model, across industries, is that the client is frequently billed for almost every interaction after implementation in 15-minute increments. A financial slap on the wrist, if you will, for reaching out to the very originators of the problem you are experiencing. This can cause some strife in the relationship to say the least.
All software systems will require upgrades at some point. Sometimes it’s for maintenance and issues, but more important is as industries evolve, new features are required to ensure your business stays current and competitive (or more ideally, ahead of the curve).
In a custom system environment, upgrades are NOT included. The vendor you chose to build the system charges you for every hour they spend working on the system. So when it comes time to upgrade, the onus is on you to first think of what those new features should be. This means you need to stay up-to-date on industry trends, know what your competition is doing, and then work with your vendor to write up specifications for those features. So if you decide down the road you need new features, you will pay a hefty bill. Custom systems get stale, whether it be in 5 years, or 10 years, they need updating. Due to the nature of custom code, in order to obtain these changes/updates, quite often it is easier to throw the entire platform away and begin again the repetitious custom cycle. Rinse and repeat on the hidden implementation costs and ongoing professional services that are described above. If the option to ‘upgrade’ your existing platform is selected as the preferred route the client receives the bill (usually similar to that of implementing the entire solution in the first place).
For those of you reading this that have gone through a custom software project I do apologize for the re-opening of nearly-healed scars, the intent is to inform those that have not yet taken such a plunge. I digress to the extent that there can be some benefits to a custom approach, for those requiring very complex functionality, not before seen. However, in insurance workflow tools, this is a very select grouping especially when considering that there are systems flexible enough to support thousands of workflows without any code modification.
Let us briefly explore the alternative:
Instead of buying a custom product, you pick a vendor who already has built out a product with all the functionality/features that you require. The product typically has a configuration module, which allows you to tweak/modify the system using simple, business friendly screens. The software has been refined over dozens of iterations and versions, which has added stability and robustness to the platform. Their entire client base has tested every nook and cranny of the solution and if there were bugs, they have been fixed. The system will also continually be updated, not just from your ideas, but from the best practices of all the customers. Finally, there are typically no ongoing services costs, which means you can call the vendor as much as you’d like and never receive a bill!
I hope the perspective was helpful,
- Krigsman, Michael. "Study: 68 Percent of IT Projects Fail | ZDNet." ZDNet. Accessed March 22, 2016. http://www.zdnet.com/article/study-68-percent-of-it-projects-fail/.
- Krigsman, Michael. "Worldwide Cost of IT Failure (revisited): $3 Trillion | ZDNet." ZDNet. Accessed March 22, 2016. http://www.zdnet.com/article/worldwide-cost-of-it-failure-revisited-3-trillion/.
- "Gross Domestic Product 2014." World Development Indicators Database, World Bank, February 17, 2016. Accessed March 22, 2016. http://databank.worldbank.org/data/download/GDP.pdf.
- Bloch, Michael, Sven Blumberg, and Jürgen Laartz. "Delivering Large-scale IT Projects on Time, on Budget, and on Value." McKinsey on Business Technology, no. 27, Fall (2012): 2-7. Accessed March 22, 2016.