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.