Fixed Price Quotes in Software Development

Fixed price projects in software development can lead to difficulties if not managed well, but may be requested for a variety of budgetary reasons. Problems can arise because software is more often than not likely to change or evolve during the development process, but fixed price places strict time limits on any deviation from the original plan and quote.

The main reasons for time increases on a project are:

• The customer doesn't know exactly what they want and requests happen after the quote is given.
• The developer doesn't know exactly what the customer wants or wasn't given all information, so couldn't quote accurately.
• The customer adopts an ad-hoc request approach, requesting changes after the project has started. This can often be because they only see the full picture during the development process or gain ideas at that stage. This is similar to having a house built in that when the visuals are in place, it's easy to imagine or evolve ideas.
• Other things might change such as the customer's priorities, with perhaps certain areas deemed more important than others, or new requirements that come along.

Ad-hoc behaviours are acceptable for all but fixed-priced projects. Fixed-price projects require a firm plan, and without it, accurate quotes are impossible. The customer needs to approach the project with a firm understanding of what they want. Changes or U-turns during development will quickly use up unquoted development time and either lead to compromise elsewhere or an increased customer bill.

If a fixed price has been supplied without a detailed plan it usually means one of two things (and that someone is going to lose out):

1. The quote is high in an attempt to cover all eventualities. The software developer can win or lose here - it's a gamble without exact knowledge of the project.
2. The quote is low but the customer expects all their requests to be fulfilled because they're paying a sum of money that they feel should cover anything that crops up. The customer can win but it's an unrealistic business expectation when paying for someone's time.

For a satisfactory outcome for both parties using the above approaches requires luck. As a software development business and in the interests of fairness, we don't like to rely on luck. We'd rather not bill for something that might happen and prefer to be transparent throughout. I believe fixed price projects should be fair for all involved, with both parties having realistic expectations.

Plan/Specification

For fixed-price projects, a plan/specification is essential if the customer wants to get value for money. It ensures both parties know exactly what is going to happen and what's included in the cost, with nothing or little left open to interpretation. This ensures developer time is well-utilised because it prevents going around in circles and maintains continuity. With a good plan, time scales and quotes can be more exact, with any small timescale fluctuations generally being absorbed.

A good specification requires thorough thought on exactly how the software will operate at the outset, before any development work has started. All functionality, eventualities and outcomes need to be considered. This can be difficult to do given the amount of variables involved and as mentioned above, with experience of the software ideas can develop.

Never-the-less, if a project has a firmly fixed price, a good initial specification should be in place for an accurate quote to be produced, with perhaps some minor padding for minor changes (not U-turns). This is where there can often be an element of disappointment or compromise for the customer. They may have minor feature requests implemented, but anything more significant can't be added if initially agreed timescales will increase and the budget is not flexible. Like any other business, the software developer has to schedule customer projects and cover costs. Fixed-price is never an all-you-can-eat meal when staff time is involved.

Who pay's for the specification?

A chicken and egg situation can arise in that, the scope of the project isn't known until it has been fully investigated and a specification drawn up and so cannot be quoted for accurately. Creating a specification itself can take a great deal of time, so it often incurs a cost for all but the simplest of projects.

For fixed price budgets, the best thing the customer can do is provide as much information as possible upfront, creating some sort of plan themselves where possible and ensure they give it necessary attention, especially for complex projects. The software developer can be consulted at this stage to provide a ballpark cost or range (which may include specification creation time), and if the range is acceptable, the specification can be then created with a firm price confirmed afterwards.

Recommendations for Customers

• Brainstorm at the very outset getting everyone involved and get all possible ideas down to form some sort of plan at the start if budgets are tight. The software developer can assist at this stage, but the important thing is this shouldn't be overlooked.
• If possible, have some sort of contingency budget available in addition to the original quote cost, or plan and obtain a quote for a 2nd phase. Software can have many variables and as ideas put forward during the process generally have good merit and value, it's usually better to have them incorporated than have to compromise. Perhaps allow 10-20% for extras.
• Remember software development is a business and businesses incur costs. The quote you are provided with is based on a timescale, so ensure that time is used wisely by providing clear direction. Constant direction changes will inevitably cost more than if you had planned well at the outset.