Although the Agile aficionados tried really hard to kill the notion of process in their efforts to remove the heritage of the capability maturity model, the fact is that every team, company and business ecosystem uses processes. These can be formally defined, to the point of individuals or companies being legally liable if the process isn’t followed, like in the medical space. Or, at the other end of the spectrum, they can be highly informal and grown over time as teams figured out how to do things.
As organizations grow and more and more people become involved in the key value-delivery activities, the need for coordination goes up exponentially. The preferred approach to coordination is to use architecture. In this case, the architecture defines the interfaces between components and teams working on different components can operate independently as long as the interfaces aren’t affected. However, for every architecture, there’s a point where we need to adopt processes to manage coordination between teams and along the organizational boundaries.
We tend to use the term “process” quite lightly as “a series of actions or operations conducing to an end.” In practice, however, any process has quite a few interfaces as well as individuals who are expected to behave in certain ways and generate specific outcomes for the process to keep moving forward. Also, once a primary process takes hold in an organization, secondary processes seek to hook into it with the intent of piggybacking and simplifying their own coordination.
In many ways, this is a positive thing as it provides structure and scaffolding for the company to operate in as well as providing a heartbeat for the organization as many processes are periodic. In a lot of companies, however, over time the process grows into an unwieldy set of activities, interfaces, dependencies and expectations that become part of the walls and fabric of the company. As long as no change is needed outside of individual activities, this will allow the organization to deliver value to its customers and optimize each step. The challenge starts when change is required and everyone in the organization realizes that they live in a straightjacket that’s impossible to change unless everyone changes at the same time – which of course is impossible to do.
This is where everyone starts to blame “the process” as being the root of all evil, for several reasons. First, there’s of course sheer frustration about the inability to change where it really is necessary to do so. Second, it provides an excuse to not change and keep things as they are. This victimhood approach is especially dangerous as the company easily becomes more and more out of touch with the market and its customers, rapidly increasing the risk of disruption.
The principle is that if you can’t change at one level, you attempt to change one level up. This continues iteratively until you reach the ecosystem level. There have been situations where entire business ecosystems have been disrupted as they were unable to respond to the changes around them, such as the shipyard industry in Europe in the 1970s and 1980s.
The misconception held by many is that there indeed is such a thing as “the process.” Of course, there are documented and certified documents of how companies, teams and individuals are supposed to work. But there are at least three main concerns with using the term as many do: definition, completeness and boundaries.
First, as with the other concepts we’ve discussed so far, the notion of “the process” is interpreted very differently by people inside and outside the organization. Similar to the elephant in the Indian fable, everyone has a different experience and interface to the process and another conceptual model of what everyone assumes is the same. This tends to lead to confusion, misinterpretation and tension between individuals and teams.
Second, although very intelligent people have spent vast amounts of time defining, modeling and describing processes, the fact is that any formally defined process tends to describe a fraction of all activities, artifacts and dependencies involved. In many ways, the description only captures the tip of the iceberg and not the 90 percent below the waterline. One illustrative example is when workers in a company go on an alternative strike where they only conduct the activities formally specified in the process descriptions and refuse to do anything not described. As one would expect, things rapidly grind to a halt.
Finally, there’s the challenge of boundaries. Formal process models have a clear beginning and end, with steps, dependencies, artifacts, and so on. In practice, no process is truly independent and has significant dependencies and relations to other activities. In that sense, what we refer to as a process may easily be a randomly selected set of activities in a cloud of many more actions, artifacts and dependencies. Even if we model a set of processes and dependencies between them, the way the interconnecting lines get drawn is highly debatable in most contexts.
The notion of “the process” is highly elusive in most contexts and can easily be abused as an excuse to avoid or delay change. This significantly increases the likelihood of disruption of the offering, company or ecosystem. Instead, we have to treat the concept with healthy skepticism, realizing that definitions, level of completeness and perceived boundaries are highly arbitrary and strongly depend on the viewpoint of the defining individual. As one of the key people in process thinking, William Edwards Deming, said: “We need to work on our process, not the outcomes of these processes.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
