CHANGE HOW YOU CHANGE
Distinctions Without a Difference
For years, analysts have reported that “projects” suffer a failure rate clocked at 2 out of 3 — or even 3 out of 4 — times.
Much of the related information provided in these reports goes into the causes of failure. Over time, more precise discussion begins to separate types of projects from each other, and types of failures associated with the differing projects.
But nearly all remind us that a frequent common flaw is the separation of accountability and authority within the operation of the project’s runtime. That commonality leads to clearly relevant advice about how to prevent (or at least minimize) the potential for project disintegration.
Flipping that coin over to its other side, those preventions and mitigations look like constructive advice. The idea is to “design out” these problems as part of “designing in” the progressively positive experiences and effects of organizing and behaving well. At the very least, this manifests as Planning.
Problem: since these points have been known for nearly twenty years now, with industry associations and certifications infusing the consciousness of most paid practitioners, why are the same failure rates still recurring year after year?
Things Are Not What They Seem
Not by coincidence, analyst reports on Change Management look frighteningly similar to those for project management. But correlation is not causation!
So it’s worth resisting the easy assumption that change efforts fail at the rate of project efforts BECAUSE change efforts ARE projects. Said a bit differently: if projects fail at 66% to 75% of the time, and we try to manage change as a project, then why would change management have any better success rate than project management?
This is a superficially clear idea, but we need to pull it apart and not let it further settle in. Presupposing that change management cannot get better until project management gets better is, at root, dedicating oneself to solving the wrong problem.
What is a project, really?
A project is, essentially, a micro-organization created as a temporary production unit authorized to act in a certain window of opportunity — that is, in a given time span. One thing worth remembering is that a project is supposed to go away.
The point of having a project instead of NOT having a project is to manage the relationship of resources to requirements. And the point of managing a project is to optimize the project’s ability to serve its purpose.
In the real world, activity occurs across a very wide range of variable characteristics, including variations in complexity, spontaneity, vector, intensity and persistence. If we did not have concerns about the effects and after-effects of activity that was occurring mainly without inhibitions on any of those characteristics, then we would not need management! We manage it precisely because we want to exert some degree of control over some — if not all — of those characteristics. The purpose of ORGANIZING is to bring predictable attention and accountability to exercising that control. This use of management is essentially a form of Engineering. So does that make the failure rates mostly failures of engineering?
It depends. All project failures tend to fall into one or more of three categories of “end result” flaws — the wrong deliverable, the wrong delivery timing, or poor production procedure. And the punchline here is that the Organization called “project” exists only to coordinate activity such that these three fundamental types of flaws do not occur at the point in time where the deliverable is needed from the project. It doesn’t matter whether the organization has only one member or 50 members.
One of the biggest risks to projects is that the passage of time features changes in the priorities of the party that is the primary intended recipient of the project output. Perfect execution of something irrelevant is, as we well know, a MARKET failure — and the “internal” market of the company or parent organization hosting the project is probably more likely to terminate the micro-organization than are the forces outside of the host. Think about it — projects in effect get Hired, and they may get Fired, and they may get Replaced.
Change Management is NOT project management.
There are two basic ways to think about Change, but each is understandable by contrast between what can occur with no deliberate influence on our part versus with our influence deliberately applied.
Before describing that, let’s look at the most important note of comparison versus projects: the point of Change management is NOT to control the relationship of resources to requirements.
And, although management applied in both Project and Change scenarios are openly sensitive to proactively handling Risk, project risk is rooted in an engineering perspective on production. “Change Risk” is NOT.
What are Change scenarios? There are two worth dwelling on.
In one scenario, conditions and circumstances are changing in some number of ways completely without regard to whether their current state at any moment is compatible with our Needs. What matters here is whether we are willing to “go with the flow” of these shifting variances, in real time, and we are NOT intending for these variations to go one way or another. In this scenario, the difference between “managed” and “unmanaged” is that in management we consciously leverage opportunity as it emerges from the variations. (This might be obscure to people who do neither art nor science, but luckily a lot of people do one or the other, even both.)
In the other scenario, we are intentionally modifying OR REPLACING a current state to resolve its incompatibility with a desired future state. The nature of this resolution is to alter the way prevailing circumstances are generated by existing conditions. Here, the difference between “managed” and “unmanaged” is that management brings a POLICY (a group of prioritized preferences and tolerances, not a procedure) as a framework for making decisions about exerting influence.
Given the differences above, it is evident that projects are functional whereas changes are cultural.
So what kinds of “failure” indicate flawed Change?
The most predictable places to look for impending or present failure are in the relationships detectable between interactions and values. These relationships should be modeled in a way that is observable and can be manipulated. Given a model, there are ways that interactions can be encouraged and composed, and there are ways that their effects can generate measurably beneficial impacts.
That points out ways that change can be deemed a failure:
· Change disconnected from serving a goal
· Change being influenced without an accepted model
· Change unsuccessfully influenced by the prevailing accepted model
· Change that generates no usable effects
Solving The Right Problem
Ultimately, both managed changes and managed projects are subject to some superior stakeholder’s acceptance or rejection. And that decision could rest on whether the stakeholder is satisfied with the type of change actually achieved. Was it a Capability Transformation? Or a Production Optimization? Or a System Development? Was it both necessary and sufficient? Will it be most useful for performance recovery? Or opportunity growth? Or sustained innovation?
A side-by-side synopsis of management profiles regarding projects versus changes is also an important view to have before committing to either:
PROJECT — a temporary micro-organization dedicated to:
· control
· output
· engineering
· production
· performance
CHANGE — a reconfiguration of existing states and relationships dedicated to:
· compatibility
· interactions
· cultivation
· development
· value
Seeing the difference between managing projects and changes makes it easier to understand why even highly diligent organizations still experience failures by putting Change through the wrong management discipline. Both Change Enablement and Change Readiness are not sufficiently addressed when left to occur as after-effects of doing something different — namely, projects.
Context and Commitment
A final note to consider in this discussion is the universal struggle to balance scale, complexity and timing in nearly all intentional responses to demand. Here, the difference between Needs and Requirements is critical to understand.
Requirements are specifications that constrain the methods available to a chosen actor. All included actors must be recognized for how the availability of what they in particular can offer, and how that offer most strongly relates to the viability of achieving the intended future. Requirements, at the least, can include or exclude actors.
Needs are differences from the current state that have understood and acknowledged value to the stakeholders invested in the effort. One of the most likely ways to provoke a failure of a change or of a project is to not directly and explicitly discover, align and support needs.
In change management, the connection between needs and requirements is a critical success factor, and almost by definition it acknowledges that while needs should stay the same as the strongest driver of change, supporting requirements may NOT stay the same during the lifespan of the effort from initiation to agreed achievement. Requirements exist only to satisfy Needs. One of the most common causes of failed managed changes is that Needs and Requirements become disconnected from each other in the activity of change.
In managed change, the issues of scope and timing must be continually reassessed in terms of Needs, with the ability to change requirements and have fulfillers adapt accordingly. This management practice calls for appropriate information flows, capability maturity, and stakeholder collaboration if breakdowns are going to be avoided. In order to be prepared for successful change, evident blockers of the flows, the maturity and the collaboration must be removed before the effort goes into full swing. Understanding this, the fact is that regardless of the size of change efforts, the same kind of preparation is necessary.
Malcolm is the Principal Consultant at Archestra Research in California and increasingly does analysis and design work on the complexity of enterprise-wide organizational change management
