98 Section 4
4.5.2 OTHER EXTERNAL COMMUNICATIONS
EVM is an effective tool for generating the information to communicate with stakeholders external to the project
team and performing organization.
The project team needs to (a) monitor and align stakeholders’ expectations, (b) negotiate planning and project
changes, and (c) monitor the performance of work accomplished by suppliers, partner organizations, or resources that
are outside of their direct control and authority.
The power and ability of the project team to exert positive and constructive influence over stakeholders and
contribute to project success is enhanced with the ability to:
Know (with rigor and accuracy) the true status of the work performed by external entities and stakeholders, and
Anticipate the likely outcomes and alternatives for work in an objective and auditable manner.
For example, EVM to-complete indices can be used to (a) identify unrealistic promises and commitments (often
well intended) that are put forward by suppliers or project teams and (b) negotiate and plan for realistic ways to
accommodate adversity and explore opportunities. Committing to unrealistic recovery plans as the project unfolds and
variations emerge is a common mistake and a poor practice that leads to project failure.
EVM data and information can be used to establish contractual performance obligations and incentives with
suppliers, sponsors, and clients and to establish performance appraisal targets for team members.
Once again, the project team should make every effort to involve all external stakeholders at a minimum level in the
EVMS. Involving all stakeholders should enable them to trust the information the project team produces and to accept
negotiations based on this information.
4.6 INTEGRATED CHANGE CONTROL
The PMB is the integrated plan against which project performance is measured. The PMB is maintained by project
management, and it is altered only in accordance with the integrated change process outlined within the project
management plan. Figure 3-4 in Section 3.3 displays the PMB relative to its subordinate elements. The relationship
of the elements shown to the PMB is addressed in Section 3.3.2.2.
As the project unfolds over time, the project management plan is refined in more detail, and as reserves are used
and converted into work scope and resources, the PMB is maintained to accurately reflect the expected project
outcome as formally approved by the stakeholders. Implementing integrated change control is a formal process
99
for evaluating these project changes, as outlined in Section 4.6 of the PMBOK
®
Guide. All of the Perform Integrated
Change Control processes from the PMBOK
®
Guide are used in EVM. An EVMS can provide enhanced inputs toward
data analysis and decision making during the integrated change control process. Changes are documented and
formally submitted as requests. Changes are then assessed, and either refused, deferred, or authorized. The decision
is recorded and communicated in a disciplined and timely manner. In order to make EVM effective over the span of the
entire project, the PMB should be updated to reflect approved change requests before they are implemented.
4.6.1 CHANGE REQUESTS
Change requests may result from project performance, an error in defining the scope of the project or product,
evolving requirements, a customer request, a change to a contract, a shift in the regulatory environment, a change in
funding, a change in the market, or the occurrence of a risk event (whether foreseen or not). Changes to the PMB may
occur when the existing cost, schedule, or scope is no longer realistic.
Changes that are approved are implemented, and the corresponding project management plan components, PMB,
and project documents are updated. Changes that are deferred or not approved are recorded in the change log
along with the reason for the decision. Effective change management requires disciplined records to carefully control
changes to the project and maintain the integrity of the PMB so that measurements are meaningful. Figure 4-8
provides an example of the type of information that could be recorded in a change log about a change request. This
is an example and is not inclusive of all information that could be included in a change log.
Change
Number
Origination
Date
Title/
Description
WBS Elements
Impacted
Justification
PMB
Impact
Status
Completion
Date
Figure 4-8. Change Log Example Information for a Change Request Affecting the Baseline
100 Section 4
4.6.2 CHANGE ANALYSIS
Changes to the project or product scope impact the resources, schedule, and cost of a project. The change control
process should account for the analysis that a scope change entails. Changes that do not impact the scope, such
as changes to the schedule or the costs, still impact the PMB. The change control process needs to ensure that the
integrity of the integrated baseline is not compromised because of these changes or due to external dependencies
that these changes impact.
A change control board (CCB) is frequently used to analyze the impact of scope, schedule, cost, and other types
of changes on the project and the PMB. The only changes that are implemented are those that are approved by the
change control board. On small projects, the project manager may act as the CCB.
4.6.2.1 SCOPE CHANGE ANALYSIS
All scope changes should be analyzed, the scope should be defined, and the impact on the CAs should be assessed.
In addition, the need to add new or delete existing CAs should also be determined. Not all changes to the scope result
in a cost or schedule impact; however, given the integrated nature of the PMB, it is probable that a scope change will
impact the other two areas.
When the scope of the project is changed, such as adding new scope, the PMB should be changed at the WBS level
where the scope change occurs.
When new work is added to the CA, the new work should be placed into one or more new work or planning
packages. When an existing WP needs to be modified, it should first be closed, then the remaining budget plus new
budget should be placed in a new WP. In the latter case, when closing the CA, make the current budget (i.e., the
cumulative-to-date PV) equal to EV. This eliminates the schedule variance (i.e., no work remaining to be accomplished
in the CA), but the CV is maintained at whatever value it has. Actual costs should not be changed for a CA that is
closed due to a scope change. Preserving this cost information maintains the historical CV, which contributes to the
project’s overall CV. The cumulative PV cannot be changed without changes to the scope and corresponding budget.
Cumulative AC or EV cannot be changed either, except to correct prior errors.
Work scope, when moved from one CA to another, is always moved together with its corresponding budget since
each budget allocation is authorized specifically for the WBS element to which it is assigned. This maintains the
integrity of the PMB. Budget should never be transferred to eliminate variances as this undermines the reporting
metrics and jeopardizes effective monitoring and control.
101
Often when scope changes occur, new CAs are created. When new scope is added, consider whether additional
management reserves (MRs) or contingency reserves (CRs) are needed. An analysis of new risks associated with the
additional scope may be performed. How these reserves are treated relative to the PMB is addressed in Section 3.3.2.2.
Although less frequent, it is possible for the project to be descoped through the change control process.
There are some applications of EVM where contractual requirements create situations in which the customer may
initiate a change that needs to be incorporated into the project immediately. The work should be authorized, planned,
and executed prior to negotiations on the pricing or cost for the change request. These types of customer-initiated
changes are referred to as authorized but unnegotiated changes. In these circumstances, the original contract or a
customer-issued letter with a not-to-exceed (NTE) amount should indicate how to manage this type of requested
change. The portion of the authorized but unnegotiated scope, which can begin immediately, is distributed directly to
the CA, and the PMB is modified. Typically, the bulk of the scope identified is for work not yet begun for downstream
CAs and WPs. In these cases, the remaining scope and associated value from the NTE letter are held in a higher-level
undistributed budget (UB) account. UB accounts should be resolved as quickly as possible, and the proposed scope
provided in an NTE letter should be negotiated as soon as practical.
When scope is added or deleted, the WBS and WBS dictionary should be updated to reflect the change in scope. The
risk register, cost management plan, and scope management plan may need to be examined and updated accordingly.
4.6.2.2 COST AND SCHEDULE CHANGE ANALYSIS
It is possible to have changes that do not impact the project scope but still impact the cost and/or the schedule—
these will have an impact on the PMB. For example, make-or-buy decisions related to the project procurement
strategy could cause changes in the cost or schedule that are best incorporated into the PMB. All changes should
be analyzed, and the impact on the CAs should be assessed. As mentioned previously, when implementing scope
changes, the maintenance of historical variances is required, and the elimination of variances is prohibited except to
correct prior errors in reported data.
When cost and schedule are changed, the project management plan and associated project documents may need
to be examined and updated accordingly.
102 Section 4
4.6.3 REBASELINING
Rebaselining refers to updating the PMB as a result of any approved changes to the schedule, cost, or project
scope. A rebaseline equates to a required realignment of the PMB. The desired result from a rebaseline is to improve
the integration of the cost, scope, and schedule baselines. To be useful, the PMB should represent a realistic project
management plan with attainable objectives. Managing performance against an obsolete baseline is of no value to
project monitoring and control.
The rebaseline takes one of two forms:
Replanning. Replanning involves a realignment of the remaining schedule and/or a realignment of the
remaining budget to meet the original target.
Reprogramming. Reprogramming is a comprehensive effort to revamp the PMB. The result of this activity is
an over-target baseline (OTB) or over-target schedule (OTS). An OTB includes additional budget in excess of
the original budget allocation. An OTS occurs when the scheduled work and the associated budgets are time
phased beyond the original completion date.
The OTB is an acknowledgment that the current PMB cannot be executed within the current project constraints.
Essentially, cost and schedule objectives have become unattainable such that a secondary baseline should be
used to provide meaningful measurement metrics.
The OTB is an attempt to attain project performance objectives in the context of new cost parameters. However,
unless the causes for the CVs are identified and rectified, the OTB will not be effective. All parties should focus
on the conditions that led to the CVs and agree on the proper corrective actions to take. In some cases, this
may be recognition that the original cost objectives were unrealistic. For example, it is possible that the original
estimates did not account for the risk component of the estimate.
The OTS acknowledges that the current schedule is unattainable and cannot be executed within the timeframes
required. The OTS is an attempt to attain the project performance objectives in the context of new schedule
parameters. However, unless the causes for the schedule variances are identified and rectified, the OTS will
not be effective. All parties should focus on the conditions that led to the schedule variances and agree on the
proper corrective actions to take. In some cases, this may confirm that the original schedule objectives were
unrealistic.
The result of any of the previous actions described in this section is a new PMB. As explained earlier, replanning and
reprogramming should only modify the baseline information corresponding to future status and actions. Rebaselining
should not hide any of the issues experienced in the project up to this point. Once the rebaseline is completed, it needs
to be formally approved, communicated, and accepted.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.