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

Measuring Business Value

Expand Messages
  • mpoppendieck
    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
    Message 1 of 6 , Dec 8, 2001
    View Source
    • 0 Attachment
      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
    • 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 2 of 6 , Dec 8, 2001
      View Source
      • 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 3 of 6 , Dec 9, 2001
        View Source
        • 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 4 of 6 , Dec 9, 2001
          View Source
          • 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 5 of 6 , Dec 9, 2001
            View Source
            • 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 6 of 6 , Dec 18, 2001
              View Source
              • 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.