Strategy
Choosing the Right Engagement Structure
Written by Jeff Lombard · Last Updated:
Download PDF
The commercial structure of a technology engagement is not an administrative detail. It shapes incentives, decision-making, risk ownership, and the quality of the resulting work.
The wrong structure can make a capable team look ineffective. It can reward activity instead of outcomes, discourage necessary changes, or transfer risk to the party least able to manage it.
There is no universally superior engagement model. The right choice depends on what is known, what remains uncertain, how quickly priorities may change, and how involved the client wants to be in delivery.
The objective is not to select the contract that appears cheapest. It is to create the conditions under which both parties can make good decisions while the cost of correction is still low.
Start With the Nature of the Work
Before choosing an engagement structure, answer four questions:
- Can the desired outcome and required scope be defined confidently?
- How likely are priorities or requirements to change?
- Who is best positioned to make day-to-day trade-offs?
- Which party should carry the financial consequences of uncertainty?
When scope is stable, a fixed commitment can work well. When the work involves discovery, complex systems, or changing market conditions, flexibility becomes more valuable than the appearance of certainty.
The engagement model should reflect reality. It should not require both parties to pretend uncertainty does not exist.
Time + Materials
In a time-and-materials engagement, the client pays for the capacity used. Priorities and scope can change as the team learns.
This is usually the most flexible structure. Work can be redirected without renegotiating the entire agreement, making it appropriate for discovery, product evolution, legacy systems, and technically uncertain environments.
The trade-off is that the client carries most of the budget risk. CX.dev is responsible for using time effectively and making progress visible, but the total cost depends on the decisions made during delivery.
Time and materials works best when the client has strong product ownership and can make timely priority decisions. Without that involvement, flexibility can become drift: the team remains active, but there is no reliable mechanism for deciding what matters most.
The model should be selected because uncertainty is real and learning is valuable—not because the work was never properly defined.
Fixed Fee, Fixed Scope
A fixed-fee engagement establishes defined deliverables, a delivery schedule, and an agreed price before implementation begins.
This structure provides high budget predictability and requires relatively low client involvement during delivery. It works well for migrations, integrations, compliance work, and builds where requirements, dependencies, and acceptance criteria can be established with confidence.
CX.dev assumes more delivery risk under this structure. That risk is reflected in the price. A responsible fixed-fee proposal must account for uncertainty, coordination overhead, and the cost of conditions that may differ from the original assumptions.
Fixed scope creates stability, but it also reduces the speed of change. Once delivery begins, substantial changes require an explicit review of cost, schedule, and downstream consequences.
This is not unnecessary bureaucracy. It protects the integrity of the original commitment.
Fixed fee is a strong model when the problem is understood. It becomes fragile when used to create artificial certainty around work that is still being discovered.
Retainer
A retainer reserves ongoing access to a defined amount of CX.dev capacity or expertise for a recurring fee.
Unlike a fixed project, a retainer does not require the entire scope to be decided in advance. The client can direct capacity toward the most important work as needs evolve.
Retainers are useful for continuous product improvement, technical advisory, fractional leadership, maintenance, and access to specialists who would be difficult to justify as full-time hires.
The model provides continuity and predictable access while avoiding the repeated setup cost of separate projects. It also allows CX.dev to develop context over time, reducing the knowledge loss and coordination cost associated with frequently changing vendors.
The client generally retains responsibility for prioritization. CX.dev can advise and challenge decisions, but the client determines where the reserved capacity is applied.
A retainer is most effective when there is a consistent flow of meaningful work. If priorities are unclear or internal decisions are repeatedly delayed, reserved capacity may go unused or be directed toward low-value activity.
Managed Services
In a managed-services engagement, CX.dev assumes responsibility for an agreed product, system, or operational outcome.
The distinction is not simply that CX.dev supplies people. We steer prioritization, allocate resources, manage technical trade-offs, and determine how available capacity should be used to support the agreed objectives.
This structure is appropriate when the client wants accountability for outcomes without managing the daily mechanics of delivery. It reduces the need to coordinate individual contributors, assign work, maintain delivery processes, or resolve every technical decision internally.
Managed services transfer more execution risk to CX.dev. They also require a clear mandate. CX.dev must have enough authority to make the decisions for which it will be held accountable.
The client remains involved in business direction, constraints, and major decisions, but routine prioritization and resource allocation sit with CX.dev.
Managed services generally carry a higher relative cost than capacity-based structures because they include delivery leadership, operational coordination, and broader accountability. The comparison should account for the internal management burden being removed—not only the external fee.
Agile Outcome Contract
An agile outcome contract combines an expected delivery period and prioritized scope with the ability to adapt as the work progresses.
CX.dev and the client agree on the intended outcome, establish an initial backlog, and estimate the expected period of delivery. Work is then completed incrementally, with the highest-value items addressed first.
At agreed intervals, the client can change priorities or exchange unstarted features for work of comparable effort. This allows new information to improve the product without automatically increasing the total commitment.
If CX.dev achieves the desired outcome earlier than expected, the client has two options:
- Continue through the agreed period and apply the remaining capacity to additional features.
- Conclude the engagement early by paying a previously agreed termination fee.
This structure is influenced by Jeff Sutherland’s “Money for Nothing” and “Change for Free” approach to Scrum contracts.
The early-completion fee aligns incentives. The client saves money by stopping once additional development no longer creates sufficient value. CX.dev shares in the benefit of delivering the outcome efficiently instead of being rewarded for consuming the full schedule.
This structure requires significant client involvement. The client must participate in prioritization, provide timely feedback, and make decisions at the end of each delivery cycle. If that participation is absent, the mechanisms that make the model work begin to fail.
Agile outcome contracts are best for situations where the outcome is understood but the exact feature set should evolve through learning.
Comparing the Structures
| Engagement structure | Relative cost | Risk ownership | Budget predictability | Speed to change | Client involvement |
|---|---|---|---|---|---|
| Time + Materials | Low–Medium | Primarily the client | Low–Medium | Very high | High |
| Fixed Fee, Fixed Scope | High | Primarily CX.dev for the agreed scope | Very high | Low | Low |
| Retainer | Low–Medium | Shared; prioritization risk primarily sits with the client | High | High | Medium–High |
| Managed Services | High | Primarily CX.dev within the agreed mandate | High | High | Low–Medium |
| Agile Outcome Contract | Medium–High | Shared between CX.dev and the client | Medium–High | Very high | Very high |
Relative cost reflects the risk, responsibility, and coordination included in each structure. It does not predict the final cost of an engagement. A model with a higher apparent price may produce a lower total cost by reducing internal overhead, preventing rework, or identifying the point at which further development no longer creates value.
Choose Based on the Risk You Need to Control
Choose time and materials when flexibility is more valuable than total-cost certainty and the client can actively direct priorities.
Choose fixed fee and fixed scope when the work is well understood, the requirements are stable, and the client wants a predictable commitment with limited involvement.
Choose a retainer when continuity and dependable access matter more than completing a single predefined project.
Choose managed services when the client wants CX.dev to own prioritization, resource allocation, and day-to-day execution within a clearly defined mandate.
Choose an agile outcome contract when the outcome is clear but learning should determine the final feature set—and when both parties are prepared to participate actively in the process.
The Contract Should Support the Work
Engagement structures fail when they reward behavior that conflicts with the desired outcome.
A flexible project placed inside a rigid contract creates change disputes. A fixed project treated as open-ended work undermines predictability. A managed service without decision authority creates accountability without control. An agile contract without client participation becomes time and materials with additional ceremony.
The commercial model should make the right behavior easier:
- Important work is prioritized first.
- Risk becomes visible early.
- Decision ownership is explicit.
- Changes are evaluated before they create downstream cost.
- Neither party benefits from unnecessary dependency or delay.
At CX.dev, we select engagement structures based on the conditions required for reliable execution. The goal is not to move risk around on paper. It is to place responsibility with the party best equipped to manage it—and build an operating structure that remains coherent when conditions change.