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

Shocking the PMI Crowd a Bit

Expand Messages
  • Scott W. Ambler
    In the current issue of the PMI s ISSIG (Information Systems Specific Interest Group) Review at
    Message 1 of 23 , Oct 2, 2006
    • 0 Attachment
      In the current issue of the PMI's ISSIG (Information Systems Specific
      Interest Group) Review at
      http://www.pmi-issig.org/kb/ISSIG%20Review/ISSIG_Review_06_2H.pdf I have an
      article questioning the wisdom of writing requirements specifications early
      in the lifecycle of a project. An important aspect of the article is that
      it argues that if a detailed requirements spec early in the lifecycle is a
      bad idea, then any practice based on this approach is also suspect.

      If you happen to work with traditional project managers, or at least know
      some, you might want to pass that URL on to them. Hopefully it will give
      them something to think about. ;-)

      - Scott
      Scott W. Ambler
      Practice Leader Agile Development, IBM
      http://www-306.ibm.com/software/rational/bios/ambler.html

      Every organization gets the process that it deserves.
    • qcsmichael1
      The article presents the ideas in a way that most PMPs can understand (though they may not necessarily agree with the ideas). Somehow I suspect your article
      Message 2 of 23 , Oct 2, 2006
      • 0 Attachment
        The article presents the ideas in a way that most PMPs can understand
        (though they may not necessarily agree with the ideas). Somehow I
        suspect your article will not be considered useful by the people in
        other articles in the same publication who ask 1) % of business v IT
        involvement in the project by phase, 2) integration of PMBOK with IS
        development methodology, 3) 'simple' earned value on all your
        projects. I suspect (based on my assumptions regarding context) that
        the Work Packages Made Practical person will also not get it...makes
        me wonder if those who compile the publication understand the
        contradictions of the content.

        I noticed you comment that "RUP teams are a bit more sophisticated
        and will write use cases with a word processor". Is this an
        intentional slant towards 'if it's IBM, it's better'? ; )
        Personally, I prefer the note cards and will assume your use of the
        word "sophisticated" referred to the definition "to make less
        natural, simple, or ingenuous".

        Good article. Maybe this stuff will sink in eventually. Personally,
        I have difficulty getting through to many of my fellow PMI-ers.


        P.S. You might consider adding authors other than yourself to the
        suggested reading list. There's a lot of good sutff out there. : )

        - Michael Schmidt

        --- In scrumdevelopment@yahoogroups.com, "Scott W. Ambler" <swa@...>
        wrote:
        >
        > In the current issue of the PMI's ISSIG (Information Systems
        Specific
        > Interest Group) Review at
        > http://www.pmi-issig.org/kb/ISSIG%20Review/ISSIG_Review_06_2H.pdf I
        have an
        > article questioning the wisdom of writing requirements
        specifications early
        > in the lifecycle of a project. An important aspect of the article
        is that
        > it argues that if a detailed requirements spec early in the
        lifecycle is a
        > bad idea, then any practice based on this approach is also suspect.
        >
        > If you happen to work with traditional project managers, or at
        least know
        > some, you might want to pass that URL on to them. Hopefully it
        will give
        > them something to think about. ;-)
        >
        > - Scott
        > Scott W. Ambler
        > Practice Leader Agile Development, IBM
        > http://www-306.ibm.com/software/rational/bios/ambler.html
        >
        > Every organization gets the process that it deserves.
        >
      • mnbluesguy
        Scott, ... have an ... specifications early ... I think my only critique of the article are your statements about Earned Value. Earned Value can be used to
        Message 3 of 23 , Oct 2, 2006
        • 0 Attachment
          Scott,

          > Review at
          > http://www.pmi-issig.org/kb/ISSIG%20Review/ISSIG_Review_06_2H.pdf I
          have an
          > article questioning the wisdom of writing requirements
          specifications early
          > in the lifecycle of a project.

          I think my only critique of the article are your statements about
          Earned Value. Earned Value can be used to measure the 'value' of
          completed/done work. It is all a matter of how you define done. In
          Agile we define done as working software. When using Earned Value, I
          insisted we develop schedules based on working functionality rather
          than software lifecycles. Software lifecycles are only about the
          process for developing software; not measuring the "doneness" of the
          application.
        • Bud Cookson
          Scott - a good article on why software development is different than construction of a building. However, it seems like a gross exaggeration to say that the
          Message 4 of 23 , Oct 2, 2006
          • 0 Attachment
            Scott - a good article on why software development is different than construction of a building.  However, it seems like a gross exaggeration to say that the BRUF approach to software is a bad thing.  What I would say is that you can only specify the requirements to the level of detail that is available from the stakeholders including their ability to conceive what is truly "needed".  At the same time, this compromise must be traded against the cost of reorganization and trial.  As in all things, there is no absolute, right and appropriate answer.
             
            As far as estimates being inaccurate at the beginning of a project, they are only as inaccurate as the requirements.  I agree that we learn things during the course of the project which will help us do things better or differently than were conceived at the beginning of the project but this doesn't mean that the estimates are inaccurate.  In fact, with a method that I have developed, I can give you a pretty good estimate of how big the "unknowns" are in the project which you can then use as the basis for your project budgets or "ranges" as you have appropriately pointed out.  I know this system works because ~90% of my software projects have come in On-Time and On-Budget so there must be something to it.
             
            Agile software development is a great thing and has huge advantages in many cases.  However, not all cases fit the model that is supported by the agile approaches.  Again, it comes down to the compromises which are based on lots of factors.
             
            Keep up the good work and great point of discussion.  Unfortunately, not all PMPs have experience in the software world, especially those environments and projects where agile makes sense although this publication and article are directed at the IT types so they should.  Hope everyone understands what is being said.
             
            BUD


            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Scott W. Ambler
            Sent: Monday, October 02, 2006 10:48 AM
            To: agilearticles@yahoogroups.com; ambysoft@yahoogroups.com; scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Shocking the PMI Crowd a Bit

            In the current issue of the PMI's ISSIG (Information Systems Specific
            Interest Group) Review at
            http://www.pmi- issig.org/ kb/ISSIG% 20Review/ ISSIG_Review_ 06_2H.pdf I have an
            article questioning the wisdom of writing requirements specifications early
            in the lifecycle of a project. An important aspect of the article is that
            it argues that if a detailed requirements spec early in the lifecycle is a
            bad idea, then any practice based on this approach is also suspect.

            If you happen to work with traditional project managers, or at least know
            some, you might want to pass that URL on to them. Hopefully it will give
            them something to think about. ;-)

            - Scott
            Scott W. Ambler
            Practice Leader Agile Development, IBM
            http://www-306. ibm.com/software /rational/ bios/ambler. html

            Every organization gets the process that it deserves.

          • Fabian Longhitano
            Bud, Can you give more details about your method for estimate? Thanks, Fabián ... Bud, Can you give more details about your method for estimate? Thanks,
            Message 5 of 23 , Oct 2, 2006
            • 0 Attachment
              Bud,
              Can you give more details about your method for estimate?
              Thanks,
              Fabián

              On 10/2/06, Bud Cookson < Bud.Cookson@...> wrote:

              Scott - a good article on why software development is different than construction of a building.  However, it seems like a gross exaggeration to say that the BRUF approach to software is a bad thing.  What I would say is that you can only specify the requirements to the level of detail that is available from the stakeholders including their ability to conceive what is truly "needed".  At the same time, this compromise must be traded against the cost of reorganization and trial.  As in all things, there is no absolute, right and appropriate answer.
               
              As far as estimates being inaccurate at the beginning of a project, they are only as inaccurate as the requirements.  I agree that we learn things during the course of the project which will help us do things better or differently than were conceived at the beginning of the project but this doesn't mean that the estimates are inaccurate.  In fact, with a method that I have developed, I can give you a pretty good estimate of how big the "unknowns" are in the project which you can then use as the basis for your project budgets or "ranges" as you have appropriately pointed out.  I know this system works because ~90% of my software projects have come in On-Time and On-Budget so there must be something to it.
               
              Agile software development is a great thing and has huge advantages in many cases.  However, not all cases fit the model that is supported by the agile approaches.  Again, it comes down to the compromises which are based on lots of factors.
               
              Keep up the good work and great point of discussion.  Unfortunately, not all PMPs have experience in the software world, especially those environments and projects where agile makes sense although this publication and article are directed at the IT types so they should.  Hope everyone understands what is being said.
               
              BUD


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroup s.com] On Behalf Of Scott W. Ambler
              Sent: Monday, October 02, 2006 10:48 AM
              To: agilearticles@yahoogroups.com; ambysoft@yahoogroups.com; scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Shocking the PMI Crowd a Bit

              In the current issue of the PMI's ISSIG (Information Systems Specific
              Interest Group) Review at
              http://www.pmi-issig.org/kb/ISSIG%20Review/ISSIG_Review_06_2H.pdf I have an
              article questioning the wisdom of writing requirements specifications early
              in the lifecycle of a project. An important aspect of the article is that
              it argues that if a detailed requirements spec early in the lifecycle is a
              bad idea, then any practice based on this approach is also suspect.

              If you happen to work with traditional project managers, or at least know
              some, you might want to pass that URL on to them. Hopefully it will give
              them something to think about. ;-)

              - Scott
              Scott W. Ambler
              Practice Leader Agile Development, IBM
              http://www-306.ibm.com/software/rational/bios/ambler.html

              Every organization gets the process that it deserves.


            • PaulOldfield1@aol.com
              (responding to Bud) ... There will be an appropriate answer in a specific situation, but that s not what I want to talk about. There s an additional overhead
              Message 6 of 23 , Oct 3, 2006
              • 0 Attachment
                (responding to Bud)
                 
                > .. it seems like a gross exaggeration to say that the BRUF
                > approach to software is a bad thing.  What I would say is
                > that you can only specify the requirements to the level of
                > detail that is available from the stakeholders including their
                > ability to conceive what is truly "needed".  At the same time,
                > this compromise must be traded against the cost of
                > reorganization and trial.  As in all things, there is no absolute,
                > right and appropriate answer.
                 
                There will be an appropriate answer in a specific situation, but
                that's not what I want to talk about.
                 
                There's an additional overhead to doing BRUF; you would need
                either to expend more effort to record the detail up front, or to
                expend duplicated effort re-doing this work when the information
                is about to be used... normally.  There may be ways of recording
                the requirements (say as acceptance tests) that avoid this
                extra overhead, but I think this degree of formality up-front
                would not be a good thing in general.  Agreed, you need to trade
                off the benefits against the costs.
                 
                >  In fact, with a method that I have developed, I can give you a
                > pretty good estimate of how big the "unknowns" are in the
                > project which you can then use as the basis for your project
                > budgets or "ranges" as you have appropriately pointed out.
                >  I know this system works because ~90% of my software
                > projects have come in On-Time and On-Budget so there must
                > be something to it.
                 
                This capacity to estimate becomes progressively easier when
                you work: in the same domain; with the same company; with
                the same team; on the same type of applications.  In case you
                manage good (~90% OT, OB) predictions toward the left end of
                the list, I'd be interested in an outline of your approach.  (I'm
                assuming you're making these predictions c. 10-20% into
                the project; earlier would be impressive, later would not).
                 
                Paul Oldfield
                 
                 
              • Bud Cookson
                Fabian - I would be glad to give you some insights into this approach. Let me start by saying that this approach is an estimate . Is it useful? Absolutely!
                Message 7 of 23 , Oct 3, 2006
                • 0 Attachment
                  Fabian - I would be glad to give you some insights into this approach.  Let me start by saying that this approach is an "estimate".  Is it useful?  Absolutely!  Is it always precise?  No!  Is it better than nothing?  Yes.
                   
                  I also do not propose that this be used in the agile world as a regular approach.  I say this because I am sure that I will be flamed for proposing something that is not necessary in the agile development methodologies and rightly so.  When you have the ability to adjust the scope while maintaining a constant expenditure rate and timeboxing the schedule, then this methodology is not needed.  However, if your customer/sponsor/client can define the requirements and wants a solid plan, then this approach is really necessary.
                   
                  The methodology is based on four steps.  It is what I call a "Category 3 Estimate" or an "Estimate Of The Estimate Accuracy" or an "Estimate Of The Unknowns".  What we are attempting to do is to estimate how much we know about the project and translating this into an estimate of the size of the unknowns in the project.  Here are the steps.
                   
                  1.  You brainstorm the factors that could influence the accuracy of your Category 1 estimates (those things that you know you know, i.e., the requirements).  These are such things as the experience of the estimator, the newness of the technology, the maturity of the customer, etc.  This list can be as long or as short as you want.  I have a list of about 25 items that I normally use but this can be adjusted based on your experiences.
                   
                  2.  You categorize each of these factors into whether it has a low, medium or high impact on the accuracy of the estimate.  I typically only use the three categories but you can use more if you want.
                   
                  3.  The artistic portion of this method is to "guess" at what the potential impact level is for each of the categories.  Yes, this is a guess but it utilizes our best idea of what the potential impact might be.  In many cases, this might be 10/20/40%.  In other cases, it might be 10/50/400%.  The actual numbers are important as a measure of the level of potential impact and you need to be open to what the potential values might be.  They will not be 10/20/30% in every case.  Just remember the statistics that say that the average overrun on a software project is something like 100%.  Therefore, it is easy to say that it is not atypical to have values here of 200 or even 500%.  The values are left to your best judgement.
                   
                  4.  The final step is to calculate a weighted average of the percentages selected in step 3 based on the number of the factors from step 1 that are in each category.  You will come out with a percentage of inaccuracy that is due to each of the categories which are then added together to produce a single number.  This is the Category 3 estimate which is a measure of how large the unknowns are for this project.
                   
                  The results of this technique can be used in several different ways.  The first is that the final, single number can be multiplied times the Category 1 estimates to produce a final estimate.  Another approach is to apply the Low category number as a Contingency to the project and take the Medium and High numbers and apply these to the Category 1 estimates.  You can keep the entire Category 3 estimate as a contingency and dole it out as the unknowns are quantified.  The specific approach here is dependent on lots of factors.  However, without doing this, you are only estimating a part of the project and therefore setting yourself up for failure.
                   
                  Again, this is not necessary in a true agile project because the unknowns are what the methodology is all about and they are accounted for in the velocity and the use of the velocity in predicting rates of progress.  However, in those cases where it is necessary to plan the project to completion, this is a very, very important tool.
                   
                  Hope that helps.  I actually have a spreadsheet that I use for this calculation which I am more than happy to provide to anyone who would like a copy.  Just send me an email directly.
                   
                  Best regards,   BUD


                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Fabian Longhitano
                  Sent: Monday, October 02, 2006 8:16 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Shocking the PMI Crowd a Bit

                  Bud,
                  Can you give more details about your method for estimate?
                  Thanks,
                  Fabián

                  On 10/2/06, Bud Cookson < Bud.Cookson@ usa.net> wrote:

                  Scott - a good article on why software development is different than construction of a building.  However, it seems like a gross exaggeration to say that the BRUF approach to software is a bad thing.  What I would say is that you can only specify the requirements to the level of detail that is available from the stakeholders including their ability to conceive what is truly "needed".  At the same time, this compromise must be traded against the cost of reorganization and trial.  As in all things, there is no absolute, right and appropriate answer.
                   
                  As far as estimates being inaccurate at the beginning of a project, they are only as inaccurate as the requirements.  I agree that we learn things during the course of the project which will help us do things better or differently than were conceived at the beginning of the project but this doesn't mean that the estimates are inaccurate.  In fact, with a method that I have developed, I can give you a pretty good estimate of how big the "unknowns" are in the project which you can then use as the basis for your project budgets or "ranges" as you have appropriately pointed out.  I know this system works because ~90% of my software projects have come in On-Time and On-Budget so there must be something to it.
                   
                  Agile software development is a great thing and has huge advantages in many cases.  However, not all cases fit the model that is supported by the agile approaches.  Again, it comes down to the compromises which are based on lots of factors.
                   
                  Keep up the good work and great point of discussion.  Unfortunately, not all PMPs have experience in the software world, especially those environments and projects where agile makes sense although this publication and article are directed at the IT types so they should.  Hope everyone understands what is being said.
                   
                  BUD


                  From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelopment@yahoogroup s.com] On Behalf Of Scott W. Ambler
                  Sent: Monday, October 02, 2006 10:48 AM
                  To: agilearticles@ yahoogroups. com; ambysoft@yahoogroups.com; scrumdevelopment@ yahoogroups. com
                  Subject: [scrumdevelopment] Shocking the PMI Crowd a Bit

                  In the current issue of the PMI's ISSIG (Information Systems Specific
                  Interest Group) Review at
                  http://www.pmi- issig.org/ kb/ISSIG% 20Review/ ISSIG_Review_ 06_2H.pdf I have an
                  article questioning the wisdom of writing requirements specifications early
                  in the lifecycle of a project. An important aspect of the article is that
                  it argues that if a detailed requirements spec early in the lifecycle is a
                  bad idea, then any practice based on this approach is also suspect.

                  If you happen to work with traditional project managers, or at least know
                  some, you might want to pass that URL on to them. Hopefully it will give
                  them something to think about. ;-)

                  - Scott
                  Scott W. Ambler
                  Practice Leader Agile Development, IBM
                  http://www-306. ibm.com/software /rational/ bios/ambler. html

                  Every organization gets the process that it deserves.


                • Bud Cookson
                  Paul - some comments on your thoughts. Thanks. BUD PaulOldfield1@aol.com said on Tuesday, October 03, 2006 1:48 AM ... I
                  Message 8 of 23 , Oct 3, 2006
                  • 0 Attachment
                    Paul - some comments on your thoughts.  Thanks.   BUD
                     
                    PaulOldfield1@...  said on Tuesday, October 03, 2006 1:48 AM >> 

                     >> There's an additional overhead to doing BRUF; you would need
                     >> either to expend more effort to record the detail up front, or to
                     >> expend duplicated effort re-doing this work when the information
                     >> is about to be used... normally.  There may be ways of recording
                     >> the requirements (say as acceptance tests) that avoid this
                     >> extra overhead,  ...
                     
                    I agree that there is a cost involved in doing this documentation, the question becomes whether it has value.  In my experience it does.  The question becomes HOW MUCH detail to do at the front end.  It doesn't involve specifying everything.  It is a matter of defining ENOUGH that we can all agree that we are headed in the right direction.  Even though acceptance tests are a critical part of managing a project because they define the completion criteria, I find that non-technical users / customers aren't able to think in these terms at the beginning.  However, once the requirements are elicited, they can then turn them around into acceptance criteria.
                     
                     >> This capacity to estimate becomes progressively easier when
                     >> you work: in the same domain; with the same company; with
                     >> the same team; on the same type of applications.  In case you
                     >> manage good (~90% OT, OB) predictions toward the left end of
                     >> the list, I'd be interested in an outline of your approach.  (I'm
                     >> assuming you're making these predictions c. 10-20% into
                     >> the project; earlier would be impressive, later would not). 
                     
                    I wish that I was able to say that I have worked in the same domain for every project.  Unfortunately, this hasn't been the case.  I have worked in embedded systems, manufacturing control systems, financial / accounting systems, online web applications, network management systems and miscellaneous desktop applications.  As far as when these estimates are done, they are typically done at the 5 to 20% area of a project.  I don't count those situations like my first project job where we kept changing the estimates and completion date until the last day so we always completed on-time and on-budget.  The 90% figure is based on projects that were estimated in the early phases of the project and were managed to completion.  Yes, there were changes along the way but there isn't a project that doesn't.  However, with good Project Management, these changes are taken in stride and when the customer expectations are managed correctly, the results are spectacular.  it doesn't work perfectly but no project does.  This estimating technique (described in another email) just gives you a better chance of being successful because you are accounting for all of the project potentials to the best of your ability. 
                     
                    .

                  • Scott Ambler
                    Responding to several at once, sorry for any confusion. - Scott ... Yes, the references that I provide actually include a lot of other references. The article
                    Message 9 of 23 , Oct 3, 2006
                    • 0 Attachment
                      Responding to several at once, sorry for any confusion.

                      - Scott
                      --- In scrumdevelopment@yahoogroups.com, "qcsmichael1" <mschmidt@...>
                      wrote:
                      > P.S. You might consider adding authors other than yourself to the
                      > suggested reading list. There's a lot of good sutff out there. : )

                      Yes, the references that I provide actually include a lot of other
                      references. The article in the PMI article summarizes many of my
                      previous writings. Those are known quantities, so I reference those.

                      --- In scrumdevelopment@yahoogroups.com, "mnbluesguy" <tannen@...>
                      wrote:

                      > I think my only critique of the article are your statements about
                      > Earned Value. Earned Value can be used to measure the 'value' of
                      > completed/done work. It is all a matter of how you define done. In
                      > Agile we define done as working software. When using Earned Value,I
                      > insisted we develop schedules based on working functionality rather
                      > than software lifecycles. Software lifecycles are only about the
                      > process for developing software; not measuring the "doneness" of the
                      > application.
                      >

                      Yes, that's an incredibly good idea which I promote whole heartedly.
                      Unfortunately, many people based "earned value" on delivery of
                      documents, not delivery of functionality. The comments were directed
                      at them.



                      --- In scrumdevelopment@yahoogroups.com, "Bud Cookson"
                      <Bud.Cookson@...> wrote:
                      >
                      > Scott - a good article on why software development is different than
                      > construction of a building. However, it seems like a gross
                      exaggeration to
                      > say that the BRUF approach to software is a bad thing.

                      Perhaps. But, the numbers seem to show otherwise. The Chaos Report
                      shows that project teams taking a BRUF approach on average deliver
                      45% functionality that is never used by their end users, when they
                      deliver at all. That's not so good, IMHO. See
                      http://www.agilemodeling.com/essays/examiningBRUF.htm for details.

                      >What I would say is
                      > that you can only specify the requirements to the level of detail
                      that is
                      > available from the stakeholders including their ability to conceive
                      what is
                      > truly "needed".

                      Sounds pretty risky to me, and the numbers seem to show that it is.
                      Maybe you can make this approach work, but on average most
                      organizations seem to be pretty bad at it.

                      > At the same time, this compromise must be traded against
                      > the cost of reorganization and trial. As in all things, there is no
                      > absolute, right and appropriate answer.

                      Exactly, you need to choose the right approach for the situation.
                      Unfortunately, my experience is that many people have never even
                      considered the concept that the BRUF approach might not be the
                      greatest idea in the world, or that they have choices available to
                      them that seem to work better in practice. Hence the article.

                      - Scott
                    • Bud Cookson
                      ... . I would agree heartily.
                      Message 10 of 23 , Oct 3, 2006
                      • 0 Attachment
                         On Tuesday, October 03, 2006 4:10 PM , Scott Ambler said:

                         >> Exactly, you need to choose the right approach for the situation. 
                         >> Unfortunately, my experience is that many people have never even 
                         >> considered the concept that the BRUF approach might not be the 
                         >> greatest idea in the world, or that they have choices available to 
                         >> them that seem to work better in practice. Hence the article.

                        .
                          I would agree heartily.  The biggest problem that I see in the Project Management world is that there are too many people who know how to do a Gantt chart in MSProject but have no comprehension of the basic concepts of Project Management.  It is not an art that can be done by rote.  It has at very high percentage of soft skills along with the whole issue of soft requirements in the software arena.  It is my hope, as well, that your article will provide some perspective for others. 
                         
                        Keep on writing.   BUD 
                      • Timothy H. Lund
                        I think PMIers have plenty of understanding of how to run a traditional, non-software project. Believe it or not, all those Gantt charts, work breakdown
                        Message 11 of 23 , Oct 4, 2006
                        • 0 Attachment
                          I think PMIers have plenty of understanding of how to run a traditional, non-software project. Believe it or not, all those Gantt charts, work breakdown structures, and critical paths make sense when you're constructing a building or manufacturing something. It's just that when you try to apply them to software (such as we did with the waterfall method oh-so-many years ago), they break down because of the ambiguous nature of software.
                           
                          ~Tim
                           


                          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Bud Cookson
                          Sent: Tuesday, October 03, 2006 6:25 PM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: RE: [scrumdevelopment] Re: Shocking the PMI Crowd a Bit

                           On Tuesday, October 03, 2006 4:10 PM , Scott Ambler said:

                           >> Exactly, you need to choose the right approach for the situation. 
                           >> Unfortunately, my experience is that many people have never even 
                           >> considered the concept that the BRUF approach might not be the 
                           >> greatest idea in the world, or that they have choices available to 
                           >> them that seem to work better in practice. Hence the article.

                          .
                            I would agree heartily.  The biggest problem that I see in the Project Management world is that there are too many people who know how to do a Gantt chart in MSProject but have no comprehension of the basic concepts of Project Management.  It is not an art that can be done by rote.  It has at very high percentage of soft skills along with the whole issue of soft requirements in the software arena.  It is my hope, as well, that your article will provide some perspective for others. 
                           
                          Keep on writing.   BUD 

                        • Keith Sader
                          Yes, those charts, wbds, and crit paths make sense during the *construction* phase of a project. Since most(all?) of sofware development is design, these
                          Message 12 of 23 , Oct 4, 2006
                          • 0 Attachment
                            Yes, those charts, wbds, and crit paths make sense during the *construction* phase of a project.  Since most(all?) of sofware development is design, these artifacts don't fit.

                            Here's a question: how do we get PMI, and other management schools to understand that software construction is performed by the compiler/interpreter?

                            On 10/4/06, Timothy H. Lund <thl@...> wrote:

                            I think PMIers have plenty of understanding of how to run a traditional, non-software project. Believe it or not, all those Gantt charts, work breakdown structures, and critical paths make sense when you're constructing a building or manufacturing something. It's just that when you try to apply them to software (such as we did with the waterfall method oh-so-many years ago), they break down because of the ambiguous nature of software.
                             
                            ~Tim
                             




                            --
                            Keith Sader
                            ksader@...
                            http://www.sader-family.org/roller/page/ksader
                            (coming back)http://www.saderfamily.org/roller/page/ksader
                          • Timothy H. Lund
                            To me, the first step is to get them to acknowledge that software projects are different than other projects for exactly that reason. Once you can establish
                            Message 13 of 23 , Oct 4, 2006
                            • 0 Attachment
                              To me, the first step is to get them to acknowledge that software projects are different than other projects for exactly that reason. Once you can establish that, it forces them to make a distinction and study the differences (which is the kind of thing they'll probably be interested in).
                               
                              Specifically, I would think the differences you'd want to highlight are:
                              - Software requirements are vague, change quickly, and shift in priority as value is delivered.
                              -Software construction is relatively cheap.
                              -Software changes are relatively easy to make.
                               
                              These paradigm shifts from traditional project management blow the traditional project management model out of the water -- an approach which minimizes the risk of needing changes and expensive construction by increasing planning based on stable requirements and the ability to do a concrete design (no pun intended).
                               
                              I would think if you get that point across to the PMI, you'll get their attention.
                               
                              Also note that the basic project goals for a software project DO line up with other projects: the project should be done on time, within budget, and the customer should be happy; so we have something in common with PMIers (whether you like to admit it or not ;-).
                               
                              ~Tim
                               


                              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Keith Sader
                              Sent: Wednesday, October 04, 2006 9:59 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: Re: [scrumdevelopment] Re: Shocking the PMI Crowd a Bit

                              Yes, those charts, wbds, and crit paths make sense during the *construction* phase of a project.  Since most(all?) of sofware development is design, these artifacts don't fit.

                              Here's a question: how do we get PMI, and other management schools to understand that software construction is performed by the compiler/interprete r?

                              On 10/4/06, Timothy H. Lund <thl@quantumleap. us> wrote:

                              I think PMIers have plenty of understanding of how to run a traditional, non-software project. Believe it or not, all those Gantt charts, work breakdown structures, and critical paths make sense when you're constructing a building or manufacturing something. It's just that when you try to apply them to software (such as we did with the waterfall method oh-so-many years ago), they break down because of the ambiguous nature of software.
                               
                              ~Tim
                               




                              --
                              Keith Sader
                              ksader@gmail. com
                              http://www.sader- family.org/ roller/page/ ksader
                              (coming back)http:// www.saderfamily. org/roller/ page/ksader

                            • Peter Hundermark
                              ... *construction* ... Give them the article The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka (Published in Harvard Business
                              Message 14 of 23 , Oct 5, 2006
                              • 0 Attachment
                                --- In scrumdevelopment@yahoogroups.com, "Keith Sader" <ksader@...> wrote:
                                >
                                > Yes, those charts, wbds, and crit paths make sense during the
                                *construction*
                                > phase of a project. Since most(all?) of sofware development is design,
                                > these artifacts don't fit.
                                >
                                > Here's a question: how do we get PMI, and other management schools to
                                > understand that software construction is performed by the
                                > compiler/interpreter?
                                >

                                Give them the article "The New New Product Development Game" by
                                Hirotaka Takeuchi and Ikujiro Nonaka (Published in Harvard Business
                                Review, January 1986) to read?
                              • Graeme Matthew
                                Scott, I so agree with your article. Im doing a contract at the moment and there is so much documentation that it is actually useless. The functional
                                Message 15 of 23 , Oct 5, 2006
                                • 0 Attachment
                                  Scott, I so agree with your article.

                                  Im doing a contract at the moment and there is so much documentation
                                  that it is actually useless. The functional specification is 324 pages
                                  !!!!! on my first day I asked one question and guess what the func spec
                                  did not handle it and that was for one feature, oops looks like another
                                  change request !

                                  One of the strange things I have noticed is that with a massive project
                                  governance and BDUF that companies dont actually look at the cost of all
                                  involved parties to get to a point where they or a vendor can actually
                                  start coding. The company where I am at now produced a Proof of Concept
                                  in 8 weeks without any specification, simply time and materials with
                                  direct collaboration with a vendor. This POC is now in production in 50
                                  sites ! Minimal Documentation !

                                  Now they say ok we need to do it nationally so lets put it into our
                                  project management framework. Here we go, ultimate perfection of waste !
                                  I say refactor the POC and make it work! Well the functional spec was
                                  finished in February this year, we are now in October and they are doing
                                  a 2 month data model and requirements finalisation exercise. Then dev
                                  starts i.e. January 2007. Budget / On Time ? what about value !!!!!

                                  Now what really makes me go oh is that it actually is not that much of a
                                  complex application. The POC works !

                                  Then I fainted and had to go for a triple by pass when the leaders say
                                  we need strong governance and control ! well lets spend $500,000 getting
                                  to the dev phase (i.e we start delivering working software) then the
                                  vendor quotes $1.1 million to develop, so its now 1.6 why not just have
                                  time and materials could have got it for 600,000 ! And then I hear we
                                  are using FDD for the design and build ! so I have 324 pages as my
                                  features list :-) sure !

                                  Regards

                                  Graeme

                                  Scott Ambler wrote:
                                  > Responding to several at once, sorry for any confusion.
                                  >
                                  > - Scott
                                  > --- In scrumdevelopment@yahoogroups.com, "qcsmichael1" <mschmidt@...>
                                  > wrote:
                                  >
                                  >> P.S. You might consider adding authors other than yourself to the
                                  >> suggested reading list. There's a lot of good sutff out there. : )
                                  >>
                                  >
                                  > Yes, the references that I provide actually include a lot of other
                                  > references. The article in the PMI article summarizes many of my
                                  > previous writings. Those are known quantities, so I reference those.
                                  >
                                  > --- In scrumdevelopment@yahoogroups.com, "mnbluesguy" <tannen@...>
                                  > wrote:
                                  >
                                  >
                                  >> I think my only critique of the article are your statements about
                                  >> Earned Value. Earned Value can be used to measure the 'value' of
                                  >> completed/done work. It is all a matter of how you define done. In
                                  >> Agile we define done as working software. When using Earned Value,I
                                  >> insisted we develop schedules based on working functionality rather
                                  >> than software lifecycles. Software lifecycles are only about the
                                  >> process for developing software; not measuring the "doneness" of the
                                  >> application.
                                  >>
                                  >>
                                  >
                                  > Yes, that's an incredibly good idea which I promote whole heartedly.
                                  > Unfortunately, many people based "earned value" on delivery of
                                  > documents, not delivery of functionality. The comments were directed
                                  > at them.
                                  >
                                  >
                                  >
                                  > --- In scrumdevelopment@yahoogroups.com, "Bud Cookson"
                                  > <Bud.Cookson@...> wrote:
                                  >
                                  >> Scott - a good article on why software development is different than
                                  >> construction of a building. However, it seems like a gross
                                  >>
                                  > exaggeration to
                                  >
                                  >> say that the BRUF approach to software is a bad thing.
                                  >>
                                  >
                                  > Perhaps. But, the numbers seem to show otherwise. The Chaos Report
                                  > shows that project teams taking a BRUF approach on average deliver
                                  > 45% functionality that is never used by their end users, when they
                                  > deliver at all. That's not so good, IMHO. See
                                  > http://www.agilemodeling.com/essays/examiningBRUF.htm for details.
                                  >
                                  >
                                  >> What I would say is
                                  >> that you can only specify the requirements to the level of detail
                                  >>
                                  > that is
                                  >
                                  >> available from the stakeholders including their ability to conceive
                                  >>
                                  > what is
                                  >
                                  >> truly "needed".
                                  >>
                                  >
                                  > Sounds pretty risky to me, and the numbers seem to show that it is.
                                  > Maybe you can make this approach work, but on average most
                                  > organizations seem to be pretty bad at it.
                                  >
                                  >
                                  >> At the same time, this compromise must be traded against
                                  >> the cost of reorganization and trial. As in all things, there is no
                                  >> absolute, right and appropriate answer.
                                  >>
                                  >
                                  > Exactly, you need to choose the right approach for the situation.
                                  > Unfortunately, my experience is that many people have never even
                                  > considered the concept that the BRUF approach might not be the
                                  > greatest idea in the world, or that they have choices available to
                                  > them that seem to work better in practice. Hence the article.
                                  >
                                  > - Scott
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  > To Post a message, send it to: scrumdevelopment@...
                                  > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                • Scott Ambler
                                  I think that we need to keep a few things in mind: 1. We should be uncomfortable about the software development is just like construction analogy. I suspect
                                  Message 16 of 23 , Oct 5, 2006
                                  • 0 Attachment
                                    I think that we need to keep a few things in mind:
                                    1. We should be uncomfortable about the software development is just
                                    like construction analogy. I suspect that most people involved in the
                                    discussion, either for it or against it, may know a lot about one side
                                    of the equation but not much about the other. I've been exploring
                                    this issue a bit, and I've found that the construction folks aren't
                                    that good at planning, estimating, and even architecting buildings.
                                    2. There are many people out there with their PMP who in fact are very
                                    good project managers. Would they have been good PMs without a PMP?
                                    Most likely.
                                    3. The PMI is trying to improve. Yes, they're moving slowly. Yes,
                                    they may never be as agile as we'd like. But they are trying and we
                                    should do what we can to help.

                                    - Scott
                                  • Scott Ambler
                                    ... wrote: ... say ... getting ... the ... have ... we ... That doesn t sound like FDD to me. Anyway, my heart goes out to you. - Scott
                                    Message 17 of 23 , Oct 5, 2006
                                    • 0 Attachment
                                      --- In scrumdevelopment@yahoogroups.com, Graeme Matthew <scrum@...>
                                      wrote:

                                      <snip>
                                      >
                                      > Then I fainted and had to go for a triple by pass when the leaders
                                      say
                                      > we need strong governance and control ! well lets spend $500,000
                                      getting
                                      > to the dev phase (i.e we start delivering working software) then
                                      the
                                      > vendor quotes $1.1 million to develop, so its now 1.6 why not just
                                      have
                                      > time and materials could have got it for 600,000 ! And then I hear
                                      we
                                      > are using FDD for the design and build ! so I have 324 pages as my
                                      > features list :-) sure !

                                      That doesn't sound like FDD to me. Anyway, my heart goes out to you.

                                      - Scott
                                    • mike.dwyer1@comcast.net
                                      Before discounting construction analogies, you may want to look into Hal McComber s http://www.reformingprojectmanagement.com/ site and sign up for his info.
                                      Message 18 of 23 , Oct 5, 2006
                                      • 0 Attachment
                                        Before discounting construction analogies, you may want to look into Hal McComber's http://www.reformingprojectmanagement.com/ site and sign up for his info.
                                         
                                        There is every possibility that the construction industry is ahead of us in defining, implementing and improving Agile.
                                         
                                        --
                                        Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


                                        The greatest oak was once a little nut who held its ground. ~Author Unknown
                                         
                                        -------------- Original message --------------
                                        From: "Scott Ambler" <swa@...>

                                        I think that we need to keep a few things in mind:
                                        1. We should be uncomfortable about the software development is just
                                        like construction analogy. I suspect that most people involved in the
                                        discussion, either for it or against it, may know a lot about one side
                                        of the equation but not much about the other. I've been exploring
                                        this issue a bit, and I've found that the construction folks aren't
                                        that good at planning, estimating, and even architecting buildings.
                                        2. There are many people out there with their PMP who in fact are very
                                        good project managers. Would they have been good PMs without a PMP?
                                        Most likely.
                                        3. The PMI is trying to improve. Yes, they're moving slowly. Yes,
                                        they may never be as agile as we'd like. But they are trying and we
                                        should do what we can to help.

                                        - Scott

                                      • Graeme Matthew
                                        Well looking at the whole FDD handles the design and build , and actually I think the practice is very good especially for large corporates. What I am trying
                                        Message 19 of 23 , Oct 6, 2006
                                        • 0 Attachment
                                          Well looking at the whole FDD handles the design and build , and
                                          actually I think the practice is very good especially for large
                                          corporates. What I am trying to do is to incorporate the Scrum
                                          principles prior to design and build. My eliminate waste is focusing on
                                          the requirements so what im leading to is:

                                          User Stories ----> Product Backlog ------> Estimation -----> Design An
                                          Overall Model ----> Build a Features List( Incorp Backlog) ---> Plan By
                                          Feature ---> Design by Feature ---> Build by Feature

                                          Their model is, spend 12 months writing bus and func spec then use FDD

                                          Its a slog !!!!

                                          Oh and by the way I got told today they chose FDD over agile :-)))))))
                                          makes you worry !
                                          Regards


                                          Graeme
                                          > That doesn't sound like FDD to me. Anyway, my heart goes out to you.
                                          >
                                          > - Scott
                                          >
                                          >
                                          >
                                          >
                                          >
                                          > To Post a message, send it to: scrumdevelopment@...
                                          > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                          > Yahoo! Groups Links
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                        • Scott Ambler
                                          ... Exactly. That s definitely not FDD in the sense of http://www.featuredrivendevelopment.com/ I suspect that FDD is being used to describe the sloggish
                                          Message 20 of 23 , Oct 6, 2006
                                          • 0 Attachment
                                            --- In scrumdevelopment@yahoogroups.com, Graeme Matthew <scrum@...>
                                            wrote:
                                            >
                                            > Their model is, spend 12 months writing bus and func spec then use FDD

                                            >
                                            > Its a slog !!!!

                                            Exactly. That's definitely not FDD in the sense of
                                            http://www.featuredrivendevelopment.com/

                                            I suspect that FDD is being used to describe the "sloggish" sort of
                                            approach that you're being forced to suffer through rather than the
                                            Agile FDD described at the site above. I suspect this terminology
                                            problem may have skewed some of the results that I got in my agile
                                            survey last spring (see www.ambysoft.com/surveys/ ). Sigh.

                                            - Scott
                                          • Scott Ambler
                                            ... into Hal McComber s http://www.reformingprojectmanagement.com/ site and sign up for his info. ... It s always a good idea to read outside of IT. I ll have
                                            Message 21 of 23 , Oct 6, 2006
                                            • 0 Attachment
                                              --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
                                              >
                                              > Before discounting construction analogies, you may want to look
                                              into Hal McComber's http://www.reformingprojectmanagement.com/ site
                                              and sign up for his info.
                                              >

                                              It's always a good idea to read outside of IT. I'll have to check
                                              this out.

                                              > There is every possibility that the construction industry is ahead
                                              of us in defining, implementing and improving Agile.

                                              Perhaps, but it doesn't appear to be getting out to the construction
                                              folks. I went for lunch a couple of days ago with someone who is in
                                              the process of building a new house. He had a few choice words
                                              about the contractors, and he's dealing with a range of them, to
                                              plan and estimate their work.

                                              My former brother-in-law is a master carpenter and he's relatively
                                              agile. He considers blue prints to be interesting suggestions but is
                                              experienced enough to know when to ignore them.

                                              - Scott
                                            • Mike Dwyer
                                              Let me know what you think Scott. What areas do you read outside the sandbox we call IT? Michael F. Dwyer Planning constantly peers into the future for
                                              Message 22 of 23 , Oct 6, 2006
                                              • 0 Attachment

                                                Let me know what you think Scott.

                                                 

                                                What areas do you read outside the sandbox we call IT?

                                                 

                                                Michael F. Dwyer

                                                 

                                                "Planning constantly peers into the future for indications as to where a solution may emerge."

                                                "A Plan is a complex situation, adapting to an emerging solution." 

                                                -----Original Message-----
                                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Scott Ambler
                                                Sent: Friday, October 06, 2006 3:49 PM
                                                To: scrumdevelopment@yahoogroups.com
                                                Subject: [scrumdevelopment] Re: Shocking the PMI Crowd a Bit

                                                 

                                                --- In scrumdevelopment@ yahoogroups. com, mike.dwyer1@ ... wrote:

                                                >
                                                > Before discounting construction analogies, you may want to look
                                                into Hal McComber's http://www.reformin gprojectmanageme nt.com/ site
                                                and sign up for his info.
                                                >

                                                It's always a good idea to read outside of IT. I'll have to check
                                                this out.

                                                > There is every possibility that the construction industry is ahead
                                                of us in defining, implementing and improving Agile.

                                                Perhaps, but it doesn't appear to be getting out to the construction
                                                folks. I went for lunch a couple of days ago with someone who is in
                                                the process of building a new house. He had a few choice words
                                                about the contractors, and he's dealing with a range of them, to
                                                plan and estimate their work.

                                                My former brother-in-law is a master carpenter and he's relatively
                                                agile. He considers blue prints to be interesting suggestions but is
                                                experienced enough to know when to ignore them.

                                                - Scott

                                              • Scott Ambler
                                                ... Will do. ... I commonly read Fortune and Economist, typically for news. I also read Harvard Business Review for general business-related ideas. My wife
                                                Message 23 of 23 , Oct 6, 2006
                                                • 0 Attachment
                                                  --- In scrumdevelopment@yahoogroups.com, "Mike Dwyer"
                                                  <mike.dwyer1@...> wrote:
                                                  >
                                                  > Let me know what you think Scott.

                                                  Will do.

                                                  >
                                                  >
                                                  >
                                                  > What areas do you read outside the sandbox we call IT?

                                                  I commonly read Fortune and Economist, typically for news. I also
                                                  read Harvard Business Review for general business-related ideas. My
                                                  wife is currently back in school working on her Master of Landscape
                                                  Architecture so I'm starting to read both building and landscape
                                                  architecture magazines.

                                                  Book wise I typically pick up things recommended to me by others,
                                                  although every so often I go to the local Chapters (our version of
                                                  Barnes & Noble) and browse.

                                                  - Scott
                                                Your message has been successfully submitted and would be delivered to recipients shortly.