Change Management: Many people we have spoken to 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. We must know 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, you need to have a common understanding of what everyone means when speaking of Change Management.
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
Our Project Management Methodologies, started in the 1980s, took a strong position about Change. We called the evaluation, decision-making, implementation and tracking of change requests and other needed project changes Change Management. We explicitly avoided calling it Change Control. Our belief is that you cannot control needed change; you must instead manage the “cause and effect” expectations about its impact.
We were attempting to reduce the petty technocrat behavior we had seen in so many organizations. In these cases, internal customers “requested” changes and the project team was the ultimate arbiter. To manage change, we included customers in the project team. Then we analyzed the business impact of changes on both the project plan and the end product. Last, customer management made the final ruling, either accepting the project and business impacts of the change, or deferring it.
Some years later, professional PM organizations came up with guides to bodies of knowledge, that prescribed ‘Change Control’. We reverted back (for the sake of consistency) to that old and incorrect terminology. It remained essential to review change impact on easy-to-measure project factors such as time and cost. Even more important was to analyze and communicate other key factors, such as needed talent changes, both inside and outside the project. And we evaluated new risks introduced by approved changes—considerations that many projects fail to evaluate.
Cumulative Impact Of Change
We analyzed the cumulative impact of approved changes at the end of each phase or stage. This is essential, although critics assert that each change was individually approved. Why essential? Because the compounding effects of multiple successive changes usually brought later surprises. Another factor: most projects have more change than progress after the first year. To limit runaway change on large projects, we established change budgets, with increasing thresholds refreshed at each phase milestone. Some projects had used all their budget, including provision for downstream costs of approved changes. Under our processes, they 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 system for keeping accountability for Return on Investment in decision-makers’ hands, not a temporary project team. That was effective Project Change Management (or change control)–and remains so.
Change Management: Maintenance and Support Change
The concerns of those who maintain and support products of projects, blend the first two types of Change Management listed above. This is true whether the products are a new software application, a new satellite, or a new miracle drug, or other outcomes. 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 are “touching” the data.
Instead, you must run the entire regression-testing script (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. That includes the database version, operating system version, and the original test scripts. Together, of course, 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. For some, they assert that 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 from the Human Resources discipline over the last 15 years, is a discipline named Organizational Change Management (OCM). We have encountered many of these folks in different organizations. Some of them may 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: Some less-effective project managers focus on the “triple constraint”, “iron triangle”, or other partial measures of project success. When they do so, they leave behind them a permanent organization that never quite implements the intended business result. It might be that the solution just doesn’t work right. Or perhaps, it is missing key and needed features (perhaps cut to meet an artificial, externally-imposed deadline). Possibly, 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 budget was justified based on ongoing staffing headcount reductions.
The Outcome
The net result, time after time, when this happens, is failure to meet the business needs. Perceived project failure. 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. The result: years of flawed project management and management practices have created a profession of Organizational Change Managers (OCM). They appear to exist only because some Project Managers did not perform their 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
Our methodology products showed the “Laddering” of key activities in every project. These key activities are those 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. But only 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.
Engaging Teams And OCMs
We have engaged Project Teams with Organizational Change Managers by introducing 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. Congratulations to you, when you use techniques such as laddering to help manage organizational change on your project. And, 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 may have too many concurrent demands for their best talent. Only a combination of that business unit’s managers and an Organizational Change Management group can help. Together, they have both the perspective and talent to assure the entire portfolio’s success. But that gets into another blog posting, if not an entire book.