Fixed Pricing on Software Projects is a Flawed Paradigm

by Colin Kennedy - Jun 10, 2013

Over the past year or so there has been a lot of attention paid to the topic of Pricing within Neuron Global. One of the reasons why it has garnered so much attention internally is because we realized,


When not done properly, fixed price bidding to is tantamount to betting your development budget to chance

© Neuron Global

After a thorough review of our past projects, that there was a strong correlation between proper pricing and a project’s success. Said another way: if we did a good job pricing the project,the outcome, almost without exception, was a positive one – the client was happy with the end result, the project deliverables met or exceeded expectations, the timeline held up, we made a profit on the work – the proverbial “win-win” situation. And when our pricing was out-of-whack, there was a much greater chance that the project would end up having more of a “win-lose” feel to it.

Right about now, some of you must be thinking to yourselves “Well, the answer is pretty straightforward…why don’t you just make sure to do a “good job” pricing every project? That way you can avoid all of the stresses that are associated with bad projects!”And that’s exactly what we’ve done since we had our epiphany. Are you curious about what we chose to do? Our solution was to stop offering fixed pricing on software development projects – it was as simple as that.We made this change becausewe came to the understanding thatthere is no such thing as “doing a good job pricing” if you’re trying to attach a specific dollar amount to a software project. And herein lies one of the keys, maybe THE key, of why 2/3 of software development projects experience significant problems:

Many clients are convinced that their project must be done for a fixed price…but due to the level of complexity of their project, it’s simply too hard for a software company to arrive at an accurate fixed price with any degree of consistency and accuracy. Legit software companies know this, but many do not have the discipline needed to refuse to bid in such a manner, and instead, price their work in a way that reflects reality.

This “reality” that we speak of is that there is a large amount of variability associated with almost all custom development projects. This variability makes it nearly impossible to accurately forecast how a project will evolve. Hence, agreeing to a fixed price is akin to agreeing to an arbitrary number that won’t accurately reflect the time, energy, and effort spent on a project when it’s all said and done. And this is a bad idea for both parties because it puts the client and the software company in conflict from the get-go. Instead of fostering creativity and a shared sense of purpose towards achieving something great, the opposite occurs. That doesn’t sound promising, does it?


We expect that this blog has raised more questions than answers, but because Pricing is such an important topic, we aren’t going to rush through it. In upcoming entries we are going to delve into the nooks and crannies of the dangers associated with fixed price software projects: why they can’t be priced accurately, what happens when these types of projects go south, and ultimately ways in which you can bridge the gap from a “fixed price mentality” to something that will create a healthier, more productive dynamic for your project.