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

How much?

Expand Messages
  • Rafael Nascimento
    Hi guys! I have a doubt about the don´t estimate approach. Many organizations, nowadays, choose between two or more software suppliers analyzing the cost
    Message 1 of 5 , Jul 8, 2011
    • 0 Attachment
      Hi guys!

      I have a doubt about the "don´t estimate" approach.

      Many organizations, nowadays, choose between two or more software suppliers analyzing the cost and the delivery date that each one "commit to".
      The famous question: "How much it´ll cost? When we´ll get it?"

      Well, if we don´t answer this, we don´t even put out feet in the organization. In most cases, we assemble the team for the project, after we sign the contract. So, we don´t have the team to estimate so early.

      Sometimes, we even know we´ll need the help of a second team, "anytime" in the schedule. But this is tricky, because it´s too early to "commit" with a budget for this second team.

      What the community use to do in this cases?

      Thanks!
      Rafael Nascimento
    • Peter Bell
      Someone has to own the commitment, so at least make sure you have a team lead who believes in the price and timeframe they are committing to. Make sure they
      Message 2 of 5 , Jul 8, 2011
      • 0 Attachment
        Someone has to own the commitment, so at least make sure you have a team lead who believes in the price and timeframe they are committing to. Make sure they are experienced enough to estimate that kind of project reasonably, make sure they understand that estimates are probabilities, so they don't give the "most likely" date as the commitment because there's less than a 50% chance you'll meet that date on any given project. 

        Then if you have fixed price and timeframe, the only thing left to vary is scope, so make sure that you have a high level set of business requirements that can be met to the letter of the contract within about 50% of the estimated timeframe and budget. Then work on an iterative basis with the client to make as many improvements to the system as possible within the timeboxed amount of hours and weeks. I find that's the least bad way of working with fixed bid and timeframe projects as you get the contract risk out of the way early and deliver something that the client has to sign off that it meets the specs (even if not their needs) no later than 60% through the project. You then have the balance of the time to work in a more agile manner, adding the most value possible within the remaining contracted time.

        Best Wishes,
        Peter


        On Jul 8, 2011, at 9:22 AM, Rafael Nascimento wrote:

         

        Hi guys!

        I have a doubt about the "don´t estimate" approach.

        Many organizations, nowadays, choose between two or more software suppliers analyzing the cost and the delivery date that each one "commit to".
        The famous question: "How much it´ll cost? When we´ll get it?"

        Well, if we don´t answer this, we don´t even put out feet in the organization. In most cases, we assemble the team for the project, after we sign the contract. So, we don´t have the team to estimate so early.

        Sometimes, we even know we´ll need the help of a second team, "anytime" in the schedule. But this is tricky, because it´s too early to "commit" with a budget for this second team.

        What the community use to do in this cases?

        Thanks!
        Rafael Nascimento


      • Rafael Nascimento
        Here in Brasil is common to sacrifice the date instead of the scope. Quality is a second option, but, in agile, it s frozen. I think it s a really bad thing to
        Message 3 of 5 , Jul 8, 2011
        • 0 Attachment
          Here in Brasil is common to sacrifice the date instead of the scope. Quality is a second option, but, in agile, it's frozen.
          I think it's a really bad thing to postpone the project (even if you can do it), because we have chances to have an "eternal" project and make the developers unhappy.

          Am I exaggerating? Is it not so bad to sacrifice the date?
          IMO, I'll always negotiate the scope, even if I can negotiate the date or the budget, the scope will be always my first option.


          2011/7/8 Peter Bell <lists@...>
           

          Someone has to own the commitment, so at least make sure you have a team lead who believes in the price and timeframe they are committing to. Make sure they are experienced enough to estimate that kind of project reasonably, make sure they understand that estimates are probabilities, so they don't give the "most likely" date as the commitment because there's less than a 50% chance you'll meet that date on any given project. 


          Then if you have fixed price and timeframe, the only thing left to vary is scope, so make sure that you have a high level set of business requirements that can be met to the letter of the contract within about 50% of the estimated timeframe and budget. Then work on an iterative basis with the client to make as many improvements to the system as possible within the timeboxed amount of hours and weeks. I find that's the least bad way of working with fixed bid and timeframe projects as you get the contract risk out of the way early and deliver something that the client has to sign off that it meets the specs (even if not their needs) no later than 60% through the project. You then have the balance of the time to work in a more agile manner, adding the most value possible within the remaining contracted time.

          Best Wishes,
          Peter



          On Jul 8, 2011, at 9:22 AM, Rafael Nascimento wrote:

           

          Hi guys!

          I have a doubt about the "don´t estimate" approach.

          Many organizations, nowadays, choose between two or more software suppliers analyzing the cost and the delivery date that each one "commit to".
          The famous question: "How much it´ll cost? When we´ll get it?"

          Well, if we don´t answer this, we don´t even put out feet in the organization. In most cases, we assemble the team for the project, after we sign the contract. So, we don´t have the team to estimate so early.

          Sometimes, we even know we´ll need the help of a second team, "anytime" in the schedule. But this is tricky, because it´s too early to "commit" with a budget for this second team.

          What the community use to do in this cases?

          Thanks!
          Rafael Nascimento



        • George Dinwiddie
          Rafael, ... You /can/ make projections into the future. See http://blog.gdinwiddie.com/2010/04/22/projecting-into-the-future/ It s just that you need to
          Message 4 of 5 , Jul 8, 2011
          • 0 Attachment
            Rafael,

            On 7/8/11 9:22 AM, Rafael Nascimento wrote:
            >
            >
            > Hi guys!
            >
            > I have a doubt about the "don´t estimate" approach.
            >
            > Many organizations, nowadays, choose between two or more software
            > suppliers analyzing the cost and the delivery date that each one "commit
            > to".
            > The famous question: "How much it´ll cost? When we´ll get it?"
            >
            > Well, if we don´t answer this, we don´t even put out feet in the
            > organization. In most cases, we assemble the team for the project, after
            > we sign the contract. So, we don´t have the team to estimate so early.
            >
            > Sometimes, we even know we´ll need the help of a second team, "anytime"
            > in the schedule. But this is tricky, because it´s too early to "commit"
            > with a budget for this second team.
            >
            > What the community use to do in this cases?

            You /can/ make projections into the future. See
            http://blog.gdinwiddie.com/2010/04/22/projecting-into-the-future/

            It's just that you need to recognize the likely inaccuracies of these
            projections. Estimates are just guesses. The less you know, the less
            likely your projections will be helpful.

            You can do things to help your projections:
            - Keep teams together, so you have a feel for how fast they produce
            software.
            - Compare future work with past work, similar in size and complexity.
            - Perform spikes or experiments to get understanding on unknown
            technologies.

            Don't treat your projections as commitments. Review them regularly,
            make adjustments, and revisit your decisions for the future. You can
            always pull the plug if things no longer look economically feasible. If
            you must make commitments, you'll have to do the same as in the old
            days--give yourself plenty of padding to allow for the unknown.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Peter Stevens (cal)
            On 08.07.11 21:41, Rafael Nascimento wrote:   Here in Brasil is common to sacrifice the date instead of the scope. Quality is a second option, but, in agile,
            Message 5 of 5 , Jul 11, 2011
            • 0 Attachment
              On 08.07.11 21:41, Rafael Nascimento wrote:  

              Here in Brasil is common to sacrifice the date instead of the scope. Quality is a second option, but, in agile, it's frozen.
              I think it's a really bad thing to postpone the project (even if you can do it), because we have chances to have an "eternal" project and make the developers unhappy.

              Am I exaggerating? Is it not so bad to sacrifice the date?
              IMO, I'll always negotiate the scope, even if I can negotiate the date or the budget, the scope will be always my first option.

              Hi Rafael,

              To answer the question, you need to understand the cost of delay. You only get value once the software you are building has been released to it user community. Until that point in time, you are investing with no return.

              What is the net impact if you delay your project by, say, 6 months. To understand this, you need to look at not just the direct costs (i.e. the salaries of the developers), but also the impact revenue, market share, costs savings, etc. which will be produced by the project.

              You can create a financial statements for multiple scenarios and see which one you like best. A good product owner will understand this and guide the project to achieve the best ROI possible.

              As a general strategy, I would try to identify the minimum possible feature set which will produce value for the customer or users and focus on those features first. The longer you delay, the more you have to invest. The longer you delay, the greater the risk that a competitor will enter the market and force lower margins, higher marketing costs (even though you have less money to invest), or even take such a strong position that you have no chance. (The details are different but the logic is similar for internal projects).

              Cheers,

              Peter
              .



              -- 
              Peter Stevens, Partner 
              DasScrumTeam AG 
              
              Switzerland: direct: +41 44 586 6450 cell:   +41 79 422 6722
              USA:         direct: +1 202 657 6450 
              World:       skype:  peterstev
              
              blog:   http://scrum-breakfast.com
              
            Your message has been successfully submitted and would be delivered to recipients shortly.