If you are involved in quoting for software projects you have to make sure that you estimate each job correctly or you could find that a job quickly becomes unprofitable. In reality it is very hard to estimate as you rarely have a defined technical spec and requirements are constantly changing.

Often the scope creep, changes and alterations can account for 20-30% of a project, could there be a better way?

I am not sure that the fixed price model is so valid any more, the scope is rarely fixed so why should the budget be fixed? I am going to experiment with a new model that take some ideas from agile development method scrum.

Instead of a scope of work have a backlog

This is a high level document for the whole project. It contains broad descriptions of all of the features, wish list items and nice to have items. The most important part is that it is then prioritised by business need with rough estimates for business value and development effort. This document should be owned by the project manager and the client.

Fast iterations, the sprint backlog

This document shows all the features that are going to be developed in the upcoming sprint (typically 1-2 weeks). The highest priority features from the backlog are developed first. The features are broken down into tasks (which should be no more than 2-12 hours work). Anyone on the development team can then work on a task they are not assigned. A task sheet is often used so you can keep track of the progress of the tasks.

Burndown

The burndown chart is something that is visible to the whole team and the client and shows the remaining work for the current sprint. It should always be up-to-date and used as a reference for when the sprint will be complete.

How can this help us with pricing?

The great thing about this method is that it prioritises the most valuable features for the business. It also means that if the client wants to add new features they must take out other features or it is very obvious that the scope has increased and that will incur an extra fee.

So your fixed price means a fixed amount of effort which is then allocated against tasks. Once the allocated time runs out and the agreed features are delivered, your client can then buy more effort or sign off the project as complete. I am not sure how this will work in practice but there has to be a better way to estimate and cost projects.