Over-Customization

Over-customizing can take you off the upgrade path
or make an upgrade extremely costly

You need staff’s creative ideas for how a new AMS, LMS, or Website can make your organization more effective. The best time to gather these ideas is when you are formulating your initial strategy and creating your requirements document for an RFP. But when it comes to implementing the new system, trying to accomplish all of staff’s hopes and dreams on the initial go-live, and customizing all the capabilities you “might want” in the future, is a risky approach. Attempting to include your entire “wish list” in the initial go-live will unnecessarily increase all of the following:

• Risk of problems (all customizations are subject to glitches, as anyone who tried to use the healthcare.gov website knows)
• Risk of delayed implementation
• Cost of the system
• Burden on staff for acceptance testing (the more customization, the more testing is required)
• Risk of being taken off the vendor’s upgrade path
• Risk that only a few vendor staff will know how to support your system (what happens if/when those people turn over?)

Sure, certain vendors offer toolkits that help preserve the upgrade path, but the more customizing you do, the more cost and associated work will be needed to ensure that new releases will work without problems. More importantly, customizing your system so that it is different from the vendor’s other clients will make you more dependent on the specific vendor’s staff who designed and developed your customizations.

Customizations commit you to a never-ending cycle of testing, verification, and potential re-engineering for each new release

In a worst case scenario, customizations will take you off the upgrade path and prevent you from upgrading to the vendor’s next release. In addition to risking the upgrade path or diminished support, over-customizing is costly and will delay the timeline to go-live.

Best case, you will need to budget for the cost (and time) to test and verify that your customizations work with each new release.

How to avoid over-customizing

Senior management should play a leadership role during the discovery phase. Department directors should be “hands-on” alongside staff during the discovery meetings. Delegating this vital phase of the implementation, or being partially involved, oftentimes increases the risk of over-customizing.


 
Staff must avoid the temptation to recreate the same business processes on the new system as used on the old system. Your focus should be on business process improvement (see Risk #2) rather than asking the vendor to replicate the same functions as your old system. If customizations are identified, the Framework’s ROI Value Analysis and Change Management templates can be used to determine which customizations can be logically justified. The Framework provides the guidance and templates needed to prioritize which customizations are necessary for go‑live, and which can be deferred to a subsequent phase. In the end, it is up to senior management to ensure that the right customizations are done for the right reasons.