More meaningful accounting to visualize software economics for more informed decision-making

1st February 2011
Simon Baker

In this article Ross Maynard says it’s unhelpful, even dangerous, to use the same methods to compile management and financial accounts. Regarding financial accounts he talks about matching accruals:

If we build inventory (stock) this month and sell it next month then the costs associated with that inventory (material, labor, overhead) should be capitalized this month and realized in the Profit and Loss account when the revenue is earned. That’s fair for external reporting because it ensures firms don’t play silly games with their costs and revenues to inflate (or deflate) profits to suit their own purposes.

He doesn’t think this is helpful for internal management accounts:

The costs of building the inventory were actually incurred this month when we made it – not when we sold it (which, in fact, may be many months away). In management accounting we are interested in the actual behavior of costs (and thus operational performance). We cannot effectively manage the actual cost behavior of the business at all when matching accruals.

He concludes that management accounts need to show the actual cash behavior and impact of the business so that operational performance can be managed effectively.

Cash-basis accounting for simpler operational economics

Investing in software development should be more about improving operational capabilities to gain a competitive advantage by driving growth, reducing costs and improving customer loyalty, and less about obtaining a return on investment.

When finance departments use expenses, including depreciation, and balance sheet concepts such as capitalization, assets versus liabilities, investments and accruals, we have found it difficult to understand the economics of operational variables in software development when making changes in pursuit of improvement. Consequently, in product streams we use cash basis accounting to visualize the cash performance in a simplified profit-and-loss statement showing the money earned, the money spent and the money left over. Here’s an example of a profit-and-loss statement we post on the wall:

Simplified profit and loss statement

The cost of a product stream includes the cost of labor, facility costs, hardware and hosting fees, software purchases and licensing fees, stationery and other sundries, etc. No distinction is made between direct and indirect costs. In conventional accounting terms that means all outgoing money is expensed as the cost is incurred, including the cost of inventory and work-in-progress, rather than carrying it as assets on a balance sheet.

A product stream drives profit. It does this first by increasing revenue without increasing costs and second by reducing costs without impacting the capacity to deliver. The aim is to remove the causes of costs by improving how the work actually works and eliminating waste. To visualize overall financial performance of a product stream we plot profit and cost on the wall:

Profit versus cost

We can see the product stream achieved self-funding and started to pay back investment with steadily rising revenue from mid January. The break-even point was reached at the beginning of June and the product stream moved into a position to drive profit, demonstrated by the increasing rate of revenue generation compared to the much flatter cost of capacity.

The cost of queues

Maintaining flow is imperative to a product stream. To drive profit, failure demand must be minimized so that as much throughput as possible concentrates on satisfying value demand and generating revenue. A product stream works to remove impediments to flow and reduce queues such as work-in-progress and inventory. Indicative costs for these queues, calculated using a cost per card, are kept visible so that economic consequences of queuing can be seen. We have seen this information significantly aid decision-making and continuous-improvement efforts.

Inventory is expensive. It costs money to produce and it continues to incur costs because code has to be maintained. Inventory also incurs a cost of delay that is equivalent to the revenue it will generate if it is released rather than queued. So far we have not included the cost of delay in the cost of queues because it has proved difficult to calculate the revenue generated by individual stories. The money invested in inventory is said to be sleeping money because it has not yet began yielding a return.

Visualizing the cost of queues in financial terms is sobering. Interestingly, we have seen this view on inventory create the incentive for businesspeople to sanction releases early and often in order to maximize profit.

Sleeping money

In the chart above, the red represents the inventory. The other colors represent work-in-progress at different parts of the product stream. The rising red peak over the first eight weeks provides a good indicator for the increasing need to release a minimal viable product. At its highest point, just before the first release, the cost inventory is around £75,000. That is 89% of the total sleeping money at that time. Inventory builds again for two smaller releases that follow the minimal viable product. After that inventory is flushed to the production environment on every weekly release.

As a side note, this is data from a real product stream. Between early February and April, the financial consequence of increased work-in-progress is due to a capacity constrained resource. The cost of queues peaks at £64,000 and after the bottleneck is removed the cost settles around an average of £34,000. From July, with the major product milestones achieved, a number of people are released from the product stream. The cost of capacity decreases and the cost of work-in-progress settles around an average of £15,000.

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Web Analytics