Change Is About Creating Language

Words are important. Words are powerful. Words are, in fact, political.

How we describe something has a great deal of influence on how it is perceived. We can convey judgement, support, criticism, caution or conjecture. The words we use can show we buy in, or that we oppose. They can indicate that we are all-in committed, or that we are on the fence. We can be clear, we can be weaselly and we can waffle.

These statements are true regardless of context, but they become particularly relevant in the context of change, and particularly organizational change. When we address and deal with change, we are trying to alter actions, behaviours and habits. We are working to get people to shift from their current state and move to a new, different way of operating. We are trying to shift minds. And shifting minds means shifting the words we use and the language we employ.

Where I’m going with this is not that we need to watch what we say, and carefully frame our arguments for change so that they find a receptive (or at least, not hostile) audience. Arguably, this happens a great deal. Personally, I think we need a lot more honesty and candour when we are contemplating change. We need to acknowledge what we are asking people to do, and the consequences—both positive and negative—that will be experienced in making the shift. But that’s a whole different argument, and one I’ll save for another article. What I mean here is that language actually helps us to create the change. Part of how we create meaning is in the identification, selection and shaping of the words we use to describe the change we are pursuing.

Take the development of a new process. As most readers know, I’ve spent a significant majority of my career supporting the development and implementation of organizational practices, whether that’s about project management, strategic planning or the spaces that exist in between. I’ve seen a lot of what works, and even more of what doesn’t work.

One of the most significant practices that doesn’t work is the wholesale implementation of process from outside the organization. Parachuting in a process from somewhere else, whether a purchased methodology, an adopted standard or an imported practice from a parent organization, is routinely doomed to fail. It simply doesn’t work.

One organization I’m aware of went through three successive implementations of project management practices in five years, each one imposed by a new corporate parent after an acquisition (they got bought out with astonishing regularity). Every single time, documents were released, training courses were held, change was championed, and the implementation failed.

The reason these implementations fail isn’t just about resistance or obstinance on the part of staff (although, depending upon how the change is managed, that can certainly be a factor). The issues go deeper than that. Practices from outside aren’t seen as relevant. They don’t understand context and culture. Aspects—and sometimes whole components—fail to support what the organization needs. Sometimes, it’s because the practices are overly bureaucratic, while in other instances they don’t go far enough. In virtually all instances, they are sufficiently unworkable to be rejected fairly quickly.

Organizations that develop processes that do work is utilize extensive adaptation, customization and tailoring. When processes become their own. Where this is the case, practices are seen as not only proprietary, but essential sources of competitive advantage. They are valued, embraced and defended. Most importantly, they produce results.

Part of this customization, and one that doesn’t necessarily get a lot of attention, is the words that are used to label, describe and define the process and its component parts. The names that are attached to stages, activities, steps and deliverables are incredibly significant. Getting them right takes an astonishing amount of work.

I was reminded of this as I’ve been working with an organization to help develop new project management guidelines. It has been an interesting challenge. The organization is a municipality, which means that they manage an array of project types. Everything from construction and engineering to events and the development of social programs occur under the umbrella of projects.

The challenge was how to create a set of project management guidelines that is relevant and appropriate for each of these project types. Stages and steps that work for everyone are required, and where every project type—no matter how concrete and specific or abstract conceptual—can be supported. Success means having every project able to see themselves in and relate to the process as defined. The practices need to be relevant and the ideas need to be relatable to the work of each and every project.

What that means isn’t just the work that is defined has to make sense. The labels that describe the work needs to respond to and support every project type. In an environment as diverse as a modern municipality, that takes a lot of work and effort, and no small amount of creativity, to make happen.

As an illustration of this, let’s take what would theoretically be a relatively innocuous term in a project management context: planning. To the average project manager, that describes the work you do after initiation and before you get to the messy bits of actually doing the work. To a manager in a municipality, however, that term can have a surprising number of possible meanings.

If we are planning in a municipality, there is certainly the possibility that we might be figuring out how to get a project done. We might also be addressing the development of a strategic, corporate or departmental plan. We might be sorting out the budget for next year. We also might be conceiving of the design of a subdivision. We could be developing policy regarding land use. We might be conceptualizing a new industrial park. We could be determining the intended use and programming of a new recreational facility. We could be designing the season of plays and performances in our theatre. All those terms are—in specific contexts, departments and roles—legitimate ways that “planning” is done in municipalities today. And I’ve probably missed a few.

The challenging—or amusing, depending upon your viewpoint—aspect of this is that, when seen from the perspective of any one of these specific roles, “planning” is seen as an entirely legitimate and very specific term. No further qualifier is seen as necessary. Shift your focus to the organization as a whole, however, and the term planning means many things to many different people. Someone implementing a project management practice that offers yet another definition of “planning” does so at their peril.

While this might be an extreme example, the point extrapolates to most organizations. A word that means one thing to one person can mean something entirely different to someone else. The result is that, particularly when we develop and implement a new capability, we need to be very conscious of the words we choose. We need to make deliberate and specific choices, be clear about our meaning, and test for possible instances of confusion or overlap.

What that means in practice is that we need to consult broadly on the words we choose, and how we choose to apply them. Going back to our example of a planning process, for example, simply naming the stages that describe how work progresses and evolves is complicated. Seemingly simple terms like “design,” “development,” and “implementation” can be interpreted vastly differently. If I’m going to use a process, I need to understand it. To understand the process, though, I need to relate to the terms being used. And if the terms stop being relevant, so does the process.

The result of this is that designing the project management guidelines for the municipality become an extended process of consultation. Just naming the high level stages of the process took several consultations over a period of weeks. The concepts each stage was intended to represent needed to be understood. The boundaries of where each stage starts and stops—and the results that move from stage to stage—needed to be clarified. Possible labels that might be applied to each stage were conceived. Tested. Rejected. Revisited. Revised. Tested some more.

The results of this exercise where both generic and specific, and in somewhat equal measure. The terms that were chosen ultimately had very specific nuance and meaning. At the same time, they were intended to be abstract and generic enough as to apply to—or at least be somewhat meaningful for—every type of project that exists within the organization.

There is still, at times, the need to clarify the expectations and intent of a particular term. There is the odd objection that a label isn’t specific enough. This is legitimate comment, but is also by design. The result, however, is that the terms that are employed have meaning and relevance to the organization.

What’s particularly important to recognize, though, is that one aspect of creating meaning was the design process that the organization went through that ultimately identified, defined and labelled each stage. The process of design and selection was actually part of what made the resulting terms understanding, appropriate and relevant. To an outside observer, what came out of the process might be entirely generic, and theoretically transportable wholesale to another organization. To an internal participant, however, those generic-seeming terms are imbued with specific meaning. The process of arriving at their selection is as important as the words that were ultimately used.

For me, this is a fundamental lesson of process design, development and implementation. As important as they are, it’s not simply the results that matter. The process by which those results are arrived at is equally important. Participating in the choices, seeing the trade-offs being made, testing for meaning and ultimately compromising and agreeing on specific labels is part and parcel of building good process. Skipping over this—or importing concepts wholesale from elsewhere—undermines this effort.

Words are important. The meaning of words is critical. And misinterpretation of meaning is what sends organizations, teams and projects off the rails. Taking the time to carefully consider and choose the our terms and assign them meaning is one of the most fundamental aspects of creating—and sustaining—lasting change.

Leave a Comment