Archive for the ‘Finance’ Category

Use Traffic Delay to Measure Congestion

Wednesday, May 25th, 2011
 “Traffic Delays to Triple” read a headline about highway congestion in my morning paper.  It turns out that planners use traffic delay to measure the cost of highway congestion.

This would be a good way to measure project congestion on your new product highway.

We’ve all experienced traffic jams (if you’re from Southern California you’re an expert).  When traffic is congested, it takes too long to get home, and your arrival time is unpredictable.  The figure below, based on Don Reinertsen’s The Principles of Product Development Flow (pages 170-172), shows how high traffic density reduces throughput.

Traffic density reduces throughput

With highway traffic, too many cars start to interfere with each other, they begin to slow down, and vehicle throughput declines.

The same thing happens in product development.  Companies’ most common headaches are that projects take too long and schedules are unreliable. Yet these same companies start too many projects, congesting project traffic, delaying projects and making schedules unreliable.

But how can you push back on project congestion without coming off as a whiner?  One way would be to build a case against congestion by assessing traffic delay as an objective measure of the cost of congestion.

Put a cross functional task force together for a retrospective on recent projects.  Estimate the total delays in weeks, weighted by the lifetime profit potential of each project to get a delay measurement in $M-Weeks.  (It would be better to use a financial cost of delay model to translate delay directly into economic loss.  But most companies don’t use these models, as I’ve lamented previously.)

Apply your best judgment to look only at delays that are caused by congestion:

  • Time spent waiting in queues at resource bottlenecks
  • Time waiting for an engineer from another project that didn’t finish on time.
  • Delay caused when an engineer was diverted to fight a fire with another project.
  • Delay caused by multitasking.  When sharing resources means alternately putting projects on hold while another one gets resources.
  • Cases where an expert needed to solve an unexpected problem was already committed elsewhere.
  • Opportunity delay, when a project might have been accelerated with more staffing. (For this one, estimate what the project schedule might have been with a reasonable staffing increase.)

Be sure to honestly estimate congestion delays without including delays from other sources, such as underestimated tasks, or “normal” process overhead.

This assessment will tell you how much project congestion is costing you.  If the figure is large, you have a concrete basis for better new project onramp control.  This will ease congestion and make projects faster and more predictable.  And maybe you’ll be able to get home on time.

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.

Do it wrong or do it over: 11th-hour project crises

Thursday, January 13th, 2011

In an article in the December 2010 issue of PDMA’s Visions magazine, Preston Smith and I talk about how preparing for change helps project leaders avoid costly 11-th hour crises. 

The mantra “do it right or do it over” encourages developers to eliminate changes with thorough planning.  But in dynamic innovative markets, relying on upfront planning to eliminate mid-project changes often leads to 11th-hour project crises. When customers change their minds or innovation works out differently than you thought, you’re stuck with the dilemma to do it wrong or do it over.  You either stick to the plan and launch a product that misses the market or change the plan and suffer costly rework and schedule delay. 

Even with the best of plans, mid-project learning may be unavoidable.  Instead of trying to eliminate change, Flexible Product Development seeks to reduce the cost of change by preparing for it.   You eliminate the dilemma because changes incur little rework or schedule delay.

Do you deal frequently with the do-it-wrong-or-do-it-over dilemma?  Look carefully–the symptoms may not show up as mid-project changes.  Project managers in plan-driven organizations may refuse to make a worthy change, but the impact only shows up later in a disappointing market launch.

For more information:

Preston G. Smith and John S. Farnbach, “Avoid costly 11th-hour project dilemmas by preparing for change,” Visions XXIV No. 4 (December, 2010): 24-27.  (Available on my web site here.)

You can read more about Flexible Product Development here, or on Preston Smith’s website.  (Preston coined the phrase “do it wrong or do it over.”)

Avoid the Short Term Treadmill in R&D Investments

Tuesday, November 9th, 2010

Reading a recent article published by Harvard Business School, it occurred to me that executives allocating R&D funding could take a lesson from financial institutions’ experience in 2008.

One factor in accelerating the economic collapse was that financial firms had put themselves on a treadmill of short term debt.   The attraction of short term debt was low interest, but short term financing requires firms to “roll” their debt, continuously selling new bonds to repay maturing ones.  When the crisis hit, bond investors bolted for the exits, so firms could no longer sell new bonds, forcing them to sell assets to repay maturing debt.  Suddenly everyone was trying to sell assets at the same time, and asset prices plummeted, quickly pushing firms toward insolvency or government bailouts.

What does this have to do with new product strategy?  Executives balancing R&D funding among product lines should avoid putting their companies on a treadmill of short term returns.

The temptation to invest in short lifecycle products is that they can produce faster revenue growth for a given level of R&D productivity (new revenue per R&D dollar).  However, over-investment in short life products puts the new product program on a treadmill.  As revenue from one product generation matures and declines, it must quickly be replaced with even more new revenue to sustain growth:  A decline in R&D productivity can lead to a frightening drop in revenue growth.

Among other strategic considerations, executives should carefully consider the treadmill effect when allocating R&D funding among product lines and avoid the risks of over reliance on short term returns.