Fixed Price vs. T&M


I don’t like fixed price contracts, or at least not in my industry – software design and build. It’s not that I don’t like constraints and deadlines – on the contrary, I think they help one focus and sometimes accomplish more than within complete freedom of action. It is, however, artificial constraints that urge me to consider alternatives.

The most prominent alternative to fixed price is the Time & Material, or simply T&M, type of contract. I will assume that the differences between the two are obvious and won’t bore you with explanations of what they are. However, I will put them head to head in order to show why my feeling, which has gradually turned into a strong opinion through experience and analysis, indicates the fixed price model as the inferior one.

A couple of considerations before we get to it:

  • This comparison is done in the context of  the software delivery (design, development) services industry. This is not to say that the arguments would not apply to other industries, only that I am most confident to talk about the former.

  • I am making an assumption, albeit a strong one, that a fixed price contract necessarily implies upfront requirements that allow for a decent indication of expected effort. After all, if the requirements are not clear, how would someone then be able to size work and thus accept obligations of a fixed price contract?

  • The opposite then, although only optionally, is true for T&M. This means that there can be a level of upfront requirements, for instance, enough to gauge an expected budget, but they are not required, because a budget can also be set on mere availability of financial resources or a simple spending appetite.

With this in mind, here’s why I believe clients would be much better off with T&M contracts versus fixed price.

Fixed price contract myths

To begin, let’s look at the main reasons behind choosing a fixed price contract over a T&M. The very word ‘fixed’ implies that there is a better (perceived) clarity around the object of the contract, which in turn provides stronger guarantees relating to:

  • Total cost of delivery

  • Definition of final deliverable

  • Timeline of delivery

Let’s look at each one separately.

Myth #1. Fixed price contract will help me manage costs better.

It will help you manage costs. However, it won’t let you do it better than a T&M contract would, as it’s just as easy, and just as common, to set up a budget for the latter.

Even if we assume that maximum spend can be equally well controlled by both, I would argue that business value received for the budget would be lower in a fixed price engagement, and here’s why:

  • A vendor will always overestimate effort required to deliver the outcome in order to ensure against the risk of not doing so, and the client ends up paying more for the equivalent amount of work, or receives less for the equivalent budget.

  • Part of that budget will also be spent on change management overhead, as opposed to delivering additional business value through software.

Change management is an important consideration here. Since a fixed price contract shifts all risk to the vendor, after contingency premium, change management is vendor’s primary tool for mitigating that risk. Since the purpose of change management is to identify any deviation from baseline requirements, price it and charge for it as additional work, this more often than not results in the final cost of delivery ending up higher than that in the original contract, thus hindering the effort to control total spend.

Myth #2. Fixed price defines final deliverables better.

Even though the name refers to a fixed price, or fixed fee, what really sets it apart from a T&M contract is a fixed scope. However, I think it’s needless to say that in most projects, especially in software projects, definition of exhaustive detailed requirements prior to commencement of delivery is very impractical  – not impossible, but impractical. What makes it so:

  • While people are really good at saying what they like or don’t like about something they see (one of the fundamental ideas behind agile delivery), we are quite bad at saying in sufficient detail what we want upfront. Which translates into incomplete or inaccurate requirements and the necessity for continuous requirements’ refinement.

  • Our own experience with upfront detailed requirements shows that due to changes in direction and priorities, as well as feedback to product deliveries, up to 40% of original requirements (including designs) do not make it into the final product. This is pure wasted effort.

Say, you do decide to define full requirements upfront. This requires a very concentrated effort and exceptional analytical skills. However, even if it is done, the following financial implications have to be considered:

  • Postponed revenue. Gathering and refinement of requirements is a time-consuming activity, and an attempt to accomplish it before beginning of development is done at a cost of delayed development and thus time-to-market.

  • Higher cost. If you contract specific resources, such as visual designers, you would be forced to use their services longer, because not only would they need to work on requirements, but also provide support to developers during delivery, as requirements are never good and clear enough on their own.

Therefore, a fixed price contract type is only applicable in a situation that is impractical to begin with.

Myth #3. A fixed price contract provides me with guarantees of when the final product is to be delivered.

This is true. If a vendor is falling behind a delivery schedule, the team can be ramped up, or development speed increased in other ways, if necessary, to meet the delivery deadlines. However, the same can be achieved with a T&M contract when working towards a milestone in a release or delivery plan. After all, a T&M contract often only defines the daily rate and total budget with sufficient flexibility in budget burn rate while working towards delivery goals.

Furthermore, the fixed price approach implies that, in order to deliver a fixed scope in a fixed amount of time, one needs to indicate, evaluate and contain any project-external influences and dependencies on any third party or client’s own internal resources that can impede a fluent delivery of the final solution – an extremely difficult task that often ends up with inflated SLAs and other commitments that are designed to act as insurance against non-delivery as opposed to reasonable coordination of efforts. With a ticking T&M meter, on the other hand, it is in the client’s best interest – mind you, both for vendor’s (smooth uninterrupted delivery) and client’s (efficient spending, fast delivery) sake – to ensure actions of different parties are orchestrated within the reasonable planning horizon to minimise/eliminate any downtime of project resources.

Product & requirements management

OK, so if we take away all the ‘comforts’ of the ‘clarity’ of the fixed price contract, and move all the risk back to the client, how can I possibly say that a client would be much better off with a T&M contract? Because, believe it or not, this is exactly what I am saying.

Well, the biggest issue, which I have witnessed all too often, is to do with the mentality behind a fixed price approach. Once a fixed price project is signed and in the drawer, the client goes into a state of mind which is something like ‘Ah… I can finally kick back, relax and just wait until my product is delivered to me’. And while this might be true for when you order a pizza, this is never the case when you order custom-made software.

What is the single most important input into software delivery? It’s requirements. There’s a reason why Scrum identifies Product Owner as indisputably the most important role in a project. And while development, QA, design and a number of other skill-sets are extremely important, it is the business value delivered through well conceived and prioritised requirements that determines success and failure of a project to the business.

And get this – product/requirements’ management is always (or should always be) the function of the client. And while T&M approach leaves all the risk with the client, it is an illusion that this risk can be outsourced or sold at a premium. The only way to deal with this risk is to manage it, and the best and only tool to do that is good requirements’ management.

I have already made a point that it makes little sense to prepare upfront full-detail requirements, but  more often than not one would want to do some upfront requirements definition/design – only enough to understand the scope of the project, inform architectural considerations as well as allow for very high-level sizing and estimation – never a commitment. Instead, as requirements are being produced and refined, they are also prioritised to make sure that more important functionality will be implemented before the more trivial.

So, where fixed price approach is trying to box requirements with time and cost constraints, T&M merely uses either or both of the constraints as a line which can easily be crossed (through trade-offs) while performing the task of continuous (re)prioritisation with the goal of delivering highest business value within the constraint.

So… what’s so great about T&M?

I believe that what a T&M contract does is create one simple thing, and that is a healthy collaborative environment that is critical to any project’s success. And it does so by correctly defining the two key ingredients of a good project:

  • Skill-set. The very reason for a client to consider a service provider is the need for specific skills (design, technological, IT architecture, project/programme management, etc.) that it lacks within its own organisation. And a vendor provides these skills at an agreed price – the daily rate.

  • Leadership in the form of requirements’ management, as it not only entails the direction of the product to be built, but also bears the responsibility of success or failure of the project. I believe it is self-deceit that this responsibility can be outsourced, or concentrated into a short effort before the beginning of the project.

No project will succeed without these two components. And if T&M provides a great basis for these working together, why the overhead of a fixed price?


This article is, without a doubt, very one-sided in favour of T&M contracts. And for a number of good reasons which, if I did a good or at least a decent job, are clear and indisputable. However, it would be wrong to say that there is no place for fixed price contracts – there certainly is.

What kind of project could qualify for a fixed price? A small one. How small is small enough? I believe the best way to gauge that is to see what project management approach you would feel more comfortable applying:

  • If the requirements are small, clear and detailed enough so that you can construct a robust waterfall plan that you are confident you will deliver with little slippage, then there’s no harm in going fixed price.

  • However, if you think that too much time would be wasted on getting a deep understanding of requirements at the outset of the project, and a resulting sequential plan still urges you to slap a big fat contingency on the price, then agile approach with a T&M contract seems a better candidate.

In any case, when you think about what services we normally buy for fixed price, it’s usually something relatively simple, something repetitive – a shoe sole to be repaired, a haircut, a wedding photographer hire even. However, you rarely expect a price upfront for fixing a car after an accident, or for legal services to draw up a proprietary contract without a raft of ‘if‘ clauses. Less so should we expect to give a fixed price for building software, which is neither simple nor repetitive. Agile approach to software delivery was invented for this exact reason that it is so difficult (virtually impossible) to plan out software for A to Z, and if you can’t plan it, you can’t reliably estimate and cost it.

Decent User Experience – A New Human Right?

We digital designers, of all hues, generally like to tell ourselves that we’re doing more than simply earning a wage; building wireframes, pushing pixels etc.  We’re making people’s lives better.

We also tend to believe that the businesses that ultimately foot our bills, take a more prosaic view; it’s all about the brand and the bottom line.

I think that there is something more profound going on here; I’m arguing that we should start to see ourselves as playing a small, but active, part in one of history’s grand narratives.  A big claim I know, for a UX blog post.  But bear with me, I guarantee you’ll be rewarded, and hopefully even, convinced.

I’ve recently been reading Steven Pinker’s excellent book on the little known fact that we’re currently enjoying the results of a multi-century long decline in violence – in all it’s forms; in crime, in war, in murder, in abuse, in discrimination.  In fact, in pretty much any form of oppression and violation of another human being’s experience of life.  The book goes into the details of this happy decline in countless different areas – here’s an example, a chart looking at the massive decline of murder rates in Europe, in comparison to the those of non-state societies.


Homicide rates in Western Europe, 1300-2000 and in nonstate societies.  From p459 of The Better Angels of Our Nature

The past was indeed a very different country – and i’d much rather be living in the here and now.

In the dim, and sadly, not so distant, past, life was cheap, authoritarian hierarchies were unassailable and invulnerable, divisions between nations and social groups were impenetrable and perhaps most importantly, liberal enlightenment philosophy had not infected our psyche with its celebration of the ‘individual’.   Today we live in a world of ‘individualism’, a world suffused by information bearing other people’s perspectives; a world in which it is ever harder to be completely blind and unsympathetic to the experiences, and suffering of others.

But what does this have to do with software user experiences? I hear you say.  Well, one of the driving forces behind this incredible change in the fabric of our culture, over the past half a century, is what Pinker refers to as the ‘Rights Revolutions’.  I believe that the value we place on good user experience should be seen in the context of these revolutions.

I am asking the question: is a decent user experience a new human right?

The Rights Revolutions

So, what are these ‘Rights Revolutions’? And what do they have to do with user experience?  Well to quote Pinker:

“The efforts to stigmatize, and in many cases criminalize, temptations to violence have been advanced in a cascade of campaigns for ‘rights’ – civil rights, women’s rights, children’s rights, gay rights and animal rights”
From p458 of The Better Angels of Our Nature


Proportion of books mentioning phrases from 1945. From p459 of The Better Angels of Our Nature

This cascade is nicely illustrated by the graph below that shows the sequence in which these phrases have become popular.  There’s a momentum behind these changes, each rights revolution raises the bar, as to what is acceptable, setting the stage for the next move forward.  If it’s not right to racially discriminate, how can we be tolerating sexual discrimination?  If we can no longer mistreat children, why should we be able to mistreat animals?

These changes, Pinker suggests, are primarily driven by “the technologies that made ideas and people increasingly mobile”.  As people were increasingly brought into contact with other people’s perspectives, through fiction, through travel, through the sharing of ideas; it became increasingly hard to maintain that other peoples experiences didn’t matter.   We increasingly came to value the rights of the individual and to sympathise with their experience. That has driven and continues to drive important and largely positive changes to the world we live in.

The right to a decent user experience?

Nothing has been as powerful in driving the large scale improvement to the quality of user experience, as the web.  Businesses got the ability to make user experience changes relatively rapidly and see the big impacts to bottom line metrics.  Perhaps more importantly, users got the ability to easily switch over to whichever site offered them the best experience for getting what they wanted.

This commercial dynamic has, sadly, been far less successful at driving substantial improvement to the user experience of specialist business software – an area that RMA specialises in.  Sadly business software is still generally sold through bulk licensing arrangements and bought by IT managers or business folk more interested in ticking boxes than in the merits of good design, or the experiences of users.

I think this is something that needs to, and is about to change.  Just because someone isn’t immediately visible as a monetizable metric on a web analytics dashboard, doesn’t mean they don’t matter.  People who work at a job day-in day-out to get important things done, matter.  Their experience is important; perhaps more important, than those of the hordes of debt-laden e-shoppers.

Let’s face it, badly designed software can make people’s life pretty miserable; unnecessarily hard to learn tools that make you feel stupid, inefficient experiences that frustratingly waste time, confused designs that hinder rather than help you get things done, ugly jarring experiences that make life just that little bit greyer.

Thanks to the web and mobile app ecosystems people are almost universally exposed to good user experience – they know what they are missing in the software that plagues their work lives.  At RMA we are witnessing this rising tide of intolerance to bad design in enterprise software. People are rising up against it; we have seen them demanding more from their bosses, their IT departments and their services providers.  They are starting to side step restrictive IT restrictions by bringing in their own devices (BYOD) and using decently designed cloud based offerings.  B2B software houses are starting to increase their investments in UX and visual design. The tide is starting to turn.

There are many powerful, financially driven, arguments for investing in better user experiences; they increase productivity while decreasing support and training costs.  But I believe that we can perhaps help the tide turn faster if we start to reframe the need for change.

We need to help shape and nurture the awareness of the right for decent user experience in all those millions of business software users. And, perhaps, more importantly those of us who work on business products, need to build a culture in which it is simply not acceptable to ship bad user experiences.  Just as it isn’t acceptable to discriminate against employees, or to cheat your customers, it shouldn’t be acceptable to subject people to bad user experiences.

For better or worse, most of us live much of our lives in software; just as life is precious, so are experiences.