Welcome to another Parallel Project Training podcast. My name is Ruth Phillips, and I’m here with Carmen Campos, one of our senior trainers. Today, we’ll be discussing resource management as outlined in the APM PMQ syllabus, launching in September 2024. Welcome to the podcast, Carmen.
Hello, everyone.
In this podcast, we’ll review the syllabus learning objectives and outcomes, discussing what the APM expects us to understand about resource management. The learning objective states that we need to understand that resource management involves identifying and scheduling the necessary internal and external resources. So, it’s all about resources today. Let’s start with the first learning outcome. Carmen, can you talk to me about resource management on a project? But first, let’s go back to basics—what exactly is a resource?
Simply put, a resource is anything or anyone you need to complete the project successfully. This could include personnel, materials, supplies, technology, and equipment. Resources may be shared with other projects or specific to your own project.
Okay, so the syllabus mentions internal and external resources. What’s the difference?
Internal resources are those within the organisation, such as staff or equipment. External resources are those you need to procure from outside, perhaps from third-party suppliers or contractors.
That makes sense. So, what is resource management, and what does it involve?
Resource management involves several activities, including identifying resource requirements, scheduling resources (which means allocating them to your project timeline), and actively managing those resources throughout the project lifecycle.
Right, these three activities are crucial because, even with all the planning and scope definition, without the necessary resources, none of the work can get done. So, it’s fundamental to project success.
Exactly.
Our first learning outcome is to know how to determine the resources required and their availability to deliver activities within a project. You mentioned three activities within resource management. Let’s talk about the first one: how do you identify resource requirements?
The first step is to thoroughly understand the project’s scope, especially in a linear lifecycle. Without knowing the deliverables and the required work, you won’t have a clear idea of the resources needed. This information can be documented in a work breakdown structure (WBS) or similar tool. By having this detail, the project manager in linear projects will have a good understanding of the types of resources needed to complete the work.
And I guess if we get the scope wrong, we might end up with the wrong or missing resources.
Yes, that’s correct. For example, if you’re defining the scope for building a new house and forget to include the heating system, you won’t anticipate needing a boiler, a heating engineer, or welding equipment. In linear projects, everything starts with understanding the scope.
Okay, that’s identifying resources. Next, you mentioned scheduling and allocating them to the project. What do we need to consider?
Once you’ve identified the resources needed, when allocating them to the timeline, you must consider the project lifecycle. The way you allocate resources will differ depending on whether the lifecycle is linear or iterative. You also need to consider the demand—how many resources are required. Often, the project manager will estimate this using expert judgement or past experience, considering requirements like health and safety, which may dictate the minimum number of people needed for a task.
This becomes particularly important if there’s competition for resources or shortages.
Exactly. You also need to think about how long tasks will take and whether resources are available when required. If not, you might need to use resource management techniques to optimise allocation. Other considerations include the cost—ensuring that resource allocation stays within budget.
So, we’ve determined the resources by understanding the scope, and we’ve considered various factors. The next learning objective is to understand how resources are categorised and allocated and how this might differ across different lifecycles. How are resources categorised?
The main categories are human resources (personnel or external contractors), materials, equipment (sometimes referred to as plant), and any facilities or spaces needed.
When allocating resources, how does the project lifecycle affect the process? For example, how does resource management differ in a linear lifecycle?
In a linear lifecycle, the focus is on delivering the full scope of work. You start by scheduling activities, identifying the required resources, and understanding when they’re needed. The schedule and scope are the primary drivers, and you aim to maintain the timeline while meeting product requirements.
In iterative projects, however, the requirements and scope are prioritised and delivered within a fixed timeframe, or timebox. You allocate the available resources for that period, even if you don’t have a detailed understanding of all the requirements.
It seems that in a linear lifecycle, you try to define the scope as clearly as possible to understand the resources needed, including their categories, skills, availability, and costs. In an iterative lifecycle, you’re fitting the scope of what you can deliver around the fixed resource allocation.
Yes, that’s correct. And of course, you also need to meet quality standards, which requires careful resource allocation before prioritisation.
Exactly. We’ve covered two learning outcomes so far. Let’s go back to the second one in the syllabus, which we skipped earlier. It’s about understanding how an organisational breakdown structure (OBS) is used to create a responsibility assignment matrix (RAM) or a RACI chart. These are tools that help with resource identification and management. So, what is an organisational breakdown structure?
An organisational breakdown structure (OBS) maps out all the roles involved in the project, organising them hierarchically to show who is responsible and what the escalation routes are for any issues that may arise.
We’ve already talked about the work breakdown structure (WBS), product breakdown structure (PBS), and cost breakdown structure (CBS). The OBS is similar but focuses on resources—specifically, roles within the organisation.
Exactly. The OBS represents different roles, and its real power comes when combined with the tasks in the WBS. This allows you to assign responsibilities for various tasks.
This brings us to the famous RACI chart or responsibility assignment matrix. Can you explain what this is and how it’s useful?
A RACI chart is a common tool for identifying responsibilities and accountabilities. RACI stands for Responsible, Accountable, Consulted, and Informed. It’s a matrix that documents who is responsible for a particular task and who is accountable. While the same person can sometimes be responsible and accountable, they are not necessarily the same thing.
Let’s clarify the difference between someone who is accountable and someone who is responsible.
The person responsible is the one doing the work. For example, if the WBS indicates that house drawings are needed, an architect might be responsible for that task. The person accountable, however, is the one who ensures the work is done correctly, even if they’re not the one doing it. This person may need to approve the work or provide sign-off and is the point of escalation if problems arise.
I always think of the accountable person as the one who has a sign on their desk saying, “The buck stops here.” They’re the one who gets in trouble if something goes wrong.
Exactly. The accountable person is ultimately responsible for the task’s outcome. I’m also a big fan of RACI charts because they help clarify these distinctions, ensuring that everyone understands who has decision-making authority.
What about the ‘C’ and the ‘I’? What’s the difference between someone who’s consulted and someone who’s informed?
Consultation involves two-way communication, where feedback is expected. For example, the architect responsible for the drawings may consult with a structural engineer to ensure everything is correct. In contrast, informing is one-way communication, where someone is kept updated but isn’t expected to provide input. For instance, the architect might inform the builders about the progress, but they don’t need to respond.
It’s important to distinguish between those who need to be consulted and those who only need to be informed. This can help reduce unnecessary meetings and streamline communication.
Yes, it’s one of my favourite tools because it also helps get buy-in from the team. You don’t create a RACI chart on your own—it’s usually done through meetings or workshops to discuss responsibility assignments. This can help prevent confusion and ensure everyone knows their role.
Especially when working across functions or with different organisations, where assumptions about roles and responsibilities might vary, a RACI chart provides clarity on who does what.
Indeed, it’s very effective.
So, we’ve talked about resource management as involving three main activities: identifying, categorising, and allocating resources. We’ve also discussed the OBS and RACI chart. As we manage resources throughout the project, we might need to use two techniques: resource smoothing and resource levelling. These terms sound similar but are quite different. Can you explain what resource smoothing is and when it’s used?
Both are techniques to help fit the scope within time and resource constraints. Resource smoothing aims to maintain a stable resource profile by avoiding peaks and troughs in demand. It focuses on protecting the project’s deadline and improving productivity while keeping the end date fixed. The key limitation in smoothing is maintaining that end date.
Resource smoothing also benefits team motivation and management by keeping resource demand consistent, avoiding the disruption of fluctuating involvement.
What about resource levelling? How does that differ?
Resource levelling is used when resources are limited, and you need to work within those constraints. It adjusts the schedule based on resource availability, often leading to extended task durations or moving non-critical activities, which might result in a delayed end date. It’s more reactive, sometimes a last resort, but aims to use resources as efficiently as possible.
Resource levelling is a pragmatic solution—making the best use of available resources, even if it means extending the project timeline.
Exactly. It’s more about being realistic with the resources you have, rather than trying to stick rigidly to the original schedule.
We’ve done a thorough review of resource management today. We’ve covered what resources are, how to identify, categorise, and allocate them, and how to manage them throughout the project lifecycle. We’ve also discussed some key tools and techniques, and how approaches might differ in linear and iterative lifecycles. Quite a lot of ground covered!
Yes, that was great.
Fantastic. Thank you.
Thank you. Goodbye.
