My project should be compliant（合

what do I do now?

Abstract

One of the greatest challenges in projects is the need to comply with certain rules and regulations, both internal and external to the organization executing them. Traditionally, compliance is documented as requirements (typically non-functional) during the project planning phase; however, there are organizational elements that make this compliance even more complex. This paper identifies the concept of compliance as superior to the compliance project goals, and aligns the concepts proposed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition, from a framework perspective. It also proposes tools to improving the results of compliance in projects.

Background

Historically, the implementation of projects has been framed in a series of best practices that recently have been codified under the auspices of the Project Management Institute (PMI). Such practices are now reflected in the PMBOK® Guide, whose fourth edition was published in 2008.

The PMBOK® Guide proposes a range of tools and processes to managing projects under a series of standardized concepts. Erroneously, the PMBOK® Guide has been considered a methodology, and many project managers use it as a guide for the step-by-step implementation of the tasks of a project.

On the other hand, many industries and governments have been standardizing and requiring operations, processes, governance, and other elements of the management of a business to be governed by a series of standards. These standards ensure the public that the products or services provided by the organizations meet the minimum standards of quality, stability, security, and reliability, as expected under certain criteria.

However, there is a large gap in the way such requirements and standards are reflected in the process of implementing a project. In general, typical project management practices consider these standards in one of two ways: Inputs in the meaning the PMBOK® Guide called “environmental organizational aspects,” affecting many of the 42 processes defined in the text, or as requirements documented in the scope of the project. However, these options do not cover a critical aspect of compliance: rules and regulations are living entities of multiple dimensions not always covered by the scope of the project.

Here is a practical example: Bank A is covered by a set of government regulatory rules. These standards require compliance with certain activities to be implemented at different levels of the organization. The bank decides to make changes to its transactional platform and, of course, considered the inclusion of requirements in the scope of the project, for example, to make sure that the audit is present in the “user acceptance testing.” Traditional project management methodology assumes the project members know the regulatory standards and, therefore, the technical requirements and design specifications, and the development itself reflects those standards. In the testing phase, the audit becomes involved and discovers that some of the components do not conform to those standards. This leads to rework of components of the project, with its consequent over budget and delays. In other words, the original assumption of full knowledge of the implications of the rules was false.

Based on almost 20 years of experience in the administration of projects in diverse industries (and pressured by the constant need for increased compliance with laws and regulations), the author of this document recognized the need to add an additional layer to the traditional practices of project management to achieve greater visibility of compliance aspects. After consulting with various sources, analyzing several methodological proposals in various industries, and managing projects under various methodologies, the use of the concept of “compliance” emerged as the best choice to achieving positive results.

The adaptation to various methodologies and more than 15 projects executed under this framework has proven its efficiency, as well as the ability to ensure compliance under various rules and regulations.

Requirements versus Compliance

A requirement is defined as “a condition or capability that must be met or possessed by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed document. Requirements include the quantified and documented needs, wants, and expectations of the sponsor, customer, and other stakeholders.” (Project Management Institute, 2008, p. 445)

The PMBOK® Guide acknowledged for the first time in the fourth edition, the existence of the requirements as a key component of the scope and determined the existence of a process (5.1) called “collect requirements.” This process is described as “…the process of defining and documenting stakeholders’ needs to meet the project objectives (…) These requirements need to be elicited, analyzed, and recorded in enough detail to be measured once project execution begins” (Project Management Institute, 2008, p.105).

Typically, a requirement associated with a standard can be as generic as desired. For example: development must comply with the regulatory framework established by X authority. Alternatively, it can be more specific to the scope of the project. For example: it must comply with the policies established by the bank security area in Y document, numbers 1 through 15. In addition, organizations are forced, for many reasons, to comply with rules and regulations that restrict their ability to operate, except under compliance with these standards. The non-compliance carries penalties or sanctions that, indeed, may threaten the very existence of the organization. Examples of such regulations are the standard Payment Card Industry for credit card processing or the Sarbanes-Oxley Act (known as SOX), covering multiple regulatory aspects for publicly trading businesses. In addition, there are standards such as ISO, allowing companies to differentiate themselves in the market, becoming an integral part of their offerings to customers. It is unthinkable that projects implemented by these companies do not comply with these standards.

Compliance is defined as “1 a: the act or process of complying to a desire, demand, proposal, or regimen or to coercion, b: conformity in fulfilling official requirements” (Merriam-Webster Online, retrieved May 2010), and it is a term that can be used to describe the need for projects to match certain rules, regulations, or standards, in correspondence with certain requirements of stakeholders in the project. This term, however, encompasses more than just simple requirements for the project, because it sets the imperative need to meet other organizational requirements from the most diverse stakeholders. Compliance, in short, bridges the gap between a requirement of the project and the need for the company to find a match between the project and organizational needs.

How Do I Manage Compliance in a Project?

Two practical avenues to complying with rules, regulations, or standards in projects are proposed:

Consider compliance as a requirement: this approach allows the project team to document early any element of the regulation that points to the addition of elements on the work breakdown structure (WBS). The advantage of this approach is that standard elements are incorporated into the scope of the project and therefore can be traced efficiently until completion.

However, this approach has two major disadvantages. On one hand, the requirements probably will be fragmented because of the complexity of the regulation. Typically, there are multiple dimensions (technical, legal, organizational, control) that most likely cannot be managed in a single branch of the WBS. On the other hand, there are requirements that very likely are not parts of the project. For example, the development of quality improvements is a specialized domain of business units operating under different criteria. The second disadvantage is that compliance activities may have a longer duration than the duration of the project, creating an environment in which tasks may not be completed as part of the project itself, leaving the stakeholder with the impression that the project has failed.

Consider compliance as the process assets of the organization: the concept proposed by the PMBOK® Guide for organizational process assets to be considered an input for a large majority of the 42 processes is well known to project managers. The formal definition of this entity is “Any or all processes related assets, from any or all of the organizations involved in the project that are or can be used to influence the project success” (Project Management Institute, 2008, p. 439). Clearly, this definition covers the rules, regulations, or standards affecting the products or services offered by the organization.

Under this assumption, the project team can decide not to document these rules as a requirement but as one of the inputs to the relevant processes. This approach has the advantage in that it considers the regulations in a more holistic way, not necessarily tied to the scope of the project. The obvious disadvantage is that the team needs a greater concentration of resources to ensure that all assets are being considered and how they affect each of the activities of the WBS.

This comparison shows that there is not a one-to-one correlation between the rules and regulations and the need for the project to incorporate them into its structure. Clearly, there is a methodological divide, and each project team should try to close it.

Framework and Tools

At this point, the problem presented by the correlation between the compliance of a product or service and the project that implements them has been established. A study of the literature in the area of project management and in the area of compliance to standards, regulations, and standards produces different results, none of them sufficiently complete to be used without adaptation to any type of project.

Some approaches in certain specific areas of knowledge provide clearer direction but are limited in scope. Examples include the areas of computer security (Arnason, 2008) and management information (Kahn, 2009).

For this reason, the author decided to explore a more open concept: a framework. The framework provides a set of guidelines to follow but does not provide a single solution for the same problem in different projects. In addition, the framework can be adopted according to the needs of the project team.

The basic assumption proposed to achieve compliance under a project reference framework is the existence of a methodology that follows the best practices from PMI. In particular, it assumes that the project is handled under a lifecycle as proposed in the PMBOK® Guide (Project Management Institute, 2008 Chapter 2). It also assumes that the organization itself, the owner of the product or service (not necessarily executing the project), has some level of maturity in the implementation of concepts in accordance with the required standards or regulations. In other words, the organization should be able to execute and monitor the processes required to complying with standards or regulations.

The framework is presented as a permeable layer between the various phases of the project and organizational capabilities to ensure compliance with regulations. The framework is not intended to replace one or the other, but it allows the closure of gaps in one of them, depending on the activities carried out in the other. The base of the framework is the recognition of the rules, regulations, or standards that the project covered by the product or service must meet. It is suggested that as part of the project initiation phase, and as a mandatory element of the project charter, those rules should be explicitly documented. For purposes of this framework, they are called “compliance objectives.”

Once this recognition has been made explicit, it is necessary to establish five pillars on which the various activities of the project must rest. These pillars also act as tools of the framework:

Compliance Documentation: The proposed tool is a set of draft documents that dynamically will change in each of the stages and for each of the components. It is necessary that the documentation be aligned with the principles of quality managed by the organization (e.g., ISO 9000) and, therefore, is treated as a deliverable of the project.

Compliance Council: Although it is not likely that a functional organization provides resources in the area of control or audit to the project, it is essential to involve them in activities related to compliance. Similarly, experts in various areas (legal, environmental, technical) must be eventually incorporated into the project. The establishment of a compliance council is the best strategy to achieving appropriate coverage of all required activities.

Compliance Risk: Project managers are used to handling project risks; however, compliance risks occasionally fall beyond the scope of the project itself. For example, failures in the implementation of security measures, according to standards established by the owners of the credit card franchises, may be reflected years after the project has been closed, when fraud is reported. Clearly, the project manager is not responsible for the results of the “operational” problem, but these risks must be understood during the execution of the project. Additionally, these risk analyses generate corporate decisions that can affect other areas of the project itself.

Compliance Audit: Audit is one of the key elements in the framework and is reflected in the establishment of a specific audit for the project in aspects of compliance. Each project activity aimed to comply or to build the compliance objectives should be analyzed by the audit. This pillar requires the existence of an organization, internal or external to the project, to record all aspects that need to be considered high risk or that create a high impact on the compliance objectives. The independence of this body from the management of the project is important to avoiding conflicts of interest.

Compliance Responsibilities: To the extent that the various members of the team understand the importance of compliance, all activities and their corresponding compliance objectives shall be allocated as parts of the project’s tasks and processes. Project managers must extract themselves from the compliance responsibility and act only as coordinators of the resources and activities required to achieving the proposed objectives.

Exhibit 1 shows the way these elements and tools interact to provide a holistic view of compliance for the project.

Exhibit 1 – Project Compliance Framework

With the introduction of these pillars, different stages, processes, and project activities begin to feed on the deliverables of the project. From a time perspective, the establishment of the pillars can happen at any time, but experience has indicated that each has a better chance of being useful when matched with a specific lifecycle step. Exhibit 2 shows a typical model of how the different components are linked to each of the project phases during the project.

Exhibit 2 – Project Compliance Lifecycle

This compliance review process acts as a gated review. Once running, the tools should allow the iterative and interactive handling of the different components and stages of the compliance. These reviews must be formal and must be documented as parts of the project.

Finally, and as part of a closing review process, the compliance audit shall submit a formal document that authorizes the project closure. At this stage, it is expected that there will be no compliance defects, but if there are some, they must be covered later by the organization, must be clearly documented, and they must have a responsible party for follow-up.

Example: Compliance to ISO-27000 Standards

For this first example, it is assumed that a project deploying technological components must comply with the security policies established in the organization, according to ISO-27000 standards.

It is assumed that the organization has a corporate strategy in accordance with these standards. This means that there are policies and documented procedures and that the implications of any technological implementation are clearly known.

In this example, the project team must include in the project chart, an explicit reference to the need to conform to such standard. Then, as part of the planning process, the project manager should:

1- Include in the project team defining the requirements, one resource from the area of security whose responsibility it will be to document and scope out the ISO-27000 requirements.

2- Include in the team a person able to understand the activities to be carried out and that involve an impact in the WBS. Typically, the activities will be documentation, risk assessment and control selection, tools selection, review code, and review of business processes.

3- The communications plan should include a recurring meeting with the members of the security team to track compliance activities and develop action plans for resolving any problem in this area.

4- Prepare a compliance closing report, outlining the results of the actions and including any documentation generated by the project. This report should also document plans of action to eliminate any non-compliance or obtain the acceptance of the business leaders for non-compliance items.

Example: LEED® certification for a construction project

LEED® (LEED® is a trademark from the United States Green Building Council and means “Leadership in Energy and Environmental Design.”) is the international certification that allows a constructor to demonstrate that the building complies with certain environmental standards. However, LEED® contains a series of requirements defined in the initial stages of design and construction and do not affect only the process of construction itself but also the lifecycle of the product (which may take decades to complete). For example, the certification grants certain credits for the way the occupants of the building operate it as well as planning of what will happen with the building once it reaches end of life.

It is important to define a clear strategy to capture all the information required from design and document it as part of the project. LEED® technical consultants have proposed the use of information-gathering techniques that may cover the design considerations from the first day of the project, using tools in each discipline’s field of expertise that is involved in the project.

Additionally, given the requirement to engage a third party (typically an evaluator with the appropriate level of certification), the framework would:

1- Set aside a project, administered under the supervision of the project manager, involving experts in each of the required environmental areas.

2- Define a specific WBS for this project and use deliverables from this project to feed the construction project.

3- Establish joint working sessions to exchange information and, above all, document the various actions that generate the credits necessary to achieving certification.

4- Involve project evaluators early to gather their feedback during the various phases of the project, which will achieve a complete synchronization between the environmental objectives and the construction itself.

Conclusion

The establishment of a framework for project compliance allows the project team to clarify activities and select the most useful tools to achieving specific objectives.

The framework also eliminates the need to reinvent the lifecycle of the project by adapting the requirements in accordance with each of the stages or phases, with the ultimate goal of achieving compliance or documenting noncompliance, if they are accepted.

Finally, the framework also allows the use of existing project management methodologies, because it adapts to the body of knowledge without sacrificing its generality, but allowing the addition of a new dynamic element and, above all, is very useful for all kinds of projects.

Arnason, S., & Willett, K. (2008). How to Achieve 27001 Certification: An Example of Applied Compliance Management. Boca Raton, FL: Auerbach Publications.

Kahn, R., & Blair, B. (2009). Information Nation: Seven Keys to Information Management Compliance. Indianapolis, IN: John Wiley & Sons.

Merriam-Webster Dictionary. [Electronic Version] retrieved on May 24, 2010 from www.merriam-webster.com

Project Management Institute. (2008) A guide to the project management body of knowledge (PMBOK® guide)—Fourth edition. Newtown Square, PA: Author.

Trusty, W., & Horst, S (2008). Integrating LCA Tools in Green Building Rating Systems. Retrieved on May 24, 2010 from www.athenasm.ca

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010, Ivan Daniel Rincon

Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC