Basics: The Dark Side of Process Architectures

Don’t get caught up in these process mistakes.

Almost all human endeavors use a process architecture.  Some of those architectures might not be immediately apparent, such as the scrum that often occurs at the beginning of a foot race or software development in a two-person start-up.  Others, such as the product development in the medical device fields, are far more regimented.  A mantra that many leaders in the software field utter is: “that we should only define just enough process.” It is easy to cobble together a process architecture that leads to common problems.  It isn’t that anyone goes out of their way to make a mess out of process architecture, but it happens far more often than anyone would like.  Common process architecture faux pas include:

Process Plaque: Over time this affects most of the components in process architectures. Process build-up is a condition caused when teams or organizations encounter new scenarios or problems. The natural impulse is to make process changes or to add new checks so that exceptions or problems does not happen again. While the goal is to avoid the potential for a problem,  often no one considers the probability of the same condition happening again.  The build-up in the amount of process that these changes generally cause is slow and evolutionary, therefore not recognized.  This is exactly like plaque build-up in your arteries. How many bratwurst do you have to eat before the blood in your arteries slows to a crawl? More than a few. Review every process change to ensure that they are solving problems based on impact and probability of occurrence (risk).  Remember that the best practice is for the process architecture to address normal circumstances and monitor for those scenarios that are out of the ordinary.

Mismatched Principles: Principles guide the way that people actually do their work.  Principles are a synthesis and expression of a person’s worldview.   Models, frameworks, and sometimes methodologies explicitly espouse a set of principles to help guide practitioners.  Examples are in the Agile Manifesto, SAFe is a set of lean/agile principles and the principles in the CMMI.  When principles in one part of a process architecture are at odds with the underlying principles in another, people can have problems trying match behavior. For example, if the part of your architecture is built on the principles of repeatability and process consistency (i.e. CMMI) and another portion on process flexibility (i.e. Lean Startup) there is a high probability for disagreements. Organizations in this scenario usually put an additional  step in place to adjudicate conflicts.

Culture Wars: Culture clash is a typical variation of mismatched principles that occurs at a broader organization level.  Some organizations have cultures that favor the use of one framework or method over another. For example, organizations with a hierarchical culture tend to have trouble adopting Agile Methods which promote flat, self-organizing teams. In the short term, the two “safe” ways to deal with culture are to adopt a process hierarchy that supports the culture or to hybridize the architecture, not to challenge the culture.  The unsafe approach is to wage culture wars.

Process Addiction: Occasionally teams or organizations confuse the goal of a piece of work. The goal becomes the performing the process rather than delivering value. Cutting teams off from a real product owner or customer can cause the team not to understand the value of what they deliver, and therefore, fall back on the process as the only marker of success.  Stakeholder or product owner roles need to put in place and be performed by individuals connected to the business.

Process Police: Enforcement of process performance can sometimes take center stage.  This type of issue tends to occur in organizations working on a certification that is not tied to output value but is tied to bid process.  A better process architecture would link both values in the sales cycle with delivering value to the customer. Another scenario that generates process police is an organization where the fear of making a mistake is a major motivator. Process police are tools to ensure that process consistency occurs.  Creating a process enforcement mechanism an instantiation of the belief a good process will substantially increase the likelihood of a good outcome. This belief may be true in manufacturing but is often assumed without proof in knowledge work. 

No one builds a model, methodology or processes to slow the delivery of value.  Nor are they built, at least at the beginning, to generate a cadre of bureaucrats to oversee those building and maintaining functionality.  Rather, process architecture problems tend to creep in after the fact as mismatches between the organization’s culture and the process architecture’s components are discovered.  On a positive note, friction generates the energy need to create change.  The goal must be to ensure that, as change occurs, the overhead that the process architecture levies do not lead to less efficient and effective delivery of value. Time is not a friend of any component of the process architecture unless it is constantly tended to keep it will drift and expand.