In my experience.. Most large software infrastructure product deployments run into the path of becoming non-standard implementations.
IT decision makers are faced with a barrage of requests for customisation even after initial deployment of the product. The pressure of these requests drive even the very seasoned managers in to a trap of massive customisation. These changes end up in the installation without objective evaluation of real and percieved business value and their impact.
This is worse..if the changes are executed during the roll-out or right after....
The resulting deployment is vulnerable and may result in:
1. Lack of Stability
2. Complication in Upgrade path
3. Less security
The Support issues around such implementation cause undue stress on the staff.
The other side of the coin is an arguement about the importance of functionality for improving efficiency and user experience.
A Tight control on the finalization of requirements during pilot phase, A Disciplined approach towards function testing and User Acceptance testing, Feature Benchmarking of Similar sized Application Deployments are key to maintain a healthy balance.
In my opinion, When deploying new products...It is better to err on the side of caution and work work towards implementing a standard out-of-the-box product with minimum customization to ensure a simple, secure and scalable installation.
This Approach can be coupled with stacking up the incoming feature requests and enhance ments requested after the initial roll-out into a planned next revision of the deployment.
In this way.. The change requests can be carefully evaluated by the vendor and the implementation team. They can proiritised based on their impact on simplicity, security and scalability of the deployment.
IT decision makers are faced with a barrage of requests for customisation even after initial deployment of the product. The pressure of these requests drive even the very seasoned managers in to a trap of massive customisation. These changes end up in the installation without objective evaluation of real and percieved business value and their impact.
This is worse..if the changes are executed during the roll-out or right after....
The resulting deployment is vulnerable and may result in:
1. Lack of Stability
2. Complication in Upgrade path
3. Less security
The Support issues around such implementation cause undue stress on the staff.
The other side of the coin is an arguement about the importance of functionality for improving efficiency and user experience.
A Tight control on the finalization of requirements during pilot phase, A Disciplined approach towards function testing and User Acceptance testing, Feature Benchmarking of Similar sized Application Deployments are key to maintain a healthy balance.
In my opinion, When deploying new products...It is better to err on the side of caution and work work towards implementing a standard out-of-the-box product with minimum customization to ensure a simple, secure and scalable installation.
This Approach can be coupled with stacking up the incoming feature requests and enhance ments requested after the initial roll-out into a planned next revision of the deployment.
In this way.. The change requests can be carefully evaluated by the vendor and the implementation team. They can proiritised based on their impact on simplicity, security and scalability of the deployment.
Comments