Fixed Price Projects
What is your take on fixed price projects? It seems they are the gold standard, yet they certainly have their faults.
A lot of people hold the belief that a fixed price project is the only way to go. Clients looking to have a project done think that it ensures their project will cost an amount that they are willing to spend on it and, an hourly basis project can very easily get out of control and end up costing considerably more.
Developers who take on fixed price projects do so for a variety of reasons; some figure it’s the easiest way for them to get work, especially when times are tough and others are uncomfortable with negotiating and having to keep going back to the client for more money.
Where I stand on this is that I do NOT take on fixed price projects; they are bad for me, and they are ESPECIALLY BAD for the clients.
Michael, my business partner Robert Kwasny, and I discussed this topic at length at DevCon 2015 in Las Vegas this past summer. The benefits for both parties seem greater when hourly based projects are employed:
This is where the developer gives the client an estimate on a range of hours that the job is going to take. That range is based on the specifications provided by the client and by the developer’s experience in doing similar types of projects. The developer keeps a close track on the hours that are being used; any changes to specifications are discussed and the client advised of the possible time increases to get those items done. The project stays on track and gets done in a timely manner.
In this scenario, the client only pays for the time that is actually being spent on his project so he ends up paying a fair price for the work. The developer is motivated throughout as he’s is getting paid what he thinks he is worth (which he probably is) and so both parties end up winning.
I’ve been using a slight variation of this style for a while: Promising a maximum number of hours for a given project based on the specifications of the client and my best guess based on experience, with the proviso that any changes would be identified, discussed, and quoted prior to implementation. If the project is completed for less than the maximum hours, the unused hours will not be charged to the customer. This approach requires building a trust level with the client before providing a bid, and that process is helped by customer testimonials and customer references. It’s best to have those resources ready to go beforehand.
This approach has worked well for me. And Rocharde’s approach has worked well for him, too. The down side: there are some projects you won’t win. The upside: the project you do win will result in a happier client, a job well done, and a profitable developer business, something in the clients best interest.
How do you handle project quotes? We want your feedback–please comment below.