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

Products or projects?

Expand Messages
  • Tobias Fors
    Mary/Tom: have you written on, or do you know of a good treatment of, possible practical consequences of handling software development as projects or
    Message 1 of 12 , Jun 13, 2006
    View Source
    • 0 Attachment
      Mary/Tom:

      have you written on, or do you know of a good treatment of, possible
      practical consequences of handling software development as "projects"
      or "products"? I'm a bit sloppy in my description here, but I think
      you might know what I mean.

      This might be simply an insignificant semantical difference, but I
      think I've seen you express a preference for the latter at some time.

      I myself am bothered by how the concept of a "project" seems to have
      become an excuse for not having to think about things like
      ineffeciences caused by multi-tasking, the problems of maintaining a
      huge number of differing initiatives that all attempt to modify the
      same code base, and so on. "Just start a project and we'll be fine. No
      'buts'!"

      I believe our language controls our thinking, which controls our
      behavior. Who has experience with this when it comes to talking about
      "products" or "projects"?

      Best regards
      Tobias Fors
    • Alan Shalloway
      ... time. ... Good question. The difference between products and projects is much more than an insignificant semantic difference and is an area where Lean
      Message 2 of 12 , Jun 13, 2006
      View Source
      • 0 Attachment
        --- In leandevelopment@yahoogroups.com, "Tobias Fors"
        <tobias.fors@...> wrote:
        > This might be simply an insignificant semantical difference, but I
        > think I've seen you express a preference for the latter at some
        time.
        >

        Good question. The difference between products and projects is much
        more than an insignificant semantic difference and is an area where
        Lean extends most other agile thinking (e.g., Scrum, XP) which are
        project centric. Products are about something the company offers to
        its customers (internal for IT products) while projects are about
        building the product. Products spawn several projects. Good
        products will grow, mature and continue to add value to the customer
        in different ways and will therefore spawn multiple projects.

        Many companies have more waste in their project selection process
        than in their project building process. They will spend 1-2 _years_
        deciding whether to approve a project. Once they have selected a
        project to build, Scrum and XP can be put into place. However, what
        they really could use to help them is the understanding of waste
        that Lean provides. Waste includes delay, task-switching, hand-
        offs... Things not showing up on an accountants balance sheet.
        Value stream maps are incredibly useful tools in this area. In both
        my Lean courses and the courses of Mary and Tom's I have seen, this
        is one of the biggest areas of impacts students have - how to
        improve the process of selecting which projects to biuld.

        Besides this direct value of thinking products instead of projects,
        the concept also reminds us that our customers are not really
        interested in software anyway. The software we deliver is a piece of
        a larger product that delivers value to the customer. We must
        always remain value-centric to the customer.

        Scrum and XP do a great job of this once the project starts - but
        getting it to start, that's another story.

        Alan Shalloway, CEO, Sr. Consultant
        Phone: 425-269-8991 Fax 425-642-8202

        Strengthening your organization's software development processes,
        practices, and techniques through training, coaching, and consulting.

        Upcoming Courses
        Test-Driven ASP.Net Jun 13-15 Bellevue, WA
        Test-Driven Development Jun 20-22 San Jose, CA
        ScrumMaster Certification Jun 21-22 Vancouver, BC
        Certified Product Owner Jun 26-27 San Francisco, CA
        ScrumMaster Certification Jun 28-29 San Francisco, CA
        Design Patterns Explained Jul 11-13 Bellevue, WA
        ScrumMaster Certification Jul 18-19 Bellevue, WA
        ScrumMaster Certification Jul 18-19 Charlotte, NC
        ScrumMaster Certification Jul 31-Aug 1 New York, NY
        Lean Software Development Aug 8-9 Bellevue, WA
        Certified Product Owner Aug 9-10 San Jose, CA
        Design Patterns Explained Aug 15-17 San Jose, CA
        ScrumMaster Certification Aug 16-17 Bloomington, MN
        ScrumMaster Certification Sep 20-21 San Jose, CA
      • Hubert Smits
        Tobias, I agree with what Alan says in his reply. We (Jeff, Jean and I) have been wrestling with the difference between project, program and product. Project
        Message 3 of 12 , Jun 13, 2006
        View Source
        • 0 Attachment
          Tobias,

          I agree with what Alan says in his reply. We (Jeff, Jean and I) have
          been wrestling with the difference between project, program and
          product. Project is easily defined (re. Alan's post), but when scaling
          agile/Scrum to the next magnitude (multiple teams working on multiple
          backlogs) that have a link (they deliver into the same program/product
          suite), what is the vocabulary to be used? We've settled on Program
          (for now) as Product would pull the definition of teams, deliverables
          etc. outside the software environment. This has to happen, and
          happens, I know that. For now the knowledge/experience we can share is
          limited to the software delivery part of product development, hence
          sticking with Projects vs. Programs.

          What triggered the question?

          --Hubert

          On 6/13/06, Tobias Fors <tobias.fors@...> wrote:
          > Mary/Tom:
          >
          > have you written on, or do you know of a good treatment of, possible
          > practical consequences of handling software development as "projects"
          > or "products"? I'm a bit sloppy in my description here, but I think
          > you might know what I mean.
          >
          > This might be simply an insignificant semantical difference, but I
          > think I've seen you express a preference for the latter at some time.
          >
          > I myself am bothered by how the concept of a "project" seems to have
          > become an excuse for not having to think about things like
          > ineffeciences caused by multi-tasking, the problems of maintaining a
          > huge number of differing initiatives that all attempt to modify the
          > same code base, and so on. "Just start a project and we'll be fine. No
          > 'buts'!"
          >
          > I believe our language controls our thinking, which controls our
          > behavior. Who has experience with this when it comes to talking about
          > "products" or "projects"?
          >
          > Best regards
          > Tobias Fors
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >


          --

          All opinions in this message are my own, and are not necessarily
          shared by my employer.
        • Tobias Fors
          Hubert: no specific event, just a growing interest in how these terms are (mis)used to justify particular behaviors, like trying to shove too much work through
          Message 4 of 12 , Jun 13, 2006
          View Source
          • 0 Attachment
            Hubert:

            no specific event, just a growing interest in how these terms are (mis)used to justify particular behaviors, like trying to shove too much work through an organization.

            /Tobias


            13 jun 2006 kl. 20.32 skrev Hubert Smits:

            Tobias,

            I agree with what Alan says in his reply. We (Jeff, Jean and I) have
            been wrestling with the difference between project, program and
            product. Project is easily defined (re. Alan's post), but when scaling
            agile/Scrum to the next magnitude (multiple teams working on multiple
            backlogs) that have a link (they deliver into the same program/product
            suite), what is the vocabulary to be used? We've settled on Program
            (for now) as Product would pull the definition of teams, deliverables
            etc. outside the software environment. This has to happen, and
            happens, I know that. For now the knowledge/experience we can share is
            limited to the software delivery part of product development, hence
            sticking with Projects vs. Programs.

            What triggered the question?

            --Hubert


          • Tobias Fors
            Hubert: can you elaborate a bit on the part where you write that Product would pull the definition[s] outside the software environment ? /Tobias
            Message 5 of 12 , Jun 13, 2006
            View Source
            • 0 Attachment
              Hubert:

              can you elaborate a bit on the part where you write that "Product would pull the definition[s] outside the software environment"?

              /Tobias


              13 jun 2006 kl. 20.32 skrev Hubert Smits:

              Tobias,

              I agree with what Alan says in his reply. We (Jeff, Jean and I) have
              been wrestling with the difference between project, program and
              product. Project is easily defined (re. Alan's post), but when scaling
              agile/Scrum to the next magnitude (multiple teams working on multiple
              backlogs) that have a link (they deliver into the same program/product
              suite), what is the vocabulary to be used? We've settled on Program
              (for now) as Product would pull the definition of teams, deliverables
              etc. outside the software environment. This has to happen, and
              happens, I know that. 

              .
               

            • Mary Poppendieck
              Tobias, I personally would like to see the term project abandoned in software development, and actually, I disagree with Alan that projects are about building
              Message 6 of 12 , Jun 13, 2006
              View Source
              • 0 Attachment
                Tobias,

                I personally would like to see the term project abandoned in software
                development, and actually, I disagree with Alan that "projects are about
                building the product." However, Tom and I are in Europe right now, so our
                timing on answering threads may be a little delayed.

                In my experience, project thinking comes from contract-inspired controls
                that are both unnecessary and wasteful in a vertically integrated company.
                Projects are defined (by PMI) as something that has a beginning and an end,
                but then, product development also has a beginning and an end. However, few
                people in product development care to apply the term project or traditional
                project concepts to product development.

                So I like to make a different distinction, one that seems to be realistic in
                many (but not all) situations. Products are development efforts that are
                (usually) funded incrementally. They start with a concept and end with a
                product launch. Along the way, the are funded incrementally as they
                progress through stages such as feasibility, test market, commercialization,
                etc. Different companies will have different steps, but in general product
                development funding is approved incrementally as the product concept grows
                and is fleshed out and proven. Products are also expected to have a long
                and useful life over which timeframe they are generally expected to undergo
                constant improvement.

                Projects, on the other hand, due to their contract origins, tend to be fully
                funded at the beginning of the project. This front-end loaded funding tends
                to drive the people providing the funds to ask for scope and schedule plans,
                which are then treated as commitments - after all - the funds are committed,
                so they want to know what they will get for the money. In addition,
                on-going change after the "end" of a project is generally regarded as bad.

                I have done a lot more product development than I have done projects, and I
                have found that because product development has the expectation that a new
                product will be funded and developed over time. Therefore, iterative
                development is often assumed as the only appropriate development approach in
                much of the product development world.

                Success in product development is generally measured in terms of market
                share and profit. Success in projects is generally defined in terms of
                earned value and conformance to a cost-schedule-scope plan. I believe that
                it is much healthier to measure business success than conformance to a
                (probably misguided, and almost always premature) plan.

                For these reasons and more, I personally believe that most software
                development - even internal IT development - would be better off thought of
                as product development rather than using the project label and the
                inappropriate metaphors that brings to mind.

                Mary Poppendieck
                www.poppendieck.com
                Author of: Lean Software Development

                -----Original Message-----
                From: leandevelopment@yahoogroups.com
                [mailto:leandevelopment@yahoogroups.com] On Behalf Of Tobias Fors
                Sent: Tuesday, June 13, 2006 11:42 AM
                To: leandevelopment@yahoogroups.com
                Subject: [leandevelopment] Products or projects?

                Mary/Tom:

                have you written on, or do you know of a good treatment of, possible
                practical consequences of handling software development as "projects"
                or "products"? I'm a bit sloppy in my description here, but I think
                you might know what I mean.

                This might be simply an insignificant semantical difference, but I
                think I've seen you express a preference for the latter at some time.

                I myself am bothered by how the concept of a "project" seems to have
                become an excuse for not having to think about things like
                ineffeciences caused by multi-tasking, the problems of maintaining a
                huge number of differing initiatives that all attempt to modify the
                same code base, and so on. "Just start a project and we'll be fine. No
                'buts'!"

                I believe our language controls our thinking, which controls our
                behavior. Who has experience with this when it comes to talking about
                "products" or "projects"?

                Best regards
                Tobias Fors




                Yahoo! Groups Links
              • Mary Poppendieck
                Hubert, Do you really mean to say that we should not think about the overall whole product rather than just the software part of a product when we consider
                Message 7 of 12 , Jun 13, 2006
                View Source
                • 0 Attachment
                  Hubert,

                  Do you really mean to say that we should not think about the overall "whole
                  product" rather than just the software part of a product when we consider
                  agile or lean development? If that is what you mean, I have to say I could
                  not disagree more strongly. Whenever we develop software, I believe it is
                  imperative to think of the final product or business process in which the
                  software is embedded. I believe that a complete team - not just a software
                  development team - should be chartered to develop the complete product.

                  Today we were in a class and one banking company - considered one of the
                  best managed companies in Sweden - has several people there. They said that
                  in their company there is NO SUCH THING AS AN IT PROJECT. And indeed, their
                  value stream map was about a request to deploy a new business process. IT
                  was just part of the value stream, part of the team, and part of the
                  solution. This company has had tremendous success with this approach, and I
                  recommend it to all.

                  Mary Poppendieck
                  www.poppendieck.com
                  Author of: Lean Software Development

                  -----Original Message-----
                  From: leandevelopment@yahoogroups.com
                  [mailto:leandevelopment@yahoogroups.com] On Behalf Of Hubert Smits
                  Sent: Tuesday, June 13, 2006 8:32 PM
                  To: leandevelopment@yahoogroups.com
                  Subject: Re: [leandevelopment] Products or projects?

                  Tobias,

                  I agree with what Alan says in his reply. We (Jeff, Jean and I) have
                  been wrestling with the difference between project, program and
                  product. Project is easily defined (re. Alan's post), but when scaling
                  agile/Scrum to the next magnitude (multiple teams working on multiple
                  backlogs) that have a link (they deliver into the same program/product
                  suite), what is the vocabulary to be used? We've settled on Program
                  (for now) as Product would pull the definition of teams, deliverables
                  etc. outside the software environment. This has to happen, and
                  happens, I know that. For now the knowledge/experience we can share is
                  limited to the software delivery part of product development, hence
                  sticking with Projects vs. Programs.

                  What triggered the question?

                  --Hubert

                  On 6/13/06, Tobias Fors <tobias.fors@...> wrote:
                  > Mary/Tom:
                  >
                  > have you written on, or do you know of a good treatment of, possible
                  > practical consequences of handling software development as "projects"
                  > or "products"? I'm a bit sloppy in my description here, but I think
                  > you might know what I mean.
                  >
                  > This might be simply an insignificant semantical difference, but I
                  > think I've seen you express a preference for the latter at some time.
                  >
                  > I myself am bothered by how the concept of a "project" seems to have
                  > become an excuse for not having to think about things like
                  > ineffeciences caused by multi-tasking, the problems of maintaining a
                  > huge number of differing initiatives that all attempt to modify the
                  > same code base, and so on. "Just start a project and we'll be fine. No
                  > 'buts'!"
                  >
                  > I believe our language controls our thinking, which controls our
                  > behavior. Who has experience with this when it comes to talking about
                  > "products" or "projects"?
                  >
                  > Best regards
                  > Tobias Fors
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                  >


                  --

                  All opinions in this message are my own, and are not necessarily
                  shared by my employer.




                  Yahoo! Groups Links
                • Alfvin, Peter
                  Mary, I think the situation of the baggage around the word project mirrors the situation of the baggage around the word process. In both cases, I think the
                  Message 8 of 12 , Jun 14, 2006
                  View Source
                  • 0 Attachment
                    Mary,
                     
                    I think the situation of the baggage around the word project mirrors the situation of the baggage around the word process.  In both cases, I think the right strategy for Lean is to rehabilitate the term rather than reject it.
                     
                    What you describe for product development (start with a concept, fund incrementally, end with a launch) matches my understanding of modern software development projects and matches my understanding of modern project lifecycles (e.g. the Unified Process as interpreted today by Philippe, Per, Scott, etc).  Equating projects to all-funding-up-front seems like equating processes to BDUF and waterfall.
                     
                    I'm not denying that it's important to characterize software development as product development, but I think projects, like processes, are the means to that product development end.  They are simply generic mechanisms for organizing work.
                     
                    Pete
                     
                    P.S. I actually thought this discussion was going to lead to whether we even should treat software development has having a beginning or an end, or whether it should just be a continuum of work (e.g. a series of Scrum sprints), with no notion of milestones or major releases or any partitioning whatsoever aside from the iterations themselves.  While that's an interesting notion to me, I've been unable to convince myself that you wouldn't be giving up something significant with that approach.
                     
                     

                    From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Mary Poppendieck
                    Sent: Tuesday, June 13, 2006 1:11 PM
                    To: leandevelopment@yahoogroups.com
                    Subject: RE: [leandevelopment] Products or projects?

                    Tobias,

                    I personally would like to see the term project abandoned in software
                    development, and actually, I disagree with Alan that "projects are about
                    building the product." However, Tom and I are in Europe right now, so our
                    timing on answering threads may be a little delayed.

                    In my experience, project thinking comes from contract-inspired controls
                    that are both unnecessary and wasteful in a vertically integrated company.
                    Projects are defined (by PMI) as something that has a beginning and an end,
                    but then, product development also has a beginning and an end. However, few
                    people in product development care to apply the term project or traditional
                    project concepts to product development.

                    So I like to make a different distinction, one that seems to be realistic in
                    many (but not all) situations. Products are development efforts that are
                    (usually) funded incrementally. They start with a concept and end with a
                    product launch. Along the way, the are funded incrementally as they
                    progress through stages such as feasibility, test market, commercialization,
                    etc. Different companies will have different steps, but in general product
                    development funding is approved incrementally as the product concept grows
                    and is fleshed out and proven. Products are also expected to have a long
                    and useful life over which timeframe they are generally expected to undergo
                    constant improvement.

                    Projects, on the other hand, due to their contract origins, tend to be fully
                    funded at the beginning of the project. This front-end loaded funding tends
                    to drive the people providing the funds to ask for scope and schedule plans,
                    which are then treated as commitments - after all - the funds are committed,
                    so they want to know what they will get for the money. In addition,
                    on-going change after the "end" of a project is generally regarded as bad.

                    I have done a lot more product development than I have done projects, and I
                    have found that because product development has the expectation that a new
                    product will be funded and developed over time. Therefore, iterative
                    development is often assumed as the only appropriate development approach in
                    much of the product development world.

                    Success in product development is generally measured in terms of market
                    share and profit. Success in projects is generally defined in terms of
                    earned value and conformance to a cost-schedule- scope plan. I believe that
                    it is much healthier to measure business success than conformance to a
                    (probably misguided, and almost always premature) plan.

                    For these reasons and more, I personally believe that most software
                    development - even internal IT development - would be better off thought of
                    as product development rather than using the project label and the
                    inappropriate metaphors that brings to mind.

                    Mary Poppendieck
                    www.poppendieck. com
                    Author of: Lean Software Development

                    -----Original Message-----
                    From: leandevelopment@ yahoogroups. com
                    [mailto:leandevelopment@ yahoogroups. com] On Behalf Of Tobias Fors
                    Sent: Tuesday, June 13, 2006 11:42 AM
                    To: leandevelopment@ yahoogroups. com
                    Subject: [leandevelopment] Products or projects?

                    Mary/Tom:

                    have you written on, or do you know of a good treatment of, possible
                    practical consequences of handling software development as "projects"
                    or "products"? I'm a bit sloppy in my description here, but I think
                    you might know what I mean.

                    This might be simply an insignificant semantical difference, but I
                    think I've seen you express a preference for the latter at some time.

                    I myself am bothered by how the concept of a "project" seems to have
                    become an excuse for not having to think about things like
                    ineffeciences caused by multi-tasking, the problems of maintaining a
                    huge number of differing initiatives that all attempt to modify the
                    same code base, and so on. "Just start a project and we'll be fine. No
                    'buts'!"

                    I believe our language controls our thinking, which controls our
                    behavior. Who has experience with this when it comes to talking about
                    "products" or "projects"?

                    Best regards
                    Tobias Fors

                    Yahoo! Groups Links

                  • Johannes Brodwall
                    Hi, Mary I found this post to be very inspiring, but I am wondering if I misunderstand something. ... From the rest of the post, I thought you were talking
                    Message 9 of 12 , Jun 18, 2006
                    View Source
                    • 0 Attachment
                      Hi, Mary

                      I found this post to be very inspiring, but I am wondering if I
                      misunderstand something.

                      On 6/13/06, Mary Poppendieck <mary@...> wrote:
                      > Tobias,
                      >
                      > So I like to make a different distinction, one that seems to be realistic in
                      > many (but not all) situations. Products are development efforts that are
                      > (usually) funded incrementally. They start with a concept and end with a
                      > product launch.

                      From the rest of the post, I thought you were talking about products
                      as things that stay in production, live and grow (and get funded) for
                      many years. But I read you to say "products are development efforts
                      that ... end with a product launch". Shouldn't this be "ends with a
                      product retirement"?

                      As I understand products, the launch is only the beginning. As I
                      understand Lean (and Agile), the initial launch should be fairly
                      quickly after the start.

                      I also cannot reconcile the above sentence with the rest of this paragraph:

                      > Along the way, the are funded incrementally as they
                      > progress through stages such as feasibility, test market, commercialization,
                      > etc. Different companies will have different steps, but in general product
                      > development funding is approved incrementally as the product concept grows
                      > and is fleshed out and proven. Products are also expected to have a long
                      > and useful life over which timeframe they are generally expected to undergo
                      > constant improvement.
                      >

                      So, which is it: A "product" has many launches/deliveries, or only
                      one? Or could it just be that I'm thinking about internal software and
                      you're writing about shrink-wrap?



                      ~Johannes
                    • Mary Poppendieck
                      Johannes, Good question! I ll go with a product has many launches/deliveries. A much more realistic point of view for software. Mary Poppendieck
                      Message 10 of 12 , Jun 18, 2006
                      View Source
                      • 0 Attachment
                        Johannes,

                        Good question! I'll go with a "product" has many launches/deliveries. A
                        much more realistic point of view for software.

                        Mary Poppendieck
                        www.poppendieck.com
                        Author of: Lean Software Development
                        -----Original Message-----
                        From: leandevelopment@yahoogroups.com
                        [mailto:leandevelopment@yahoogroups.com] On Behalf Of Johannes Brodwall
                        Sent: Sunday, June 18, 2006 2:54 PM
                        To: leandevelopment@yahoogroups.com
                        Subject: Re: [leandevelopment] Products or projects?

                        Hi, Mary

                        I found this post to be very inspiring, but I am wondering if I
                        misunderstand something.

                        On 6/13/06, Mary Poppendieck <mary@...> wrote:
                        > Tobias,
                        >
                        > So I like to make a different distinction, one that seems to be realistic
                        in
                        > many (but not all) situations. Products are development efforts that are
                        > (usually) funded incrementally. They start with a concept and end with a
                        > product launch.

                        From the rest of the post, I thought you were talking about products
                        as things that stay in production, live and grow (and get funded) for
                        many years. But I read you to say "products are development efforts
                        that ... end with a product launch". Shouldn't this be "ends with a
                        product retirement"?

                        As I understand products, the launch is only the beginning. As I
                        understand Lean (and Agile), the initial launch should be fairly
                        quickly after the start.

                        I also cannot reconcile the above sentence with the rest of this paragraph:

                        > Along the way, the are funded incrementally as they
                        > progress through stages such as feasibility, test market,
                        commercialization,
                        > etc. Different companies will have different steps, but in general
                        product
                        > development funding is approved incrementally as the product concept grows
                        > and is fleshed out and proven. Products are also expected to have a long
                        > and useful life over which timeframe they are generally expected to
                        undergo
                        > constant improvement.
                        >

                        So, which is it: A "product" has many launches/deliveries, or only
                        one? Or could it just be that I'm thinking about internal software and
                        you're writing about shrink-wrap?



                        ~Johannes




                        Yahoo! Groups Links
                      • Glen B Alleman
                        Mary, Your discussion between product and project is very interesting. In the world of spacecraft the product is launched literally at the end of the
                        Message 11 of 12 , Jun 18, 2006
                        View Source
                        • 0 Attachment
                          Mary,

                          Your discussion between product and project is very interesting. In the
                          world of spacecraft the "product" is "launched" literally at the end of the
                          project (program). In some cases the program continues with on-orbit
                          operations, which can be transferred to another program - the operations
                          program, which has many projects.

                          In large construction - site remediation, interstate highway development -
                          the "product" is "launched" by having the drivers drive on the highway. Many
                          projects are the path to completion - bridges, drainage, roadway, lighting,
                          as well as the basic roadway. The remediation projects have similar
                          structures where the "product" is the removal of the site wastes.

                          While the "product" approach is useful, so is the "project" approach. Both
                          can have incremental deliverables with fully functional but partially
                          capable features - this is the basis of capabilities based planning (CBP)
                          current in use in defense and civil program. This approach (CBP) works well
                          for enterprise IT was well.

                          In the end projects produce products of some form. Whether you call it a
                          project/program or a product probably depends on your starting point of
                          view.

                          Both paradigms are useful, both have value and both have limitations.

                          Glen B. Alleman
                          www.niwotridge.com
                          www.niwotridge.com/Blog


                          > -----Original Message-----
                          > From: Mary Poppendieck
                          > Subject: RE: [leandevelopment] Products or projects?
                          >
                          > Johannes,
                          >
                          > Good question! I'll go with a "product" has many launches/deliveries. A
                          > much more realistic point of view for software.
                          >
                          > Mary
                        • Brad Appleton
                          My most recent experience (last 6+ years) resonates with what Mary says below. Prior to that, I used to think of project-team and product-team as synonymous
                          Message 12 of 12 , Jun 23, 2006
                          View Source
                          • 0 Attachment
                            My most recent experience (last 6+ years) resonates with what Mary says
                            below. Prior to that, I used to think of project-team and product-team
                            as synonymous terms, and felt that product & project were almost
                            synonymous too, except that "project" emphasized the work and "product"
                            emphasized the deliverable.

                            But for the last 6+ years "project" and "product" have meant VERY
                            different things to the development team. The "product" is the thing
                            that we develop and maintain, release after release. Whereas a "project"
                            is the work-plan for a single release of the product. (And the
                            "architecture" is what sustains the product from release to release and
                            holds it together, or causes it to fall apart)

                            In this scenario, project managers and senior technical folk are
                            frequently very much at odds with one another, because they dont have
                            the same definition and criteria of "success". The project manager gets
                            motivated and rewarded based on the "success" of the individual
                            projects: was each release "on-time, in-scope and within budget". Things
                            that cause "technical debt" to be incurred, but which are paid off as
                            part of a later project are not as important as checking off the "done"
                            box on the current project. So there is a lot of motivation to be
                            short-sighted and sub-optimizing at the expense of being able to sustain
                            and grow to meet the increasing demands of the customer.


                            Mary Poppendieck wrote:
                            > In my experience, project thinking comes from contract-inspired controls
                            > that are both unnecessary and wasteful in a vertically integrated company.
                            > Projects are defined (by PMI) as something that has a beginning and an end,
                            > but then, product development also has a beginning and an end. However, few
                            > people in product development care to apply the term project or traditional
                            > project concepts to product development.
                            >
                            > So I like to make a different distinction, one that seems to be realistic in
                            > many (but not all) situations. Products are development efforts that are
                            > (usually) funded incrementally. They start with a concept and end with a
                            > product launch. Along the way, the are funded incrementally as they
                            > progress through stages such as feasibility, test market, commercialization,
                            > etc. Different companies will have different steps, but in general product
                            > development funding is approved incrementally as the product concept grows
                            > and is fleshed out and proven. Products are also expected to have a long
                            > and useful life over which timeframe they are generally expected to undergo
                            > constant improvement.
                            >
                            > Projects, on the other hand, due to their contract origins, tend to be fully
                            > funded at the beginning of the project. This front-end loaded funding tends
                            > to drive the people providing the funds to ask for scope and schedule plans,
                            > which are then treated as commitments - after all - the funds are committed,
                            > so they want to know what they will get for the money. In addition,
                            > on-going change after the "end" of a project is generally regarded as bad.

                            --
                            Brad Appleton <brad {AT} bradapp.net>
                            Agile CM Environments (http://blog.bradapp.net/)
                            & Software CM Patterns (www.scmpatterns.com)
                            "And miles to go before I sleep" -- Robert Frost
                          Your message has been successfully submitted and would be delivered to recipients shortly.