Site icon Mark Mullaly

Embracing “It Depends”

It should be relatively evident from my last few articles that I have little tolerance for irrelevant, inappropriate and—above all—cookie-cutter attempts to implement process. This isn’t just wrong, but is—in my view—entirely dangerous. It’s also wasteful, inefficient, and frustrating for everyone involved.

So what’s the answer? In case that wasn’t obvious, this would be “it depends.” As I’ve acknowledged, that’s a frustrating answer. It’s one that many people don’t like, because it’s vague and imprecise and leaves a lot open to interpretation. And it is an answer that immediately leads to a far more exasperated question: “Okay, Mr. Smarty-pants. What does it actually depend on?”

So glad that you asked. But before I answer, a little bit of explanatory background, illustrated by a story. Stay with me here, though, because it’s extremely relevant, I promise.

A lot of where we get tripped up and confused by process—and the appeal of concepts like “best practices”—is in how they are described. Take project management. There are standards out there for managing projects (not just from PMI, although that would be a noteworthy example). And there is a lot of marketing rhetoric around those standards. They are described as “world leading” and “essential” and “broadly accepted.” Yes, they are even referred to as “best practices.” The implicit implication is that if you are not using them, and using them as fully defined, you’re doing something wrong.

Yet what we’ve lost sight of is where those standards actually come from. In fact, most of us have lost sight of where project management practices in general came from. And the answer isn’t that far back in time. Depending upon who you ask, modern project management traces it’s history back only about sixty years or so. Dupont developed techniques to deal with the management of large-scale plant turnarounds, and the US Department of Defence was experimenting with how to deliver the Polaris nuclear missile submarine platform.

Both of these efforts drew on some of the best management minds available at the time (Rand and McKinsey are often mentioned) to help develop new management approaches. What emerged weren’t simply pre-defined solutions, however. They experimented. They tried things out. What worked or seemed promising, they kept and expanded upon. What didn’t work, they threw away. What emerged, over time, were techniques that we now recognize as the heart of modern project management (including the critical path method, PERT and earned value management techniques).

What we’ve become fixated on here is the results. In essence, the presumption is that because these techniques worked in a particular context, they should be relevant and applicable in other organizations and other contexts. That was also one of the driving motivators of the founding of PMI. They sought to promote more broadly the techniques and practices that were pioneered during this period.

We’ve forgotten about the process of getting to the process. The experimenting. The learning. The adapting. The trying of new things to see what works, and continuing to adapt and refine. Process isn’t something that is parachuted in wholesale. It is does not start out complete and perfect, and does not remain static and unchanging. It needs to work in the context of where it’s being applied.

Going back to the experiences in Dupont and on the Polaris program, what was implemented was appropriate for the time. Both were staunchly formal, hierarchical, command-and-control organizations, in an environment where subordinates were pretty much expected to deliver on the expectations of their superiors, without question, challenge or opposition. The techniques that emerged supported and responded to this. They reinforced top-down direction and—even in work that had risks and challenges—presumed a level of predictable, planned and deliberate definition and execution of work. It was all about planning the work and working the plan.

Now, if you work in a top-down, traditional, formal, hierarchical, command-and-control organization, there might still be a lot of modern project management that appeals. But even then, you’re going to have to adapt it. If your organization doesn’t resemble the US military during the Eisenhower era, however, some larger modifications may be relevant and useful.

This is where we get to “it depends,” and figuring out what it actually depends on. Put simply, if we are going to implement process that works, it needs to be relevant. It needs to be useable. It needs to be appropriate. It needs to be understood. It needs to be valued. And it needs to be actually used.

That doesn’t tell you WHAT the process should look like, of course. And that is—being entirely honest—what drives most of the frustration with “it depends” as an answer. When appropriate process is contingent, there are no simple guidelines or clear prescriptions. It does, however, define the success criteria of what good process actually looks like. That is going to be different in each case, however. But the answer needs to conform to those expectations, or it simply isn’t going to work.

In determining appropriate process, there is a lot of judgement and consideration required. There are a lot of options and opportunities to be explored and worked through. We are adapting and experimenting. We are figuring out what works. We are returning to the principles of where process comes from, not simply relying on the results of someone else’s exploration.

Which brings us to how we get to figuring out “it depends” and determining what an appropriate solution—for us—actually looks like. What I’m sharing here is my approach to thinking through this process. That’s not to say that it’s the only way of getting there, either. But it’s one that has worked—consistently and reliably—for me in guiding organizations through a conversation about how they manage, and determining how they can manage more effectively:

There are a lot of people that don’t like “it depends” as an answer. I get it. It’s easier to look for simple and beguilingly precise answers. It’s easier to go with what others have done. It’s easier to go with “best practices,” which—as we’ve discussed—usually aren’t. And that’s the problem. Simple solutions, appealing as they are, don’t make meaningful differences when the problem is complex change. Contextual answers take a lot more work. They require a lot more effort. But in the long run, they are the only things that actually make a difference.

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.

Exit mobile version