Lean tools: Cost of delay

Let's try to answer a question which many programmers would find not so important. Why is every Lean practitioner obsessed with delivering early?

Of course, a component of this approach is the benefit of feedback that rapid development produces. But, depending on the domain, another component can get as important: the economic advantage derived from a short time-to-market.

The conventional economics model

Software development has a cost: apart from the hardware and location fixed costs, one of the major operating expenses is developer time. An employer pays a programmer $ X per hour, plus the cost of benefits such as insurance and taxes.

There are many tools that save the developers time: in the conventional model, their benefit is measure directly as the developer's time cost which is not spent but instead saved. For example, providing double monitors or solid state drives to each developers would increase a bit their productivity, maybe saving them 10 minutes a day. By considering an even trade off between what you spend on hardware and on programmers, these devices would pay for itself in one or two months - so they're actually good investments.

Rapid development

In many domains, however, you cannot make an even tradeoff between X dollars spent and a programmers hour of salary. Time to market or to the next release is an important dimension of the product. If you save a day of development, the balance is as follows:

• investment spent for a tool or implementing a technique
• money saved because of reduced use of programmers time
• additional revenue deriving from the earlier time to market.

Shaving days after days of coding produces the same features at a lower cost; but releasing X days earlier means you outpace the competition.

The product model

The Poppendiecks propose to use a standard (in the accounting field) profit & loss statement for each product under development.
On the temporal dimension, this statement is just a spreadsheet starting from now and spanning some columns into the future (months or even years). Each of the rows is instead an estimate of revenue or expense.

2012 Q1	2012 Q2	2012 Q3
Contracts sold	100	400	600
Revenue	100000	400000	600000
Development	-400000	-100000	-100000
Hardware	-10000	-20000	-20000
	...	...	...

The catch is comparing different P&L statements containing a delay or not; the variables that influence earlier profits are:

• the lack of competition early in the market, or by contrast the growth of a product in time. In this table, there should be additional columns where the product plateaus and eventually dies out in the far future.
• The discounting factor reducing the present value of future earnings due to risk and interest over capital. Metrics like Net Present Value can extract from this table a single final figure which will vary if you move revenues and expenses forward or backward in time.

Another catch is that as developers we are often clueless about producing monetary figures like these. Collaboration with accountants and marketing colleagues is strongly suggested; after all, a cross-functional team already incorporates different expertise like developers, testers and analysts: why not expand around the whole product lifecycle?

The application model

A vast number of software firms, however, develops applications for a paying customer instead of a product to market. The model for estimating profits and losses would be related to the customer business model instead of your own.

An interesting exercise in this field is to find out which are the customer's economic drivers for the project. Do they want to shave some costs? Or to increase the revenue of a business unit? Maybe the goal is to lower or increse some business metric, like the response time of the business to a customer's request.

Even when the actual current and projected numbers are gathered as estimates, you can transform sets of features supporting the business internal workings into money. Here are some example scenarios from my past work and how I could estimate their benefit now:

• using a web application for assigning drivers to trips instead of dispatching printed copies will save $50 per month in printing costs and $100 in employee time.
• Accepting reservations directly from an online form is estimated to halve the bounce rate on the restaurant website.
• Syncing automatically the student entrances in the main database for the parent's benefit will get the private school a few (how many in percentage?) more students the next year.

All these hypotheses should be validated before jumping into development, but we are entering in the realm of the Lean Startup model here...