A schedule is not a plan but a plan might have a schedule in it!

A schedule is not a plan but a plan might have a schedule in it!

The first two organizations I worked for called the project schedule the ‘project plan’. A little later when I went to work for an organization that approached project management more formally, I was initially confused when a Gantt chart stopped being a project plan and my trusty plan was replaced by a document indicating how things would be approached rather than what would be done. I still occasionally conflate the concept of a project schedule with a project plan. While the two tools are related, they are different and serve different purposes.

A project plan is a deliverable used to document planning assumptions and as a vehicle to communicate the approved of scope, cost and schedule. Some form of a schedule is typically included in the plan. Inclusion of an early schedule establishes a link between the two deliverables. The Project Management Institute (PMI) indicates that the project plan is a formal, approved document. Formal project plans can include a wide array of sub-plans, including a risk management plan, quality plan or communication plan. Formal, classic project plans can be quite significant documents requiring a lot of effort to prepare. A plan and all of the sub-plans provide a platform for a project manager and stakeholders to develop a common understanding of how a project will be approached and establish roles. Many Agile projects use the Agile Team Charter to set expectations for how the project will be approached at the team level.

A cautionary note: writing and getting a plan signed-off does not ensure that all parties have developed a common understanding. Interaction and conversation are critical steps to developing a common language for the project.

Project schedules come in many forms ranging from simple approaches, such activity lists and time tables, to highly complex forms that include task network-based schedules and Critical Path Methods (CPM). A common thread in most schedules is that features, tasks and activities (or some subset) are documented and connected as a tool to guide the team and communicate progress. Agile teams use prioritized backlogs and release plans as schedules and while other methods use techniques such as milestone charts, task lists, Gantt chats and/or CPM (this only scratches the surface). Schedules act as tools to guide activities in a project, to answer the “when” questions and to help answer the “how much will this cost” questions.

Plans are a mechanism to help teams and project leaders consider how the project will be approached, to define roles and to begin to establish a common understanding between everyone involved. Project schedules reflect how the work will get done and when it will get done. Schedules reflect tactical planning, while plans take a more strategic view. Like planning, all projects use some form of scheduling technique. Team charters, backlogs, release plans, iteration backlogs, task lists or Kanban boards or project plan documents and detailed project schedules, reflect the difference in our approach and philosophy.