Search This Blog

Friday, April 17, 2020

OPA: Differences among Policy, Processes, and Procedures

More frequently that one realizes in my project management training as well the conceptual understanding of the organizational process assets, there is always disconnects among the three assets, namely policy, processes, and procedures. Contrary to many that think they are the same or almost similar, they are different. A specific organization may mix up the meaning within their firm. However, based on my limited exposure in working with these OPA elements, I feel that there is a clear conceptual hierarchy among policy, processes, and procedures. Sometimes, even the PMI materials do not differentiate them in the training materials causing confusion and chaos.  Let me elaborate first with an example.

Let us think of a simple security requirements in a company. Often, a company will have an IT security policy. They will differentiate physical resources such as the servers and access to these rooms from the non-physical security considerations like protecting intangible resources like the data, memory, etc. 

For every type of asset identified, there may be additional processes. For instance, when someone has to access the building to ensure that the temperature and humidity are within the tolerances, there would be a process. For people that develop software applications, there will be security processes like secured code development guidelines. So, each policy may be governed by one or more processes giving a one-to-many relationship between policy and processes. 

What if a named resource is sick or inaccessible but an entry to the physical building is required to ensure that the HVAC is working as expected! What if the person is available but must bring his children inside the building on a weekend? On the software development side, what if there is a contractor who can't access certain documents in a shared folder? How to remotely wipe out data on a phone that has sensitive company information including but not limited to software development details? As you can see, each process is not always a happy path scenario but considers multiple what-if scenarios. Each such scenario presents a risk when not protected appropriately. So, many procedures are written down in granular detail with the approvals that are required so that company's assets are protected. So, each process is associated with one or more procedures (1:N relationship) supported by additional guidelines.

Each policy, process, and procedure may be supported by additional policies, processes, and procedures as necessary.