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

Measuring productivity

Expand Messages
  • chet hendrickson
    Hello David, In you comments you related your findings on productivity between agile and traditional development as measured in hours per function point. Can
    Message 1 of 18 , Jun 28, 2007
    • 0 Attachment
      Hello David,

      In you comments you related your findings on productivity between
      agile and traditional development as measured in hours per function
      point. Can you tell us more about the hours part of this. Are you
      measuring developer hours per function point or all hours expended on
      the project?

      On a related topic, how do you measure the waste usually found in a
      traditional/waterfall project. I am referring time and other
      resources expended in creation of artifacts during the analysis and
      design phases for features that are dropped later? This shouldn't
      those efforts be viewed as an opportunity cost as well?


      --
      Best regards,
      chet mailto:lists@...
    • seidolce1960
      ... Chet, An organization needs to understand total time and cost on a project. Anyone working on the project needs to be recording their time. I use hours
      Message 2 of 18 , Jun 28, 2007
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, chet hendrickson <lists@...> wrote:
        >
        > Hello David,
        >
        > In you comments you related your findings on productivity between
        > agile and traditional development as measured in hours per function
        > point. Can you tell us more about the hours part of this. Are you
        > measuring developer hours per function point or all hours expended on
        > the project?
        >
        > On a related topic, how do you measure the waste usually found in a
        > traditional/waterfall project. I am referring time and other
        > resources expended in creation of artifacts during the analysis and
        > design phases for features that are dropped later? This shouldn't
        > those efforts be viewed as an opportunity cost as well?
        >
        >
        > --
        > Best regards,
        > chet mailto:lists@...
        >
        Chet,

        An organization needs to understand total time and cost on a project. Anyone working on
        the project needs to be recording their time. I use hours instead of cost or man days
        because everyone agrees on what an hour represents.

        When I develop cost figures I use an internally developed loaded rate, usually around
        $100/hr.

        Sometimes organizations have it recorded and sometimes I have to estimate it based up
        how much people are dedicated to projects and cost based upon internal salary numbers.

        It is important to know the blend of developers and everyone else charging time to a
        project.

        I develop a range of productivity based upon past completed projects. The larger the
        range the more variation in the way projects are completed.

        In most software organizations there is a tremendous amount of waste. When we establish
        some baseline numbers I do some comparisons with similar companies and create a "you
        are here diagram." This helps organizations understand potential improvements.

        Typically I develop a set of baseline number such as:

        1. Time to Market
        2. Hrs/FP (and $/FP).
        3. Staff/FTE Ratio (FTE = full time equivalent).
        4. Issues Per Hour Worked (development environment)
        5. Issues Per Function Point
        6. Production Issues Per Hour of Project
        7. Production Issues per Function Point
        8. Breakdown of Project by Task or by Phase (hopefully taken directly from project plans).

        I do this for several projects within an organization. I develop a range of number with
        means, confidence intervals and all that stuff. While I use function points, other sizing
        metrics can be used too.

        The larger the range or standard deviations the more project variation and the harder it is
        to predict and estimate.

        For an acquisition I will include some other numbers such as total application function
        points and come up with a market value or purchase price. I will calculate book value and
        good will.

        I gather a bunch qualitative project information as well. I gather it via observation not
        surveys.

        Waste
        The worse the productivity numbers the more waste or inefficient the project. Creating
        project documentation is not necessarily a waste. It is important to measure the number
        of times a document is reference or looked at by someone else (this is really easy to come
        up). If documents are being created and no one looks at then they need to be questioned.

        Project Comparisons (organizational comparisons)
        Projects can be compared to see what is causing the variation in productivity and other
        items. Questions like, Why are some projects more productivity than other projects? can
        be answered.

        I can compare organizations and ask, why is this organization 10 times more productive
        than another organization.

        User Groups (Business Side)
        I also try to get a read on the business side and understand what prompts them to ask for
        specific functionality. What experience levels do the "domain experts" have in relation to
        software development.

        I quantitative things like the % of time a domain expert is dedicated to a project as well as
        his tenure in the business group.

        I could go on and on....

        David Longstreet
        Software Economist
        www.SoftwareMetrics.Com
      • Manuel Klimek
        David, just out of interest: how are those things measured technically? I m just curious, because I can t imagine how to measure all those things. - how do you
        Message 3 of 18 , Jun 28, 2007
        • 0 Attachment
          David,

          just out of interest: how are those things measured technically? I'm just
          curious,
          because I can't imagine how to measure all those things.
          - how do you make sure that developers don't lie when they write down the
          time
          - how do you make sure the function points you count are not wasted, do you
          read the corresponding source code?

          And with regards to the comments about European / USA productivity
          per developer. How can one compare such numbers? Since you're an
          measurement expert I'd hope you have some hints :-)

          Thanks,
          Manuel

          On 6/28/07, seidolce1960 <David@...> wrote:
          >
          > --- In extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
          > chet hendrickson <lists@...> wrote:
          > >
          > > Hello David,
          > >
          > > In you comments you related your findings on productivity between
          > > agile and traditional development as measured in hours per function
          > > point. Can you tell us more about the hours part of this. Are you
          > > measuring developer hours per function point or all hours expended on
          > > the project?
          > >
          > > On a related topic, how do you measure the waste usually found in a
          > > traditional/waterfall project. I am referring time and other
          > > resources expended in creation of artifacts during the analysis and
          > > design phases for features that are dropped later? This shouldn't
          > > those efforts be viewed as an opportunity cost as well?
          > >
          > >
          > > --
          > > Best regards,
          > > chet mailto:lists@...
          > >
          > Chet,
          >
          > An organization needs to understand total time and cost on a project.
          > Anyone working on
          > the project needs to be recording their time. I use hours instead of cost
          > or man days
          > because everyone agrees on what an hour represents.
          >
          > When I develop cost figures I use an internally developed loaded rate,
          > usually around
          > $100/hr.
          >
          > Sometimes organizations have it recorded and sometimes I have to estimate
          > it based up
          > how much people are dedicated to projects and cost based upon internal
          > salary numbers.
          >
          > It is important to know the blend of developers and everyone else charging
          > time to a
          > project.
          >
          > I develop a range of productivity based upon past completed projects. The
          > larger the
          > range the more variation in the way projects are completed.
          >
          > In most software organizations there is a tremendous amount of waste. When
          > we establish
          > some baseline numbers I do some comparisons with similar companies and
          > create a "you
          > are here diagram." This helps organizations understand potential
          > improvements.
          >
          > Typically I develop a set of baseline number such as:
          >
          > 1. Time to Market
          > 2. Hrs/FP (and $/FP).
          > 3. Staff/FTE Ratio (FTE = full time equivalent).
          > 4. Issues Per Hour Worked (development environment)
          > 5. Issues Per Function Point
          > 6. Production Issues Per Hour of Project
          > 7. Production Issues per Function Point
          > 8. Breakdown of Project by Task or by Phase (hopefully taken directly from
          > project plans).
          >
          > I do this for several projects within an organization. I develop a range
          > of number with
          > means, confidence intervals and all that stuff. While I use function
          > points, other sizing
          > metrics can be used too.
          >
          > The larger the range or standard deviations the more project variation and
          > the harder it is
          > to predict and estimate.
          >
          > For an acquisition I will include some other numbers such as total
          > application function
          > points and come up with a market value or purchase price. I will calculate
          > book value and
          > good will.
          >
          > I gather a bunch qualitative project information as well. I gather it via
          > observation not
          > surveys.
          >
          > Waste
          > The worse the productivity numbers the more waste or inefficient the
          > project. Creating
          > project documentation is not necessarily a waste. It is important to
          > measure the number
          > of times a document is reference or looked at by someone else (this is
          > really easy to come
          > up). If documents are being created and no one looks at then they need to
          > be questioned.
          >
          > Project Comparisons (organizational comparisons)
          > Projects can be compared to see what is causing the variation in
          > productivity and other
          > items. Questions like, Why are some projects more productivity than other
          > projects? can
          > be answered.
          >
          > I can compare organizations and ask, why is this organization 10 times
          > more productive
          > than another organization.
          >
          > User Groups (Business Side)
          > I also try to get a read on the business side and understand what prompts
          > them to ask for
          > specific functionality. What experience levels do the "domain experts"
          > have in relation to
          > software development.
          >
          > I quantitative things like the % of time a domain expert is dedicated to a
          > project as well as
          > his tenure in the business group.
          >
          > I could go on and on....
          >
          > David Longstreet
          > Software Economist
          > www.SoftwareMetrics.Com
          >
          >
          >



          --
          http://klimek.box4.net


          [Non-text portions of this message have been removed]
        • Nicholas Cancelliere
          What if I lie to make myself look better? Who s to say I didn t spend 55 hrs this week working instead of 40 hrs? Does the manager follow me around all day,
          Message 4 of 18 , Jun 28, 2007
          • 0 Attachment
            What if I lie to make myself look better? Who's to say I didn't
            spend 55 hrs this week working instead of 40 hrs? Does the manager
            follow me around all day, or when I'm working late, or working from
            the Starbucks on wifi?

            I always find such metrics dubious. The best you can do (if a
            developer is salary) is assume 40 hrs a week, and how many weeks did
            that project take? But then there is the whole accounting of "opex"
            vs "capex" and then you have to figure out of those 40 hours a week,
            how many are actually spent on the project -- then it becomes a
            downhill spiral from there. In the end it's simply guesswork and
            trust that you come to some number that you can give to accounting
            and make them happy.

            How do you ensure that what a developer reports he's doing on a
            project is really what he's doing?

            Nicholas




            On Jun 28, 2007, at 3:46 PM, seidolce1960 wrote:

            > An organization needs to understand total time and cost on a
            > project. Anyone working on
            > the project needs to be recording their time. I use hours instead
            > of cost or man days
            > because everyone agrees on what an hour represents.

            ---
            Nicholas Cancelliere
            Austin, TX




            [Non-text portions of this message have been removed]
          • Steven Gordon
            Is the ROI of a project a relevant factor? FPs that do not deliver business value might as well be multiplied by 0. ... [Non-text portions of this message
            Message 5 of 18 , Jun 28, 2007
            • 0 Attachment
              Is the ROI of a project a relevant factor? FPs that do not deliver business
              value might as well be multiplied by 0.

              On 6/28/07, seidolce1960 <David@...> wrote:
              >
              > --- In extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
              > chet hendrickson <lists@...> wrote:
              > >
              > > Hello David,
              > >
              > > In you comments you related your findings on productivity between
              > > agile and traditional development as measured in hours per function
              > > point. Can you tell us more about the hours part of this. Are you
              > > measuring developer hours per function point or all hours expended on
              > > the project?
              > >
              > > On a related topic, how do you measure the waste usually found in a
              > > traditional/waterfall project. I am referring time and other
              > > resources expended in creation of artifacts during the analysis and
              > > design phases for features that are dropped later? This shouldn't
              > > those efforts be viewed as an opportunity cost as well?
              > >
              > >
              > > --
              > > Best regards,
              > > chet mailto:lists@...
              > >
              > Chet,
              >
              > An organization needs to understand total time and cost on a project.
              > Anyone working on
              > the project needs to be recording their time. I use hours instead of cost
              > or man days
              > because everyone agrees on what an hour represents.
              >
              > When I develop cost figures I use an internally developed loaded rate,
              > usually around
              > $100/hr.
              >
              > Sometimes organizations have it recorded and sometimes I have to estimate
              > it based up
              > how much people are dedicated to projects and cost based upon internal
              > salary numbers.
              >
              > It is important to know the blend of developers and everyone else charging
              > time to a
              > project.
              >
              > I develop a range of productivity based upon past completed projects. The
              > larger the
              > range the more variation in the way projects are completed.
              >
              > In most software organizations there is a tremendous amount of waste. When
              > we establish
              > some baseline numbers I do some comparisons with similar companies and
              > create a "you
              > are here diagram." This helps organizations understand potential
              > improvements.
              >
              > Typically I develop a set of baseline number such as:
              >
              > 1. Time to Market
              > 2. Hrs/FP (and $/FP).
              > 3. Staff/FTE Ratio (FTE = full time equivalent).
              > 4. Issues Per Hour Worked (development environment)
              > 5. Issues Per Function Point
              > 6. Production Issues Per Hour of Project
              > 7. Production Issues per Function Point
              > 8. Breakdown of Project by Task or by Phase (hopefully taken directly from
              > project plans).
              >
              > I do this for several projects within an organization. I develop a range
              > of number with
              > means, confidence intervals and all that stuff. While I use function
              > points, other sizing
              > metrics can be used too.
              >
              > The larger the range or standard deviations the more project variation and
              > the harder it is
              > to predict and estimate.
              >
              > For an acquisition I will include some other numbers such as total
              > application function
              > points and come up with a market value or purchase price. I will calculate
              > book value and
              > good will.
              >
              > I gather a bunch qualitative project information as well. I gather it via
              > observation not
              > surveys.
              >
              > Waste
              > The worse the productivity numbers the more waste or inefficient the
              > project. Creating
              > project documentation is not necessarily a waste. It is important to
              > measure the number
              > of times a document is reference or looked at by someone else (this is
              > really easy to come
              > up). If documents are being created and no one looks at then they need to
              > be questioned.
              >
              > Project Comparisons (organizational comparisons)
              > Projects can be compared to see what is causing the variation in
              > productivity and other
              > items. Questions like, Why are some projects more productivity than other
              > projects? can
              > be answered.
              >
              > I can compare organizations and ask, why is this organization 10 times
              > more productive
              > than another organization.
              >
              > User Groups (Business Side)
              > I also try to get a read on the business side and understand what prompts
              > them to ask for
              > specific functionality. What experience levels do the "domain experts"
              > have in relation to
              > software development.
              >
              > I quantitative things like the % of time a domain expert is dedicated to a
              > project as well as
              > his tenure in the business group.
              >
              > I could go on and on....
              >
              > David Longstreet
              > Software Economist
              > www.SoftwareMetrics.Com
              >
              >
              >


              [Non-text portions of this message have been removed]
            • seidolce1960
              ... extremeprogramming@yahoogroups.com , ... Yes, of course, I measure profit margins and increased revenue and profits.
              Message 6 of 18 , Jun 28, 2007
              • 0 Attachment
                --- In extremeprogramming@yahoogroups.com, "Steven Gordon" <sgordonphd@...>
                wrote:
                >
                > Is the ROI of a project a relevant factor? FPs that do not deliver business
                > value might as well be multiplied by 0.
                >
                > On 6/28/07, seidolce1960 <David@...> wrote:
                > >
                > > --- In
                extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
                > > chet hendrickson <lists@> wrote:
                > > >
                > > > Hello David,
                > > >
                > > > In you comments you related your findings on productivity between
                > > > agile and traditional development as measured in hours per function
                > > > point. Can you tell us more about the hours part of this. Are you
                > > > measuring developer hours per function point or all hours expended on
                > > > the project?
                > > >
                > > > On a related topic, how do you measure the waste usually found in a
                > > > traditional/waterfall project. I am referring time and other
                > > > resources expended in creation of artifacts during the analysis and
                > > > design phases for features that are dropped later? This shouldn't
                > > > those efforts be viewed as an opportunity cost as well?
                > > >
                > > >
                > > > --
                > > > Best regards,
                > > > chet mailto:lists@
                > > >
                > > Chet,
                > >
                > > An organization needs to understand total time and cost on a project.
                > > Anyone working on
                > > the project needs to be recording their time. I use hours instead of cost
                > > or man days
                > > because everyone agrees on what an hour represents.
                > >
                > > When I develop cost figures I use an internally developed loaded rate,
                > > usually around
                > > $100/hr.
                > >
                > > Sometimes organizations have it recorded and sometimes I have to estimate
                > > it based up
                > > how much people are dedicated to projects and cost based upon internal
                > > salary numbers.
                > >
                > > It is important to know the blend of developers and everyone else charging
                > > time to a
                > > project.
                > >
                > > I develop a range of productivity based upon past completed projects. The
                > > larger the
                > > range the more variation in the way projects are completed.
                > >
                > > In most software organizations there is a tremendous amount of waste. When
                > > we establish
                > > some baseline numbers I do some comparisons with similar companies and
                > > create a "you
                > > are here diagram." This helps organizations understand potential
                > > improvements.
                > >
                > > Typically I develop a set of baseline number such as:
                > >
                > > 1. Time to Market
                > > 2. Hrs/FP (and $/FP).
                > > 3. Staff/FTE Ratio (FTE = full time equivalent).
                > > 4. Issues Per Hour Worked (development environment)
                > > 5. Issues Per Function Point
                > > 6. Production Issues Per Hour of Project
                > > 7. Production Issues per Function Point
                > > 8. Breakdown of Project by Task or by Phase (hopefully taken directly from
                > > project plans).
                > >
                > > I do this for several projects within an organization. I develop a range
                > > of number with
                > > means, confidence intervals and all that stuff. While I use function
                > > points, other sizing
                > > metrics can be used too.
                > >
                > > The larger the range or standard deviations the more project variation and
                > > the harder it is
                > > to predict and estimate.
                > >
                > > For an acquisition I will include some other numbers such as total
                > > application function
                > > points and come up with a market value or purchase price. I will calculate
                > > book value and
                > > good will.
                > >
                > > I gather a bunch qualitative project information as well. I gather it via
                > > observation not
                > > surveys.
                > >
                > > Waste
                > > The worse the productivity numbers the more waste or inefficient the
                > > project. Creating
                > > project documentation is not necessarily a waste. It is important to
                > > measure the number
                > > of times a document is reference or looked at by someone else (this is
                > > really easy to come
                > > up). If documents are being created and no one looks at then they need to
                > > be questioned.
                > >
                > > Project Comparisons (organizational comparisons)
                > > Projects can be compared to see what is causing the variation in
                > > productivity and other
                > > items. Questions like, Why are some projects more productivity than other
                > > projects? can
                > > be answered.
                > >
                > > I can compare organizations and ask, why is this organization 10 times
                > > more productive
                > > than another organization.
                > >
                > > User Groups (Business Side)
                > > I also try to get a read on the business side and understand what prompts
                > > them to ask for
                > > specific functionality. What experience levels do the "domain experts"
                > > have in relation to
                > > software development.
                > >
                > > I quantitative things like the % of time a domain expert is dedicated to a
                > > project as well as
                > > his tenure in the business group.
                > >
                > > I could go on and on....
                > >
                > > David Longstreet
                > > Software Economist
                > > www.SoftwareMetrics.Com
                > >
                > >
                > >
                >
                >
                > [Non-text portions of this message have been removed]
                >
                Yes, of course, I measure profit margins and increased revenue and profits. I think that is
                self evident from my previous post. I was given some examples not an exhaustive list.

                No software unless it is of some value returns anything to the bottom line.

                David Longstreet
                Software Economist
                www.SoftwareMetrics.Com
              • seidolce1960
                Manuel, I hope developers do not lie when they report their time. You need to have management that reward proper time reporting. It is hard to map any
                Message 7 of 18 , Jun 28, 2007
                • 0 Attachment
                  Manuel,

                  I hope developers do not lie when they report their time. You need to have management that
                  reward proper time reporting.

                  It is hard to map any specific piece of functionality to the bottom line. This why you need to
                  study your customer and make sure you are delivery the right functionality.

                  I examine how profits change when they start doing things differently in development.
                  Again, it is probably impossible to tag a piece of functionality to a specific bottom line result.
                  This has to done on an overall basis.

                  David Longstreet
                  Software Economist
                  www.SoftwareMetrics.Com
                • seidolce1960
                  Manuel, European to US comparison. The best numbers come from those companies with operations in Europe and the USA. This way we can make sure numbers are
                  Message 8 of 18 , Jun 28, 2007
                  • 0 Attachment
                    Manuel,

                    European to US comparison.

                    The best numbers come from those companies with operations in Europe and the USA. This
                    way we can make sure numbers are consistent. There can be some general comparisons
                    between companies also.

                    David Longstreet
                    Software Economist
                    www.SoftwareMetrics.Com
                  • William Pietri
                    ... I think that s an excellent point of agreement between all of us, David. A lot of the dialog in the agile community is around delivering business value.
                    Message 9 of 18 , Jun 28, 2007
                    • 0 Attachment
                      seidolce1960 wrote:
                      > No software unless it is of some value returns anything to the bottom line.
                      >

                      I think that's an excellent point of agreement between all of us, David.
                      A lot of the dialog in the agile community is around delivering business
                      value. Perhaps you could use that point of common interest more as you
                      make your points?

                      Thanks,

                      William
                    • Phlip
                      ... How could they, if they pair, work in a common area, and write the hours on the story card? Nobody is talking job-cost accounting here! ... Planning game?
                      Message 10 of 18 , Jun 28, 2007
                      • 0 Attachment
                        seidolce1960 wrote:

                        > I hope developers do not lie when they report their time. You need to have management that
                        > reward proper time reporting.

                        How could they, if they pair, work in a common area, and write the
                        hours on the story card?

                        Nobody is talking job-cost accounting here!

                        > It is hard to map any specific piece of functionality to the bottom line. This why you need to
                        > study your customer and make sure you are delivery the right functionality.

                        Planning game?

                        --
                        Phlip
                      • Steven Gordon
                        The implication was that you measured profit margins of the company, not the individual project. It would be interesting if a company could maintain high
                        Message 11 of 18 , Jun 28, 2007
                        • 0 Attachment
                          The implication was that you measured profit margins of the company, not the
                          individual project.

                          It would be interesting if a company could maintain high profitability while
                          wasting money producing lots of FPs on projects that were eventual failures,
                          but a monoploy could indeed do just that.

                          On 6/28/07, seidolce1960 <David@...> wrote:
                          >
                          >
                          >
                          > --- In extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
                          > "Steven Gordon" <sgordonphd@...>
                          > wrote:
                          > >
                          > > Is the ROI of a project a relevant factor? FPs that do not deliver
                          > business
                          > > value might as well be multiplied by 0.
                          > >
                          > > On 6/28/07, seidolce1960 <David@...> wrote:
                          > > >
                          > > > --- In
                          > extremeprogramming@yahoogroups.com <extremeprogramming%40yahoogroups.com>
                          > <extremeprogramming%40yahoogroups.com>,
                          >
                          > > > chet hendrickson <lists@> wrote:
                          > > > >
                          > > > > Hello David,
                          > > > >
                          > > > > In you comments you related your findings on productivity between
                          > > > > agile and traditional development as measured in hours per function
                          > > > > point. Can you tell us more about the hours part of this. Are you
                          > > > > measuring developer hours per function point or all hours expended
                          > on
                          > > > > the project?
                          > > > >
                          > > > > On a related topic, how do you measure the waste usually found in a
                          > > > > traditional/waterfall project. I am referring time and other
                          > > > > resources expended in creation of artifacts during the analysis and
                          > > > > design phases for features that are dropped later? This shouldn't
                          > > > > those efforts be viewed as an opportunity cost as well?
                          > > > >
                          > > > >
                          > > > > --
                          > > > > Best regards,
                          > > > > chet mailto:lists@
                          > > > >
                          > > > Chet,
                          > > >
                          > > > An organization needs to understand total time and cost on a project.
                          > > > Anyone working on
                          > > > the project needs to be recording their time. I use hours instead of
                          > cost
                          > > > or man days
                          > > > because everyone agrees on what an hour represents.
                          > > >
                          > > > When I develop cost figures I use an internally developed loaded rate,
                          > > > usually around
                          > > > $100/hr.
                          > > >
                          > > > Sometimes organizations have it recorded and sometimes I have to
                          > estimate
                          > > > it based up
                          > > > how much people are dedicated to projects and cost based upon internal
                          > > > salary numbers.
                          > > >
                          > > > It is important to know the blend of developers and everyone else
                          > charging
                          > > > time to a
                          > > > project.
                          > > >
                          > > > I develop a range of productivity based upon past completed projects.
                          > The
                          > > > larger the
                          > > > range the more variation in the way projects are completed.
                          > > >
                          > > > In most software organizations there is a tremendous amount of waste.
                          > When
                          > > > we establish
                          > > > some baseline numbers I do some comparisons with similar companies and
                          > > > create a "you
                          > > > are here diagram." This helps organizations understand potential
                          > > > improvements.
                          > > >
                          > > > Typically I develop a set of baseline number such as:
                          > > >
                          > > > 1. Time to Market
                          > > > 2. Hrs/FP (and $/FP).
                          > > > 3. Staff/FTE Ratio (FTE = full time equivalent).
                          > > > 4. Issues Per Hour Worked (development environment)
                          > > > 5. Issues Per Function Point
                          > > > 6. Production Issues Per Hour of Project
                          > > > 7. Production Issues per Function Point
                          > > > 8. Breakdown of Project by Task or by Phase (hopefully taken directly
                          > from
                          > > > project plans).
                          > > >
                          > > > I do this for several projects within an organization. I develop a
                          > range
                          > > > of number with
                          > > > means, confidence intervals and all that stuff. While I use function
                          > > > points, other sizing
                          > > > metrics can be used too.
                          > > >
                          > > > The larger the range or standard deviations the more project variation
                          > and
                          > > > the harder it is
                          > > > to predict and estimate.
                          > > >
                          > > > For an acquisition I will include some other numbers such as total
                          > > > application function
                          > > > points and come up with a market value or purchase price. I will
                          > calculate
                          > > > book value and
                          > > > good will.
                          > > >
                          > > > I gather a bunch qualitative project information as well. I gather it
                          > via
                          > > > observation not
                          > > > surveys.
                          > > >
                          > > > Waste
                          > > > The worse the productivity numbers the more waste or inefficient the
                          > > > project. Creating
                          > > > project documentation is not necessarily a waste. It is important to
                          > > > measure the number
                          > > > of times a document is reference or looked at by someone else (this is
                          > > > really easy to come
                          > > > up). If documents are being created and no one looks at then they need
                          > to
                          > > > be questioned.
                          > > >
                          > > > Project Comparisons (organizational comparisons)
                          > > > Projects can be compared to see what is causing the variation in
                          > > > productivity and other
                          > > > items. Questions like, Why are some projects more productivity than
                          > other
                          > > > projects? can
                          > > > be answered.
                          > > >
                          > > > I can compare organizations and ask, why is this organization 10 times
                          > > > more productive
                          > > > than another organization.
                          > > >
                          > > > User Groups (Business Side)
                          > > > I also try to get a read on the business side and understand what
                          > prompts
                          > > > them to ask for
                          > > > specific functionality. What experience levels do the "domain experts"
                          > > > have in relation to
                          > > > software development.
                          > > >
                          > > > I quantitative things like the % of time a domain expert is dedicated
                          > to a
                          > > > project as well as
                          > > > his tenure in the business group.
                          > > >
                          > > > I could go on and on....
                          > > >
                          > > > David Longstreet
                          > > > Software Economist
                          > > > www.SoftwareMetrics.Com
                          > > >
                          > > >
                          > > >
                          > >
                          > >
                          > > [Non-text portions of this message have been removed]
                          > >
                          > Yes, of course, I measure profit margins and increased revenue and
                          > profits. I think that is
                          > self evident from my previous post. I was given some examples not an
                          > exhaustive list.
                          >
                          > No software unless it is of some value returns anything to the bottom
                          > line.
                          >
                          > David Longstreet
                          > Software Economist
                          > www.SoftwareMetrics.Com
                          >
                          >
                          >


                          [Non-text portions of this message have been removed]
                        • Jon Eaves
                          ... I think you ll find most large financial institutions are incredibly adept at doing this. Banks and insurance companies have found a way to dislocate the
                          Message 12 of 18 , Jun 28, 2007
                          • 0 Attachment
                            Steven Gordon wrote:
                            > The implication was that you measured profit margins of the company, not the
                            > individual project.
                            >
                            > It would be interesting if a company could maintain high profitability while
                            > wasting money producing lots of FPs on projects that were eventual failures,
                            > but a monoploy could indeed do just that.

                            I think you'll find most large financial institutions are incredibly adept at
                            doing this. Banks and insurance companies have found a way to dislocate the
                            cost of development from their profit margins. Something that I'm particularly
                            interested in understanding.

                            It's an area that I'm actively exploring with my management, to identify the
                            affect of good software development practices and the success and/or failure of
                            software projects on our divisional and corporate profitability over time.

                            I'm not getting a huge amount of traction right now, mostly because others don't
                            see it as important, and I'm not currently adept enough at communication about why
                            it is important to move forward.

                            Oh well, one bite of the elephant at a time.

                            Cheers,
                            -- jon

                            --
                            Jon Eaves <jon@...>
                            http://www.eaves.org/blog/
                            Co-Author of "Apache Tomcat Bible", "Professional Tomcat 5", "Beginning JavaServer Pages"
                          • Micron Engineering
                            ... project. ... use ... an ... Ok, I do this from the beginning of my career. ... waste. Yes, this is common expecially in big companies, it is common also in
                            Message 13 of 18 , Jun 28, 2007
                            • 0 Attachment
                              seidolce1960 ha scritto:
                              >



                              > Chet,

                              >

                              > An organization needs to understand total time and cost on a
                              project.

                              > Anyone working on the project needs to be recording their time. I
                              use

                              > hours instead of cost or man days because everyone agrees on what
                              an

                              > hour represents.


                              Ok, I do this from the beginning of my career.
                              >

                              >

                              > Sometimes organizations have it recorded and sometimes I have to

                              > estimate it based up how much people are dedicated to projects and

                              > cost based upon internal salary numbers.

                              >

                              > In most software organizations there is a tremendous amount of
                              waste.


                              Yes, this is common expecially in big companies, it is common also in
                              other industries not sw related

                              > When we establish some baseline
                              numbers I do some comparisons with

                              > similar companies and create a "you are here diagram." This helps

                              > organizations understand potential improvements.

                              >

                              > Typically I develop a set of baseline number such as:

                              >

                              > 1. Time to Market 2. Hrs/FP (and $/FP). 3. Staff/FTE Ratio (FTE =

                              > full time equivalent). 4. Issues Per Hour Worked (development

                              > environment) 5. Issues Per Function Point 6. Production Issues Per

                              > Hour of Project 7. Production Issues per Function Point 8.
                              Breakdown

                              > of Project by Task or by Phase (hopefully taken directly from
                              project

                              > plans).

                              >
                              I cut a lot here...

                              >

                              > I could go on and on....


                              David I am sure, you do a great job but this job is more related to
                              managers then to engineers. In my career I saw a lot of managers calling
                              a consultant to solve problems created by management itself (but they
                              think created by development teams).
                              Generally best results I seen came from self reorganized teams made by
                              skilled and motivated engineers. Measuring productivity on creative
                              engineering teams (skankworks teams) is like a joke, they have the
                              minimum productivity in the world but they made a lot of impressive
                              products (not only sw).
                              To make a great job you need skilled engineers (skilled teams
                              ofengineers), skilled team leaders/managers and a company that recognize
                              that its "people" is its reachness. It is not so difficult to recognize
                              these qualities in start up companies of last 20-30 years on electronics
                              and sw industry (I am sure also in other activities but I don't
                              personally know).
                              >

                              > David Longstreet Software Economist www.SoftwareMetrics.Com

                              >




                              [Non-text portions of this message have been removed]
                            • Ilja Preuss
                              ... How would management know whether time reporting was proper? Curious, Ilja
                              Message 14 of 18 , Jul 1 11:39 AM
                              • 0 Attachment
                                seidolce1960 wrote:

                                > I hope developers do not lie when they report their time. You need to have management that
                                > reward proper time reporting.

                                How would management know whether time reporting was proper?

                                Curious, Ilja
                              • Chris Wheeler
                                ... Speaking of productivity, there is an interesting paper called Kratylus Automates His Urnworks that addresses some issues around deciding what
                                Message 15 of 18 , Jul 1 3:07 PM
                                • 0 Attachment
                                  On 6/28/07, chet hendrickson <lists@...> wrote:
                                  >
                                  > Hello David,
                                  >
                                  > In you comments you related your findings on productivity between
                                  > agile and traditional development as measured in hours per function
                                  > point. Can you tell us more about the hours part of this. Are you
                                  > measuring developer hours per function point or all hours expended on
                                  > the project?


                                  Speaking of productivity, there is an interesting paper called 'Kratylus
                                  Automates His Urnworks' that addresses some issues around deciding what
                                  productivity is and how it could be measured. I can't recall who wrote it,
                                  but it's a fairly fun read and should make anyone come away with some
                                  different thoughts around productivity.

                                  Chris.


                                  [Non-text portions of this message have been removed]
                                • Dave Nicolette
                                  ... wrote it, ... I googled the title and found a reference to it: Harvard Business Review, May-June 1984 Kratylus Automates His Urnworks, by Tolly Kizilos The
                                  Message 16 of 18 , Jul 1 7:13 PM
                                  • 0 Attachment
                                    --- In extremeprogramming@yahoogroups.com, "Chris Wheeler"
                                    <christopher.wheeler@...> wrote:
                                    >
                                    > On 6/28/07, chet hendrickson <lists@...> wrote:
                                    > >
                                    > > Hello David,
                                    > >
                                    > > In you comments you related your findings on productivity between
                                    > > agile and traditional development as measured in hours per function
                                    > > point. Can you tell us more about the hours part of this. Are you
                                    > > measuring developer hours per function point or all hours expended on
                                    > > the project?
                                    >
                                    >
                                    > Speaking of productivity, there is an interesting paper called 'Kratylus
                                    > Automates His Urnworks' that addresses some issues around deciding what
                                    > productivity is and how it could be measured. I can't recall who
                                    wrote it,
                                    > but it's a fairly fun read and should make anyone come away with some
                                    > different thoughts around productivity.
                                    >
                                    > Chris.

                                    I googled the title and found a reference to it:

                                    Harvard Business Review, May-June 1984
                                    Kratylus Automates His Urnworks, by Tolly Kizilos

                                    The full text may be available in a subscription online library or in
                                    a meatspace library. Sounds interesting.

                                    Dave
                                  • Scott Ambler
                                    ... need to have management that ... How many times have you seen people fill in their time sheets so that it conforms to the plan, regardless of what actually
                                    Message 17 of 18 , Jul 2 12:47 AM
                                    • 0 Attachment
                                      --- In extremeprogramming@yahoogroups.com, Ilja Preuss <it@...> wrote:
                                      >
                                      > seidolce1960 wrote:
                                      >
                                      > > I hope developers do not lie when they report their time. You
                                      need to have management that
                                      > > reward proper time reporting.
                                      >
                                      > How would management know whether time reporting was proper?

                                      How many times have you seen people fill in their time sheets so that
                                      it conforms to the plan, regardless of what actually happened? Is
                                      that proper?

                                      How many times have you seen people fill in their timesheets with
                                      lower hours than actually worked so that they came in on budget?

                                      Also, is time expended the real issue? If I spend 50 hours coding,
                                      is that more valuable than the 5 minutes I spent to come up with an
                                      architectural strategy that saved 500 hours of coding?

                                      - Scott
                                    • Nicholas Cancelliere
                                      100% agree with you here Scott, well put. I ve seen it happen on the projects I work on. If accounting wants more capex hours the managers would tell me find
                                      Message 18 of 18 , Jul 2 5:12 AM
                                      • 0 Attachment
                                        100% agree with you here Scott, well put. I've seen it happen on the
                                        projects I work on. If accounting wants more capex hours the
                                        managers would tell me find and bill as much capex as I could (almost
                                        hinting that I should ignore or try not to find opex hours). Or when
                                        opex was desired, it'd be the other way around. Then you had the
                                        developers themselves trying to either look under budget or not
                                        appear to be underestimating (which is erroneously looked at as
                                        incompetence, if you can't estimate right - in itself a whole other
                                        problem).

                                        In the end you get numbers that are nothing near reality. I don't
                                        think having developers keep their hours is any accurate gauge of
                                        productivity because of my experience. And as you said -- if someone
                                        spends 2 hrs on something to eliminate 2 days of coding find a better
                                        solution to something, how much is that worth?

                                        Nicholas



                                        On Jul 2, 2007, at 2:47 AM, Scott Ambler wrote:

                                        > --- In extremeprogramming@yahoogroups.com, Ilja Preuss <it@...> wrote:
                                        >>
                                        >> seidolce1960 wrote:
                                        >>
                                        >>> I hope developers do not lie when they report their time. You
                                        > need to have management that
                                        >>> reward proper time reporting.
                                        >>
                                        >> How would management know whether time reporting was proper?
                                        >
                                        > How many times have you seen people fill in their time sheets so that
                                        > it conforms to the plan, regardless of what actually happened? Is
                                        > that proper?
                                        >
                                        > How many times have you seen people fill in their timesheets with
                                        > lower hours than actually worked so that they came in on budget?
                                        >
                                        > Also, is time expended the real issue? If I spend 50 hours coding,
                                        > is that more valuable than the 5 minutes I spent to come up with an
                                        > architectural strategy that saved 500 hours of coding?
                                        >
                                        > - Scott
                                        >
                                        >
                                        >
                                        > To Post a message, send it to: extremeprogramming@...
                                        >
                                        > To Unsubscribe, send a blank message to: extremeprogramming-
                                        > unsubscribe@...
                                        >
                                        > ad-free courtesy of objectmentor.com
                                        > Yahoo! Groups Links
                                        >
                                        >
                                        >

                                        ---
                                        Nicholas Cancelliere
                                        Austin, TX




                                        [Non-text portions of this message have been removed]
                                      Your message has been successfully submitted and would be delivered to recipients shortly.