Define your “process process”

April 21, 2016February 8, 2021 by John Borwick In IT management, Process improvement

In your organization, how do people understand what is expected of them? Employees can be reprimanded for incorrectly executing a process (e.g. “You didn’t fill out your status report!”) when they didn’t understand what the process was supposed to be (e.g. “What weekly status report?”).

Some processes are so fundamental that we can safely assume everyone understands them: close the office refrigerator door when you’re done; park inside the lines of the parking lot. But in IT some of our most important capabilities are complex processes that we want to improve (i.e. change). Understanding the current-state process is hard enough; how can we ensure everyone knows the new process? Relying on word-of-mouth is not only inefficient, it’s outright dangerous, as people can argue over the processes based on who told them what when.

As a simple solution: document your process! This documentation does not need to be complicated; I just released a simple process template that you can start with. However, process documentation is not enough: you also need a “process process” for how processes are created, changed, and removed over time.

One of the first things I tend to recommend an organization do is define its “process process.” This sounds silly, and bureaucratic, but it’s important. The process process is a way for everyone to agree that a process is official and binding on them. It provides stakeholders with a way to object to or change the process, which helps with buy-in once the process is in effect. It provides leaders with a way for the organization to change itself, so that leaders don’t have to manage by edict. It also adds a mechanism for existing processes to be improved.

Here are the core things you need for creating your process process:

1. Process template. This does not have to be fancy. As I mentioned, you can start with our open-source template. The idea is that all processes would be written using this template. If you realize you need additional information collected for a process–say if you want to maintain RACI charts for each process–you can add a new section to the template.
2. Controlled, accessible, authoritative location for approved current-state processes: You need a place where all stakeholders (e.g. all IT staff who may need to know the processes) can go to access the process documentation. This can be as simple as a SharePoint site, Google Drive folder, or file share, or it could be a fancy document-management system or knowledge base.
3. Major process change process: This is the process to be used when a new process is created, changed in a significant way, or removed. This process should have several levels of review, including a review that includes the top leadership involved (e.g. the CIO/CIO’s office) for the scope of the process. Typically the decision should be “Approved,” “Approved with minor changes” (see below process), or “Deferred/rejected.”
4. Minor process change process: This is the process for smaller process changes, such as changes to role names, screenshots, descriptions, etc. Ideally, this maps to an “approved without objection” where anyone can object to escalate something to the major process change process.
5. Periodic process review process: The process owner for each process should have to review their processes every so often. I am a big fan of doing this review very regularly, say quarterly. The whole idea is that the review should be quick, and just validate that the process documentation is accurate. This review is a check to ensure your process documentation is still needed, and it’s reliable.
6. “Process process” owner: Someone needs to be in charge of the “process process” and associated documentation such as the process template. This is a fair amount of initial work, but the work lessens over time as people understand the process process. This role maps well to anyone who handles communication or documentation. This job entails ensuring that processes are updated and reviewed appropriately.
7. Extremely strong bias towards iterative improvement with first-version processes: You want to approve processes early, without a huge amount of detail. Do not let people go for six months defining a process in a huge level of detail. That probably sounds weird, but you want to show people that processes can be changed. Ideally, you want processes to go through a couple of major revisions pretty quickly so that people see that you’re not approving a process in 2016 that will not change for 10 years. Create the expectation that processes can change.

Typically, you will draft a “process process” document and put it through your “major process change process,” with the caveat that you will also get some other higher-level stamp of approval such as the CIO’s signature. The idea is that people realize that all processes (or at least all unit-wide processes) must be documented in this way for them to be binding.

You may be realizing that the process process is reminiscent of IT service change management. Indeed, you can think about this as a type of IT service change. The infrastructure that you build for approving these processes can later be used for high-risk changes such as major upgrades to your ERP system or campus-wide outages. That’s another reason why I recommend that organizations build a “process process” early: not only are you creating a mechanism to define, improve, and communicate your processes, you’re also creating a reference point you can use later when building IT service change management.