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

Re: SCRUM with Fixed Price Contracts

Expand Messages
  • Mike Beedle
    ... Vicki, I understand your frustration. The big fixed price project situation happens in most large companies, and in many small and medium ones is not
    Message 1 of 78 , Jul 1, 2006
    • 0 Attachment
      Vicky wrote:
      > Once the project is approved, the project is run largely on SCRUM
      > principles. From all the screens - various modules are identified.
      > Based on modules selected by the clients and dependencies [GUI
      > design must proceed integration of GUI with backend] sprints
      > [generally 2 weeks] are identified.

      > For the sprints - tasks are written in detail over the first two
      > days. Client is involved in these tasks [written more like
      > acceptance tests]. This is the phase where trouble actually
      > creeps in. Some of the clients [we work with dedicated clients]
      > can indulge in long discussions on what is in scope and what is
      > not.

      > After everything what it comes down to is even lengthier proposal
      > document which outlines more "what is not in scope" than "what is
      > in scope".

      > Another problematic area is the top management starts viewing
      > estimates [proposal estimates] as the metric and the teams which
      > exceed that metric are categorized as under performers.

      > Perhaps a more possibly question can be - how can we provide a
      > fixed price estimate for all the sprints/ iterations up front? Or
      > even can we?


      I understand your frustration. The "big fixed price project"
      situation happens in most large companies, and in many small and
      medium ones is not uncommon.

      Here are some ideas that may help you:

      1) Estimate for the Overhead Upfront (Bloat Upfront)

      To "Estimate Upfront" we respond with "Large Estimate Upfront".

      Make the client pay for the unknowns.

      If the only way you have to get the business is by bidding
      for the whole project at "fixed cost", but then "loosing money"
      by babysitting the client; well bloat the estimates, knowing
      everthing you do with them will involve overhead, babysitting,
      and creeping requirements.


      Your developers and technical lead come with a "technical estimate"
      of 20 hrs to do something, then you adjust the estimate by
      analyzing, how much overhead will be involved in the tasks? who will
      we be working with you? How many groups are involved? Who is the
      business manager? etc.

      This is where the magic factor of 2.5, 3.3, or even 4, comes from.
      Developers are terrible at estimating this factor because in most
      cases they don't see the politics, the babysitting, the
      communication overhead, etc.

      If the customer complains, then tell them about how hard is to get
      things done at their company, and use well-known examples for this.
      (You may want to do this at lunch when you are with a manager by
      yourself, not a group meeting.)

      Politically this works better than the following alternatives,
      but unless your "planned overhead" is very large, be aware there is
      still a lot of exposure for your company:

      You don't want to braek even of loose money on ANY project!

      In the back of you mind, you should always be thinking in some
      of those lengthy pointless meetings: "They are paying for this!".

      Be aware this is an "averaging game".. some tasks will be longer
      than estimated, some shorter than estimated, some just right, but
      on the average, if you picked up the correct factors, you will
      still make money.

      If the client tells you "we only use 5 hrs for this", then tell them
      "yes, but we used X hours for that" -- use real examples.


      2) Use the "Fixed Bid" to your advantage aka stong Change Management

      This is similar than the above, but you hold every number as true,
      and then adjust per Product Backlog item. Here you will manage the
      customer with the "fixed cost" for the specifed Product Backlog item
      to your advantage. As once they pass their estimate, you will
      charge them extra for ANY time spent if you blow the estimates
      for individual Product Backlog items.

      This is to force the client to tell their people:

      "Don't waste any time in extra or lengthy meetings --
      we are paying for them".


      We had 10 hours for implementation of XYZ, since we spent 20,
      we 10 hours are from the fix bid, and 10 are for change mangement.

      3) Do "Fix Bid" as "Fixed Number of Hours"

      This one is almost a contracting trick. When you sign the contract
      make sure somewhere in the contract says that it is a "fix bid for
      X number of hours".

      When the team runs out of time, then they get as much as they
      could do with the bucket of time.

      This is where the magic email to the client manager goes as
      something like:

      "Joan, We are at 900 hrs, and I getting concerned that the 1200 hrs
      for which we fixed bid for the project will not be enough to
      finish all the tasks. What tasks should we leave out? Or
      alternatively, can we secure more budget to finish all of them?"

      The manager may come to you and say, "no this is a fixed bid
      project", that's when you pull the contract and say: "yes, it is
      fixed bid for 1200 hrs". Touche!


      If at all possible, however, convince your customer not
      to work on "fixed price projects". It is so much better
      when the customer pays for what they get every time.

      This is good for them, because they can build the software
      and change directions easier if necessary -- making compromises is
      almost universal, and it is better for you -- you won't have
      to play all of the "games with hours" above.

      Good luck,

      - Mike

      * I am watching Brazil vs. France still 0-0 at half time, and
      Roddick vs. Murray at Wimbledon. Roddick is up 6-5!!!
    • 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.