Pflogging ... in pursuit of accelerated value creation

The word process is an abstract concept. As a result, its meaning is often dependent upon the context in which it is used, and the mental models of those who are using the term. The dangerous part of this is that people can carry on conversations about them, and believe that they are talking about the same situations, even though they are actually discussing several, fundamentally different things. As a result, they each can think that they are communicating about the same 'process', and can go away from that conversation with the mistaken impression that they all agree on something meaningful, or all have a shared vision of what it will take to transform something. What is really going on is that consensus is typically achieved by adding ambiguity, rather than removing it.

As an example of these different 'mindsets', consider the following:

1. People often use the word "process" to describe what people actually did in a particular situation, as in, "The process we were using did not anticipate this situation". This is another way of saying, "We hadn't anticipated the situation that arose".
2. People also use the word "process" to describe what was agreed to as formalized direction for what was to have been done, as in, "The written process did not provide for the situation we encountered".
3. Finally, people use the word "process" to talk about how people intend things to work, as in, "Our process should respond to problems that are encountered along the way."

Ambiguity can enter into each of these scenarios separately, and must be dealt with through different approaches in each context. Yet by adopting an abstract term for discussion, such 'strategic ambiguity can stall this necessary clarifications. Until the details of a process are actually formalized and written down, there is no meaningful basis for evaluating the results of 'the process'; what you are really doing is evaluating people's mental models. Once a process is written down, and under configuration control, only then can you begin to refer to that process in the same way that you might describe using different versions of a program, as in, "When I used version x of program / process y, it did not support the situation that arose when I presented it with these specific types of inputs, so I wrote a change request to have it supported in version 3; when version 3 was in beta testing, I noticed that new feature had been added, so I approved the release of the program / process." When such details are written down, their content can be examined, and their quality and functionality can be evaluated and improved over time. When such details are instead abstractions in people's heads, it is difficult to improve those ideas in a consistent way. It is also unlikely that you will be able to 'scale' those ideas across a large group of people, and get predictable results.

As an additional wrinkle, there is rarely just a single process in use, but rather typically are a collection of writings, each usually being evolved by different teams, often to different requirements and schedules. This evolution must be planned, managed, and integrated in order to consistently produce a new set of written material that satisfies a defined set of objectives, and that organizations can then follow. Since processes are primarily intellectual, rather than physical, they run the risk of being misinterpretted and misapplied. One can think of processes as 'source code', and an organization as a computer to run that source code on. You really don't know how well the source code is until you try to run it in the target computer (i.e. the organization). In a sense, you can have source code that sounds great to the programmer, but what matters is how well that source code operates in dynamic execution.

To deal with these risks of execution, the process improvement industry has tended to adopt a few concrete terms and definitions to describe these concepts. First,  the capability of a documented process is used to describe ‘the capacity or ability to do something, achieve specific effects or declared goals and objectives.’ A related concept is fitness for use, which is 'a process free of deficiencies.' In essence, capability determines what features a collection of processes has, and fitness determines how well the process implements that feature set. To evaluate these two things, one must of course know what the requirements basis for the process is, and these requirements must be written down, and be managed under configuration control, just as the process itself is. Finally, the concept of organizational maturity is an indication of the degree to which an organization is consistently practicing a well-defined set of processes in performing its work.

To achieve organizational maturity, the infrastructure to deploy and support this defined set of processes must be robust, and the culture must accept the direction to follow this set of processes. This generally only happens when the process has been designed to accomodate the needs for the critical stakeholders in the culture, and when the processes have been verified and validated to be sure that the process is, indeed, fit for use.

Often, there are different responsibilities for process execution, process management, and project management, for such a defined set of processes. Data produced by these processes can have considerable variation, before this set of processes are well documented, integrated, and managed. As a result, the data produced by those processes may not even be suitable for decision-making, until the processes have sufficient capability and fitness, which usually requires that appropriate disciplines are put in place. Until the processes are capable, and the organization is mature, this can create a situation in which decisions are made based upon perceptions and mental models, rather than reliable data. When this occurs, such decisions are often performed in an outer, 'decision-making' loop, while execution occurs in a different, inner-loop context. This can be dangerous, since delays between execution and decision-making can bias these decisions, and introduce oscillations into operation. This is depicted in the diagram on the right (click on it to access a full-size version).