Fixed Price vs. Time&Materials - Which Pricing Method to Choose?

One of the main goals of a Project Manager is to maintain a comfortable environment for developers in order to let them do their job in the best way possible.

And even though they don't seem to relate directly to actual development, contract details often affect not only financial prognosis but also the everyday work of web-development teams. Let's see how.

Fixed price as well as time and materials, as noted in the title, are two main models that development agencies use to bill their customers. Fixed price suggests that there is a fixed budget and usually a timeline for delivering a project with a known scope. Both sides agree on them before starting a project and do not expect any amendments during its implementation.

Time and materials pricing method is a leaner model in which a client is billed for the time they spend on the project, no matter how long it takes. This also includes any third party materials that are used in the project.

Pros and cons of fixed price

First of all, let's see how the price is formed for a fixed budget: it consists of the project estimation plus some risk margin (most often it's around 20-30% of the whole project costs).

Estimations are the most difficult part of the process, especially when dealing with completely new projects. It's almost impossible to come up with the precise figure until you get deeper into the project, try a couple of approaches and pass a few iterations.

This is why the margin is added: we assume that there are some risks which we don't see now and which might occur later (aaand they usually do).

The fixed price model usually looks attractive to bigger companies that have to plan and justify their budget far in advance and don't mind paying extra in exchange for made-in-stone predictability.

So that seems pretty fair for projects where the scope is not about to change, right? The profits are going to directly reflect the estimated skills of the team (which grows with its expertise) and the customer knows exactly how much it is going to cost.

However, there are always new inputs during a project: whether it is new requirements from clients, or a new version of an API we were going to use, or new browser to support. 

What can happen during a project?

• Every change in scope will initiate a discussion about changes in the contract (since the scope has changed, terms should change as well). And the worst thing is that those discussions usually take more time and resources than implementing the change itself ¯\(ツ)/¯.
• This also works in the opposite direction:
  • if the team finds a better approach to solve the task which requires more time now, but possibly saves a lot in the future or
  • if the team brings up a new feature that will have great business value, then they do not feel that they can do it, because neither fits into the plan and we should follow the plan precisely.
• Last but not the least. The above points could make the relationship between the customer and an agency tense, since investigating who took the initiative to make the given change sounds like the eternal question of who's guilty?, which never helps build a transparent and equal partnership.

This could result in a situation where the team loses motivation, because their expertise is not being used and the customer, in turn, gets the product done exactly how they required it even if it's not the best product that could have been produced. In this case, both parties are not fully satisfied with the project that was completed.

So based on this, fixed price could be a good fit if the project scope is clear, similar projects were implemented by the agency in the past and both parties agree upfront on how they will deal with any potential changes to the requirements.

Why consider time and materials?

But there is a reason why more and more development shops choose the time and materials model, and this reason is ... Agile.

It is a wider topic than this post can cover, but let's face it: Lean methodologies have proved themselves to be the most effective tool for managing the development of web applications (and many other things!).

And since the main point of Agile philosophy is the ability to adjust to ever-changing conditions, there's absolutely no point to use it in combination with fixed price budgeting model, which by definition does not allow amendments to be made.

The pros of T&M

T&M suits projects managed in an agile way best: it gives room for maneuvering by both sides and allows each to make a lot of product decisions without involving contract lawyers. It allows both sides to suggest improvements and add new features based on the market needs and not on the document that was signed a couple of months ago.

The agency will know that new requirements brought up by the client will be billable for them and will perceive them as new insights, not an attempt to abuse previous agreements. The client can be sure that he is not paying more than the amount it actually took to deliver the scope. The client can also use all of the team's experience and consultancy they want in order to release the better product.

So, in short, in the T&M approach, instead of fixing scope, time and price, we fix another parameter - quality.

The cons of T&M

On the other hand what this approach lacks is the timeline and budget predictability which is so attractive in the fixed price model. Since the scope is malleable, the team can not make any commitments on the deadline for the whole project. It doesn't mean it's unpredictable though, it's just that the estimations change with every change in the scope. This is totally manageable, especially if the customer is close to the production team and knows how one or another change will affect the project frames.

Another minus of this model is that customers are often afraid that agencies will abuse it and do things longer than they actually take to complete. Though it's not really reasonable, the agency's reputation is what it relies on when building its business. As a result, it's not in their long-term interests, but it could be a serious obstacle in negotiating the contract details.

Both of these issues can be addressed by maintaining a friendly and transparent communication between parties, creating a trusting environment and being open about everything connected to the project (which of course sounds easy on paper, but that's the topic for a separate post :) ).

In our experience, this approach shows the best results in the long run and helps us be a partner to our customers rather than a simple workforce.

Hybrids may just suit your needs

Though the Time&Materials method seems to be very attractive, it makes sense to establish some boundaries until both parties know each other better, and just like in any relationship, make sure that it’s worth pursuing.

There are an infinite number of combinations of these title models. For instance, it could be generally time and materials, but with the budget cap set based on the initial estimations of the scope. Or only part of the scope can be fixed and estimated for fixed costs, and the rest can be billed based on T&M.

It's simply about finding a concept that will suit both parties the best and will not restrict any of them from doing their job.