ExistBefore
IT

Professional

How to document further modifications requested by the client during a project

"On the fly" modifications are the true Olympic sport of projects. If you want to avoid endless arguments over what was included and what was added later, you must track every request well. Start doing it immediately: the difference is already visible at the next call.

4 min read

1. How it usually happens

A project starts with a clear perimeter. Or at least, it seems so.

Then requests arrive:

"Can we just add one small thing?"

"While we're at it, let's fix this too?"

"It's a quick tweak, right?"

Every modification is reasonable taken individually. The problem arises when they pile up.

Within a few weeks:

  • work has increased
  • timelines stretch
  • client has a different perception of initial perimeter

And most importantly, nobody remembers when a request became part of the project.

Classic anecdote: web project, 5 pages planned. At delivery they become 11. Client is convinced it was always like this. Team has in mind a sequence of calls, voice messages, and comments on shared files. Nobody has an orderly reconstruction.

There are also subtler dynamics:

  • requests made in call and never written
  • modifications approved with an "ok" in chat without context
  • tasks added directly on operational tools without passing formal confirmation

The result is always the same: a grey zone where everything seems included.

2. What you need to prove

Here the point is very concrete: when a modification was requested, in what form, and relative to what initial perimeter.

You must be able to prove:

  • existence of modification request
  • precise content of request
  • moment it was made
  • context (call, email, chat, tool)
  • difference compared to original scope
  • any confirmations or approvals

In an argument, the question becomes:

"Was this activity planned at the start or added later?"

3. What to collect

Here you need to collect traces of modifications as they happen, not a posteriori.

Useful materials:

  • emails with modification requests
  • chat screenshots (Slack, Teams, WhatsApp, etc.)
  • relevant conversation exports
  • call recordings or notes
  • comments on shared docs (Google Docs, Figma, etc.)
  • tasks added on project management tools
  • updated document or deliverable versions
  • summaries sent after meetings
  • any mini-quotes or written approvals

A practical detail:

even a simple screenshot of a message like "let's add this point too" with visible date and time can make much clarity later.

4. How to proceed

The key here is turning modifications into something traceable and orderly.

When a request arrives:

  • avoid leaving it only oral
  • immediately put it in writing (even with a short summary)
  • link request to a precise context

Right after:

  • save or export relevant conversation
  • take screenshot if request is in chat
  • create a small "info block" (request + context)

Then take a fundamental step:

  • clarify if modification is within scope or an addition
  • if needed, send a short alignment message ("this activity is extra compared to...")

To organise everything:

  • create folder dedicated to project modifications
  • gather materials by date or theme
  • maintain logical request sequence

At this point:

  • create coherent packages (request + any reply + updated deliverable version)
  • timestamp these materials in the state they exist

If modifications continue:

  • repeat process without overwriting
  • keep every step as part of project history

Over time, you get a clear timeline:

request → clarification → approval → implementation

5. Mistakes to avoid

Most common mistakes are those looking harmless while working.

  • accepting modifications only verbally without written trace
  • answering "ok" in chat without contextualising
  • updating deliverables without keeping previous version
  • never distinguishing between initial scope and additions
  • leaving requests scattered across different tools

There is also an attitude mistake:

considering every modification as "part of normal flow" without ever stopping to record it.

Useful precautions besides timestamping:

  • always send a short recap after calls with modifications
  • use clear labels like "new request" or "extension"
  • maintain consistency in file names and versions

When documentation is orderly, discussions shorten greatly. Free timestamping adds a precise time reference to every collected step.

6. After documenting

If a misalignment arises:

  • reconstruct modification sequence
  • share steps in chronological order
  • highlight what was added over time

This approach helps shift conversation onto concrete facts.

If needed:

  • involve client project referent
  • prepare clear variation summary
  • evaluate formal update of times and costs

In more complex cases:

  • you can use collected documentation to support structured confrontation
  • having clear timeline makes any verification faster

In the end, real advantage is simple:

you manage to distinguish precisely between planned work and work grown along the way, without having to reconstruct everything from memory.