80% Outsourcing overruns happen not because of a high rate, but because of risk and change management. The contract model reflects how risk, flexibility, and incentives are distributed between the client and the contractor. Fixed Price In this model, the price, scope, and deadlines are fixed before work begins.
Suitable when requirements are stable and easy to verify. Pros: a predictable budget, minimal operational oversight. Cons: - High risk premium in the price - an extra margin the contractor builds into a fixed quote to cover uncertainty; - formal Change Request (CR) - any changes require an official request and approval, which slows work and increases project cost. How to strengthen the model: - Set strict acceptance criteria in the requirements specification. - Fix the CR rate card and the "change corridor" - the boundaries within which the team can change scope, timelines, or budget without renegotiating the contract or going through lengthy CR procedures. - Run weekly reviews to detect deviations early.
Fixed Price works for clear, well-bounded tasks - as-is migration, development of individual modules, audits, and pilots with a clear readiness criterion. Time & Materials (T&M) In this approach, you pay for actual hours and materials at a fixed rate.
You take on the financial risk of scope in exchange for maximum flexibility. Pros: fast start, easy priority changes, low risk premium.Cons: Without disciplined requirements and a steady release cadence, the budget will drift out of control. How to strengthen the model: - Set NTE, the hour cap per iteration/quarter. - Get a weekly report on monthly budget burn rate. - Review change decisions every week. - Set up financial incentives tied to target metrics: the contractor gets a bonus for meeting or exceeding agreed KPI and a penalty for missing them.
T&M is cheaper than fixed price when management is disciplined. It is suitable for research, product development, and integration with unknown dependencies. Retainer/Subscription support In this model, a fixed monthly fee is set for a pool of hours or services: maintenance, support, and enhancements within the package.
Often used in support and IT services. Pros: a stable team and predictable payments. Cons: - risk of hour underutilization - actual time used is less than what is paid for; - lack of transparency if there is no SLA and no service catalog. How to strengthen the model: - Create a service catalog. - Agree to carry unused hours over to the next month. - Set SLA for response/recovery time, priorities, and reporting.
Retainer-based support works well for a steady flow of small tasks when there is a clear SLA and service catalog. Managed Services is an SLA-based service contract. With this model, the vendor is responsible for service outcomes such as availability, MTTR, and throughput.
Suitable for operating and supporting critical systems. Pros: payment for results, not process, with a clear penalty system. Cons: a mature client-side service is needed, with a service catalog, monitoring, and incident tracking. How to strengthen the model: - Introduce a multi-level SLA by priority. - Create a catalog of standard work with out-of-package pricing. - Agree on who will calculate the metrics and how. - Set penalties for underperformance. Managed Services is the most stable model.
Its success depends on well-designed SLA and transparent metrics. Dedicated Team - a team tailored to you. You get a dedicated team with fixed rates, managed by you either independently or together with the vendor.
This model works when you need to scale a team quickly, for long-term product development, or to access rare skills. Pros: rapid scalability, control over culture and practices. Cons: - efficiency risks shift to you, so you need strong management of goals, deadlines, and value, plus control over technical quality and implementation approach; - dependence on specific people. How to strengthen the model: - Set performance KPI - speed, defects. - Prohibit rotations without approval. - Agree on timelines for replacing key roles. - Maintain a knowledge base, documentation, and onboarding.
Dedicated Team works best for a mature client: you save on speed and quality, but you are responsible for management.
Outcome-Based - pay for results In this model, you pay the contractor when a measurable outcome is achieved: "% migration", "putting the module into production". Pros: payment for value, with strong contractor motivation. Cons: difficulty formalizing the metrics baseline and attributing results. How to strengthen the model: - Agree with the contractor on how the result will be measured. - Perform independent verification. - Clearly define what you must provide - access, test data.
Outcome-Based works well as an add-on to Fixed Price or T&M: you pay for key milestones. Risk allocation matrix
| Model | Risk of budget overspend | Risk of getting the wrong result | Scope change flexibility | Implementation complexity |
|---|
| Fixed Price | Low/medium, built into the price | Medium due to a rigid specification | Low | Medium |
| T&M | High, if there are no constraints | Medium/low | High | Low |
| Retainer | Medium - underuse or overspend of the pool | Medium | Medium | Low |
| Managed Services | Medium - penalties/credits | Low service quality | Medium | High |
| Dedicated Team | Medium/high, the client is responsible for efficiency | Medium | High | Low |
| Outcome-Based | Low/medium | Low with clear metrics | Medium | High |
How to choose a model: a quick framework The decision depends on three factors: requirement stability, the criticality of deadlines and quality, and the team's readiness to manage change. 1. Requirements are clear, scope is limited: choose Fixed Price for a module or phase with a change-request grid. 2. Many unknowns, fast progress needed: T&M with an NTE cap per sprint/quarter and a weekly CR board. 3. Stable support/operations: Managed Services/Retainer with a multi-level SLA.
4. Need to scale development quickly: Dedicated Team with performance KPI.
