Software maintenance: client value models
Dennis Howlett has a great post on his ZDNet blog: A fresh model for software maintenance.
He targets a number of things that vendors should do to reduce the cost and burden of software maintenance - treating customers individually, training their resellers and partners better, and helping the customers to build their own centres of excellence so they can support themselves better. The ideas are based in part on
C.K. Prahalad and M.S. Krishnan's book, The New Age of Innovation: Driving Cocreated Value Through Global Networks. Looks like something I should be reading soon.
This is an issue close to my heart, since it is a very sore point for many clients. Software buyers are much more likely to query the maintenance charges than the initial build costs - and yet maintenance seems to be an area where most small software companies don't make any money. Oracle seems to be an exception (Dennis quotes their 30% margins and says that much of it is from maintenance revenues), while SAP has just eliminated its low-cost maintenance models and is moving all its customers onto the top-priced Enterprise support package. Clearly a sensitive area.
Howlett's model seems to provide a good way to control costs by targetting vendors' skills where they bring most value - but we at Inon are starting to pitch our customers on something perhaps even more radical.
We want to charge our clients for support and maintenance according to the measurable value that we create for them. Our clients want three main things from our software:
As the relationship with each client evolves, we're in a better position to know how to achieve those goals and to suggest new things to try. So, why don't we charge them for delivering those exact results?
And after all, that's exactly what the maintenance contract is supposed to provide: maximum revenue by minimising downtime, keeping productivity high by avoiding workarounds and bugs, and making sure the outputs of the system are accurate by preventing errors.
And in this context, why distinguish between maintenance, support and new features? If I have a genuine partnership with my client, and I understand their business, I want to be able to weigh up a new feature idea (which will boost productivity by 8% for 20 users) against a bug fix (which will save 100 users 0.5 hours per week) and decide which one is in the client's interest for to implement first. At the moment I probably have to make the bug fix because it's in the maintenance agreement, and never get to add the new feature because it needs approval of new capital expenditure - or because the client doesn't agree with my estimate of the additional value that it will provide.
I would much rather my client pays me £20,000 for increasing their productivity by 8% than guarantees me £2,900 a quarter for support based on a percentage of their licence fee. This way I am motivated to deliver the best possible service and I will put my efforts in the places where they will bring the best return. What's more, I can make more money this way and it's in my client's interest for me to do so.
As Dennis points out, any model of this kind "requires that vendors have a much clearer understanding of their customers, their levels of competency [and] the value they can deliver". What's more, it requires both parties to agree on a good-faith model for measuring the returns - increased productivity is going to be hard to measure, and if it's not achieved, the vendor can try to blame the incompetence or change resistance of the client's employees. But if both parties trust each other, this simply puts the vendor in the position of having to work constructively with a trainer to get the best outcome for the client. A model that encourages effective working relationships like that is going to produce better results than one that doesn't.
But whatever the additional effort and intellectual difficulty of implementing this, the potential returns can be so spectacularly beyond those of the normal model that it must be worth it. At least for any vendor who can attract staff intelligent and committed enough to make it work. We believe that our revenue, and the money our clients make out of our services, can both more than double by implementing this model.
He targets a number of things that vendors should do to reduce the cost and burden of software maintenance - treating customers individually, training their resellers and partners better, and helping the customers to build their own centres of excellence so they can support themselves better. The ideas are based in part on
C.K. Prahalad and M.S. Krishnan's book, The New Age of Innovation: Driving Cocreated Value Through Global Networks. Looks like something I should be reading soon.
This is an issue close to my heart, since it is a very sore point for many clients. Software buyers are much more likely to query the maintenance charges than the initial build costs - and yet maintenance seems to be an area where most small software companies don't make any money. Oracle seems to be an exception (Dennis quotes their 30% margins and says that much of it is from maintenance revenues), while SAP has just eliminated its low-cost maintenance models and is moving all its customers onto the top-priced Enterprise support package. Clearly a sensitive area.
Howlett's model seems to provide a good way to control costs by targetting vendors' skills where they bring most value - but we at Inon are starting to pitch our customers on something perhaps even more radical.
We want to charge our clients for support and maintenance according to the measurable value that we create for them. Our clients want three main things from our software:
- increased revenue
- increased productivity
- and more accurate figures and reporting
As the relationship with each client evolves, we're in a better position to know how to achieve those goals and to suggest new things to try. So, why don't we charge them for delivering those exact results?
And after all, that's exactly what the maintenance contract is supposed to provide: maximum revenue by minimising downtime, keeping productivity high by avoiding workarounds and bugs, and making sure the outputs of the system are accurate by preventing errors.
And in this context, why distinguish between maintenance, support and new features? If I have a genuine partnership with my client, and I understand their business, I want to be able to weigh up a new feature idea (which will boost productivity by 8% for 20 users) against a bug fix (which will save 100 users 0.5 hours per week) and decide which one is in the client's interest for to implement first. At the moment I probably have to make the bug fix because it's in the maintenance agreement, and never get to add the new feature because it needs approval of new capital expenditure - or because the client doesn't agree with my estimate of the additional value that it will provide.
I would much rather my client pays me £20,000 for increasing their productivity by 8% than guarantees me £2,900 a quarter for support based on a percentage of their licence fee. This way I am motivated to deliver the best possible service and I will put my efforts in the places where they will bring the best return. What's more, I can make more money this way and it's in my client's interest for me to do so.
As Dennis points out, any model of this kind "requires that vendors have a much clearer understanding of their customers, their levels of competency [and] the value they can deliver". What's more, it requires both parties to agree on a good-faith model for measuring the returns - increased productivity is going to be hard to measure, and if it's not achieved, the vendor can try to blame the incompetence or change resistance of the client's employees. But if both parties trust each other, this simply puts the vendor in the position of having to work constructively with a trainer to get the best outcome for the client. A model that encourages effective working relationships like that is going to produce better results than one that doesn't.
But whatever the additional effort and intellectual difficulty of implementing this, the potential returns can be so spectacularly beyond those of the normal model that it must be worth it. At least for any vendor who can attract staff intelligent and committed enough to make it work. We believe that our revenue, and the money our clients make out of our services, can both more than double by implementing this model.
Comments