Rails - Sep 2005 - [OT] Pricing/estimating of agile projects

This might be a bit off topic, but since Rails has such a strong
relationship to agile software development, I think many of you can
relate to this question.

How do you price your projects? If I take the Depot application (from
the book) as an example, the initial customer request was basically
for an online store, with some simple use cases defined in section
5.2.

For me at least, it would be very difficult to provide a correct
estimate from this information, so I would try to get the client to
just pay me my hourly fee for the amount of work done. However, a lot
of clients don''t feel comfortable with this arrangement. They
basically want a fixed price so that they know in advance how much the
project is going to cost them. Hey, I can understand that. But for me,
that doesn''t quite work with the highly agile, iterative development
that I like to do.

How do you handle this?

Best regards,

Carl-Johan Kihlbom

> How do you handle this?
Fixed budget. Fixed scope. Fixed timeframe.

Pick two.

Best regards,
Tomas

If the client wants to fix the price then you have to fix your costs, 
which really means fixing your time (assuming you are working alone), 
which means, if you and the client are not sure how it is going to go 
you will need to vary the scope.

Try some of the agile mailing lists.  Its a popular topic.

Tom

Carl-Johan Kihlbom wrote:
>This might be a bit off topic, but since Rails has such a strong
>relationship to agile software development, I think many of you can
>relate to this question.
>
>How do you price your projects? If I take the Depot application (from
>the book) as an example, the initial customer request was basically
>for an online store, with some simple use cases defined in section
>5.2.
>
>For me at least, it would be very difficult to provide a correct
>estimate from this information, so I would try to get the client to
>just pay me my hourly fee for the amount of work done. However, a lot
>of clients don''t feel comfortable with this arrangement. They
>basically want a fixed price so that they know in advance how much the
>project is going to cost them. Hey, I can understand that. But for me,
>that doesn''t quite work with the highly agile, iterative
development
>that I like to do.
>
>How do you handle this?
>
>Best regards,
>
>Carl-Johan Kihlbom
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>  
>

Fixed budgets are great! They tell you when you''re done (i.e.
there''s
no more money).

What you need to do is evaluate their vision for the project (build an
online shop) and make up with yourself whether some reasonable version
of that vision would be realistic for the funds available. You don''t
have to be in complete agreement with the client at this stage what
that might be.

Then you start up the show with a handful of stories to cover the
first week or two of the development, then show the progress to the
client, and tell them how much of the budget was spent doing that. Now
they can form their own prioritization based on the velocity
exhibited, the stories they want done, and the budget they have.

To make this work you need trust. There''s no better way to build trust
in software development than by showing working, valuable software.
Thankfully, you''re in an environment that makes that task a whole lot
less expensive than it used to be.
-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

BTW, if your clients are not buying that suggestion, show them
http://www.joelonsoftware.com/articles/PickingShipDate.html and
substitute "ship date" with budget and follow a similar scheme.
-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

With all due respect to the "Agilists" on this list, certain projects 
are small enough to lend themselves to an agile approach and certain 
projects aren''t. Certain customers are willing to participate in an 
agile project and certain customers aren''t.

Software project management in particular and project management in 
general have been around a **long** time. I''ve been a programmer for 43
years, and I can tell you that the languages change, the people change, 
the processes change, the computers get cheaper and more powerful. But 
IMHO the only *major* improvement to software development in the time 
I''ve been programming has been *version control*.

I can''t recall exactly when that happened; maybe some of the other 
old-timers on this list can tell me. The first such tool I can remember 
is SCCS, which I think came out of the same Bell Labs group that did 
UNIX, and not too long after UNIX or even at the same time.

How do you price a project? That''s really more a sales and marketing 
question than it is a technical one. In other words, you want to get the 
maximum amount of money for your time and the customer wants the best 
possible software in the shortest possible time for the least amount of 
money. The key idea here is that this is a human-human communication 
*about* time, money, products and services. And the key rule is "Win-win 
or don''t play!"

Be willing to walk away if you''re not going to get paid what
you''re
worth. There are plenty of opportunities out there, even if you limit 
yourself to what Rails can do and "agile" projects, not
"programming in
general". As far as sales and marketing are concerned, I highly 
recommend the books, tapes, and web site of Sharon Drew Morgen. Try

http://newsalesparadigm.com/

Carl-Johan Kihlbom wrote:
>This might be a bit off topic, but since Rails has such a strong
>relationship to agile software development, I think many of you can
>relate to this question.
>
>How do you price your projects? If I take the Depot application (from
>the book) as an example, the initial customer request was basically
>for an online store, with some simple use cases defined in section
>5.2.
>
>For me at least, it would be very difficult to provide a correct
>estimate from this information, so I would try to get the client to
>just pay me my hourly fee for the amount of work done. However, a lot
>of clients don''t feel comfortable with this arrangement. They
>basically want a fixed price so that they know in advance how much the
>project is going to cost them. Hey, I can understand that. But for me,
>that doesn''t quite work with the highly agile, iterative
development
>that I like to do.
>
>How do you handle this?
>
>Best regards,
>
>Carl-Johan Kihlbom
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>
>  
>
-- 
M. Edward (Ed) Borasky

http://www.borasky-research.net/
http://borasky-research.blogspot.com/

http://pdxneurosemantics.com
http://pdx-sales-coach.com
http://algocompsynth.com

On 17 Sep 2005, at 12:09 pm, Carl-Johan Kihlbom wrote:
> How do you price your projects? If I take the Depot application (from
> the book) as an example, the initial customer request was basically
> for an online store, with some simple use cases defined in section
> 5.2.
>
> For me at least, it would be very difficult to provide a correct
> estimate from this information, so I would try to get the client to
> just pay me my hourly fee for the amount of work done. However, a lot
> of clients don''t feel comfortable with this arrangement. They
> basically want a fixed price so that they know in advance how much the
> project is going to cost them. Hey, I can understand that. But for me,
> that doesn''t quite work with the highly agile, iterative
development
> that I like to do.
Ideally, you''d have a client who''s happy to just pay the
hourly rate,
and who understands the idea of iterative development and evolving  
estimates. This is great when it happens, but most clients seem to  
like a bit more certainty in their lives, which means something  
closer to providing a fixed quote.

We use an approach that essentially wraps up agile methods and rapid  
prototyping inside a more traditional "design than implement"  
schedule. We use iterative development day-to-day to give clients the  
''wow'' factor of having software in their hands very quickly,
and to
rapidly refine the details of the design. But we discuss and decide  
on the vision and broad scope of the project up-front, and clients  
seem to like this because it gives them something firm to grasp on to  
at the beginning.

As far as quoting a price goes, we don''t quote a price for the full  
project up-front. Instead, once we understand the overall vision for  
the project, we quote a price for a ''consultation stage''. This
is
where we flesh out the detailed scope and the broad design, by doing  
a few iterations to figure out how the system is going to hang  
together, and what the system is and isn''t going to do.

Then we quote a fee for the remainder of the project, specifying on  
paper all those decisions that the client''s made about the scope of  
the system. During this final stage, we get into agile development  
proper. It''s here that we figure out all the little details of design.

We find that this approach lets us exploit the key benefits of  
agility in the actual software development, while keeping just enough  
documentation, scheduling and fixed-fee quoting to make the clients  
feel secure and able to make good, accountable business decisions.

Chris

Although I haven''t drunk most of the Agile method kool-aid, I generally
use a prototyping, high-feedback form of development.  Even when I''m
not
using that method, however, I find that estimating development
time is fraught with peril.

So, I try to level with the client, saying:

   I''m much better at developing than I am at estimating.  In three
   decades of programming, I''ve learned that many of the real issues
   arise when I start coding.  I''ve also learned from experts such
   as John Mashey, that I''m not alone in this.  So, I''d prefer
not
   to give an estimate at all, let alone a binding one.

   However, I understand that you need a way to track and control the
   development costs.  My suggestion is that I report to you on at
   least a weekly basis, saying what I''ve done, what I plan to do, etc.
   That way, you can pull the plug with little loss if we don''t appear
   to be making good progress.

Generally, this works.  If it does not, I try estimating, but do the
reporting anyway...

-r

P.S.  John Mashey is a _real_ Unix old-timer, as describes in Wikipedia:

         http://en.wikipedia.org/wiki/John_Mashey

       He has given several classic talks on related topics, but I''ve
       not been able to find printed versions.  Here, at least, is a
       summary of one talk:

 
http://www.usenix.net/publications/library/proceedings/bsdcon02/confrpts.pdf
-- 
email: rdm-go8te9J4rpw@public.gmane.org; phone: +1 650-873-7841
http://www.cfcl.com        - Canta Forda Computer Laboratory
http://www.cfcl.com/Meta   - The FreeBSD Browser, Meta Project, etc.