Maintain a Project Communication, Decision and Action Register

Solution: Maintain a Project Communication, Decision and Action Register

Maintain a register of the important communication, decisions, actions, commitments and other significant events in your project.

I am not suggesting that you record every email.

That would probably create another enormous collection of information that nobody wants to read.

Instead, record the items that may be important later.

These could include:

• Decisions – what was decided, by whom and when.
• Actions – what needs to be done, by whom and by what date.
• Client instructions – especially instructions given verbally.
• Approvals – including exactly what was approved.
• Commitments – promises made by either the client or the project team.
• Clarifications – answers to ambiguous requirements or technical questions.
• Assumptions – particularly assumptions affecting scope, cost or schedule.
• Dependencies – information, approvals or inputs required from the client or others.
• Issues – unresolved matters requiring attention.
• Risks raised with the client – particularly where you have explained the possible consequences.
• Rejected proposals – useful later when someone asks why another option wasn’t used.
• Changes in direction – even where they have not yet become formal variations.
• Important correspondence – emails or letters that establish a position or record an important discussion.

The purpose isn’t simply to create another correspondence log.

It is to preserve the important chain of events throughout the project:

Communication → Decision → Action → Outcome

That makes the register much more useful.

Don’t Replace the Source Documents

There is an important distinction between the register and the original project records.

The register should not replace emails, meeting minutes, formal correspondence, contractual notices, approved drawings, variation documentation or other formal project records.

It should act as an index and summary of the important information contained in those records.

For example, your register might contain:

DEC-043 – Select Option B for access road

The entry could identify the date, decision maker, reason and source document.

You should still retain the steering committee minutes, email approval or other document that actually records the decision.

The register just makes that decision easy to find.

You don’t want someone to say:

“The register says the client approved it”

You want to be able to say:

“The register says the client approved it on 22 October 2025, and here is the original approval.”

Record Decisions and Actions Properly

Actions and decisions are related, but they are not the same thing.

For example, a meeting may produce this decision:

Decision: Use the revised foundation design.

And then this action:

Action: Consultant to issue revised drawings by Friday 24 October 2025.

If you only record the action, you eventually lose the reason behind it.

If you only record the decision, you may lose track of who was responsible for implementing it.

You need both.

For important decisions, don’t just record what was decided.

Record enough information to understand the decision later.

This could include:

• Decision required
• Options considered
• Recommendation
• Decision maker
• Final decision
• Decision date
• Reason for the decision
• Consequences
• Assumptions
• Supporting documents

For example:

DEC-043 – Select Option B for access road

• Options considered: A, B and C
• Recommendation: Option B
• Decision Maker: Client Project Director
• Decision date: 22 October 2025
• Reason: Lower environmental impact and faster approval pathway
• Consequence: Approximately $80,000 additional construction cost
• Source: Steering Committee Meeting #6

I think the reason for the decision is particularly important.

Years later, people often look at an old project decision and think:

“Why on earth did they do that?”

Sometimes a decision that looks terrible in hindsight was completely logical based on the information, constraints and risks that existed at the time.

Perhaps the cheapest option would have delayed environmental approval by six months.

Perhaps a particular technology was selected because the preferred alternative wasn’t available.

Perhaps the client specifically instructed the project team to prioritise schedule over cost.

If you only record the final decision, all that context can disappear.

A good decision register preserves the information that made the decision sensible at the time.

For actions, record enough detail to make them manageable.

A simple action such as:

“John to investigate.”

Isn’t very useful.

A better action would be:

“John Smith to confirm available electrical supply with the client by 5pm Friday 24 October 2025.”

That clearly identifies what needs to be done, who is responsible and when it is due.

Where possible, link related communications, decisions and actions so that you can follow the chain from the original discussion through to implementation.

Use Separate or Integrated Registers

How you structure the system should depend on the size and complexity of the project.

A large project may justify separate:

• Correspondence register
• Decision register
• Action register
• Issue register
• Change register

There may also be separate risk, variation, technical query and other registers,

For smaller and medium sized projects, I generally prefer an integrated approach.

You could maintain a project register with a Type field that allows you to categorise and filter entries such as:

• Decision
• Action
• Instruction
• Approval
• Clarification
• Issue
• Correspondence
• Commitment
• Dependency
• Change

You can then filter the same register depending on what you need.

For example:

Show me all outstanding actions.

Or:

Show me all client instructions related to the access road.

Or:

Show me all decisions made about the foundation design.

This can be much simpler to maintain than having information spread across five different registers.

The exact system is less important than making sure the information is recorded consistently and can be found easily.

Include Enough Information to Make the Register Useful

The categories above describe what types of information should be recorded.

You also need to decide what information each register entry should contain.

A basic integrated register might include fields such as:

• Reference number
• Date
• Type
• Subject
• Summary
• Person or organisation responsible
• Action owner
• Due date
• Status
• Related decision, issue or change
• Source document or correspondence
• Location or link to the source document

You don’t necessarily need every field for every entry.

An approval may not have a due date.

An action probably will.

A decision may need the decision maker and reason.

The objective is not to make the register complicated.

It is to make it useful.

Record Important Verbal Communication

Verbal communication is particularly important to capture.

A client may say during a phone call:

“Don’t proceed with Option A. We want you to develop Option B instead.”

You should still confirm that instruction in writing, as discussed in Confirming Details of Verbal Conversations.

But I would also consider adding the instruction to the register.

For example:

INS-024 – Client instructed project team to discontinue Option A and Develop Option B.

The register entry could then link to your confirmation email.

This means someone doesn’t need to know that the instruction occurred during a particular phone call before they can find it.

Keep the Register Current

Like most project management systems, the register is only useful if people maintain it.

A register that hasn’t been updated for two months may be worse than not having one, because people assume it is current when it isn’t.

Decide who is responsible for maintaining it.

You might update it from:

• Project meetings
• Client meetings
• Steering committee meetings
• Important emails
• Formal correspondences
• Action lists
• Phone call confirmation emails
• Change discussions

On smaller projects, the project manager may maintain it directly.

On a larger project, project controls, project support or several nominated team members may contribute.

If your project systems are well integrated, this is also an area where AI could become very useful.

A well defined AI agent could potentially review meeting minutes, correspondence and project systems, identify decisions and actions and propose updates to the register.

That could make maintaining the register much easier.

On an existing project that doesn’t have an actions and decisions register yet, you could get AI to scan all available project folders, emails and sources and draft a register for you. You would then need someone to review and edit it for accuracy, especially if the AI doesn’t have access to all the project information.

However you do it, someone still needs to make sure the information is accurate and that significant decisions aren’t being overlooked.

Make it Easy for Someone New to Understand the Project

One of the best tests of a project register is to imagine that you disappear from the project tomorrow.

A new project manager takes over.

Could they open the register and understand:

• The important decisions that have been made?
• Why those decisions were made?
• Important client instructions and approvals?
• Commitments made by both parties?
• Outstanding actions?
• Major unresolved issues?
• Important dependencies?
• Changes in direction?
• Where to find the original supporting records?

Could they understand the important history of the project without having to read six months of emails?

If the answer is yes, the register is doing its job.

The register isn’t just a list of correspondence. It is a searchable history of the important things that have happened on the project.