45
are created for the same WBS scope due to the changing nature of the team. One example of this is moving
from a design focus team to a testing focus team.
What level of the WBS is a logical point to manage? This can be influenced by:
Make-or-buy decisions,
Level of risk, and
Level of criticality to the project, either cost, schedule, and/or performance.
What is the availability of trained/capable CA managers?
Will the work be divided up by project life cycle, control points, or reviews?
This is often done because the composition of a team usually changes when a WBS item passes through the
project life cycle from design, first article, testing, or other phases.
When building the CA structure, it is important to include 100% of the WBS being measured across the
project life cycle. That is, all of the work to be measured should be represented when the work within the CA is
summarized. It is permissible for multiple organizations (frequently called performing organizations) to work on the
scope within a CA; however, management responsibility and accountability belong to only one organization (the
responsible organization). For EVM, the OBS needs to represent the responsible organization’s structure with the
responsible people or the empowered integrated project team (IPT). In many cases, the IPT has multifunctional or
multiorganizational representation, which allows for teams to be more product oriented. This can result in the OBS
structure aligning with the WBS structure.
Whenever work and budget moves into, out of, or within the project, one or more CAs change. Any change should
always be reflected on the responsibility assignment matrix and authorized through change control. This approach
provides the project manager with a continuously updated picture of all of the work and budget that is associated
with a project. When CAs have only a planning package within a future rolling wave planning process, it’s possible
that a particular organization might not be identified; however, the WBS components should be clear and cover all of
the work to be measured with EV within the PMB. In these cases, the control account should be owned by the project
manager until the work is further broken out and assigned to a particular individual or team.
3.3.2 RISK MANAGEMENT
In order to navigate uncertainty, the outputs of the risk management processes as described in the PMBOK
®
Guide should be incorporated into the PMB. The objective of risk management is to exploit or enhance positive risks
(opportunities) and to avoid or mitigate negative risks (threats) in order to optimize the chances of project success.
46 Section 3
Risk management planning processes identify risks (see Section 11.2 of the PMBOK
®
Guide), analyze risks both
qualitatively (Section 11.3 of the PMBOK
®
Guide) and quantitatively (Section 11.4 of the PMBOK
®
Guide), and plan
risk responses (Section 11.5 of the PMBOK
®
Guide) for the uncertainties, both positive and negative, on the project
baseline.
To incorporate risk considerations within the baselines, the project team conducts qualitative and quantitative
risk analysis (scope, schedule, and cost) along with developing and incorporating into the baselines the planned risk
responses. Integrating the outputs of the risk management processes with EVM enables early insight into scope,
schedule, and cost estimates by comprehending the expected probability of a threat or opportunity occurrence related
to schedule and cost estimate impact.
The project management plan incorporates risk responses/mitigations in various forms according to the risk
management plan and risk register. Some responses may require updating the project baselines (cost, schedule,
and scope) up front, while others may require changing the plan baselines only after reaching specific emerging
circumstances (or risk triggers). The contingent responses should be planned and then included in work packages or
planning packages. For example, a contingency plan may be implemented when the probability of a high-impact risk
increases significantly after a risk trigger point has been reached, thus causing a replan of the baseline by moving
the contingency to a specific WP/activity. EVM and risk management are best consolidated at the CA level under the
responsibility of the manager of the CA. The movement of a contingency to a specific WP/activity goes through the
change control process.
The implementation of risk responses, up front or later in the project, affects the expected rate at which the project
work will be executed. The PMB should account for this factor. Information from the risk register, which may be
included in the PMB, contains the items listed in Sections 3.3.2.1 and 3.3.2.2.
3.3.2.1 AGREED-UPON RESPONSE STRATEGIES
Risk responses, which usually involve effort for both negative and positive risks, impact the scope, schedule, and/
or cost baselines of specific CAs within the project. These responses need to be planned within the baseline work.
Additionally, project resilience depends, in part, on how the project team sets the risk tolerance and risk appetite (risk
avoidance or risk seeking) and to what extent contingency and/or management reserves are used. Stakeholder risk
appetite should be considered and EVM variance thresholds appropriately adjusted depending on the established
risk tolerance. Risk responses that are planned are incorporated into the PMB along with contingencies, while the
management reserves are outside the baseline. The CA manager can handle the assigned risk and the responsibilities
for managing the risk responses and contingencies on the project. Thus, the CA manager, in many instances, becomes
the risk owner.
47
3.3.2.2 MANAGEMENT AND CONTINGENCY RESERVES
Contingency reserves are used for identified risks that are accepted and those risks for which contingent responses
are devised. These reserves can fund contingency plans when they need to be implemented or can fund a necessary
reaction to a risk after it occurs. Contingency reserves may be global to the overall project or may be allocated to
specific control accounts.
Contingency reserves are not used for the purpose of masking overruns. Instead, these reserves are determined as a
result of understanding identified risks and their potential impacts and are placed at the appropriate levels within the PMB.
While it is expected that contingency reserves will be consumed to accommodate evolving risk responses or realized
risk impact, there may be situations when the risk is either greater or lesser than initially estimated. In these cases, it is
appropriate that a variance be recorded. Based on existing OPAs, the project team may decide, especially when impacts
are significant, to adjust the future baseline through the change control process. The PMB is not going to be as effective as
a management tool when the baseline is significantly different from the plan the project team is following. When reserves,
whether too robust or not robust enough, have the team significantly off the baseline, the project team and stakeholders
should consider baseline changes. Often, OPAs and EEFs drive environments when the original baselines are maintained
for historical purposes while additional baselines are established for effective management of the remaining work.
The PMBOK
®
Guide, The Standard for Risk Management in Portfolios, Programs, and Projects [6], Practice Standard
for Project Risk Management [7], Practice Standard for Scheduling [8], and Practice Standard for Project Estimating
[9] cover additional information regarding the use of risk responses and reserves to address the impact of risks on the
cost, schedule, or scope baselines. When using EV, any risk response, which includes activities that expend budget,
needs to be assigned within a CA, and the activity captured in the project’s scope, schedule, and cost baselines.
3.3.3 SCOPE BASELINE
The scope baseline, comprised of the project scope statement, WBS, and WBS dictionary, aligns with work and
planning packages and provides information on all of the product and project deliverables against which execution
and delivery are compared. Scope realization data, generated from the accomplishment of project scope, should
be planned at the appropriate WBS activity level for WPs within the CAs. The basis for collecting the scope data is
determined by the measurement method selected. The criteria, sometimes called the rules of credit, are outlined and
documented during planning in the development of the project scope definition that is captured in the WBS dictionary
and the WP and activities. Consideration should be given to deliverable quality.
When planning the scope baseline, the project team should consider how the scope data will be collected. The
adequate measurement of the volume of scope accomplished based on a specific point in time and, especially at the
end of each project control period (e.g., week, month), should be considered. The collection of scope realization and
48 Section 3
validation data includes information about project progress such as which activities or work packages have started,
what their progress is, which have finished, and projecting when others will be accomplished. How this data is
planned will impact how it is collected. It is used in the determination and measurement of EV and other EVM metrics
as outlined in Section 4.4.
3.3.4 SCHEDULE BASELINE
The schedule baseline represents the approved version of a schedule model that can be changed using formal
change control procedures and is used as the basis for comparison to actual results over time. When integrated with
the project budget, the schedule baseline forms the basis for the development of the PMB. At any given point in time,
and especially at the end of each project control period (e.g., week, month), the schedule data describe what and how
much project work was planned to be performed.
The term schedule is often used to mean both the schedule model and the output of activities with associated
dates. For clarity and consistency with the PMBOK
®
Guide, this standard defines (a) the project-specific data within
the scheduling tool as schedule model and (b) the resulting outputs, based on the project-specific data, as schedule
model presentations.
The schedule model includes all the time-related attributes used in the representation of the project management
plan for executing the project’s activities, for example, baseline start and finish dates, durations, dependencies, and
other activity definitions and scheduling information. The basis for schedule data is outlined and documented during
planning in the development of the integrated master schedule and determination of measurement methods to be
used in the EVMS, as described in Section 3.2.2.2.
Developing the schedule model is the process of translating all of the WBS components into a sequential, time-
phased model for project execution. Resource loading the schedule model at the activity level is not required for the
application of EVM; however, it is a recommended practice that lends credibility to the PMB.
The project schedule integrates the activities associated with each WBS component and identifies dependencies
between project activities as well as the dependencies that are external to the project. The schedule model can be
decomposed and presented at various levels of detail.
This standard focuses on those schedule components having specific relevance to the practice of EVM. Therefore,
for purposes of this section, it is assumed that the scheduling processes covered in the PMBOK
®
Guide are followed.
For an overview of what is considered good practice on most projects most of the time for scheduling, refer to Section 6
of the PMBOK
®
Guide. For a more extensive treatment on the definition and implementation for project scheduling
practices, refer to the Practice Standard for Scheduling.
49
3.3.4.1 SCHEDULE STRUCTURE
The schedule model, following good schedule practices, also needs to consider the need for EVM. The key is to
build the schedule structure logic to not only reflect the WBS, but also the CA structure. Consider the integrated master
schedule as the integration of all the individual CA detailed-level schedules. Within each CA’s schedule, there should
be a clear linkage to WPs and planning packages.
3.3.4.2 SCHEDULE AND BUDGET RELATIONSHIP
The relationship between the schedule model and the budgeting system is maintained throughout the life of the
project. The PV is derived using the same assumptions as the scheduling model. The same WBS and set of other
budget elements (CAs, WPs, and planning packages) should exist in both systems. Certain attributes of these, such
as start and finish dates, budgets or weighting, and organizational responsibility, should always remain consistent
between the budget and the schedule. The estimated cost (labor hours, direct material dollars or monetary units,
travel, etc.) should be allocated to the work package or activity in the schedule that it supports, but it is not necessary.
The minimum requirement is to allocate cost to the control account level. To ease the administrative burdens of
keeping the cost and schedule baselines in sync, a resource-loaded (cost) schedule may be used. The result of the
resource-loaded schedule is an integrated model of the time-phased budgeted plan. These schedules can also have
the WBS dictionary, rules of credit based on the selected measuring method, basis of estimate for costs, and other
information incorporated, thus providing a single model that represents the PMB.
Once the project schedule model is reviewed and agreed to by all of the project stakeholders, it is saved and stored
as the project schedule baseline and forms the basis for the time-phased PMB. Section 4.6 addresses maintenance
of the baselines.
3.3.4.3 SCHEDULE MODEL
The schedule model represents the time phasing for execution of the project’s scope of work. The project schedule
reflects the total project scope of work as defined in the WBS and, to a sufficient level of granularity, the plan,
implementation, and control of the project. Both the high-level master schedule and the highest level of the WBS
represent the overall project scope. Lower levels of the WBS correspond to equivalent levels of the schedule, extending
this concept to control accounts, work packages, and planning packages. Figure 3-7 is the initial detailed schedule
portion of the overall project schedule presentation. It represents the schedule model for the example in Appendix
X4, which has activities over five quarters. Near-term activities are detail planned into work packages. The schedule
is further detail planned during rolling waves (see the example in Appendix X4). Refer to the Practice Standard for
Scheduling for further details on developing a schedule model.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.