It’s time for a little discussion about time! Well, actually about time and materials because when it comes to project pricing in software development, there are two main approaches: Fixed price and Time and Materials.
If we go over to Wikipedia , we will find out that “a fixed-price contract is a type of contract where the payment amount does not depend on resources used or time expended” and it is similar to many of our dealings in the day to day life when we buy something – it is clear what we want, it is clear what we are buying and the price is also known upfront.
This approach works well for consecutive projects that are very similar to each other, are clearly defined by the customer and the supplier did the same kind of project over and over again. That means fixed prices contracts are suitable for, let’s say, installing a pool in your backyard – the scope of the project and the customer’s expectations are clear, hopefully the supplier did the same kind of work several times before, so the supplier knows how long it will take and how much it will cost to fulfill the order.
That also means that fixed price does not work that well in software development. Why? Because software development can be unpredictable. Most of the times, you know the deliverables (although these can change and sometimes it can be beneficial for the customer to be changed from a business point of view) but the path to those deliverables is not a clear path and software development is more of a exploratory work than a clear–cut one.
In a Time and Materials contract (thanks once again to Wikipedia ) “the employer agrees to pay the contractor based upon the time spent by the contractor’s employees and subcontractors employees to perform the work, and for materials used in the construction (plus the contractor’s mark up), no matter how much work is required to complete construction.”
This does not mean that estimates should not be given and it also does not mean that the development company can just keep on billing endlessly without delivering a product. That is why it is a good idea to combine this approach with Agile practices because after each iteration working software can be delivered to the customer.
The relationship will be a flexible one: if the customer will want to change the scope or add new features, the contractor will be happy to oblige. In a fixed price contract scope creep (the customer adding requirements along the way) is one of the concerns for the development company and can lead to a tensed relationship between customer and developer.
Both approaches have their strengths and weaknesses – the fixed price contracts may look more appealing to the customer, because it seems that the risk and the budget is known upfront, but the customer must not forget that in order to have a fixed price contract work out fine, the customer should invest time even before starting the project in order to exhaustively define requirements and expectations. Also, sometimes correctly estimating a large software project is something nearly impossible and you can have a look at some of the big failed projects here .
The bottom line is this: in software development, the vast majority of projects cannot be clearly defined to the smallest detail upfront and that means a fixed price contract will be nothing more than a coin flip when it takes to taking the risks and the potential losses – both the customer and the developer will hope they get lucky and that just does not sound to me like good business practices.