Drew Barontini

More about me
Issue #12

Project Plans

My dad is a labor-negotiations lawyer. He negotiates contracts with labor unions, and he’s been doing it for many decades now. I get a lot of my process-oriented qualities from him. When I was talking to him recently, he told me about the meticulous documents he maintains for each of the contracts he works on—he calls them “Contract Records”. They contain detailed notes, key stakeholders, decisions, dates, and everything in between.

When he was getting back to work on a contract that stalled out for many months, he was the only person able to immediately recall all the context and the last state of the contract. Why? Because of his ‘Contract Records’. Everyone was amazed, but it was expected for him.

Information is power.

When learning about this, I realized his document is almost exactly like one I create and use for all of the projects I work on:

The Project Plan

A Project Plan is a singular document that holds all relevant details of a fixed-time project. While the elements vary from project to project, I always start from the same template and modify it to fit project-specific nuances. Standardized, but with adaptability.

Here are the key parts of the Project Plan:

A good Project Plan will get anyone immediately up to speed on a project. And it’s a living, breathing document you can use to keep a constant pulse on the work. I can’t tell you how many times I’ve shared a Project Plan with curious inquirers. And it’s invaluable when you need to onboard new team members.

Project Summary

The Project Summary should include things like:

This is the place to get anyone up to speed on the project quickly.

Project Deliverables

The Project Deliverables cover the list of items that need to be completed by the end of the project. What work is actually being done? What are the artifacts to create?

I like to list these as outcomes. They should be clear and tangible because, once you hand them off, they tell you when the project is complete:

Project Schedule

The Project Schedule is critical because the schedule is The Sacred Timeline. This is incredibly important because everything in the Project Plan is in service of staying on schedule. This should cover:

Project Communication

The Project Communication shows you the lines of communication.

Understanding how communication flows is important. Once you see it spelled out this way, it makes it easier to assess and determine if there are any communication gaps.

Project Log

The Project Log is the last part of my Project Plans. This is where I like to document key decisions and updates. When something notable happens (meeting, discussion, decision), I write it in the log—when it occurred, who was involved, and a description of the event.

For example, when I sent a client a pitch document and they confirmed (over email) everything looked good and agreed with how I marked priorities. Or when the team makes an important technical decision. That is critical information, and it’s worth keeping track of.

Build Your Own

As with all things, find your expression—the Project Plan that works for you. These top-level sections work well for me, but I adapt them for each project. Some need more or less of the individual sections. Adapt it. Make it yours.

To help you get started, here’s a link to my Project Plan Template you can start from.

Enjoying this issue? Sign up to get weekly insights in your inbox.