Fixed Price Vs. Time and Materials (T&M)

Meeting with a new prospect. Great conversation. Seems like we're a good fit. And suddenly, THAT question pops up: Can you send me a quote for the project?

I certainly could say yes. It would indeed be easier. I could assume 90% of the scope and requirements, speculate how the project and priorities will evolve, probably inflate the pricing to protect our team, and send a fixed price quote. But I just know that that doesn't work out. It doesn't work out for us and definitely won't work out for our client, either.

In this short blog post, I'll explain why in agile software development, Time and Materials (T&M) is the most beneficial pricing model for providers, clients, and, most importantly, for the project's health.

Fixed-price

Clients tend to assume that fixed price software development is less risky. At a first sight, it might make sense: you specify a scope, a number of user stories, and the provider is committed to having everything ready in a defined timeline, for a fixed price.

Zero risks, huh?

I won't lie; as a product owner, a fixed price is comfortable. You know what your costs are upfront. You know your timeline and what to expect. You know what requirements will be covered. You can just leave all of the work to the team until the product is ready.

But... what if requirements change?

In my experience working with startups and even well-established companies, requirements do change. It is the natural (and convenient) lifecycle of any agile project. Priorities change as the context varies, and as we go more in-depth into the users, the business, and the market. It isn't bad; it just means we're making smarter and more educated decisions.

With a fixed price agreement, you don't have the flexibility to change priorities or pivot. So you can find yourself in a scenario where you know you could be doing things better, but you can't. And this is a big risk.

At the same time, the provider:

• Doesn't have the flexibility to suggest changes to the scope or the team composition.  The resource estimation for the entire project is done beforehand: it doesn't matter if you finally didn't need all that design time, or if you need some extra help on QA. Everything is pre-defined.
• Providers tend to add a risk factor, or padding, to safeguard themselves.
• And instead of focusing on developing your project and meeting your needs, the provider will be influenced by its own profit interests and trying to optimize its costs, putting the quality of your product at risk.

In a nutshell, even in the best scenario where scoping was great and requirements didn't change, either you'll be paying more for the project for the benefit of a known price, or the software provider will lose profit (and probably lower the quality of your product to prevent that from happening). In either case, someone loses. Not to mention that a fixed price doesn't promote a team & partner spirit, which will probably negatively affect the project's outcomes and the personal investment of everyone involved.

Time & Materials (T&M)

To build software, you need people: developers, designers, QA engineers, and some other roles. This said, the real cost of a software project translates essentially to how much work the team invests in building the product.

As software tends to be uncertain, it is difficult to accurately calculate the timeline and right team composition to complete the scope of work. What we can do is an estimate.

With T&M, instead of paying a fixed sum for a defined scope, you pay the software team for the hours of work they invest in finishing the project and for the materials they use.

The biggest advantage of a T&M is that, as a product owner, you have more control over the project and the decisions made along the way. You get to decide in which direction the project goes as you have the flexibility to change the scope or the priorities. You have what's most important: the team. And you lead the way.

This doesn't mean you won't have a clear idea of costs and timeline upfront. Before starting the project, you'll get an estimate of how much the provider considers the project will cost based on analyzing the requirements.

The project is split into small scopes (called sprints) with a much more accurate estimated time, workforce, and cost. As the project progresses, estimations start being more and more accurate. During the project, the team and product owner together lead the way, evolving in the right direction, and finally delivering a product that fits the needs.

T&M with Cap

There are different approaches to T&M. A big fear for clients is not knowing how much the project will cost, and how the invoices will look every month. It is a normal practice to use T&M with Cap. This is when the client determines a budget upper limit according to its constraints. The provider will consider this budget when prioritizing and scoping. At the same time, this prevents uncontrolled cost escalations.

Conclusion

Even though fixed pricing can make sense in very specific software projects, or in other engineering fields, like civil engineering, it usually doesn't apply to the software products we work in. You can be sure that there won’t be necessary changes in the design and specs for a bridge, but software requirements can (and should) change in a year, month, or even a week. The world of technology is nimble; context changes rapidly, and we must adapt to survive.

One of the main principles of Agile Software Development is “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Fixed pricing just limits the agility and flexibility of a project.

Have I worked in both modalities? Yes.

Do I prefer Time & Materials? Yes, I think this model benefits everyone involved and real partnership collaboration.

Will I keep working with fixed-price projects? Probably.

I understand how budgets and RFPs work in certain companies, or that you might have had a bad experience working in T&M with an agency that wasn’t reliable. I also understand that it might be a better choice for everyone in small scopes with few risks. But in my experience, to build products that really respond to the user, market, and business needs, creating genuine partnerships is a key factor.