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

181RE: [scrumdevelopment] Measuring Business Value

Expand Messages
  • Narsu, Uttam
    Dec 9, 2001
      I think there's a missing dimension here, and that's risk and therefore risk

      Including risk allows one to gauge the value and the implications of trading
      off one variable over another, like trading off quality to make that market

      I'm also concerned that there's no measure of future value, what we would
      term flexibility. Measuring flexibility has business value because when it's
      present, then you may be better placed to meet a new requirement. Of course,
      there's a danger to flexibility in that as the XP'ers say, the simplest
      design is the best. Risk lets you quantify that as well, since a more
      complex, yet flexible design will take longer.

      We tend to use a framework that measures cost, benefits, flexibility and
      risk to measure business value. I don't believe it's been applied to the
      context of project management, but there may be some useful ideas in it for
      this domain. If anyone wants to hear about it (don't worry, it's an open,
      academically aligned methodology), I can sketch out the details in a mail

      Uttam M. Narsu
      Director, Giga Information Group
      139 Main Street, 4th Floor
      Cambridge, MA 02142
      617-577-4730 617-577-4906 (fax)
      unarsu@... <mailto:unarsu@...>

      -----Original Message-----
      From: Ken Schwaber [mailto:ken.schwaber@...]
      Sent: Saturday, December 08, 2001 9:19 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Measuring Business Value

      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/

      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