Understanding Change: If we are to be successful as Change Agents, we need to understand Change. That understanding ranges from the dynamics of Change, to the disciplines involved, even to the terminology around Change. This posting deals with some of the terminology around Program or Project Change.
For example, many years ago, I wrote my first IT PM methodology. I labeled the processes around requesting, evaluating, approving and implementing needed project changes Change Management. In that era (pre-1985), it was more popular to call those actions Change Control.
My rationale was that we cannot control Change. In fact, we are foolish to attempt to do so. But we could manage the process, and manage the impact of the change on the product. Thus, Change Management. There was one concern. If PM is the discipline of Managing Change (as I claimed), then Change Management in Managing Change was too recursive.
Understanding Change: Changes
Then, those who do what we call Configuration Management borrowed the phrase Change Management. Their actions involved automation of version control, tracking changes in installed systems, tools or processes. This might occur late in a project, or long after the project’s product is complete. It was further complicated when a software package came on the market with the name ChangeMan. Its purpose: to track configuration changes.
One outcome is that we had to start calling our practices Project Change Management. Otherwise, the IT folks would get confused. A small sacrifice.
Then in the late 1980s, along came the organizational “Change Management” people. We first encountered them in the NorthEast USA. They were people who saw the need for a separate discipline, borne from Human Resources, to manage the impact of change on the organization. Some knew a little about Project Management, our discipline of organizational change. But they were mostly concerned with the human aspects of change.
Understanding Change: Part of the PM Role
We agreed with the concern for the human or personal aspects of change. We felt that Change Management should always be part of every effective Project Manager’s initiatives. And, we consistently identified the essential “laddering” of Customer activities and responsibilities in every internal project. That Customer engagement is a key requirement, needed to assure benefit realization. After all, benefits seldom happen without properly managing the impact of the project’s change in the target organization(s).
Perhaps their efforts, continuing today, are the result of not-yet-competent Project Managers and teams they encounter. Our position is that we don’t care who takes credit for the organization’s success with the project results. As long, of course as somebody does. But we capitulated HR’s use of this emerging and eager discipline, and reverted to calling our processes Project Change Control.
Understanding Change: Laddering Change
Some from the organizational Change Management discipline applied the same “laddering” we offer in our PM methods. We identify the specific activities and results that must have Customer/Client ownership and involvement if the project is to succeed.
Those “laddered” activities and results are areas of key and consistently-recurring Risks (threats and opportunities). They then found that they could engage Executives who cared about Benefits Realization in their actionable items. Win-win resulted when those organizations moved from a react mode to a prevent mode, especially on those Risk/threats.
To Summarize Understanding Change
Even though we Change Agents don’t really control change, we must manage it. And that change includes project changes, configuration changes and organizational changes. So today, when you speak of Change Control or Change Management, be sure your audience understands the Change you are discussing. And how you and they will know it is working. We still frequently see too much confusion about the terms today.
Do you? And what will you do about it?