Despite the mantra of vanilla, customizing packaged software is an expectation of implementation. After all, it is ‘packaged’ software and designed to meet the majority of requirements across businesses functions or industries. According to the 2011 Panorama Consulting Group ERP Report, 15-percent of companies did not customize their ERP software with the remaining 85-percent choosing some level of customization: 37% chose minor customization (1-10% of code modified), 33% had “some” customization (11-25% of code modified) and 15% reported significant or extremely customized solutions with > 25% of code modified (2011 ERP Report, Panorama Consulting).
However, when it comes to analyzing customizations, most project team’s do not conduct a traditional ROI analysis, but rather rely on a more subjective cost / benefit analysis that focuses on the impact to the project instead of return on investment. Typically, this approach has been sufficient because there is a portion of the implementation budget allocated towards customizations and the ratio of customization costs to overall costs is small. Although this approach has typically been sufficient for the project team, it may not be in the best long term interest of the organizations as 58% of organizations fail to realize more than 50% of the anticipated benefits from their enterprise software applications (2011 ERP Report, Panorama Consulting).
Since every situation is different, organizations and project teams should plan for software customization and should approach decisions regarding customization based on multiple factors including: impact on project (time, scope and budget), impact on the organization (support costs, upgrade, development organization maturity) and impact on the product (product maturity and delivery model) against the ability of the implemented system to deliver the anticipated benefits as outlined in the original system ROI analysis and cost justification.
For significant decisions not to customize the software that impact desired business process improvements, organizations should also consider the cost of not customizing and adopting the software as is. In some cases, staying vanilla may yield short term results to the project team, but may hinder user acceptance or result in data entry errors that translate to additional support and training costs. This is often the case as project teams routinely underestimate the technology skill sets of end users and complexity of adopting complex business processes to meet the requirements of the software.
Therein lays the delicate balance: the impact of the customization on the project and on-going support costs versus the ability of the system to provide business process improvements which may require customization.
While I am not advocating making major customizations to packaged software, I am arguing for a comprehensive decision process earlier in the project lifecycle that considers both the impact on the project as well as long term business benefits. Too often, decisions regarding software customization are approached from the perspective of the project team and driven by the impact on the project scope, costs and timeline. Typically, this analysis serves organization with business requirements that meet vanilla software functionality, but it may not be sufficient for organizations with moderate to significant gaps between business requirements and software functionality. In either case, organization need to incorporate analyzing potential customization costs as part of the project planning and software acquisition phases to ensure adequate project resources to address functionality gaps as well as downstream impacts to project scope, timeline and costs.
