3.1.1 Confirm Project Compliance Requirements
Confirm project compliance requirements (e.g., security, health and safety, regulatory compliance.)
Most organizations have some non-negotiable aspects to their projects. These are characteristics, that if not there, or if not up to standard, would mean the project would have to stop or the product or service being worked on would fail critical checks.
As project managers, we need to understand and confirm exactly what is required for our project. There is no point building the world’s best mouse trap if we are not allowed to sell it, or selling it would create problems for our organization.
Compliance as Requirements or a Framework?
One way to think about compliance constraints is as must-have requirements. They are conditions that must be met for the project to be accepted. Most compliance constraints have severe financial or legal ramifications if they are not met. This “constraints and requirements” view has some advantages and disadvantages.
On the plus side projects have familiar tools to manage requirements. We can convert them into WBS work packages and product backlogs and track them in tests and traceability matrices. On the downside, the complexity of regulations means a constraint may be fragmented across its technical, legal and control aspects. This makes adherence difficult to tie back to a single WBS or product backlog item. Plus, some constraints may not be proven satisfied until beyond the duration of the project, which could create challenges in accepting the project.
Another way to consider handling constraints is with a framework. A framework provides a set of guidelines to follow but does not provide a single solution for every project. Also, the framework can be adapted according to the needs of the project team.
The compliance framework model above shows an outer loop of compliance objectives providing input to WBS or Backlog entries that support the compliance objectives. Within the model, we see tools and techniques such as compliance-related documentation, council, risks, audits and responsibilities that help monitor and manage compliance work.
However, you think about compliance activities; they need to be performed. They are the price of admission for obtaining acceptance for our projects and staying in business as an organization.
3.1.2 Classify Compliance Categories
Compliance constraints can come in many forms. For engineering projects producing or changing physical assets, compliance could be around safety, legal or regulatory constraints. For knowledge work projects creating or updating intangible assets, they could be around security, privacy laws and storing personal information.
Some examples of compliance categories are shown in the mind map below:
Compliance categories will vary depending upon the project type and business we are engaged in. Also, since compliance is often linked to laws that vary by region and country, where our product or service may be offered will impact our compliance rules. For instance, laws around storing customer information vary by country. If we provide digital products globally, we need to be aware of regional variations or risk exclusion and penalties.
Depending on your project, keeping up with all the project compliance categories can be a daunting task. This is why some compliance frameworks feature a compliance council, compliance documentation and compliance audits to help keep items under control.
3.1.3 Determine Potential Threats to Compliance
There are many sources of compliance threats. We could build an underperforming product or service, we could miss a new or updated law or regulatory requirement. Some common threat categories are shown below.
Product defects refer to errors or bugs in deliverables – For instance, the car burst into flames while charging.
Errors in our testing and validation used to confirm compliance – we tested 10,000 charging cycles, but only using our own charging infrastructure.
Changes to regulatory or legal requirements – new legislation makes autonomous vehicle functions illegal to use in school zones.
Awareness gaps – such as not knowing our product emits radio waves that interfere with pacemakers.
New markets – threats associated with new, unknown regulations or laws.
Since these are threats, a form of risk, we can use risk registers and other risk management tools and techniques to identify, track and manage them. As with any risk, we likely want to track information such as
- The identified risk
- Impact of a realized risk
- Risk owner
- Risk responses – including avoidance, mitigation, transfer/sharing, and acceptance.
3.1.4 Use Methods to Support Compliance
While being aware of compliance threats is a necessary first step, the real benefits only come from taking action. We must ensure compliance activities are followed, and the threats acted upon. The tools we have at our disposal to help with this include:
Execution Reports aka Work Performance Reports
Project managers regularly create reports about:
- Overall progress
- Project activities
- Deliverable status
- Risk reports
Tracking Tools and Information Radiators
- Release roadmaps
- Story maps
- Kanban boards
- Cumulative flow diagrams
- Risk burndown charts
In addition to reporting, project managers are responsible for ensuring actions are taken to manage the risks. This includes:
Testing and validation activities
The ongoing running tests to verify project components meet specification and compliance requirements. Testing and validations are often conducted
Audits and inspections
Audits are structured, independent reviews to determine if project activities comply with project and organizational procedures, policies and processes. Often audits and inspections are performed by specialists from outside of the project team, such as an internal audit team or PMO. They are designed to identify that good practices are being used and find any nonconformity, gaps, and shortcomings.
When possible, audit teams should proactively offer improvements to improve quality and productivity. They should also share good practices from other projects and highlight contributions to lessons learned and retrospectives.
Control Limits and Tolerances
Control limits are upper and lower bounds that can be established around a project characteristic. Tolerance is the region with these bounds that the project manager is empowered to manage between. Typically, if a tolerance range is breached (or forecast to be breached), the project manager would escalate the issue.
Common control limits and tolerance ranges can be set around any measurable element. Common measures include:
- Budget
- Time
- Quality
- Non-functional requirements
Non-functional requirements describe attributes such as reliability, security, capacity and documentation needs. See this link for an example of non-functional requirements in a software project.
Sign-offs and Approvals
Gaining approval that the solution and its deliverables meet requirements is another way to help ensure compliance. We must identify the necessary stakeholders who are authorized to sign-off and then assist by facilitating the process. Sign-off and approval can happen throughout the project as deliverables are produced, or at completion. Agile projects aim for the delivery of completed and accepted deliverables throughout the life cycle. Some environments and products better suit or require a final acceptance.
Frequent review and approvals allow us to gather early warnings of potential issues. They also allow us to take early corrective action reducing scrap and rework. This helps reduce cost overruns, delays and increased risks.
3.1.5 Analyze the Consequences of Noncompliance
For project managers to effectively identify and manage legal or regulatory compliance requirements, we need the following items in place:
List
A comprehensive list of the legal, regulatory, and other constraints that apply to the project.
Definitions
Definitions of which parts of the solution are subject to compliance requirements. This includes the scope of the compliance requirement and the stakeholders responsible for managing, approving, and signing-off on the component’s compliance.
Business Rules
A set of business rules that constrain the project solution and improve the likelihood of compliance. For example: “To meet the site safety requirements, we will require all employees, contractors and site visitors to wear personal protection equipment at all times and attend training before being allowed on site.”
Methods.
Methods to track and manage the review and approval activities related to each compliance item.
Processes
Processes to track and manage the risks and risk responses related to compliance requirements.
Since compliance is a particular form of requirement, we rely on quality management to ensure it is being planned for, tested and tracked. This also includes taking corrective action to fix any problems found and changing our processes to improve quality in the future.
On traditional, plan-driven approaches, the quality management plan describes the activities needed to achieve the necessary quality objectives. It describes the expectations for the project’s quality requirements. These will include:
- Quality objectives of the project
- Quality standards to be used
- Quality roles and responsibilities
- Project deliverables and processes subject to quality review
- Quality management activities planned for the project
- Which quality tools will be used
For agile life cycle projects, much of the quality management plan information is contained in the Definition of Ready, Definition of Done, user story acceptance criteria, non-functional requirements and dedicated compliance activity stories.
Organizations that operate in highly regulated environments but wish to gain the agile benefits of short iterations with quick feedback loops and reprioritization may choose a hybrid approach. It is possible to encapsulate an agile development process in a more rigorous and documentation focussed wrapper of compliance activities.
An example of this is how one of Lockheed Martin’s drone software suppliers operates. Just to do business with Lockheed Martin, suppliers must demonstrate thorough security processes and detailed traceability from requirements to documented tests. The supplier wraps an agile core with more traditional process to create a hybrid that supports rapid exploration of new ideas but still satisfies strict compliance requirements.
Regardless of which way quality assurance is embraced with the project life cycle, we need to ensure the appropriate actions are taken based on the outputs of QA activities. These include:
Review – Deliverables are reviewed to verify they meet both functional and non-functional requirements.
Validate – QA validates whether the deliverables align with compliance requirements and provides details on any variances identified.
Recommend – Where necessary identify and suggest potential improvements to fix any defects or other noncompliance.
Escalate – When noncompliance issues are identified, the project manager should determine if it is within the tolerance level and can be handled within the project or if it needs to be escalated.
Other QA processes project managers need to be aware of include:
Sampling
When it not viable or cost-prohibitive to inspect every product or deliverable, substituting a sampling of the outputs for review might be appropriate. The goal is to provide similar results in identifying quality issues while reducing the cost of quality.
QA Tools
- Data gathering – Using checklists and other sources of acceptance criteria.
- Data analysis – Techniques such as process analysis, alternatives analysis, document analysis, and root cause analysis.
- Decision making techniques – A group of techniques used to help people reach decisions.
- Data presentation techniques – Creating and interpreting charts such as histograms, scatter charts, cause and effect diagrams, flowcharts, affinity diagrams, etc.
- Audit reports – documentation from reviews used to determine if activities comply with policies, processes, and procedures.
- Design for X – A set of guidelines to optimize for a specific aspect of the design. The X can be reliability, cost, service, usability, safety, quality, or any other variable of interest.
- Problem-solving techniques – Tools and steps used in solving problems. Often including: Defining the problem, Identifying the root-cause, Generating possible solutions, Choosing the best solution, Implementing the solution, and Verifying solution effectiveness.
- Quality management methods: Six Sigma, Plan-Do-Check-Act
Quality Improvement Methods
Quality movements
- Plan-Do-Check-Act (Shewhart and Deming)
- Total Quality Management (TQM)
- Kaizen
Agile and Lean Quality Assurance
Agile approaches borrow many ideas from Lean thinking, such as the emphasis on quality and continuous improvement. Both agile and lean approaches aim to make waste visible so it can be reduced or eliminated through activities such as value stream mapping. They also promote frequent reviews to inspect the product or service being created. The plan, build, demo, retrospective activities of an agile iteration closely mirror Demming’s Plan, Do, Check, Act (PDCA) quality cycle.
3.1.6 Determine Approach and Action to Address Compliance Needs
Determine necessary approach and action to address compliance needs (e.g., risk, legal)
After ensuring we understand all the compliance requirements and using QA approaches to test them, we need to ensure any issues are addressed. This is essentially the application of the processes already discussed:
Create a Quality Management Plan – Create a suitable Quality Management Plan and educate the team and relevant stakeholders about how it will be executed on an ongoing basis. This will help identify any noncompliance issues as early as possible.
Establish Tolerances – Establish the project tolerances and enable the project manager to either take corrective actions with the team or quickly escalate any noncompliance outside of the tolerances.
Apply QA Processes – Confirm the outputs and deliverables. Establish how and where external audit teams will validate the use of appropriate processes and procedures. Also, how audit results will enable the team to identify improvements.
Exercise the process – Leverage all the QA tools and techniques to assess quality deliverables and identify improvements, corrective actions, or defect repairs required.
A general theme is to be proactive and catch issues early. This reduces the impact of the problem on downstream activities and minimizes the amount of scrap and remediation. The quicker we catch a problem, typically the less if costs to address it.
Issue remediation costs follow a pattern similar to the cost-of-change curve. The longer things go un-noticed or un-corrected, the more costly they are to fix.
Monitoring compliance is not a once-and-done process. It needs to be an ongoing activity to ensure outputs and deliverables continue to be in compliance. It also needs repeating to keep up with any regulation updates and when we enter new markets.
3.1.7 Measure the Extent to which the Project is in Compliance
The final task we cover in this module is measuring the extent to which the project is in compliance. It deals with executing the quality management plan, using tolerances, QA tools and audits to see if we are in compliance. Then, if we are not in compliance, taking action to bring the project back or escalate the issue. This process is repeated throughout the project, so it is depicted as a continuous cycle below.
Execute Quality Management Plan – Create a clear Quality Management Plan and execute it on an ongoing basis to find any noncompliance issues as early as possible.
Use Tolerances – Establish project tolerances and enable the project manager to either initiate corrective actions or to quickly escalate any noncompliance.
Apply Quality Assurance Tools – Make use of effective QA tools and techniques to assess deliverables and identify improvements, corrective actions, or defect repairs required.
Use Audits – Determine where external audit teams can confirm or validate the use of appropriate processes and procedures. Also, how audit results can enable the team to identify improvements.
Confirm Compliance or Take Action – Use QA outputs to confirm deliverables and process compliance or identify the need for corrective actions. Then determine the issues are within tolerances for the team to remedy or if escalation outside of the project team is needed.
Deliverables and Tools
- Risk Register
- Risk Response Plan
- Quality Management Plan
- QA Outputs
- Signoffs / Approvals
- Non-functional Requirements
- Work Performance/Execution Reports
- Configuration Management System
- Variance Analysis
- Tolerances
- Escalation Procedures
- Audits
- Sampling
- QA Tools
Related Topics
- 1.3 Support team performance
- 1.7 Address and remove impediments/obstacles for the team
- 1.10 Build a shared understanding
- 2.3 Assess and manage risks
- 2.7 Plan and manage quality of products/deliverables
- 2.8 Plan and manage scope
- 2.9 Integrate project planning activities
- 2.10 Manage project changes
- 2.12 Manage project artifacts
- 2.14 Establish project governance structure
- 2.15 Manage project issues
- 3.2 Evaluate and deliver project benefits and value
- 3.3 Evaluate and address external business environment changes for impact on scope
Further Reading
Congratulations! You score 100% and won the 3.1 Project Compliance badge.