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

RE: [scrumdevelopment] Measuring Business Value

Expand Messages
  • Ken Schwaber
    Excellent. Right now software projects only allow variation between cost, quality, time and functionality (usually just functionality). I intend to restate the
    Message 1 of 6 , Dec 8, 2001
    • 0 Attachment
      Excellent.
      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.
      Ken

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


      Ken,

      I am delighted to hear that your next book will focus on driving
      software development based on business value. I thought I'd post
      a
      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
      unit
      cost. This meant that it was imperative that I maximize the
      utilization of that big machine, so as to minimize my product's
      unit
      cost.

      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.

      Mary



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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • mpoppendieck
      I submit that in a for-profit business, true business value is rarely a function of cost and generally not a function of meeting a deadline. At 3M, arguably
      Message 2 of 6 , Dec 9, 2001
      • 0 Attachment
        I submit that in a for-profit business, true business value is
        rarely a function of cost and generally not a function of meeting a
        deadline. At 3M, arguably one of best companies in the world at new
        product development, development cost and time were simply not an
        issue. But at every phase review, starting with product concept, a
        cost accountant presented a projected P&L. The only bar you have to
        pass was that the margin on this P&L met a high threshold. And guess
        what – this system delivered tons of high margin products!

        Mary

        --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
        wrote:
        > Excellent.
        > 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.
        > Ken
      • Narsu, Uttam
        I think there s a missing dimension here, and that s risk and therefore risk management. Including risk allows one to gauge the value and the implications of
        Message 3 of 6 , Dec 9, 2001
        • 0 Attachment
          I think there's a missing dimension here, and that's risk and therefore risk
          management.

          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
          window.

          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
          message.

          Uttam
          --
          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


          Excellent.
          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.
          Ken

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


          Ken,

          I am delighted to hear that your next book will focus on driving
          software development based on business value. I thought I'd post
          a
          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
          unit
          cost. This meant that it was imperative that I maximize the
          utilization of that big machine, so as to minimize my product's
          unit
          cost.

          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.

          Mary



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

          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:
          scrumdevelopment-unsubscribe@...

          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        • Ken Schwaber
          An initial description of my work with John Logan on business value driven development is contained in a new book from John at
          Message 4 of 6 , Dec 9, 2001
          • 0 Attachment
            An initial description of my work with John Logan on business value driven
            development is contained in a new book from John at
            http://www.evolution-not-revolution.com/ . This is a very business oriented
            book, but the project management basis in agile is the core.
            Ken

            -----Original Message-----
            From: Narsu, Uttam [mailto:UNarsu@...]
            Sent: Sunday, December 09, 2001 6:26 PM
            To: 'scrumdevelopment@yahoogroups.com'
            Subject: RE: [scrumdevelopment] Measuring Business Value


            I think there's a missing dimension here, and that's risk and therefore risk
            management.

            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
            window.

            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
            message.

            Uttam
            --
            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


            Excellent.
            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.
            Ken

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


            Ken,

            I am delighted to hear that your next book will focus on driving
            software development based on business value. I thought I'd post
            a
            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
            unit
            cost. This meant that it was imperative that I maximize the
            utilization of that big machine, so as to minimize my product's
            unit
            cost.

            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.

            Mary



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

            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:
            scrumdevelopment-unsubscribe@...

            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:
            scrumdevelopment-unsubscribe@...

            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          • Ken Schwaber
            Uttam, I d like to hear more about the details. I believe that business value is a composite of benefits, flexibility, risk, profitability, long term
            Message 5 of 6 , Dec 18, 2001
            • 0 Attachment
              Uttam,
              I'd like to hear more about the details. I believe that business value is a
              composite of benefits, flexibility, risk, profitability, long term
              competitive advantage, stock price, etc. ... all of the things which the
              business person or product manager has to use to convince someone to fund
              the product development.
              Ken

              -----Original Message-----
              From: Narsu, Uttam [mailto:UNarsu@...]
              Sent: Sunday, December 09, 2001 6:26 PM
              To: 'scrumdevelopment@yahoogroups.com'
              Subject: RE: [scrumdevelopment] Measuring Business Value


              I think there's a missing dimension here, and that's risk and therefore risk
              management.

              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
              window.

              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
              message.

              Uttam
              --
              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


              Excellent.
              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.
              Ken

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


              Ken,

              I am delighted to hear that your next book will focus on driving
              software development based on business value. I thought I'd post
              a
              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
              unit
              cost. This meant that it was imperative that I maximize the
              utilization of that big machine, so as to minimize my product's
              unit
              cost.

              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.

              Mary



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

              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:
              scrumdevelopment-unsubscribe@...

              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:
              scrumdevelopment-unsubscribe@...

              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            Your message has been successfully submitted and would be delivered to recipients shortly.