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

Re: [scrumdevelopment] SCRUM with Fixed Price Contracts

Expand Messages
  • Ron Jeffries
    ... I thought you said this was a fixed-price contract. Is time accounting more than just an internal accounting mechanism? ... Well, actually, the way I do
    Message 1 of 78 , Jul 4, 2006
    • 0 Attachment
      On Tuesday, July 4, 2006, at 3:05:41 AM, Vickydhiman wrote:

      > Hello Ron and Group:

      >>>If the team is spending time with the customer, surely that
      >>>should be billed. If the team is spending time planning and
      >>>designing, surely that should be billed. Tell us more about how
      >>>you account for your time?

      > Historically, we have only billed developer time to the clients.
      > The communication/ interaction/ project management time has not
      > been billed. Analyst team time is billed however for all the
      > solution framework work.

      I thought you said this was a fixed-price contract. Is time
      accounting more than just an internal accounting mechanism?

      >>> My favorite estimation technique is to put all the features on
      >>> cards, have experienced team members estimate the cards as to
      >>> how long they'd take to do in a perfect world, then multiply
      >>> that number by three.

      > And you provide these cards for the custom for an estimate of how
      > much an iteration would cost the client?

      Well, actually, the way I do Agile, the customer is supposed to
      provide the requirements ... so they would be her cards.

      >>> So it's the manager / Scrum Master who is actually jerking the
      >>> project around, not the customer?

      > Its basically the client. Scrum Master just follows the brief -
      > discusses with the client and then provides the milestone for
      > modules completion.

      Well ... it sounds to me as if the SM is talking to the client and
      then bringing changes / extensions back to the team. He would /not/
      be doing that using your previous method? If that's the case then he
      must be doing something different.

      >>> It sounds to me as if that feedback loop, relating cost to
      >>> value, is broken in your project. If that's the case, probably
      >>> no estimation technique is going to help.

      > I am not sure if I even understand what cost to value loop means.
      > Probably Google around a bit.

      I suspect you won't find it. I am referring to this loop, which
      appears to be broken in your situation:

      1. Customer has a fixed amount of money she wants to spend.
      2. She has estimates of how much all the features will cost.
      3. She proposes an enhancement, grand and glorious and overblown.
      4. The team tells her how much it will cost.
      5. She decides whether she can afford it, based on the cost of all
      remaining work, and the value to her of this idea.

      By agreeing to a fixed-price contract, you have relieved your
      customer of the responsibility to make rational decisions about the
      value of items given their cost. It is now to her advantage to
      demand all kinds of things: the more she demands, the more she gets.

      That's why Agile practitioners, in general, do not recommend
      fixed-price contracts.

      > I am sure that business must generate profits and despite
      > everything we are able to generate profits but probably not enough
      > profits. We routinely offshoot our project estimates but probably
      > because of other factors [low taxes, low salaries etc.] we are
      > able to generate profits. And we all agree that there is scope for
      > improvement.

      There always is. ;-> Better estimation would help, but can lead to
      lost contracts because your prices will be higher.

      What is your present policy on "change control" in your contracts?

      >>> I would like to hear more about the communication loop between
      >>> team, manager, customer, as regards changes and costs.

      > We have switched to using BaseCamp PMS over past one year or so.
      > All project milestones, to-do lists, messages, documents are
      > posted there. The team and client have access to this account
      > where all project discussions are done.

      Interesting that you would respond to a question about communication
      by referring to a tool. Although Basecamp does bill itself as a
      project collaboration tool, I was actually interested in what the
      actual discussions were like:

      Customer has some wild new idea. I gather that the manager / Scrum
      Master has this conversation. How does that conversation go?

      I would think that part of the manager's interest would be the
      cost of the feature proposed. How does he find out what that cost
      will be? Does he involve the team? What does he do with the

      Does he just commit to whatever the customer says? How does the
      cost of a proposed feature enter into the conversation? Is he
      looking at the effect of some exotic new feature on the time and
      money burndown? Is he calculating the effect of that feature on
      the project time and money budget? Does he share that information
      with the team? With the customer?

      > The basic document which governs the discussion on changes and
      > costs is the basic proposal document [specification and
      > estimates].

      Yes ... what does it say?

      > Let's revisit our sign-in page functionality:

      > We drew the two text boxes and buttons and some links. Now the
      > client says that what you showed me was obviously a basic page and
      > what I require is an aesthetic looking web page which has a fancy
      > faded background image [he would point out and say Graphics Design
      > is part of the scope], some "?" Javascript pop-ups. And suppose
      > this is the first time a client has made such a request [you had
      > no historical data for this]. How would we handle this request?

      The first time ever? I hope that the requests that surprise you are
      rather more exotic than this one.

      I would think that I might be tracking Graphics Design separately,
      having called it out. If I could write the project proposal, I'd be
      budgeting a specific amount of money for graphics design, and
      allowing the customer to manage the tasks. "The creation of that
      image, if we do it, will cost one graphics design day of the twenty
      days you purchased. You've already used nine days. We'll be happy to
      create the image if you want us to."

      Or, if I were any good at Web design -- I'm not -- I would think I'd
      have discussed the overall look and feel of the design, and written
      it into the proposal. Then we could say "This goes beyond the look
      and feel we agreed to. Let's look again at the watercolor pictures
      in the proposal. We can go to the next level if you want us to, at a
      cost of $X, or, of course, we'll be happy to proceed on the
      originally-purchased level."

      You have your finger on the reason why I'd not want to bid a
      fixed-price contract and then give the client a free hand in asking
      for anything she wanted. I don't see how it could work, because as
      soon as I relieve her of the responsibility to manage the price, her
      best strategy really is to ask for everything in the world.

      What I might do, as a tactic "in the interest of time" would be to
      insist on building out the whole product with simple features first,
      coming back to address frills later. This would get the customer
      impatient to deploy the system, and would ensure that all the
      promised functionality was there, if not as fancy as they might
      like. I might focus on getting a good, clean, but simple version of
      everything up, and then revisit tarting it up, after the system was
      ready to deploy.

      It might be necessary to hold back actual deployment until after the
      contract term was up, which I wouldn't usually want to do. We
      haven't talked about the payment terms, nor do we need to, but if we
      were only going to get the money at the end, or after specific
      milestones, that might change things.

      In the whole thing, I'd be very uncomfortable, though, because what
      I consider to be a critical project feedback loop, the link between
      cost and value, is broken in a fixed-price situation.

      Ron Jeffries
      I could be wrong. I frequently am.
    • Adrian Howard
      ... [snip] How accurate are the estimates pulled from the database? What happens when they re wrong? Who decides that the developer has met the analysts spec?
      Message 78 of 78 , Jul 5, 2006
      • 0 Attachment
        On 5 Jul 2006, at 16:33, Vickydhiman wrote:

        > Hello Sammy:
        > Developers create the estimates based on specifications done by
        > Analysts. For most cases, estimates already exists and are pulled
        > from the database.

        How accurate are the estimates pulled from the database? What happens
        when they're wrong?

        Who decides that the developer has met the analysts spec?

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