As a freelance software coder I often get asked to provide fixed priced quotes on projects. Unless the project is particularly small and well defined I will encourage the client to consider working on a time and materials basis. Why? I’m glad you asked 🙂
Client motivation – A matter of trust
Clients ask for fixed price quotes to seek protection from cost blow-outs. The basis of these requests are a lack of trust in the software developer. It might be a lack of trust in the software developers estimation ability or their ability to communicate looming cost blow-outs or even their honesty.
This is understandable, sometimes it is hard to trust people that we don’t know. It’s a completely natural response, especially when money is involved. There are many unscrupulous operators out there and everyone has heard stories of software projects being delivered way over budget.
The problem, for clients of software developers, is that asking for a fixed price does not provide much protection against cost blow-outs.
The devil is in the detail
You see, fixed priced quotes are based on technical specifications (requirements and design documents) and good specs are hard to write. 20-40% of project budget hard to write! It is very difficult to remove every ambiguity and cover ever edge case in these documents. A design document that specifies every detail without ambiguity would have effectively implemented the software on paper which, in my opinion, is not the best use of resources.
Clients also come into projects with their own assumptions which are often different to that of the developer. This can result in requirements being left unwritten in the specifications.
So, the technical specs are almost always lacking. This is not to say that anyone is at fault, just that the reality of things means specs are rarely perfect.
So what do these ambiguities, assumptions and missing requirements mean to a software developer when asked to provide a fixed price quote? Risk, a whole boatload of risk. Risk that the amount of work required to satisfy the requirements is elastic depending on how you interpret the requirements. It also introduces risk for the client, the risk that they are not going to get what they think they are asking for within their budget.
The introduction of this risk changes the dynamic of the relationship. Instead of working as a team aiming for the same goal, the developer and client become adversaries. The developer wants to interpret things in the way that results in the least amount of work for the fixed amount of money of their quote. Meanwhile the client is fighting to make sure the software developer is delivering what they want.
This is not the basis of a good relationship.
Software Projects are Fluid
What would life be without change? Change happens in everything we do. Software projects are no different. At the start of a project things might be crystal clear, but as we move forward new ideas can crop up, old ideas can have their once solid foundations crumble. So where does that leave the fixed price quote? How do you work out which portion of the fixed price has already been expended? How do you incorporate additional work into the equation? More fixed price quotes? In my experience software projects can become mired in such scenarios with neither party walking away happy.
So that’s why when starting with new clients I try to suggest that we work on a time and materials basis. I want to be part of a team working toward a goal together, trusted by my client to to do a good job.
If a new client is resistant to working on a hourly basis I recommend starting the relationship with a small, well defined, self contained project. The small size lessens the risk to both parties. It helps both me and my client to understand how we communicate and work together. It also helps to establish a level of trust to give confidence to the client that I am an honest operator that provides realistic initial estimates and my communication efforts will allow my clients to take action before potential cost blow-outs become serious issues to the project.
After the success of that initial project clients are usually more open working on a time and materials basis, which is a much better way to do things in my opinion.