Return to Answer

The ROI for individual features or improvements is often hard to put in numbers. However, lots of organizations understand that when they have ordered some kind software made for their specific business, which saves them a certain amount of money X every year, that it makes sense to reinvest a certain percentage of X into maintenance and evolvement of that software. This will even more apply when the software will return some license fee Y every year, then the percentage should refer to "X+Y".

How large this percentage should be, however, is a strategic decision, since many of the effects of small incremental improvements will show their value only after a longer period. The very minimum, however, is the percentage to cap the maintenance cost required to make sure the monthly bugs in the application get fixed, and the software gets adapted to environmental changes (like new OS versions, new versions of platforms to interact with, security fixes, changes in 3rd party base libraries, and so on).

Hence there usually needs to be someone who gets paid for doing the maintenance. That's a good basis for a synergy effect - paying a regularly yearly fee not just for for maintenance, but also for and evolvement, makes it possible for the maintainer to have someone on the payroll who has the actual knowledge for further development of the product. If your organization is only willing to pay maintenance cost when a bug occurs or a new OS version comes to the market, and the maintainer has to rebuild the knowledge for changing the slightest things in the software every year, because they don't have a few dedicated persons for this job, this can become a lot more expensive for your organization then if they invest some money regularly for maintenance and evolvement on the basis of a fixed budget per year.

As an example, just look at the companies who made the failure of let themselves develop individual software for platforms like Windows XP or the old Internet Explorer 6.0, and forgot to make contracts to keep this software up-to-date - they now face a huge problem to get a replacement on a modern OS or browser, which often will cost them way more money in total than if they had done some strategic investment earlier.

So in short, I would not try to calculate the ROI for small individual features. Try to make your organizational leaders become aware of the bigger picture, hope they are open for strategic thinking, and try to convince them to make a strategic yearly reinvest of a certain percentage of "X+Y".

Note: I found a very interesting related article about prioritizing features, which talks about why "ROI" is not a good metrics for prioritizing the backlog, and introduces a different model ("cost on delay"), maybe it is useful for you.

The ROI for individual features or improvements is often hard to put in numbers. However, lots of organizations understand that when they have ordered some kind software made for their specific business, which saves them a certain amount of money X every year, that it makes sense to reinvest a certain percentage of X into maintenance and evolvement of that software. This will even more apply when the software will return some license fee Y every year, then the percentage should refer to "X+Y".

How large this percentage should be, however, is a strategic decision, since many of the effects of small incremental improvements will show their value only after a longer period. The very minimum, however, is the percentage to cap the maintenance cost required to make sure the monthly bugs in the application get fixed, and the software gets adapted to environmental changes (like new OS versions, new versions of platforms to interact with, security fixes, changes in 3rd party base libraries, and so on).

Hence there usually needs to be someone who gets paid for doing the maintenance. That's a good basis for getting a synergy effect - paying a regularly yearly fee not just for maintenance, but also for evolvement, makes it possible for the maintainer to have someone on the payroll who keeps the actual knowledge for further development of the product. If your organization is only willing to pay the absolutely minimal maintenance fee, maybe only on-demand when a bug occurs or a new OS version comes to the market, and the maintainer has to rebuild the knowledge for changing things in the software every year, because they don't have a few dedicated persons for this job, this can become a lot more expensive for your organization than if they invest some money regularly for maintenance and evolvement on the basis of a fixed budget per year.

As an example, just look at the companies who made the failure of let themselves develop individual software for platforms like Windows XP or the old Internet Explorer 6.0, and forgot to make contracts to keep this software up-to-date - they now face a huge problem to get a replacement on a modern OS or browser. Such decisions can finally cost them way more money in total than if they had done some strategic investment earlier.

So in short, I would not try to calculate the ROI for small individual features. Try to make your organizational leaders become aware of the bigger picture, hope they are open for strategic thinking, and try to convince them to make a strategic yearly reinvest of a certain percentage of "X+Y".

Note: I found a very interesting related article about prioritizing features, which talks about why "ROI" is not a good metrics for prioritizing the backlog, and introduces a different model ("cost on delay"), maybe it is useful for you.

The ROI for individual features or improvements is often hard to put in numbers. However, lots of organizations understand that when they have ordered some kind software made for their specific business, which saves them a certain amount of money X every year, that it makes sense to reinvest a certain percentage of X into maintenance and evolvement of that software. This will even more apply when the software will return some license fee Y every year, then the percentage should refer to "X+Y".

How large this percentage should be, however, is a strategic decision, since many of the effects of small incremental improvements will show their value only after a longer period. The very minimum, however, is the percentage to cap the maintenance cost required to make sure the bugs in the application get fixed, and the software gets adapted to environmental changes (the usual operational requirements like new OS versions, security fixes, security fixes in 3rd party products and so on).

Hence there usually needs to be someone who gets paid for doing the maintenance. That's a good basis for a synergy effect - paying a regularly yearly fee for maintenance and evolvement makes it possible for the maintainer to have someone on the payroll who has the actual knowledge for further development of the product. If your organization is only willing to pay maintenance cost when a bug occurs or a new OS version comes to the market, and the maintainer has to rebuild the knowledge for the development every year, because they don't have a few dedicated persons for this job, this can become a lot more expensive for your organization then if they invest some money regularly for maintenance and evolvement on the basis of a fixed budget per year.

As an example, just look at the companies who made the failure of let themselves develop individual software for platforms like Windows XP or the old Internet Explorer 6.0, and forgot to make contracts to keep this software up-to-date - they now face a huge problem to get a replacement on a modern OS or browser, which often will cost them way more money in total than if they had done some strategic investment earlier.

So in short, I would not try to calculate the ROI for small individual features. Try to make your organizational leaders become aware of the bigger picture, hope they are open for strategic thinking, and try to convince them to make a strategic yearly reinvest of a certain percentage of "X+Y".

Note: I found a very interesting related article about prioritizing features, which talks about why "ROI" is not a good metrics for prioritizing the backlog, and introduces a different model ("cost on delay"), maybe it is useful for you.

The ROI for individual features or improvements is often hard to put in numbers. However, lots of organizations understand that when they have ordered some kind software made for their specific business, which saves them a certain amount of money X every year, that it makes sense to reinvest a certain percentage of X into maintenance and evolvement of that software. This will even more apply when the software will return some license fee Y every year, then the percentage should refer to "X+Y".

How large this percentage should be, however, is a strategic decision, since many of the effects of small incremental improvements will show their value only after a longer period. The very minimum, however, is the percentage to cap the maintenance cost required to make sure the monthly bugs in the application get fixed, and the software gets adapted to environmental changes (like new OS versions, new versions of platforms to interact with, security fixes, changes in 3rd party base libraries, and so on).

Hence there usually needs to be someone who gets paid for doing the maintenance. That's a good basis for a synergy effect - paying a regularly yearly fee not just for for maintenance, but also for and evolvement, makes it possible for the maintainer to have someone on the payroll who has the actual knowledge for further development of the product. If your organization is only willing to pay maintenance cost when a bug occurs or a new OS version comes to the market, and the maintainer has to rebuild the knowledge for changing the slightest things in the software every year, because they don't have a few dedicated persons for this job, this can become a lot more expensive for your organization then if they invest some money regularly for maintenance and evolvement on the basis of a fixed budget per year.

As an example, just look at the companies who made the failure of let themselves develop individual software for platforms like Windows XP or the old Internet Explorer 6.0, and forgot to make contracts to keep this software up-to-date - they now face a huge problem to get a replacement on a modern OS or browser, which often will cost them way more money in total than if they had done some strategic investment earlier.

So in short, I would not try to calculate the ROI for small individual features. Try to make your organizational leaders become aware of the bigger picture, hope they are open for strategic thinking, and try to convince them to make a strategic yearly reinvest of a certain percentage of "X+Y".

Note: I found a very interesting related article about prioritizing features, which talks about why "ROI" is not a good metrics for prioritizing the backlog, and introduces a different model ("cost on delay"), maybe it is useful for you.

The ROI for individual features or improvements is often hard to put in numbers. However, lots of organizations understand that when they have ordered some kind software made for their specific business, which saves them a certain amount of money X every year, that it makes sense to reinvest a certain percentage of X into maintenance and evolvement of that software. This will even more apply when the software will return some license fee Y every year, then the percentage should refer to "X+Y".

How large this percentage should be, however, is a strategic decision, since many of the effects of small incremental improvements will show their value only after a longer period. The very minimum, however, is the percentage to cap the maintenance cost required to make sure the bugs in the application get fixed, and the software gets adapted to environmental changes (the usual operational requirements like new OS versions, security fixes, security fixes in 3rd party products and so on).

Hence there will usually someone who gets paid for doing the maintenance. That's a good basis for a synergy effect - paying a regularly yearly fee for maintenance and evolvement makes it possible for the maintainer to have someone on the payroll who has the actual knowledge for further development of the product. If your organization is only willing to pay maintenance cost when a bug occurs or a new OS version comes to the market, and the maintainer has to rebuild the knowledge for the development every year, because they don't have a few dedicated persons for this job, this can become a lot more expensive for your organization then if they invest some money regularly for maintenance and evolvement on the basis of a fixed budget per year.

As an example, just look at the companies who made the failure of let themselves develop individual software for platforms like Windows XP or the old Internet Explorer 6.0, and forgot to make contracts to keep this software up-to-date - they now face a huge problem to get a replacement on a modern OS or browser, which often will cost them way more money in total than if they had done some strategic investment earlier.

So in short, I would not try to calculate the ROI for small individual features. Try to make your organizational leaders become aware of the bigger picture, hope they are open for strategic thinking, and try to convince them to make a strategic yearly reinvest of a certain percentage of "X+Y".

Note: I found a very interesting related article about prioritizing features, which talks about why "ROI" is not a good metrics for prioritizing the backlog, and introduces a different model ("cost on delay"), maybe it is useful for you.

The ROI for individual features or improvements is often hard to put in numbers. However, lots of organizations understand that when they have ordered some kind software made for their specific business, which saves them a certain amount of money X every year, that it makes sense to reinvest a certain percentage of X into maintenance and evolvement of that software. This will even more apply when the software will return some license fee Y every year, then the percentage should refer to "X+Y".

How large this percentage should be, however, is a strategic decision, since many of the effects of small incremental improvements will show their value only after a longer period. The very minimum, however, is the percentage to cap the maintenance cost required to make sure the bugs in the application get fixed, and the software gets adapted to environmental changes (the usual operational requirements like new OS versions, security fixes, security fixes in 3rd party products and so on).

Hence there usually needs to be someone who gets paid for doing the maintenance. That's a good basis for a synergy effect - paying a regularly yearly fee for maintenance and evolvement makes it possible for the maintainer to have someone on the payroll who has the actual knowledge for further development of the product. If your organization is only willing to pay maintenance cost when a bug occurs or a new OS version comes to the market, and the maintainer has to rebuild the knowledge for the development every year, because they don't have a few dedicated persons for this job, this can become a lot more expensive for your organization then if they invest some money regularly for maintenance and evolvement on the basis of a fixed budget per year.

As an example, just look at the companies who made the failure of let themselves develop individual software for platforms like Windows XP or the old Internet Explorer 6.0, and forgot to make contracts to keep this software up-to-date - they now face a huge problem to get a replacement on a modern OS or browser, which often will cost them way more money in total than if they had done some strategic investment earlier.

So in short, I would not try to calculate the ROI for small individual features. Try to make your organizational leaders become aware of the bigger picture, hope they are open for strategic thinking, and try to convince them to make a strategic yearly reinvest of a certain percentage of "X+Y".

Note: I found a very interesting related article about prioritizing features, which talks about why "ROI" is not a good metrics for prioritizing the backlog, and introduces a different model ("cost on delay"), maybe it is useful for you.