I can build you a beautiful project schedule for a terrible project. It can include hundreds of tasks, perfectly linked dependencies, color-coded milestones, resource assignments, completion percentages, and a finish date calculated down to the day. I can put it into sophisticated project management software, generate a crazy cool Gantt chart, and present it to leadership in a way that makes everyone feel like the project is completely under control.
None of that means we have a good project plan.
One of the most common mistakes I see in project management is confusing scheduling with planning. A schedule is certainly part of a project plan, but it is not the plan itself. The schedule tells us when activities are expected to happen, who is responsible, and how different pieces of work relate to one another. Those things matter. But a real project plan needs to do something much more important: it needs to help the team make decisions.
A good project plan starts with the outcome.
Before worrying about dates, tasks, or software, we should be able to clearly explain what we are trying to accomplish and what success actually looks like. From there, we need to understand the people involved, the assumptions we’re making, the resources available, the constraints we’re operating within, and the risks that could prevent us from reaching that outcome. Only then does the schedule gain meaningful context.
This matters because projects rarely happen exactly as planned. Stakeholders change their minds. Resources disappear. Requirements evolve. Vendors miss deadlines. Assumptions prove incorrect. Risks become issues. New opportunities appear. Sometimes the environment changes so dramatically that portions of the original plan no longer make sense.
That doesn’t mean planning failed. It means reality showed up.
Planning isn’t meant to predict the future perfectly. The purpose of planning is to prepare the team to make better decisions when the future doesn’t behave the way we expected. That’s why I think project managers should view the project plan as a decision-making system rather than simply a collection of documents. When something changes, the plan should help us understand the impact. What happens to scope? What happens to schedule? What happens to cost? What new risks are created? Who needs to know? Who has the authority to make the decision? What should happen next?
If the only thing we can do when something changes is move a few bars on a Gantt chart, we aren’t really managing the project. We’re maintaining a schedule.
This is also why planning shouldn’t stop when the project moves from the Plan phase into Delivery. I teach a simple lifecycle of Initiate, Plan, Deliver, and Close, but those phases shouldn’t be interpreted as isolated boxes. Planning continues throughout the project. As we learn more, we adjust. As uncertainty decreases, we add detail. As risks emerge, we respond. As we make decisions, we update our approach.
The farther into the future we’re looking, the less certainty we usually have. Trying to plan every activity six months from now at the same level of detail as the work happening next week doesn’t make the project more controlled. It often creates false precision. Good project managers understand that distinction.
They aren’t trying to prove that they predicted everything correctly. They’re trying to make sure the team knows where it’s going, understands what could get in the way, and can make intelligent adjustments along the way.
So build the schedule. Identify your milestones. Establish your dependencies. Assign your resources. Those things absolutely matter. But don’t mistake the schedule for the plan. If your project plan can’t help your team decide what to do when something goes wrong, you probably don’t have a project plan. You have a schedule.
