In my previous fixed price article I looked at why fixed price is not only bad for suppliers but also for clients. I also argued that contrary to popular belief using big design up front methodologies will not solve these problems. Fixed price is difficult no matter what methodology you use. In this article I want to look at why fixed price is still popular with many clients. Then we'll look at what we need to do to be a bit more successful at fixed price and how agile methodologies can help us do this.
To look at why fixed price is popular with clients I'll start with a comment I got on my previous article. Sergey Pyatigorsckiy commented "As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it's spending money, at worst - wasting money. That is why real huge governmental projects are fixed priced: Nobody really cares."
I tend to agree to some extent. Clients often don't care about the project, they often just want the software and be done with it and for them the easiest way to get this is fixed price. So fixed price projects and clients that don't care seem to go together. In most cases clients do care about the outcome of the project. Clients have a problem they want to see solved. Or, more cynical, in larger organizations, clients want a big successful project to show their manager. Often clients don't realize that in order to improve chances of a successful outcome they should care about the project. Most clients have experience with processes like buying a new car, they specify what they want, recieve a time and cost estimate, wait a few days and get their car. Why should software be any different?
Bookmark/Search this post with:
In his excellent article 10 Contracts for your next Agile Software Project, Peter Stevens
described 10 different contracts that are often used in software development projects. At the end of his article he singles out one contract-type:
"Fixed price projects and agile development are considered not to mix. I know from experience that this is not strictly true. I am also convinced that other forms are better."
I completely agree with him on this but since fixed price contracts are so common in software development it seems like a good idea to look at them a bit more carefully. In this article I want to look the problems with fixed price and why traditional software engineering methodologies are unable to solve these problems. In my next article I want to continue on a more positive note and show how agile practices will help you make the most of fixed price.
Bookmark/Search this post with: