The revealing truth about the plan and schedule

Special Guest Article from Deb Schaffer at ProProject Manager

Project managers have many different roles: scheduler, budget analyst, occasional relationship coach. Educator is one role that is often unexpected. Often we are asked, “Aren’t the project plan and the schedule the same thing?”

Let’s eliminate the confusion about this. Your friends don’t think that the directions to your house are the actual house, right? Here’s some clarification.

There are different ways of running projects. Two of the most popular are the traditional, sequential method – often called the Waterfall method – and the Agile method. The project plan and scheduling the project tasks are handled differently depending on the approach.

Traditional project management: The project management plan

In the traditional project management methodology, the project management plan is defined by the Project Management Book of Knowledge, 5th Edition (PMBOK), pg. 554 as “The document that describes how the project will be executed, monitored, and controlled.”

The project management plan is a comprehensive document that includes a collection of subsidiary documents such as:

  • Risk Management Plan
  • Requirements Management Plan
  • Process Improvement Plan
  • Cost Management Plan
  • Schedule Management Plan

In addition, the Project Management Plan contains the budget, how changes are going to be managed, how performance, execution, and communication are handled as well as the initial schedule.

Although the project manager is in charge of developing the project management plan, the PM gathers information from all the stakeholders, including the team, in completing the plan. The larger the project, the more input is needed for the many plans that are involved.

This plan is typically generated before the project is executed, and maintained throughout the project. For large efforts, it can take quite some time to create and verify. In most projects, the stakeholders and the sponsors have input into the project management plan. This can lead to conflicts that must be negotiated and resolved before any work takes place.

The project schedule is one component of many contained in the project management plan.

The schedule

The project schedule in a traditional project management methodology is a linked collection of tasks which produce deliverables, moving the project closer to completion and final deliverable. PMBOK (pg. 555) defines the schedule as “An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.”

Traditionally, the schedule is developed and a finish date is determined. Then work begins, and the team works to the finish date.

Team members are very familiar with the schedule. The project manager refers to the schedule, maintains it, and continually verifies it with the team and other stakeholders. It is no wonder that over time, the schedule becomes the “picture” of the project.

Agile Methodology: The stories and the sprints

Agile teams have different priorities than the traditional, sequential project management teams. There is no formal project management plan – but there is a backlog that is managed by the Product Owner.

Scrum is the most popular form of Agile development, and in a Scrum team, the Product Owner holds the vision for the product. He works with the Scrum Master and the development team to determine the product that is built during the sprints.

The work to be done is found in the stories. These stories describe the capabilities of the finished product for the development team. The Product Owner develops and manages the stories, with the help of the customer and the team.

The plan is actually a series of sprints, or weeks of work, that the team agrees to perform based on the stories. Sprints are typically about two weeks, and at the end of that time, there is a working product. The entire project is not done – each sprint completes the agreed upon work on their way to the finished project.

The Sprint Review

At the end of each sprint, the team reviews their work and the process. What worked, what didn’t, and what could be changed to help the team finish more work faster? After a few sprints, the team can predict their velocity, which helps to understand when the project finishes.

Until there is a predictable velocity for a Scrum team, it’s difficult to estimate a finish date.

Unlike traditional project management, there is not one, detailed plan published as an approved document for review in the Agile method. The development team determines what work gets done during the Sprint. The Product Owner is the keeper of the backlog, and any team member or stakeholder can sit in on the daily scrum meetings and the sprint reviews to keep abreast of what is being produced and the completion of the backlog.

It’s a very fluid process.

Project plan and the schedule

Is it true that the project plan and the schedule are the same? In traditional project management, the answer is no – though the schedule is a component of the project management plan. The schedule is often simplified into a milestone chart or Gantt chart for ease in describing the progress of a project team. This chart is often called the “plan.”

For an Agile team, the question doesn’t really make sense. The team works in small, producible increments in short time frames. The scheduled work often changes daily as developers finish and begin the next increment towards the goal of finishing the committed work during the sprint. The plan is different for each sprint.

The next time you have a party, remember that the project management plan is like the directions to your house. The schedule (or the sprint) is the kitchen where everyone hangs out.

The two are definitely related, but not the same thing at all.

This entry was posted in Best Practices, Guest Contributions, PMO, Project Reporting by Deb. Bookmark the permalink.

About Deb

Deb Schaffer, PMP is a project manager, instructor, and blogger. She’s managed software development, IT infrastructure, web development and training development projects for companies such as J.D. Edwards, PeopleSoft, and Lockheed Martin Space Systems. She spent 3 years as the OnePager contact and trainer at Lockheed Martin Space Systems. She resides in the Denver area, helping companies manage training and marketing projects, writing newsletters and blog posts, and mentoring staff. When the weather is nice, find her out on the golf course playing and making notes to update her book, Play Golf, Colorado! Contact Deb on LinkedIn at DebSchafferPMP and at her blog,

Leave a Reply

Your email address will not be published.