Out of Control Controls and Processes

Summary

Processes and controls are critical for any enterprise. Well constructed processes and controls describe how things get done, provide order and repeatability, and reduce the risk of undesirable outcomes. However, no process and set of controls can guarantee that there will be no errors. And a poorly constructed process can actually do more harm than good.

The key is balance. The process and its controls should be as simple as possible, no simpler, and no more complicated than it needs to be. Achieving this balance requires:

1. A clear and crisp set of objectives that the process, and its controls, is intended to achieve
   
2. An understanding of the costs and risks of implementing the process and its controls, versus not implementing them
   
3. In-depth knowledge of the domain for which the processes are being developed
   
4. An understanding of the limits of what a process and its controls can do
   

Introduction

No doubt. Processes are important for businesses. So are controls. Don't get me wrong. I believe in the need for good processes and solid controls. Anarchy, however appealing to some, is, well, anarchy. And some order is needed to ensure that things get done how and when they need to get done. Entropy increases over time unless you expend energy to reduce it. So there needs to be some mechanisms in place to keep things in order.

But an over reliance on process and controls isn't the solution. In fact, complex processes with many controls can substantially increase the risk to the enterprise in terms of opportunity costs. If the processes are so complex and the controls so burdensome that the enterprise must expend extraordinary effort to accomplish even trivial tasks, then, it is logical that there may be little risk of error. Yet, in this case, the ratio of output to expended resources becomes small. And, the very existence of the enterprise is at risk.

Clearly, on the other hand, having no processes and controls can lead to errors that result in the end of the organization as well.

Definitions

Let's start with a few definitions.

A process describes the act of taking something through an established, and usually routine, set of procedures to achieve a defined outcome. 

Examples of processes include the act of converting recycled PET into bottles for holding spring water, the on-boarding of a new employee, or the purchase of an asset for a portfolio.

A procedure is a sequence of steps that are performed to accomplish a task.

Examples of procedures are the sequence of steps a pilot performs as part of the safety check process, the sequence of steps to log on to your computer, or the sequence of steps performed to close out your cash register at the end of your shift.

Processes may contain controls that provide checkpoints to ensure that the process is being followed or determine whether the process is in control. 

Examples of controls include a measurement of the thickness of the plastic bottle after the first injection, approval to allocate various resources to a new employee during the on-boarding process, or the required approval by the portfolio manager when the asset being purchased has a price above some threshold.

The set of controls and their objectives are often referred to as the controls framework.

Examples of a control's objective may be to reduce the likelihood of errors, malfeasance, and to give management comfort that the enterprise's processes are being followed. Examples of control frameworks are COBIT and COSO.

Process Limitations

Let me back up and talk about what processes can and cannot do. As I defined above, a process describes the act of taking something through an established set of steps to achieve a defined outcome. Usually, the procedures of a process are routine. This means that you have a repeatable set of steps, which are likely to be executed many times over the course of the enterprise's existence. In other words, you have written down the steps for something that is being done over and over again, and you want to ensure that the appropriate outcome occurs every time. An example of this could be the manufacturing of a bottle. Or it could be a nightly marking and recording of economic variables used by the enterprise. In each case, you want the same outcome to occur every time. You want each bottle coming off the manufacturing line to have the same measurements (within a specified tolerance) every single time. Or you want to ensure that the same approach to marking the economic variables occurs every single night so that the variables are consistent, and any trending or relative comparisons make sense.

Next, you may add controls to the process to ensure that the process is being followed. For example, you may add a device to measure the thickness of the side of the bottle; noting when a bottle is out of tolerance, and potentially stopping the manufacturing line. Or, you may have someone review and approve the marks for the economic variables before they are moved to a central, shared repository.

These controls can prevent some types of errors, but remain completely ineffective against potentially unexpected events. In the manufacturing line, the measuring device could fail or be incorrectly calibrated. You may argue that part of the process could be to check the calibration every x number of hours. But in order to check the calibration, you may have to shut down the manufacturing line. And shutting down and restarting the manufacturing line can be too costly, lead to additional risks of equipment failure, or make the manufacturing process too inefficient and expensive relative to competitors. To return to our example of the nightly marking of economic variables, the review of the marks may check against external data sources and perform additional sanity checks. But if one or several of the existing data sources are incorrect, the review may not (and should not be expected to) catch that difference.

If you're not yet convinced that there are unknowable events against which a process and its controls cannot protect, try to develop a process for driving a car such that no one ever has an accident. Can it be done? Of course it can't be done. There are too many unexpected, and more importantly, unknowable events that occur even during a simple drive to the local grocery store. As you drive, you may follow the process and look in all directions at a four-way stop sign, mark it down in a notebook and have it signed by the passenger so that it is auditable, and while you're doing that, someone driving behind you has a heart-attack and plows into your trunk. What controls or processes could have prevented that?

No process, set of processes, or controls can guarantee that no error or malfeasance will occur. It is true. Good processes and controls can significantly reduce the risk of an undesirable outcome. And good processes and controls are constructed in such a way that they balance negative impact on productivity against the risks of undesirable outcomes.

Routine and Creative Endeavors

Placing a process around routine endeavors can increase, possibly significantly, the likelihood that the outcome is the desired outcome. Through procedures and controls you can build a fair amount of predictability into a process. And as required in many enterprises, the artifacts required by the process can be archived as evidence that the correct steps were taken and made available for internal and external review.

But not all endeavors are routine. Many endeavors we undertake within an enterprise are what I call creative. By creative I mean that they are endeavors for which the steps we must undertake to get to an outcome are not knowable at the outset. In some ways, driving is a creative endeavor. At the outset of your trip to the local grocery, there are many unknowable steps you will have to take. Your tire could blow out and you would have to take corrective action to avoid driving into the median. The details of the actions you need to take are not knowable before they are taken. They are a response to a complex set of circumstances that reveal themselves only when they occur. (It is true that you can come up with general principles such as don't pump the brakes (you have ABS). But those are principle, not procedures.)

There are many problems for which the solution isn't known. These problems must be solved through thought, experimentation (trial and error), discussion, research, or whatever it takes. I call the act of solving these problems a creative endeavor. At the outset you may know what you are trying to solve in detail. On the other hand, the problem may be open-ended and part of the endeavor will be to figure out what the problem is that you must solve. In either case, you may not know what steps you will need to take to develop the solution.

You can rightly argue that you can put a process into place for solving these types of problems. For example, you may argue that the first step is to identify the problem. Then you must develop the solution. Then you must validate that the solution works. And so on. But that is only marginally helpful. In fact, such a process is so high level that it is just plain obvious, and hardly useful at all. The fact that the steps toward the solution aren't known means that no process can be described in any significant detail which lays out the sequence of steps that must be taken to arrive at the solution. Rather, it is during the endeavor that the next steps may become clear—or maybe not.

This doesn't mean that you can't or shouldn't put a process in place to manage a creative endeavor. No. I believe that you should. But for a creative endeavor, the objectives of the process and its controls should be carefully aligned with the risk they are intended to mitigate. Any creative endeavor that could have an impact on the enterprise should clearly have controls to reduce the risk of undesirable outcomes.

Take for example, the development of a mathematical model. Most people would agree that this is a creative endeavor. Most people would also agree that before the model is used for driving decisions, the model must be fully tested, and the results of that model should match the expected results and be sensible. In this case, you may put into place a process that focuses on ensuring that the model is well tested and gives reasonable results. And, at the same time, put less focus on the steps that were taken to arrive at the model in the first place. You may also want to ensure that the model and its implementation are well documented, to protect the business, should the author of the model leave the organization. And so you add that to your process.

As another example, take the development of a piece of software by an organization outside of the enterprise. In this case, because the requirements provided to the external organization ("Vendor") form part of the contractual obligation, the requirements are clearly important. In this case, the process should ensure that the requirements are clear and complete before the vendor begins the development. And, that there is a clear arrangement in the contract so that requirements can change—which is likely.

In summary, developing sensible and realistic processes and controls is be complicated. For routine endeavors, at least, we have a good idea of the sequence of steps and the desired outcome. But for creative endeavors, developing processes and controls is complicated because the solution and the steps towards the solution may not be knowable at the outset.

Developing the Process and its Controls

Overly complex processes and too many controls can substantially increase the risk to the enterprise in terms of opportunity costs. If the processes are so complex and the controls so burdensome that the enterprise must expend extraordinary effort to accomplish even trivial tasks, then, it is logical that there may be little risk of error. Yet, on the other hand, ratio of artifacts produced to resources expended becomes small. In other words, the cost (resource expenditure) of producing output becomes large, profits (monetary or reputation) decrease, and the very existence of the enterprise is at risk.

Clearly, on the other extreme, having no processes or controls in place can lead to errors that result in the collapse of the organization as well.

The key is balance. But how do we achieve this balance?

Clear, Crisp Objectives

Before developing a process and its controls, we must define what the process is attempting to describe and what risks it is attempting to mitigate. Are we attempting to prevent someone in the back office from depositing funds into their account? Are we attempting to ensure that the numbers for financial reporting are correct? Are we attempting to ensure that we have adequate documentation for a mission critical application? Whatever the objectives are, we must know them before we can build a process to attempt to achieve them.

The objectives are only part of the equation. We must also understand the costs.

Understanding the Costs

We achieve part of the balance by ensuring that the cost of executing the process and its controls is significantly less than the cost of the undesirable outcome. To illustrate this point, imaging a scenario where the cost (monetary, reputation, etc) of the processes and its controls are equal to the cost of the undesirable outcome. Further, imagine that in this case that if we don't use the process we always get the undesirable outcome. This implies that if we don't use the process we incur the cost of the undesirable outcome. And it also implies that if we do use the process, we incur the cost of the undesirable outcome (recall, that was the cost of executing the process). These two implications lead to the conclusion that we incur the same costs regardless of the process. In other words, we gain nothing by using the process.

To further the argument, let us image that for the same endeavor, we get the undesirable outcome only some fraction of the time if we don't use the process. In this case, not using the process costs the enterprise only a fraction of what it would have lost had it not followed the process.

In other words, unless the undesirable outcome occurs every time we don't adhere to processes and its controls, the cost to company ends up being higher when the endeavor adheres to the process and its controls than it would if they were merely neglected. Clearly, this does not make sense for the enterprise.

The solution in this case isn't to get rid of the process and its controls. Rather the solution is to lighten the process and its controls so that the cost of executing them is only a fraction of the cost of the undesirable outcome. And that fraction should be smaller than the likelihood that the undesirable outcome occurs when the process and its controls aren't followed.

OK, so that's all in theory. And, in practice determining the cost to the enterprise of the "undesirable" outcome is difficult to determine. The likelihood that the "undesirable" outcome occurs is also difficult to determine. In cases where the endeavors are routine, there is hope. When we have routine endeavors, we can capture statistics. And we can use these statistics to determine the likelihood of "undesirable" outcomes. And, we can capture the actual costs of these "undesirable" outcomes.

In the end, though, we need to use judgment to guide the development of the process, its controls, and the real risks we are trying to mitigate.

In-Depth Domain Knowledge

Good judgment requires, at a minimum, an understanding of the domain in which you are making judgment calls. An investor that makes decisions on buys and sells without an in-depth understanding of the products in which (s)he is investing, is not an investor, but rather a gambler. The development of a process and its controls requires an in-depth understanding of the risks involved in the endeavor that the process aims to describe and control. Developing a process without in-depth domain knowledge runs the risk that the controls are too light where they should be heavy, too heavy where they should be light, or some combination of both. I have seen processes developed by people that don't have the domain knowledge. And in each instance, they have attempted to provide controls that prevent undesirable outcomes. And as we now know, this is not possible; we can only reduce risk to an acceptable level.

A good process needs to be low drag. It should align with the way its adherents work. The process may require additional work, but that work should make sense, be logical, and its purpose intuitive. A good process must allow for the nuances of the endeavor where they are truly needed, render unwanted nuances unnecessary, and prevent those that shouldn't occur. A good process should have little overhead. For example, how much does it cost to take a simple endeavor (say one hour's worth of work) through the process--2 hours, 3 days, one month? And I argue that to develop a "good" process as described above, requires an understanding of the endeavor the process is meant to describe and control.

As an aside, in physics there is a principle of least action that says that the path followed by a real physical system is that for which the action (think expended energy) is minimized. This applies to people as well. And so when the process is too onerous, people tend to look for an easier path. And easier path not have the needed controls. In this way, they may circumvent important controls.

Understand the Limits of What the Process Can Solve

From our discussions about developing a process to drive a car, we learned that it is not possible to create processes that prevent all undesirable outcomes. When we develop processes and controls, we must resist the temptation to build processes that "prevent" all undesirable outcomes. At best we can hope to reduce the risk of undesirable outcomes. When we attempt to build processes to prevent all undesirable outcomes, we tend to make the processes extremely costly and complex.

Understanding the limitations of processes--what they can and cannot solve--helps us develop processes that are simpler and less costly to execute, and at the same time, have addressed the areas where they can actually reduce risk.

Coupled with an understanding of the real risks, the costs of those undesirable outcomes, understanding what the processes can and can't solve helps as develop a reasonable balance between the cost of executing the process, the risk of loss.