4squareviews

The Agile Project Management Processes Grid has been created by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference.”   He divides the 87 processes used in agile project management into five process groups and seven knowledge areas.

This post covers the second of three processes in the block of processes that are used in the Initiate process group and the Risk Management knowledge area:  Regulatory Discovery.

In traditional project management, there are two “generic” inputs that are used with a lot of the processes, namely “Operational Process Assets” (or OPAs) and “Environmental Enterprise Factors” (or EEFs).  The OPAs are assets such as documents that are used in the organization as repositories of procedures, guidelines, and templates to be used in project management.   With regard to risk analysis, these were covered in the previous agile PM process 5.1 Organizational Practices.

The EEFs, on the other hand, make up the environment outside the organization in which the project takes place.   One large category of EEFs are government regulations.   Risk analysis involving these government regulations is what this current process 5.2 Regulatory Discovery is all about.

Regulatory Discovery Process 

Here’s how the process works.

1. Identifying all stakeholders (process 1.1 Stakeholders Identification).
2. Identifying those stakeholders, external and internal, who may need to audit the project.
3. Identify the documentation that will be required by those stakeholders, sometimes referred to as documentation user stories.
4. Make sure the documentation user stories track the requirements such as testing plans, results, etc.
5. Create a protocol for tracking the documentation user stories during the lifecycle of the project.

Since the relative penalty for not being in compliance with government regulations is high, it is important to engage in regulatory discovery and compliance activities in order to mitigate risks such as product liability.

However, the amount of resources that you place in compliance should be the minimum needed to ensure compliance, and compliance activities should be directed away from critical team members so that they can concentrate not on reducing a negative (mitigating risk) but on increasing a positive, in terms of adding real value on the project on behalf of the customer.

The kind of risk mitigation that SHOULD involve the critical team members is related to quality standards, which is the subject of the next post.

Filed under: Uncategorized |