Do You Know How to Plan and Manage Reliable Project Compliance?

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.

Project Compliance and The PMP Examination

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:

• Confirm project compliance requirements (eg: security, health & safety, regulatory)
• Classify compliance categories
• Determine potential threats to compliance
• Use methods to support compliance
• Analyze the consequences of non-compliance
• Determine necessary approach and action to address compliance needs (eg: risk, legal)
• Measure the extent to which the project is in compliance

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:

The PMBOK Guide, 6^th Edition

PMBOK 6 has almost nothing to say about project compliance. The two mentions (both very short) refer to:

1. The Project Management Office (PMO) role in process compliance (on page 48)
2. Tailoring your quality processes for compliance and audit (on page 276)

The PMBOK Guide, 7^th Edition

PMBOK 7 has a little more to say, if we know what we are looking for:

1. In the section on Project Management Principles, we can infer elements of project compliance in: 
   • #8 Build quality into processes and deliverables (on page 47)
   • #10 Optimize risk responses (on page 53)
2. Among the 8 Project Performance Domains, we find:
   • Quality (on page 80)
   • Measurement (on page 93)
   • Uncertainty (on page 116)
3. And, as you’d expect, among the Models, Methods, and Artifacts:
   • Data gathering (on page 174)
   • Information (on page 188)
   • Reports (on page 190)

The Association for Project Management Body of Knowledge

Although it’s not a recommended text for the PMP exam, the 7^th edition of the APMBoK is an excellent reference for serious project managers. It has two specific sections that deal with aspects of project compliance:

1. Audit and Assurance – Section 2.2.4
2. Regulatory Environment – Section 3.3.4

PRINCE2

Arguably, PRINCE2 is all about compliance and good governance. But the word is not in the index of the current, 2017, edition of Managing Successful Projects with PRINCE2.

Our Agenda

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:

1. Project Compliance: What are we talking about? 
2. Why is Project Compliance Important?
3. Summary of the Project Compliance Process
4. Setting the Environment for Project Compliance
5. Approaches to Ensure Project Compliance: Models, Methods, and Artifacts
6. Monitoring, Measuring, and Controlling Project Compliance

Project Compliance: What are we talking about? 

To start with, I think we need to consider four things when we are looking at project compliance:

1. Compliance of what? 
   That is, what things need to comply? And therefore…
2. Compliance with what?
   What do those things need to comply with? Then…
3. Levels of Compliance 
   What do we mean by compliance and non-compliance. And finally…
4. Threats to Compliance
   What can cause non-compliance?

Compliance of What? 

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:

• Quality
• Behavior: ethical and socially responsible
• Security
• Health and Safety
• Privacy, confidentiality, and data protection
• Service availability, capacity, continuity, and resilience
• Product robustness and durability
• Availability and timeliness
• Environmental impact: emissions, pollution, and the disposal or decommissioning processes
• Functionality
• Process, procedures, and performance

Compliance with What? 

But what do all of these need to comply with? Once again, this list can never be exhaustive. But, the principal examples are:

• Legal and regulatory frameworks
  Local, National, International
• Standards frameworks 
  Such as: ISO, ANSI, and BSI
• Industry rules and regulations
• Internal policies, practices, procedures, and guidelines

Levels of Compliance 

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:

• Top price, premium products, or
• Lower price, budget products

Threats to Compliance 

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:

• Human error
  This can include insufficient:
  • Awareness
  • Training
  • Care and diligence
• Technical faults
  These can include:
  • Poor calibration
  • Faulty components
  • Software errors or ‘bugs’
  • Wear on components
  • Substandard components or materials
• Changes to standards, policies, regulations, legislation, etc
• Need for haste or to save on resource costs
• Poor compliance procedures
  These will include failings in:
  • Specification and design
  • Decision-making
  • Quality assurance
  • Testing and assessment
  • Oversight
  • Document management – configuration management and version control

Why is Project Compliance Important?

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.

Examples are:

• Reputational damage 
  Not just from failures in quality or regulatory compliance, but alse with ethical or social responsibility failures, for example
• Financial cost
  This arises from the costs of putting things right and meeting fines or legal 
• Prosecution
  Legal sanctions can range from small fine penalties all the way to corporate homicide/manslaughter charges
• Removal of products or services from use or from sale
• Serious harm or loss of life
  This can arise from health and safety or security breaches – including breaches of data security
• Environmental damage
  This can also have all of the consequences above

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.

Summary of the Project Compliance Process

A great process to summarize how we manage project compliance is the Shewhart or Deming cycle of Plan-Do-Check-Act.

• Plan
  Define what you need to achieve, figure out how you will do it, and set up an environment where project compliance can thrive
• Do
  Build and operate the processes that will ensure project compliance
• Check
  Monitor and measure compliance – both as an internal part of your project and with the help of external verification and audit.
• Act
  Act on your findings to control compliance and adapt your processes to improve compliance.

Next, in the following three sections, I will wrap the Check and Act steps into one section.

Setting the Environment for Project Compliance

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.

Quality Management Plan 

Your Quality Management Plan will cover:

1. Expectations of your Stakeholders
2. Criteria against which quality can be assessed
3. The Quality Standards you will work to
4. Quality Assurance procedures
5. Quality Control procedures
6. Change Control process
7. Assigning roles and responsibilities 
   Roles determine individuals’ rights and access.

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:

• Team member to Team Leader
• Team Leader to Project Manager
• Project Manager to Project Sponsor or Client
• Project Sponsor to project or operational Board

These will, of course, include the time, resource, and cost implications of resolving potential non-compliance.

Quality Design (QD)

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.

Project Compliance as a set of Activities and Deliverables

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.

Approaches to Ensure Project Compliance: Models, Methods, and Artifacts

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:

• Risk Management
• Quality Management 

…to which we need to add Configuration Management.

Risk 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.

Quality Management

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:

1. Quality Assurance
   Making sure you deliver to the quality standards you have set
2. Quality Control
   Testing and validation of the deliverables you create, against the functional (and non-functional) requirements and your quality standards

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

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.

Monitoring, Measuring, and Controlling Project Compliance

We will consider four things in this section:

1. Internal Project Compliance Validation
2. External Project Compliance Validation
3. Controlling your Compliance Process – acting on findings
4. Final Sign-off and Approval Process

Internal to the Project

There are four basic processes here:

1. Sampling and testing 
   This is about data-gathering. But you need to bear in mind that it may not be feasible or cost-effective to test and validate every product or process. So, you may want to work with a sample. This can also reduce the cost of quality and so maximize the value your project is able to deliver (Value = Benefit – Cost).
2. Analysis of conformity and variance 
   From your sample and testing, how well do your processes and products comply with the project’s standards and requirements? 
3. Reporting 
   You will, of course, create regular project reports. These need to include your assessment of project compliance and risks to future compliance. You will also discuss any external audit and assurance activities along with the recommendations that flow from them.
4. Escalation of non-compliance issues 
   Finally, if there are issues around non-compliance, you need to deal with them. And, if you are unable to bring them under control – or if you need decisions, resources, or permissions to do so – you will need to escalate the issues. You should have set-up your escalation procedures and delegation authorities (PMI calls them ‘tolerance limits’) when you set the environment for project compliance.

External Audit and Assurance

Audits are carried out by teams external to your project. This could be by, for example:

• The organization’s internal audit function
• An internal project assurance team
• Your Program or Portfolio Management office (PMO)
• An external auditor – consultants trained in assessing compliance to industry standards
• Regulators 

They could be verifying one or more of your:

• Compliance with processes and procedures
• Delivery of products/deliverables to standards
• Conformity with policy, regulation, or legislation
• Use of good practices

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.

Controlling Compliance – The ‘Act’ Step in the PDCA Process

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?

Final Sign-off and Approval Process

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…

Congratulations.

What next?

What is Your Experience of Project Compliance?

I’d love to hear your thoughts about and experience of project compliance. I will respond to any comments you make below.