The Foundation of Process Design

Process design is the part of a process improvement project where the process practitioner “builds” a new version of the process, with a goal of optimizing efficiency and reducing waste. This is an integral dimension of business process management and is also the phase of process improvement that demands the most academic rigor. It can be the fun, creative part of the cycle; however, with a blank slate, or for a practitioner with minimal formal training from a traditional discipline (e.g. Lean/SigSigma), it can be a daunting task–particularly under the pressure of typical corporate project constraints.

Like many aspects of process management, process design as a discipline has become more complex than it has to be. This is because the operating definition of the activity (i.e., where it starts and ends, where and how it should be applied) is ambiguous from an industry standpoint. Without a clear academic container to understand the scope of the activity, mastering process design is a difficult, trial-by-fire endeavor. 

In this post, I’ll introduce some Cavi-approved, process science-based operating definitions around process design. The goal of this exercise is to share some foundational principles which can be applied in the process design phase to support a more effective approach.

What is process design?

Before diving in, it is worth noting that the term “design” can be used in both noun and verb contexts. This distinction will come in handy as we go through the definition of the “process design” concept.

A process design (noun form) is some type of physical (e.g. a document) representation of a planned sequence of activities meant to achieve a particular objective. While this is a representation of the process sequence as it works in a theoretical sense, every process working in the real world is informed by a process design. This is true even for processes where the design is not formally or consciously articulated and/or premeditated–in these cases, the process design is implicit within the physical execution of that process.

Despite the fact that a process design exists for every process regardless of physical documentation, the best way to work directly with a process design concept is to visualize it by creating a process document (commonly referred to as a “process map” or “process flow”). If you are working with a process which in its current state does not have a process design document associated with it, you are in the position to “reverse engineer” the design document from observation. 

This is therefore an important part of the definition: a process design is not restricted to new processes that don’t exist yet. All processes intrinsically have a design which can be documented, even if this was not done at the outset of the process being initiated.

The activity of process design (verb form) encompasses all activities required to create a new process design (noun form above). Depending on what activities are considered requisite to designing a new process, the scope of what is considered “process design” work can vary. From the Cavi perspective, process design starts with the actual creation of the design document and ends when that document is finalized

Despite the seeming simplicity of this definition, a good process designer is more than someone who can pull out a piece of paper and start drawing a process diagram. The job of the process designer involves understanding the overall objective of a process design, along with the context and phases of the process improvement cycle which both precede and follow the process design stage. These are the factors that collectively dictate whether this design phase will be successful or not.  

The objective of process design

The objective of process design is a universal one: that the design be enabled in the workflow layer; or in non-Cavi terms, that the design be successfully implemented/deployed in a live operating environment. 

Regardless of the language we use to describe this objective, the point is that whatever process design you make should be realistic enough in a real-world context that people and technology can be instructed to do it. As obvious as that may sound, it is actually the most difficult part of process design work: creating something with enough detail and realism to it that it could actualize in physical reality and fulfill the intent of the design. 

To expand that point by analogy, pretend you are a sketch artist for the police. You could listen to a witness description of a suspected criminal for 10 minutes and draw a 10 second sketch of a smiley face with some hair and eye color details that match the description of the suspect. You would have designed the picture of the suspect, and sure, it may help filter down to some extent the several million person pool that the suspect is currently hiding in. But given the objective of the exercise–successfully identifying the real-world criminal–the chances of meeting this objective using that sloppy sketch wouldn’t be stellar. Conversely, you could spend months of effort on the portrait, work with the witness over multiple sessions and paint a portrait so realistic that it would be like a photograph. The level of realism in this case increases the likelihood of meeting the objective by orders of magnitude because it drastically reduces room for ambiguity or error in the scenario; however, at what cost? 

This is the same continuum which applies to process design: a spectrum of low effort/cost and a not-very-realistic design, to extremely high effort/cost and a design with almost life-like detail. If the objective is to have a design that can be implemented in the real world, then the balancing act is always a question of how to achieve the level of detail needed to make it usable at the lowest cost. 

Optimizing the context and activities around process design therefore becomes the lever to control how expensive and effective process design will be. Understanding how to structure the process design activity within the larger process optimization context will determine: 

  1.  the necessary expertise and variables required for design work, 
  2. the complexity and conditions of the operating environment the design is intended to be deployed to, and
  3. the considerations around how to maximize the return on design work (lowers the effort/cost, while achieving a level of detail minimum for successful implementation). 

Project context and process design

There is an infinite amount of variation in project contexts that could demand process design work (because after all, every project attempts to change a process). In talking about process design foundations, I will first offer some resources to learn more about the Cavi Method approach to project structure, and then discuss universal scenarios that will help to appropriately frame process design activities within any project context.

The ideal project structure to facilitate good process design is the Cavi Methodology for executing process improvement projects. If you’re interested in understanding how that method is curated specifically to support good process design work, you can find an introduction to the Cavi method here, and read specifically about the process analysis and design phases within that methodology here

In a more universalized context, demand for process design can be organized into three categories: 

  1. Improving an existing process;
  2. Creating a new process from an internal energy flow; or 
  3. Creating a new process from an external energy flow. 

In the first scenario, improving an existing process, we have the classic process improvement case. In this type of project, there is a process that is already operationalized in the physical environment, but with an aspect that requires review (usually to reduce some dimension of cost). In this situation it is critical to review the “as-is”, or current, version of the process as a baseline, and then tweak that working baseline to create a new design to transition into. 

This strategy ensures higher physical continuity because you are modifying an already working system to slightly change its behavior. Even this can be tricky work, but of the three scenarios, it is the most manageable from a process design standpoint because there is already a working model from which to draw knowledge and build the foundation of the new process design. 

In the second scenario, the task would be to build a new process with no direct baseline to start from, but this process will be integrated into a larger system which is already working and under the control of the authority sponsoring the new process design (thus the “internal” energy source designation). 

Examples of this type of project would be to design the deployment of an entirely new product line, or create a new R&D process under a newly acquired budget. Even though these processes are built from scratch to meet a new business objective, they must be considered within the context of the business environment they will be integrated into. In this sense, there is still a baseline, but instead of it being a baseline from the existing process it is more about the background information around resource inventory, set of cultural constraints, and empirical records of process design work principles that have succeeded in the past. 

This is an important distinction, and just as you increase your chances of success in process improvement by leveraging the working reality of a legacy process, you strive to leverage as much as you can of the parent as-is structure that the new process will eventually fit into with the same logic: leverage the as-is environment to whatever extent possible to reduce the risk of unrealistic process design. 

By now the logic pattern should be emerging: base your process design in what already exists to the highest extent possible to mitigate process deployment risk. So what about processes that are new and seemingly have no existing structure to anchor them (such as a brand new start-up company)? 

In this case–the third scenario–the ask is to design a process that will be powered by an external energy flow (i.e. the outside labor and customer market) that is not under the control of the person sponsoring the process design (i.e. startup founder or venture capitalist). In this case, the as-is baseline is embedded within the market itself, and the principle of process design foundationally remains the same. 

Whatever value the process is meant to bring to the market, the as-is can be found where instances are happening already. The deployed version may not be 1:1 or bundled how the new process proposes it be done, but if there is a market for your proposed process, then the value is being demanded and consumed in some form from the current market, and there are resources and labor being used to create the supply. In this case, the “as-is” baseline to bring into the process design is in the form of educated market research, based on the concepts we just covered. Finding where the as-is process is available for review within the existing marketplace and figuring out how it can be captured (as much as possible) will ensure that a brand new process design is feasible.

If you can keep those three scenarios differentiated and know where to look for design foundations before you start creating documentation, it will greatly increase the likelihood of design success within process work. The Cavi Method highlights the universal need to identify an as-is baseline, as no process will be integrated into a vacuum without other processes already in place. Knowing how to create the right structure for process design to succeed is largely about understanding the universal objective and patterns that are demanded of all process design work, and being appropriately aware before jumping in with a blank piece of paper. 

Process design is a complicated thing to do well, and this post is the tip of the iceberg in terms of mastering design work. If you’re interested in learning more about effective process design, please engage with our other blogs and resources, leave a comment, or reach out to us directly at info@caviconsulting.com.

—-

Are you enjoying our blog? If so, please subscribe to our mailing list where you will get updates about free and/or beta knowledge products as they become available. Thank you for reading!