The Client Changes Their Mind, but the Deadline Doesn't - How to Manage Scope Changes, Document Agreements, and Renegotiate Deadlines Without Delivering Three Projects for the Price of One ebook

Cover

The Client Changes Their Mind, but the Deadline Doesn't

How to Manage Scope Changes, Document Agreements, and Renegotiate Deadlines Without Delivering Three Projects for the Price of One

Max Paradox

PROBLEM? RELAX. YOU'VE GOT THIS!

ISBN: 978-83-8483-758-0

ALL-IN Rafał Płonkowski

Table of contents

Title page

INTRO

Chapter 1 - Where Does a Small Revision End and a Second Project Begin?

Chapter 2 - Why Clients Change Their Minds After Approving Everything

Chapter 3 - The Price of Being Agreeable: When "Of Course" Becomes an Unpaid Contract

Chapter 4 - Fighting Fire with More Fire: Why Heroic Project Rescues Often Fail

Chapter 5 - Everything Is Urgent, Including the Things Nobody Needs

Chapter 6 - Approved, Except for Everything: The Review That Never Ends

Chapter 7 - The Agreement Is Somewhere: How Projects Lose Decisions Between Emails, Calls, and Chat Messages

Chapter 8 - The Invisible Invoice: Where Your Project Profit Goes When Changes Are Free

Chapter 9 - From "Could We?" to a Real Change Request: The Art of Asking Before Acting

Chapter 10 - How Heavy Is One Change? Measuring Its Impact Before the Deadline Breaks

Chapter 11 - The Deadline Is Not Sacred: How to Renegotiate Time Without Losing the Client

Chapter 12 - The Cost of Saying Yes: How to Charge for Changes Without Apologizing

Chapter 13 - Who Can Actually Say Yes? Decisions Without Guessing the Organization Chart

Chapter 14 - Approved Doesn't Mean Implemented: Getting a Change Into the Real Project

Chapter 15 - When the Client Holds All the Cards: Negotiating Without the Luxury of Walking Away

Chapter 16 - When the Project Has Already Gone Off the Rails: Recovery Without Pretending Everything Is Fine

Chapter 17 - Waiting for an Answer: When the Client's Silence Becomes a Project Risk

Chapter 18 - The Boring Miracle of Staying Organized: Making Change Control Part of Everyday Work

Chapter 19 - The Return of "Just This Once": Recognizing Scope Creep Before It Takes Over Again

Chapter 20 - The Client Will Change Their Mind Again. You Can Still Stay in Control

Landmarks

Cover

Title page

Table of contents

Start of content

INTRO

At 3:42 on a Thursday afternoon, your team is preparing to deliver a beautifully designed employee training handbook. The client has approved the content, the illustrations are finished, and the final files are waiting to be sent. Then the phone rings. “We've had a brilliant idea,” says the client, sounding delighted. “Instead of a handbook, could we make it an interactive online training platform? Nothing complicated. Just a few quizzes, employee accounts, progress tracking, and certificates. You've already written the content, so most of the work is done. We can still launch on Monday, right?” You stare at the completed handbook. Apparently, during the last thirty seconds, it has been promoted to a software application without receiving any additional staff, funding, or development time.

You know what happens next. You want to preserve the relationship, demonstrate flexibility, and avoid sounding like someone who considers every new suggestion a personal attack. So you say something reassuring. Perhaps “We'll see what we can do,” or the particularly dangerous “That should be manageable.” The client hears a commitment. Your team hears about the request several hours later, when you announce that the weekend has developed an unexpected professional dimension. By Monday, everyone is exhausted, the original deliverable has been neglected, and the client is disappointed that the shiny new platform doesn't perform functions nobody explicitly discussed. Congratulations. You've managed to turn a successful project into an emergency while remaining exceptionally polite.

This is the uncomfortable reality of uncontrolled scope changes. The problem isn't necessarily that clients are unreasonable, dishonest, or secretly plotting to destroy your calendar. Clients change their minds because they learn new things, receive different instructions, discover previously overlooked needs, or finally understand what they want after seeing an actual result. Sometimes their new ideas are genuinely better than the original plan. Sometimes the original requirements were unclear, and what looks like an additional request is something the contractor should already have delivered. The difficulty begins when changing expectations are treated as though they have no consequences for the work required to satisfy them.

A project has finite resources, even when everyone involved would prefer otherwise. People have limited working hours. Specialist skills aren't always immediately available. Some activities depend on others being completed first. Budgets contain actual money, not encouraging motivational quotations. Yet discussions about new requirements often take place as though these constraints are merely matters of attitude. The client asks for something extra, and the contractor is expected to produce it through enthusiasm, teamwork, and possibly a motivational speech about going the extra mile. Unfortunately, an extra mile is still a mile. Someone has to travel it, and the journey takes time.

Perhaps you've tried solving the problem by working harder. You accept additional requests, rearrange your schedule, and hope the next one will be the last. Or perhaps you've tried being stricter, reminding clients that the original agreement is final and every deviation requires an additional charge. Neither approach works universally. Unlimited accommodation can destroy profitability and exhaust your team. Rigid resistance can prevent valuable improvements and damage relationships unnecessarily. Effective scope management requires a more useful skill: distinguishing between an idea worth exploring and a commitment you're actually prepared to make.

That distinction becomes particularly important when the original agreement is ambiguous. Imagine a client who commissions a reporting system described as “easy to use.” After delivery, they request accessibility improvements, simplified navigation, and additional export options. Are these new features, corrections to inadequate work, or clarifications of an existing obligation? The answer depends on what was agreed, the applicable requirements, and the actual functionality delivered. You cannot resolve the issue fairly by automatically declaring every request additional work. Nor should you assume that a vaguely worded contract obliges you to build whatever the client eventually imagines. Understanding the baseline is essential before arguing about deviations from it.

Money introduces another layer of difficulty. A change that looks insignificant compared with the total contract value may consume a substantial share of the expected profit. A freelancer can lose several billable days by granting a sequence of seemingly harmless favors. A manager can undermine several other projects by repeatedly reallocating the same specialists to urgent requests. And a company can deliver an impressive result while discovering that its most enthusiastic customer has become its least profitable relationship. There is nothing inherently wrong with offering additional work at no charge. Sometimes it's a sensible commercial decision. The trouble begins when nobody knows how much generosity is being provided, or who ultimately pays for it.

Deadlines create their own peculiar negotiations. Clients may insist that a date is immovable while introducing requirements that make the original schedule unrealistic. Sometimes the date genuinely cannot change because an event, launch, or external obligation depends on it. In other situations, the deadline is simply a preference that gradually acquired the status of natural law. You need to recognize the difference. If the deadline is fixed, perhaps the scope, sequence, or available resources can change. If every constraint is genuinely fixed, then someone must confront whether the requested outcome is feasible. Refusing to acknowledge an impossible combination doesn't make it possible. It merely postpones the conversation until everyone has considerably less time to respond.

Documentation matters just as much, although few people begin their careers dreaming of becoming exceptionally talented meeting-minute enthusiasts. The goal isn't to create a bureaucratic monument to every conversation. It's to establish a reliable account of what was proposed, what was approved, who made the decision, and which conditions apply. A friendly conversation can generate several possibilities without authorizing any of them. A short written confirmation can prevent those possibilities from mysteriously appearing in the delivery plan as contractual obligations. Good records protect both sides, especially when memories become suspiciously favorable to their respective owners.

You may also face situations where ordinary negotiating advice feels hopelessly detached from reality. Perhaps one customer represents a substantial portion of your revenue. Perhaps your employer has already promised the impossible and expects you to make it happen. Perhaps the decision-maker refuses to respond while the deadline approaches. You can't always walk away, demand a higher price, or summon additional staff. This book takes those limitations seriously. It explores how to make workable decisions when your bargaining position is weak, how to communicate risks without unnecessary confrontation, and how to recover when a project has already drifted beyond its original boundaries.

The objective is not to transform you into the person who says no to everything. It's to help you become someone whose agreements are meaningful. You'll learn to examine new requests before accepting them, distinguish real needs from proposed solutions, evaluate consequences, clarify responsibilities, and negotiate terms without treating every disagreement as a personal battle. You'll also learn why even a formally approved change can fail when nobody updates the actual work. These are practical skills for freelancers, project managers, business owners, consultants, and anyone responsible for delivering results while other people continue having ideas.

Start with one simple adjustment. The next time someone asks for an addition, resist the urge to provide an immediate promise. Acknowledge the request, find out what outcome matters, and establish what you need to check before committing. You don't need an elaborate procedure for every small adjustment, and you certainly don't need to become hostile. You need a moment of professional judgment between hearing an idea and accepting responsibility for delivering it.

Your clients will continue changing their minds. Some changes will be useful, others inconvenient, and a few will arrive with the breathtaking timing of a fire alarm during a wedding ceremony. What changes is your ability to respond deliberately. You can remain helpful without being endlessly available, flexible without abandoning your budget, and professional without promising miracles.

After all, the client is entitled to ask for three projects.

That doesn't mean you have to sell all three for the price of one.

Chapter 1 - Where Does a Small Revision End and a Second Project Begin?

The production company had been hired to create eight audio episodes for a public transport campaign. Each episode would explain a different aspect of travelling around the city, from buying tickets to using accessible services. The scripts were approved, professional narrators had been booked, and editing was under way. Then the client attended a marketing conference. Apparently, someone had delivered an inspirational presentation about the future of digital communication, because the next morning the producer received an enthusiastic email. Could the audio episodes also become short animated videos, preferably with subtitles in four languages and versions suitable for social media? The client added that this should be straightforward because the recordings already existed. By this logic, owning a bag of flour means you're practically running a bakery.

The request wasn't unreasonable. Animated videos might reach people who would never listen to a podcast, while subtitles could improve accessibility and make the material useful in noisy environments. The proposed additions might genuinely serve the campaign. The problem was the assumption that because the new deliverables used some existing material, they belonged to the original agreement. The client saw eight pieces of content that could be reused. The producer saw animation, translation, layout, synchronization, additional reviews, and a different distribution process. Neither perspective was automatically dishonest. They simply described different amounts of work, and nobody had yet established which one the original price covered.

This is where scope management begins: with knowing what you actually promised. A project scope is more than a collection of activities or a general description of what the customer hopes to achieve. It defines the results you're responsible for delivering, along with the relevant characteristics, quantities, constraints, and conditions for completion. Depending on the work, it may also identify what the client must provide, what is explicitly excluded, and how revisions will be handled. You don't necessarily need a formidable document with fourteen appendices. You need an agreement clear enough to distinguish fulfilling an existing obligation from accepting a new one.

Imagine the original proposal specified eight audio episodes, each approximately seven minutes long, including script editing, narration, sound production, and one consolidated review of each completed recording. That establishes a reasonably identifiable commitment. If the producer delivers only six episodes, the missing two are not optional extras. If the sound contains defects caused during production, correcting those defects is not automatically additional work either. But creating eight animated videos introduces a different output requiring different activities. It cannot sensibly become part of the original promise merely because both products contain a human voice. A recording is not an animation waiting for permission to reveal its true identity.

The distinction between correcting a defect, clarifying an agreement, and expanding the scope matters more than the label attached to the request. Suppose a client reports that a published episode uses an incorrect station name even though the approved script contains the correct name. That may be a production error the supplier should remedy. If the script itself contains an ambiguity that neither party resolved, determining responsibility may require examining the original agreement and the circumstances of approval. If the client now wants an entirely new section about services introduced after the scripts were finalized, that is potentially new work. All three requests may arrive in the same email headed "A few corrections," but they shouldn't automatically receive identical treatment.

There is an important complication here. Difficult work isn't necessarily extra work. You may discover that a promised feature takes twice as long as you estimated or that your preferred production method doesn't produce acceptable results. Those discoveries don't, by themselves, establish that the customer has changed the scope. If you've committed to delivering a particular outcome for an agreed fixed price, an inaccurate estimate may be your commercial problem. Of course, the precise obligations depend on the contract and applicable law. But professionally, you need to resist the temptation to rename your own planning mistake as a customer-requested enhancement. Clients have an impressive ability to remember what you originally promised, especially when you explain why fulfilling that promise now costs more.

The reverse problem occurs when the initial agreement is too vague. Consider a consultant hired to produce a "comprehensive assessment" of a company's purchasing process. Does comprehensive include interviews with suppliers? Reviewing three years of transactions? Visiting every warehouse? The adjective sounds reassuring until someone attempts to turn it into a schedule. If no meaningful boundaries were agreed, an argument about whether an activity is additional may remain genuinely uncertain. The practical response is to reconstruct the original understanding using proposals, messages, meeting notes, and the project's purpose, then clarify the boundaries together. Inventing precise exclusions after the disagreement starts is unlikely to inspire confidence.

Scope also includes details that aren't immediately visible in the finished product. A client may request the same report in six formats or ask that a training session be delivered to several additional locations. The underlying information might remain unchanged, but distribution, preparation, quality checks, and coordination may increase substantially. A small alteration to an important component can be especially deceptive. Changing one field in an order form may require updating the database, connected systems, validation rules, and reporting. The customer sees a rectangle on a screen. The development team sees several systems politely refusing to agree about what the rectangle means.

Equally, a request that looks extensive may have very little incremental cost. Perhaps the software already supports an alternative display option, or a requested output can be produced directly from existing approved material. If you can provide something valuable without significant additional work or risk, insisting on a full-scale change negotiation may be commercially foolish. The objective isn't to turn every client conversation into a toll booth. It's to understand the consequences before deciding how to respond. Sometimes a small courtesy is exactly the right decision, provided everyone understands what has been agreed and it doesn't quietly establish an expectation of unlimited future additions.

The cumulative effect of small requests deserves particular attention. One extra caption, a revised introduction, a different file naming convention, and a slightly modified approval process may each seem harmless. Across eight episodes and several rounds of review, they can become a meaningful amount of work. Because no single request appears important enough to challenge, the project gradually expands without a recognizable moment of change. You may find yourself working considerably longer than planned while struggling to identify any one decision that caused the problem. The answer is often that there wasn't one. There were twenty minor decisions that nobody considered together.

A useful way to identify this pattern is to compare the current expected deliverables with the agreed baseline periodically, rather than relying entirely on individual requests. Have the number of outputs increased? Are they more complex? Have review requirements or delivery responsibilities changed? Are you now supporting activities originally assigned to the client? The purpose isn't to assemble evidence against the customer. It's to notice when the working definition of success has shifted. A project can evolve sensibly, but that evolution should be visible to the people responsible for its cost, schedule, and delivery.

Some projects deliberately allow requirements to evolve. An ongoing product-development engagement, for example, may define a team capacity and budget while allowing the customer to change which features receive priority. In that arrangement, a newly requested feature isn't necessarily an additional purchase. It may replace something previously planned. What matters is understanding the boundaries of the arrangement. If the customer can reorder work within an agreed capacity, that flexibility is part of the service. If every new feature is added while all existing commitments remain unchanged, the capacity constraint hasn't disappeared. It has simply been excluded from the conversation, presumably for being insufficiently enthusiastic.

This distinction also matters when assessing ideas offered by your own team. Developers, designers, engineers, and consultants frequently notice improvements that customers haven't requested. Some are necessary to meet the promised outcome. Others offer attractive additional benefits. You should welcome professional initiative while being careful about expanding commitments without approval. A designer who voluntarily creates four extra concepts cannot automatically charge the client for them. A programmer who builds an elaborate reporting feature because it seems elegant may consume resources needed elsewhere. Scope creep isn't always something clients inflict upon contractors. Sometimes it emerges from a team sincerely trying to make something better than anyone asked for.

When a questionable request arrives, the most useful first step is to describe the difference without immediately arguing about payment. Try two sentences: "The approved scope includes eight completed audio episodes in English. The new request adds animated video versions and subtitles in four languages." This description identifies a measurable difference and avoids accusing the client of changing the rules. Once the difference is clear, you can examine its effects and decide whether to incorporate it, offer it separately, replace existing work, or leave it for another phase. The conversation becomes easier when everyone is discussing an identifiable result rather than defending competing interpretations of the word "minor."

Be equally careful about distinguishing a suggestion from authorization. A customer asking "Would it be possible to add subtitles?" may genuinely be exploring options. If you immediately instruct your team to start, you've converted a question into a commitment without knowing whether the customer wanted to proceed. Conversely, replying "Certainly possible" may sound like agreement to deliver the work. A more useful response is: "Yes, that's an option. I'll confirm what it involves and whether it fits the current scope before we agree on implementation." It communicates willingness to help while preserving the difference between investigating an idea and accepting responsibility for completing it.

A practical review doesn't always need a formal meeting. For a clearly minor change within your authority, you may be able to decide immediately. For a complex addition, you may need input from several specialists. The amount of process should reflect the impact of the request, not a universal rule that all modifications deserve identical paperwork. A replacement photograph that can be inserted before production starts is different from changing the format of every completed deliverable. You need enough information to make a responsible decision, and no more ceremony than the decision warrants. Excessive bureaucracy can be just as effective at damaging customer relationships as unrestrained promises.

Disagreements become more difficult when the client believes the proposed work was always included. Avoid treating that belief as proof of bad faith. Ask which part of the original understanding supports the expectation, examine the available evidence, and distinguish agreed obligations from assumptions. You may discover a genuine omission in your own proposal. You may also identify a new requirement that emerged during the project. If the contractual implications remain uncertain, particularly where substantial sums or potential disputes are involved, obtaining appropriate legal advice may be necessary. A confident project manager is useful, but confidence alone doesn't resolve ambiguous contractual obligations.

Return to the producer and the proposed animated videos. Instead of announcing an immediate price increase or agreeing to complete everything by the original deadline, the producer identifies the requested outputs and asks which audiences the videos need to reach. The client explains that short subtitled clips are primarily intended for passengers accessing information without sound. That clarification may suggest a smaller, more useful package than eight fully animated episodes in four languages. The producer can now prepare a meaningful proposal and explain how it differs from the existing agreement. The client's underlying need receives attention without being mistaken for a completed order.

Understanding where the original scope ends isn't about defending a document at the expense of the customer's needs. It allows those needs to be considered fairly. A correction can be made because it belongs to the original commitment. A genuinely new deliverable can be evaluated because it changes that commitment. A small improvement can be offered willingly rather than accidentally. The boundaries make cooperation more honest, not less flexible. Without them, even generous intentions become difficult to manage, because nobody knows what has been promised or what remains available.

Next time someone describes an addition as "basically the same thing," resist the urge to argue about adjectives. Compare the promised result with the newly requested one. Identify the actual difference and the work it creates. You may discover that the request is smaller than you feared, or considerably larger than the client imagined. Either discovery is useful. At least you'll make the decision before completing a second project that somehow managed to hide inside the first one wearing a name badge marked "Quick Adjustment."

Chapter 2 - Why Clients Change Their Minds After Approving Everything

The regional delivery company had approved its new dispatch dashboard three times. The first approval came after a presentation of the proposed layout. The second followed a demonstration using sample delivery routes. The third arrived in a cheerful email stating that the company was "fully aligned and excited to proceed." The software team began development, reassured by this impressive collection of positive statements. Then the dispatchers tried the working version. Within twenty minutes, they identified a fundamental problem: the dashboard assumed that drivers followed routes in a fixed order, while actual deliveries were constantly rearranged around customer availability, traffic, and urgent collections. The operations director requested a redesign. The project manager stared at the three approvals and wondered whether they came with a refund policy.

The tempting explanation was that the client didn't know what it wanted. There was certainly evidence of changing expectations, but the conclusion was too convenient. The operations director had approved what appeared to be a useful system. The dispatchers, who understood the daily exceptions, hadn't been sufficiently involved. The software team had built an interpretation of the approved requirements without discovering how often the planned workflow would break down. Everyone had contributed something to the misunderstanding, although nobody had deliberately set out to create it. The client wasn't a single, perfectly informed person with one stable opinion. It was an organization containing people who knew different things and had different responsibilities.

This is the first reason customers change their minds: an initial agreement doesn't necessarily represent a complete understanding of the problem. People make decisions using the information available at the time. When new information appears, their preferences may change. That isn't always a sign of inconsistency. Imagine choosing a layout for a warehouse based on an accurate floor plan, then discovering during a trial that forklifts cannot safely navigate a particular turning area. Maintaining the original design simply because it was approved would be foolish. The real challenge is distinguishing a legitimate discovery from an avoidable failure to consult the right people earlier.

A presentation can make almost any reasonable concept appear convincing. Screens display clean data, users follow predictable paths, and every button behaves exactly as intended. Real organizations are less considerate. Customers provide incomplete information, staff interrupt tasks, deliveries arrive late, and someone inevitably needs a feature the demonstration never mentioned. These details may remain invisible until the proposed solution meets ordinary work. People can sincerely approve an attractive design without realizing how it will behave during a busy afternoon. The problem isn't that they suddenly developed new tastes. They discovered something about the work that the presentation hadn't revealed.

That's why the people paying for a project aren't always the people best equipped to describe its operational requirements. A senior manager may understand the business objective but rarely perform the underlying tasks. A finance director may know the reporting obligations without understanding the frustrations of frontline employees. Marketing may have excellent reasons for requesting a particular customer experience, while the support team knows why some apparently convenient features create additional work. Each group sees part of the situation. If you consult only one, your requirements may be consistent, polished, and wonderfully incomplete. The missing information tends to appear later, usually after somebody has described the project as nearly finished.

Different stakeholders also have different incentives, and those incentives influence what they ask for. In the delivery company, dispatchers wanted flexibility because they were responsible for managing exceptions. Senior management wanted predictable routes and accurate performance reporting. Finance wanted reliable cost information. Customer service wanted the ability to provide accurate delivery updates. These objectives weren't necessarily incompatible, but they required conscious decisions about which capabilities mattered most. Without that discussion, each stakeholder could approve the initial concept and later request changes that improved their own part of the operation. The result would look like repeated indecision, when the deeper problem was a set of competing priorities that nobody had reconciled.

A particularly awkward version occurs when someone important joins the conversation late. Perhaps the project sponsor originally approved the requirements, but the chief executive sees the finished design and asks why it doesn't include a feature previously discussed in an unrelated meeting. The project team may be hearing about that feature for the first time. Meanwhile, the sponsor is embarrassed because the executive assumes the requirement was already understood. The sponsor may then present it as a minor adjustment rather than acknowledge that an internal conversation never reached the delivery team. This creates pressure for immediate accommodation, although the underlying cause is an organizational information gap rather than a technical discovery.