Contracts & Procurement
Choosing a pricing structure for technology work
When an agency should buy on a fixed price, when time and materials fits, and how to manage each.
Technology contracts are usually priced one of two ways. Each allocates risk differently, and choosing the wrong one for the work creates friction and cost.
Fixed price
The vendor delivers a defined scope for a set price. The agency gets budget certainty; the vendor bears the risk of underestimating.
Fits when the scope is clear and stable: a defined migration, a specified integration, an assessment with a known boundary. Requires a precise statement of work, objective acceptance criteria, and a change process for anything outside them.
Goes wrong when requirements are vague. Vendors either pad the price to cover uncertainty or resist every change. If the agency cannot write testable requirements, it is not ready for a fixed price.
Time and materials
The agency pays for hours worked at agreed rates, usually with a not-to-exceed ceiling. The agency bears the risk of the work taking longer.
Fits when the scope is exploratory or will evolve: discovery, prototyping, ongoing support, staff augmentation. Requires transparent reporting and an agency manager who actively directs the work.
Goes wrong when nobody manages scope and the ceiling becomes the target.
Hybrid structures
Agile development is often bought as fixed-price increments: each release scoped and priced separately, giving budget certainty per release and flexibility across the program. Support agreements often combine a fixed monthly fee for defined services with hourly rates for extra work.
What to require regardless
Stated assumptions, testable acceptance criteria, a change process, and reporting that shows progress against plan.
Questions to ask a vendor
How they arrived at the price, what assumptions it depends on, what happens if an assumption fails, and how they report progress. A vendor who can answer clearly is managing the risk; one who cannot is passing it to the agency.