CompTIA Project+ PK0-003

Project Change Management

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

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

00:00:00 - Welcome to the next segment of the CompTIA Project Plus Certification
00:00:04 - Exam Series, 4.0 Change, Control, and Communications.
00:00:10 - This is where we, the project managers, do our work. This is
00:00:15 - where the actual project management activities exist to manage
00:00:19 - the change to our project, to control/manage
00:00:23 - our project, and communicate the results of that back to the
00:00:27 - project stakeholders. For those of you following along and comparing
00:00:30 - this to the PMI PMBOK Guide processes, this is the monitoring
00:00:38 - and control processes from PMBOK.
00:00:41 - In this nugget, we are going to discuss 4.1
00:00:44 - Change Management Procedures
00:00:49 - and 4.2 Change Impact to the Triple Constraints. Or
00:00:54 - the full name for these, as per CompTIA, is 4.1
00:00:58 - Given a Scenario, Implement Proper Change Management Procedures,
00:01:02 - and 4.2 Evaluate the Impact of Potential Changes to the Triple
00:01:07 - Constraints. Doing effective change management on our projects
00:01:12 - is critical to overall project success. Changes will happen.
00:01:18 - The business will request changes. The project team will discover
00:01:22 - changes within the project definition itself. Change is inevitable
00:01:27 - in a project. It's our job as project managers to change,
00:01:33 - to manage the changes, and to ensure that changes are communicated,
00:01:42 - that changes are reviewed,
00:01:46 - that they are sized,
00:01:48 - and they are approved.
00:01:52 - And when we are talking about sizing changes, that we are primarily
00:01:56 - sizing our changes against the triple constraints, we determine
00:02:01 - the impact to the scope. We are determining the impact to the
00:02:06 - budget for the project. And we are determining the impact to
00:02:08 - the schedule for our project.
00:02:11 - With good effective change management in place, we are positioning
00:02:16 - our project for delivery success. We are ensuring that changes
00:02:20 - will be accepted into our project. But through the approval of
00:02:24 - the changes, we are then understanding that this change is going
00:02:28 - to increase the budget for the project and is going to change
00:02:32 - the project's schedule so that our project completion deadline
00:02:36 - milestone is now going to be extended by three weeks or whatever
00:02:40 - the appropriate change is going to be.
00:02:43 - Change is inevitable.
00:02:45 - We as project managers need to ensure we have effective change
00:02:49 - management in place for our project.
00:02:53 - And as critical as change control or change management is, change
00:02:57 - control, change management is relatively straightforward and
00:03:01 - is achieved through these three, I'm going to say relatively
00:03:04 - straightforward steps. And the key is the integrated change management.
00:03:10 - This ensures that all
00:03:12 - changes are processed, all changes are analyzed,
00:03:19 - all changes are costed,
00:03:23 - sized against our triple constraints, and all changes are approved.
00:03:31 - And that's the key to integrated change management. Often, that
00:03:36 - approval will take place in the form of a change control board.
00:03:42 - A change control board is an organizational level change approval
00:03:47 - authority that will review project changes and determine whether
00:03:51 - or not that project makes sense or that change to the project
00:03:55 - makes sense in terms of overall
00:03:58 - organizational priorities and requirements. And if we have good
00:04:03 - effective change management in place, that we have proper approval
00:04:06 - processes through a change control board in place, this thing
00:04:10 - that I've written in the middle, which is scope creep, should
00:04:13 - disappear from our project. Scope creep is where we have small
00:04:19 - incremental changes happening,
00:04:25 - and I'm going to say daily,
00:04:28 - on our project that aren't analyzed, costed, sized, and approved.
00:04:33 - They are simply slipped in.
00:04:38 - But if we have the small incremental daily changes slipping in,
00:04:44 - all of a sudden, our deadline, our milestone, our schedule
00:04:50 - will slip
00:04:52 - by X weeks,
00:04:55 - and literally, we don't know why.
00:04:58 - It happened because we allowed scope creep to happen. Small incremental
00:05:04 - changes slipped in. It's our job as project managers to ensure
00:05:08 - we have effective integrated change management where all changes
00:05:13 - are analyzed, costed, sized, and approved, and then scope creep
00:05:18 - totally disappears.
00:05:21 - As I just stated, the key to successful change management is
00:05:25 - integrated change control, ensuring that every change, all changes
00:05:30 - are processed in a consistent fashion. And the best way to ensure
00:05:34 - we are doing things in a consistent fashion is to use a consistent
00:05:38 - form/template. And I'll share with you a model change control
00:05:46 - form/template that I have found to be very effective. By using
00:05:51 - this consistent change control form, we are ensuring that all
00:05:55 - changes are treated equally and all changes are assessed for
00:05:59 - the impact to the triple constraints primarily but also considerations
00:06:03 - for the other, the HR, the procurement, the risk, the human resource,
00:06:09 - and that we have effective communications throughout the organization.
00:06:13 - And to me, a key to effective communication is maintaining a
00:06:17 - change control log, which I will communicate.
00:06:24 - I will ensure
00:06:27 - stakeholders are aware,
00:06:33 - and I will use the change control log to manage
00:06:39 - all changes, all my change requests to closure.
00:06:46 - Often, the process of creating change controls will take time.
00:06:50 - From the point in time when the person first says, "Hey Steve,
00:06:55 - I think we need to add incremental functionality to the system,"
00:06:59 - to when that incremental functionality is analyzed, costed, assessed
00:07:05 - against the triple constraints, documented, presented back to
00:07:09 - the business for approval, and then finally, integrated into
00:07:12 - the project itself, a period of time, weeks
00:07:18 - can have transpired. By having a good effective change control
00:07:23 - log, we are using it as a communications tool and we are using
00:07:27 - it to manage the CR process, ensuring that no changes fall through
00:07:31 - the cracks. And again, in just a moment or two, I will share
00:07:35 - with you a change control log that I found to be very effective.
00:07:39 - So let's have a look at the first element, which is our change
00:07:42 - control form.
00:07:45 - And here is a project change request that I have found to be
00:07:48 - very effective in my projects. It's very straightforward but
00:07:52 - it certainly captures everything we need to have to do effective
00:07:58 - change management.
00:08:00 - A bit of indiscernible information at the top, the project name,
00:08:04 - the project manager, that would be my name, and as we've discussed
00:08:08 - with other forms filling in, a simple but straightforward and
00:08:14 - self-contained name for the change request. Change request to
00:08:20 - add sorry. I shouldn't even put the word change request. "Add
00:08:24 - business functionality for incremental
00:08:28 - customer support" would be a good request name for a change request.
00:08:34 - It describes the purpose of the change. And the reason we want
00:08:38 - a clear, self-contained,
00:08:42 - but short name for the change request, we're going to carry that
00:08:45 - name forward into our change request log. We will probably be
00:08:50 - referring to critical change requests by name in our status report,
00:08:55 - and we will certainly be referring to delinquent change request
00:08:59 - in the process by name in the status report, so we want to have
00:09:04 - a name that's meaningful. When we refer to the change request
00:09:08 - in the status report, we want everyone to clearly understand
00:09:11 - exactly what change we were referring to. A couple of key information
00:09:16 - that we are going to have on this change request form is the
00:09:19 - date issued, when was the change initiated, when did the business
00:09:25 - first asked for the change, and when do we expect to have final
00:09:33 - approval on the change? In some changes, we'll have a very short
00:09:36 - turnaround. It's a simple change. The analysis of the impact
00:09:40 - or the change may only take a couple of hours. We can turn the
00:09:44 - analysis around and back to the business on the same business
00:09:48 - day. And we can ask the business to give us an approval or a
00:09:51 - rejection of that change within two or three business days. So
00:09:55 - that turnaround would be very short. Other changes may be very
00:09:59 - large. It may take us a week of effort to determine the impact
00:10:04 - of the change. And then presenting that impact to the business,
00:10:08 - they may take another week or two weeks to do their cost/benefit
00:10:12 - analysis and to do their assessment of whether or not that change
00:10:16 - makes good business sense. But as project managers, we need to
00:10:21 - carefully manage the time frame between the date issued and the
00:10:26 - due date and ensure that
00:10:29 - all change requests are being given the proper attention, and
00:10:33 - that change requests are being closed. Otherwise, as I said,
00:10:36 - we will be starting to report on delinquent change requests in
00:10:39 - our status report, and we don't want to ever have to report on
00:10:43 - delinquency in a project, of course. Having said we want a clear,
00:10:48 - self-contained name, sometimes we just don't have the real estate
00:10:53 - to give the full name, so sometimes, we do abbreviate and say
00:10:58 - this is CR1 or CR15. Certainly not as descriptive as a good self-contained
00:11:05 - name, but at times, still effective for good management of the
00:11:09 - change processes itself.
00:11:12 - Very important indiscernible information, I think all fairly
00:11:16 - self-explanatory, having just spent several minutes explaining
00:11:20 - it. We get into the meat of the change request itself. The reason
00:11:25 - for the change,
00:11:26 - this would typically be the business justification, the business
00:11:31 - reason, the what. If we take it back to a systems development
00:11:36 - life cycle, what does the business want
00:11:41 - and who prepared it? So that as we are going through and doing
00:11:46 - our analysis of the change, we can go back to the person who
00:11:51 - prepared the change itself and get clarification.
00:11:55 - Then we come in to the real effort from a project viewpoint for
00:11:59 - the change is the description of the change.
00:12:04 - In order to achieve the what that was defined up here, here is
00:12:09 - what we need to do or, better still, here is how we are going
00:12:14 - to solve it, again, putting it in to the language of the systems
00:12:17 - development life cycle. The reason for the change is the what.
00:12:21 - The description for the change is the how. Here is how we are
00:12:24 - going to address your request for change. And again, the project
00:12:30 - team member, because typically, the description of the change
00:12:33 - is going to be filled in by the project team member, the project
00:12:36 - team member will identify him or herself here so that again,
00:12:40 - if clarification is required, we'll go back and be able to go
00:12:44 - to the person who did the analysis and the design on the change.
00:12:49 - Now we are starting to get into the impact,
00:12:52 - the cost. More times than not, that's the one single biggest
00:12:58 - number that the business wants to hear as it's dealing with project
00:13:03 - changes. "How much more is this going to cost me?" So I put in
00:13:08 - a succinct block in my project change request for the cost, and
00:13:13 - often, I will double duty here. I will say cost amount and
00:13:22 - schedule impact
00:13:25 - because again, those are the two big items, two of the three
00:13:30 - triple constraints.
00:13:32 - Triple constraints are cost, time, and scope. Well, really, the
00:13:38 - scope is what we are describing up here. Here is the impact.
00:13:42 - Here is the how. This is the change to the scope that this change
00:13:47 - is going to do. And here are our other two triple constraint
00:13:51 - components of the cost impact and the schedule impact, and again,
00:13:55 - who did it. Often, the same person who does the analysis and
00:14:00 - design on the change request will do the cost and schedule impact.
00:14:04 - But at times, it may be sent up the project management chain,
00:14:07 - and myself may do the cost impact and the schedule impact of
00:14:13 - the change. So again, it's important to document who does that.
00:14:16 - And then here is where we do the rest of the integrated change.
00:14:21 - What are the other ramifications of this change? What are the
00:14:24 - ramifications to the schedule if I didn't include it in here?
00:14:28 - What's the impact to the staffing? What's the impact to the risk?
00:14:34 - What's the impact to the procurement.
00:14:38 - What's the impact to the other parts of our project management
00:14:43 - focus, ensuring that each and every change request has the full
00:14:47 - discussion, full impact analysis across all of our project management
00:14:53 - components, and again, who did it. And with these, I'm going
00:14:58 - to say four simple blocks filled in. But as I've said already
00:15:03 - in my introduction, sometimes, it will take days or even weeks
00:15:07 - to fill in these four simple blocks. And if that change is that
00:15:12 - complex, often, these four simple blocks may span three or four
00:15:18 - or five, maybe even as many as 20 pages of description.
00:15:23 - A page or two from the business for the what, the reason for
00:15:26 - the change, five or six pages of the how, the analysis and the
00:15:32 - design results, the scope changes to our project, a page or two
00:15:36 - of the cost and schedule impact. If it's complex, maybe we are
00:15:40 - going to give them options. You can do this via A, via B, or
00:15:44 - via C. And again, a page or two for the impact to the risks of
00:15:49 - the project, to the procurement, to the other aspects of our
00:15:52 - project. We'll present all of that back to the business,
00:15:58 - and then we will get it approved.
00:16:01 - I believe I'm back in my soapbox again; sorry guys I believe
00:16:06 - that formal signature
00:16:09 - on acceptance documents, I also believe that formal signature
00:16:13 - on project change documents is vital. It signifies the importance
00:16:19 - of the project change. By approving this change, the project
00:16:24 - authority has given me the rights to change my project scope.
00:16:31 - They have given me the rights to change my project milestones
00:16:35 - and maybe even my project completion date, and they've given
00:16:38 - me the rights to change my project budget.
00:16:44 - And sometimes, these changes are significant, which again is
00:16:48 - why I suggest we should have formal signature, but we've discussed
00:16:51 - already that there are organizations where formal signature is
00:16:55 - a foreign concept. Therefore, I would request as a minimum that
00:16:59 - you get an e-mail approval or some other form of approval, or
00:17:05 - again, the worst case scenario is if I don't hear from you in
00:17:08 - the next two business days, I will be proceeding on the assumption
00:17:12 - that you have approved this change.
00:17:16 - But treat changes with care and attention,
00:17:21 - and treat changes with the appropriate
00:17:24 - degree of rigor. If it's a simple change, we may be able to fill
00:17:29 - in this entire form in a few hours. And if it's a complex change,
00:17:34 - it may take some time. And give it the proper care and attention
00:17:38 - to get approval on to the process itself. Now, in this discussion,
00:17:44 - I've had the connotation that changes are always incremental.
00:17:48 - We're adding scope. We're adding cost. We're changing our schedule.
00:17:53 - We're delaying our project implementation date. And that is typically
00:17:57 - the norm, but not all changes will be incremental.
00:18:02 - Partway through the project, the business realizes that hey,
00:18:06 - we don't need this functionality. Our business model has changed
00:18:11 - and we can remove functionality requirements from scope. Equally
00:18:16 - important to process that through the same change process. The
00:18:20 - only difference up here, the cost amount and the schedule, and
00:18:22 - that impact will be negative numbers rather than positive numbers.
00:18:28 - Project change requests should be submitted any time any project
00:18:34 - fact documented in the project management plan during project
00:18:40 - initiation changes. Now let me repeat that. Project change control,
00:18:48 - project change management should be applied any time a statement
00:18:53 - made in the PMP changes,
00:18:58 - changed to the positive, changed to the negative, or sometimes
00:19:03 - changed to the zero. We simply have documented a change of the
00:19:08 - accounting principle from LIFO to FIFO. The project management
00:19:12 - plan said the inventory would be validated via the LIFO accounting
00:19:17 - principle. Partway through the project, before any code has been
00:19:20 - written, before any analysis has been done, we've decided, or
00:19:24 - the business has decided to change it to the opposite.
00:19:28 - That's a change. No analysis, no design, no development has been
00:19:32 - done. The cost for implementing LIFO is considered to be identical
00:19:36 - to the cost of implementing FIFO. That still should be processed
00:19:41 - through with the same degree of discipline as any other change
00:19:45 - because we've changed a fact that was written in our project
00:19:49 - management plan. Treat project change with the care and attention
00:19:55 - that it has. And this thing that we are going to discuss in just
00:19:58 - a few minutes in this series called scope creep isn't going to
00:20:02 - come up and bite your project, destroy your project. So, with
00:20:08 - the change request form completed, our next step is to put that
00:20:11 - onto our change request log.
00:20:16 - The change request log is very simple to use and very straightforward.
00:20:19 - As you can see, we log each change to see our number one.
00:20:27 - The date was June 7th.
00:20:32 - The resolution date will be filled in as it's determined. This
00:20:36 - is the complete meaningful I can't
00:20:43 - even type and self-contained name. And the status is Open. The
00:20:48 - status is In Estimation.
00:20:53 - The status is Under Review. The status
00:20:58 - is Approved.
00:21:02 - And that's all there is to the project change request log. The
00:21:05 - key is keeping the log up to date. The key is communicating the
00:21:11 - log as part of regular status reporting. This project now has
00:21:17 - six change requests processed against it. Four of the six change
00:21:21 - requests have been approved, and the net impact to the project
00:21:24 - has been an incremental budget of $50,000 and a change of the
00:21:28 - milestone date by or final implementation date of three weeks.
00:21:35 - As we find change requests are not being actioned as quickly
00:21:40 - as possible, whether that's within our team because we don't
00:21:42 - have the time to do the analysis in the design, or the change
00:21:46 - request isn't being actioned quick enough within the business
00:21:50 - unit after we send it back for a review,
00:21:53 - as I said already, we need to take project management action
00:21:57 - on those and again, bring them out in our project status reports
00:22:01 - and let IT management know that the project is resource constrained
00:22:07 - and we have change requests not being acted on, or let the business
00:22:11 - community know that they are not turning the change requests
00:22:14 - around as quickly as possible. So you can see there is a lot
00:22:17 - of power in a very simple form that if we effectively manage
00:22:22 - this form, again, we are going to keep project change under control
00:22:27 - and we are going to manage project change and we are going to
00:22:31 - demonstrate to the business that change is not necessarily a
00:22:35 - bad thing. Change can be managed and change can be managed and
00:22:40 - still deliver predictable results for our project. I already
00:22:45 - talked extensively about this particular detail, but as we are
00:22:49 - examining each change, we need to ensure that we are examining
00:22:53 - the change on the triple constraints but we are also examining
00:22:57 - the change in its relationship to the quality, the human resource,
00:23:01 - the procurement,
00:23:03 - that we are doing this in an integrated fashion and that we are
00:23:06 - doing the appropriate communication of the change throughout
00:23:10 - the project. And with that, we have full integrated change management
00:23:15 - addressing each and every one of the disciplines of
00:23:19 - project management as defined for this CompTIA Certification
00:23:23 - as well as defined in the PMBOK Guide itself. Now, the other
00:23:28 - aspect of change that we need to talk about in this nugget is
00:23:33 - sources of change.
00:23:35 - All along in this nugget so far, I referred to change coming
00:23:41 - from the business, and that is certainly a significant
00:23:47 - source of project change. The business is going to need to add
00:23:53 - functionality. The business is going to need to change requirements.
00:23:56 - The business is going to have, make requests on the project to
00:24:01 - change the scope of our project as a result of refinement, as
00:24:05 - a result of better understanding, as a result of standard business
00:24:09 - process. But changes can come at our project from other aspects
00:24:13 - as well. Change can come out our project from within the project
00:24:17 - team. The team had assumed that we are going to use technology
00:24:23 - X when the project management planning was created. Now that
00:24:27 - we are trying to deliver under project X, we've discovered that
00:24:31 - X really wasn't an appropriate technology platform and Y is a
00:24:35 - far better technology platform. The fact that the original premise
00:24:41 - for the project that it was going to be X was documented in the
00:24:44 - project management plan says we need to process a change to change
00:24:51 - that fact in the project management plan. Internal, project-focused,
00:24:57 - change technology from X to Y. Changes can come at our project
00:25:03 - from literally any aspect, any area, anything that could possibly
00:25:10 - change the project. It can be from the scope. It can be from
00:25:15 - the team members, we need to change key team members. It can
00:25:18 - be a directive from senior management. It can be the economics.
00:25:23 - The project needs to scale down because we are in a recession,
00:25:26 - or the project needs to ramp up because we are going into a growth
00:25:29 - stage. It can come from the technical environment. It can come
00:25:32 - from the business environment. It can come from changing priorities
00:25:37 - within the organization. So be prepared for change coming at
00:25:42 - your project from every possible angle.
00:25:46 - And that's the perfect introduction to our next discussion on
00:25:49 - change, is this thing called Scope Creep. Recognizing
00:25:55 - that change can come out our project from any possible angle,
00:25:59 - not just the business,
00:26:01 - leads to this thing called scope creep. And scope creep is really
00:26:06 - best summed up with the fact that small incremental changes will
00:26:11 - happen to our project. The team is going through and doing an
00:26:15 - analysis and determines that X.1.3.4,
00:26:20 - assumption made during project planning is invalid, and they
00:26:24 - simply proceed with the updated change. The business comes in
00:26:29 - and says "No, that screen shouldn't be green. It should be yellow.
00:26:33 - The senior management says, "Steve, can you change the priority
00:26:38 - of your project to allow us to take one of your team members
00:26:42 - away?" So small incremental changes are going to happen on a
00:26:46 - project. As project managers, we have to resist the urge of simply
00:26:51 - saying, "Sure." Team members that change through X.,
00:26:58 - that's peanuts, that's less than half an hour's worth of change
00:27:04 - to the project, yes, just go do it. But if the fact was documented
00:27:09 - in the project management plan, we need to process the change,
00:27:13 - and that manages
00:27:18 - that small incremental change. It presents it,
00:27:23 - it makes it visible,
00:27:25 - and it gets approval.
00:27:29 - Same thing if the business said, "Steve, it shouldn't be yellow.
00:27:32 - It should be green. How long does it take to change a color on
00:27:36 - a screen? Minutes or seconds?"
00:27:40 - resist the urge to just say, "Sure, I'll do it. Manage the process.
00:27:45 - Make it visible. Get approval. If you are changing a fact in
00:27:51 - the PMP, the project management plan, it needs to be processed
00:27:55 - through change. Scope creep happens because we don't manage it,
00:28:00 - because there were open-ended requirements and we do refinement
00:28:03 - on the requirements, because the business has slow turning around
00:28:07 - decisions, or our technology within our project team itself is
00:28:10 - slow in decisions, and therefore, we make assumptions and we
00:28:13 - do changes. Perhaps we ourselves had a poorly written scope or
00:28:18 - project management plan so it wasn't clear. It wasn't obvious
00:28:22 - when change was happened. Change definitely happens, as I said,
00:28:26 - directly from the business, is to get refined understanding of
00:28:30 - the requirements or new requirements come up. And sometimes,
00:28:35 - yes, sometimes it happens that we have innovative developers
00:28:39 - who simply think they know a better way to code the business
00:28:43 - requirement than the way the analyst and the designers did it
00:28:47 - based on the raw business requirement. We have bored developers
00:28:51 - looking for new ways to tweak their programming tools and do
00:28:54 - something neat, cool, or spiffy.
00:28:57 - Every time
00:29:00 - there is a change,
00:29:03 - we need to document it and we need to prevent scope creep. I
00:29:08 - actually personally don't believe there is such a thing as scope
00:29:12 - creep. I believe we either have successfully managed CRR processes
00:29:19 - where all changes are effectively managed and approved, or if
00:29:24 - we don't have effective management of the change process, we
00:29:27 - don't have scope creep. We have scope gallop.
00:29:34 - And with scope gallop, every small change just incrementally
00:29:39 - goes into our project in a half hour here and a half a day there
00:29:44 - and a couple of days somewhere else. All of a sudden, our project
00:29:48 - has absorbed
00:29:49 - three weeks of incremental change, small, little bits, and all
00:29:55 - of a sudden, our project is now three weeks behind schedule because
00:29:58 - we haven't managed it. So be aware of scope creep. Scope creep
00:30:03 - can turn into scope gallop in days.
00:30:07 - And if we carefully manage change, the whole concept of scope
00:30:12 - creep is going to go away. We make the change visible and we
00:30:16 - get approval, and we can deliver predictable
00:30:22 - results. And our final discussion in this change management nugget
00:30:30 - is the concept of a change control board. And a change control
00:30:35 - board may or may not exist in your organization. Whether it exists
00:30:39 - or not in your organization is largely determined by the size
00:30:42 - of the organization and how project ties in organization is.
00:30:47 - So a large organization that has a lot of focus on projects will
00:30:52 - often have a change control board, where smaller organizations
00:30:56 - or organizations that don't do a lot of project work may not
00:31:00 - have a change control board.
00:31:03 - Whether or not your organization has a change control board or
00:31:06 - not, understand what a change control board is because there
00:31:10 - will be discussion, there will be questions on your Project Plus
00:31:15 - Certification Exam related to the usage of, the value of, the
00:31:20 - operation of a change control board.
00:31:24 - The good news is it's pretty straightforward. A change control
00:31:28 - board provides formal change authorization
00:31:33 - at the organizational level. We talked about preparing a change
00:31:37 - request, understanding what the change is, understanding the
00:31:41 - impact of the change, describing the impact and the triple constraints
00:31:44 - and the other areas that cost the schedule, et cetera, and presenting
00:31:48 - that for approval. Typically, we would always present it to the
00:31:52 - business for approval. They would say, "Yes, this change makes
00:31:56 - good sound business sense for me." And then with business approval,
00:32:01 - the change would then go to the formal change authorization at
00:32:05 - the organizational level, which meets to ensure that both the
00:32:10 - project and the organizational priorities and requirements are
00:32:15 - being achieved. So if we have a project that was approved at
00:32:20 - $50,000 with a cost/benefit
00:32:23 - of X,
00:32:27 - the organizational
00:32:30 - change control board is going to ensure that consistent with
00:32:35 - organizational priorities that this project was approved with
00:32:39 - that budget, with this cost/benefit payback period of such and
00:32:43 - such that with this change, this still makes
00:32:49 - organizational sense.
00:32:56 - Sure, the business says, "This still makes sense. I need this
00:33:00 - incremental change." But if the change has upped this to a $75,000
00:33:05 - project and our cost/benefit payback is now less by or has increased
00:33:12 - by a certain amount,
00:33:14 - the business may be told that, "Hey, your project has now been
00:33:20 - dropped in priority. We are getting less value from our money,
00:33:25 - our corporate money by investing in your project." Therefore,
00:33:28 - either A) your change request is going to be denied at the organizational
00:33:32 - level, or the overall priority of your project is going to be
00:33:36 - dropped because there are other organizational projects that
00:33:40 - need our rare and scarce organizational resources more. So a
00:33:45 - change control board, to sum this up, really is the same as an
00:33:48 - organizational approval board. It makes sure the right activities
00:33:53 - are taking place in the organization and that changes to approved
00:33:57 - projects continue to make sense from an organizational viewpoint.
00:34:02 - And that's what you really need to know for getting those questions
00:34:06 - on the Certification Exam itself right. And
00:34:10 - this concludes our Nugget on change control or change management.
00:34:15 - Change control, change management is really summed up in integrated
00:34:19 - change management where we focus all changes
00:34:24 - and we evaluate
00:34:28 - the impact
00:34:30 - on the triple constraints:
00:34:37 - dollars, time, and scope. We also assess the impact on the other
00:34:43 - PM areas:
00:34:46 - risk, procurement, human resources, communications,
00:34:50 - quality. We present all changes for approval,
00:34:57 - and then we formally add the impact,
00:35:02 - typically positive, incremental change of scope, time, and schedule,
00:35:07 - but we add the impact to the project management plan and we adjust
00:35:12 - the conditions under which the project is being delivered.
00:35:16 - If we have good effective change management in place, this thing
00:35:20 - called scope creep disappears because all changes are being effectively
00:35:24 - managed, and we don't have random changes to our project schedule
00:35:29 - brought about by saying, "Oh, sure. I'll give you that favor.
00:35:31 - Oh sure. Just slip that in. I'll do that." Effective project
00:35:35 - management or effective change management eliminates scope creep.
00:35:39 - And the last aspect to effective change management is depending
00:35:43 - on your organization itself, you may need to present the project
00:35:47 - changes to a change control board, which is simply an organizational
00:35:52 - change control board validating that changes to your projects
00:35:56 - are consistent with overall
00:35:59 - organizational strategies and overall organizational priorities. This
00:36:06 - concludes our nugget on project change management. I hope this
00:36:09 - module has been informative for you, and thank you very much
00:36:12 - for viewing.

Project Risk Management

Project Quality Management

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

Please help us improve by sharing your feedback on training courses and videos. 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.


Pick up where you left off watching a video.


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 assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer


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

Stay Connected

Get the latest updates on the subjects you choose.

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