Locked lesson.

Upgrade

About this lesson

Project requirements encompass more than the functional requirements. There are government, industry, and organizational requirements with compliance attributes that must be managed.

Quick reference

Compliance Categories

There are many potential compliance requirements. Understanding the categories for these requirements helps the project manager identify which will apply to a given project.

When to use

At the time of project initiation, the compliance categories are reviewed to determine compliance requirements. These are noted as project constraints in the project initiating and planning documents.

Instructions

Compliance is the adherence to required or expected standards and principles. These standards can be segregated into three categories.

Government or Industry Standards

These are the compliance references with the biggest “teeth.”  Operating in a manner that is contrary to one of these can create legal problems including fines and criminal charges.  Many of these will be unique to a particular type of project, so it is critical to determine if your project activities must comply – examples are environmental laws that apply to specific materials.  However, some are general standards that would apply to any project, such as employment laws and regulations.

There are also industry codes and standards.  Not surprisingly, these vary from industry to industry and may even from location to location within the same industry.  An example is building codes which apply to construction projects but can literally vary from city to city.  Some industries have government oversight bodies that set regulations and other industries will recognize an independent agency such as the IEEE or NEMA as standards issuing agencies.  Within the project management arena, the Project Management Institute is such as organization.

Customer Requirements

Customer or user requirements become a compliance issue when the project is being completed under contract.  In that case, the requirements documents that are noted in the contract’s Statement of Work (SOW) are contractually required constraints on the project and must be complied with.  These will either be in the form of user needs and functional requirements or in industry standards that are referenced in the contract. 

Some of the customer-based requirements may not be formally captured in the contract.  However, they may be an expectation of the user community and a failure to comply with those requirements will result in a rejection of the project deliverables.   These are less rigid since they do not have the force of law behind them and a project team can negotiate these with the stakeholders.

Internal Policies and Procedures

Most organizations have internal policies and procedures that projects are expected to comply with.  Many of these deal with general business practices such as employment, purchasing, security, or financial practices.  Some organizations will also have internal project management policies and procedures that must be complied with.  These are usually captured in the organization’s project management methodology and procedure.  These may require the use of certain project management tools or applications.

Hints & tips

  • Projects with external stakeholders will typically have more compliance documents, many of these imposed directly, but some are included in an indirect manner based upon the stakeholder’s expectations.
  • Check to make sure you are using the correct revision of external standards.  Many standards are changing frequently.  Unless the compliance reference for the project is to use the latest version, you will need to be compliant with the version specified.
Login to download
  • 00:03 Hello, I'm Ray Sheen.
  • 00:05 Well, let's dig deeper into the topic of project governance.
  • 00:09 I'd like to discuss the categories of project compliance that should be
  • 00:13 addressed by your project governance process.
  • 00:16 First, let's agree on what we mean by compliance.
  • 00:19 It's the adherence to requirements or expected standards and principles.
  • 00:23 So we're not talking about a compliant personality who does whatever someone
  • 00:28 tells them to do.
  • 00:29 We're actually talking about standing on principles to ensure that what is being
  • 00:34 done is being done correctly.
  • 00:35 Of course that begs the question of,
  • 00:38 who determines what is the correct way to do things?
  • 00:41 In project compliance, we can organize the standards into several categories.
  • 00:46 One category is easy to understand.
  • 00:48 This is the category of government or industry standards and regulations.
  • 00:52 These are universally and are published and easily available.
  • 00:56 In fact, if anything, there are too many of them.
  • 00:58 The stakeholders and
  • 00:59 project manager must determine which apply on any given project.
  • 01:03 The next category is the customer or user standards.
  • 01:06 These are set by the economic buyer of the project results.
  • 01:10 They're often listed in the project requirements documents.
  • 01:14 Many times, these will be unique to a given project based upon how the user
  • 01:18 intends to deploy the project results.
  • 01:20 The third category is internal policies and procedures.
  • 01:24 These have been established by organization and are applied by
  • 01:27 the stakeholders to the project based upon the type of the project.
  • 01:31 Let's dig deeper into each of these categories to understand the nature of
  • 01:35 the requirements, and the compliance perspective.
  • 01:38 I'll start with the government and industry standards.
  • 01:41 These standards are universally applicable to any activity that is governed
  • 01:45 by the area of industry, technology, or society.
  • 01:48 They can have a very real impact on projects.
  • 01:51 For instance, environmental standards and
  • 01:54 laws may limit the activities that can be conducted in certain regions.
  • 01:58 Also, virtually every country has employment laws that must be followed.
  • 02:02 And many local, regional and national agencies require licensing and
  • 02:06 permitting for certain types of activities.
  • 02:09 Compliance with standards and laws are critical for the project and organization.
  • 02:14 I know a former project managers who lost their job for violating these and
  • 02:18 organizations that have paid heavy fines.
  • 02:21 In addition to compliance with government standards,
  • 02:24 they're often industry standards.
  • 02:26 While these may not have the same effect of law,
  • 02:29 they can absolutely shut down a project if violated.
  • 02:32 Examples include building codes or transportation codes.
  • 02:36 If you ignore these,
  • 02:37 the project will not be able to get past a certain stage in the project.
  • 02:41 No one will work on the project or use the project results.
  • 02:45 Some industries are considered to be regulated and
  • 02:48 to participate you must follow the industry standards.
  • 02:51 For instance, the pharmaceutical industry has numerous standards for cleanliness and
  • 02:56 processing.
  • 02:57 In addition, some industries have user or consumer protection standards.
  • 03:00 Being able to state that you comply with a standard can be an advantage for
  • 03:05 the project or project result.
  • 03:08 Many companies have created their own set of internal standards and policies.
  • 03:12 These are usually based upon lessons learned from a previous project.
  • 03:16 The standard guides a team on technical practices that they must follow.
  • 03:20 Some companies do not create their own instead, they borrow from practices
  • 03:26 published by professional associations such as PMI, ITIL, or IEEE.
  • 03:31 Most organizations will require that the project demonstrate that they
  • 03:35 are in compliance with applicable standards and
  • 03:38 regulations while conducting technical design reviews.
  • 03:42 The next category is the customer or user requirements.
  • 03:45 Customer compliance is a big factor when the project is done under contract.
  • 03:50 The customer who is paying the bill can and
  • 03:53 does require certain things to be done or not to be done.
  • 03:56 Some obvious elements of these are the statement of work in the contract.
  • 04:00 This will contain formal requirements for performance and
  • 04:03 often requirements for customer communication.
  • 04:06 In many cases, the customer may reference an industry standard which makes it
  • 04:10 a compliance requirement.
  • 04:12 Compliance to use requirements is a bit different.
  • 04:16 They don't have the power of the purse where they can shut you down because they
  • 04:20 are not paying for the project.
  • 04:21 But the users do have power to reject the project results.
  • 04:25 For this reason,
  • 04:26 it's important to understand how the user will use the project results.
  • 04:30 What are their expectations?
  • 04:32 What is the normal way they do things today?
  • 04:34 You must meet these standards to achieve a project success.
  • 04:38 And in some cases, the users have a sense of what is good workmanship or
  • 04:42 a standard of excellence.
  • 04:44 They may not formally state their expectation, but fail to meet them and
  • 04:48 you will soon hear about it.
  • 04:50 In general, compliance for customer and user requirements is less rigid.
  • 04:55 In part because they don't have the power to put you in jail or find you.
  • 04:59 Well, that's good there is a corresponding negative and
  • 05:02 that is that these requirements are often evolving.
  • 05:05 What was good enough for the customer last week is no longer good enough this week.
  • 05:10 And to further complicate this area, the priority of conflicting requirements
  • 05:14 often varies depending upon which project stakeholder you talk with.
  • 05:19 Our third category was internal policies and procedures.
  • 05:23 These include organizational business practices, such as employment practices or
  • 05:27 purchasing practices.
  • 05:29 For instance, I worked in one organization that had policies concerning how
  • 05:32 contractors and vendors must submit their deliverables.
  • 05:35 There was one way regardless of what the project team wanted to do.
  • 05:39 Another example that's gaining prominence is security.
  • 05:43 Many organizations have created restrictions about who can have access to
  • 05:47 different levels of information and
  • 05:49 different platforms that data will be stored on.
  • 05:51 And of course, almost every organization has policies around travel.
  • 05:56 Add to this, any requirements imposed by the project management methodology.
  • 06:01 Again, this may specify tools to use or when reviews must be conducted.
  • 06:06 And even if the methodology does not require it,
  • 06:09 often stakeholders will add these requirements for reports or meetings.
  • 06:14 Finally, the project may impose its own requirements on itself.
  • 06:17 It may set up regular meetings that all core team members must attend.
  • 06:21 Or may require that everyone maintain their status of a particular app.
  • 06:26 I've also seen projects create risk management policies that they use to
  • 06:30 ensure risks are identified and responded to appropriately.
  • 06:33 We'll talk more about the use of communication tools when we discuss
  • 06:37 the project management information system.
  • 06:40 Compliance is a hot topic in business today.
  • 06:43 Use the categories for project compliance to guide your review and ensure that
  • 06:48 you have not overlooked a compliance element that could derail your project.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course