Project Scheduling: Your Essential Guide

A project plan is at the heart of every successful project. At the heart of every project plan is project scheduling to set the timing of each activity.

In this guide, we’ll look at all the key elements of project scheduling. We will largely follow the process structure in the 6th Edition of the PMI‘s Project Management Body of Knowledge (PMBOK Guide). It’s a reliable guide. But, we’ll also step outside it’s Project Scheduling Knowledge Area (KA), to survey the full scope of the discipline.

Project scheduling is the creation of a plan for when the project will deliver its products (or deliverables). This will include how it will time and sequence all the activities that you will need to carry out and how and when you will apply resources to each task. The rusulting document (or document set) is your Project Schedule.

What is a Project Schedule?

At its simplest, your Project Schedule is a timetable of what you will do and when you will do it. It shows a planned start and completion date for each activity. This means estimating resource requirements and task durations, and understanding the formal dependencies and ogical sequencing of the tasks within your schedule.

Necessarily, it will also show the resources that you will allocate to each activity. So, this means that it is not possible to separate the scheduling processes from those of resource management.

Likewise, it starts from the things you’ll need to produce and the tasks this will need. So, again, project scheduling is also closely associated with your Project Scoping processes.

Your Project Schedule will be a key project document that will need formal approval. But it will also need to remain under constant review. You will probably have to revise and update your project schedule during the life of your project; sometimes many times.

Before We Start

Here is a video that will get us started…

How does the PMBOK Guide Define Project Schedule?

This is how the Glossary section of the 6th Edition of the PMBoK defines Project Schedule:

An output of a schedule model that presents linked activities with planned dates, durations, activities, and resources.

A Guide to the Project Management Body of Knowledge, 6th Edition.
© The Project Management Institute, 2017.

How does Your Project Schedule Relate to Your Project Pan and Project Management Plan?

Sometimes, people use the terms ‘Project Plan’ and ‘Project Schedule’ interchangeably. In truth, your project schedule is one part of a larger project plan for how you will deliver your project.

And that, in turn, is governed by what the PMBoK calls a ‘Project Management Plan’. This sets out how you will manage your project:

• planning it
• delivering it
• monitoring it
• controlling it
• closing it down

In the PMBoK, the Project Management Plan is the output of process 4.2: Develop Project Management Plan.

The Project Scheduling Process

The figure below illustrates the Project Scheduling process. It also includes other, related, elements that form part of project planning.

We will use this chart as our navigations aid. But, because the PMBoK is an important guide to many of our readers, who may be considering preparing for a CAPM or PMP qualification, we’ll relate our process back to the guidance within the PMBoK.

[thrive_text_block color=”note” headline=”Resources for Potential PMP or CAPM candidates”]
PMP versus CAPM: All You need to Know

PMP Certification: What You Need to Know [Complete Review]

The PMI Talent Triangle: A Guide [for members and non-members]

What is the PMI? | Video

PMI Education Contact Hours and PDUs: Your Essential Guide

PMP​ and CAPM Exam Preparation

[/thrive_text_block]

Plan Schedule Management (PMBoK 6.1)

This part of the process sets the context for how you will carry out your project scheduling. In the PMBoK process (6.1), the output is a Schedule Management Plan. It forms part of the wider Project Management Plan that we described above.

What to Take Account of

There are a number of other key inputs. The PMBoK identifies them as:

1. Project Charter
2. Project Management Plan
3. Enterprise environmental factors
4. Organizational process assets

I would add three other essential elements:

1. An understanding of the opportunity or problem that is driving the project You will need to take this in conjunction with your understanding of the wider enterprise environment
2. The team’s experience and skill-base, which will link to the organizational processes
3. Stakeholder perceptions: what the need, want, and expect

The Content of your Schedule Management Plan

The essential elements of your schedule management plan will be your approaches to:

• Project Scheduling: how you will create your project schedule. The policies and process you will apply, and the tools you will use.
• The data that you will need, to create your project schedule: activities, external constraints and dependencies, and resource availability
• How you will monitor, control, and review your project schedule

For me, the most valuable part of this process in the PMBoK is the list of additional components of the schedule management plan, in section 6.1.3.1. I’ll summarize it:

• Project Schedule model development
• Release and iteration length
• Level of accuracy
• Units of measure
• Organizational process links
• Project schedule model maintenance
• Control thresholds – I think of this as particularly important
• Rules of performance measurement (these link to how you may use Earned Value Management – EVM)
• Reporting formats

Define Activities (PMBoK 6.2)

The first step in actually creating a Project Schedule is to define the activities that the project will need to carry out. For many project managers, this is the task of scoping.

However, for PMBoK users, ‘scope’ refers to the products or services the project produces: its outputs or deliverables. For project managers coming more from the UK tradition, scope refers to the scope of work; the full set of activities that you’ll need to carry out. We have a companion guide called: ‘Scope Management Plan: Everything You Need to Know’.

Producing Your Activity List

Consequently, the tools you will use for this will depend on your interpretation of ‘scoping’.

For some, you will start with an activity-based Work Breakdown Structure (WBS) as the primary method for producing your comprehensive list of activities. But, if you come from a US/PMBoK tradition, you will decompose your product-based WBS (PMBok process 5.4) and consider the activities you will need, to produce each of the deliverables.

A note on Milestones

PMBoK considers a milestone list as an output of this process. I think of it as more fundamental. So, we’ll consider this as a separate step, after we’ve looked at sequencing.

Sequence Activities (PMBoK 6.3)

Sequencing the activities in your project plan is about deciding the order in which you will carry them out. There are two factors you will take into account:

Mandatory (or absolute) Dependencies

These are dependencies that determine a necessary sequence of activities. You have no choice in the order of two more tasks, because it is constrained by on or more of:

• cold, hard logic
• contractual necessity
• legal constraints
• technical or physical limitations

Discretionary (or preferred) Dependencies

These set a sequence based on what you and your project team consider to be best practice or the most advantageous way of doing things.

Here, there are more than one way to structure your sequence, but you lock in one approach for your own reasons:

• good practice
• priority
• expediency
• resource availability

There will be consequences to your choices here. So, it is essential that you document these choices and the reasoning you have applied. This may be part of your ‘Assumptions List’.

Types of Dependency

The first way to think of dependencies is to consider where they come from:

• within the project (‘internal dependencies’), or
• outside the project (‘external dependencies’), over which you and your team have no control. These most often arise from enterprise-wide policies and procedures – especially timing related – or from statutory processes and new regulations. These will call-back to thinking you’ll have done at the Plan Schedule Management process.

Formal Dependencies

Unfortunately, we don’t have space here to go into this aspect of project scheduling in detail. But, you will need to understand the four potential types of dependencies and their relative commonness.

1. Finish-to-Start Dependencies. These are the most common, by far. They are also the only type that is used in highly-structured formal project scheduling. Here, task B cannot start until task A is complete. (Note that we’ll look at exceptions to this definition soon, under ‘Leads and Lags’)
2. Finish-to-Finish Dependencies. These are somewhat common and the best example is cooking where everything needs to be ready to go onto the plate at the same time.
3. Start-to-Start Dependencies. These are less common in project management, but vital to fair play in a race.
4. Start-to-Finish Dependencies. While it is theoretically possible for the finish time of some task B to be set by the start time of its predecessor, A… I’ve never seen this and neither have I ever been able to formulate a credible example. If you have, please tell us in the comments!

Leads and Lags

But what if task B needs to start after the completion of task A, but not straight away? Maybe 1 week later? That’s a ‘lag’ of one week. Or maybe it needs to start 2 days after task A starts. That’s a ‘start-to-start dependency with a 2-day lag’.

Or, maybe task B needs to start 3 days before task A finishes? That’s a ‘finish-to-start dependency with a 3-day lead’.

Project Milestones

Milestones have two purposes in Project Scheduling (and another in Project Control).

In project scheduling, your milestones can either :

1. Reflect external constraint or dependencies that will drive timing decisonons for our project
2. Create time constraints within which you choose to work, by setting deadlines for work packages or key activities

Together, these two uses create a framework within which you will make project scheduling decisions.

So, a milestone list can be one or both of:

• an input to your project schedule
• an output as a part of your project schedule

Estimate Activity Durations (PMBoK 6.4)

For my money, estimating is the hardest part of this process. You’ll need to deploy a range of estimation techniques to maximize the likelihood that you have a robust schedule, and minimize the risk of optimism bias.

PMBoK’s ITTO (Inputs, Tools & Techniques, Outputs) for this process (6.4) provides a long list of documents that will contribute to this, but I think it more helpful to focus on the steps you will take to estimate the durations of activities.

Estimating Effort

The effort you will need for any task will depend on the:

• Scale and complexity of the task
• Skill level and productivity of the people undertaking it (for which track-record will be a valuable indicator)
• Motivation and availability of the people you will allocate

You have a number of estimating methods you can use, but these are outside the scope of this article. So, do take a look at our article: ‘Project Estimation: Master the Art and Craft’. These include:

• Bottom-up estimating
• Parametric estimation
• Analogous estimates
• Three-point estimation

Develop Schedule (PMBoK 6.5)

Now it’s time to put all of your work together into a project schedule. There are many tools for building your plan, of which the most frequently used are the various forms of Network Chart. These allow you to lay out the sequence of tasks as the dependencies specify, and add durations to each.

Common conventions for how to do this are the:

• Critical Path Method (CPM)
• Program Evaluation and Review Technique (PERT) – which uses three-point estimates
• Gantt Chart
• Critical Chain (less common)

Allocate Resources to Your Project Schedule

In the PMBoK, this is subsumed into process 6.5, Develop Schedule, in the form of ‘Resource Optmization‘ (6.5.2.3). However, I think this is a significant-enough task to deserve its own step.

Here is where you will assign specific resources to each task. Of course, I principally mean people, but you will also allocate physical resources like assets, materials, and equipment).

Thinking about your people, you will also beed to think about:

• Sharing the workload fairly and making sure you don’t ask anyone to do more work than they have the capacity for within any time-frame. This is called ‘resource leveling‘ and also applies to other resources.
• Accounting for non-productive time, like holidays and other, non-project, work

Note Your Assumptions and Risks

I know that we have talked about logging assumptions for your discretionary dependencies above, but there is more to note. Project scheduling is at the heart of making sure you deliver your project on schedule. So it is a source of significant risk.

And risk arises from two things:

1. Unknowns
2. Untested assumptions

You will need to manage both of these throughout your project. So, youmust therefore record them as you go.

Control Schedule (PMBoK 6.6)

Shift happens and your project will slip against its baseline schedule. So, you will need to:

• monitor progress against schedule, and make forecasts
• intervene to address slippage (or the threat of slippage)
• review your project schedule and reassess it and the assumptions on which you based it
• maintain it under effective version control

As you progress, you will learn more about your project and better understand the risks you face. So, you need the flexibility to amend your project schedule throughout your project. And, I recommend you do so in a planned way – either at key milestones or on a regular cycle (such as quarterly). This does not mean, by the way, that you are not free to review your schedule whenever the need arises.

Another important aspect of schedule control is managing change requests. If that’s of interest to you, we recommend our article, ‘OnlinePMCourses Guide to Change Control’.

The Tools and Techniques of Project Scheduling

It would take a whole series of articles to fully describe the tools and techniques that you can use as part of the Project Scheduling prcess. However, this article would not be complete if I did not list some of the most important ones.

And no, I’m not just doing to copy out all the tools and techniques from the PMBoK ITTOs. Of course, you know that expert judgment, data analysis, and meetings will be involved. You can look those up as well as I can, if you are studying for a CAPM or PMP qualification.

But, I do want to point you in the direction of some of the most important tools:

• Work Breakdown Structure (WBS)
• Critical Path Method (CPM)
• Program Evaluation and Review Technique (PERT) – which uses three-point estimates
• Gantt Chart
• Critical Chain (less common)
• Project Management Information Systems (PMIS)
• Earned Value Management / Analysis (EVM / EVA)
• Burndown and Trend Analysis
• Scenario (what-if) analysis
• Resource Levelling
• Variance analysis

Tips and Advice for Project Scheduling

To end this survey, I would like to highlight a few simple tips, from my own experience.

‘More brains are better than few brains’

And some brains are better than one. By which, I mean: don’t try to do your project scheduling on your own. If you have a team, harness their wisdom. You get two major advantages doing this:

1. By applying multiple minds to the problem, you are far more likely to get more robust estimates and more rigorous logic.
2. When team members have taken some responsibility for the plan, they are far more likely to stick to it. The excuse ‘I never believed in your schedule anyway‘ is not going to be a runner, is it?

Better yet, Distribute Planning and Scheduling

My preferred approach to all aspects of planning: scoping, scheduling, and budgeting is simple. I allocate chunks of that planning to workstream leaders and ask them to work with their teams to put together the scope, schedule, or budget.

My job is then to make sure each component meshes together without overlaps or omissions. I leave the technically demanding details to the technically adept experts on my team.

Small Projects are Different

I would not, for one moment, want to suggest that the steps in this article are all mandatory discrete steps for every project. A lot of the peopke I train and who are in our OnlinePMCourses community do small projects.

If you’re one of them, then for you, everything but controlling the schedule is a single process. You’ll do all of it in parallel, and probably on your own or with just one or two colleagues. That’s fine.

And Finally, it’s an Iterative Process

I cannot emphasise enough the degree to which a simple process flow often misrepresents the way we do projects and, most particularly, how we plan them.

For example, I could make an equally strong case for swapping the sequence of some of the steps in the process above. There are numerous equally valid approaches. Because none properly represents the way we really work

What we actually do is work through the process until we get to a settled answer at one step. Then we cycle back over the previous steps to:

• check what we have is self-consistent
• see if there are ways to further optimize what we have done

This constant cycling back and reviewing – or iteration – is the true nature of project definition, project planning in general, and project scheduling in particular.

What is Your Experience of Project Scheduling?

We’d love to hear from you about your ideas, experiences, and questions about project scheduling. Please do contribute to the comments below, and we’ll respond to everything you write.

By the way… What of the future?

You may like this video on How to Use Machine Learning in Project Estimating, Scheduling, & Planning: