Four reasons not to build financial cost of delay models

I had the chance to chat briefly with Ronica Roth, Agile Solutions Evangelist with Rally Software, about the barriers to developing financial cost of delay models.  Based on this and other conversations with colleagues and clients, I’ve compiled a list of reasons why you should NOT create these models for your company.

To begin, cost of delay models seek to quantify the financial impact of delaying or accelerating the market launch of a product.  For example, a model might say that a 3 month schedule slip will reduce new product revenue by 15%.

It’s tempting to think that models like this might improve project decisions, but watch out!  There are four reasons why you shouldn’t use this approach:

1.  Our developers’ brains are too full of technical knowledge to understand the financial impact of their decisions.  Instead, their decisions should be driven by managers’ sermons on the evils of delay.

In today’s fast-paced markets, decisions have to be made quickly at the lowest possible levels.  Models for cost of delay provide an important tool for developers to optimize day-to-day tradeoffs, without waiting for the next management review.  Good cost of delay models are an important part of delegating project decisions to the team.

2.  Our competitors don’t intimidate us!  We’re happy following them to market with four products, rather than beating them with three.

Cost of delay models help reduce development cycle time with better project staffing decisions.  It’s obvious that you don’t make money by starting projects; you make money by finishing them.  Yet most companies chronically overbook development capacity by starting too many projects, which ends up delaying all of them.  Knowing the cost of delay helps you decide to fully staff three projects, rather than thinly staffing four. 

3. Quantifying the cost of delay would destabilize our time-honored Loudest Voice process for resolving project contention at bottlenecks.

Bottlenecks crop up all the time in product development.  As an example, consider a QA function in an instrument company, where multiple projects may collide to create a bottleneck.  In many companies, the product champion with the loudest voice determines priorities.  Cost of delay models that are understood and supported by all stakeholders support rational priority decisions to optimize financial results.

4. Taking time to agree on good cost of delay models will get everybody talking and undermine the silo walls we’ve built stone by stone over the years.

In today’s competitive markets, functional silos can inhibit the good cross functional collaboration that’s critical to effective product development. In companies where there’s conflict about time to market, a cross-functional task force to agree on cost of delay models will be a first step toward better collaboration.

If, in spite of these cautions, you’re interested in building cost of delay models for your company, a good place to start is Chapter 2 of Developing Products in Half the Time, by Preston Smith and Don Reinertsen (John Wiley & Sons, 1998).  The book’s been around for a while, but the principles still apply.

Comments are closed.