Customers only want their own functional changes
By Jan Verlaan on Tuesday 16 August 2011, 13:12 - Maintenance Policies - Permalink
A customer only wants you to build his requested functional fchanges and not those of other customers. A functional change, especially an unexpected one, could severely upset the customer system or his systematics.
You have to decide how you will coop with such requests. Keep in mind that there will always be a big grey area. An area under the influences of threats of contracts breaches or lawsuits.When to consider and when not
Do not consider functional changes for products without any development and no sight of profit. What's the use?
Functional Changes could be considered for products without any development but with clear sight of profit (extend of Support and Maintenance contracts for example). It speaks for it self to pick the functional changes well. Only take those to keep money coming in.
Functional Changes could be considered for products that have development activities. You always have to question your self if the version in maintenance mode is the place to introduce a functional change. A product in development mode is of course the place to introduce new functionality (and thus functional changes). The new functionality of course must be in line with your plans of product growth.
Inform your customer well and upfront
When you introduce a functional change in a product in maintenance mode make sure you inform all your customers well. The customer had to digest the change in his organization when he upgrade to the latest version of the software. Sometime procedures have to be changes, personnel updated, night jobs adjusted, etc. Your customer will not be amused when he was not informed upfront and proper.
Choose your functional changes well
Customers would like to see only their own requests implemented. Those of other customers are not necessary for them and sometimes even annoying or even desasteurus. If you do allow functional changes in products in maintenance mode select them well. Your customization department will fllourish when your only build functional changes in products in development mode. Another way of making money.
There are several kinds of functional changes. You could divide them into the following groups:
- Small (and low impact) functional changes
- User-friendly
- Increases Usability
- Performance improvements
- No notice hardly harms your customer
- Large functional change
- Significant changes in the functionality
- No notice harms your customer
- New functionality
- Significant addition to the functionality
- Legal requirements
- No notice harms your customer
Risks of functional Changes
When a Functional change is added in a released product you have to be aware of the following risks:
- Incompatibility with other products that are integrated into your product
- Disturbance in the development of future versions
- Additional Training is required for Support and Customers
- Customers have to adjust their customizations
- Reconfigurations of tables is risky and time-consuming
- Unexpected changes in the functionality when customers are not informed well upfront
- Not all customers are interested
- More complex data migration
From this risk perspective Small functional changes could occur often to support the customer satisfaction level. Large and New functionality should be avoided as much as possible.