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

57310Re: [scrumdevelopment] RE: How to perform estimation for custom (billable) work

Expand Messages
  • Kurt Häusler
    Oct 18, 2013
    • 0 Attachment
      Yep your current process is dripping with dysfunction.

      But assuming your customers, sales, middle management and VP recognize
      that, and are open to alternatives then the battle is practically won!
      The ideas are out there, it is just that they hardly ever get used
      because things kind of fall apart at the convincing others that there
      is even a problem bit.

      Try the price per PBI model and see how it goes.

      On Wed, Oct 16, 2013 at 5:17 PM, <vilson_a@...> wrote:
      >
      >
      > Thanks for all the replies so far.
      >
      >
      >
      > I guess I should add a little more context to my original post.
      >
      > We currently have 3 teams, and all teams work on a mix of roadmap and custom
      > (billable) work, when the custom work is needed/required to be done.
      >
      >
      >
      > To my original post, where I state “estimation to price the project is
      > currently done in hours”, that part is done by Sales/Middle Management (most
      > of the time based on similar projects done in the past), this is way before
      > it gets to the development teams.
      >
      >
      > Once a project gets assigned to a team, the team will break it down into
      > user stories and estimate them using Fibonacci.
      >
      >
      >
      > To explain the process a little bit further:
      >
      > All the way up top, during the “contract” estimation, the VP and other
      > managers, will set a delivery date, and to do that they usually calculate
      > how many hours the project was estimated (contracted) at, and then, based on
      > the number of dev hours available, etc… give the client a fixed date.
      > Once the project is estimated by the team (in points), and a release plan is
      > done, they are realizing that the original (hours) estimate done by
      > Management is not corresponding to the estimation (points) done by the Team,
      > and then they are realizing that they over committed.
      >
      >
      >
      > Since Q4 was the first quarter they have ever been able to have everything
      > estimated ahead of time, it was a big surprise for them to “see” (ahead of
      > time – and not at the last 2 weeks) that they over-estimated, and the team
      > will not be able to complete all work that was “promised” by management
      > without some “creative planning”.
      >
      >
      >
      > One solution that is floating around is to have a separate team to do all
      > custom work, and they would not estimate in points. Which I honestly think
      > will not solve any problem.
      >
      >
      >
      > Thanks again!
      >
      > Alex Pereira
      >
      > www.brainstack.net
      >
      >
      >
      >
      >
      >
      >
      > ---In scrumdevelopment@yahoogroups.com, <adam.sroka@...> wrote:
      >
      > Excellent advice.
      >
      > I would add that even if you do decide to do fixed price/scope still run it
      > iteratively and get frequent feedback. That way you don't head down the
      > wrong path. Also, if you are running late it's not a surprise and you can
      > negotiate changes early.
      >
      > Vet your customers carefully to make sure that they can provide the inputs
      > and frequent feedback needed to run a successful Agile team. Don't chase bad
      > money. The reputation of your team is more valuable than the revenue from a
      > doomed project.
      >
      >
      > On Wed, Oct 16, 2013 at 10:53 AM, Vikrama Dhiman <vickydhiman@...> wrote:
      >
      >
      > Hi Alex:
      >
      > I wrote about it several years ago. I think some if not all is still
      > relevant. Here are some thumb rules (first 2 are sort of preachy - so skip
      > to 4th for direct points);
      >
      > 1. If you do want to do fixed price, you want to do it for less scope and
      > not more (as it minimizes the risk).
      > 2. There is some literature on 1/3rd - 2/3rd contracts and some very little
      > one on PS2000 contracts - dig into those.
      > 3. What starts as a custom fixed price billable project does not need to be
      > so eventually too. You can easily convert a fixed-price to a more manageable
      > time and material provided you show evidence of collaboration and business
      > value delivery early on. So, get the project in how-so-ever you do it right
      > now and then hopefully convert it later.
      > 4. Here is another technique which I have seen people use - float a RFP
      > similar to work you would do and get 3-4 quotes yourself under a pseudo-name
      > or something. Give you an idea of how much you should 'actually' bill. You
      > could bill more if you have good presales team, domain expertise, proven
      > record.
      >
      > Check more at http://agilediary.wordpress.com/category/contracts/
      >
      > Good luck.
      >
      > -Vikrama Dhiman
      >
      >
      > ________________________________
      > From: Adam Sroka <adam.sroka@...>
      >
      > To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      > Sent: Wednesday, October 16, 2013 8:07 PM
      > Subject: Re: [scrumdevelopment] How to perform estimation for custom
      > (billable) work
      >
      >
      > The best way to do it is optional scope. Deliver something every sprint.
      > When your customer is happy with what you have delivered they can quit. You
      > should know what it costs to run the team for a sprint. Add your margin to
      > that and you know what you have to charge (To mitigate risk maybe negotiate
      > for a minimum number of sprints and/or add additional margin to cover
      > downtime between projects.)
      >
      > If you need to calculate how many sprints it will take to complete some
      > quantity of work, and you haven't had time to establish a velocity yet, the
      > most realistic way to accomplish that is to look at how long it took you to
      > develop products in the past. Come up with a range based on past performance
      > and assume that it will take similar effort this time.
      >
      > That may seem like an oversimplification, but it has the advantage of being
      > based on something you know. It blows my mind that people think a bunch of
      > small guesses added together are somehow more efficacious than one big
      > guess. At least with the big guess you still have your eye on the ball and
      > aren't bogged down in minutiae.
      >
      >
      > On Thu, Oct 10, 2013 at 4:24 PM, <vilson_a@...> wrote:
      >
      >
      > Hello everyone,
      >
      > I was wondering if you guys could help me out with this problem. Although I
      > have worked in an Agile environment before, even as an Scrum Master, this is
      > actually the first time I’m working in a company (currently implementing
      > Agile) that does custom (billable) work.
      > I am sure most of you have had the opportunity to deal with this situation,
      > and I was wondering how you have worked it out.
      >
      > Estimation to price the “project” is currently done in hours, and of course
      > it is a completely unrealistic number. Since I have been a Scrum master
      > before, I am trying to help the Dev Manager figure this out.
      >
      > Just to clarify, for regular product roadmap items we do estimate in points
      > (Fibonacci).
      >
      > Please let me know if any more detail is required.
      >
      > Thanks!
      > Alex Pereira
      > www.brainstack.net
      >
      >
      >
      >
      >
      >
      >
      >
      >
    • Show all 17 messages in this topic