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

Re: [scrumdevelopment] Re: Help with The Inevitable Question

Expand Messages
  • Ron Jeffries
    Hello, Giora. On Monday, September 1, 2008, at 7:01:15 AM, you ... It appears that I have failed to make my point, which is that it is a fool s game to ask
    Message 1 of 38 , Sep 1, 2008
    • 0 Attachment
      Hello, Giora. On Monday, September 1, 2008, at 7:01:15 AM, you
      wrote:

      >> I'd be inclined to tell them something like this:
      >>
      >> a) we're going to do it chunk by chunk anyway, in the value of
      >> highest business value first;
      >> b) we are going to make it always releasable so you can try it,
      >> or even use bits you like better;
      >> c) we are guessing that you'll want some new things, and find
      >> some old things to drop out;
      >> d) if we have to set a price now, we need to be sure we set it
      >> at a profitable level; we'll have to assume the worst case;
      >> e) if we proceed chunk by chunk, we'll both make out fairly.
      >>

      > I don't think this is a "chunk by chunk" or "big bang" problem. I
      > think it is perfectly acceptable to get a sense of the budget-bet
      > required before making an investment in anything - software or
      > otherwise. Is it not fair to ask: "If I have $1M to spend on a
      > product, will I get enough of a product to make a dent in the market?"
      > Furthermore, when we speak of value we have to consider not only the
      > benefit but also the cost. Also, what if I have three different
      > products to invest in, certainly having an idea of the cost to bring
      > them to market would be a factor in which one to invest in.

      It appears that I have failed to make my point, which is that it is
      a fool's game to ask for the price up front on a fixed- but-
      unknown- content implementation which is almost certainly not what
      they really want anyway.

      Having an idea of the cost would be nice. Having an answer to the
      question "Can you give me something decent for $1M in six months?"
      is really nice.

      That does not appear to be what the customer is asking for.

      My mission, and I've chosen to accept it, is to help the OP get what
      he wants, which is an incremental pricing deal. I think the idea
      would be called "negotiation", which is, I would like to suggest
      ever so kindly, a natural part of business, compared to knuckling
      under, which seems to be your suggestion.

      If one believes, as I and the OP both seem to, that an incremental
      deal is better for everyone, then one believes also that one is
      morally bound to try to put such a deal together.

      To do so, I suggested my list of statements above as a start in the
      direction of leading the prospect to an arrangement that will be
      better for both sides.

      I'm a bit surprised at being taken to task for trying to make the
      world a somewhat better place. Not very surprised mind you, as it
      happens a lot.

      > That being said, I don't believe we need "all the requirements known"
      > in order to get a sense as to the relative size of a particular
      > product initiative. Even with traditional waterfall projects, the
      > business-case justification for investing in a particular project is
      > done before the "requirements phase". Most companies would then review
      > this cost-estimate after requirements-gathering, and then typically
      > again after the "design phase". So the notion of "revisiting the
      > estimate" is not a new concept in even the most traditional of
      > organizations.

      That is just not true. Most companies do not review such things,
      especially not with contractors or other people over whom they can
      hold a sword. In far too many situations one's initial estimate is
      immediately taken as a promise. That is the primary reason why most
      projects come in neither on time nor on budget ... because the
      initial time and budget are taken as a promise.

      > What they're going to get now with Agile is a more frequent and
      > smaller review cycle and with each iteration gaining in accuracy
      > and precision. Finally, with all the benefits that come with
      > delivering releasable code in each iteration comes also the
      > ability to make enhanced decision on whether to stop investing, or
      > invest more based on real results.

      Yes, they are going to get that. That is why the OP's organization
      should negotiate NOW to get this customer on board with the Agile
      approach.

      Almost certainly the biggest single cause of trouble in Agile
      projects is that critical stakeholders are not on board with the
      incremental and iterative character of the project. Here we have
      someone with the foresight to get his customer aligned with Agile at
      the beginning. And you're trying to shame him out of it. I don't see
      the value of that.

      > Quite honestly, not only is the question "Inevitable" it is required.
      > We should stop shaming people for asking it.

      The demand "Give me a fixed bid for this project" is not a question.

      And just because someone even does a question does not mean that we
      need to answer it in its original form. We are free to interpret the
      initial question as the start of a conversation:

      Q: What's this bastard going to cost me?

      A: Well, no one really knows, or could know. We could do several
      things.

      Q: What could we do?

      A: Well, we could spend a lot of time and money coming up with a
      price that we were sure would cover whatever you might eventually
      want. We'd have to charge you for that study, and we would have to
      set the price higher than you might like, to cover unforeseen items.

      Q: That doesn't seem good for me.

      A: No, it isn't. Then you would negotiate us down and finally we
      would find ourselves in a situation where neither one of us was
      likely to be happy. But there are other options that are better for
      both of us.

      Q: Really? What are those?

      A: Well, for example ...


      And just one more editorial note. Please consider not describing
      what people are doing as "shaming" when it isn't. It interferes with
      understanding.

      Ron Jeffries
      www.XProgramming.com
      A lot of preconceptions can be dismissed when you actually
      try something out. -- Bruce Eckel
    • ceezone
      I agree with whatever you are saying Roy. But these are my observations/experience: 1. Most project managers have, heard of/Used (even if poorly)/considered,
      Message 38 of 38 , Sep 25, 2008
      • 0 Attachment
        I agree with whatever you are saying Roy.

        But these are my observations/experience:

        1. Most project managers have, heard of/Used (even if
        poorly)/considered, Function points.

        2. Very few have heard of Use case points.

        3. Almost no one has heard of COCOMO (shame)

        Someone somewhere (blast my memory) has made a very valid point about
        estimations showing a graph which corresponds to one of a the
        economics curve of law of diminishing marginal returns. This is a
        curve of estimation accuracy.vs.effort expended on arriving at the
        estimate. I think lot of organisation forget that!

        cheers
        Cheenie




        --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...>
        wrote:
        >
        > Wonderful!! Apply mathematics and metrics (COCOMO-II - because
        COCOMO-I was found to be deficient and in need of improvement) and
        Function Points, which look great because of the emphasis on metrics
        and measurement and historical 'facts' ... and THEN ADD SOME
        CONTINGENCY ... which clearly indicates that all those metrics and
        measurements and estimating methods don't work very well ... and ...
        ummm ... what is the measure of 'some' in that 'add some contingency'
        bit?I'm sorry to be appearing to ridicule your suggestion, H. but ...
        well, yes, I am ridiculing your suggestion.
        >
        > My advice to Simon would be to first ask the clients to give a full
        and accurate statement of requirements, and a clear contractual
        undertaking that if it is not stated in that specification, then it
        will not be included in the developed system. The client must provide
        that spec in sufficient detail for you to give an estimate of
        sufficient correctness. They surely are not so unreasonable as to ask
        you for accuracy without them also being accurate and correct and
        comprehensive.
        >
        > If the existing system can be seen as being exactly what they want,
        and so can be pointed to as the spec., then one may ask the question
        Why on earth are they asking for a rewrite?
        > An interesting fact that arose from my research (albeit a
        reasonably restricted research activity to admit to the facts) into
        software estimating. I researched amongst consulting firms and
        contracting firms that represented well over 50% of the local
        industry in my home city; not one of them used COCOMO of any vintage,
        and not one of them used Function Point Analysis, and many of the
        project managers had never heard of COCOMO or Function Points. Do I
        come from the real boondocks of software projects?
        >
        > Regards,
        > Roy Morien
        >
        >
        >
        > To: scrumdevelopment@...: hmeftah@...: Mon, 1 Sep 2008 09:16:55
        +0000Subject: [scrumdevelopment] Re: Help with The Inevitable Question
        >
        >
        >
        >
        > Hi Simon,Many of my clients ask the same question. How estimate
        revamping anexisting application.You have to start from concrete
        facts: 1) your current application even it's not perfect works every
        day. 2) Your application is based on VB code, therefore this code
        isthe latest version of your application documentation.3) You know
        all functions and methods, screens, data structure andso on.4) you
        may know how long a new feature took to be designeddeveloped and
        tested.For my point of view your project is quite large so you may
        need aproof of concept phase to estimate time and budget. I think
        your gradual revamping is a good approach, upon these 4 basicfacts
        above you can estimate and budget for example section X whichwill use
        that method, that class, this sort of data structure, thisdatabase
        access. Use "playing cards" Scrum phase to estimate our teamvelocity
        at day one.Then refine your figures by using COCOMOII analysis,
        function pointsestimate and add some contingency.Good luckH. Meftah
        >
        >
        >
        >
        >
        > _________________________________________________________________
        > Are you a friend magnet? Play now to win prizes for you and your
        friends!
        > http://clk.atdmt.com/GBL/go/106906016/direct/01/?
        href=http://www.friendmagnet.com.au
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.