Document All Client Communication

Project knowledge must belong to the project, not remain in the memories or inboxes of particular people.
When you have a good relationship with a client, it is easy to become informal. You talk regularly, make decisions on the phone, agree to things during meetings and assume everyone understands what was decided.
That works perfectly, until someone forgets, disagrees, leaves the project or is replaced.

Good relationships don’t remove the need for documentation. In fact, good relationships can sometimes make documentation more important because people become comfortable making informal agreements.

Table of Contents

Problem: Important Client Communication Exists Only in People’s Memories

1. People remember conversations differently.

Two people can leave the same meeting with different interpretations.

One person remembers:

“The client approved it.”

The client remembers:

“I said it sounded reasonable, but I didn’t approve it.”

That distinction can become very important six months later.

2. People forget context

Even if everyone is honest, memories become simplified.

What was actually said:

“We can probably deliver it by September 18th provided the client supplies the survey information by Friday.”

Eventually becomes:

“You said you’d deliver it by September 18th!”

Written communication would have preserved the conditions and context, not merely the final date.

3. The client’s project manager changes

A new client PM may know nothing about the history of the project, especially the informal things:

Informal agreements
Concessions their predecessor made
Reasons behind decisions
Why the schedule changed
Why a particular solution was selected
Additional work the client requested
Commitments the client made to your team

And understandably, the new PM may say:

“Show me where this was agreed.”

If you can’t, you have a problem.

4. Your own project manager can change too

The same problem applies if you leave.
A well managed project shouldn’t depend upon the personal memory of one PM.

I’ve seen first-hand what happens when a project depends on one person’s memory.

Refer to my post Document All Changes, Variations and Agreements, where I describe what happened when a project manager unexpectedly died and undocumented agreements became a serious problem.

5. Disputes change the interpretation of old conversations

While things are going well:

“Of course, that’s what we agreed.”

When the project is two months late and $300,000 over budget:

“That’s not how I remember the conversation.”

The documentation is often most valuable long after you created it.

Solution: Create a Written, Searchable Communication Record

Follow up verbal conversations in writing.

This is probably my most important recommendation.

After a significant phone call or in person discussion:

“Thanks for the discussion today. Just confirming my understanding that…”

Then briefly state:

What was decided
Who will do what
Due dates
Assumptions / conditions
Anything still unresolved

You don’t need to turn every conversation into a formal letter, a short confirmation email can be enough.
This is also an overlooked advantage:
It gives the client an opportunity to correct you.

If you’ve misunderstood them, you’d much rather discover that the next morning than six months later.
It isn’t adversarial at all, it is polite confirmation and correction, and a good client project manager will appreciate it.

Document outcomes, not just meetings

Don’t simply record:

Meeting held with client Tuesday.

Record the details:

Decisions
Actions
Responsibilities
Due dates
Unanswered questions
Approvals
Rejected proposals
Assumption
Matters requiring escalation

Meeting minutes shouldn’t merely prove that a meeting occurred. They should preserve what came out of the meeting.

Don’t just rely on your email inbox

Project communication is now spread across multiple locations:

Email
Teams
Slack
Phone calls
Video meetings
SMS
Project management software
Document management systems
Site meetings
Handwritten notes (such as your diary)

The important records should ultimately be somewhere that the project team can find. A client’s instruction buried in the PM’s personal inbox isn’t much better than an instruction stored in the PM’s memory if no one knows it exists.

PMI guidance similarly talks about defining both a filing/collection structure and how to overcome communication complexity.

Note where communication is stored in your project management plan (read more on why your project needs a project management plan)

Use a correspondence register

And a full project communication, decision and action register if the size and complexity warrants it. Not every small project requires one, the system should be proportionate to the project. A $20,000 project probably doesn’t need the correspondence controls of a $10 million dollar project.

Make correspondence searchable

Useful habits might include:

Meaningful subject lines
Consistent project numbers
Reference numbers for important formal correspondence
Storing important correspondence centrally (I like a project mailbox that the whole team can access)
Linking correspondence to issues/variations where possible
Keeping decision and action registers
Avoiding important decisions buried inside long unrelated email chains

The test could be:

Could a new project manager find and understand this decision six months from now?

Don’t make documentation adversarial

Some project managers take “get everything in writing” too far and begin communicating like every email is preparation for litigation.
That can actually damage client relationships.

The objective isn’t:

“I’m documenting this so I can prove you wrong later.”

It is:

“I’m documenting this so we both have the same understanding.”

Keep communication:

Factual
Neutral
Concise
Professional
Non-accusatory

As I noted in my post The Importance of Good Communication, you need to do regular updates. Keep the client informed and tell them about problems rather than letting them discover problems themselves. This is for their benefit, not to cause them worry.

Particularly document bad news

Project managers naturally document approvals and instructions. They sometimes become less enthusiastic about documenting:

Delays
Mistakes
Unresolved problems
Rejected recommendations
Warnings
Risks
Client dependencies
Late information from the client

But these can be the most important communications to retain.

For example:

“We advised on May 4th that if the survey wasn’t received by May 8th, the design milestone would be delayed by approximately two weeks.”

This is very different from trying to reconstruct the conversation after the milestone has been missed.

Know when an email is not enough

A short contractual caveat:

Some contracts prescribe how formal notices, variations, claims or approvals must be issued. A casual email or Teams message may provide useful evidence of a conversation but without satisfying whatever formal process the contract requires.

So make sure to document the communication, but also follow the project’s contractual communication and notice requirements where applicable.

“I sent an email” is not equivalent to a formal contractual approval.

What should I document?

Always consider recording communication involving:

Client instructions
Decisions and approvals
Changes or proposed changes
Commitments from either party
Due dates and milestones
Reasons for delays
Assumptions and dependencies
Actions and who owns them
Client feedback
Risks and issues raised with the client
Rejected recommendations
Agreements about responsibilities
Clarification of requirements
Anything you think someone might later ask, “Who agreed to that?”

Example communications worth documenting

An Example Scenario

Before

Client PM phones:

“Don’t worry about producing the full report this month. Give us the preliminary results and you can give us the final report next month.”

Your PM says okay.

Nothing is written down.

Three weeks later the client’s PM leaves.

The replacement PM looks at the contract:

“The final report was due last Friday. Why haven’t you delivered it?”

Your PM:

“John told us not to.”

The new client PM:

“Do you have that in writing?”

After implementing a communication register.

Replacement PM:

“I see in the shared communication register that John told you not to send the report for last month. When you send it next month could you also please note that it covers both months, so the records are clear.”

Nice and simple. No arguments. No disagreements. No confusion.

Lesson: If it Matters, Put It in Writing

Don’t rely on memory.
Don’t rely on relationships.
Don’t rely on particular people remaining on the project.

Instead, create enough written history that someone joining the project tomorrow can understand:

What was discussed, what was decided, why it was decided and what everyone agreed to do next.

This article is part of a set of related articles on Communication:

Document All Client Communication