December 1, 2020
No Modifications: Avoiding Cost and Complication in Your Software Implementation
You don’t have to complete more than 900 supply chain software implementations to figure out that modifications can add significant time, cost, and trouble to a software deployment or upgrade. Open Sky Group knows. We’ve done over 900 implementations since our founding, and our “No Modifications” software implementation approach has become our best practice, resulting from this rich body of experience.
What do we mean by “modification?”
When you change software to behave differently from the way it was designed to function, you have to change the software’s basic code. As soon as you do that, all sorts of consequences follow. Certainly, the software may do the one thing you wanted it to do differently. But from that point on, other linkages in the software become unrecognizable to the system. Support personnel may not be able to maintain it. Your warranty could be nullified. And in the long-term, new upgrades and integrations may not “take” as they should, because the base code has been fundamentally changed. Any time you introduce even a small modification to your software, the entire ecosystem potentially changes. These changes can trigger a host of cascading effects that can create a minefield of issues for your IT department.
How does the “no modifications” software implementation approach work?
At Open Sky Group, we enter every project with the understanding that there will be no software modifications performed during the implementation process. This level sets our engagement from the get-go, setting upfront expectations that no basic code will be changed. Instead, we rely on the inherent extensibility of the software to accommodate any unusual user requirements. Most software companies are aware that there is no one-size-fits-all way to design a software product. Extensions are intentionally built in to achieve the necessary rightsizing. For instance, a dashboard can be flexibly arranged to provide a unique user view. Or, different functionality can be featured on a screen to accommodate a particular departmental workflow. These changes can be made without modifying the base code allowing the software to better “fit” the company while not rendering the software unsupportable long-term.
Three ways to prepare for a “no modifications” implementation
Our advice to anyone seeking to avoid modifications in software implementations is as follows:
1. Establish ground rules
Come to an agreement within your organization regarding what you will and will not accept in terms of software changes upfront. View your implementation as an “event.” Everyone should be aware that something new is about to take place and now is the time to make any necessary changes. Bring your operations and IT people together, get them to communicate their needs, wants, and desires. Help them to understand that a little flexibility on either side may be all that it takes to circumvent a costly, complicated software modification. Then, nominate a leader to enforce the rules throughout the duration of the project and hold everyone accountable.
2. Put gatekeepers in place
Building on the above, identify those on your team who will have the final say over any product changes that come up during the implementation. This may be a small steering committee of capable leaders with the vision and power to review requests, weigh costs and formulate reasonable compromises. The goal is to ensure that no unwarranted changes proceed without the proper vetting.
3. Remain open-minded
Understand what makes your business unique. Most software today is designed to perform within industry best practices. So, if you feel you need to change it in some way, make sure you are not drifting backward into “the way we’ve always done things.” Stay flexible. Indeed, if you are not doing something according to best practices, ask yourself why? It may be that you have a unique business advantage to preserve. Or, it may be driven by an underlying reluctance to evolve as an organization. Be honest. A frank answer can save you a lot of time and trouble when it comes to software modifications.