If it isn’t excruciatingly obvious by now, I do a lot of work with organizations into define and improve their practices. This is particularly true about how they manage the evolution of stuff (that would be a technical term). Defining strategy, delivering projects, managing change and the other messy work that doesn’t fit under the umbrella of “doing the same thing over and over again.”
Perhaps not unsurprisingly, I have biases about what that should look like. Those biases aren’t specifically grounded in how I like to function, but in what actually works for getting people to collaborate in a relatively similar manner. Process for the sake of process is to be avoided. Bureaucracy for the sake of bureaucracy is to be discouraged strongly. And whatever does get implemented needs to respect—and align with—the culture of the organization.
Even more important is how you get to process. You can’t start with a blank page and design from the ground up. You need to recognize what is there, and build on it. Identify the components that exist and that work, and enhance them. Identify what doesn’t work, certainly. But start from what does. Consult broadly about how people think about and approach their work. Incrementally move from there, tending towards something that solves their problem and helps them move forward.
That’s all well and good in theory. And it’s hard to do. As I’ve written about before, there is a widespread opinion that you can just mandate and require process changes. That if senior management says “make it so” people should just line up and do what is asked of them. This worldview assumes that process change involves publishing something that tells everyone what they need to do, with the expectation that everyone will immediately comply.
To be clear, the “process as edict” approach doesn’t work. Or, to be more precise, it works in very limited contexts where there is follow-up, enforcement and imposition of meaningful consequences. People will comply with imposed process, but only to the degree that they are watched and any failure to comply results creates outcomes they don’t want. As soon as someone stops looking, or enforcement stops, behaviours go away. In the meantime, skilled and valuable resources find other, more attractive environments, and leave.
I’ve written about unreasonable process—and unreasonable expectations—before. That’s not what this post is about, though. It’s actually about something more insidious and challenging in managing process change: what happens when even reasonable expectations don’t get complied with. It’s an exploration of what happens when useful, relevant, meaningful and well-designed processes don’t actually get followed.
An interesting example of this showed up in a recent assessment project I was conducting. The organization had been working to improve its project management practices for some time. And arguably, they had made a number of meaningful and relevant steps to do so. There journey had started several years earlier. They had evaluated the practices that existed at the time. They had consulted with people involved in doing the work. They had designed and tailored practices that fit and were relevant for the organization. And they were in the process of implementing a software package to manage their overall project information in a collaborative way.
In terms of execution, what this organization was doing should have ticked all the boxes. They had an approach that was designed and tailored for them, the people that would use the process had an active role in shaping it, and it was being supported by templates, tools and practices that made sense and were appropriately scaled to the work that the organization did.
The only problem was, they weren’t really being utilized. People knew about the process, they were aware that it existed, they understood what was required. They had received enough training to know what was expected, why it was relevant and meaningful and what using the process meant for the success of the organization. And yet, people largely continued with their own personal and personalized ways of working. They didn’t make the change, even where doing so would have solved meaningful problems and enhanced how everyone functioned.
The fundamental question to answer was: Why?
What was missing? What was getting in the way of people taking on an approach that made sense, that they had been consulted about and that they had contributed to designing? Why did something that on paper had a great deal of support in actual practice have virtually none?
Understanding what was going on was a challenge. There wasn’t an immediately obvious explanation for the behaviours that were being exhibited and it required a lot of digging to figure out. And the answer raises some important implications for how we think about organizational practices, and how we try to use them.
Part of the reason this was difficult to sort out is that, on the surface, everything seemed reasonable. Ideal, even. Or at least, as close to ideal as anything can be when dealing with something that looks like organizational change. Project managers knew they were managing projects. They acknowledged they had a role to play in doing that. They could speak to the process and how it had been designed (and the role they played in contributing to it). They acknowledged the training. And they knew what they were supposed to be doing.
In fact, they were highly nuanced in how they described the process. You could hear an answer that stated, “The process says that this is what we include in a project plan.” Or, “When building a risk management plan, the process calls for an assessment of probability and outcome, and each risk is expected to have a mitigation strategy.” It would be incredibly easy to take that at face value, and presume that’s what they did. When pushed to clarify as to whether or not they followed the process, however, the answer was, “No.”
Instead, everyone had their own way of approaching projects, that was largely an extension of how they had always been involved in projects. Schedules might be no more than a photograph of a meeting-room white board. Budget status could be—and often was—a running tally of invoice amounts on a piece of paper pinned to a cubicle wall. Status reports might be an email narrative of what was going on—if you were lucky. Often they were nothing more than a verbal update. They knew what they were supposed to do; they just didn’t actually do it.
This got even more confusing when senior managers were interviewed. They, too, acknowledged the process. They recognized their role within it. They could articulate what was expected, and why. They discussed the importance of projects to the organization, and how the project management process had evolved. So far, so baffling. But the first glimmer of insight came when talking about how they responded to project updates.
In a word, they didn’t. They got updates. If something was going seriously sideways, they would intervene and respond to the issue. And apart from that, they pretty much let the project do its thing. They trusted the project managers to deliver their work. They got involved in their projects only as much as necessary, and no further.
Some context about this organization might be appropriate at this point. They are a young organization in terms of projects. They are fairly progressive, fairly entrepreneurial (especially given their industry) and ambitious in the projects they take on. They make some choices about what they do, but not many. And even though they start the year with list of theoretical project priorities, that often gets added to. The expectation is, “get it done.” And, remarkably, they’ve got a pretty good track record of delivering.
The challenge is that they don’t have a terribly good track record of managing. Projects get delivered late. They go over budget with some regularity. What gets delivered gets qualified based on what becomes possible, and revised downwards when necessary to make sure something can be delivered. They produce results. Just not always the intended—or complete—results.
It took me a while to build this picture. And it took me a while longer to make sense of it. What was particularly confusing was seeing the investment made in developing and enhancing practices—and the collaborative nature of how those had been built. The expectation in such a situation was that people would use them. While that’s often not true in organizations where process is imposed, it’s pretty rare to see in organizations that have made the effort to tailor and adapt them, and to build something that can work—and work well.
And yet, here was an example where this was exactly the case. While it took further digging to figure out how this state of affairs came to be, figure it out I did. And what was playing out was—in retrospect—relatively clear. It was simply unexpected.
The organization knew projects were important to their overall success. They had come to appreciate the relevance of project management in helping to make projects successful. They knew enough to say project management would be useful, and were aware of their culture enough to know that parachuting process in from the outside would fail.
What was also true, however, was that what the organization valued above all was delivering. Not delivering perfectly. Not delivering to schedule. Not fully defining and delivering scope. Success was about saying you were going to do something, and being able to turn around at the end of the day and saying you delivered on that commitment. And the nuance lay in exactly what that commitment represented.
It might be reasonable to assume that delivery was about delivering the right solution, or the right value. It might be equally reasonable to assume budget and schedule were the yardsticks of choice. But what ultimately mattered, pure and simple, was accomplishment. We said we would deliver “x” and we successfully delivered on something called “x.” We ticked the box. What was inside the box was less important than whether or not the box could be checked off.
The consequence of all this was that “get it done” mattered far more than “get it done well.” And the further consequence was that implementing project management became another thing that got done. They started well. They took a reasonable approach. They were able to ultimately able to tick the box next to “implement project management” and say it had been accomplished. But they didn’t follow through on “use what we’ve built.”
This was the cultural value that was most understood by the people that were there, but took time for someone from the outside to understand. Results matter more than process. And while we can talk about process, and create a solid perception that process is importance to us, if we don’t ultimately pay attention to using process, we’ll revert back to what we know.
That also says a great deal, though, about how process is implemented, and how it is reinforced. I started off by saying that even bad process can be enforced if someone is watching closely enough. This is not in any way to recommend that as a strategy. Even good process, though, requires oversight and support. We need to care. We need to ask questions in the context of the process. Managers and executives need to lead by example, setting expectations that the process be used. And above all they need to follow up when it is not being used.
We pay attention to the things that matter. We engage in the practices that we care about. It’s not enough to say a process is important. We need to demonstrate its importance. We need to follow through with action. And where we demonstrate inaction, we also deliver a very clear message.