Policies, Processes, and Procedures

Relationships among Policies, Processes, and Procedures

process-improvement-header Graphics Image by Converge PointOpens in new window

Process ImprovementOpens in new window requires that participants understand the distinction between a Policy, a Process, and a Procedure before beginning improvement activities. All three terms address related subject matter but do so with different types of content and at different levels of detail.

Each term has a unique purpose that drives the content contained within each document. Although these terms are often used interchangeably, Policies, Processes, and Procedures are in fact distinct items.

Consequently, it is important to have a formal definition of each term prior to embarking on improvement initiatives. With this understanding, participants and stakeholders know what work will be performed over the course of a Process Improvement projectOpens in new window.

Although it is very easy to lump these terms together as if they were a single entity, knowledge of the difference will enable participants to understand the documentation that will be produced, as well as deliver higher-quality artifacts throughout Process Improvement projects.


Policies are guiding principles that are intended to influence decisions and actions across an organizationOpens in new window and govern the implementation of its process-and-subprocesses-definedOpens in new window. They include laws, guidelines, strategic goals, and business rules under which an enterprise operates and governs itself (why an organization does something).

Policies contain the formal guidance needed to coordinate and execute activity throughout an organization. When effectively deployed, policies help ensure process designsOpens in new window meet organizational standards.

There is not a one-to-one relationship between a Policy and a Process as corporate policies may affect multiple processes. However, processes must reflect the business rules contained in any related Policies.

Policies outline a particular principle an its classification, describe who is responsible for its enforcement, and outline why the Policy is required. Although both are considered elements of guidance, policies are usually translated and refined into business rules.

As shown in Figure X-1, a simple Policy Document is the most common tool used to describe a Policy.

 Figure X-1. A sample of policy Figure X-1. A sample of policy
  • A Business Rule is a declarative statement of control or constraint that the business places upon itself or has placed upon it.
  • Policies, on the other hand, are general or informal statements of direction for an enterprise.

A Policy may be the basis for one or more business rule statements, just as a business rule statement may be based on one or more policies. An example of a Policy-Business Rule relationship for a car dealership would be the following:

  1. Business Policy: We only sell vehicles in legal, roadworthy condition to our customers.
  1. Business Rules: Vehicles must be safety checked upon return from each customer test drive.


Processes are related activities or actions that are taken to produce a specific service, product, or desired result.

Processes can be formal or informal, large or small, specific to a set of cross-functional departments, or span across an entire organization. Processes are publicly known, documented, supported, and widely used by an organization.

Processes contain resources, steps, inputs, and outputs used to indicate where there is separation of responsibility and control within a series of related and connected activities (what an organization does or should be doing).

Unlike the relationship of Policy to Procedure, there is a direct relationship between Processes and Procedures as Procedures describe in detail how each activity within a process is carried out.

Processes address who is responsible for performing activities (departments or divisions), what major activities are performed, and when the process is triggered and subsequently halted.

Common tools used to display processes include Flowcharts, Cross-Functional Process Maps, and Integrated Definition for Functional Modeling (IDEF) Diagrams.

An example that illustrates this concept is the process of repairing a vehicle at a car dealership (Figure X-2). The process is triggered by a customer’s request for an appointment and concludes when the vehicle is returned to the customer for use.

chiasmus diagram showing abba pattern Figure X2. A Simple Process Map for Automobile Repair | Credit: Sparx SystemsOpens in new window

A Subprocess is a set of activities that have a logical sequence and that meet a clear purpose but with functionality that is simply part of a larger process. Just like processes, there are goals, inputs, outputs, and owners, but they are modeled as lower levels of detail within larger processes.

Subprocesses are important because they play a major role in improving overall processes. In many cases, processes are too large to analyze and improve at one time, and so grouping common process activities into subprocesses can help Process ImprovementOpens in new window efforts tremendously.

It is recommended to break large processes into separate master processes and child processes, because it reduces the complexity of the process map and allows subprocesses to handle exceptional situations and ancillary activities. Subprocesses are also useful for hooking the functionality of an existing process into another process.


A Procedure is a set of written instructions that define the specific steps necessary to perform the activities in a process. They document the way activities are to be performed to facilitate consistent conformance with organizational requirements and to support quality and consistency.

  • Procedures define how the work is performed and are typically documented in step-by-step fashion, describing in detail each activity within a process.
  • Procedures detail specifically who performs the activity (the role within a department), what steps are performed, when the steps are performed, and how the steps are performed, including any standards that must be met.

The development and use of Procedures is an integral part of successful process-focused organizations.

Procedures provide individuals with the information needed to perform their jobs properly and they detail the regularly recurring work processes that are to be conducted or followed. Many businesses use Procedures to reduce errors, assist with training employees, or as a point of reference to ensure consistency of work.

In doing so, use of Procedures can minimize variation and help ensure quality through consistent implementation of activities within an organization. Procedures can take the form of a Work Instruction, a quick reference guide, or a detailed Procedure Document.


Work Instructions are a form of Procedure and are generally recognized as a subset of Procedures. However, they are typically written to describe how to do something for a strange role or activity within a process; whereas full-fledged Procedures describe the detail of every activity within an end-to-end cross-functional process.

Well-written Procedures can often eliminate the need for documenting Work Instructions. However, most process mapping and modeling tools available today enable and encourage Work Instructions over formal Procedures due to the click-through and comment-oriented nature of the applications. Organizations may choose the most optimal and user-friendly route for their users.

    Research data for this work have been adapted from the manual:
  1. Tristan Boutros, Tim Purdie. The Process Improvement Handbook: A Blueprint for Managing Change and Increasing Organizational Performance.