Why Hourly Rate is Better Than a Fixed Price for Software Product Development

In the article on engagement models we explained how we run full-cycle product development. Depending on the character of a project, it is possible to choose one of the two pricing models – Fixed-price (FP) or Time and Materials (T&M). Some projects go well with an FP model, others are not recommended because of high risks incurred for both parties.

We draw a distinct line between the two pricing models in terms of their use. However, our clients sometimes press for signing fixed-price contracts rather than paying per hour regardless. Why would they knowingly choose the no-win option?

The answer is simple. Naturally, as consumers, we always want to know how much something will cost and when it will be delivered, especially when that much money is at stake. Similarly, avoiding the T&M model also has its raison d’être as including too many unknowns for the client: besides zero information on the overall cost and the release date, little is known about the software development process or how the scope is defined. Very often a ballpark estimate is taken for a fixed price, and then the client expects us to live up to this promise, without understanding how the pricing is conducted. Or the belief that with more detailed specifications the scope creep is unlikely to happen.

The FP model would be an easy and simple solution if only:

• the scope didn’t change (but it sure will);
• if the conceptual fields of the client and service provider coincided from the start (and they almost never do);
• if the project didn’t include any elements requiring a thorough analysis of domain expertise or creating a working prototype, proof of concept (which is bound to be there with custom software engineering).

Why initial estimate is inaccurate

When a client sends an order, they have a vague understanding of how an idea can be interpreted technologically, nor can they give an adequate detailed description of functionality, sufficient for creating specifications. For a service provider, nearly every new project means a new area of knowledge acquisition. Thus the initial estimation of costs and time is largely a guess or a guesstimate. There’s Steve McConnell’s term – “Cone of Uncertainty” – which nominates Barry Boehm’s idea of how impossible it is to give a completely precise and accurate estimate upfront. It is inevitable that early estimates tend to be highly erroneous. Those created at the inception can be inaccurate by a factor of four on the high or low side. According to the Project Management Institute (PMI), the cone of uncertainty is asymmetric and it evolves, as the project unfolds, from an initial order of magnitude estimate (+75% to -25%) through the budgetary estimate (+25% to -10%) to the final definitive estimate (+10% to -5%). Though it’s easier to predict the cost of some standard solutions, with custom software the cone of uncertainty is really large.

Read also: Software Project Estimation: Our Best Techniques

Why early fixing of scope is dangerous

Another misconception is that if we fix the scope right from the start, it will be easier to make the price and time estimates. But there’s the rub: the scope is bound to creep for two reasons mainly: firstly, it’s rarely detailed enough, as you need a business analyst’s opinion at the very least, not to mention a technology expert’s aid at some point (for the most part, this moment is overlooked by clients); secondly, the architectural concept evolves as the knowledge builds up or due to some external circumstances. Thus freezing this variable right from the start is a potentially dangerous if not fatal error. It’s been a major stumbling block with fixed-price contracts based on unclear or insufficient specification. So why go for a mediocre solution if you can gain more by being flexible? According to the author of Agile Estimating and Planning Mike Cohn, a definition of a failed product might as well include the criterion ”a project on which no one came up with any better ideas than what was on initial list of requirements”.

Why fixed-price model is less efficient

Obviously, the source of mistrust with T&M or other models with non-fixed payment lies in the fact that clients rarely understand the software development process, its organization, and factors hindering or enhancing its efficiency. On the face of it, the opportunity to choose the lowest bid and freeze expectations about the product must generate cost savings. But it actually generates a lot of waste (of time, resources, energy, and funds). Here is how the waste accumulates.

Ideation and documentation

When the scope is fixed, the only option is to work in ‘waterfall’ manner. That means the preliminary process of research and documenting is more profound and, consequently, takes as long, if not longer, as the actual development. So if the negotiations fail after the first phase, it’s an unthinkable waste of time and effort. By contrast, in agile methods, a quick initial estimate, if approved by a client, will smoothly transit into production without any further hassle.

Getting up to speed

Another concern is the time for learning the basics of business and arranging technical environment. When every single function is handed down in a cascading manner – from design, through the development and quality assurance, to implementation, – it reduces the chances of sharing resources and generating knowledge. So this mode includes more ramp-up and ramp-down at every stage. Even in Agile, the learning curve shows that product development begins no sooner than the 3rd sprint. With waterfall, it takes much longer.

Management overheads

Finally, the FPM fosters antagonism rather than partnership in the way it deals with risks. Instead of having common goals and risks, the client pushes the financial risk to the vendor by requesting a fixed-price, and the vendor pushes risk back to the client by embedding it into the budget. To cope with risks, the process has to be closely supervised, which puts extra load onto project management and, consequently, has to be compensated for. Moreover, agility is lost when every change has to be analyzed, negotiated, and then implemented to tight deadlines.

Why an hourly rate is a win-win

An hourly rate has a number of advantages. To begin with, it’s economical, for you needn’t carve the price in stone right from the start, and it’s easier to calculate the costs as the project evolves. And so there is no need to build extra costs into the budget to provide for the unknowns. Moreover, the vendor focuses on functionality and quality rather than on deadlines and costs. So there’s no need to compromise the quality and there won’t be a dilemma ‘features over bug tracking’. Finally, applying Agile methodology, like Scrum, allows for more flexibility, which is important for producing something really valuable for a client.

To conclude

It is not worth fixing something in our volatile world or making people live up to pie-crust promises. As Niels Bohr said, “Prediction is very difficult, especially about the future”. What really matters is building up trust, granting enough freedom, and expecting great things from your business partners. So next time you ask for a quote, consider an hourly rate with Agile.