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