Fixed-price or time-and-materials TMA: choosing the right model

When you hand over the maintenance of an application, the question of price hides another one: what does the provider commit to? On a fixed price, it commits to a scope and service levels; on time and materials, to skills and time; with work units, to a price list per type of request. None of these models is better in itself. This guide explains what each one commits to, which work it suits, and how to combine them in a single contract.

It is aimed at executives, CIOs and buyers who are preparing or renegotiating an application maintenance contract (TMA, third-party application maintenance). You will not find a daily rate or a “usual” percentage here: they depend on the application and are negotiated. You will find what you need to choose the model before comparing prices.

Fixed price, time and materials, work units: what are we talking about?

The terms vary from one provider to another, but TMA is paid for in three ways. What sets them apart is not the amount: it is what the provider commits to deliver, and who bears the risk when the volume of work changes.

French public procurement law recognises only two forms of price, and the distinction also sheds light on private contracts. Under Article R2112-6 of the French Public Procurement Code, prices are either “unit prices applied to the quantities actually delivered or performed” or “lump-sum prices applied to all or part of the contract, whatever the quantities delivered or performed”. Measured against this text, time and materials and work units are unit prices: you pay for what has been done. A fixed price belongs to the second family. And the words “all or part” allow a lump sum to cover only part of a contract, with the rest paid at unit prices.

Fixed price: predictable, if the scope is known

On a fixed price, you pay a set amount per month or per year, and the provider takes on a scope described in the contract: the applications and environments covered, the types of work included, the service levels. Whether the month brings three defects or thirty, the invoice does not change. It is the model that gives the best budget visibility, and the only one that naturally lends itself to guaranteed response times: the provider commits to a result and organises its resources to deliver it.

This predictability comes with a condition: the provider must know the application before committing. Without reading the code, it has only two options, covering itself with a margin or underestimating, and both are paid for later. Hence the value of an audit or a transition period before regular operation. The CCAG-TIC, the general administrative terms for French public IT contracts, caps this transition at six months in contracts that refer to it (Article 38); a private contract sets its own freely.

A fixed price has two limits. Anything outside the scope is handled separately: the same text provides that maintenance operations not foreseen in the contract may only be carried out with the contractor’s agreement (Article 39). And a badly sized fixed price costs you both ways: too broad, you pay for capacity you do not use; too tight, every request becomes a discussion about what is included.

Four points to check in a fixed-price contract.

• What is included, type of work by type of work, and what triggers a quote.
• The rule that separates a defect, which is covered, from an evolution, which is billed separately.
• The service levels: response times, coverage hours, measurement, and the consequence if they are not met.
• The report that shows what the fixed price actually covered, and the date on which its amount is reviewed.

Time and materials: flexible, with the steering on your side

On time and materials, you pay for the time spent by the provider’s staff, based on a daily or hourly rate. The provider commits to resources: skills, availability, continuity in case of absence. It commits neither to a result nor to a volume of work delivered: if an evolution takes twice as long as planned, you pay the difference.

Time and materials suits needs that are hard to describe in advance: evolutions decided as you go, a gradual rebuild, an application whose scope keeps moving. It also suits a lasting reinforcement of an existing team: that is the model of dedicated developers. On the other hand, it requires someone on your side to express needs, set priorities and approve the work: without that steering, time gets used up with no direction. If nobody holds that role in-house, a part-time technical director can take it on.

It is poorly suited to response-time commitments on incidents. A provider that supplies time can commit to the availability of its teams, rarely to the time it takes to restore your application. If that time matters, it is an argument for putting at least corrective maintenance on a fixed price.

Four safeguards make time and materials easy to read.

• A cap per month or per batch, beyond which nothing is done without your agreement.
• An estimate before each significant request, then compared with the actual time.
• A detailed time report per request, not a total per person.
• A regular meeting where priorities are set and consumption is reviewed.

Work units: a price list in between

The work-unit model, also called a ticket book, starts from a price list: each type of request is worth a number of units set in advance. You buy a volume of units; each request is classified in the price list, costed in units, approved by you, then deducted from the balance. The cost of a request is known before it starts, as with a fixed price; the total volume follows your needs, as with time and materials.

Everything rests on the price list. To be useful, it must give, for each type of request, a description and an example taken from your application; otherwise every estimate becomes a negotiation. Prepaid time, a volume of hours bought in advance and deducted at the time actually spent, is a simpler variant: it protects the overall budget, not the price of each request.

What the contract must specify:

• The price list: the types of request, the number of units for each, a concrete example for each.
• Who classifies a request in the price list, and how a disagreement is settled.
• How long the units remain valid, and what happens to unused ones: carried over, refunded or lost.
• Tracking of the balance, request by request, in the ticketing tool.
• A review of the price list after a few months, based on the requests actually handled.

Choosing according to the type of work

The right reflex is to start from the work, not from the contract. The CCAG-TIC distinguishes four types of maintenance (Article 38): preventive, corrective, adaptive and evolutive. They are not forecast in the same way, so they are not paid for in the same way.

One boundary matters more than the others: the one between corrective and evolutive work. A defect is a gap between what the application was supposed to do and what it does; an evolution changes what it must do. When the two are not paid for in the same way, this rule must be written down, along with the name of whoever decides in case of doubt. Our guide to evolutive maintenance details this boundary.

The mixed model: a fixed-price base, evolutions paid separately

The answer is not necessarily “fixed price or time and materials”: it can be “fixed price and something else”. The easiest scheme to read puts preventive and corrective work on a fixed price, with service levels, and pays for evolutions separately: in work units if they are similar, on capped time and materials or by quote if they are projects. You keep a fixed budget for what keeps the application running, and a budget you can steer for what moves it forward.

The model is reviewed over time. At the start, when the provider is discovering the application, the real volume is unknown; after a few months of tracked requests, it can be read in the ticketing tool, and both the fixed price and the price list can be adjusted. Set in the contract the date of this review and the figures it will be based on. Our guide to outsourcing your application maintenance describes the steps of this start-up phase.

The questions to ask before signing

• Do you know the volume of your requests over the last twelve months, by type of work?
• Is the application’s scope stable, or will it change a lot?
• Do you need a guaranteed response time on incidents, and over which hours?
• Who, on your side, sets priorities and approves requests?
• Does the provider already know the code, or is an audit and a transition period needed?
• What happens to anything not used: time, units, fixed-price capacity?
• On what date, and based on which figures, is the model reviewed?

Whichever model you choose, the other clauses do not change: scope, security, code ownership, reversibility. Our guide to the application maintenance contract reviews them.

Frequently asked questions

A model is chosen, then reviewed

Fixed price, time and materials or work units: the choice is made type of work by type of work, based on what you know about your application, and it is reviewed when you know more. A fixed price buys predictability, time and materials flexibility, the price list a little of both. What matters is that the contract clearly states what is paid for, what is committed to, and how the model evolves.

iones’ application maintenance is based on an adjustable fixed price, tracked by a consumption report, and the nearshore team can also reinforce yours on time and materials, with dedicated developers. To find out which model suits your application, write to us.