Unraveling Software Configuration vs Customization
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?
Related
About the Author
Laura Murphy
VelocityEHS
Laura is Vice President of Customer Experience at VelocityEHS Canada. She has worked in the EHS software industry since the mid-’90s and joined EHS software provider KMI at its inception in 1999. Laura’s professional experience spans software implementations, design, product management and the systemic user experience. She specializes in datavisualization, strategic planning and translating EHS business needs to software solutions. She has served as Affiliates Council President at the National Association for Environmental Management (NAEM) since January 2015. Laura holds a Bachelor’s degree in Environmental Studies and Resource Management from the University of Toronto.