On a fixed-price contract, every hour of unplanned work comes straight out of your margin. Scope creep rarely arrives as one big request. It shows up as a series of small, reasonable-sounding asks: an extra report format, a second training session, one more integration "while you're in there".

Each one is easy to say yes to. Together they can turn a profitable contract into a loss. This guide covers how to spot scope creep early, price changes properly, and keep the contract's own obligations from slipping.

Start with a baseline you can point to

You can't manage changes to scope you never wrote down. The baseline is the list of everything the contract commits you to, with each item tied to the clause it came from.

If you kept your RFP compliance matrix, you already have most of it. Add anything from the signed contract that wasn't in the RFP: negotiated terms, side letters, and the statement of work.

For each item, record:

  • The exact wording and its source clause
  • An owner on your side
  • A due date, if the contract sets one
  • The effort you estimated when you bid

When a customer asks for something, the first question is simple: is it on the list? If it is, it's your job. If it isn't, it's a change.

Is it a change or a clarification?

Not every new request is scope creep. Some are reasonable readings of vague requirements. A useful test:

Situation Usually
The request is in the baseline's wording In scope
The wording is vague and the request is a reasonable reading of it In scope, but write down the agreed reading
The request adds volume, frequency, formats, users, integrations or deliverables Change
The request moves a date earlier or adds a deadline Change
The request comes from someone who didn't sign the contract Confirm authority, then treat as a change

When it's genuinely unclear, agree on an interpretation with the customer in writing, then add it to the baseline. Ambiguity left unresolved tends to be settled later in the customer's favour.

Price the change from your own costs

Many teams price changes by gut feel or a flat day rate. A better method uses the same numbers you used to bid:

  1. Estimate the hours by role. Engineering, project management, support, training.
  2. Multiply by each role's cost rate. This is what an hour costs your company, not what you bill.
  3. Set the price from your target margin. The lowest price that keeps your margin is the cost divided by one minus the margin.

Here is a worked example with illustrative numbers. A customer asks for a second export format:

Role Hours Cost rate Cost
Engineering 20 $150 $3,000
Support 5 $80 $400
Total 25 $3,400

At a 35% target margin, the lowest price that holds the margin is $3,400 ÷ (1 − 0.35), or about $5,231. Quoting $3,400 "at cost" would mean doing the work for nothing. Quoting $4,000 would look generous and still pull the contract's average margin down.

Sometimes you'll choose to absorb a change for the relationship. That's a legitimate decision, as long as it's a decision. Log it with a price of zero and the reason, so the cost is visible.

Run every change through one process

A change process doesn't need to be heavy. It needs to be consistent:

  1. Log it against the requirement it changes, with the customer's request in their words and where it came from (an email, a meeting, a change order).
  2. Estimate and price it as above.
  3. Get approval from someone with authority on both sides before work starts.
  4. Update the baseline: the requirement's wording or date, the estimate, and the contract value.
  5. Keep the history. The original and the change should both stay on record.

The most common failure is step 3 happening after the work. Once the work is done, your negotiating position is gone.

Track the obligations that aren't deliverables

Scope creep gets the attention, but margin also leaks through obligations that were in the contract all along and simply got missed:

  • Monthly or quarterly reports
  • Service level reviews
  • Security audits and certifications
  • Training sessions and refreshers
  • Data retention and export on request

These are easy to forget because they recur and they belong to nobody in particular. Give each one an owner, a schedule, and a record of when it was done. A missed recurring obligation can cost more in credibility than a late feature.

Get sign-off as you go

The cleanest defence against a dispute is evidence of acceptance. When a deliverable is done, record:

  • The date the customer accepted it
  • Who accepted it
  • Where the evidence is: a sign-off email, a signed acceptance form, meeting minutes

Accepted work is closed work. Without acceptance, "done" stays open to reinterpretation, and reinterpretation is where scope creep lives.

A short checklist

  • Is there a written, sourced baseline of everything the contract requires?
  • Does every requirement and obligation have an owner?
  • Are changes priced from cost rates and a target margin, not gut feel?
  • Is approval given before work starts?
  • Is the contract value updated when a change is approved?
  • Is acceptance recorded with evidence?

If you can answer yes to all six, scope creep becomes a commercial conversation instead of a surprise. Mauby is built to keep that record for software vendors, from the first bid to the last deliverable.