Kyle Cordes

In any development project, there are well-known risks:

• Risk that the scope will be underestimated at the start
• Risk that the scope will increase over time (not always a bad thing - often a client discovers that additional functionality would deliver additional business value)
• Risk that the development firm will be unable to deliver any working solution at all
• Risk that the project will take more time than anticipated
• Risk that the project will take less time than anticipated

In a time-and-materials pricing model, the client takes most of the risk, and this is generally justified because the client will receive most of the benefits of a successful project. Many development firms (including many very good ones) only offer time-and-materials pricing.

They do this because of the problems with the other extreme – fixed-price contracts in which an attempt is made to fully describe the software project in advance, then specify a fixed price to build it. In this model, the
development firm takes most of the risk, with some unfortunate side effects:

1. The development firm is strongly motivated to interpret software requirement as narrowly as possible, rather than in a way which maximizes the business value of the software.
2. The development firm and its client can end up in an adversarial relationship.
3. Arriving at a project specification and price can be very expensive and time consuming, so much so that this model is often infeasible.
4. It can result in an overly conservative approach to software development, estimation, and design. The client might be quoted a price which covers the highest amount of time than anyone can imagine the project taking, when then becomes a self-fulfilling prophecy.

However, a key merit in the development firm taking on some of the risk, is that the development firm is in a position to affect the outcome. This suggests a compromise.

A compromise between these two extremes is referred to here as Shared-Risk Pricing. It works like so: a basic set of core software requirement is developed for a fixed price, then the remainer of the project is billed on a time-and-materials basis. That core set of requirement is intended to approximate the minimum feature set the software must have to be useful, while encompassing the efforts needed to set up development environments, ensure familiarity with tools, and develop the key parts of the software.

If you found this post useful, please link to it from your web site, mention it online, mention it to a colleague, or invite Kyle to speak at your next event.