Yes, but is it any good?

Process Management is the application of knowledge, skills, tools, techniques and systems to define, visualize, measure, control, report and improve processes with the goal to meet customer requirements profitably.
~Wikipedia Entry for Process Management, October 2007

In the last two installments, we’ve talked about how to analyze and create process, and how exceptions play a major role in processes. Now we need to ask ourselves what it takes to make a good process.

At the core, a process is about creating a reliable, repeatable outcomes. To do this, we need to develop a good process, certainly, but what else needs to happen? Well, staff needs to use the process and find it makes their lives easier and less disruptive. This is a case where both the “carrot” and the “stick” can be utilized to get the desired outcome. The “carrot” is in streamlining the process down to only the most necessary activities to achieve the desired outcome. That is, reducing the work on people’s plates to give them more time to focus on valuable activities. If your processes create bureaucracy, people will find ways around them. In some big environments, I’ve seen an almost underground economy of favor trading and process dodging emerge because the stated processes were too burdensome to be effective. Once your processes have been appropriately “right-sized”, though you can start considering the “stick” side of the equation – meaning that at some point it becomes necessary to attach consequences to not adhering to processes. The simplest illustration of this comes with the speed laws on the roads. If you knew there was no one monitoring or enforcing the laws, how likely would you be to consistently follow the law? Safety and conservation aside, most people would be screaming down the road as fast as their engines could carry them. If management practices within your organization don’t address (or worse, subversively encourage) ignoring procedures, then your problems run deeper and you’ll need to work with other parts of the organization to implement broader cultural change. We’ll talk about that further down the road.

To “right-size” the process, we need to look at several elements. Though there are many questions you can ask about a process, some of the most important ones can be summarized: Is this the best place I can put a process to get the outcome I need? Is there a place closer to the input that I can place this activity? Do I understand all of the required inputs to the process and how they will be used or transformed by the process? Do I understand who uses my output and how? Have I made the process as simple and straight-forward as possible? Do I understand the exceptions to the process? Could I explain the process to someone who doesn’t understand the specific details of the work I’m doing without going over their head? Have I cut out elements of the process which don’t make sense, don’t specifically deliver on the intended outcome or which consume resources without adding value?

Like any project, the goal of our processes is to deliver a product which is of good quality (a healthy outcome), which can be executed quickly and at the lowest possible cost and/or highest possible return on our investment of time.

Okay, here comes the “boring” part. To work this stuff out, you need to start by creating a process flow. We’ve talked enough about this in the previous installments, but lets go over it once again just to make sure – start with your input, and proceed through evaluating each decision point that occurs in the process. You need to begin critically analyzing these decisions points. Do they have all the necessary inputs? Does the result directly lead to or assist the development of the desired outcome? How long does it take to resolve each step? Why does it take that long? A good way to get this information is to go right to the people responsible for executing the process and talking to them. Have them walk you through the process. For that matter, do the process a few times yourself so that you understand exactly what the folks have to do. This is important, because often the processes an organization uses contains hidden steps, which are only revealed through this practice of getting into the trenches. Those hidden steps add up pretty quickly in terms of bureaucracy and time consumed, so understanding why they are there (are they actually hidden requirements, for example) helps in engineering a more effective process.

Now, you’ve worked through your process. You understand the constituent inputs, outputs, processing steps and exceptions. You know who gives you input and who uses your output. Now what? Measure it. You will need to establish some methods of ensuring that the process is doing what you want in the timeframe that you want. This is accomplished by establishing some key metrics to regularly evaluate the outcomes. For example, let’s say one of the processes you are developing revolves around resolving help desk cases in a timely fashion. To do this, you’ll need to define what timely looks like, then measure your outcomes against this criteria to see how you’re performing. Establishing these metrics may very well involve more than just your part of the organization. How long should a customer wait for a help desk case to get resolved? If you’re answer is “it depends”, do you think you would benefit if the customer had a say in the matter?

Over the last few installments, we’ve talked about establishing emergency solutions, getting them up and running and functioning in the way you need them to.
But the road doesn’t end there. Actually, its just the beginning. You’ve tackled the “C” in GRC – Compliance. Compliance is the first step to developing a truly world class IT organization. The “R”, Risk Management, and the “G”, Governance, are also key to creating and maintaining a powerful IT organization that delivers value to its customers. The next series of installments will discuss taking your compliance efforts a step further to help your organization manage risk and improve overall performance.