A Project Plan Is Really Just a Record of Agreements

When I got promoted to associate project manager early in my career, I thought I knew what I was doing. I'd watched other project managers for years and had managed a few small projects myself. But nobody ever sat me down and walked me through the basics. On my first major project, I stared at a blank Excel template for what felt like hours, trying to figure out how to create an actual project plan. I knew the tools existed, I knew templates were available, but I had no idea where to start.

That's when I learned the hard way that creating a project plan isn't about mastering software or filling in templates. It's about having the right conversations with the right people in the right order.

I started with what seemed obvious at the time but wasn't: I sat down with the project sponsor and key stakeholders for a kickoff conversation. I asked three simple questions that would become my foundation for every project since. What are we trying to achieve? When does it need to be done? Who needs to be involved? These questions gave me the goal, the deadline, and my cast of characters. Without these anchors, any plan I created would just be elaborate guesswork.

Once I had clarity on the destination, I made what turned out to be the smartest decision of that project. Instead of trying to figure out the work breakdown structure myself, I got the people who would actually do the work in a room together. I asked them to walk me through every step needed to reach our goal. They knew things I couldn't possibly know, details about dependencies and complexity that would never show up in any template. This collaborative approach to breaking down the work became the backbone of every successful project I've managed since.

For each task we identified, I learned to ask two critical questions: Does anything need to happen before this can start? What could go wrong or slow this down? The answers to these questions built the logic of my project timeline. They revealed the hidden connections between tasks and helped me understand where I needed buffer time. Without these conversations, my Gantt charts would have been fiction dressed up as planning.

I also learned to get time estimates from the people doing the work, not from their managers. Managers, with the best intentions, almost always underestimate how long things take. The person who's actually going to write the code, design the process, or coordinate the logistics usually has a much more realistic view of the effort required.

After drafting the plan, I'd share it back with the team and ask two more questions: Did I miss anything, and does this sequence make sense? I learned to expect corrections on the first pass. Getting feedback wasn't a sign I'd done something wrong, it was proof the process was working.

Looking back, the biggest insight from that first real project planning experience was understanding what a project plan actually is. It's not a document you create in isolation and hand down to your team. A project plan is really just a structured record of agreements made between people. Every task, every timeline, every dependency represents a conversation where someone said yes to something.

The tools matter, of course. Whether you're using Excel, Google Sheets, Microsoft Project, or Smartsheet, you need something to capture and organize all these agreements. But the tools are just vessels for the real work, which happens in those conversations where you're building understanding and alignment with your team.

The next time you're staring at a blank project template, remember that the template isn't where the planning happens. The planning happens when you're talking with people, asking questions, and listening to their answers. How often do we skip straight to the tools and miss the conversations that make the plan actually work?