Hello, and welcome to another Parallel Project Training podcast. My name is Ruth Phillips, and I’m here with Carmen Campos. Today, we’ll be discussing schedule management in relation to the APM PMQ syllabus for exams starting in September 2024. Welcome to the podcast, Carmen.
Hello, everyone.
Schedule management is quite important for us as project managers. Before we delve into the detailed learning outcomes, Carmen, could you explain what a project schedule is and what the activity of scheduling entails?
Certainly. In simple terms, a schedule is a timetable—a timeline that shows the forecasted start and end of activities within a project. When creating a schedule, we follow a process to determine the overall duration of the project. Often, people confuse a plan with a schedule, so let’s clarify the difference.
A plan provides information not only about timelines but also about what needs to happen. For example, a project management plan, risk management plan, or configuration management plan covers various aspects in more detail. When we talk about a schedule, we’re focused on the ‘when’—when specific activities are predicted to start and finish within the project. It’s about timetabling activities and resources, not the broader plan. This is purely about when things will happen.
Right, let’s look at the syllabus now. The first learning outcome is about defining scope, specifically in terms of outputs, outcomes, and benefits. Why is scope suddenly relevant when discussing scheduling?
That’s an interesting question. In the previous qualification, scope was a separate section. To create a schedule properly, the first thing we need to do is define the baseline scope of work. Without knowing the scope, we can’t identify the necessary activities, estimate durations, or determine resources. Scope is the starting point.
Exactly. The syllabus suggests defining scope in terms of outputs, outcomes, and benefits. That’s a lot of project management terminology—can you break it down for us? First, what is project scope?
Project scope encompasses everything the project will deliver—products, outputs, outcomes, benefits, and the work required to achieve these. In short, it’s everything the project will deliver and all the work involved. This high-level scope needs to be considered at the project’s start, typically when the business case is put together.
For example, if you’re building a new hotel, the hotel itself is an output. This output leads to a change, which is the outcome, such as increased accommodation capacity in the area. The benefits are the positive impacts of this change for different stakeholders. For instance, the hotel might generate financial benefits, boost local businesses by attracting more visitors, or create employment opportunities.
That’s quite a broad definition of scope. If you were speaking informally, people might think of scope as just the work needed to deliver the outputs. But we’re also including the outcomes, benefits, and all the work required to achieve these, making it a much wider definition.
Yes, it is. The challenge comes when we need to detail the scope, especially for linear projects, which require a well-defined scope from the outset. This is critical during the concept phase, where we work on the business case and start fleshing out the high-level outputs, outcomes, and benefits.
So, how do we get to that more detailed scope in the definition phase? What steps do we take?
We can use tools and techniques to map out all the deliverables and products that make up the project, as well as the work required to develop them. It’s crucial to consider not just the output but also the outcomes and benefits. For example, if your hotel is a five-star resort with on-site cafes and attractions, you might not achieve the benefit of helping local businesses as effectively.
A robust business case helps the project manager think through all the necessary products and deliverables. For example, a product breakdown structure (PBS) can break down the hotel into its constituent parts—car park, playground, spa, main building, etc.—and help identify all these deliverables. Don’t forget the managerial products, like documentation and the project management plan, which also need to be delivered.
Absolutely, both the managerial and physical deliverables need to be considered. This process helps visually represent everything in a structured way.
So, we have this hierarchical visual representation of everything we’ll deliver. How much detail do we go into? How far should we break down these products or outputs?
It depends. There’s no one-size-fits-all answer; it varies with the scale and complexity of the project. However, two key considerations are that each product or deliverable should have a unique identification and a set of associated requirements. This helps with scope management and change control later on, as you can check for quality against these specifications.
That makes sense. So, that’s our product breakdown structure. The syllabus also mentions a work breakdown structure (WBS). How is that different?
While both tools provide a visual representation, the work breakdown structure focuses on the scope of work. It maps out the activities and work elements that constitute the project’s scope of work. Using the hotel example again, you’d break down the work into design, construction, electrical work, plumbing, etc. Each task leads to a deliverable—the design work results in drawings, construction work results in a wall, and so on.
I see the difference. But why do we need both? Why not just create a WBS or a PBS?
It’s useful to have both because each can help identify gaps in the other. Thinking about products might highlight missing work, and detailing the work might reveal overlooked products. Ultimately, the tasks at the lowest level of the WBS form the basis for scheduling the project.
The syllabus also mentions a cost breakdown structure (CBS). We discussed this in more detail in another podcast on budgeting and cost control, but could you briefly explain what the CBS is and how it relates to schedule management?
Certainly. The cost breakdown structure categorises the project’s costs, such as people, equipment, materials, expenses, and managerial overheads. The CBS, when used alongside the PBS and WBS, helps assign costs to work packages, giving the project manager an overall financial view. This level of detail is valuable for tracking performance against the budget.
I see how the PBS, WBS, and CBS help define the scope by identifying activities and resources needed. Our next learning outcome is understanding the links and dependencies between activities within a project and with business-as-usual activities. How do we move from having a WBS to forming a schedule with dependencies?
Good question. Once the scope of work is defined and agreed upon by stakeholders, we need to consider the dependencies and logical sequence of tasks, as the WBS only represents them hierarchically. We need to determine what needs to happen before something else.
For example, you can’t plaster the walls until the plumbing is in place. After establishing these dependencies, we consider the resources needed to complete the tasks. The WBS helps identify these resources, such as electricians for electrical work. Some resources might be project team members, while others could be external or from business-as-usual operations, requiring us to consider dependencies with those activities as well.
Exactly, and these dependencies include both natural ones, like waiting for plaster to dry before painting, and resource dependencies, such as needing a financial accountant who might be unavailable due to business-as-usual commitments.
Yes, and when discussing resources, we must also consider other categories, such as materials. For instance, a painter might be available, but if the paint itself has a lead time and isn’t available as scheduled, we might need to adjust and optimise the schedule. We also need to estimate durations without knowing exactly who will perform the work, making the initial estimate a prediction that might need revision.
Which leads us nicely to the final learning outcome: estimation. As you mentioned, estimates are based on various factors like resource type and skill level, so we’ll need to re-estimate and optimise our schedule as we progress through the project lifecycle. What are some reasons for this, and what benefits does it bring?
The main benefit is increased accuracy in our estimates. As more information becomes available, our confidence in these estimates grows, improving our chances of adhering to the plan and meeting success criteria. Common reasons for re-estimating include incorrect assumptions, changes in project scope, or external factors.
I love the analogy of a project manager with a crystal ball captioned, “I’m a project manager, not a magician.” Early in a project, so much is unknown, making initial estimates less reliable. As we gain more information, it’s crucial to re-estimate to improve accuracy.
Exactly. More information, changes, external factors, and even expert insights gained later in the project can all necessitate re-estimation. We also talk about critical path and critical chain methods in the PMQ course, which help with scheduling. While it’s easier to understand these methods with visual aids, could you give a brief overview of each?
Sure. The critical path method identifies the shortest time to complete all project activities in logical order. Software like Primavera or Microsoft Project can calculate this automatically, but it’s essential to understand the underlying logic to verify the results. The critical path highlights activities with no slack, meaning any delay affects the project’s end date.
The critical chain method, on the other hand, focuses on resources. It considers resource availability to determine the shortest time to complete the project, accounting for resource constraints.
I recommend using the study guides for visual aids to better understand these methods. I think we’ve covered the three learning outcomes well, Carmen. We’ve discussed defining scope in terms of outputs, outcomes, and benefits, and how to break it down using product, work, and cost breakdown structures. We also looked at dependencies and the importance of re-estimating and optimising schedules, along with some techniques to help us throughout the project lifecycle.
We’ve had a good discussion on schedule management. Thanks very much, Carmen.
Thank you.
