- Mignon McLaughlin, The Neurotic's Notebook, 1960
Continuing my series on Project Change Management, it is now time to drill into the change management process. As I explained in my previous post in this series, the change management process is unlike other project management processes because it is not neatly contained, either by PMBoK knowledge area nor, except for one Monitoring and Controlling process, by PMBoK process group. This post will attempt to demystify change management by examining what is in place, how it works, and what it could look like.In the PMBoK (5th ed), other than “Perform integrated change control” in the Monitoring and Controlling Process Group, the remaining change management activities are spread across and buried within the Knowledge Areas and Process Group activities. So there’s a “perform” process, but how do you know what to “perform” if you don’t plan for it? How can you “perform” an activity if you don’t recognize it?
Let’s start with an understanding of what, conceptually, project change is. In a project, if you could alter the plan indiscriminately, there would be no need for a change management process. The change process would be “do whatever you want, whenever you want” and, thus, the project would equally be “do whatever you want, whenever you want.” Similarly, if there’s no plan, then there’s nothing to change. So, project change is the formal approach for replacing an agreed-to plan with an amended agreed-to plan. Since the plan establishes stakeholder expectations, change management is the structured approach for resetting expectations.The word we usually use for “agreed-to plan” is baseline.
Let’s step through this from the beginning of a project: The project is initiated, chartered and planned. A project plan (time, cost, procurement, HR, scope, change, etc.) is produced, agreed to by the appropriate authorities (baselined) and published to stakeholders. At this point, all stakeholders should be operating on the same expectations and you, the PM, should be reporting status, progress and variance based on the plan. Now, someone comes along with a request to add a new feature (or get it done quicker, or cheaper, or without a key resource, or ….). At that point, the project change management process is used.The requestor submits the request according to the approved change management process. The interesting thing here is that, regardless of how it’s described, the change activity is like a mini-project with all of the steps. The change request is equivalent to a Charter. The project team evaluates the request, estimating how the current project activities will be altered (new tasks, changed tasks, eliminated tasks, etc.) and creating a revised project plan, which must then be reviewed and approved (at which time it becomes the new baseline plan) or rejected (and the current plan remains effective).
So, if a stakeholder can submit a request to change the schedule, why isn’t there an “Evaluate schedule change request” or “Perform schedule change,” and likewise for all of the process groups? As you – an experienced project manager – well know, all the project parts are connected: you can’t tweak one area without somehow changing some other area. Therefore, there is no time (or scope or cost or HR or procurement, etc.) change activity: there is, reasonably, “Perform integrated change control.”So I want to pause here: I will continue this subject in my next post on this, where I will discuss how the current PMBoK activities relate to change management.
Does your organization have an effective and manageable project change management process? How does it work?
© 2013 Chuck Morton. All Rights Reserved.