Coming from a finance background my education and experience is grounded in ensuring that money invested returns ROI. We think of things such as ROI, IRR Cash Flow, etc... For example when a manufacturing company decides to make a hardware purchase for machinery (any kind) to produce some type of 'goods/product' they perform financial analysis regarding the cost of the equipment, the rate of return that it will generate, how quickly they can amortize it and ultimately what is the net profit that the machine is expected to generate over its anticipated lifespan.
For most of my career we start on projects that have a goal in mind, potentially new revenue or cost savings, some have gone so far as to try to determine the ROI, but in general I haven't seen the type of due diligence that manufacturing type companies perform, applied universally to software development.
This may be an underlying cause of many of the software development projects never seeing the light of day or failing to deliver the expected outcome because we never performed effective financial plans that would establish the scope and speed necessary to deliver a software product so that it warrants the investment.
In Agile I think we have ways of providing some level of financial analysis that can provide us with an understanding if an idea is worth pursuing.
- Using the following as a guideline we can begin to estimate costs:
- Team Size - 5
- Blended Rate - $125 an hour
- Hourly team rate - $625
- Cost of Sprint(2 weeks) - $50,000
- Let's assume that the feature that we want the team to work on has come back with an estimate of 5 Sprints.
- Estimated Development Cost - $250,000
- Let's now assume that this investment is expected to yield an additional $1,000,000 in annual revenue.
- Expected ROI in the first year - 300%
Before we engage our teams we need to be sure that the $250k investment will return an appropriate level of return. In this simple example its a no brainer.
But our world of software development isn't always so clear-cut, we often don't know what the expected outcome will be until we release the product into the wild. There is often additional cost for refactoring before the product hits the mark with your consumers.
But using some of these simple ways of working through anticipated costs we can easily modify the example to reflect additional Sprints for refactoring once the product is released.
In this example let's assume that the team requires an additional 8 sprints to move from MVP to final product.
The final cost of the product would climb to $625k and our return would drop significantly to 54%. Still not bad but not the eye-popping number we initially thought it would be.
Factor in sustainment costs into this over the life of the product and you begin to see that your investments in your software absolutely need to go through the same level of analysis as other types of large infrastructure purchases that non-software organizations go through.
I'm currently working on creating a lightweight model based upon Markowitz's Efficient Frontier investment model that money managers use today to ensure that your risk and return threshold is aligned. I'll be posting my initial thoughts and approach in a coming blog.