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.22.214.171.124.9,
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.