Lesson 7.4: Scope creep, pricing and saying no
Small yeses add up to a missed date. Learn how scope creep happens, a change process, how pricing models shift risk, and how to say no well.
By the end of this lesson you will be able to keep a customer project inside its boundary without making the customer feel refused. You will learn how scope creep happens and why each small yes feels harmless, a four-step change process, three ways to price customer work and who carries the risk in each, a way of saying yes and no at the same time by showing the trade-off and a short checklist of what an agreement should say. You will see three projects, one of which was swallowed by requests, and use a simulator that shows how a stream of small requests turns into a slipped date. This lesson closes Module 7, on going from one customer to many. It follows 7.3, where you learned to prove the value of what you delivered, and it covers the commercial discipline that keeps that value deliverable at all. You do not need a business background. The ideas are explained from the start, though this lesson is practical guidance and not legal advice, and a real contract should be reviewed by the people in your company who handle them.
Almost every forward deployed engineer has had this experience. The pilot is going well. The customer is delighted, and in a weekly meeting someone says: "This is great. Could it also show the branch name? And could we export the list? Oh, and could the callers see the last three payments?" Each is small, each is reasonable, and each is exactly the kind of thing you want to say yes to, because yes feels like service. Six weeks later, the team is three weeks behind, the metric is untested and the customer is unhappy that the date has moved. No single yes caused it. The sum did.
What scope creep is
Scope creep is the gradual growth of a project's work beyond what was agreed, without a matching change to the time, the budget or the plan. The key word is without. A change to the scope that is assessed, agreed and paid for in time or money is a change, and perfectly healthy. What makes creep harmful is that it is unassessed: nobody decides, nobody counts the cost and the plan quietly stops being true.
It happens for understandable reasons.
People discover what they want as they see it. This is the very reason demos work, as Lesson 4.4 explained, and it produces a stream of ideas. Ideas are good. Acting on every one is the problem.
The scope was never clear. If the boundary was vague, every request sits in a grey area, and the engineer decides case by case, usually in favour of yes.
New stakeholders arrive. A new manager, a new team, a new priority brings new wishes that were not in the original plan.
The engineer wants to please. Saying yes is pleasant and builds goodwill now, at the price of trouble later.
Small requests seem free. A change that takes an hour looks costless, and no one counts the hours.
Nobody owns the decision. If no one is responsible for weighing a request against the plan, the default is to add it.
The first defence is the one you built in Lesson 2.3: a clear scope, with a written list of what is out. The rest of this lesson is about the second line of defence, which is a way of handling requests once the project is running.
The arithmetic of small yeses
The cost of a request is easy to underestimate, for a reason of arithmetic. Each request seems tiny against the whole project, so it is judged on its own size. But requests arrive steadily, and the cost accumulates in a straight line while the plan stays fixed.
Suppose that during a ten-week project, with a team of two, one and a half small requests arrive each week, each taking a day and a half. Over the project that is about twenty-two days of extra work. The team's total capacity, two people for ten weeks, is a hundred working days. The extra work is more than a fifth of the total, and the project is likely to slip by a week or more, even if every request seemed trivial.
The remedy is not to refuse all requests. It is to make their cost visible, so that each is a decision.
A four-step change process
A simple process turns creep into change. It is short enough to be used for small requests and firm enough to protect the plan. Agree it with the customer at the start, ideally in the one-page plan, so that it is a shared rule, not a reaction.
1. Capture. Write the request down, in the requester's words, and thank them. Put it on a visible list: the parking lot from Lesson 2.3, with a date and a name. This step costs a minute and shows the request was heard.
2. Assess. Estimate its cost in effort, time and risk, and what it would displace. Even a rough answer, "about two days, would delay the second language by two days", is far better than none. Sort it as a bug, a change or a new idea, as in Lesson 4.4. A bug, something that does not do what was agreed, is fixed under the existing plan.
3. Decide. The sponsor, or a named decision-maker, chooses: accept it and say what moves, defer it to the next phase or decline it. The decision belongs to the customer, with your recommendation. You do not decide alone, either to accept or to refuse.
4. Record. Write the decision, with the reason, on the plan, as a new version, and tell everyone affected. The record is your shared memory, and it settles later arguments about what was agreed.
For small requests, the process can be quick: a note in the weekly update and a yes or no from the sponsor. For larger ones, a short conversation. What matters is that every request goes through it, so that none is added silently, and that the cost is stated before the decision.
A small contingency, agreed in advance, helps. Many plans include a margin of, say, ten per cent of the effort, set aside for the unexpected. It lets you absorb a few small changes without renegotiating each, as long as you tell the customer how much of it has been used. When it is spent, the next change must come with a trade-off.
Predict first: in week six of a ten-week pilot, the head of collections says, "We would love a report by branch. It is a small thing." You estimate it at three days, and you are already tight on time. What do you say? Decide before reading on.
Say yes to the idea, and bring the cost into the conversation: "That is a good idea, and it is useful. It would take about three days. We are tight, so I can add it if we move something. Options are: push the second-language test by three days, drop the export list we planned, or add it to the next phase. Which would you prefer?" This is not a refusal. It treats her as the decision-maker and puts the choice in front of her. Most sponsors, shown the trade-off, either defer the report or pick what to give up, and in either case the project stays honest.
Yes, and here is the price
The most useful habit in this lesson is a shift of language. "No" and "yes" are both poor answers to most requests. "No" feels like rejection. "Yes" hides the cost. A better answer is "yes, and here is what it costs".
The pattern has three parts.
Acknowledge the value. "That would be useful."
State the cost in their terms. "It would take three days, which means the language test moves from the 20th to the 23rd."
Offer the choice. "Would you like to swap it for something, add it to the next phase, or extend the date?"
It works because it respects the customer's right to decide and your duty to tell them what they are deciding. It also protects the relationship: you did not refuse them, and they did not pay a price they did not know about.
There are some requests to which the answer is simply no, and Lesson 6.2 covered them: requests that break a security rule, promise a result you cannot back or damage the pilot's ability to measure anything. For those, say no plainly, explain why in the customer's terms and offer what you can.
Pricing: who carries the risk
A forward deployed engineer is not always the person who sets the price, but you need to understand how work is priced, because the model shapes how scope creep behaves. Three common models, and a fourth that is growing, are worth knowing.
Fixed price. The customer pays an agreed sum for an agreed scope. The customer knows the cost in advance, and the supplier carries the risk of overrun. It suits work with a clear, stable scope. Its weakness is that any change to the scope needs a new estimate or a change request, and if the scope was wrong at the start, there is little room to adapt. Fixed price makes scope creep painful for the supplier, which makes the supplier careful.
Time and materials. The customer pays for the actual hours and resources used. The customer carries the risk of overrun, and there is great flexibility. It suits work whose scope is unclear or likely to change. Its weakness is that without a strong process on the customer's side, requirements tend to grow, since each addition seems to cost nothing in negotiation. Time and materials makes scope creep painful for the customer, though they may not notice until the bill arrives.
Value-based or outcome-based pricing. The price is tied to the value the customer receives, such as a share of the savings or a fee that depends on reaching a target. It aligns the supplier with the customer's results. Its weakness is practical: it needs agreement on how value is measured, which Lesson 7.3 showed is not easy, and customers may be reluctant to share the financial information that requires.
Subscription or usage-based pricing. The customer pays a recurring fee, often per user or per amount of use, for the product, with the custom work either included or priced separately. This is common where a company sells a product and the field engineer's work is part of onboarding. It makes the long-term relationship, and therefore adoption and value, the thing that matters.
Model · Who carries overrun risk · Good for · Watch out forFixed price · The supplier · Clear, stable scope · Disputes about what is in scope, rigid when the scope was wrong
Time and materials · The customer · Unclear or changing scope · Growing requirements, unpleasant bills
Value-based · Shared · Measurable outcomes · Agreeing and measuring the value
Subscription or usage · Shared over time · Product with ongoing use · The cost of onboarding and custom work
Several of the sources describing these models note that the pricing label matters less than the change process. A fixed-price project with a clear process for changes behaves well, and a time-and-materials project without one drifts. Whatever the model, settle how changes will be handled before work begins.
The risk column in the table becomes concrete with numbers. Suppose the work overruns. Under a fixed price the customer pays the same and the supplier's margin shrinks. Under time and materials the supplier is paid for the extra days and the customer's bill grows. Try an overrun and see who feels it.
At the defaults, a 100-day plan at ₹20,000 a day is a ₹20 lakh fixed price, and with a 25 per cent overrun the supplier's margin falls from about ₹8 lakh to about ₹5 lakh. Under time and materials the customer's bill rises from ₹20 lakh to ₹25 lakh and the supplier's margin rises to about ₹10 lakh.
Pricing a pilot
A particular question for forward deployed engineers is whether a pilot should be paid. There are arguments on each side.
For a free or discounted pilot: it lowers the customer's barrier, speeds the start and may win a larger contract.
For a paid pilot: a customer who pays has a stake. They provide the data on time, assign people and take the result seriously. A free pilot is easy to deprioritise, and it signals, to the customer and to your own team, that the work is worth little.
Many companies settle on a modest, paid pilot, with a clear scope, a success metric and a decision at the end about the larger work. Where a pilot is free, it helps to ask for commitments in exchange: named people, data by a date and a decision date. Whatever the price, the scope discipline in this lesson applies equally, because a free pilot attracts requests more readily than a paid one.
The price should connect to the value. A pilot that is expected to produce ₹48 lakh a year in value can bear a price that would be absurd for one expected to produce ₹5 lakh. Lesson 7.3's measurement is what lets you have that conversation honestly.
What an agreement should say
Most of the protection against creep is written down before the work starts. You may not draft contracts, and your company has people who do, but you should know what a good agreement says, because you will live with it. In particular, check that it covers the following.
The deliverables. What will be delivered, in specific terms, and what is excluded.
Acceptance criteria. How the customer will decide it is done: the metric, the test, the date.
Assumptions and dependencies. What the customer must provide, such as data by a date, access, named people and reviews, and what happens to the schedule if they are late.
The change process. How requests are assessed, decided and priced, and who has authority to agree to them.
The schedule and the milestones. With dates, and the effect of changes.
Payment terms. Linked to milestones where possible, so that both sides have a reason to keep moving.
Warranty and support. How long defects are fixed at no charge, and what support continues, as in Lesson 5.4.
Ownership and reuse. Who owns what you build, and what may be reused for others, as Lesson 7.1 noted.
If something important is missing, raise it with your commercial colleagues before work starts, not after. A short clause that says "requests outside the agreed scope will be estimated and agreed in writing before work begins" is among the most valuable sentences in any statement of work.
Worked example 1: the lender and the eight small requests
During the lender's ten-week pilot, requests arrive: a branch column, an export button, the last three payments on screen, a different greeting in the messages, a second report, a filter by language, a change to the colour of the groups and a weekly email summary. The engineer says yes to each, since each takes a day or two.
By week eight, about seventeen team-days of unplanned work have been added to a plan of eighty. The language test has been delayed twice, and the pilot's start of the measured period is three weeks late. The head of collections, who made most of the requests, is surprised and unhappy: "Why is it late?"
The engineer reconstructs the list and shows it to her. She had not realised that the requests together amounted to more than three weeks. They agree a reset. The request list becomes visible in the weekly update, each item with a cost. Three items are kept, two moved to the next phase and three dropped. The pilot recovers two weeks. The lesson the head of collections draws is her own: "I should have asked what each one cost." Nothing was wrong with her requests. What was missing was the price.
Worked example 2: the fixed-price pilot with a fuzzy scope
A company agrees to deliver a support assistant pilot to a bank at a fixed price. The statement of work says the assistant will "answer customer questions about accounts". It does not say which questions, which channels, which languages or how accuracy will be judged.
The bank's team reads this broadly: all questions, in English and Hindi, by chat and email. The supplier reads it narrowly: the twenty most common questions, in English, by chat. Neither is wrong, and the gap is large. In week four the bank asks why Hindi is missing. The supplier says it was never in scope, and the bank says "questions about accounts" meant all of them.
The dispute takes three weeks, costs goodwill and ends with a compromise that leaves both sides feeling they paid for the misunderstanding. The cause was the scope, not the engineers. The fix, for the next contract, is a scope that lists the question types, the languages, the channels and the accuracy test on a real sample, and a change process for anything else. A day spent on the scope at the start would have saved three weeks.
Worked example 3: value-based pricing done carefully
A logistics company wants a delivery-delay prediction pilot. The supplier proposes a lower fixed fee for the pilot and a fee for the rollout that depends on the measured reduction in late deliveries, with a cap and a floor. Both sides agree how the reduction will be measured before the pilot begins: the share of deliveries more than two hours late, in the pilot depots against matched depots, using the company's own delivery records.
Because the measurement is agreed in advance, and the data belongs to the customer, there is little to argue about when the result comes. The pilot cuts late deliveries by a fifth in the pilot depots. The rollout fee is calculated from the agreed formula, and the customer's finance team, which had checked the method in advance, approves it without a dispute. The arrangement also changes behaviour: the customer provides data promptly and takes the dispatch changes seriously, since the result affects what it pays.
The case shows the condition for outcome-based pricing to work: agree the measure, the baseline and the data source up front, and put them in writing. Without that, a value-based price becomes a long argument about what the value was.
How many small requests can the plan absorb?
You can see the effect of requests on a date in numbers. A project has a capacity in team-days, the number of people times the working days. A contingency sets aside part of it. Requests consume effort at some rate. Once the contingency is spent, every further day of requests delays the project by that day divided by the team's size.
The simulator below does the arithmetic. Set the planned length of the project, the team size, the contingency as a share of capacity, the number of small requests arriving each week and the average days each takes. It shows the extra work, the contingency available and the slip in weeks if every request is accepted, and plots the slip as the request rate grows.
The model is simple. It treats requests as steady, which they are not, and ignores the cost of switching between tasks, which makes real requests dearer. But it shows how a stream of small items becomes a date, which is the point to put in front of a sponsor.
Try three experiments. First, keep the defaults and read the slip. Second, raise the contingency to 20 per cent and see how much room it buys. Third, raise the requests to three a week and see how quickly even a generous margin disappears.
At the defaults, a ten-week project with two people has a hundred team-days of capacity and ten of contingency. One and a half requests a week at a day and a half each is 22.5 team-days, so the contingency covers 10, and the remaining 12.5 days slips the date by 1.25 weeks. If the rate rises to three requests a week, the extra work is 45 days and the slip is 3.5 weeks. The arithmetic gives you a number to show: not "we are busy", but "the requests so far add up to a week of delay".
Common mistakes
A vague scope. Write what is in, what is out, how success is judged and what the customer must provide.
Saying yes to be nice. Say yes to the idea and state the cost.
Saying no flatly. Offer the trade-off, and let the customer decide.
No visible list. Keep a parking lot, with costs, in the weekly update.
Deciding alone. The sponsor decides, with your recommendation, and the decision is recorded.
Ignoring contingency. Set one in the plan, and report how much of it is used.
Treating the price model as the answer. Whatever the model, agree the change process before you start.
Free pilots with no commitments. Ask for named people, data by a date and a decision date.
Unclear acceptance. Agree how success will be judged, in writing.
Leaving the contract to others entirely. Know what it says, and raise gaps before work begins.
Key takeaways
Scope creep is unassessed growth of the work without a change to time or budget. It comes from discovery, vague scope, new stakeholders, a wish to please and the illusion that small requests are free.
Small requests add up in a straight line while the plan stays fixed. Make their cost visible so that each is a decision.
Use a four-step change process: capture, assess, decide, record. The customer's sponsor decides, with your recommendation, and a small contingency helps.
Answer "yes, and here is the price": acknowledge the value, state the cost in their terms and offer a choice. Say a plain no only to requests that break rules or promise what you cannot back.
Pricing models shift who carries the risk: fixed price puts it on the supplier, time and materials on the customer, and value-based and subscription pricing share it. The change process matters more than the label.
Agree scope, acceptance criteria, dependencies, the change process, milestones, warranty and ownership before work begins, with your company's commercial team.
Check yourself
1. What makes scope creep harmful, as opposed to a healthy change?
It is unassessed: nobody decides, counts the cost or changes the time, budget or plan, so the plan quietly stops being true.
2. Name the four steps of the change process.
Capture, assess, decide and record.
3. A customer asks for a three-day report in a tight week. What do you say?
Say yes to the idea, state the cost and what it would move, and offer the choice: swap it for something, add it to the next phase or extend the date.
4. A project of 8 weeks with 3 people has 10 per cent contingency, and 1 request a week of 2 days arrives. How much slip results?
Capacity is 120 team-days, contingency 12. Requests add 16 days, so 4 days exceed the margin. 4 ÷ 15 is about 0.27 weeks.
5. In which pricing model does the supplier carry the overrun risk, and in which the customer?
In fixed price the supplier carries it. In time and materials the customer does.
Try this
This exercise takes about forty minutes and gives you a change process and a scope check. Use a real project, or imagine one.
1. List at least six requests that might plausibly arrive in a project, such as a new column, an export, a second language or a new report.
2. For each, estimate the effort in days and what it would displace, and mark it as a bug, a change or a new idea.
3. Add up the effort, and use the simulator to see the slip if all were accepted with your plan's contingency.
4. Write the "yes, and here is the price" response for the three requests that matter most.
5. Write a four-step change process in one paragraph, with who decides, that you could put into a one-page plan.
6. Write the scope of a project in five lines: what is in, what is out, how success is judged, what the customer provides and what happens if they are late.
7. Choose a pricing model for the project and write who would carry the overrun risk and what you would watch.
8. Write three clauses you would ask your commercial team to include.
A good result is a request list with costs, a slip figure, three "yes, and the price" answers, a change process, a five-line scope and three clauses. It completes Module 7: you can now spot what belongs in the product, carry it to the people who build it, prove the value and keep the work inside its boundary. Module 8 turns to practice and career.
Sources
[Time and Materials vs Fixed Price: Key Differences and Use Cases](https://reliasoftware.com/blog/time-and-materials-vs-fixed-price) and [Pricing Projects As A Freelancer Or Agency Owner](https://smashingmagazine.com/2024/08/pricing-projects-freelancer-agency-owner/). Used, with other summaries, for the descriptions of fixed price, time and materials and value-based pricing, who carries the risk in each and the point that the change-request process matters more than the pricing label. These are practitioner articles and search summaries, and I did not read them in full.
The three projects, the request list, the figures and the simulator's defaults are the author's illustrations for teaching, not data from real companies. The four-step change process and the agreement checklist are practical guidance written for this lesson, not industry standards. This lesson is not legal advice, and contracts should be reviewed by the people in your company who handle them.
Tags: Forward Deployed Engineer Scope creep Pricing Change control Negotiation