How can you measure the value you get for that software product maintenance contract?

It ebbs and flows with the strength of the market and the flair of the account managers, but if you have acquired a software product from a vendor at any time, you are probably paying somewhere between 15% and 20% of the original price in "software maintenance" fees per year. Why? There are two different answers:  Answer #1 is the one that you hear from the vendors - it's for receiving new releases on a regular basis with bug fixes and innovative updates to the product.  I know this one well - I have said it myself often enough in my prior lives and tried to keep a straight face.  There are a number of problems with Answer #1.  Why is software development the only industry that requires its customers to continue paying for its mistakes? But software is complicated - yes, that's why customers paid the big bucks for vendors to employ all those highly paid developers in the first place.  Why do customers have to incur the costs and risks of updating their production software at a frequency driven by their vendors and pay for the privilege? If they don't upgrade , they cant reasonably expect the vendor to debug their problems, can they? Answer #2 is the answer I researched after trying to defend the software vendor line one too many times - wait for it - Answer #2 is that nobody knows.  There is no reason for the existence of software maintenance fees and no reason for choosing 20%.  Like the invention of the wheel, it seems that one day someone came up with it and it has been with us ever since. The situation has really bothered me for some time but I guess that old age and the emergence of SaaS have dimmed my crusading passion on this issue until an article in InformationWeek by Mary Hayes Weier got my blood boiling again. So how can you measure the value that you are getting from software product maintenance projects? I recommend a risk management + cost-benefit approach.  Lets make the assumption that you have this software in production so it works and does not crash too frequently.  Lets ask ourselves the question: Is it worth paying the next maintenance contract fee? On the cost-benefit side, work out the total costs of having the maintenance contract.  This must include the cost of loading new releases into test environments, testing, loading into production environments and any loss of service due to this process.  On the benefit side, calculate the additional revenue (or cost savings) generated by the changes in each new release.  I will be surprised if you can justify the next payment on cost-benefit alone.  If you can, you probably have so many problems with the software in production that you should consider getting rid of the software anyway! So, we need to mix in the risk management component.  What risks are you incurring by not having a maintenance contract and how can you mitigate them.  I don't plan to give you an exhaustive list here but lets consider a few examples. Without a maintenance contract there is a risk that if you have a serious problem, you wont be able to get help.  True but lets think it through.  If you have a serious problem then you cannot wait for the next release.  You need an off-release fix now.  You will have to pay for it but this might actually give you extra leverage because the vendor maintenance staff may only be able to fix bugs in "current" releases anyway.  How much will it cost?  Negotiable but if you don't like the negotiating balance of power when your application is down - try to negotiate pricing with your vendor or a third party in advance.  After all, its the vendors product that has failed! Without a maintenance contract and installation of regular upgrades, you will have a really hard time upgrading every few years when there is something of value in a release.  True.  But lets imagine that happens once every 5 years - save up the 5 years * 20% per year and buy new software every 5 years! Without a maintenance contract, how will all those irritating but not mission-critical Level 3/4  defects get fixed?  Do it yourself.  If you are not taking releases, you don't need to worry about maintaining consistency with the original application. Final thought:  Buy SaaS - I do! Software Maintenance Fees: Time For This Model To Change?

Written by Michael D. Harris at 19:27
Categories :



"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!