[consulting] Why fixed rate "budgets" are a waste of time for everyone (was REVISED RFP FOR DRUPAL DEVELOPER)

[António P. P. Almeida]

On 11 Nov 2010 21h50 WET, victorkane at gmail.com wrote:

> Excellent discussion!
>
> Fixed rate budgets are a waste of time for everyone first and
> foremost because they posit the waterfall approach to software
> development; the requirements are thought of as a fixed abstract
> continent, and the analysis of those requirements are supposed to be
> done on the quick (and for free) by the candidate consultant. When
> the truth of the matter is:
>
> * Requirements will change at a minimum of 40% during the
>   development of the
> web app, as complexities emerge and are dealt with and what is built firms
> up how to implement the business model.
> * The adquisition of knowledge of estimatation in best done in the analysis
> and design phase, which in turn is best done in an agile, user story (bit
> sized self-contained) iterative and incremental manner; so it is revealed
> bit by bit. However, total accountancy and transparency is provided by the
> client participating in this process by writing acceptance tests for a
> single user story as the analysis and design and implementation goes
> forward.
> * Analysis and design of ALL the project is ridiculous because of the 40%
> reqs chagne and because the proof is in the pudding (delivery) not in
> anyone's head.
> * As more and more of the backlog is delivered and is staged, the candidate
> architecture firms up, risks are dealt with up front, change requests form
> part of the backlog, and the client learns more and more about what she or
> he really wants.
>
> If the client is misled towards thinking that developers "who really
> know what they are doing" can give a "good estimate" then they are
> at best exaggerating the power of an RFP... it cannot, in the
> Chomskian sense, be explicit. It cannot be an explicit description
> of the project. The only explicit description of the project is the
> series of acceptance tests which are passed as part of the
> incremental and iterative development and continuouos build. The
> economist.com process (thin slices continuously built), recently
> presented at some conference or other, I think is the best
> exemplification of what can really work. Well.
>
> Then, the team with time (if it is not ridiculously and continously
> broken up just when it's getting good) can cultivate a productivity
> with their synergy, and estimates begin to make more and more sense.
>
> Hope that helps towards what you were asking,
>
I agree and it reminds of something I heard from Jason Fried of
37Signals fame. It goes like this:

"If the client wants you to be strict on the budget and/or timeline,
be flexible on the features you built."

Nothing wrong per se with fixed budgets, it boils down to the frame
of reference you setup in your relationship with the client.

Something has to give in. Waterfall development methods are so 20th
century. I'm in the process of firing a client that insists in that
methodology. Furthermore they seem to be the ones that are more
demanding of you while also being the ones that are willing to pay
less.

--- appa