Fixed Price Projects – the client always loses
One of most often struggles I see in my freelancing work is the problem of fixed price projects. The very popular scenario I see when I negotiate a project is this: the client provides basic specification, some wireframes or designs and asks – how much will it cost?
In the past I would sit down for about 2-3 hours, break the project into smaller tasks and do a PERT estimate – which involves pessimistic/realistic/optimistic estimates and some fancy calculations around them (read more here). Once done, I would send my estimated offer and we started the next phase of the negotiation.
The biggest problem here is that the client didn’t always understood that it’s an rough estimate and wanted a fixed price for the work.
So let me try to explain why I think that fixed priced projects are evil and they hurt the customer the most.
Fixed price means fixed specification
First fundamental thing I try to teach my customers is that fixed price project requires a lot of planning ahead and it’s virtually impossible to predict all scenarios without actually building them. Let’s take a simple example – new user sign-up page. Usually we get this page from the designer and it’s pretty straightforward – sign up with Facebook or email with few controls.
So let’s say the developer estimates it as a 2 day work, builds it and sends for review. However the client comes back with feedback that the provided feature is not what he had in mind – guess what, it turns out that there are several scenarios we understood differently.
Data Validation
- Developer: “No client side validation. The server is responsible for returning invalid data with message.”
- Client: “I want client side validation with these options: (…)”
User Interface Details
- Developer: “I’m using default system date picker, system alerts and no custom animations”
- Client: “I want custom calendar picker for date time, custom alert popups, and you know, custom animations”
And the list goes on…
As you can see there’s a lot of things that can go wrong here and even communication around these requirements will take at least solid 1 hour meeting with several emails back and forth. And remember, this is just one simple screen.
Fixed price also means lottery
Now let’s assume that we received better specification from more tech-savvy client and that he understands all of the above limitations. We both agree that within the fixed priced project some minor changes are allowed and major ones will require extra cost and start the work.
Well, the client is still on the bad position. Let’s look at the possible scenarios.
Scenario 1: The developer overestimated the cost
We have experienced developer with established position and may offer extra price for the work without the fear that the client will go for cheaper alternative. So let’s assume the developer estimated the project work to cost 10,000$ and added 50% to the offer for extra unpredicted scenarios. In the end everything went according the plan, so when the project ends and the client pays the 15,000$ price he lost 5,000$ compared to actual work. Not good.
- Client Pays: 15,000$
- Developer Work: 10,000$
- Client Lost: -5,000$
Scenario 2: The developer underestimated the cost
When the developer underestimates the cost, you might think that’s a win for the client, right? The developer estimates the project to cost 10,000$ but he was off and it required 50% more effort to complete. In theory you might believe that the client got 15,000$ project for just 10,000$. Not exactly.
Usually when the developer sees that he’s off with the estimate he’ll start cutting corners and work under a lot of pressure. Code quality will lower; bugs will be resolved in an ugly manner and they might hit back hard after some time after the project ends. In other words – the developer will be able to reduce the damage on his side and the client will receive low quality work. Still no good.
- Client Pays: 10,000$
- Developer Work: ~13,000$
- Client Lost: Quality of provided software
Scenario 3: The developer managed to estimate the cost properly
Congratulations, looks like we found an unicorn! Just don’t expect that we’ll be able to pull it off on the 2nd project. In general it’s virtually impossible to properly estimate the work – we need to accept it as a fact. Recently one of my projects managed to be only 5% off with the overall estimation, which I consider really good result, however I also have >100% off projects in my portfolio.
On the other hand the client still managed to lose something – and this is the ability to change project scope during the work.
- Client Pays: 10,000$
- Developer Work: 10,000$
- Client Lost: Ability to change the project scope
The Solution: Build in small increments with frequent communication
When the client wants to build some software, it’s natural that he would like to know how much it costs upfront, right? There’s no escaping from this. Unfortunately, the software development industry can’t accurately provide the effort and time required to complete projects. The good news is that we have some tools in our disposal to make this process more predictable and with fewer surprises (AGILE is the keyword).
Let me share the process which I’m currently using with my clients.
- We start the project with a fixed price road-mapping project, where we discuss all the requirements. I provide the list of tasks required to build the software (backlog) and roughly estimate the costs and time.
Delivery: A list of tasks (backlog), and a document with all the agreed requirements and solutions. - We agree on the scope for the next 2 week mini-project (so called sprint) and select several tasks from backlog which we plan to build in this sprint. The sprint has fixed price.
- For the next 2 weeks we build the features and communicate the progress and potential problems with the client.
- If we completed the tasks sooner, we take another task from the backlog.
- If we underestimated the effort, we move the feature to the next sprint.
- At any point the client may add/change or remove the tasks in the backlog – but he understands that it’ll impact the final cost.
- Once we’re done with the sprint we provide the build for testing to the client and discuss next batch of work.
- We repeat steps 2-5 until the client is happy with the result and is ready for release.
With this process the client is very active in the development process and has the control of the spent budget and may act accordingly. He also understands how much effort some features require and can decide if they are really worth it – and in my opinion is the biggest benefit and cost saver.
In my work I have found this process very helpful, but would love to hear your thoughts if you have different experience or concerns. Feel free to leave a comment or contact me directly.