There are a host of reasons why your project may be subject to constraints with which you must comply. So, understanding project compliance is not a negotiable skill-set. However, we are often left to figure it out for ourselves; learning as we navigate various compliance requirements we are subject to.
We need to identify and manage these compliance criteria, and evaluate our performance against them. This article takes you through everything you need to know.
In 2019, the PMI (Project Management Institute) introduced a new syllabus for its premier certification examination, the Project Management Professional (PMP). This was contained in the 2019 edition of the Examination Content Outline (ECO).
The ECO is divided into three Domains, each split into a number of Tasks. Domain II Task 1 is ‘Plan and Manage Project Compliance’. It consists of 7 Enablers:
In my view, this is not a bad syllabus. However, the challenge is that the primary references that PMI recommends to prepare for the PMP exam, have little to say on the topic:
PMBOK 6 has almost nothing to say about project compliance. The two mentions (both very short) refer to:
PMBOK 7 has a little more to say, if we know what we are looking for:
Although it’s not a recommended text for the PMP exam, the 7th edition of the APMBoK is an excellent reference for serious project managers. It has two specific sections that deal with aspects of project compliance:
So, we are largely on our own, as far as core reference books go. I have divided my comprehensive review of Project Compliance into six sections:
To start with, I think we need to consider four things when we are looking at project compliance:
First, I’ll start by listing the main things that may need to comply with some standard or another. Of course, this can never be an exhaustive list:
But what do all of these need to comply with? Once again, this list can never be exhaustive. But, the principal examples are:
Next, we need to understand what we mean by ‘compliance’ and ‘non-compliance’. Often the situation is a binary one. However, it is possible that there are levels of compliance. An example comes from the computer chip industry. While some chips will fail their testing, others may perform at levels that suit them for either:
Finally, for this section, what can cause us concern that aspects of our project may become non-compliant? Clearly, the commonest sources of compliance risk are:
This is one of those ‘you have to address it’ questions. But, you shouldn’t need me to tell you the answer. Because compliance requirements come with consequences if we fail to meet them.
Therefore, these represent project risk. In this sense, Project Compliance is, fundamentally, a suite of risk response strategies. Project compliance and risk management are complementary disciplines.
A great process to summarize how we manage project compliance is the Shewhart or Deming cycle of Plan-Do-Check-Act.
Next, in the following three sections, I will wrap the Check and Act steps into one section.
In the planning stage of the PDCA process, you will define what you need to achieve, figure out how you will do it, and set up an environment where project compliance can thrive. Clearly, this will often begin with creating a Quality Management Plan.
Your Quality Management Plan will cover:
Do take a look at our comprehensive article: Project Quality Management: All You Need to Know
An important part of your Quality Management Plan will be setting tolerances against which you will escalate compliance issues, for example, from:
These will, of course, include the time, resource, and cost implications of resolving potential non-compliance.
We cover QD in our full article, Project Quality Management: All You Need to Know. But this is a core part of the planning stage: setting the quality parameters within the design process. Put another way, quality design is designing-in the quality standards you need to meet.
If you are going to have a compliance-first attitude to your project, you need to build compliance activities into your fundamental planning process. And that, of course, means building project compliance into your Work Breakdown Structure (WBS). And you will do so both at each relevant product or activity (depending on the type of WBS you are using), and probably also in its own workstream.
At the ‘Do’ step in the PDCA cycle, you need to build and operate the processes that will ensure project compliance. PMBOK 7 gave us the terminology of Models, Methods, and Artifacts. But earlier editions already contained the core Knowledge Areas of:
…to which we need to add Configuration Management.
We have a tremendous amount of content on this site, about Project Risk Management. Our primary resource is our Ultimate Guide to Project Risk Management.
From the outset, get into the habit of adding all of your compliance-related risks to your project risk register. From there, you can start to develop appropriate Risk Response Strategies – our award-winning article offers a full roundup of your options.
We also have a full article on Quality Management: Project Quality Management: All You Need to Know. The two essential processes at this stage are:
I summarize the meaning of these terms (and Quality design) in this 60-second video:
However, note that PMI conflates both QA and QC into its loose use of the term ‘Quality Assurance’.
The principal tools for both quality assurance and quality control are data gathering and analysis. But there are a wealth of specific tools available from the operational process environment. Not least among these is the toolset that Six Sigma offers.
As the project proceeds, you will generate an array of test scripts, test reports, quality assurance and control documentation, and audit and assurance reports. As part of your compliance process set, you will need to have procedures for referencing and storing these. Which, of course, brings us to…
Configuration management tracks and records the components of your project deliverables. It is:
‘Defining, controlling, releasing, changing, documenting, and reporting the configuration items in a system.’‘Be on the Inside. Decode the Jargon of Project Management’ by Mike Clayton (OnlinePMCourses)
We have a 6-minute video that gives a thorough answer to the question, What is Configuration Management?
Clearly, your configurations need to include compliance information, supported by your testing and validation results. You will hand all of this information over to the end-user, client, or customer, at the end of the project.
Alongside this, you will need to establish Document Management and Version Control procedures for all of your project documentation. You need to be able to track every version and control access appropriately. This will ensure you have a thorough and secure audit trail that will demonstrate you took project compliance seriously, and acted diligently.
We will consider four things in this section:
There are four basic processes here:
Audits are carried out by teams external to your project. This could be by, for example:
They could be verifying one or more of your:
Often, project teams will view these external auditors with suspicion or distrust. But the reality is that they see their job as to improve your performance and avoid errors of non-compliance. Your best approach is to see them as a critical friend. That is, as someone who wants to help you, and is prepared to tell you some uncomfortable truths to do so.
Treat this as an opportunity to both learn and also demonstrate your ability to take feedback and act on it swiftly and effectively.
This is where you apply constant adaptation and learn from your experiences. What do internal and external validations teach you? And how can you improve your project process to offer still greater levels of project compliance?
The last step (at least, conceptually) in project compliance is sign-off by the person or body that has the authority to do so. This will acknowledge your completion of one or more deliverables. But, more relevant to this article, it will also recognize that, in completing them, your project has complied with all of the requirements it has needed to.
This process may be a one-off, at the end of the project. But, more likely, it will happen incrementally, throughout your project.
The sign-off documentation is part of your set of primary project documents. Storing and securing them is a vital part of your project compliance too. But, once you have done that…
I’d love to hear your thoughts about and experience of project compliance. I will respond to any comments you make below.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.