I work in an environment that is somewhat dominated by a project governance mentality. What does this mean? What it means to me is this – that our diligence is focused on spending rather than on asset creation. Why is this significant? Because it changes how we focus the decisions in the process of software development.
I work in a software development function, within a large financial enterprise. We create software assets with a life between 5 and 20 years. The capital investment in that process is closely audited, and highly regulated. The valuation of those assets for tax and depreciation purposes is a “cost” basis. So we depreciate those assets on a schedule established by accountants and after the depreciation period, they are accounted as worthless.
This is standard accounting practice across every corporation in the US, and is true of every one that develops “bespoke” application software to solve their own business needs. There is nothing wrong with this in and of itself. It simply is missing something that is incredibly important. It is missing any connection to why we developed the software in the first place. I wonder if some of this is because software is so darned intangible? Or if perhaps there was a cost basis established that exposed how the software added value to the enterprise (that also is close to intangible). Perhaps if the software were directly connected to a revenue stream (that is we could sell the software to other companies).
The problem is that software typically solves business problems that are “soft cost” related. Soft costs are notoriously hard to measure. So when we try to calculate the “business value” realized through the implementation of the software, we have numbers that cannot directly applied to the bottom line. Hard cost can be applied to the bottom line. The thing is that the cost of developing and implementing the software is a hard cost, and does get applied to the bottom line. When my return on investment for a software project is measured in soft cost, we all have to hold hands and sing “cum ba yah” when the look at the numbers. If you are familiar with the problem, soft cost savings as a means of calculating business value is squishy. For example, a to value a software feature that increases productivity of some process – unless there is an associated body count in that business unit, we have a “soft” cost savings. The actual body count (reduction in force) would represent a hard savings. You can justify the soft cost by saying improved customer satisfaction, employee satisfaction, growth capacity, whatever, but there is no actual money involved except for the cost of the software. Any associated revenue growth in the business unit, now equipped with the software capability can be attributed to any number of factors including the software. That is what I mean by soft cost. There is no associated reduction in the business unit’s operating budget, so the cost of developing and implementing software is offset against future revenue from the unit.
If I were selling the software, then it could be offset against the revenue produced from software sales and implementation services. If I were an internet company, and the software was “infrastructure” to my product offering like Facebook, or Google, I would look at it like an expenditure on physical equipment in a manufacturing company, means of production. If I were to use software infrastructure to support a distributed workforce – (people working from home) – I could count hard savings on physical facilities.
So what – I hear you all say – so what is this: as a product manager, if I don’t/can’t establish a value for my product, it becomes hard to justify continued investment in it. All I have left is cost, and managing cost of software development, means typically that I add less value to the business.
As a software product manager, I should be focused on maximizing the value that my product delivers on a daily basis to the business users who are my customers. If I do not have rational, reasonable ways to establish and measure the delivery of that value, all of my decisions about which capabilities to implement, which to prioritize, which to defer become suddenly emotional, political, whimsical. The basis on which decisions are made becomes vague, ambiguous, squishy, and nebulous.
The appropriate equation that should govern our decisions to add software capabilities are:
TCO (total cost of ownership) = ( Cost of Software build (as depreciated) + Cost of system maintenance and support (as spent or projected) )
projected value = Sum( annual benefit [ projected over the life of the application ] ) – TCO
Realized value = Sum( annual benefit [ to date ] ) – TCO (to date)