If you’ve been managing projects for a while, you know that little details that seem insignificant during the project can end up being critical as the finish date approaches. As a project manager, you want to make sure these details are organized and logged somewhere where they can be found easily, but you also need to avoid bombarding your stakeholders with too much information.

Many years ago, I found myself in a status meeting when the client asked “What was the decision we made about ____ ?” Boy, was I embarrassed. I had completely forgotten what had been decided. At the time I probably thought, “This is important, but I’ll remember it. I don’t need to write it down.” And then life happened and there were 100 other project details to deal with before this one came up again. I learned my lesson: I need a good system to keep track of all of project details. Back in the day it was a notebook and a pen and typing up notes when I had the time. Now our tools have evolved, and we have shared online workspaces to document and maintain project information.

What type of decisions should you document?

That will depend on your specific project, of course. But pay special attention to things like:

• Product specification changes (new features, new functionality, or new requirements)
• Deadline changes (especially when expectations have changed with stakeholders or clients)
• Goal / strategy decisions (do changes to strategy impact execution that’s underway?)
• Resource changes (people being added to or removed from the team)
• Priority changes (certain aspects of the project become more important)
• Design changes (especially when they may impact multiple areas of the project)

How much information should you document?

Being an effective communicator requires finding a balance between too much and too little information. Most people read as little as they can get away with! When you’re documenting decisions, it pays to go back to the “4 W’s & H”:

• What the decision was
• Who made the decision (and who else was part of the decision-making process)
• When the decision was made
• Why the decision was made (including why the alternatives were rejected)
• How the decision was made (including links to supporting data or details)

In LiquidPlanner, the project details page is the natural place to log this type of information. If you put changes in as comments, you can notify other team members who need to be looped in, and they’re automatically date stamped for a chronological record.

When it comes to creating a valuable project decision record, be concise, be consistent, and be (factually) correct. Your project team will thank you.