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

Commitment in projects

Expand Messages
  • strazhce
    Hi, Ron, recently in this group you ve stated, that you and Chen don t propagate story points anymore. So I ve googled and found this:
    Message 1 of 19 , May 14, 2011
    • 0 Attachment
      Hi, Ron,

      recently in this group you've stated, that you and Chen don't propagate story points anymore. So I've googled and found this:
      http://www.infoq.com/news/2011/01/scrum-project-estimation.

      From the citation I understand, that you suggest:
      1. On sprint level - do not estimate user stories at all, but break the required functionality into stories about the same this big.
      I think, this is clever, because:
      - you actually DO estimate things
      - but you force people do compare stories, so they come up with comparison-based estimate, not gut feeling guess
      2. For big stories you suggest estimating in [ideal] weeks, so if some asks to estimate e.g. a fairly big change request to the system, you do this.
      These are probably hard to compare (a lot of variables?), so qualified guess is ok.

      Did I get it right? Did I get your motivation right?

      If this was live conversation, I would wait for your confirmation. This way I'm impatient, so... I wonder, what do you suggest doing in further cases:
      2.1 Someone asks for the estimate, but he needs a promise = commitment (e.g. for fix-price proposal). Maybe it would be better to say, he needs an estimate with the certain degree of confidence :-)
      2.2 Someone asks for the estimate of the big project (and again fix-price and probably fix-time, but due dates are easier to negotiate or change). Big = hundreds of man-days.

      I think the right thing to do is to compare on big scale (e.g. vs other systems with the same number of screens/tables/etc.).

      I know, that FTFP is not the most popular thing around there, but this is actual reality around me.

      Thanks.
      Oleg
    • Steve
      Hi Oleg ... Sorry to interrupt your discusiion with Ron but I m curious to know why you think that FTFP is not the most popular thing around there (here?). The
      Message 2 of 19 , May 14, 2011
      • 0 Attachment
        Hi Oleg

        --- In scrumdevelopment@yahoogroups.com, "strazhce" <infobox.oleg@...> wrote:
        >
        > I know, that FTFP is not the most popular thing around there, but this is actual reality around me.

        Sorry to interrupt your discusiion with Ron but I'm curious to know why you think that FTFP is not the most popular thing around there (here?).

        The whole basis of Agile (well in my mind) is fixed time and fixed resource (the two equals fixed price) but we vary what is delivered and negotiate at the end of the project about what to do with what wasn't done.

        Of course there are negotiations up-front about the minimum that will be delivered and of course this does need some sort of estimating exercise.

        Are you saying that you work in fixed price, fixed time AND fixed requirements? If so, YUCK!!
      • Michael James
        ... I m thinking FPFTFR might be fine too. But the requirements would have to be so well fixed that the product was already done. --mj
        Message 3 of 19 , May 17, 2011
        • 0 Attachment
          On May 14, 2011, at 12:30 PM, Steve wrote:

          Are you saying that you work in fixed price, fixed time AND fixed requirements? If so, YUCK!!

          I'm thinking FPFTFR might be fine too.  But the requirements would have to be so well fixed that the product was already done.

          --mj

        • strazhce
          Hi, Steve ... Yes, we work mostly by Fixed Price + Fixed Requriements. Resource is variable (a bit - there is a delay between requesting some more people and
          Message 4 of 19 , May 18, 2011
          • 0 Attachment
            Hi, Steve
            --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
            >
            > Hi Oleg
            >
            > --- In scrumdevelopment@yahoogroups.com, "strazhce" <infobox.oleg@> wrote:
            > >
            > > I know, that FTFP is not the most popular thing around there, but this is actual reality around me.
            >
            > Sorry to interrupt your discusiion with Ron but I'm curious to know why you think that FTFP is not the most popular thing around there (here?).
            >
            > Are you saying that you work in fixed price, fixed time AND fixed requirements? If so, YUCK!!
            >
            Yes, we work mostly by Fixed Price + Fixed Requriements.
            Resource is variable (a bit - there is a delay between requesting some more people and getting those people from the company).
            Time is relatively fixed, but it can be renegotiated - based on the customer's true needs and deadlines.
            And FPFR gets us all negatives - big upfront specifications delimiting scope as much as we can, scope creep, customer trying to get more without offering to pay more etc.

            This is my understanding of FTFP. I see it as playing a lottery which is not totally random but has some rules. But still a lottery.

            We make a guess, that we will be able to do FR for FP. Then we find out we missed that guess - either by underestimating and customer is very happy he gets big bang for low bucks. Until he comes up with some slight change, which he is not willing to pay for and we are not willing to do at our expense.
            Or we overestimated and have contracted more money than work. And then we are kind to the customer until we run out of those extra money. When he comes up with change requests, he is super happy, because he can make changes and doesn't have to ask for more money inside his organization.

            Guess what, we underestimate more frequently than overestimate. But mostly not too much. And thanks to hard working, bright, effective people and strict scope control we don't lose money.

            Unfortunately this is very common way of doing IT business around me. So I have to accommodate and play the game the best I can. I don't have power to change the game.

            Oleg
          • Steve
            ONE reason that companies outsource development is to offload risk. If you can get someone to do something agreed fixed time and cost, then the risk of that
            Message 5 of 19 , May 18, 2011
            • 0 Attachment
              ONE reason that companies outsource development is to 'offload' risk. If you can get someone to do something agreed fixed time and cost, then the risk of that time and cost being wrong falls on the outsource company.

              As you say, people mostly underestimate even when adding a fair chuck to the estimates for 'unforseens' and 'margin' (and you have to keep that as low as you dare in competitive market) and so the FTFPFR model does not often (if at all) work to the satisfaction of both sides of the 'contract'.

              Of course, another reason for outsourcing is to take advantage of specialist skills. These are usually taken to mean architecture, design and development languages but there is no reason why superior project management skills cannot be a good reason to outsource.

              Those superior skills are the 'Agile' way of working with FTFP but prioritised requirements that may not all get done; we can discuss what to do with the ones that don't get done at the end of the project.

              'Change control' and 'scope creep' are catered for perfectly in a non-ceremonial way, the customer gets early benefit and gets what they need (rather some possibly vague idea of what they want).

              When you put these 'facts' (in more detail obviously) to clients, they will generally agree or even if sceptical, are willing to give it a go for a trial period.

              Is it your clients that are intractable or your senior management?

              There is as saying that 'if you continue to do things the way you have always done them, then you will always get the same results'!

              --- In scrumdevelopment@yahoogroups.com, "strazhce" <infobox.oleg@...> wrote:
              >
              > > --- In scrumdevelopment@yahoogroups.com, "strazhce" <infobox.oleg@> wrote:
              > > >
              > > > I know, that FTFP is not the most popular thing around there, but this is actual reality around me.
              > >
              > > Are you saying that you work in fixed price, fixed time AND fixed requirements? If so, YUCK!!
              > >
              > Yes, we work mostly by Fixed Price + Fixed Requriements.
              > Resource is variable (a bit - there is a delay between requesting some more people and getting those people from the company).
              > Time is relatively fixed, but it can be renegotiated - based on the customer's true needs and deadlines.
              > And FPFR gets us all negatives - big upfront specifications delimiting scope as much as we can, scope creep, customer trying to get more without offering to pay more etc.
              >
              > This is my understanding of FTFP. I see it as playing a lottery which is not totally random but has some rules. But still a lottery.
              >
              > We make a guess, that we will be able to do FR for FP. Then we find out we missed that guess - either by underestimating and customer is very happy he gets big bang for low bucks. Until he comes up with some slight change, which he is not willing to pay for and we are not willing to do at our expense.
              > Or we overestimated and have contracted more money than work. And then we are kind to the customer until we run out of those extra money. When he comes up with change requests, he is super happy, because he can make changes and doesn't have to ask for more money inside his organization.
              >
              > Guess what, we underestimate more frequently than overestimate. But mostly not too much. And thanks to hard working, bright, effective people and strict scope control we don't lose money.
              >
              > Unfortunately this is very common way of doing IT business around me. So I have to accommodate and play the game the best I can. I don't have power to change the game.
              >
              > Oleg
              >
            • Pascal Roy Live Hotmail
              Really, are you really offloading the risk? As far as the project is concerned, you really just moved the risk around but it is still fully there. You maybe
              Message 6 of 19 , May 18, 2011
              • 0 Attachment
                Really, are you really offloading the risk?

                As far as the project is concerned, you really just moved the risk around but it is still fully there. You maybe offloaded part of the financial risk (not even all since even if you outsource, you still put money in it).  I would think that If you really cared about your project, you'd want to know how the outsourcer is addressing this risk anyway...

                Another thing. By outsourcing, you probably even increased the risk since you are now dealing with another entity over which you have even less control. That's not to mention the increased complexity in communication.

                It seems, we are more concerned in our field about saving our bacon when things go wrong rather than working together to make things work from the get go and making hard decisions together when necessary.

                IMHO, offloading risk to outsourcers offers a false sense of security. Even if you sue, how long will that take? How much of the money will go to the lawyers? You might not even get anything if the outsourcer goes into bankruptcy. And what about the project, is it any better for it? Isn't that the primary goal of any software development project, producing working software???

                Le 2011-05-18 à 09:11, Steve a écrit :

                 

                ONE reason that companies outsource development is to 'offload' risk. If you can get someone to do something agreed fixed time and cost, then the risk of that time and cost being wrong falls on the outsource company.


              • George Dinwiddie
                ... Are you really? Or are you working by Price Not To Exceed + Requirements Not Less Than? If you are truly working with fixed requirements, how do you fix
                Message 7 of 19 , May 18, 2011
                • 0 Attachment
                  On 5/18/11 4:32 AM, strazhce wrote:
                  > Yes, we work mostly by Fixed Price + Fixed Requriements.

                  Are you really? Or are you working by Price Not To Exceed +
                  Requirements Not Less Than?

                  If you are truly working with fixed requirements, how do you fix them?
                  How do you prevent undiscussed requirements from showing up later as
                  assumed and essential?

                  - George

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • Steve
                  Hello Pascal? Roy? Should have been more explicit - the client is trying to offload time and cost risk. But you are entirely correct, it is a misconceived and
                  Message 8 of 19 , May 18, 2011
                  • 0 Attachment
                    Hello Pascal? Roy?

                    Should have been more explicit - the client is trying to offload time and cost risk.

                    But you are entirely correct, it is a misconceived and simplistic notion and that is the fundemental reason that FTFPFR contracts seldom if ever really work to the satisfaction of both parties.

                    Totally agree that we should all spend more time working together rather than covering our backs but in Oleg's case, I am assuming, it is not the client necessarily being awkward but his senior management who sound like typical 'command and control' freaks rather than collaborative and cooperative types.

                    I also agree that IF the client cared about their project, they would do as you say, but again that is an interesting point because some clients act as if they do not really care.

                    --- In scrumdevelopment@yahoogroups.com, Pascal Roy Live Hotmail <pascal_roy_1967@...> wrote:
                    >
                    > Really, are you really offloading the risk?
                    >
                    > As far as the project is concerned, you really just moved the risk around but it is still fully there. You maybe offloaded part of the financial risk (not even all since even if you outsource, you still put money in it). I would think that If you really cared about your project, you'd want to know how the outsourcer is addressing this risk anyway...
                    >
                    > Another thing. By outsourcing, you probably even increased the risk since you are now dealing with another entity over which you have even less control. That's not to mention the increased complexity in communication.
                    >
                    > It seems, we are more concerned in our field about saving our bacon when things go wrong rather than working together to make things work from the get go and making hard decisions together when necessary.
                    >
                    > IMHO, offloading risk to outsourcers offers a false sense of security. Even if you sue, how long will that take? How much of the money will go to the lawyers? You might not even get anything if the outsourcer goes into bankruptcy. And what about the project, is it any better for it? Isn't that the primary goal of any software development project, producing working software???
                    >
                    > Le 2011-05-18 à 09:11, Steve a écrit :
                    >
                    > > ONE reason that companies outsource development is to 'offload' risk. If you can get someone to do something agreed fixed time and cost, then the risk of that time and cost being wrong falls on the outsource company.
                    > >
                    > >
                    >
                  • Daniël W. Crompton
                    On 18 May 2011 16:20, Pascal Roy Live Hotmail ... Hi Pascal, Really, are you really offloading the risk? ... I don t think Steve actually means offloading the
                    Message 9 of 19 , May 18, 2011
                    • 0 Attachment
                      On 18 May 2011 16:20, Pascal Roy Live Hotmail <pascal_roy_1967@...> wrote: 

                       
                      Hi Pascal,

                      Really, are you really offloading the risk?

                      I don't think Steve actually means offloading the risk, I can reduce the risk by allowing a company whose core business is development to complete that portion of the project. And part of this risk can also be transfered or shared, just like with insurance. This means part of the consequences of failing to complete the outsourced project falls on the entity that accepted the project.


                      As far as the project is concerned, you really just moved the risk around but it is still fully there. You maybe offloaded part of the financial risk (not even all since even if you outsource, you still put money in it).  

                      I assume you don't work using this model or you might have known that failure to deliver may have additional financial consequences for the party that is completing the project, this can be in the from of late fees or fines. This offsets a portion of risks of late delivery. 

                       
                      I would think that If you really cared about your project, you'd want to know how the outsourcer is addressing this risk anyway...

                      You shouldn't really get into bed with a company without due diligence, this goes for both parties. This may make it difficult in the case of risks that can't be identified or assessed.

                       
                      Another thing. By outsourcing, you probably even increased the risk since you are now dealing with another entity over which you have even less control. That's not to mention the increased complexity in communication.

                      It seems, we are more concerned in our field about saving our bacon when things go wrong rather than working together to make things work from the get go and making hard decisions together when necessary.

                      IMHO, offloading risk to outsourcers offers a false sense of security. Even if you sue, how long will that take? How much of the money will go to the lawyers? You might not even get anything if the outsourcer goes into bankruptcy. And what about the project, is it any better for it? Isn't that the primary goal of any software development project, producing working software???

                      Due diligence should ensure that these risks have been identified or accessed.

                       
                      Le 2011-05-18 à 09:11, Steve a écrit :

                       

                      ONE reason that companies outsource development is to 'offload' risk. If you can get someone to do something agreed fixed time and cost, then the risk of that time and cost being wrong falls on the outsource company.


                      D.

                    • woynam
                      Correct me if you have a good example, but I imagine it is rare for a company to recoup the true cost of a failed project from an outside vendor. When you
                      Message 10 of 19 , May 18, 2011
                      • 0 Attachment
                        Correct me if you have a good example, but I imagine it is rare for a company to recoup the true cost of a failed project from an outside vendor.

                        When you factor in the cost of litigation, loss of revenue from the "missing" system, loss of goodwill with your customer base (who really don't give a rat's ass why you didn't deliver the system you promised), I just can't see how the risk is reduced by outsourcing.

                        Recently, many of the automobile manufactures had to step in and prop up their suppliers. If the suppliers go belly up, it can have a devastating impact on your business.

                        So, you've just successfully sued your outsourcing company into oblivion. Chances are, your company was at least partly at fault. How likely is it for another company to want to step up to the plate? My guess is that if one is willing to take their place, they'll increase their costs to cover the potential loss.

                        Mark


                        --- In scrumdevelopment@yahoogroups.com, Daniël W. Crompton <webhat@...> wrote:
                        >
                        > On 18 May 2011 16:20, Pascal Roy Live Hotmail
                        > <pascal_roy_1967@...>wrote:
                        > >
                        > >
                        > Hi Pascal,
                        >
                        > Really, are you really offloading the risk?
                        > >
                        >
                        > I don't think Steve actually means offloading the risk, I can reduce the
                        > risk by allowing a company whose core business is development to complete
                        > that portion of the project. And part of this risk can also be transfered or
                        > shared, just like with insurance. This means part of the consequences of
                        > failing to complete the outsourced project falls on the entity that accepted
                        > the project.
                        >
                        >
                        > As far as the project is concerned, you really just moved the risk around
                        > > but it is still fully there. You maybe offloaded part of the financial risk
                        > > (not even all since even if you outsource, you still put money in it).
                        > >
                        >
                        > I assume you don't work using this model or you might have known that
                        > failure to deliver may have additional financial consequences for the party
                        > that is completing the project, this can be in the from of late fees or
                        > fines. This offsets a portion of risks of late delivery.
                        >
                        >
                        >
                        > > I would think that If you really cared about your project, you'd want to
                        > > know how the outsourcer is addressing this risk anyway...
                        > >
                        >
                        > You shouldn't really get into bed with a company without due diligence, this
                        > goes for both parties. This may make it difficult in the case of risks that
                        > can't be identified or assessed.
                        >
                        >
                        >
                        > > Another thing. By outsourcing, you probably even increased the risk since
                        > > you are now dealing with another entity over which you have even less
                        > > control. That's not to mention the increased complexity in communication.
                        > >
                        > > It seems, we are more concerned in our field about saving our bacon when
                        > > things go wrong rather than working together to make things work from the
                        > > get go and making hard decisions together when necessary.
                        > >
                        > > IMHO, offloading risk to outsourcers offers a false sense of security. Even
                        > > if you sue, how long will that take? How much of the money will go to the
                        > > lawyers? You might not even get anything if the outsourcer goes into
                        > > bankruptcy. And what about the project, is it any better for it? Isn't that
                        > > the primary goal of any software development project, producing working
                        > > software???
                        > >
                        >
                        > Due diligence should ensure that these risks have been identified or
                        > accessed.
                        >
                        >
                        >
                        > > Le 2011-05-18 à 09:11, Steve a écrit :
                        > >
                        > >
                        > >
                        > > ONE reason that companies outsource development is to 'offload' risk. If
                        > > you can get someone to do something agreed fixed time and cost, then the
                        > > risk of that time and cost being wrong falls on the outsource company.
                        > >
                        > >
                        > D.
                        >
                      • Paul Hudson
                        ... Maybe you don t have a software development capability, or an immature one or one that isn t familiar with the technologies. Or the outsourcer is the
                        Message 11 of 19 , May 18, 2011
                        • 0 Attachment
                          On 18 May 2011 17:38, woynam <woyna@...> wrote:
                          I just can't see how the risk is reduced by outsourcing.

                          Maybe you don't have a software development capability, or an immature one or one that isn't familiar with the technologies.

                          Or the outsourcer is the supplier of other products (packaged software, or hardware or something) and has the expertise in their products to do the required customisations and extensions you need (this is pretty much how my employer works).

                          "Outsourcing" seems to have become a negative term for getting other companies to do the bits they're better at and your company is less so. But that's been done for centuries. Do you do your own payroll? (Companies used to - outsourcing that was Andersen's initial business). Generate your own electricity? Make th cardboard for the boxes you package your products in? Ford did make their own steel once, but it would be very odd for a car company to do that today,

                          Software is a bit different, but not completely different from other kinds of "outsourcing". Now the benefits from having a close relationship (physically and in day to day interaction) between the people who want the software developed and hte developers of the software are considerable, but that doesn't *require* that people are in the same organisation.

                          Comparative advantage and all that...

                          Paul


                        • strazhce
                          George, ... you are of course absolutely right, price is at most , but requirements are at least . This invites trouble. We just can t prevent customer from
                          Message 12 of 19 , May 19, 2011
                          • 0 Attachment
                            George,

                            --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                            >
                            > On 5/18/11 4:32 AM, strazhce wrote:
                            > > Yes, we work mostly by Fixed Price + Fixed Requriements.
                            >
                            > Are you really? Or are you working by Price Not To Exceed +
                            > Requirements Not Less Than?
                            >
                            > If you are truly working with fixed requirements, how do you fix them?
                            > How do you prevent undiscussed requirements from showing up later as
                            > assumed and essential?

                            you are of course absolutely right, price is "at most", but requirements are "at least". This invites trouble.
                            We just can't prevent customer from brining new requirements and claiming this is of course in scope of original request and "this is absolutely clear" from some tiny sentence in request for proposal. That happened to us many times.

                            Oleg
                          • Daniël W. Crompton
                            On 18 May 2011 18:38, woynam wrote: Hi Mark, Correct me if you have a good example, but I imagine it is rare for a ... This is where due
                            Message 13 of 19 , May 19, 2011
                            • 0 Attachment
                              On 18 May 2011 18:38, woynam <woyna@...> wrote:

                              Hi Mark,

                              Correct me if you have a good example, but I imagine it is rare for a company to recoup the true cost of a failed project from an outside vendor.

                              This is where due diligence comes in, discovering whether a company is able to finish the project on time or at all. Due diligence is the foundation of the project, and this should happen before the project is outsourced and a vendor is chosen, discovering that the project has failed means that there was something wrong with the foundation.

                              A large international bank, they decided that they wanted an ISP in 1998. They are a financial organisation and as such had little or no experience with building an ISP. Their business case is that when they increase the number of internet connections in the long term banking can take place, so giving all their customers, and the rest of the country while they're at it, an internet connection will reduce the number of brick and mortar, and more importantly personel costs. How did they get this ISP running in 3 months without in house knowledge?

                              A medium size retail company has a business case that a webshop will increase their revenue and give them a marketing platform for exploiting their current CRM, their specialization is brick and mortar stores. How did they get their webshop?

                              When you factor in the cost of litigation, loss of revenue from the "missing" system, loss of goodwill with your customer base (who really don't give a rat's ass why you didn't deliver the system you promised), I just can't see how the risk is reduced by outsourcing.

                              You are focussed on one risk: the project failing. The companies described above didn't create expectation in their customers before delivering and thus didn't create the risk that customer goodwill could be lost. They identified and assessed ALL the risks, up to the point of not allowing key developers and members of the management team travel in the same aircraft.

                              Recently, many of the automobile manufactures had to step in and prop up their suppliers. If the suppliers go belly up, it can have a devastating impact on your business.

                              This is a situation of their own making: They wanted to make their suppliers solely reliant on them to give them power over their suppliers, when the automobile manufactures started to fail this had a trickle down effect on their customers who had become overspecialized. Just look at the Panda, over specialization leads to extinction.

                               D.

                            • Steve
                              Hi Mark Another amendment to my original post! I should have said that one of the original reasons for outsourcing was to off load some of the financial
                              Message 14 of 19 , May 19, 2011
                              • 0 Attachment
                                Hi Mark

                                Another amendment to my original post!

                                I should have said that one of the "original" reasons for outsourcing was to off load some of the "financial" risk.

                                As you point out, that reason was then and is now, simplistic and naive.

                                As the other replys to this post have pointed out, the real reasons should be to take advantage of specialist skills not available or not practical/cost-effective to have in-house.

                                One of those skills looked for should be how to agree contracts and run projects in order to maximise value to both organisations.

                                My view to acheive this is to run Fixed Time, Fixed Cost and Variable Requirements delivery projects as long as both sides understand that what is agreed as a minimum delivery at the start of the project may change as well during the project.

                                'Traditional' outsourcing risks are reduced on all sides but new risks are introduced. Probably the main one being that the required commitment from the client does not happen.

                                Thoughts?

                                --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                                >
                                >
                                > Correct me if you have a good example, but I imagine it is rare for a company to recoup the true cost of a failed project from an outside vendor.
                                >
                                > When you factor in the cost of litigation, loss of revenue from the "missing" system, loss of goodwill with your customer base (who really don't give a rat's ass why you didn't deliver the system you promised), I just can't see how the risk is reduced by outsourcing.
                                >
                                > Recently, many of the automobile manufactures had to step in and prop up their suppliers. If the suppliers go belly up, it can have a devastating impact on your business.
                                >
                                > So, you've just successfully sued your outsourcing company into oblivion. Chances are, your company was at least partly at fault. How likely is it for another company to want to step up to the plate? My guess is that if one is willing to take their place, they'll increase their costs to cover the potential loss.
                                >
                                > Mark
                                >
                                >
                                > --- In scrumdevelopment@yahoogroups.com, Daniël W. Crompton <webhat@> wrote:
                                > >
                                > > On 18 May 2011 16:20, Pascal Roy Live Hotmail
                                > > <pascal_roy_1967@>wrote:
                                > > >
                                > > >
                                > > Hi Pascal,
                                > >
                                > > Really, are you really offloading the risk?
                                > > >
                                > >
                                > > I don't think Steve actually means offloading the risk, I can reduce the
                                > > risk by allowing a company whose core business is development to complete
                                > > that portion of the project. And part of this risk can also be transfered or
                                > > shared, just like with insurance. This means part of the consequences of
                                > > failing to complete the outsourced project falls on the entity that accepted
                                > > the project.
                                > >
                                > >
                                > > As far as the project is concerned, you really just moved the risk around
                                > > > but it is still fully there. You maybe offloaded part of the financial risk
                                > > > (not even all since even if you outsource, you still put money in it).
                                > > >
                                > >
                                > > I assume you don't work using this model or you might have known that
                                > > failure to deliver may have additional financial consequences for the party
                                > > that is completing the project, this can be in the from of late fees or
                                > > fines. This offsets a portion of risks of late delivery.
                                > >
                                > >
                                > >
                                > > > I would think that If you really cared about your project, you'd want to
                                > > > know how the outsourcer is addressing this risk anyway...
                                > > >
                                > >
                                > > You shouldn't really get into bed with a company without due diligence, this
                                > > goes for both parties. This may make it difficult in the case of risks that
                                > > can't be identified or assessed.
                                > >
                                > >
                                > >
                                > > > Another thing. By outsourcing, you probably even increased the risk since
                                > > > you are now dealing with another entity over which you have even less
                                > > > control. That's not to mention the increased complexity in communication.
                                > > >
                                > > > It seems, we are more concerned in our field about saving our bacon when
                                > > > things go wrong rather than working together to make things work from the
                                > > > get go and making hard decisions together when necessary.
                                > > >
                                > > > IMHO, offloading risk to outsourcers offers a false sense of security. Even
                                > > > if you sue, how long will that take? How much of the money will go to the
                                > > > lawyers? You might not even get anything if the outsourcer goes into
                                > > > bankruptcy. And what about the project, is it any better for it? Isn't that
                                > > > the primary goal of any software development project, producing working
                                > > > software???
                                > > >
                                > >
                                > > Due diligence should ensure that these risks have been identified or
                                > > accessed.
                                > >
                                > >
                                > >
                                > > > Le 2011-05-18 à 09:11, Steve a écrit :
                                > > >
                                > > >
                                > > >
                                > > > ONE reason that companies outsource development is to 'offload' risk. If
                                > > > you can get someone to do something agreed fixed time and cost, then the
                                > > > risk of that time and cost being wrong falls on the outsource company.
                                > > >
                                > > >
                                > > D.
                                > >
                                >
                              • chrischany
                                By outsourcing you take on some risks such as lower quality of work - I have seen so many things come back that is not of any substantial quality. Another
                                Message 15 of 19 , May 19, 2011
                                • 0 Attachment
                                  By outsourcing you take on some risks such as lower quality of work - I have seen so many things come back that is not of any substantial quality. Another risk is getting back something that you didn't really want due to a different interpretation of the requirements. As a result, change requests are required which increases the cost.

                                  - Chris
                                • woynam
                                  I worked on a mainframe migration project several years ago. The requirements document had a paragraph describing the requirements for handling
                                  Message 16 of 19 , May 19, 2011
                                  • 0 Attachment
                                    I worked on a mainframe migration project several years ago. The "requirements" document had a paragraph describing the requirements for handling cancel/replace order routing in the system.

                                    The corresponding test plan for this "feature" was over 70 pages long, containing over 100 significant test cases.

                                    Yes, thinking that you "know" the requirements upfront can only lead to trouble.

                                    Mark

                                    --- In scrumdevelopment@yahoogroups.com, "strazhce" <infobox.oleg@...> wrote:
                                    >
                                    > George,
                                    >
                                    > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
                                    > >
                                    > > On 5/18/11 4:32 AM, strazhce wrote:
                                    > > > Yes, we work mostly by Fixed Price + Fixed Requriements.
                                    > >
                                    > > Are you really? Or are you working by Price Not To Exceed +
                                    > > Requirements Not Less Than?
                                    > >
                                    > > If you are truly working with fixed requirements, how do you fix them?
                                    > > How do you prevent undiscussed requirements from showing up later as
                                    > > assumed and essential?
                                    >
                                    > you are of course absolutely right, price is "at most", but requirements are "at least". This invites trouble.
                                    > We just can't prevent customer from brining new requirements and claiming this is of course in scope of original request and "this is absolutely clear" from some tiny sentence in request for proposal. That happened to us many times.
                                    >
                                    > Oleg
                                    >
                                  • Steve
                                    Hi Chris. This what happens if you just want to throw the spec over the wall to the supplier. To have the expectation that they will do everything exactly
                                    Message 17 of 19 , May 19, 2011
                                    • 0 Attachment
                                      Hi Chris.

                                      This what happens if you just want to 'throw' the spec 'over the wall' to the supplier. To have the expectation that they will do everything exactly that you want is totally unrealistic.

                                      The only way that this could, possibly, work is if you spend inordinate amounts of time to make sure that the spec could not be mis-interpreted; probably impossible but certainly impracticable.

                                      You mention 'quality' - I have started a disscusion about 'What is Quality' elsewhere - I would be interested about how you measure 'quality'

                                      Cheers

                                      --- In scrumdevelopment@yahoogroups.com, "chrischany" <agile.forums@...> wrote:
                                      >
                                      > By outsourcing you take on some risks such as lower quality of work - I have seen so many things come back that is not of any substantial quality. Another risk is getting back something that you didn't really want due to a different interpretation of the requirements. As a result, change requests are required which increases the cost.
                                      >
                                      > - Chris
                                      >
                                    • George Dinwiddie
                                      Oleg, ... This is the crux of the matter. There is a fundamental problem with receiving cash from the customer and giving them a blank check on which they can
                                      Message 18 of 19 , May 19, 2011
                                      • 0 Attachment
                                        Oleg,

                                        On 5/19/11 3:50 AM, strazhce wrote:
                                        > George,
                                        >
                                        > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie<lists@...> wrote:
                                        >>
                                        >> On 5/18/11 4:32 AM, strazhce wrote:
                                        >>> Yes, we work mostly by Fixed Price + Fixed Requriements.
                                        >>
                                        >> Are you really? Or are you working by Price Not To Exceed +
                                        >> Requirements Not Less Than?
                                        >>
                                        >> If you are truly working with fixed requirements, how do you fix them?
                                        >> How do you prevent undiscussed requirements from showing up later as
                                        >> assumed and essential?
                                        >
                                        > you are of course absolutely right, price is "at most", but
                                        > requirements are "at least". This invites trouble. We just can't
                                        > prevent customer from brining new requirements and claiming this is
                                        > of course in scope of original request and "this is absolutely clear"
                                        > from some tiny sentence in request for proposal. That happened to us
                                        > many times.

                                        This is the crux of the matter. There is a fundamental problem with
                                        receiving cash from the customer and giving them a blank check on which
                                        they can later fill out whatever amount they wish. No software
                                        development methodology can fix that problem, because it's not a
                                        software development problem.

                                        It is, instead, a negotiation problem. There are many ways to address
                                        this problem, but they seem to fall into three broad categories.

                                        1. *Deceit* We can promise the customer whatever we want, knowing we
                                        have a way to avoid delivering. Perhaps we have better lawyers, or we
                                        can fold the company and give them no recourse.

                                        2. *Specification* We can try to lock down /exactly/ what is promised
                                        and what is not to a degree that any ambiguity is not overly expensive.
                                        The concept of "overly expensive" is variable depending on the amount
                                        of buffer we've added to our estimates and the amount of profit margin
                                        we've built into our rate structure.

                                        3. *Collaboration* We can offer good-faith estimates of both the work
                                        and the cost, showing how we can track the conformance of those
                                        estimates with reality as things progress. In the best of cases, if
                                        reality and the estimates diverge enough to make one party
                                        uncomfortable, then we amicably renegotiate.

                                        It is, of course, more difficult if you have a marketing department
                                        acting as a go-between between an external customer and an internal
                                        development department. Having communication chains always makes it
                                        more difficult to collaborate.

                                        When the marketing department is negotiating by specification with the
                                        external customer, and by collaboration with the internal one, then
                                        they're between a rock and a hard place. At least have the advantage of
                                        seeing trustworthy estimates and getting early warning when they're in
                                        trouble. That's better than negotiating by specification in both
                                        directions.

                                        In such a position, they need to have enough understanding of the
                                        trustworthiness of the estimates by development, and of the clarity and
                                        completeness of the specifications from this particular customer, that
                                        they can set the buffer and profit margin at levels that ensure a
                                        profit. That's a tough thing to do, but it's the job they've signed up for.

                                        Sometimes I've noticed that when the buffer and profit margin are
                                        insufficient, they fall back on the strategy of deceit. For example,
                                        I've seen contracts where the acceptance period for the customer to
                                        detect and report any deviations from the specification to be impossibly
                                        short. This allows them to deliver a system that appears to meet what
                                        the customer needs, but has grave problems under the surface. Another
                                        example is to tie the specifications down enough that the customer is
                                        sure to want changes in it before the delivery date, and then soak them
                                        with change charges.

                                        There is no one way to handle these issues. My preference is for a
                                        strategy of collaboration, but that's not what a Fixed-Time, Fixed-Cost,
                                        Fixed-Scope contract is.

                                        - George

                                        --
                                        ----------------------------------------------------------------------
                                        * George Dinwiddie * http://blog.gdinwiddie.com
                                        Software Development http://www.idiacomputing.com
                                        Consultant and Coach http://www.agilemaryland.org
                                        ----------------------------------------------------------------------
                                      • Daniël W. Crompton
                                        On 19 May 2011 18:26, George Dinwiddie wrote: Let s assume that as a client I want to mitigate and reduce these risks. 1. *Deceit* We
                                        Message 19 of 19 , May 19, 2011
                                        • 0 Attachment
                                          On 19 May 2011 18:26, George Dinwiddie <lists@...> wrote:

                                          Let's assume that as a client I want to mitigate and reduce these risks.

                                          1. *Deceit* We can promise the customer whatever we want, knowing we
                                          have a way to avoid delivering. Perhaps we have better lawyers, or we
                                          can fold the company and give them no recourse.

                                          I ask for references from other companies that the outsourcing company has worked with on similar projects, I speak to the people in the previous client companies and verify the facts. I find customers who are not happy with that which was delivered, for most companies this is not too hard, and talk to them. I weigh the pros and cons, identify the risks that I might face and I go to the next company who have a tender for this project and start again. Only once I have evaluated all the companies I will make a decision, based on comparing all the companies I have spoken to.

                                           
                                          2. *Specification* We can try to lock down /exactly/ what is promised
                                          and what is not to a degree that any ambiguity is not overly expensive.
                                          The concept of "overly expensive" is variable depending on the amount
                                          of buffer we've added to our estimates and the amount of profit margin
                                          we've built into our rate structure.

                                          As part of pre-sales, in my role as PO, I go to the outsourcing company and lead a workshop which cover the business requirements, discuss use cases and create the initial user stories. The advantage with SCRUM is that user stories encompass the requirements and transform  requirements into goals and milestones. The ambiguity that may have been part of the initial specifications or user stories can be cleared up by me during the Sprint Planning.

                                          D.


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