Change Management: Confusion or Success Factor?

PM Commentary by Stacy Goff

Many people we have spoken to over the last several years have expressed concern over the increasing level of confusion around the term Change Management. The confusion goes back many years, but appears to be getting worse. As Change Agents, it is important for Project and Program Managers to understand the topic, the relevant competences, and the different perceptions asserted by different interested parties.

Depending on your perspective, Change Management is one or more of the following:

  • The configuration management of developers’ code, and the operating environment in which it was validated.
  • Managing the impact of requested and approved project changes, during the project.
  • Managing the impact of needed changes, updates, and improvements on the project result after that result is in business use.
  • Managing the organizational changes needed to embrace and appropriately apply project results.
  • Figuring out how to get reassigned and work for a Manager or Project Manager who is more effective.

Well, we just made that last one up. We are not here to proclaim which is the right or wrong perception: However, in every project or program, we do proclaim that you need to have a common understanding of what everyone means when speaking of Change Management.

Developers’ Change
Developers live in their own world, with many unique definitions for borrowed terms. For example, in some cases, a “project” is the repository for their code. No wonder some developers still have difficulty understanding their business and user requirements. They are not part of the “project.” Unless, of course, your project repository automatically generates the code from the requirements you capture. It is not up to us to change Developers” terminology; instead, we should understand it. When developers speak of Change Management as being part of the code library, then think Configuration Management.

Project Managers’ Change
THE Guide, a blended Information Technology and Project Management Methodology that we wrote in the 1980s (and continue to update today), took a strong position about Change. We called the evaluation, decision-making, implementation and tracking of change requests and other needed (or imposed) project changes Change Management. We explicitly avoided calling it Change Control. Our belief, then and now, and especially in IT, is that you cannot control needed change; you must instead manage the “cause and effect” expectations about its impact.

In part, we were attempting to reduce the petty technocrat behavior we had seen in so many organizations, where internal customers “requested” changes and the project team was the ultimate arbiter. To manage change, we included customers on the project team, then analyzed the business impact on both the project plan and the end product. Then we had customer management make the final ruling, either accepting the project and business impacts of the change, or deferring them. Later, when professional PM organizations came up with guides to bodies of knowledge, we reverted back (for the sake of consistency) to the old and incorrect terminology of change control. We always reviewed change impact on easy-to-measure project factors such as time and cost. We also analyzed and communicated other key factors, such as needed talent changes, both inside and outside the project, and new risks introduced by approved changes—considerations that many projects fail to evaluate.

We analyzed the cumulative impact of approved changes at the end of each phase or stage. This is important, because even though each change was individually approved, the compounding effects of multiple successive changes usually brought later surprises. To limit runaway change on large projects (most projects have more change than progress after the first year) we established change budgets, with increasing thresholds refreshed as part of each phase milestone or stage gate review. A project that had used all its budget, including provision for downstream costs of approved changes, either had to go through an audit, or waited until the beginning of the next Phase for change review funding.

All in all, a nice, tight system for putting accountability for Return on Investment in decision-maker’s hands, rather than a temporary project team. That was effective Project Change Management (or change control)–and remains so.

Maintenance and Support Change
The concerns of those who must maintain and support products of projects, whether the products are a new software application, a new satellite, or a new miracle drug, actually blend the first two types of Change Management listed above. And, there is more information needed to truly manage this type of change. Not to dwell on IT, but a classic issue is this: You need to make one tiny change in an application that has 12,000 Application Points of scope. The change will require adding just one piece of data, and changing another. It will take less than a half hour to complete this change. How much time will it require to test and validate it? The old rule of thumb, half-to-equal the time required to make the change, does not apply if you am “touching” the data.
Instead, you must run the entire regression-testing script (originally used to validate the entire system) against all applications touching that data. Of course, you do have documentation of all the applications touching that data, don’t you? And, you can completely emulate the environment of the original testing, including the database version, operating system version, and the original test scripts, together with all the cumulative patches you have made to all applications since their original validation, right? Hopefully, the original developers did not think that being agile means that you skip all the documentation, because the running code is the best documentation …

Which brings up another IT observation: The vast majority of things that go “bump” are things you have recently touched. That is another reason why those Change Management logs are important. You do keep those, right?

Organizational Change Management
Coming out of a Human Resources background, and emerging over the last 15 years is a new group that calls itself Organizational Change Management (OCM). We have encountered many of these folks in different organizations, and some of them may even be a bit strident about “their” discipline of Change Management. We have coached project teams through the challenges of dealing with OCM experts. Often, fearful Project Managers are concerned about the additional time and cost of complying with OCM requirements. In truth, OCMs usually just introduce processes that most competent project managers have always independently applied in their projects. Yet some wonder, who are these people, why are they so demanding, and why do Change Agents need them? There are many questions, and we have a few answers.

Filling a Business Need: When less-effective project managers focus on the “triple constraint”, “iron triangle”, or other partial measures of project success, they leave behind them a permanent organization that never quite implements the intended business result. Whether the solution just doesn’t work right, or it is missing key and needed features (perhaps cut to meet an artificial, externally-imposed deadline); perhaps the end-users have never been trained to use the product effectively, or the documentation is incomprehensible. In some cases, the project result may require more staff to achieve desired benefits, but the project itself was justified based on headcount reductions.

The net result, time after time, when this happens, is failure to meet the business needs. Perceived project failure. Of course, competent Project Managers always add these considerations to their project plans, and add business-oriented project success measures. But, they may be thwarted by Managers who measure project success based on time and cost considerations alone. Thus, years of flawed project management and management practices has created an entire profession of Organizational Change Managers (OCM), who appear to exist only because some Project Managers don’t perform their entire job as effective Change Agents. Perhaps this is why you occasionally encounter OCMs who are a bit strident about their role.

Laddering Changes For Benefits Realization
From its beginnings, our methodology product, THE Guide, showed the “Laddering” of key activities in every project, that must be staffed and completed correctly to assure effective organizational change, and benefit realization. Depending on the methodology (we had multiple paths for different project situations), there was consistent adoption and benefit realization when the following types of activities were managed and “owned” by internal customer managers. These were the activities that:

  • Established the business case, and responsibilities and timing for realizing it.
  • Elicited, prioritized and approved business requirements.
  • Established the high-level test plan, and the acceptance testing details.
  • Developed and delivered any needed training.
  • Generated, reviewed and approved the user documentation.
  • Established or approved the transition plan, including capacity analysis, training, coaching and possible position reclassifications.

When these activities were accepted and completed by the right customer managers, the projects came to closure faster and cheaper, and with a higher level of quality and customer satisfaction. As well, the projects achieved the promised business benefits. Not only that, but the presence of the early activities that “tested” customer commitment helped identify risks early in the project if those commitments were not met. Early identification offered time to resolve the risks, by escalating a range of responses to decision-makers.

One of the ways we have engaged Project Teams with Organizational Change Managers is to introduce them both to this “Laddering” approach. We call it laddering because, if you visualize a ladder, it has two vertical posts, and horizontal rungs. Imagine your project plan to be the leftmost post. The rightmost post is the set of actions the organization should be implementing during the project, to maximize outcome success. The horizontal rungs include the activities we identify above (a partial list). And the visualization of the ladder means the two posts should be completed concurrently, not sequentially. Both groups see the benefits of working together, and each learns to respect the contributions of the other toward the common goal, benefit realization.

Portfolio Change Management
For Project Teams that still feel “those OCMs” to be a pain, here is another perspective. Even when you use techniques such as laddering to help manage organizational change on your project, who is looking at the impact of a dozen concurrent projects that all affect one business unit? Perhaps this is why you feel that your customer doesn’t care about a project you are working on in their behalf–they have too many concurrent demands for their best talent. Only a combination of that business unit’s managers and an Organizational Change Management group has both the perspective and talent to assure the entire portfolio’s success. But that gets into another blog posting, if not an entire book.

Your Comments?