How to make a business case for incremental product development

Question

I don't work for an development company, but we have been working in partnership with one to develop an application for use internally within our business. The application is somewhat "niche", and so while we have the ability to scale it and roll it out to our other locations (we are an international company), it is unlikely that we will be releasing it onto the global market (eg. selling to our competitors). Even if we did, the application would be somewhat niche and the market small.

In order to get funding for the project, we needed to prepare a business case. We used an Agile-ish development approach, in that we built our business case on developing the "minimum viable product", and got approval for budget on that basis. We were extremely fortunate to be be working with a technology provider who was very focused on the end-user / usability of the application, as well as the minimum technical functionality, and as a result our "minimum viable product" was actually very polished.

However, as we went through the development, we identified a large number of possible enhancements, both to the functionality and to the user experience (and even a few architecture ones). Given that we had a constrained budget & timeline, we had to be quite aggressive and disciplined in prioritisation. The result is that we now how our application ready to roll-out to the end users, but a large list of really good opportunities in our backlog, for which we have no budget to progress them.

I really want to make the case to get more funds and develop the app further, but it is hard to make the business case. From the company's perspective, this is not our core business: it is a tool to help us deliver our core business, and therefore budget must compete with other activities. As we have delivered our "MVP", we have delivered most of the value (at least in the eyes of the budget holders). The additional features have a much reduced return-on-investment compared with the MVP.

How do people generally make the case for adding the next feature set in agile projects? How do you convince budget holders and decision makers of the value of the user-experience, the intangibles, the polishing; particularly in a niche application like ours where you don't need continuous releases and updates to stay ahead of the competition?

This link provided some thoughts, but it doesn't really provide me with any answers. Does anyone have any thoughts on how to frame additional features vs diminishing value?

Note: The original business case was made on taking a manual process and making it semi-automated (using software for what was once paper-based). The additional features are around better data integration with other systems, UI enhancements, changes to some of the application logic to make it more flexible: i.e. all valuable things, but none with a fantastically high "return on investment".

Answer 1

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.