Three ways to buy
How you buy consulting shapes what you get. Fixed scope and time and materials both have their place. Problems start when you use one where the other fits. In practice there is a third model, milestone pricing, which combines the two and suits most implementation work.
| Topic | Fixed scope | Time and materials | Milestones |
|---|---|---|---|
| You pay for | A defined deliverable | Hours or days worked | Each accepted stage of a larger piece of work |
| Who carries estimate risk | The provider | You | Shared: the provider per stage, you across stages |
| Flexibility during the work | Low; changes go through change control | High; you can redirect at any time | Medium; scope can change between stages |
| What you need up front | A clear question and a recognizable deliverable | Trust and active management on your side | A clear first stage and an outline of the rest |
| Best for | Assessments, workshops, scoped builds | Exploration, staff support, unpredictable work | Implementation after an assessment |
When fixed scope works best
Fixed scope fits work with a clear question and a recognizable deliverable: an architecture assessment, a readiness scorecard, a decision workshop, a scoped build with acceptance tests. The buyer knows the price before starting and the provider carries the risk of its own estimate.
It works because both sides can describe the end state in a sentence and check whether it was reached. "A risk and cost register for our production AWS accounts, with a 90-day roadmap" is a fixed-scope deliverable. "Help us improve our cloud" is not.
Fixed scope also has a useful side effect: it forces the scoping conversation to happen before the work starts. What is included, what is not, what you must provide and how the result will be accepted all have to be written down. That conversation alone often clarifies what the buyer actually needs.
When time and materials is the honest choice
Open-ended work, such as exploring an unfamiliar system with no documentation or supporting a team through an unpredictable period, is hard to fix in advance. Forcing a fixed price onto it usually produces either a padded quote or a long list of change requests. Neither helps the buyer.
Time and materials is the honest choice when:
- The question itself is still unclear and the first job is to find it.
- The work depends heavily on decisions or inputs the provider does not control.
- You need extra hands on a known task, directed by your own team.
- The work is short enough that the cost of scoping it would exceed the cost of doing it.
The price of that flexibility is that you manage the work. Agree a weekly report of hours, progress and next steps, and a cap that triggers a conversation before it is exceeded.
A middle path that works
For most cloud, data and AI work, the best structure is a sequence: a short fixed-scope engagement first, then implementation in milestones.
- Assessment, fixed scope, two to four weeks. It produces the evidence needed to scope the next phase: current state, options, risks and a plan.
- Milestone 1, fixed per milestone. The first slice of implementation, with acceptance criteria written from the assessment.
- Further milestones, each scoped and priced once the previous one is accepted, using what it revealed.
You commit in steps, and each step is informed by the last. You can stop after any milestone with something that works, take the remaining work in-house, or change direction without renegotiating a large contract. Our note on why we sell a decision before a program explains why we start this way.
The risks of each, and how to manage them
| Model | Risk for the buyer | How to manage it |
|---|---|---|
| Fixed scope | A deliverable that meets the letter of the contract but not the need | Acceptance criteria written in terms of the decision or outcome, plus a mid-point review |
| Fixed scope | A padded price to cover unknowns | Provide access and information early so the provider can scope precisely; ask what assumptions drive the price |
| Time and materials | Work that expands without delivering | Weekly reporting against goals, a cap, and the right to stop at any time |
| Time and materials | Junior people learning on your budget | Name the people in the contract and agree how substitutions work |
| Milestones | Milestones defined as activities rather than results | Each milestone ends in something that can be tested or demonstrated |
What to put in the statement of work
Whatever the model, the statement of work decides most of what happens later. Six items prevent most disputes.
| Item | Vague | Clear |
|---|---|---|
| The question or outcome | "Improve cloud cost efficiency" | "Identify and rank the main drivers of AWS cost growth in production, with savings ranges and owners" |
| Deliverables and exclusions | "Recommendations report" | "Findings register, roadmap and executive briefing. Excludes implementation and purchase of commitments" |
| What you provide | "Client will cooperate" | "Read-only access to accounts X and Y by day 3; four interviews of 60 minutes in week 1" |
| Acceptance criteria | "To client satisfaction" | "Accepted when the register covers all production accounts and each item has evidence, impact and an owner" |
| Change control | "Changes by mutual agreement" | "Changes proposed in writing with effect on scope, time and price; nothing starts until approved" |
| Who does the work | "Qualified consultants" | "Named lead architect for the whole engagement; substitutions only with written approval" |
A provider who is comfortable writing those down is usually a provider who has done the work before.
Handling change without a fight
Change is normal. Discoveries during an assessment or a build often change what should be done next. What causes conflict is change that happens informally and is argued about later. A simple process avoids that:
- Either side raises the change in writing, with the reason.
- The provider states the effect on scope, time and price, including "no effect" when that is the case.
- The buyer approves or declines. Nothing changes until it is approved.
- The change is recorded in a running log attached to the statement of work.
Small changes with no effect on price still go in the log. Over a long engagement, the log is the shared memory of why the work ended where it did.
How to compare proposals
When proposals use different models, they are hard to compare on price alone. Score them on what actually predicts a good outcome.
| Criterion | What good looks like |
|---|---|
| Understanding of the problem | The proposal restates your question better than you did, and names what is out of scope |
| Deliverables | Concrete outputs with acceptance criteria, not activities |
| Assumptions | Listed explicitly, with what happens if one turns out wrong |
| People | Named, with the time each will spend; the person who scoped it does the work |
| Your effort | What you must provide, and when, is stated |
| Exit | You can stop at a defined point with something useful |
Example: the same need, three structures
A payments company wants to reduce cloud cost and prepare for a sponsor bank review. Three providers respond.
- Provider A proposes a large fixed-price program to "optimize and harden" the platform over six months. The price is certain, but the scope is vague and the assumptions are not stated. Change requests are likely from month two.
- Provider B proposes a team on time and materials, starting next week. Flexible, but nobody can say what will be delivered or when the work ends.
- Provider C proposes a three-week fixed-scope assessment, then implementation in milestones scoped from its findings, with the first milestone outlined and the rest to be priced as each is reached.
Option C is not always cheapest, but it is the only one where the buyer knows what the first commitment buys and can decide on the next one with evidence. For high-stakes work on a platform the provider has not seen yet, that is usually the structure that ends best for both sides.
Red flags in a proposal
- No exclusions. Every honest scope has things it does not include.
- Deliverables described as activities: "workshops", "analysis", "support".
- No mention of what you must provide, which usually means delays will be yours.
- Senior names in the proposal and unnamed people in the contract.
- A fixed price for work whose question is still unclear, without stated assumptions.
- A time-and-materials proposal with no cap, no reporting and no right to stop.
Questions we hear
Is fixed scope always more expensive?
Not necessarily. A good provider prices fixed scope on its real estimate plus a known risk margin. Time and materials can end up higher when the work expands, and lower when it goes smoothly. What fixed scope buys you is certainty.
Can we switch models during a project?
Yes, at a natural boundary such as the end of an assessment or a milestone. Switching in the middle of a deliverable usually causes disputes about what was already done.
What about retainers?
They suit ongoing advisory work with a defined cadence, such as a monthly governance review. Define what is included each month and how unused capacity is handled.
Who should write the acceptance criteria?
Both sides, before the work starts. The buyer knows what the result is for; the provider knows what can be tested.