Many prospective clients ask if we can offer a fixed price for their software development project.

To give a fixed price estimate, requirements need to be defined in great detail, stay fixed, be limited in scope and we would need to invest much time into analysis. From my experience, this is rarely practical.

Therefore we only give a rough estimate for each sprint. A sprint is phase and a subset of requirements that can correspond to for example 300 man-hours.

We can also give very rough estimates for larger sets of requirements. The larger set of requirements, the more rough the estimate would be.

Rough estimates require less administration and give you as a client more flexibility. If one of our clients would be dissatisfied about a certain feature or service, we are happy to consider a discount as a gesture of goodwill, and instead focus on how we can avoid any dissatisfaction in the future.

We understand that a fixed price for each request might sound ideal for you as a client. But here are more reasons why we never offer fixed prices:

• Requirements change during development. This is natural, as all parties spend time thinking about how the system will be used. Foreseeing and estimating for such changes is hard, if not impossible.
• Fixed price jobs are often an administrative burden: time needs to be spent by project leaders to clarify whether or not a request is part of an earlier fixed-price requirement or not. This cost has to be passed along at some point of time. It is more constructive to focus efforts on delivering true value.
• A fixed estimate may end up being costlier because we need to spend time specifying exactly what to do, and what not to do, to minimize risk.
• Development risk getting delayed as change requests need new estimates which need approval from you. Temporarily moving a developer off a project while waiting for approval results in inefficiency.
• Each software project is unique and an unknown number of research hours may be needed to clarify what exactly needs to be done and how long it will take. Let’s say it takes 10% and the very rough estimate of the full project is 2000 hours – the risk of investing that many hours for a project that might be turned down is usually prohibitive. This is one reason why basically all professional software developers today follow the agile development methodology where the key is to focus on estimating and developing one set of requirements (sprint) at a time.
• We bill all our clients hourly and we keep busy. Our selective recruitment process means that hiring talent is usually the bottleneck. Therefore we find it too high risk to take on a fixed price project.

But how can we control the budget on a non-fixed price project?

• LiteBreeze does a lot to make your project a success.
• We can provide estimates for one sprint at a time as per the agile development methodology and if you feel that not enough value for money has been provided in a specific sprint then immediately contact us to discuss. If we have failed to deliver within a reasonable number of hours, we can discount hours. We’re committed to a long-term relationship that is mutually beneficial.
• We suggest that both of us re-prioritize features frequently to make sure time is put into only the top priority tasks that give the most value per hour spent. Focus on High Impact Low Effort (HILE) tasks.
• Evaluate the reported progress and send us feedback on how well you feel the developers are doing.
• We keep developers’ performance high through frequent coaching.
• We have a radically transparent system and our aim is to make it easy for you to evaluate. You can at any time check how each hour is spent through our client portal and the daily/weekly billing notification emails. We update time overviews (timesheet summaries) daily.

When I personally contract third party consultants and experts, I don’t insist on a fixed price for these reasons, except for perhaps an initial limited project study to make an initial assessment of their skills.

Long term project success is more about recruiting the right software development team and coaching your software developers through feedback, rather than pushing for fixed price deliveries.