Archive for April, 2011

Four reasons not to build financial cost of delay models

Friday, April 15th, 2011

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.

Designs change. Deal with it!

Friday, April 8th, 2011

Study after study shows that while CEOs espouse the importance of innovation, their companies are turning away from significant new product innovations in favor of simple product renovations.  I think one important cause of this split personality is that companies don’t have a good way to deal with mid-project changes.  They avoid changes by favoring simple product extensions in stable, well-known markets.

These companies would be better off to realize that change is an inevitable part of product innovation–It’s just not realistic to expect project planners to know everything about an opportunity before they start development.

An article Preston Smith and I wrote about this dilemma was published in the March 17, 2011 issue of Machine Design.  You can read it on my website here.  We discuss how change is the rule, not the exception, for product innovation.

Three prevailing fallacies about the cost of project flexibility may be hobbling developers with outdated development processes that can’t deal with mid-project changes:

  • The first fallacy is that flexibility is prohibitively expensive.  It doesn’t have to be.  Recognizing and preparing for uncertainties eliminates most of the typical cost of change.
  • The second fallacy is that flexibility makes projects unpredictable.  In fact it’s rigid planning that drives up budget and schedule variance when change is forced on a project.
  • The third fallacy is that development flexibility delays a product’s market launch.  The article gives an example of how flexibility speeds market launch by allowing developers to start work before requirements are completely stable.

In short, project flexibility has gotten a bum rap.  You need to change and adapt to what you learn in the middle of a project, and new flexible development tools give developers what they need to deal effectively with changes.