CompTIA Project+ PK0-003

Define Change Management Process

by Steve Caseley

Start your 7-day free trial today.

This video is only available to subscribers.

A free trial includes:

  • Unlimited 24/7 access to our entire IT training video library.
  • Ability to train on the go with our mobile website and iOS/Android apps.
  • Note-taking, bookmarking, speed control, and closed captioning features.

What is Project Management

Project+ and how to prepare for the exam

Pre-Project Setup

Project Planning

Prepare Scope Statement

Create WBS and WBS Dictionary

Define Change Management Process

00:00:00 - Continuing along our project road map for 2.0 project planning
00:00:05 - we move to the next step which is 2.3 Define Change Management
00:00:10 - Process or as the Project Plus Certification defines it 2.3 outline
00:00:17 - a process for managing changes to a project.
00:00:21 - Change management is inevitable
00:00:28 - or at least in my humble opinion change management or change
00:00:33 - itself to your project is inevitable.
00:00:37 - We can do as good a job as we want or as possible I shouldn't
00:00:42 - say as we want as good a job as possible in project planning
00:00:47 - to define a clear unambiguous scope statement to produce the
00:00:51 - most wonderful WBS and all of the other components we're going
00:00:54 - to discuss in the remaining nuggets in project planning
00:01:00 - change is still going to happen. And we'll discuss some of the
00:01:04 - reasons for and causes of change in this nugget but change is
00:01:08 - going to happen so it's important in project planning that we
00:01:12 - prepare for change,
00:01:18 - i.e. we define
00:01:21 - the rules.
00:01:24 - And that's what we're going to discuss in this nugget is the
00:01:28 - rules for change management. We're still in planning, we're not
00:01:32 - going to execute change management, we'll talk about executing
00:01:35 - the change management later in the nugget series when we get
00:01:38 - into execution and control. Here we're defining the change management
00:01:43 - process, we're going to be prepared for change and we're going
00:01:45 - to define the rules and we're going to ensure
00:01:49 - the business
00:01:53 - accepts/understands these rules.
00:01:59 - It's the pro-activity we're going to be prepared for, we're going
00:02:03 - to define the rules so that on week 2 or month 2 or month 6 or
00:02:09 - month 8, whenever change starts to happen on your project everybody's
00:02:14 - prepared and everybody understands what the process is. So let's
00:02:18 - understand what the change management process is. So
00:02:22 - the change management process itself has two key components.
00:02:27 - One the integrated change management ensuring that we have a
00:02:31 - change management process that addresses
00:02:36 - all project aspects and when I say all I'm talking about everything
00:02:42 - we're defining in project planning scope, time, cost, human resources,
00:02:47 - procurement, quality, risk that our integrated change management
00:02:52 - addresses all of those components. And our second key component
00:02:55 - to change management is having a change control board in place
00:03:00 - that authorizes
00:03:04 - the changes and ensures that the changes are authorized and considered
00:03:08 - in conjunction with overall corporate direction. And I have this
00:03:13 - other thing thrown in the middles called scope creep. Scope creep
00:03:18 - is not a change management process in and of itself but scope
00:03:23 - creep is something we need to understand,
00:03:28 - we need to be prepared for,
00:03:32 - and therefore is important that we understand what this little
00:03:37 - evil thing called scope creep is as part of our change management
00:03:41 - process so that if we're building our processes for integrated
00:03:44 - change management and presenting the integrated change management
00:03:48 - to a change control board that we have ensured that we're effectively
00:03:52 - managing around eliminating this thing called scope creep. So
00:03:58 - let's delve a little deeper and let's focus on and let's understand
00:04:01 - what integrated change management is all about. The
00:04:06 - first step to integrated change management is understanding that
00:04:10 - change impacts everything, all project aspects.
00:04:18 - Everything that we've learned about project management from the
00:04:21 - PMBOK, everything that we're going to discuss in this nugget
00:04:24 - series on project planning has to be considered as part of addressing,
00:04:31 - analyzing, understanding
00:04:33 - all changes. Typically when people think of changes they think
00:04:37 - of the big three. When we change a project
00:04:43 - we're probably changing the project scope, we're adding
00:04:49 - or removing
00:04:52 - components of the scope.
00:04:55 - And that's what change is all about we're adding or removing
00:04:59 - components of the scope so again as people prepare for change
00:05:03 - management, plan for change management, we are probably equipping
00:05:09 - ourselves to deal with changes to the scope. And it's probably
00:05:13 - self evident or at least I will describe to you why it's self
00:05:17 - evident that if we change the scope most likely,
00:05:24 - but not always, but most likely any change to the scope is going
00:05:28 - to relate in an equivalent change in the time. So for adding
00:05:33 - scope we're going to add time to our project; if we're removing
00:05:37 - scope most likely we're going to remove time from the project.
00:05:41 - Now again, I'm sure you can sit down and come up with the scenario
00:05:44 - where I'm removing scope but as a result of removing scope I
00:05:49 - need to undo work that's done or I need to make changes to other
00:05:53 - functions to deal with this reduction in scope so maybe the time
00:05:57 - actually goes up but again generally speaking as we add scope
00:06:02 - we're going to add time, as we remove scope we're going to remove
00:06:05 - time and I think again fairly self evident as we add scope we're
00:06:11 - most likely going to increase the cost of the project and as
00:06:14 - we remove scope we're going to reduce the cost of the project.
00:06:19 - These are front and center
00:06:27 - and I think most of you listening to this series center, I've
00:06:32 - got a few too many words in there most of you listening to this
00:06:35 - nugget series are going to appreciate that any change to scope
00:06:39 - is going to impact or any change to the project is going to impact
00:06:44 - the scope, the time, the cost. What I want you to consider
00:06:48 - is the impact to the other project aspects for every change to
00:06:54 - our project. Does the change impact our definition of quality
00:06:59 - or does the change impact their expectations of quality or does
00:07:04 - the change require us to make changes to our quality system? Consider
00:07:13 - not all changes will have an impact on the project quality statement
00:07:18 - and on the project quality processes but some changes will have
00:07:23 - an impact on the quality processes so we should always consider
00:07:28 - what impact does adding/removing the scope, the time, the cost,
00:07:34 - what impact is that going to have on our quality processes.
00:07:38 - Consider not always.
00:07:41 - If we're adding scope which adds time, which adds cost to the
00:07:45 - project it may
00:07:48 - have an impact on our human resources, on our team.
00:07:54 - We may need to add team members.
00:08:01 - Or if we're removing scope we may need to remove team members.
00:08:06 - Or we may need to reassign.
00:08:10 - We had a developer who was going to move into a testing role.
00:08:14 - Now I know some of you may be saying "Developers can't test"
00:08:18 - I've actually seen some developers that are really good testers,
00:08:21 - I've also seen some developers that are really bad testers, but
00:08:25 - we may have planned some role reassignments
00:08:29 - as a result of adding scope, maybe those role reassignments need
00:08:33 - to be reconsidered. So every change should be again evaluated
00:08:39 - for what impact it's going to have on our human resource plans,
00:08:43 - on our team compositions.
00:08:46 - Maybe as a result of adding or removing scope we need to change
00:08:50 - our procurement strategies, maybe we need to buy more,
00:08:55 - maybe we need to buy less
00:08:58 - consider. And risk what does this change do to our risk? Does
00:09:04 - it remove
00:09:06 - a risk component?
00:09:08 - Does it change?
00:09:11 - Does it add?
00:09:14 - So we need to broaden our vision, we need to ensure that the
00:09:20 - business expects that we will be processing changes,
00:09:25 - we will be defining the impact all changes
00:09:30 - are going to have on the big three the scope, the time, the cost
00:09:35 - but we're also going to consider what impact the change is going
00:09:39 - to have on quality, human resources, procurement, and risk
00:09:43 - and these all require communications, we need to tell the business,
00:09:51 - we need to tell management,
00:09:55 - we need to tell the team
00:09:58 - what's going on in the change process.
00:10:03 - This is integrated change management
00:10:07 - scope, time, cost, quality, human resources, procurement, risk
00:10:12 - all with the communications element gives us integrated
00:10:18 - change management.
00:10:23 - So how do we make integrated change management work? So
00:10:27 - having just explored that change management has to be integrated
00:10:31 - for all project aspects
00:10:37 - how do we ensure that every time we process change that we're
00:10:42 - going to deal with all the project aspects? My humble suggestion
00:10:46 - is we use established
00:10:52 - processes and forums. And
00:10:57 - in just a minute I'm going to share with you my established change
00:11:01 - form and on that change form we have considerations for all the
00:11:06 - project aspects and we have a change log which we're going to
00:11:11 - use for our communications.
00:11:17 - If we establish a process, if we publish the process
00:11:25 - now in planning
00:11:31 - we're planning
00:11:34 - the change process.
00:11:38 - So let's have a look at what a good change form could look like. So
00:11:45 - here is a change request form I often use on projects. The form
00:11:49 - in and of itself is very straightforward, nice and short and
00:11:53 - succinct, it's a single page. Now the form itself is a single
00:11:58 - page. Often when we fill it in it may expand beyond the single
00:12:01 - page into two or maybe three pages but we should strive to keep
00:12:06 - the material on the change request form as straightforward, as
00:12:10 - succinct as possible to make the change process less onerous
00:12:15 - and less threatening to the business to use. You want to make
00:12:18 - change an acceptable process. Let's
00:12:21 - have a look at filling in the form. Project name, obviously that's
00:12:25 - going to be the name for your project; the date issued often
00:12:29 - typically will be today's date; the project manager myself; the
00:12:33 - due date let's spend just a few minutes discussing the due date.
00:12:37 - We're issuing the form today, I believe it's very important in
00:12:41 - the change management process we're going to define that we define
00:12:46 - the expectations for accepting of the change. So we're issuing
00:12:52 - the change today, the due date is 10 days from
00:12:57 - now or whatever is going to be a reasonable period of time to
00:13:02 - negotiate with the business for when the change request should
00:13:06 - be returned, I think 10 days should be more than ample. As a
00:13:10 - matter of fact I would strive to get my business to accept a
00:13:14 - return date of five days so that the project doesn't get into
00:13:18 - a limbo state waiting for changes to be approved. Why is the
00:13:23 - due date important? The due date is important because if 10 days
00:13:27 - transpires and the business doesn't return the change then I
00:13:33 - have again pre-warned them that says "Now I'm going to get nasty,
00:13:37 - now I'm going to start to nag you to get the change request returned/approved"
00:13:43 - so again you're warning them in advance so you're going to become
00:13:45 - a nag and more importantly we're defining the true criteria of
00:13:50 - what will happen to the change if it's not acted upon within
00:13:55 - the due period, i.e. in 10 days I'm going to start nagging but
00:14:00 - very soon after that I'm going to enact the policy that says
00:14:05 - "Changes not completed within the assigned period will automatically
00:14:11 - reject it. If you don't tell me to do it within 10 days it's
00:14:16 - not going to happen." Or maybe we want to take the positive side
00:14:20 - of that. "I'm going to give you a change request, you have 10
00:14:24 - days to tell me you don't want it to happen, and if after 10
00:14:27 - days you don't notify me that it's not going to happen, then
00:14:32 - I'll automatically start working on it." One method over the
00:14:36 - other, positive versus the negative, there are no true pros and
00:14:39 - cons, it's simply the change management process, you need to
00:14:44 - work through with the business. The request name my suggestion
00:14:48 - is make it as meaningful as possible and make it as self sufficient
00:14:52 - as possible. As we start to do the communications process associated
00:14:57 - with changes we're not going to be carrying the full change document
00:15:01 - itself forward in our communications, in our status report, in
00:15:05 - our steering committees, we're simply going to have a quick reference
00:15:08 - and we have a meaningful and self sufficient request name,
00:15:13 - within a sentence, we don't want this to become paragraphs, we
00:15:16 - want it to be a sentence or even better still a sentence fragment,
00:15:20 - but it should be meaningful and self sufficient and we're going
00:15:23 - to have a change request number,
00:15:25 - number 1 for example. Now
00:15:28 - let's get into the meat of the change. The reason for the change
00:15:33 - this should be from the business.
00:15:37 - The business typically, not always, sometimes changes will be
00:15:42 - initiated by the project for improvement purposes or for changes
00:15:46 - in technology, but most changes are going to come from the business
00:15:50 - and it should be in business language.
00:15:57 - I like to track who's doing this, so this was prepared by Steve,
00:16:02 - the reason for the change typically from the business in business
00:16:05 - language again as short and as sweet, as succinct as possible
00:16:11 - but it also needs to have enough clarity so that we can do a
00:16:16 - good impact analysis,
00:16:19 - it's going to spread across the reason for the change and the
00:16:23 - description, it needs to be clear
00:16:26 - and available for analysis.
00:16:34 - And again often the reason for the change and the description
00:16:38 - change will come from the same people but again I like to track
00:16:40 - if there is a difference. With
00:16:43 - those two pieces of information filled in
00:16:48 - and often what I will do is the description of the change clear
00:16:52 - and available for analysis, I will then document
00:16:57 - my analysis
00:16:59 - results here if the description of the change from the business
00:17:05 - isn't succinct enough or it isn't completed enough it's the better
00:17:10 - definition. And now we're going to start to impact or define
00:17:15 - the impact of the change. It's going to cost the project these
00:17:19 - many dollars. In order to implement the change it's going to
00:17:24 - cost the project an additional $5000 or in order to remove the
00:17:28 - functionality I will be removing $2000 from the project budget.
00:17:33 - The ramifications schedule one week extension
00:17:40 - to the milestone
00:17:44 - dot, dot, dot,
00:17:47 - dot, no impact
00:17:49 - to staffing.
00:17:55 - And those are the big hitters the scope impact right here, the
00:18:01 - cost impact,
00:18:03 - the schedule impact, and I've added the staffing impact because
00:18:08 - of all the other areas that we need to consider as part of integrated
00:18:11 - change management staffing is the one that's most likely to be
00:18:15 - impacted but now I have room for other considerations.
00:18:20 - I have considered the impact that this change is going to have
00:18:24 - on my quality processes.
00:18:28 - And often I will say "no impact to quality."
00:18:35 - What impact is it going to have on procurement? And again if
00:18:38 - there's none I will say "no impact on procurement." What impact
00:18:41 - is it going to have on project risks? But with this again I think
00:18:45 - fairly straightforward, fairly succinct, one page, maybe expanded
00:18:50 - as we start to fill in the details, two to three pages of
00:18:55 - definition of a fully integrated change. We know why the business
00:19:00 - wants the change, we have a clear available for analysis, the
00:19:06 - documentation of the analysis results are going to be put in
00:19:08 - here so it fully defines the change,
00:19:16 - we're identifying the cost, we're identifying the schedule, we're
00:19:20 - identifying all of those other areas for consideration. And
00:19:26 - to wrap up my change document
00:19:30 - I have the approval process.
00:19:32 - I believe that it's important for the IT organization, the project
00:19:39 - delivery organization to say "I've reviewed this, I believe we
00:19:43 - have done complete thorough analysis, I believe that the cost,
00:19:48 - the schedule, the other impacts of the change are realistic so
00:19:53 - I'm willing to put my name and my signature that says "I, Steve
00:19:57 - Caseley, am happy with the analysis that has been done by my
00:20:02 - team, I'm willing to commit my project to do this change for
00:20:08 - this much money, for this much schedule impact. You have my word
00:20:13 - on it, you have my signature." And then this is where I want
00:20:17 - within the 10 business days I want the business to come back
00:20:20 - and say "Yes, it's approved,
00:20:25 - and you have my signature to authorize the project to go ahead
00:20:29 - and do the work."
00:20:31 - This is
00:20:33 - a fully integrated change management process. This is a fully
00:20:39 - integrated change request form.
00:20:43 - Now again we're in planning, we're not going to be filling in
00:20:46 - these change request forms in planning. What we're doing in planning
00:20:50 - is presenting this change request form to the business as part
00:20:54 - of our project plan that says "Here is the process I'm going
00:20:58 - to follow. Here are my expectations of when you're going to tell
00:21:02 - me whether or not the change is accepted." Here is where I'm
00:21:07 - going to tell you what the impact or what the decision that's
00:21:11 - going to happen after 10 days is going to be it's going to be
00:21:14 - accepted or it's going to be rejected. And here's the type of
00:21:17 - information that the project team is going to pull together
00:21:21 - as part of change analysis, fully integrated, and here's where
00:21:25 - I'm going to make my commitment to you to execute the change
00:21:29 - and here's where you're going to give me your authorization
00:21:32 - to do the change. The
00:21:35 - final step in our integrated change management process is the
00:21:39 - communications. We just reviewed the detailed change log or the
00:21:45 - change form itself which dealt with the scope, the time, the
00:21:49 - cost, the quality. The last aspect of integrated change management
00:21:52 - as I said is communications and I believe communications is achieved
00:21:57 - by something as simple as a change request log.
00:22:01 - And it's a log that we make available so CR number 1
00:22:06 - was done today,
00:22:09 - was resolved in five days from now,
00:22:13 - the change request name remember meaningful and self
00:22:18 - sufficient, and the status is approved.
00:22:25 - And then change request 2
00:22:30 - was done tomorrow and so on. But if we take this change request
00:22:35 - log and we then do a cut and paste of the change request log
00:22:40 - and include it in our status report, if we do a cut and paste
00:22:44 - log of the change request log and include it in our steering
00:22:47 - committee meetings we can very, very quickly do that last piece
00:22:52 - of integrated change management and have proper full communications
00:22:58 - of project changes to the business, to management, to the team,
00:23:05 - etc. etc. So integrated change management is key, it's important
00:23:11 - that we plan for integrated change management upfront, that we
00:23:15 - define the integrated change management process we're going to
00:23:18 - follow, that we show the business our change request form, and
00:23:23 - we show the business that we're going to manage the change request
00:23:27 - through this change log and we've effectively
00:23:31 - defined our process for change management. Now let's move from
00:23:36 - there and let's look at this little annoying thing that I described
00:23:39 - in the introduction called scope creep. And
00:23:43 - scope creep is not so much a part of change management but scope
00:23:47 - creep is a result of ineffective change management.
00:23:52 - More times than not scope creep is going to come about when the
00:23:55 - business identifies small incremental changes. It's tiny,
00:24:01 - it's going to take five minutes
00:24:05 - to do, it doesn't
00:24:09 - impact anything.
00:24:14 - So the business says "Slip it in"
00:24:20 - as politely as you can without creating a bad relationship with
00:24:26 - the business, with the acceptor, we have to resist
00:24:31 - this tiny, doesn't impact anything, just slip it in because yes,
00:24:36 - it's a small incremental change,
00:24:40 - I don't believe any change can be done in five minutes,
00:24:44 - maybe, just maybe
00:24:48 - the change to the analysis document is going to take five minutes,
00:24:52 - but a change to the analysis document isn't going to take five
00:24:55 - minutes, it's probably going to take an additional five hours
00:25:00 - in design and may take as much as five days in development. So
00:25:05 - tiny changes up front can expand to larger changes down the stream
00:25:11 - and if we don't follow our integrated change management process
00:25:14 - and do a thorough analysis of the cost, the time, the schedule,
00:25:20 - the quality it
00:25:23 - may be much more significant than the tiny that we think it is
00:25:27 - and even if it is that tiny what other things downstream
00:25:36 - that it may impact if we don't consider it. So resist this urge
00:25:42 - to just slip it in, I think it's important that we document all
00:25:48 - changes how big can I write all
00:25:54 - all changes should be documented, all changes should be managed
00:25:59 - to our integrated change management process, and if we manage
00:26:03 - those expectations up front in planning
00:26:06 - the small incremental changes, the slip it in urge should again
00:26:12 - be eliminated.
00:26:14 - Why do these small incremental changes happen? Well often it's
00:26:21 - a result of an open ended scope statement. Our scope statement
00:26:24 - is not clear, unambiguous,
00:26:27 - and well defined so again in planning we need to try to remove
00:26:32 - the open ended scope statement and we need to have clear, well
00:26:36 - defined, unambiguous, etc. etc. all of those things that we discussed
00:26:43 - a couple of nuggets ago in scope statement should definitely
00:26:48 - be applied because it's going to make things easier for us.
00:26:53 - Often these things will come about as a result of slow decisions.
00:26:58 - We ask for a decision on whether the screen should be red or
00:27:03 - blue. The business is hesitant to make a decision on red or
00:27:08 - blue so we don't do anything and we just continue and we continue
00:27:11 - and we continue, we've gone through analysis, we've gone through
00:27:13 - design, and finally we went with the original statement that
00:27:18 - says it should be red but now finally after it's developed
00:27:22 - the determination is "You know? It really should have been blue"
00:27:26 - as a result of slow decisions we may have changes so we need
00:27:30 - to again make sure we plan ways to improve,
00:27:36 - to accelerate
00:27:39 - the decision making process.
00:27:42 - One of the main reasons for scope change, for scope creep is
00:27:46 - a refined understanding of the requirements. Remember we said
00:27:49 - one of the biggest challenges that we have in IT project delivery
00:27:53 - is it's intangible.
00:27:55 - We're going to try to clearly and unambiguously define it but
00:27:59 - it's still intangible. As we start to do analysis, as we develop
00:28:03 - prototypes, as we start to put working code in front of the business
00:28:08 - they're going to get a far better understanding of the requirements
00:28:10 - and say "Well that was close
00:28:13 - but here's what I really need."
00:28:16 - That's a change.
00:28:18 - And another big scope creep area that I feel we need to take
00:28:23 - special attention to eliminate is creative developers.
00:28:28 - The developer knows better than the business. The developer reads
00:28:32 - the specification,
00:28:34 - the developer understands the specification, but the developer
00:28:37 - in their own minds says "You know what? I really don't think
00:28:41 - that's what they wanted. I'm going to do it the way I think they
00:28:44 - wanted it done. They just weren't bright enough to ask for it
00:28:49 - so I'm going to fix it for them without asking." Well chances
00:28:52 - are the business did define it right and the developer has developed
00:28:57 - to the wrong specification their own. Or creative developers
00:29:02 - are I'm going to say bored developers.
00:29:07 - They're creating routine business functionality,
00:29:12 - the routine business functionality isn't challenging they creative
00:29:15 - side, and they say "You know what? This development tool that
00:29:19 - I'm working on can do so much more than the business is asking
00:29:22 - for. I can add bells, I can add whistles, I can put shiny spokes
00:29:26 - on the wheels, I can make this thing a work of art" and again
00:29:31 - the developer decides to embellish and emboss the requirement
00:29:35 - to make it more fun to code.
00:29:39 - Again, in planning we need to as effectively as possible put
00:29:44 - quality control gates in place to eliminate creative developers
00:29:50 - from changing the requirements to suit their own development
00:29:54 - requirements. So scope creep
00:29:57 - something we need to be aware of, something we need to manage
00:30:03 - out during planning.
00:30:10 - And with that dealt with it's time to move on to our last aspect
00:30:14 - of change management which is our change control board. This
00:30:19 - concept of change control board will definitely be something
00:30:23 - that you will expect to see on your Project Plus exam, may or
00:30:28 - may not be something you decide to implement in your project.
00:30:32 - A change control board is a formal change organization typically
00:30:37 - done at an organizational level. That's the key definition that
00:30:41 - you need to be aware of for the exam.
00:30:45 - Change control board is a formal change authorization
00:30:50 - at the organization level that reviews
00:30:54 - the change requests, the CRs, and manages the CRs from both a
00:31:00 - project viewpoint and an organizational viewpoint to ensure that
00:31:05 - the scarce organizational resources and dollars are most appropriately
00:31:11 - allocated to the various projects to allow them to achieve both
00:31:16 - the project priorities and the organizational priorities.
00:31:20 - And that is really the message I want to give to you for a change
00:31:25 - control board. Almost guaranteed you're going to see something
00:31:29 - related to it on the exam, it's an organizational change process
00:31:33 - that reviews all of the changes and approves the changes
00:31:42 - to ensure that approved changes are going to address both organizational
00:31:47 - and project priorities and requirements and looks at
00:31:53 - it from the larger view. And
00:31:59 - this is the reason I say you may or may not need to implement
00:32:03 - the formal change control board at your project that you're managing
00:32:08 - in real life in your organization.
00:32:11 - If your project sponsor has sufficient authority to approve changes
00:32:17 - on behalf of the project and take that approval within their
00:32:22 - organizational structure then you may not need a full organizational
00:32:27 - change board, you get it within your acceptor in himself or herself,
00:32:32 - but other projects will find that a formal change authorization
00:32:36 - at an organizational level absolutely helps us address these
00:32:41 - project and organizational requirements, looking at it from the
00:32:44 - larger view and ensuring that the scarce
00:32:49 - organizational resources
00:32:53 - are properly allocated. And that's all a change control board
00:32:57 - is. This concludes our nugget on change management. This nugget
00:33:02 - was focused on integrated change management. Integrated change
00:33:07 - management ensures that all changes
00:33:12 - are considered
00:33:17 - and that all project management components scope, time, cost,
00:33:21 - quality, communications, procurement, human resources, and I'm
00:33:27 - missing one in there but all aspects to project management, all
00:33:32 - of our knowledge areas are considered for all changes and that
00:33:36 - it is a controlled
00:33:40 - approved process
00:33:47 - that's what integrated change management is all about. We looked
00:33:49 - at a change request form
00:33:53 - which ensures that we consider all changes, that we apply a formal
00:33:57 - process, and that the change form considered all of the PM areas,
00:34:04 - and that it was presented for approval and we looked at a CR
00:34:08 - log that was used for communications
00:34:17 - and that's what integrated change management is all about. We're
00:34:20 - discussing change management here in planning so that we can
00:34:23 - tell the business,
00:34:28 - the process
00:34:32 - to be followed
00:34:35 - during delivery.
00:34:41 - No one likes to be surprised,
00:34:43 - the business would be horribly surprised if we introduce the
00:34:46 - change management process at week 8 in the project so we tell
00:34:50 - them in advance what our integrated change management process
00:34:53 - is going to be.
00:34:55 - The second component to integrated change management is our change
00:34:59 - control board, it provides the organizational
00:35:03 - review and approval,
00:35:09 - definitely going to be something that you should consider for
00:35:11 - your exam,
00:35:13 - highly recommended but not critical that you implement the change
00:35:17 - control board on all projects that you're going to manage in
00:35:20 - real life. And lastly we spent a few minutes discussing the scope
00:35:24 - creep and how again we need to plan
00:35:29 - upfront to eliminate scope creep and make it go away. This
00:35:36 - concludes our nugget on defining the change management process.
00:35:40 - I hope this module was informative for you and thank you very
00:35:43 - much for viewing.

Develop Project Schedule and Resources and Roles

PERT/GANTT/CPM and Schedule Compression

Communications Management Plan

Risk Management Plan

Quality Management Plan

Cost Management Plan

Procurement Management Plan

Transition and Project Management Plan

Human Resource Management

Project Governance

Project Tracking

Project Change Management

Project Risk Management

Project Quality Management

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

This forum is for community use – trainers will not participate in conversations. Share your thoughts on training content and engage with other members of the CBT Nuggets community. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus

Course Features

Speed Control

Play videos at a faster or slower pace.

Bookmarks

Pick up where you left off watching a video.

Notes

Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

Premium Features

Transcender® Practice Exams

These practice tests help you review your knowledge and prepare you for exams.

Offline Training

Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching

Develop and maintain a study plan with one-to-one assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer

Certifications:
PMI-PMP, PMI-ACP, PMI-SP, Project+

Area Of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development


Stay Connected

Get the latest updates on the subjects you choose.


  © 2014 CBT Nuggets. All rights reserved. Licensing Agreement | Billing Agreement | Privacy Policy | RSS