Unraveling Software Configuration vs Customization

Laura Murphy

One of the common themes I heard during NAEM’s EHS MIS Workshop last March was the question, “Was this configured or customized?”

While presenting to her peers, Patty Miceli used an analogy to describe the philosophy on software customization that her team practiced during the implementation:

“Customization is like shopping at Niemen Marcus. It’s fun to walk by and look in the windows and maybe even go inside and look around. But my experience (and my husband) always tells me to put that credit card away and keep walking.”

Following this anecdote, along with the chuckling, I noticed a lot of head nodding around the room. In presentations thereafter, someone in the crowd invariably raised their hand and asked if the system (or a specific feature) was configured or customized. It was clear the general audience accepted this as an important question, and it also seemed generally accepted that “configuration” was the right answer.

But I had to wonder, does everyone truly understand this technical distinction?

I was surprised that this question was never raised or discussed. If that is because everyone understands this distinction, do we all accept the same definitions and differentiators? Is there a common understanding of the specific pros and cons of each approach? Is everyone who asks this basic question able to drill down to specific questions that reveal to what extent a system would need to be configured and customized to meet their objectives? Because without this understanding, the basic question is arguably a vague one open to much interpretation.

These uncertainties led me to a discussion with our Chief Architect, Jack Jones, and some of our customers who were in attendance at the workshop. We decided to write a white paper to outline the facts as well as our perspective  on the subject. 

In a nutshell, yes, the generally accepted rule is to avoid customization. This will keep your implementation simple, your costs down, and your upgrade path unconstrained. However, there are certain circumstances in which some level of customization may not necessarily be the wrong answer. If customization is determined to be necessary or add sufficient value, the key is to understand how it is managed within the infrastructure of the core system, and exactly what the implications and risks are for implementation, maintenance and support.

What are your experiences with customizing or configuring software to fit your needs? Any lessons you think could be valuable to those going through the selection or implementation process  today?


About Laura Murphy

Laura Murphy is the Vice President of Customer Experience at VelocityEHS (formerly KMI). With 17 years’ experience in the EHS&S software industry, she is a passionate promoter of user‐centered design and data visualization best practices, and specializes in system design for incident management, audit & inspections, compliance, training and sustainability.

View all post by Laura Murphy »

  1. Rick Lebherz

    August 4, 2011

    Thank you for sharing this one. As a sales person for EHS and Sustainability software we use these terms often, and it is nice to know that some people understand their is truly a difference. IMHO it comes down to configuration means we have what you need today, but we have to do some minor changes to make it work for what you want. Customization means we have don’t have what you want and will have to build it special for you.

    I also agree that while configuration is preferred some customization might not be a bad thing depending on the overall value it will add to your organization.

    Another key aspect along those lines to keep in mind, and ask is the process by which both of these happen and the general timelines associated with both. Then try to keep your vendor honest and working towards those dates. Some software applications are a pain to change anything, if you want it this is what you get. If you want to change anything we have to make changes at a pretty deep level in the application which means developers time and resources are going to cost you. Other applications have considered the need for flexibility and making some pretty standard changes and ‘configurations’ without having to really get deep into the program.

    I would use the analogy of customizing a truck. If you are unable to find that exact model with the features you want/need, you should prioritize based on what you know you have as is and what will need to be done. What is the level of effort and how much time and money will it cost to make changes you want to make. (also keep in mind wants vs needs) If you find one that matches all your criteria except the lift or the tint, those arent huge factors. But if you buy the base model and try to make all the changes, it would take more time and effort to get what you want.

    Good luck to everyone out there.

  2. tanyacharles11

    August 4, 2011

    Thanks for this great article. I believe that to truly break the mold into sustainable innovation come customization is necessary. One thing to make sure of when you are deciding between customization and configuration is that you have done your research. Make sure you check to see if anyone else has done a similar implementation, and make sure the company is willing to support any customization with upgrades!

Leave your comment