Once a change has been requested, at some point in the process someone is going to ask you what the impact of the change is on the project. You'll be required to assess the impact of the change and report on the impacts it will have on the various project plans. Changes will almost always affect at least one of the following, if not several of the following: scope, project schedule, budget, or quality.
Note:Here's the third rule of change: Budget changes almost always require changes to the project schedule, scope, quality, or a combination of the three. Schedule changes almost always require changes to the budget, scope, quality, or a combination of the three. Scope changes always require changes to the project schedule and may require changes to the budget, quality plan, or any combination of the three.
Keep in mind that just because a change is requested doesn't mean it has to be implemented. That's one of the reasons you go through the effort to create a scope statement. Perhaps your stakeholders are asking for a change that is out of scope for the project and is recorded as an out-of-scope requirement in the scope statement document. You can remind them, by showing them a signed copy of the scope statement if needed, that their request is documented as out of scope for this project.
Remember that time equals money, so even if the change doesn't impact the budget directly but it impacts the time required to complete the tasks, it still indirectly impacts the cost of the project. If all your project team members are on staff and the tasks take longer than originally planned, their salaries are charged to the work of the project longer than originally planned, so indirectly, the cost of the project has risen. And, the end product doesn't reach the customer, or the marketplace, until the delayed completion date, which means that the ability of the company to collect revenue on the product of the project is delayed.
Calling in Reinforcements
Your first step in examining how changes will impact the project is to get the project planning documents together. You begin by reviewing the change requested against the associated planning documents. The impact of some changes will be obvious. Start by noting those changes and ask yourself how they may impact other parts of the project that are not so obvious.
Use some of the techniques we discussed in previous chapters, such as brainstorming, to come up with ideas, impacts, and all the project areas that may be affected. Involve stakeholders and project team members to help you uncover all the possible impacts of change and any risks associated with the change.
Usually you'll find that change requests fall into one of three areas: scope change, schedule change, or budget change. We'll look at these categories of change to see how changes in these areas may impact the project, how to assess their impact, and how to make adjustments to accommodate the changes.
Three questions should be examined for each of the changes we'll discuss:
Start examining how the change affects the project by asking these three questions. The third question should be examined by the project team to determine whether there are ways to accommodate the results of the change while reducing the impact or coming up with other ways to get the same results.
Adjusting for Scope and Schedule Changes
Scope changes are probably the most frequent type of change requested on a project. In this section we'll look at how scope changes are requested, what questions to ask to help you assess their impact, and how they affect the schedule. Remember that scope changes always require schedule changes, so we'll cover both of those types of changes here.
Scope changes include any changes to the deliverables or requirements of the project. In Chapter , "Defining the Project Goals," we discussed how any modification to the agreed-upon WBS is considered a scope change. You'll recall that the WBS details the project deliverables, summary tasks, and tasks. Therefore, changes to any of these items constitute a change in scope.
First, let's look at how scope changes are requested and what types of information you need to assess their impact. Figure 11.1 shows a sample change request template. Your project team or stakeholders can use this template to request any type of change, including scope changes. We've already discussed most of the elements on this form. Each heading has a brief explanation beneath it describing the kinds of information the requestor and project manager should provide.
Modify this template for use on your projects. And don't forget to file these in your project notebook. I recommend putting these in an appendix or starting a separate notebook for change requests. If you're keeping this information online, create a directory just for change requests and the change request-tracking log. Be sure to note the tracking number from the change request log on the top of this form.
Modifying the Scope and Schedule
When the scope change is approved, you'll need to adjust the project schedule to accommodate the change. Remember that changes to scope always require changes to the project schedule. In order to do this, you'll need to assess how the changes affect the project and what adjustments you need to make to accommodate the changes. Things you can do to help make adjustments for scope and schedule changes include the following:
Once the changes have been approved, the project manager should adjust the project schedule to account for the changes. Communicate those changes—including new tasks, new due dates, modified tasks or dates, and so on—to the project team members. Discuss scope and schedule changes as part of your regular team meetings.
Adjusting the Project Schedule
Sometimes you'll be asked to shorten the project schedule even after it's been approved and the Executing phase has begun. Reasons for this new urgency may include a new marketing opportunity, the sponsor's fear of a budget cut before the project can be completed, or a scope change that may require shortening the schedule.
There are two techniques for shortening, or compressing, the schedule. The first is called fast tracking. As an example, let's say that the team writing the technical users guide for a software programming project starts writing the manual at the same time the testing team is testing the modules. Originally, the writers were not going to start until the testing phase was complete, but by starting the two activities at the same time, the schedule is shortened.
A schedule compression technique that starts two tasks at the same time that were originally scheduled to start sequentially.
The second technique for shortening the schedule is called crashing. Crashing is a technique that weighs cost and schedule trade-offs. For example, you may consider adding resources to the critical-path tasks to crash the schedule. Adding resources will shorten the amount of time needed to complete these tasks. (Remember that adding resources to the noncritical-path tasks won't help because noncritical-path tasks don't impact the schedule.) Another technique of crashing is limiting or reducing the project requirements. This will also sometimes shorten the project schedule if the tasks related to these requirements are on the critical path.
A schedule compression technique that examines ways to reduce the duration of critical-path tasks.
Crashing isn't always an option because the results may negatively impact the project. Always check the critical path after using this technique because the critical path may change. You may have some tasks drop off the critical path while others that were not critical are now considered critical. Fast tracking doesn't always work either. There is often a reason for tasks starting one after another, especially for quality control or completeness of the product.
Managing and Revising Costs
Changes to the budget come about for several reasons, including incorrect estimating techniques, schedule overruns, and inadequate WBS development. These items are within your control as the project manager and they underscore the importance of proper project Planning techniques.
Budget changes that come about due to circumstances you can't control include the schedule and scope changes we discussed in the previous section, fixed budgets that are set from the beginning of the project, and corrective actions taken to get the project back in line with the project plan. All of these conditions may lead to budget revisions.
The first step in adjusting the budget is to determine the revised cost estimates. Review the original estimates and confirm your assumptions regarding those estimates. Realize that the product or service you planned to purchase may have changed, been upgraded, or been modified somehow, which affects the original estimate and the cost of the product today. If you're bringing in new resources or materials that weren't previously included in the budget plan, you need to acquire estimates for those items and include them in the updated budget.
Next you must update the budget with the new costs. Include narrative information that describes why the updates or additions are necessary, and note the change request tracking number associated with the budget update. Get approval of the updated budget from the project sponsor, and distribute copies of the new budget to the appropriate folks.
Project Management Related Tutorials
|Business Analyst Tutorial||Strategic Planning for Project Management Tutorial|
|Software Development Lifecycle (SDLC) Tutorial|
Project Management Related Interview Questions
|Business Analyst Interview Questions||Strategic Planning for Project Management Interview Questions|
|Network Monitoring Interview Questions||Software Development Lifecycle (SDLC) Interview Questions|
|Business process outsourcing (BPO) Interview Questions||Project Manager Interview Questions|
|PMP Interview Questions|
Project Management Tutorial
Building The Foundation
Developing Project Management Skills
Initiating The Project
Defining The Project Goals
Breaking Down The Project Activities
Planning And Acquiring Resources
Developing The Project Plan
Executing The Project
Controlling The Project Outcome
Closing The Books
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.