Leadership

Supervise larger projects with a schedule management plan

As your project grows larger, your project management processes need to become more rigorous and structured. On a larger project, you may need to plan ahead to understand and communicate how you will manage the schedule by creating a schedule management plan. Find out what such a plan should entail.

As your project grows larger, your project management processes need to become more rigorous and structured. (The reverse is also true: Processes should be simpler for smaller projects.)

Normally, the process used to update and manage a project schedule is pretty clear. For example, you might receive updates from your staff every Friday and assign new duties each Monday.

However, such a simple process may not be rigorous enough for a very large project. The project manager on a larger project may need to plan ahead to understand and communicate how he or she will manage the schedule. The document used to define this is a schedule management plan.

A schedule management plan is part of the overall project management plan, which includes all of the documents the project manager needs to manage the project successfully.

Here are some specifics that a schedule management plan can define for a project:

  • Roles and responsibilities: Describe different roles, and define their responsibilities for schedule management.
  • Schedule owner: This is likely the project manager. It would be rare that a formal project manager would not own the schedule.
  • Update responsibilities: Normally the project manager is in charge of updating the plan, but things can be more complex on larger projects. For example, a project administrator might make the initial schedule updates based on the project status reports and then send the draft to the project manager for final updates. Team members can also update the status of their assigned activities, leaving the project manager to perform a final analysis after those updates.
  • Access to the plan: Schedules are typically not kept confidential, so anyone can access and read them. However, if you have reasons to keep the schedule more secure, you can specify the access. For example, you might not want contractors to read it.
  • Update frequency: Describe the timing of schedule updates. In many projects, users update the schedule on the morning of the first workday. While you should update the schedule at least weekly, you may also want to do so more often.
  • Progress feedback: Describe how you want team members to provide schedule feedback. Such feedback often comes in the form of a team member status report, but it may also come during meetings or through e-mail. Use this section to define how you want to receive this feedback to minimize confusion with team members.
  • Schedule change review and approval: Define the process required to evaluate and approve proposed schedule changes. You should also describe who has the authority to accept and approve changes to the schedule. Keep in mind that the approval process doesn't include internal activity deadlines; instead, it applies to changes in the overall project deadline. The project manager may have some discretion to extend the deadline date by some number of days or weeks, but after a certain threshold, some formal body may need to approve the change.
  • Tools: Describe any scheduling tools that the team will use on this project, who has access to the tools, and what team members can do with the tools (e.g., read the schedule, update schedule, etc.)
  • Reports: Define the types and names of reports you're using to manage the project, who creates them, who receives them, the frequency of the reports, etc.
  • Schedule integration: While projects normally keep independent schedules, the master schedule can also serve as a roll-up of other underlying schedules. You could also integrate the schedule with a higher level program or portfolio schedule.

All of these suggested items are components you should think about and define when beginning a larger project. Once you've created the schedule management plan, don't forget to communicate the information to all interested stakeholders -- and make sure you follow the plan throughout the duration of the project.

Want more information about managing successful projects? Automatically sign up for our free IT Project Management newsletter, delivered each Wednesday!

6 comments
CfK
CfK

In principle I agree with many of the detail points raised. The core of your article is "A schedule management plan is part of the overall project management plan...". I have many times applied exactly this approach to projects both large and small. Key here is that it is a part, not the whole. A project manager's time should not be consumed by every detail of the project, and attempting to micro-manage and record every aspect. If the PM is doing that then the PM may as well do the whole project work personally and do away with the project team. Rather the objective is to provide a framework and a set of standard tools that the project members can use easily to predict and record tasks, time, effort, cost, and so on. These tools should be integrated in that the project administrator, or PM if a smaller project, can produce rollup reports that give accurate, up to the minute, information about the health of the project and all its constituent parts, including schedule, financial, and resources. The report should highlight where risks are occurring, and allow the project manager to quickly drill down to the particular work element that is causing the issue, identify who is responsible for that element, and take corrective/mitigative action as appropriate.

rodbell101
rodbell101

Imo, the key advice in Tom's article is upside down: Bluntly put, it's wrong. Tom says: "As your project grows larger, your project management processes need to become more rigorous and structured. (The reverse is also true: Processes should be simpler for smaller projects.)" I advise the opposite: Larger PM processes need to be formulated as minimally detailed modules bounded by best-guess scheduling parameters. Each module should be a mini-project whose successful completion includes a detailed plan for the next module. Each module will include, as part of its schedule and activities, the tasks for detailed planning of the next module. The next module of the larger project, then, should be rigorously structured and closely scheduled, down to such details as scheduling--and confirming with follow-up calls or emails--meetings as called for in the module's project plan. But this detailed scheduling should be done near the end of the preceding module, and near the beginning of the current module. As a rule, detailed planning is most effective for near-term tasks and events. The longer the chronological scale, the less reliable is any schedule. (Apply this principle to getting tickets for a major event that is "sold out" many months in advance. Go to the big game on the day of the event, and wait until it's almost kick-off time. There will be tickets available, probably at face value. That's because some people won't be able to come to an event they scheduled 6 months in advance, and some scalpers will hold out too long to get peak prices for those tickets.) There's more to putting together such a plan than I can detail here (how do you construct, schedule, and budget the "big and simple" schedule, and how do you modularize it?), but I hope the main point is clear: Do not try to control a large-scale project with a detailed, rigorous schedule. Schedule the big project in terms of broad-stroke events and deadlines; schedule the modular components, the "small projects", in terms of a rigorous and highly detailed set of tasks and deadlines.

blarthomore
blarthomore

My experience has been that too much of the project manager's time is consumed with project administrative "crip-crap," e.g., keeping the project spreadsheet up to date, when the "bean counting administration" should be handled by a person tasked with the up-dating of the plan. The managers should be spending their time working the project details with the team and the stakeholders. Many of the job listings for PM's include a requirement for strong MS Project knowledge. Running an accounting program is not nearly as important as maintaining and managing coherence with the functional elements of the tasks at hand. I want a really good, detailed oriented, lieutenant keeping track of the metrics, i.e., putting the data into the project management software, and presenting those metrics to me in an actionable format.

patclem
patclem

I've seen so many times - project managers and business owners so focused on budgets, charters, scope and even requirements documents, none of which any of the people doing the real work EVER look at. At the same time, the schedule is a great big mess. To stay off the report that shows their project yellow or red, project managers go work the schedule. Tasks are marked as complete that are barely started. Other tasks that are finished early aren't even marked as started. IMHO, the schedule IS the project. If your schedule isn't rock solid, and being used and recognized by the team, the responsibility of project management has failed. Last thing - KISS. Keep it simple. Too many project schedules are too complicated or not at the right level of detail. Law of Systemantics - complex systems are most likely to fail. Thanks for this article. More common-sense schedule management techniques are needed out here.

griffonconsulting
griffonconsulting

You wrote "Many of the job listings for PM's include a requirement for strong MS Project knowledge. Running an accounting program is not nearly as important as maintaining and managing coherence with the functional elements of the tasks at hand." The key here is strong knowledge. I routinely have a Project Control Officer who is charged with the responsibility of keeping the nitty gritty of the MS Project file up to date. My role as a Project Manager involves using that data. Thus, the strong knowledge of how the software works leads to a much better understanding of what the information presented through reports means. It is often said that knowledge is power. I prefer, use of the knowledge you possess is power. When I teach the theory of scheduling and cost control the focus is in the use of the information. For example, there are many discussions on variance calculations and the use of float that occurs in a schedule. I have to keep bringing the people back to the point where it is not as important to know how the calculation is done, but to understand what it means and what you need to do about it. Sure there are some discussions regarding the nitty gritty stuff, but the key is that those who are reading the information must understand what it means. Unfortunately, there are many organizations to do not see this; they just view use of the tool (and knowledge of how to use it) as being the whole solution.

petraborchert
petraborchert

I completely agree that "too much of the project manager's time is consumed with project administrative crip-crap". Ideally, PM should reduce work - not create more paper/busy work. That is where the power of the project manager is truly flexed. The article notes that the schedule could be open to the team. Most of the tasking & scheduling should be open to the team. This requires however, a system that everyone in the team can easily operate in (perhaps a spreadsheet instead of MSProject or a checklist sign off w/ dates, etc). Each team member tracks his/her own progress in the documentation, with the PM overseeing the progress. Again, the key is to keep that system simple. So that it doesn't create more work for the team and the PM. The team member should spend less time updating his/her progress than it takes to type and email to the PM explaining the progress. This method promotes: + team-member ownership, buy-in, and accountability + PM focus on project rather than paperwork + live updating

Editor's Picks