Leverage the benefits of effective requirements management with these three easy steps
Project requirements are constantly changing, and managing those changes is one of the most challenging tasks in capital project management. We’ve written before about change control processes, but we’ve never pulled together some basic change control guidelines specifically for managing project requirements and helping capital project managers who are practicing Advanced Work Packaging (AWP). It’s long overdue.
Our industry could benefit from a standard widely used in the Information Technology industry: the Capability Maturity Model Integration (CMMI) standard. CMMI was developed at Carnegie Mellon University as a training and appraisal program that is used to guide companies in improving their processes. The Concord® Team built T-CON™ with the CMMI process areas in mind, tailored to the needs of capital project managers who employ Advanced Work Packaging methodologies. Project managers like you.
In this article, we’ve distilled some of the most important CMMI concepts into three steps that any project manager can take to make AWP even more practical and efficient. Apply them, and you’ll become a superhero to your team.
1 | Formally define your change-request process.
When your change request process is out of whack, the entire project is at risk of cost overruns and major delays. How do you know if your change request process is weak? Well, if your scope statements have different technical requirements, that’s a big red flag. Other signs include inter-departmental confusion about basic project requirements and team members wasting time trying to track down specifications for their work. The solution is a formal change request process.
First, you need a single source of truth (SSOT) — a place where you keep the most up-to-date answer to key questions about requirements (and everything else). Second, you need a formal change control process in place, which defines how changes are requested and who must approve them. Third, you’ll need a system for propagating the change across stakeholders, from client to contractor. Finally, make sure you’re tracking changes throughout the entire lifecycle of the requirement, so you can look back and see who made which decisions, when, and why.
Pro tip: Many companies only track changes for technical requirements, and that’s a mistake. Smart companies also track and manage changes to project execution requirements. For example, what requirements need to be met in order for a work package to be considered “complete?” More on this in a minute.
2 | Measure the impacts of change.
You need a system to measure the impacts of change. The foundation of this system is creating consensus around the definition of done.
Here’s how it works. Before you break ground on a new project, establish a checklist that answers this simple question: “How will we know when we are done?” Simply identify the requirements that must be met — from both a technical and from a project execution perspective — in order for the work package to be considered complete. Get all of your key stakeholders to sign off on this list and voila, you have consensus around the definition of done.
How does this help you measure the impacts of change? When you’ve achieved alignment around what “done” means, you’ve created a definitive list of requirements for your project. A well-oiled change control process will allow you to consider proposed changes in light of these requirements, providing clear insight into the impact your changes will have on timelines, costs and other variables that matter to you.
The result? A simple, effective way to understand how changes are impacting your timeline — and your bottom line.
3 | Establish fully traceable decision-making.
Fully traceable decision-making means tracking five key variables:
Who made the decision
When they made the decision
Why they made the decision that they did
The impact of the decision
Who needs to take action
The goal of traceable decision making is to be able to explain why decisions are made and how they affected the project as a whole — with precision, and in real-time. This is an integral part of your overall change request process, and while it looks a lot like the risk register, this “decision register” is a different beast entirely.
Whereas your risk register captures and assigns responsibility for project-related risks, a decision register is a concept taken from CMMI in which you capture responsibility for decisions that are made concerning project requirements — both technical and execution-related. Tracking changes across both of these domains gives unrivaled visibility into the project, so everyone from owners to sub-contractors fully understands what is changing and why. This allows teams to be proactive, nimble and more effective in their work, especially if they can gather this information with ease from an SSOT.
In addition, your decision register will provide a powerful tool for learning down the road — about what works, and what doesn’t.
We’d love to hear your thoughts on the ways that you work to effectively manage requirements while you practice Advanced Work Packaging. Let us know what you think, contact us today.
Learn about how the Concord® Team and platform can support your project’s AWP delivery and POC here.
