In most businesses, the customer has a pretty good idea what they’re getting and how much it will cost. This allows the individual to value the product versus the cost and make a rational decision about whether or not to go forward with the purchase. This system makes sense and has been at work sense the dawn of markets.
When it comes to custom application development, however, there is a different approach. This approach entails getting an estimate of both the cost of the application as well as when it will be finished from the developer. If the delivery deadline is missed (as it usually is) the developer makes up for it by charging you more than originally estimated. How does this make sense? I’m getting what you promised me late, but at least I get to pay more for it?
This time and materials approach may have worked in the past, but customers have too many other options and are rightfully starting to demand accountability from their vendors. Customers should expect to pay what they are quoted and fixed-cost budgets should become the standard. Fixed-cost budgets have three main advantages over the traditional time and materials model:
- Provides Alignment – With the time and materials model the goals of customer and developer diametrically opposed. The customer wants a solution quickly and affordably, while the developer is rewarded by delivering slowly and thus charging more. Fixed-cost aligns the interests of both parties.
- Provides Accountability – Customers should be able to rely on the estimates they receive. With a fixed-cost budget the vendor is forced to be accountable for bad estimates or self-imposed delays. The solution may still be delivered late, but it will be the vendor, not the customer, who is footing the bill for the delay.
- Simplifies Budgeting – With a fixed-cost budget both parties know exactly what to expect when a project begins. The customer can budget the project feeling confident that the costs won’t balloon at a later date and the vendor won’t try to lowball the initial bid and raise the price later. Everybody wins.
Obviously all development projects can change and significant changes in scope can require a budget to be updated. This should be reasonable to both parties, however, as the estimates the budget was based on have shifted. However, this should be the exception and not the rule. If the product being delivered is not significantly altered from the original agreement then the customer should demand that the price should not change. Not only will this provide the benefits I listed above, but it will also dramatically improve the customer-developer relationship which everybody should look forward to.