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

Re: [XP] Re: Customer doesn't trust our estimates

Expand Messages
  • Simon Brown
    ... I can see how this might happen - it could be taken as hostility. So much is carried in the tone of voice that the same phrase could be taken entirely
    Message 1 of 50 , Apr 1, 2003
      At 06:18 01/04/2003 -0500, you wrote:
      >On Tuesday, April 1, 2003, at 3:10:15 AM, Simon Brown wrote:
      >
      > > "We have given you an estimate of the time we believe it will take to
      > > complete the work. We're working as hard as we can. If you think there are
      > > programmers who can do the same work in less time than we have estimated,
      > > then by all means hire those programmers."
      >
      > > Liberally borrowed/paraphrased from Ron, but I like it. I intend to use it
      > > often in my place of work.
      >
      >I can think of no higher praise than to have my thoughts used. A word of
      >warning: the customer may feel trapped into using your team. Thoughts like
      >the one above need to be expressed in a friendly open way, not one that
      >will drive a wedge between us. Use with caution.

      I can see how this might happen - it could be taken as hostility. So much
      is carried in the tone of voice that the same phrase could be taken
      entirely differently in two different situations.

      Essentially what I am trying to do here is make myself braver. We're not
      doing XP here, and sometimes we will give an estimate to the account
      manager, who will go away and give this estimate to the customer, and
      return with a cut-down deadline and no change in scope. Historically I am
      very bad at doing anything other than mumbling "I'll see what I can do" in
      this situation.

      One of the things I am thinking of doing is putting some of this stuff up
      on my wall. Not necessarily so that others see it, but so that it reminds *me*.

      I am trying to bring about some changes in our workplace, but it's a slow
      process at the best of times. We have source code control now, which makes
      me very happy indeed, and we have a very tiny amount of automated testing,
      with the probability of some more. After this week we might be able to
      convince management that pairing has some value.

      Tiny steps, I guess...

      > > You have to own the estimates, and your customer has to understand that
      > the
      > > estimates are exactly what the name implies - your best Estimate of the
      > > time it will take to do the work. She needs to understand that the work
      > > takes the time it takes. If she wants it to take less time, there needs to
      > > be less work.
      >
      >This is the lesson, of course: the customer needs to focus requests on the
      >essence of her ideas for the product, and to eliminate less-valuable
      >things. As you suggest, more time with her will help her do that. And at
      >every opportunity, if she says that some estimate is too large, I would try
      >to be ready with something like this:
      >
      > "Well, three days is for the feature as specified, with the rotating
      > rings and flashing lights. If the rings can be standing still and only
      > half the lights flash, we could do that in two days. Then we can make the
      > rings rotate and the other lights flash later, if there's more time."

      I'm definitely stealing this one. :)

      Simes.

      --
      Simon Brown <simes@...>

      "He's saying it's just a cake, sir."
      "We can't take that chance. Order full orbital response."
    • davechaplin
      Is your customer technical? If so, then ask them to show you how they would do it quicker. Admit that you don t know. You know yourself that you are working
      Message 50 of 50 , Apr 9, 2003
        Is your customer technical? If so, then ask them to show you how they
        would do it quicker. Admit that you don't know. You know yourself
        that you are working very fast using XP, and that the quality
        investments you are making will pay off. You can gamble on that. Make
        sure your estimates accurate though, since no-one likes a deadline
        that isn't hit. Under promise /commit, and over deliver.

        Don't tell her you are coding 6 hours a day regardless. Tell her you
        are coding 8, then make sure you only code spikes and R&D stuff in
        the other 2 hours. Personally, we stop touching production code after
        about 4pm. Our brains are a bit dead. Then we work on previously
        marked TODO's/STUB's in the code that are low brain activities to fix.

        Regarding the problems with times estimates. Give a range if you are
        unsure. e.g. between 5 and 15 days. Tell her you need to do some R&D
        for 2 days to get an accurate estimate. If she takes the lower one
        that is her problem and you have a project management problem you
        need to solve. Openly refuse to commit to deadlines unless you are
        sure of hitting them. I suspect you had project overuns in the past
        because someone else other than the developers was promising
        something that couldn't be delivered. Seen that before. It was solved
        by the particular project manager being marched out the building by
        security. That solved it!

        Hope that helps.

        Dave.

        --- In extremeprogramming@yahoogroups.com, "rodriguez_jose48"
        <rodriguez_jose48@y...> wrote:
        > Now, after we've managed to have some separation of
        responsibilities
        > between programmers and Customer, our main problem is that the
        > customer does not trust our estimates.
        >
        > She thinks we are giving her too big estimates, and that we are
        > working too slowly. She is right in thinking like this because in
        the
        > past this project didn't went so well, and schedule overruns were
        > a 'normal' thing.
        >
        > What can we do to solve this problem?
        >
        > This has a couple of bad consequences over the process.
        >
        > For example we cannot tell her we are programming only 5-6
        hours/day.
        > I've seen on this list that others have a similar period of
        effective
        > coding each day, so I believe it is a normal thing (anyway we are
        > tired after 5-6 hours of effective coding).
        >
        > Another problem is that we fear to have the Customer with us during
        > the planning. We fear that we will not be able to give an accurate
        > estimate in a short time (planning a story shouldn't take long, I
        > guess) and if we give a shorter estimate, she will not agree to
        > change it in the future.
        >
        > Besides, during the planning game, we, the programmers, have to be
        > careful, not to tell anything about the mapping real time/ideal
        time
        > (we are estimating in ideal days and weeks).
        >
        > Any ideas?
        >
        > Jose.
      Your message has been successfully submitted and would be delivered to recipients shortly.