Change Management – What’s so Confusing?

"I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”
                                                                                                - Robert McCloskey

With this post, I begin a series on change management.  Today I’ll make the effort to clarify what change management we’re discussing.  Next I’ll discuss a challenging philosophical dilemma posed by the choices of how change management is implemented.  Then I can settle in with actually discussing the “hows” of change management best practices.

When change management comes up on my projects, I always ask what “change management” the person is referring to.  I know of three different change managements that are commonly encountered on projects and there is invariably confusion because different project team members have different contexts where their specific change management label makes sense, but they often don’t realize that other groups use the same label, change management, to refer to something completely different.

In the HR and process worlds, change management refers to Organizational Change Management, the methods for transitioning people, teams and processes from a current state to a new future state.  This can involve realigning people, changing roles and duties, training, adding people, eliminating positions, streamlining job functions, etc.

In software engineering, change management refers to Systems Change Management, the practices necessary to successfully implement new software or update the installed software with new features.  This is better referred to as release management, but is frequently called change management by the practitioners.

When the PMBoK refers to change management, it means Project Change Management, which involves documenting and updating changes to the approved baseline project plan.  Project Change Management is neither difficult nor complex, but few organizations practice it effectively.

Note that an organizational change may involve a project and/or a software release.  A project can involve making organizational changes.  A project can involve implementing a software release.  A software release may be run as a project.  As I opened, it is not unusual at all to encounter all three of these change managements on a project and have different team members using the same terms and meaning completely different things.  Oh, the confusion you can sow.

For the remainder of my series on change management, I will be exclusively discussing project change management.  In my next post, I’ll take up one of the challenging philosophical questions about implementing project change management.

Are there any other change managements out there that I’ve missed?  Have you encountered confusion on projects when referring to change management?  How did you resolve the confusion?

© 2013 Chuck Morton.  All Rights Reserved.