Fixed Price Contracts that change
With our customers the most used form of contract is the fixed price, only a few customers with whom we have a good old friendship accept other formats of contract.
But I don’t want to talk about the pros&cons of a fixed price contract, everyone who works in the business of software know how bad it is not only for the developer company but also for the customers.
But what happens most of the times?
What I see is that we always start with a fixed price contract in which we put all the functionalities that the application must have and we try to estimate the costs and time needed for the development.
If the project starts we try to be agile, so we try to deliver as soon as possible a small functionality to our customers so that they can begin to try it and to evaluate.
What happens here is a curious thing: the customer sees the prototype of the program and even if it is only a small part of the requested product usually he begin to ask for modifications or for a new functionality.
In these contexts, the customer, having a fixed-price contract should accept an addendum to the initial contract that adds the requested modification and/or the new functionalities.
So we abandon the original contract to follow the new addendum with a small set of functionality that we can precisely estimate.
This happens on every small release and so we move from a big-fixed-size contract to a collection of small-fixed-size contracts that are easier to estimate and certainly more manageable.
It seems like the customer unconsciously understand that the fixed size doesn’t work.
This gives us another important effect: in fixed sized contracts, sometimes happens that the customer thinks that every extra request is included in the contract, so he starts to ask for new features. The problem is not only that we have to work more for the same price, is that the customer does not give the right value to his requests: when something is free, you get it even if you don’t need it.
So splitting the contract in small parts, and evaluate every single part gives to the customer the right value for every feature, so he can decide if what he ask for is really needed.
RSS


