As most of you are likely aware, I’m a bit of a process geek. Actually, I’m a lot of a process geek. My career (astonishing as this might be) has been pretty much dedicated to developing, optimizing, improving and assessing process for many organizations. That has included the development of processes, guidelines, policies, templates, checklists and tools for numerous organizations.
At the same time, if I’m completely honest, I’m not a giant fan of process. That’s particularly true when I encounter and am required to use the processes of organizations that I’m managing projects for. I often find them unwieldy, bureaucratic and unnecessarily complex. That often leads to a questioning of why the process wants what is being asked for. Occasionally, it raises fundamental doubts as to whether what is being sought is in any way valuable or useful.
This prompts a semi-serious question: “Am I just a process snob?” Am I in love with my own processes, while critiquing and resenting those of others? I would like to think the answer is no. I get that process—when done well—provides useful guidance and sets expectations on what should get done and why. At the same time, my continued frustration with it is frequently applied raises some interesting challenges about how process is implemented, how process is perceived and how process is responded to in organizations.
To clarify, when I’m talking about process, I’m essentially talking about “methodology.” The practices, capabilities and definitions of how we manage large, complex undertakings. For example—and what is particularly relevant for me—definitions of how projects get managed and delivered.
Operationally, it’s a bit of a different world. Operations management—and that is its own discipline—has fundamental objectives of consistency, repeatability and the reduction of variation. The goal is to do the same thing, the same way, day in and day out. That is the essential basis of operational efficiency. It’s how we get to quality and conformance.
In a project world, process takes a different focus. We are managing complex changes. The very definition of projects is that they are unique. They are not, for the most part, repetitive. It’s the rare organization that does the same kind of project over and over again in exactly the same way. For most organizations, project are different and varied. So when we start to talk about process, a key question is how consistent actual practices can actually be.
Project management processes as implemented often have the expectation of rigour, formality and consistency. To a very large extent, that’s exactly the sort of journey we are signing on to when we commit to improving the “maturity” of our organizational practices. Maturity, in essence, assesses the degree to which process is formally defined and uniformly adhered to.
The open and essential question, however, is this: exactly how much process—and how much consistency—is actually appropriate? With a speedy follow-on question of: and when does process start costing too much, and stop delivering sufficient value to make it worth while?
We know, intuitively and empirically, that the law of diminishing returns will kick in at some point in every organization’s process implementation. Prior to this point, investments in process see corresponding returns in value. After this point, every investment made in increasing the structure, rigour and apparent bureaucracy of process results in comparatively less value. From here, we can invest all we want, but value doesn’t go up. In fact, for many organizations, it declines.
What’s interesting about this is that while we may recognize the truth of this in theory, we are often enormously bad at responding to it in real life. Probably the most extreme example of this was in one of the case study organizations that was included in the Value of Project Management study. An one engineering company, their practices had evolved over the previous twenty years. During that period, the documentation of how they managed their projects grew to no less than 10 four-inch binders of documentation. We’re talking four linear feet of process (and no, I’m not making this up).
The problem with that much process on paper is that it doesn’t actually get followed in real life. What people do is what they remember—or believe that they remember—about the process, not what it actually says. The results is less rigour, and substantially less process, than what is implied or believed to be the case.
What’s astonishing about this example is how long it took the organization to come to the realization that its process as defined was getting in the way of its process as practiced. In fact, the answer to declining process adherence was often the introduction of more process. It was only comparatively recently that the organization invested substantial effort and time (more than 20 person years of effort, drawing on their best project managers) to distill their former process down to no more than one three-inch binder of documentation.
An inherent challenge in developing and implementing process is that it is comparatively easy to ask for everything. It’s often significantly harder and a lot more work to comply with everything that gets asked for. A major challenge of process designers is finding a balance, of getting process “just right.” Too complex, and it doesn’t get adhered to; too simple, and it produces no value.
An example I’ve used before, but is relevant here, is a relatively small project I was managing for a client. In the proposal, we had described how we manage projects like the one we were conducting. We are advised at the kick-off meeting that we would need to use the status report template provided by their PMO. A quick review of the template revealed the following: the template alone ran to five pages, required cost information to be broken out two different ways, required effort information to be broken out in three different ways and implicitly required the use of earned value management. A follow up question revealed that they used to explicitly ask for earned value to be used, but people complained; their solution was to remove the references, but leave the information requirements unchanged.
All of this to say that status reporting was more than a little burdensome. It took between three and five hours to complete each status report, and required a substantive change in how I normally approach managing projects to do so. A project that had a total effort of about 300 person hours grew by 65 hours (with a corresponding scope change request) simply to comply with the status reporting. And, based upon the questions that I received—where were exactly none—I’m not sure that any of them were ever read. Process was complied with, but largely for the sake of complying with process.
This is exactly the sort of imposition of requirements that agile proponents talk about when they complain of deliverable-intensive, “high ceremony” projects. And they’re not wrong. But that’s not to say that process itself is bad. The challenge is often in how we develop it, and how we apply it. Good process needs careful thought in terms of what it requires, what it produces, what is valued and to what extent actual value is—and can be—realized.
In simplest terms, process needs to be appropriate. It needs to be suitable and reasonable to the task at hand. This is not an ideological question of linear, iterative or agile processes; the nature of what we are managing should drive and determine which approach makes most sense. This is also not a question of consistency simply for consistencies sake. Consistency has value when it supports better adherence or makes reviewing documentation and finding information easier. But flexibility and adaptability is also necessary. We need to be able to make adjustments to best realize results and deliver value. In a project world, that often means that the process that is needed depends on the situations and demands we find ourselves faced with.
Finding the right balance between defining process expectations and allowing for flexible adjustment is critical. IMaking the process easier to use typically makes the job of the process developer that much harder, in that we need to give real consideration to where, when and how value is being delivered. We need to be incredibly sensitive to when the law of diminishing returns might just be kicking in. And we need to resist the urge to ask for everything, just because we can.
When good process works, it works very well. It’s seen as helpful and useful, as a way to get things done more effectively. Bad process, by contrast, typically just gets in the way of everything and everybody.
Over the next few weeks, I’ll be getting in to these themes in a little bit more detail. I’ll look at how and why we build the processes we do, what works and doesn’t work, and what makes sense in making process useful, constructive and meaningful.