Value, and Throughput Accounting

There are many good articles written about how business value is the unacknowledged key driver of software development, and how Throughput Accounting gives businesses a new way to look at making business decisions based upon value delivered over time rather than Cost Accounting, which focusses on a simplistic view of cost-reduction as the main lever to control a business. But I'm not going to talk about that today.

Instead, let me ask a simple question: How do you prioritise a backlog? 

The answer is also simple: each backlog item has a value to the business and a cost. Cost is a function of actual cost to build and a weighted 'cost of risk', which is the sum of risk items individually multiplied by both their probability and their downside cost impact. 

Neither cost nor value are generally known in advance, both are estimates. Why? 

Value is an estimate in most situations; there are some situations in which value is known to a fairly high degree of certainty e.g. 3rd party supplier contracts i.e. a customer has given you a fixed price contract to implement a feature. Even under such circumstances the value is not 100% certain, the customer may pull out, may go bankrupt, may renegotiate half-way through implementation for a lower-cost solution, etc. 

Cost is an estimation because not only the 'cost-of-risk' part of the cost is an estimation, but the actual 'cost to implement' is also not known with certainty beforehand. Even in those situations in which it might be thought that the 'cost to implement' component is known e.g. buying in a third-party Commercial Off-The-Shelf solution (COTS) there are always extra unforeseen costs that cannot be accounted for up-front e.g. cost to integrate, cost to deploy, cost to configure, cost to manage the project etc. 

In summary: cost is an unknown, and value is an unknown. There are ways of assessing and managing these levels of uncertainty in advance, these methods are well known to scientific researchers who even in the hard sciences (I'm speaking as a Physics graduate) must take into account random and non-random variances and look for statistically significant correlations in their observed experimental data. In over twenty years in the IT industry I have not seen any calculations of cost and value that would come anywhere near passing the levels of rigour necessary for the peer-review of a scientific paper. Now, you may argue that these levels of rigour are unnecessary outside of the scientific community. I could offer the counter example of the UK government's National Programme for IT (NPfIT), the £22bn technology revitalisation programme for the UK's National Health Service (NHS), but although I think that programmes like these do indeed need appropriate levels of rigour, I will instead make the simple observation that the vast majority of IT projects I have worked on have had no significiant value analysis at all. 

Let me say that again: more than 90% of Product Owners, Business Analysts, Project Stakeholders and Executive sponsors that I've dealt with over the last twenty-something years have had anything more than a gut-feel about what a feature is worth. Not even a 'back of  a fag-packet' style calculation. Now I'm guessing that somewhere, in a board room, some kind of business case was put forward for the project, and there were some kind of expected costs and benefits analysed, and some kind of ROI figures bandied about, but none of that kind of high-level information ever made it down to the project teams, despite it being an essential part of the Prince 2 requirement for a business case document, a mandatory part of the one essential document (Project Initiation Document) that is key to the starting of any project.

Question: If no-one knows what a feature is worth, how can it be prioritised? Answer: simple - it is prioritised according to two common factors: a) how hard a stakeholder is willing to argue against his political rivals for its importance, and b) cost.

I would be prepared to argue that most of the debate that has taken place in Agile circles about Story Points and Estimation (of which whole books have been written) has been driven by the lack of any indication by the business of what the actual value of a Feature is, because if the only tool you have is a hammer (cost) every problem begins to look like a nail (more accurate and timely cost-reduction). 

The next time someone - Product Owner, Business Analyst etc. - asks you what the estimation of the cost to develop a feature is try saying "$10,000 plus or minus 1000%". When they demand - and I'm betting they will demand - a more accurate estimate say "I'll give you a more accurate calculation of cost when you give me an equally accurate calculation of business value." 

Nine times out of ten you'll be safe in the knowledge that not only do they not know the value of a feature right now, but they have no way of determining the value of a feature either. A shocking state of affairs, but why should you be forced to do more work to cover up for someone else's lack of professionalism? As long as the conversation remains focussed on the red-herring of cost, the true subject of import: value (and hence throughput) will remain unaddressed. 

In a future article I'll talk about different kinds of value, and how we can use Net Present Value (NPV)-style calculations to drive backlog prioritisation, but really, it's better to crawl first before trying to run and tripping over the shoelaces that the business has tied together for us.