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

RE: [XP] consultant fees for an xp shop?

Expand Messages
  • Kent Beck
    Dear James, Hourly rates are a simple, accountable, and well-understood way of charging for XP-related services. I am generally satisfied with the results when
    Message 1 of 40 , Dec 6, 2007
      Dear James,

      Hourly rates are a simple, accountable, and well-understood way of charging
      for XP-related services. I am generally satisfied with the results when I
      use them. However, they don't fully align the client's and consultant's
      interest so I try to apply the principle of mutual benefit to pricing.

      For example, I have been asked to quote TDD training for a large company. I
      could just figure out how much I wanted to charge per day. Slightly more
      accountable would be charging per student with a maximum class size. The
      fully accountable pricing scheme is to defer my fee until a few months
      later, interview the students from the class, and only charge for those
      using TDD or using TDD better as a result of the class. The fee per student
      in this case would be several times higher than the fee per student in the
      class. If the training is effective from the client's perspective they pay
      more, but they don't mind so much because they know they have received
      value. The big sticking point in this case is whether I have the courage to
      believe that students can learn and apply lessons learned in my classes. I
      have used the same principle to defer part of my fees until the on-time
      delivery of software.

      Charging per feature seems like a step in the direction of mutual benefit.
      The client doesn't actually want the consultant spending time, the client
      wants features (that will result in business benefit). Charging per feature
      shifts some of the risk of under-estimation onto the consultant, which can
      be a relationship building move. If the consultant is justifiably confident
      in his estimates, it can also be a way to improve margins.


      Kent Beck
      Three Rivers Institute

      -----Original Message-----
      From: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com] On Behalf Of James Carr
      Sent: Saturday, December 01, 2007 4:48 PM
      To: extremeprogramming@yahoogroups.com
      Subject: [XP] consultant fees for an xp shop?

      hi all,

      I have friend running his own consulting company who is thinking about
      giving xp a try since they are almost doing it naturally. they code in
      pairs, do tdd, and their customers come in on site a few times a week.

      his question he has for me is that they've been doing hourly rates, but he
      wonders if there is a charging system that fits more with xp.

      my suggestion is to maybe charge for each feature, maybe put a price on each
      uniţwhich would give clients a realistic choice because each feature would
      have a cost attached.

      anyhow, I am assuming there are several consultants lurking on this list, so
      what kind of pricing system do you guys use?


      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:

      ad-free courtesy of objectmentor.com
      Yahoo! Groups Links
    • Peter Bell
      Hi Kent, Strictly speaking, none of our clients fit into a pure product model as we specialize in ³quickly customized² apps, so even our simple clients need
      Message 40 of 40 , Dec 17, 2007
        Hi Kent,

        Strictly speaking, none of our clients fit into a pure product model as we
        specialize in ³quickly customized² apps, so even our simple clients need
        custom screens, maybe a unique authentication method, their own business
        objects, custom validation rules and workflows and the like. However we have
        a collection of DSLs for generating such solutions, so we can produce such
        ³custom² apps pretty quickly.

        The issue is that because our development times are so fast, the vast
        majority of our cost for a feature point is how long we spend discussing it,
        revising it (changing colors, tweaking layouts, adding dark matter that
        wasn¹t originally specified) and the like. For example, I might be able to
        generate most feature points in 1-2 hours whereas if I was hand coding them
        it might take 15-25 hours. If the client is happy with my first cut I¹m
        done. If they are really picky I might spend 10-12 hours going back and
        forth discussing it, answering lots of questions, making tweaks, etc. That
        means for those clients, feature points cost me maybe 8x what they do for a
        less picky client. I find about 1 client in 8 is very picky. My challenge is
        to be able to provide fixed bids while still avoiding losing money hand over
        fist 1 time out of 8.

        The way I usually explain this is that when dealing with small businesses,
        most clients only care about 10% of the app. They might ask about the
        checkout flow but not care about how authentication works. They might care
        about the admin screens but not about the calendar layout. It¹s a different
        10% for each client, but most clients focus on a small subset of possible
        design decisions. About 1 client in 8 wants to go through every single
        decision in excruciating detail. They want to understand why you can¹t email
        a password to users (because it is hashed in the db), they want to customize
        how the list paging in the admin works, they want to change the checkout
        flow, they want to tweak every possible element of every screen and action.
        If we were to bid our projects based on that, we¹d have to charge about 7
        times what we do which would make us uneconomic for our clients (including
        for the ones who want to ask all the questions). What we¹re trying to do is
        to figure out how to handle that 1 client in 8 as I respect their interest
        in every detail of the solution, but can¹t afford to include that level of
        hand holding within our fixed bids.

        And that is where the idea of the blended solution comes in:

        The idea is that we¹d charge fixed bid for building a feature point within
        spec but then hourly for tweaks, hand holding, discussions and the like.
        That way we¹d be incented to build the code efficiently and the client would
        be incented to respect our time when asking questions as they¹d know each
        question and tweak was on the clock . . .

        Make sense? And (more importantly), any ideas?!

        Best Wishes,

        On 12/17/07 11:56 AM, "Kent Beck" <kentb@...> wrote:

        > Dear Simon,
        > Michael Cusumano's book "The Business of Software" talks about how all
        > software business end up as a mix of product and service revenue (with
        > Microsoft and Adobe as rare counterexamples). The book also describes how
        > the transitions between business models is often difficult. It sounds to me
        > like this describes your situation. You had a pure service business. Then
        > you extracted enough frameworks to have basically a product business with a
        > little customization. Now you have some customers who don't fit into a
        > product business but you don't want to just ignore them. Is that a fair
        > summary?
        > Regards,
        > Kent Beck
        > Three Rivers Institute
        > _____
        > From: extremeprogramming@yahoogroups.com
        > <mailto:extremeprogramming%40yahoogroups.com>
        > [mailto:extremeprogramming@yahoogroups.com
        > <mailto:extremeprogramming%40yahoogroups.com> ] On Behalf Of Peter Bell
        > Sent: Thursday, December 13, 2007 1:57 AM
        > To: extremeprogramming@yahoogroups.com
        > <mailto:extremeprogramming%40yahoogroups.com>
        > Subject: Re: [XP] Re: consultant fees for an xp shop?
        > On 12/13/07 4:35 AM, "Simon Jones" <simon@tcbventures.
        > <mailto:simon%40tcbventures.com> com> wrote:
        >> >
        >> > Just an observation. Some of what you are describing seems to be
        >> > related to a charging model for a /product/. This is very difference
        >> > I would suggest, from a services model and I'm not sure this related
        >> > to the price-per-feature being discussed (although I may be wrong).
        >> >
        >> > Froma services pov, I still have a problem with pbf. Namely, despite
        >> > the small size of features this is still essentially fixed-price. To
        >> > my mind this creates a conflict of interest.
        >> >
        > Hi Simon,
        > Good question. Actually while we use a software product line, and many
        > elements of what we do are productized, we specialize in apps which require
        > a mix of re-use and custom requirements. Because of that we have stories
        > which we just pick out of a library and (other than
        > customization/communication time) are pure profit, but the vast majority of
        > the problems (and the relevance to this debate) are the completely custom
        > stories.
        > We¹ve got pretty good tooling for rapidly creating custom stories as well,
        > but we find that for custom stories (which is what most consultants are
        > working on), the communication problems are much greater because of our lack
        > of domain knowledge. If you want to talk about relating articles to pages in
        > a cms, you¹re unlikely to surprise me, but if we¹re working on a database to
        > track spread of infectious diseases in sub-Saharan Africa, there are likely
        > to be many more tweaks, much more dark matter and much more client
        > collaboration all of which make it much harder to provide an accurate fixed
        > bid precisely because of the conflict of interest you¹re alluding to ­ once
        > the price is fixed, it is in our interest to complete the feature in the
        > minimum amount of time (tempered only by our professionalism) and it is in
        > the clients interest to keep iterating (for free) until it is absolutely and
        > exactly how they¹d like it to be (tempered only by their willingness to
        > invest in a mutually beneficial client:vendor relationship).
        > I have had plenty of good experiences with fixed bid. It helps if the client
        > is either reasonable or is too busy to argue. It helps when the client is on
        > a tight deadline, and it helps if there is a high-trust, non-adversarial
        > working relationship. The problems we have is that we often work through
        > resellers, so we don¹t get to pick our clients and we fixed bid new client
        > relationships and sometimes we just get picky clients who want to spend a
        > lot of time discussing, revising and reviewing every single element of the
        > app. Nothing wrong with that, but it¹s not consistent with the pricing that
        > we offer and wouldn¹t be a fair price for the vast majority of clients who
        > don¹t need so much hand holding.
        > We¹re looking seriously at moving towards a blended model. We¹ll fixed bid
        > the features and guarantee only to deliver something that meets the story
        > spec. We¹ll then charge hourly for discussions, additions, revisions,
        > training and support. In that way we take the risk in the software
        > development and are incented to be efficient at that, and they take the risk
        > in terms of the revisions and support and are incented to respect our time
        > during the ³tweaking² phase. Our guidance would be for the clients to
        > estimate 20-40% in addition to the fixed bids to complete the stories to
        > their satisfaction, with the larger percentage reserved for stories with
        > greater risk features but that don¹t require their own formal discovery
        > phase.
        > Best Wishes,
        > Peter
        > [Non-text portions of this message have been removed]
        > [Non-text portions of this message have been removed]

        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.