Staying OOB - Insights
Factors influencing client choices between staying OOB and customization in COTS implementation
- Devil in the detail
- Performance and Product support
- Total Cost for customization
- Client stakeholder's involvement in the project
Devil in the detail - Clients with no previous experience with Component-Off-The-Shelf (COTS) products need to understand that while such products offer tremendous scope for a rapid implementation, processes and work flows need to be adapted to the product to take advantage of the same. Architectural and solution decisions that are taken early on need to consider the product features in detail; otherwise decisions can be made that will result in customization. This needs to be done early on in order to build the mindset necessary for critical analysis of requirements and adapting the same to the product.
Performance and Product support - Customization of a product results in moving away from the more Product vendor's tested product performance parameters and the support that the client is already paying for. Every customization adds its own challenges in getting the product to work and has performance implications as well. Therefore even for customizations, one should stay within the boundaries of the product framework.
Total Cost for customization - While products may have features or a framework that make it convenient to customize, it is to be noted that typically only 30% of the effort in a customization is the build effort. Documentation/Impact analysis/Quality Assurance is the remaining 70% of effort. This additional cost of customizations therefore needs to be understood by a client early on before committing to an implementation as it is a major factor in the decision to customise.
Client stakeholder's involvement in the project - The presence of a stakeholder from the Client goes a long way into optimizing the use of product features. Such stakeholders will understand the nuances of business requirements in the early stages of the project. Educating the stakeholder about product features will lead to informative and detailed discussions between the implementation team and the stakeholder wherein requirements are analyzed both in terms of their value to business as well as fit into the product to decide whether to keep or to discard requirements.
Performance and Product support - Customization of a product results in moving away from the more Product vendor's tested product performance parameters and the support that the client is already paying for. Every customization adds its own challenges in getting the product to work and has performance implications as well. Therefore even for customizations, one should stay within the boundaries of the product framework.
Total Cost for customization - While products may have features or a framework that make it convenient to customize, it is to be noted that typically only 30% of the effort in a customization is the build effort. Documentation/Impact analysis/Quality Assurance is the remaining 70% of effort. This additional cost of customizations therefore needs to be understood by a client early on before committing to an implementation as it is a major factor in the decision to customise.
Client stakeholder's involvement in the project - The presence of a stakeholder from the Client goes a long way into optimizing the use of product features. Such stakeholders will understand the nuances of business requirements in the early stages of the project. Educating the stakeholder about product features will lead to informative and detailed discussions between the implementation team and the stakeholder wherein requirements are analyzed both in terms of their value to business as well as fit into the product to decide whether to keep or to discard requirements.
Comments
Very relevant comments CD. Thanks for posting Bharat's thoughts. While the usual argument against customization is on weaking the product, affecting the performance and ability to convince the business owners, I was particularly struck by the point on the mistake of assuming customization effort means just build. Creating an appetite for changing the business process where it makes sense needs committed support from senior management. I recall a customer who had several different varieties of order types with very similar process pipelines, many of which could've been compressed easily, but that meant a rewiring the thought process of all folks in the logistics, warehousing and order mgmt teams and hence the initiative died an early death. The result as mentioned was more code, more build effort, more documentation, more testing and more interdependencies of shared components across different processes.
Posted by: Gopi Krishnan | November 1, 2010 8:29 PM