Hello, and welcome to another Parallel Project Training podcast. These podcasts are recorded for the new APM PMQ syllabus, launching in September 2024. Today, we’re going to be discussing requirements management. My name is Ruth Phillips, and I’m here with Lisa Regan, one of Parallel’s senior trainers. Hi, Lisa.
Hi, Ruth. I’m looking forward to talking about requirements management today.
Great, let’s get started. Looking at the syllabus, there are two learning outcomes for this topic, which split requirements management into two main areas. The learning objective is to understand requirements management as the ability to capture and monitor the requirements of a project. The first learning outcome focuses on understanding how to establish scope through requirements management processes such as gathering, analysing, justifying requirements, and baselining needs. So, let’s start by breaking this down. When do we actually start capturing and gathering requirements, Lisa?
In the business case, you would have high-level requirements, but the detailed work really begins in the definition phase as part of the Project Management Plan (PMP).
And who needs to get involved in this process?
The project manager, for starters. Gathering requirements is all about talking to people, especially your key stakeholders. When we talk about gathering requirements, it involves eliciting information through interviews, one-on-ones with subject matter experts, brainstorming sessions, or focus groups. It’s about gathering as much information as possible and recording it, ensuring you talk to as many stakeholders as possible to avoid missing anything crucial. It’s important to be as comprehensive as you can in the gathering phase.
Absolutely. I’ve found that starting stakeholder engagement alongside gathering requirements can make the process more efficient. The people you gather requirements from are usually key stakeholders who need to be engaged and interested in the project. Additionally, it’s important to allow people time to think and reflect. As project managers, we can get frustrated when stakeholders don’t immediately know what they want, but it can be challenging to clearly define and prioritise requirements in a measurable way. Often, people just want a better version of what they currently have, rather than thinking outside the box. Someone once said people just want a better chariot rather than designing a car.
Yes, sometimes people don’t know exactly what they need—they just want a gold-plated version of what they have.
Exactly. So, after gathering high-level requirements in the concept phase, we move into the analysis of requirements during the definition phase. What does this involve?
Analysing requirements is like a Venn diagram—you’re trying to identify any gaps or overlaps between requirements. For example, does satisfying one requirement automatically satisfy another? Or are there conflicting requirements? The analysis also involves a technical function-cost analysis, which assesses the value of each requirement to the organisation. Once this analysis is done, it’s essential to get stakeholder consensus. This is where conflict resolution often comes into play because different stakeholders may have different priorities.
Absolutely. People often have differing priorities, so reaching a consensus is a key part of the process.
Yes, and in this analysis and justification phase, subject matter experts play a crucial role. As project managers, we’re not expected to know everything, but we need to know who to consult. These experts can help clarify what each requirement means for the project, its cost, time implications, and how it will be delivered. Justifying requirements often involves a MoSCoW analysis—categorising requirements as Must Have, Should Have, Could Have, or Won’t Have.
I love using MoSCoW in projects, particularly those with an iterative lifecycle. It’s an effective way to prioritise requirements. Another useful approach is linking requirements back to the business case, especially through the function-cost analysis, to ensure that the prioritisation enables the delivery of the benefits outlined in the business case.
Yes, there are many linkages in this process. Once you’ve justified the requirements, it’s important to communicate them clearly to prevent misunderstandings later on.
Absolutely. In iterative lifecycle projects, requirements management is particularly strong. Techniques like user stories can make it easier for stakeholders to articulate their requirements. Visualising requirements through models or prototypes can also help stakeholders confirm that what’s being developed meets their needs.
Yes, and finally, the syllabus mentions baselining needs. What happens at this stage?
Baselining is about setting requirements in stone. Once you’ve reached an agreement, you communicate it clearly and include it in the deployment baseline as part of the PMP. In a linear lifecycle, any changes after this point must go through a change control process. While iterative projects are more flexible, even in a timebox, requirements must be managed carefully to avoid scope creep.
We’ve touched on how requirements management ties into other areas like stakeholder engagement, the business case, and change control. Another important aspect is configuration management, which often sounds daunting but is essential. The syllabus now asks us to understand how to manage scope, which includes configuration management.
What exactly is configuration management?
At its core, configuration management is about version control—whether of documents or physical items. It involves managing different versions of items to ensure quality and consistency. As soon as you have more than one version of anything, you’re doing configuration management. The question is how well you’re doing it. Configuration management might seem like a small topic, but it has significant implications for quality and change control.
Yes, and there’s a process to follow, often remembered by the acronym PICSA: Planning, Identification, Control, Status Accounting, and Audit. Can you start with the planning stage?
Planning is about determining who will handle configuration management—whether it’s a specialist, a configuration librarian, someone from the PMO, or even the project manager, depending on the project’s size and complexity. Configuration management isn’t just about documents; it applies to everything produced in a project, from widgets to code to training materials.
The next stage is identifying the configuration items. What does this involve?
Configuration items come from the Product Breakdown Structure (PBS). These could be individual items or groups of items, depending on the project’s complexity. The PBS helps determine the level of granularity needed for configuration management. The identification process also involves managing different versions and ensuring that the correct versions are used.
Then we move on to control, which is where configuration management is put into practice. When a change is made, we need processes in place to handle it properly, ensuring that the right version is updated and checked back in.
Exactly. Systems today make it easier to manage this electronically, but for physical products, similar principles apply. Regardless of the type of product, the process ensures that the correct versions are managed and that everyone is informed of changes.
After control, we have status accounting. What does this involve?
Status accounting is like keeping a log of what’s been done—tracking the configuration item’s ID, who made changes, the date, and the current version. It’s all about traceability, so at any point, you can see the history of an item’s configuration. While it might not sound exciting, it’s crucial for maintaining control and providing information for reports and reviews.
Finally, we have audit. What does this entail?
Audits are independent checks, often conducted by the PMO, to ensure that configuration management processes are being followed correctly. Audits can happen at any time, but they’re often done at the end of a project phase to ensure everything is in order before moving forward. It’s a good housekeeping practice to ensure that what’s recorded matches the reality of what’s been delivered.
So, our key message is to stay on top of configuration management as a way to control and manage scope effectively.
Absolutely. Thanks, Ruth. I think we’ve covered everything we need to for requirements management. We discussed how to establish scope through requirements management by gathering, analysing, justifying requirements, and baselining needs. Then we covered how to manage scope using the configuration management process, following the PICSA steps: Planning, Identification, Control, Status Accounting, and Audit.
It’s been a really interesting session. Thank you very much, Lisa.
Thanks, Ruth. No problem. Thank you.
