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

consultant fees for an xp shop?

Expand Messages
  • James Carr
    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,
    Message 1 of 40 , Dec 1, 2007
    View Source
    • 0 Attachment
      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?

      thanks,
      james
    • 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
      View Source
      • 0 Attachment
        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:
        http://www.pbell.com/index.cfm/2007/12/13/Managing-Risk-in-Website-Developme
        nt

        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,
        Peter

        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.