Loading ...
Sorry, an error occurred while loading the content.

173RE: [scrumdevelopment] Measuring Business Value

Expand Messages
  • Ken Schwaber
    Dec 8, 2001
    • 0 Attachment
      Right now software projects only allow variation between cost, quality, time
      and functionality (usually just functionality).
      I intend to restate the formula as you indicated below, where
      business value f(cost, time, quality, functionality), so the busines person
      adjusts the four to create business value.

      -----Original Message-----
      From: mpoppendieck [mailto:mary@...]
      Sent: Saturday, December 08, 2001 4:01 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Measuring Business Value


      I am delighted to hear that your next book will focus on driving
      software development based on business value. I thought I'd post
      few observations on the subject.

      There are many barriers that get in the way of optimizing business
      value across a value chain, especially when the value chain includes
      more than one organization. Generally, each organization is trying
      to maximize its own individual measurements. However, measurements
      which do not span the value chain invariably cause sub-optimized
      business value across the organizations.

      To use a manufacturing example, we used to optimize the utilization
      of individual machines. After all, I had to use a very expensive
      coater, and it's burden rate was assigned to the unit cost of my
      product, and my product's P&L statement was based on it's
      cost. This meant that it was imperative that I maximize the
      utilization of that big machine, so as to minimize my product's

      This logic, however sound it may seem, turned out to be patently
      wrong. Machine productivity is a sub-optimized measurement. Only
      when it was abandoned as a critical performance measurement could
      progress on providing real business value be made. People who
      understand Just-in-Time and Supply Chain Management understand this.

      When a contract is put in place between two companies, it is assumed
      that the contract defines true business value, but in fact, it
      rarely does. Contracts cause measurements such as cost, schedule
      and scope to be important, because the meeting the contract terms is
      thought to be equivalent to providing business value. Generally
      these measurements are as misguided as the old manufacturing value
      of maximizing machine productivity.

      In fact, cost, schedule and scope are usually sub-optimized
      measurements; certainly all three of them taken together are. These
      measurements do not define true business value across the value
      chain, any more than the contract itself defines cross-organization
      value. In fact, such measurements will mostly get in the way of
      driving the entire effort toward true business value.

      The fundamental focus of Supply Chain Management is to do away with
      sub-optimizing points of measurement so as to optimize business
      value across multiple companies. Software development would do well
      to consider how to do the same.


      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 6 messages in this topic