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.
No comments:
Post a Comment