The Ideology of Process

I’ve been thinking about—and writing about—process for a very long time now. I’ve explored what makes good process. I’ve decried what I view as bad process. I’ve advocated for sensible, sane and practical approaches to designing and implementing process. In all of that, I have talked around but have surprisingly not tackled head-on a fundamental consideration of how process gets designed, built and implemented: the mindset and personality of the people doing the work.

Why this has taken so long is a genuine curiosity. Process doesn’t happen by accident. It doesn’t magically appear. Once it exists, it evolves, sometimes in surprising and unpredictable ways. But the actual bringing of process by any name—methodology, framework, guidelines, procedures, policy and more—into the world is a product of design and intent. It is the work product of individual people.

It takes a certain mindset to be attracted to process work. I should know; I’ve been doing that work for a very, very long time now. What has been interesting to observe is how much my own perspective and attitude has shifted over the decades since I started. It says a lot about who I am now, but it says as much or more about who I used to be—and the truths I held as self-evident—early in my career.

My entire career—as a consultant, and before—has been in support of organizational change. Every position that I have held since I left university has involved being a “change agent,” whether that role and expectation was express or implied. It’s interesting to explore why that particular work appealed. There has always been a drive to improve things, to help make them better, to solve problems and build and implement new capabilities. That ambition and interest existed at the outset of my career, and persists to this day. What has evolved is my sense of what a good solution looks like.

Many of the processes that I was involved with early on were tied to formal methodologies. (For the curious, “methodology” is a fancy term for “formal way of doing things documented in great detail across multiple binders”). An early example of this was being hired as an analyst within a project management office in the early 1990s (so ahead of that organizational trend curve) to implement a methodology called STRADIS. This was a data-driven means of systems development originally developed by Chris Gane and Trish Sarson (yes, THAT Gane and Sarson) and licensed by the McDonnell Douglas Corporation (yes, THAT McDonnell Douglas; please don’t ask why an aircraft company was selling software lifecycles, because I haven’t got a clue).

The out-of-the-box methodology (and it came in a big box) spanned approximately ten 2-inch binders. My job was to help tailor and customize it for use within this organization, and to design a project management structure by which development projects could be managed. This is the kind of meaty and juicy work that I revelled in at the time. A big, complex problem with lots of detail and structure and nuance to manage. Of course, the starting point was already big; that was a lot of manuals. We can all guess where it went from there.

What was not clear to me—and arguably I don’t know the answer to this day, although I can certainly make educated guesses—is why this specific lifecycle was chosen for this organization. While further speculation is possible, I also don’t really have a sense of what problem this methodology was intended to solve. My first day on the job I found the binders on the desk in my cubicle, and my marching orders were to make them work.

Implementing process is often a response to problems and challenges. Failures have occurred or difficulties have been encountered. Current practices are viewed as too formal or too lax or without sufficient structure. Inconsistencies exist, lapses in requirements occur and activities that are viewed as important don’t always happen. For anyone who is in any way conversant with organizational life, so far so normal. There are processes and procedures that are informally followed or liberally ignored in just about every organization on the planet. As long as those processes aren’t deemed important or essential, they are allowed to continue to slide. The challenge is what occurs once someone decides that doing the right thing the right way (or at least better than it is right now) is actually necessary.

In the case of my early adventures in adapting methodology, that decision had absolutely been made. Where this goes from here is inherently predictable: things get more formal, more detailed and more robust. Rigour gets introduced, standards are created and compliance is expected. The result is something that is logical and structured and provides clear expectations of how things should and will be done going forward. Process of this sort very often gets written as a set of detailed instructions and guidelines of exactly what is to be done, and how, and with what specific outcome.

What often gets overlooked in all of this is the personality and mindset that goes along with doing this kind of work. Designing methodologies, processes and frameworks is structure and detail-oriented work. There is a theoretical flow-through of action, information and logic from the start of the process to the finish. Everything that is there should be there for a reason, and everything should connect to everything else in a way that is logical, ordered and structured.

The people doing this work tend to like order and detail and structure. They are often perfectionist by nature, and want things to be objectively correct and logically sound. People who do this work value formality and clarity. They like neat boxes and tidy structures. They arguably crave rigour. They are unlikely to see what they build as bureaucracy or bloat so much as the right amount of detail to do the job perfectly every time. As a consequence, the processes that they produce often parallel these tendencies. Lots of discipline and definition, with everything in its place.

The important thing to recognize is that there is a lot of “should” behind this. There is an orientation of the designers towards defining what others should do. There is an orientation of the processes that outline everything practitioners should do, if they are truly doing things properly. They prescribe practices and pronounce expectations, with a view that everything should be considered and very little is optional. Even where models attempt to provide adaptive guidance for different sizes or types of projects, the bias is often to more, not less.

An internal consultant at a recent client exemplified this reality. He was responsible for the implementation of a corporate framework whose impact would be felt throughout the organization. He had a great deal of expertise in the subject matter the framework was based on, but far less familiarity in terms of the organization and its culture. The framework that he was designing was intended to be as robust and mature as possible. This also meant that it looked very formal, rigid and bureaucratic. 

The reality is that it the capability being implemented was all those things and more. It was a solution that would work for an organization much larger than the one in question. It was without question overkill. Worse, however, was that it didn’t fit the culture. It was not designed to be used or usable, but to be objectively “correct.”

The basis of this determination of “correct” is an important thing to explore all on its own. What gets perceived as the right way to do things is often the most formal, as interpreted by standards or erstwhile “best practices.” It is making sure that all the “i”s are dotted and the “t”s are crossed in all possible eventualities. It is about making sure that what is implemented and done is unassailable. There should be no question of correctness, no audit should find it wanting and there should be no recourse for someone to come back and suggest that corners were cut or standards were in any way relaxed.

There is a mindset that goes with this perspective as well. As mindsets go, it is a potentially dangerous and almost certainly expensive one. It is a view steeped in two independent but related dimensions. First, there is a perceived right way to do things. This mindset also holds that there are many wrong ways to do things, which generally tend to reflect any approach that compromises or diminishes what is deemed as formally perfect. This second dimension is one of risk aversion. This is not about adapting to objective risks that the process will encounter, however. It is about avoiding all potential risks of criticism or of the process being found wanting or in some way substandard. It is personally avoiding the risk that their work might be judged and found unacceptable.

I would be lying if I said I haven’t been guilty of adopting this mindset. I have inflicted too-cumbersome processes on organizations early in my career. Under the guise of structure and formality and constructive guidance, I have produced processes that were larger, more detailed and more bureaucratic than they needed to be. Fundamentally, each one of these methodologies led with process rather than purpose. They focused on what was logically correct, not what was practically reasonable.

Once you start to recognize this truth, you begin to see it everywhere. In part, this is because it is promoted everywhere. There is unfortunately precious little process guidance to do what works, what is reasonable or what is appropriate. Few are brave enough to say “start with nothing, and add in only what makes sense to get the work done.” Processes developers and practitioners both fear the consequences of being challenged on such choices, and opt to include far more than is necessary.

These assumptions are embedded in the language and structure of maturity models as well. The earliest maturity models were designed as constructive tools of supplier assessment, designed to help vendors provide better solutions to their largest customers. I saw the value of such an approach when I built one of the earliest project management maturity models, back in 1996. The very use of the term “maturity,” though, implies rigour and structure. The levels of maturity create a language that says more is always better. No matter how much guidance I provided around identifying the level that is appropriate for an organization, the default tendency is to want to shoot for the top of the model. If you aren’t Level 5, do you even manage?

The other more insidious quality of maturity models is that what all levels of maturity value most is consistency. They expect repeatability and conformance. This feels like an unassailable logic. It very reasonably extends the underlying principles of ISO 9000 quality management guidelines, where you are expected to say what you do, and do what you say. In an operational context, variation is very bad indeed; reducing and eliminating causes of variation is the very essence of total quality management. 

In the context of projects, however, variation is inevitable. It is neither possible nor reasonable to manage every project exactly the same way. That organizations try is unfortunate, but unsurprising. Projects are by their nature different. Many types of projects are done within individual organizations. Project needs will vary depending on the kind of project it is, how big it is and how complex the challenge to be managed. Process should also vary based upon how big the team is, and how visible and transparent process needs to be as a result.

I manage very large projects with very little structure and rigour when I’m the one doing all—or at least most—of the work. Process grows when I need to involve others. It gets enhanced further when there is an on-going expectation of transparency and reporting to a client (not usually a given, to be perfectly honest). It grows exponentially as more people are added, and there needs to be greater understanding of how the work and the team members interrelate and interact. 

All of this has served to evolve over time how I think about and approach process work. My emphasis is now very much from the outside in. To start with what already exists, and to understand why it is there. To build on what works, and not start over from scratch. To understand the problems, and collaboratively identify possible solutions that would make a meaningful difference. To understand the culture and what can be accepted. To understand the people and what will make them successful. To design process that allows people to see them being more capable of delivering results well than what they have in place today.

It is a different orientation to design process for people, rather than perfection. It requires a different mindset to do that well. There is a need to be ever mindful that in everything you define, you are imposing requirements that you are asking people to comply with. There needs to be good reasons and good rationale for everything that you build in. There needs to be appreciation for what people require and empathy for what will help them and what will be distracting or overwhelming. Process needs to be as simple as possible and no more complex. It needs to be as easy to use as possible and no harder. It needs to ask for what is essential and absolutely no more.

It is possible to design good and relevant process. It took me more time than I would like to admit to make a shift in my own perspective of what that looks like. Doing so started with a shift in mindset first, and practice afterwards. Our orientation and attitude to the process that we build and the people that will use it fundamentally shapes what will result. Design from a perspective of caring, and I guarantee you will get results that matter and make a difference.