5 Ways You May Unintentionally Create Schedule Risks

The Problems with Crashing, Fast Tracking, and other Schedule Compression Techniques

How do project managers unintentionally create schedule risks? As a result, perhaps you feel a cloud of uncertainty about your schedule.

5 Ways You May Unintentionally Create Schedule Risks

Image courtesy of Adobe Stock.

Many times, it starts with pressure from a sponsor to deliver the goods early. For sure, project managers have a responsibility to work with their sponsors to understand the requirements and to complete the projects within the sponsor-imposed deadlines. Rather than wasting our time complaining about the deadlines, how can we work with our sponsors and team members to find solutions to schedule issues?

My friend Colin Gautrey has some wise advice on 8 Ways You Can Better Respond to Unrealistic Demands.

As we work to develop and compress our schedules, let’s be aware of the common causes of risk. We will be in a better position to manage the risk and deliver our projects on schedule.

5 Causes of Schedule Risk

  1. Crashing the schedule. It’s always been funny to me that the Project Management Body of We have too many cooks in the kitchenKnowledge uses the word “crashing” as a schedule compression technique. The term makes me think of an uninvited guest crashing a party, but with schedule management, the individuals are actually invited to the party. Project managers use crashing to shorten the schedule for the least incremental cost by adding resources, typically to the critical path. It can be a great technique — just be aware — crashing may increase your risk. Too many cooks in the kitchen spoil the broth.
  2. Fast tracking. Here’s a technique to shorten the schedule by performing activities in parallel for at least a portion of their duration. For example, we might start work on a software design while the team is working on the requirements. Consequently, this technique may increase your risk and requires good communication and coordination; otherwise, it may be anything but fast.
  3. Assigning the wrong resources. You ask a manager for a resource for your project. In return, you get the person who is least busy, not the skilled resource you need. Rather, Susan, an experienced project manager describes specific skills needed and uses her influencing skills to persuade the manager, greatly improving her chance for securing the queen resource. What’s a project manager to do when resources are preassigned?
  4. Making sequence mistakes. John, an inexperienced project manager, failed to work with his team to sequence the project activities properly, resulting in issues which were discovered after the schedule was approved. As a result, John has learned to engage his team members when identifying and sequencing future project activities.
  5. Failure to baseline your schedules. The project manager and team did a great job in breaking down the project, identifying activities, and creating the project schedule. However, the project manager failed to get approval for the schedule. What happened? Yes, the schedule changed. The team did not have a baseline for comparison resulting in significant uncertainty about the health of the project. Like building a house without a plumb line, who knows if the walls are straight?

Question: What other ways have you seen project managers unintentionally create schedule risks?

What tips do you have for breaking down your project into deliverables and activities?

I asked this question on LinkedIn: What tips do you have for breaking down your project into deliverables and activities? Bill Duncan responded with the following tips (which I thought were great):

  1. Recognize that “work packages” are only the lowest level of the WBS from the buyer’s perspective in a contracting environment.

  2. Recognize that any deliverable can be described as an activity (by adding a verb) and any activity can be described as a deliverable (by removing a verb). Don’t worry about the distinction until you have the decomposition done.

  3. Decomposition happens phase-by-phase. You can’t develop a complete WBS for a non-trivial project at the start.

  4. When you are confident that you can estimate cost and duration, you have enough detail.

  5. Every lower level must be both necessary and sufficient for the item above it.

  6. Every item occurs once and only once.

What else would YOU add?

Check out my article on How to Break Down Your Projects.

How to Break Down Your Project

Scope and Schedule Management

How should you break down your project?

Steven Pressfield said, “A great trick that I learned having worked as a screenwriter for many years, the way screenwriters work, is they break the project down into three-act structure: Act 1, Act 2, Act 3. I think that is a great way to break down any project, whether it’s a new business or anything at all.”

How to Break Down Your Project

Image courtesy of Adobe Stock

Whether we are creating a Pixar movie, a building, a highway, or a service center, wise project managers break down their projects into pieces. As we do, we create a structure for the project that helps stakeholders understand the project.

Some people struggle with the challenges of creating large, complex systems, highways, and companies. How can we do this? The answer: one bite at a time. Breaking projects into pieces makes the impossible possible. In addition, the break down creates the vision.

How to Identify Scope Risks

8 ways to identify scope risks

Some project managers struggle to identify scope risks. Why?

How to Identify Scope Risks

Image courtesy of Adobe Stock

First, individuals may lack a concrete understanding of scope; scope seems to be a nebulous concept. WHAT exactly is scope?

Second, individuals may not know HOW to identify scope risks.

Either way, the failure to identify (and manage) scope risks can be costly. It’s like an overdrawn bank account. There are all kinds of penalties and fees if you know what I mean.

What are Scope Risks?

Risks are uncertain events or conditions, that if they occur, will have a positive or negative effect on the project objectives. What are some examples of scope-related risks?

  • Individuals may add features to the product that were not approved.
  • The project team may not identify all the deliverables, requiring changes later.
  • Scope changes may not be processed through the change control process.
  • Requirements may not be properly analyzed and understood.
  • Requirements may change and affect the deliverables.
  • Requirements may not be properly prioritized.
  • The design may be simplified resulting in less effort and cost.
  • Traceability structure may not be developed resulting in requirements not being managed through the design, development, and testing processes.
  • The project team may fail to identify all the activities required to create the deliverables.

Keep in mind that scope is the sum of the products, services, and results to be delivered through the project. Product scope includes the features and functions of the products, services, and results. Project scope is the work required to create the deliverables.

How to Attack the Enemies of Scope Management

Why is scope management so difficult? What enemies cause us scope issues?

Let’s first consider the essence of scope management: “to ensure that the project includes all the work required, and only the work required, to complete the project successfully,” according to the Project Management Body of Knowledge (PMBOK). Let’s take a look at each part of this statement.

How to Attack the Enemies of Scope Management

Enemy #1 – Not Including All the Work

Some project managers have a bad habit – they create their project plans with little input from the stakeholders. What’s the result? The project manager may miss key deliverables. They do not have ALL the work required in their project plan.

The What, Why, and How of Project Requirements

Learn technical skills to accelerate your projects through requirements development

How big of a deal are project requirements?

The Project Management Institute says, “47% of unsuccessful projects fail to meet goals due to poor requirements management.”

In his book — Just Enough Requirements Management — Alan Davis shares, “Various studies suggest that errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product.”

The What, Why, and How of Project Requirements

Photo courtesy of Adobe Stock

What are Project Requirements?

Project managers talk about this topic a lot. Stakeholders hear the term “requirements” but interpret the meaning in different ways. Before we can manage anything, it’s critical that we have a working definition.

3D Question Word What on white backgroundRequirement: something that is needed or that must be done. –Merriam-Webster Dictionary

The Project Management Body of Knowledge defines requirement as “a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.”

Karl Wiegers — author of Software Requirements — shared this definition: “Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute.”

How to Develop a Simple Scope Management Plan

5 Questions for Developing a Scope Management Plan

How can you develop a scope management plan quickly that provides value to the project? It’s not as complicated as it may seem.

How to Develop a Simple Scope Management Plan

Photo courtesy of Adobe Stock

Some project managers check the Project Management Body of Knowledge (PMBOK) for advice, which I think is a great place to start. However, project managers may make the following mistakes: Individuals may see the PMBOK as a prescription and include every element for every project. On the other hand, some people see all the “required steps” and throw their hands up, deciding to do nothing.

I am a simple guy that likes simple ways of doing things. I use the PMBOK as a guide, but I determine which parts make sense for each of my projects.

Not familiar with terms such as a scope management plan, WBS, or scope baseline? Here’s a quick summary.

5 Questions to Ask

Here are some questions I answer when developing a scope management plan:

Have You Left Anything Out of Your Project Plan?

The Project Plan Checklist

Have you left anything out of your project plan? Check out this project plan checklist to help you identify the baselines and plans that will be most helpful to each of your projects.

I like to keep my project plans as simple as possible. For many project plans, I will only have three or four of the items in this checklist. But I like to make sure that I’ve not skipped something that was needed.

As I define my baselines and plans, I strive for clarity, brevity, and simplicity. My aim is the create a project plan that is easy to understand and that helps me and the project team achieve the project objectives.

Project Plan Checklist

Image courtesy of Adobe Stock (edited in Canva)

Project Plan Checklist


Scope Baseline

  • Project Scope Statement – describe product(s), project work, major deliverables, assumptions, and constraints
  • Work Breakdown Structure – create a hierarchical decomposition or outline of the scope of work to achieve the project objectives and to create the deliverables
  • Work Breakdown Structure Dictionary – provide the detailed information about the deliverables, activities, cost estimates, and scheduling information for each item in the WBS

Schedule Baseline – approved version of the schedule

Cost Baseline – approved version of the project budget

What is the Management Reserve for Project Budgets?

How to budget for the unknown unknown risks

Have you ever had a budget crisis due to the lack of a management reserve? Unforeseen work comes knocking at your door. You look at your budget, but you don’t have the funds to handle this work.

What is the Management Reserve for Project Budgets?

Image courtesy of Adobe Stock

There is a better way to handle the unexpected. You can — assuming that your organization supports the concept of reserves — create a management reserve when estimating the cost of your project. Let’s dig a little deeper.