Inputs of Plan Scope Management

Know the following four inputs of the Plan Scope Management process:

Project Management Plan To help inform what the project is intended to accomplish, the project management plan with all of its approved subsidiary plans are used to help create the scope management plan.

Project Charter As the project charter helps to communicate the high-level goals, business needs, assumptions, and constraints, it is used in this process to align the scope management plan with stakeholder expectations.

Enterprise Environmental Factors Several enterprise environmental factors can influence the Plan Scope Management process, including but not limited to the organization’s culture, its infrastructure, marketplace conditions, and personnel administration.

Organizational Process Assets Policies, procedures, and historical information, including a lessons learned knowledge base, are a few of the organizational process assets that help shape the scope management plan.

Tools and Techniques of Plan Scope Management

The two tools and techniques that the Plan Scope Management process uses are expert judgement and meetings:

Expert Judgment Input that is received from experienced team members and those who are knowledgeable about the project area provide what is considered to be expert judgment. Be sure that you look to all corners of your organization for any person or group with specialized education or training, or who might possess knowledge, skills, and/or experience in helping to develop the scope management plan.

Meetings In the course of developing the scope management plan, members of project teams may attend meetings to help with information exchange and decision making. Depending on the meeting, the following members might be a part of the discussion to include: project manager, project sponsor, selected project team members, and anyone having responsibility in this area.

Outputs of Plan Scope Management

For the exam, know the outputs of the Plan Scope Management process. This includes, naturally, the scope management plan, as well as the requirements management plan.

The components of this plan include processes for

• Preparing a detailed project scope statement
• Creating a WBS from the detailed project scope statement
• Establishing how the WBS will be maintained and approved
• Specifying how formal acceptance will be obtained for completed project deliverables
• Controlling and handling change requests to the detailed project scope statement

Inputs of Collect Requirements

Know the following inputs of the Collect Requirements process:

Scope Management Plan The scope management plan provides direction on how members of the project pick the type of requirements needed to be collected for the project.

Requirements Management Plan The requirements management plan helps define and document the stakeholders’ wants and needs.

Stakeholder Management Plan We will cover the stakeholder management plan in the “Developing a Stakeholder Management Plan” section later in this chapter. For the collect requirements process, the stakeholder management plan is used to document the stakeholder communication requirements and their level of engagement. This will help the project team adjust the requirements activities to the level of stakeholder participation that is needed.

Project Charter In this process, the high-level project requirements and product description are used from within the project charter.

Stakeholder Register In this process, the stakeholder register is used as a way of determining who can provide the necessary information on the project and product requirements.

Tools and Techniques of Collect Requirements

Know the following tools and techniques that can be used during the Collect Requirements process:

• Interviews
• Focus groups
• Facilitated workshops
• Group creativity techniques
• Group decision-making techniques
• Questionnaires and surveys
• Observations
• Prototypes
• Benchmarking
• Context diagrams
• Document analysis

Interviews Interviews allow subject matter experts and experienced project participants to impart a lot of information in a short amount of time. The following are characteristics of interviews:

• Typically structured as a one-on-one conversation with stakeholders
• Can be formal or informal
• Consist of questions prepared ahead of time

Focus Groups Focus groups are usually conducted by a trained moderator. The key to this tool lies in picking the subject matter experts and stakeholders to participate in the focus group; they then engage in discussion and conversation as a way of imparting their feedback about the project’s end result.

Facilitated Workshops Cross-functional stakeholders come together in a facilitated workshop to discuss and define requirements that affect more than one department. The following are characteristics of facilitated workshops:

• All the participants of the workshops understand the various project needs.
• The workshops provide a facilitated forum to discuss and resolve their participants’ issues.
• A consensus is reached more easily than through other methods.

Group Creativity Techniques Group creativity involves the following techniques:

Group Decision-Making Techniques According to the PMBOK ^® Guide, several group decision-making techniques are used. The four methods mentioned are as follows:

• Unanimity, where everyone agrees on the resolution or course of action
• Majority, where more than 50 percent of the members support the resolution
• Plurality, where the largest subgroup within the group makes the decision if a majority is not reached
• Dictatorship, where one person makes the decision on behalf of the group

Questionnaires and Surveys Questionnaires and surveys involve querying a large group of participants via questionnaires or surveys and applying statistical analysis, if needed, to the results. This is considered to be a quick way of obtaining feedback from a large number of stakeholders.

Observations Observations consist of a one-on-one experience where an observer sits side by side with the participant to observe how the participant interacts with the product or service. This technique is also known as job shadowing; it can also involve participant observers who perform the job themselves to ascertain requirements, or the observation of a group of participants performing a job function. Observations are particularly useful when stakeholders have a difficult time verbalizing requirements.

Prototypes Prototyping is a technique involving constructing a working model or mock-up of the final product for participants to experiment with. The prototype does not usually contain all the functionality the end product does, but it gives participants enough information that they can provide feedback regarding the mock-up. This is an iterative process where participants experiment and provide feedback, the prototype is revised, and the cycle starts again. Prototypes are a great way of getting feedback during the early stages of a project’s life cycle.

Benchmarking Ever like to see how you measure up against other organizations or internal projects? With benchmarking there is a comparison of actual or planned practices against comparable organizations to measure performance, to glean new ideas to be used to improve your organization, and to identify best practices.

Context Diagrams Use of context diagrams helps to visually represent the product scope by mapping a business system with the people and other systems that interact with that business system. This is done by displaying the business system inputs and user roles, and then depicting the inputs, outputs, and user roles for those who receive the output.

Document Analysis Another technique used in the identification of requirements is documents analysis, where existing documentation is reviewed to see if there is relevant information to complete the requirements. According to the PMBOK^® Guide, a great variety of documents could be scrutinized, including but not limited to the following:

• Business plans
• Marketing materials
• Contractual agreements
• Requests for proposals
• Business processes or interface documentation
• Use cases
• Problem/issues logs
• Policies and procedures
• Regulatory documents

Outputs of Collect Requirements

For the exam, know the outputs of the Collect Requirements process, which are as follows:

Requirements Documentation This output involves recording the requirements in a requirements document. According to the PMBOK^® Guide, this document includes at least the following elements:

• Business need for the project and why it was undertaken
• Objectives of the project and the business objectives the project hopes to fulfill
• Stakeholder requirements, including impacts to other organizational areas
• Functional requirements
• Nonfunctional requirements
• Quality requirements
• Acceptance criteria
• Business rules
• Organizational areas and outside entities impacted
• Support and training requirements
• Assumptions and constraints
• Signatures of the key stakeholders

Requirements Traceability Matrix The traceability matrix links requirements to business needs and project objectives and also documents the following:

• Where the requirement originated
• What the requirement will be traced to
• Status updates all the way through delivery or completion

Table 3.1 shows a sample traceability matrix with several attributes that identify the requirement.

Here are the characteristics of a traceability matrix:

• Each requirement should have its own unique identifier.
• A brief description includes enough information to easily identify the requirement.
• The source column refers to where the requirement originated.
• Priority refers to the priority of the requirement.
• The test scenario records how the requirement will be tested or during which project phase, and test verification indicates if it passes or fails the test.
• Status may capture information about the requirement that refers to whether the requirement has been approved to be included in the project. Examples include added, deferred, and canceled.

After requirements have been gathered, the next step is to begin breaking down and documenting the project and product’s scope. The end result will be a WBS, which is a deliverable-oriented, high-level decomposition of the project work. But before the WBS can be generated, a few additional steps must be addressed:

• The creation and sign-off of the project scope statement
• The creation of a scope baseline

The project scope statement is an output of the Define Scope process and is where the project deliverables are documented along with the constraints and assumptions of the project. Once the project scope statement, WBS, and another output called the WBS dictionary are created, they become part of a scope baseline.

Inputs of Define Scope

The Define Scope process has four inputs you should know:

Scope Management Plan The scope management plan outlines how this process is to be carried out.

Project Charter From within the project charter, this process primarily utilizes the project objectives. Objectives are quantifiable criteria used to measure project success. They describe what the project is trying to do, accomplish, or produce. Quantifiable criteria should at least include the following items:

• Schedule
• Cost
• Quality measures
• Business measures or quality targets (sometimes)

Requirements Documentation The requirements documentation includes elements such as functional and nonfunctional characteristics, quality metrics, and acceptance criteria. For a more detailed description, see “Outputs of Collect Requirements” earlier in this chapter.

Organizational Process Assets This process uses historical information from within the organizational process assets as well as policies, procedures, and project scope statement templates.

Tools and Techniques of Define Scope

Know the following tools and techniques that you will use during the Define Scope process:

Expert Judgment According to the PMBOK^® Guide, the following items are examples of expert judgment used in this process:

• Subject matter experts or consultants
• Stakeholders
• Industry groups and associations
• Other departments or units internal to the organization

Product Analysis Product analysis is a method for converting the product description and project objectives into deliverables and requirements. According to the PMBOK^® Guide, product analysis might include performing the following to further define the product or service:

• Value analysis
• Functional analysis
• Requirements analysis
• Systems-engineering techniques
• Systems analysis
• Product breakdown
• Value-engineering techniques

Alternatives Generation Alternatives generation is a technique used for discovering different methods or ways of accomplishing the work of the project. Examples of alternatives generation are brainstorming and lateral thinking.

Lateral thinking is a process of separating problems, looking at them from angles other than their obvious presentation, and encouraging team members to come up with ways to solve problems that are not apparently obvious or look at scope in a different way. This can also be described as out-of-the-box thinking.

Facilitated Workshops Facilitated workshops involve stakeholders coming together to discuss and define requirements that affect more than one department.

Outputs of Define Scope

Know the following outputs of the Define Scope process:

Project Scope Statement The purpose of the project scope statement is to document the project objectives, deliverables, and the work required to produce the deliverables so that it can be used to direct the project team’s work and as a basis for future project decisions. The project scope statement is an agreement between the project organization and the customer that states precisely what the work of the project will produce.

According to the PMBOK^® Guide, the project scope statement should include all of the following:

• Product scope description
• Product acceptance criteria
• Project deliverables
• Project exclusions
• Project constraints
• Project assumptions

Project Documents Updates Project documents encompass those documents from within the project that are not plans or baselines. There may be several common updates and changes to project documents resulting from this process:

• Original project objectives
• Stakeholder register
• Requirements documentation
• Requirements traceability matrix
• The scope statement as a result of approved changes

Inputs of Create WBS

For the exam, know the following inputs of the Create WBS process:

Scope Management Plan The scope management plan is a planning tool that documents how the project team will define project scope, how changes to scope will be maintained and controlled, and how scope will be verified.

Project Scope Statement The project scope statement contains information valuable to creating the WBS, most notably the list of project deliverables.

Requirements Documentation The requirements documentation describes how the requirements meet the business needs of the project.

Enterprise Environmental Factors In addition to enterprise environmental factors that have already been discussed, there may be industry-specific WBS standards that are relevant to the type of project that you are undertaking. If so, that information may serve as an additional reference to the creation of the WBS.

Organizational Process Assets This process uses historical information from within the organizational process assets as well as policies, procedures, and WBS templates.

Tools and Techniques of Create WBS

The Create WBS process has two tools and techniques: decomposition and expert judgment.

Decomposition Decomposition involves breaking down the project deliverables into smaller, more manageable components of work that can be easily planned, executed, monitored and controlled, and closed out.

The project manager typically decomposes the work with the help of the project team, whose members have expert knowledge of the work. Benefits of team involvement include a more realistic decomposition of the work and getting team buy-in.

Decomposition provides a way of managing the scope of the project and also does the following:

• Improves estimates
• More easily assigns performance measures and controls
• Provides a baseline to compare against throughout the project or phase
• Ensures that assignments go to the proper parties

According to the PMBOK^® Guide, decomposition consists of the following five-step process:

1. Identify the deliverables and work.
2. Organize the WBS.
3. Decompose the WBS components into lower-level components.
4. Assign identification codes.
5. Verify the WBS.

Expert Judgment For creating the WBS, expert judgment is routinely used to start breaking down project deliverables by analyzing the information available. Don’t forget that expert judgment can also come in the form of predefined templates, which provide instructions on how to effectively break down common deliverables. Templates can come from the industry you are working in, or created by your organization as a result of experience gained from performing similar projects.

Outputs of Create WBS

The Create WBS process has two outputs:

• Scope baseline
• Project documents updates

Scope Baseline The scope baseline for the project is the approved project scope statement, the WBS, and the WBS dictionary. These documents together describe in detail all the work of the project. The documents allow managers to carry out the following activities:

• Document schedules
• Assign resources
• Monitor and control the project work

Work Breakdown Structure (WBS) The following are various ways of organizing the WBS:

The following is a general description of the various levels within the WBS:

Collectively, all the levels of the WBS roll up to the top so that all the work of the project is captured. According to the PMBOK^® Guide, this is known as the 100 percent rule.

Here are the other elements of the WBS that you should know:

Project Documents Updates The following documents may need to be updated as a result of this process:

• Project scope statement
• Requirements documentation
• Any other project documents that should reflect approved changes to the project scope statement

Inputs of Plan Schedule Management

Similar to the Plan Scope Management process, you will need to know the following four inputs of the Plan Schedule Management process:

Project Management Plan To help inform what the project is intended to accomplish, the project management plan with all of its approved subsidiary plans is used to help create the schedule management plan. Specifically, the scope baseline and other information about risk, cost, and communication decisions are used to help create the schedule.

Project Charter In regard to this process, the project charter is used to define the summary milestone schedule and the requirements to obtain project approval as it relates to managing the project schedule.

Enterprise Environmental Factors Several enterprise environmental factors can influence the Plan Schedule Management process, including but not limited to the organization’s culture, its infrastructure, project management software that provides the scheduling tool and schedule alternative generation, published commercial information, and organizational work systems.

Organizational Process Assets Quite a few process assets influence the Plan Schedule Management process, including but not limited to these:

• The use of monitoring and reporting tools
• Schedule control tools
• Historical information
• Policies, procedures, and guidelines related to formal and informal schedule control
• Templates
• Project closure guidelines
• Change control procedures
• Risk control procedures

Tools and Techniques of Plan Schedule Management

The three tools and techniques that the Plan Schedule Management process uses are expert judgment, analytical techniques, and meetings:

Expert Judgment Expert judgment brings invaluable perspective about prior similar projects attempted, as well as the existing environment that will affect the project. This can also be useful in considering how to combine methods of schedule planning and how to best resolve differences between those methods.

Analytical Techniques Most management involves picking between different options, and it is no different for this process. Plan schedule management may ask you to pick between strategic options to estimate and schedule the project like the scheduling methodology, which scheduling tools and techniques to use, estimating approaches, formats, and project management software. As the project develops, the schedule management plan may require analysis to determine options that fast track or crash the project schedule. Remember, that these options may introduce risk to the project, so don’t forget to update the risk register.

Meetings In the course of developing the schedule management plan, members of project teams may attend schedule development meetings. Depending on the meeting, the following members might include the project manager, project sponsor, selected project team members, and anyone having responsibility in this area.

Outputs of Plan Schedule Management

The primary output of the Plan Schedule Management process is the schedule management plan.

The components of this plan establish the following:

• Project schedule model development, which specifies the methodology and tools to be used
• Level of accuracy, which sets the tolerances used to determine realistic activity duration estimates and the amount needed for contingencies
• Units of measure, which could be vital depending on the industry the project is in and whether the project involves multiple countries
• Organizational procedure links, as provided by the framework of the WBS
• Project schedule model maintenance, or a model for updating status and progress of the project
• Control thresholds, which establish the variance thresholds for monitoring schedule performance and define the amount of variation the project can sustain before some action must be performed
• Rules of performance measurement, where physical measurement, rules of performance measurement, or earned value measurement rules are set
• Reporting formats and frequency of reports
• Process descriptions for each of the schedule management processes

Inputs of Define Activities

You should know the following inputs of the Define Activities process:

Schedule Management Plan The critical input from this plan is the defined level of detail needed to manage the work.

Scope Baseline The scope baseline takes into account the following:

• Work packages, from within the WBS
• Constraints and assumptions, from within the project scope statement

Enterprise Environmental Factors Enterprise environmental factors include the project management information system; the organizational culture and structure; and published, commercially available information.

Organizational Process Assets The organizational process assets provide existing guidelines and policies, historical project documents (such as partial activity lists from previous projects), and a lessons-learned knowledge base, all of which are used for defining the project activities.

Tools and Techniques of Define Activities

You can use the following three tools and techniques in the Define Activities process:

Decomposition Decomposition in this process involves breaking the work packages into smaller, more manageable units of work called activities. Activities are individual units of work that must be completed to fulfill the deliverables listed in the WBS.

Rolling Wave Planning Rolling wave planning is a form of progressive elaboration that involves planning near-term work in more detail than future-term work. As the work progresses, the work that was once considered future-term is then broken out into more granular detail.

Expert Judgment Expert judgment helps define activities and involves project team members with prior experience developing project scope statements and WBSs.

Outputs of Define Activities

The following are outputs of the Define Activities process:

Activity List Activity lists contain all the schedule activities that will be performed for the project, with a scope-of-work description of each activity and an identifier so that team members understand what the work is and how it is to be completed.

Activity Attributes Activity attributes describe the characteristics of the activities and are an extension of the activity list. Activity attributes will change over the life of the project, as more information is known.

During the early stages of the project, activity attributes typically consist of the following:

• Activity ID
• WBS identification code it’s associated with
• Activity name

As the project progresses, the following activity attributes may be added:

• Predecessor and successor activities
• Logical relationships
• Leads and lags
• Resource requirements
• Constraints and assumptions associated with the activity

Milestone List Milestones are major accomplishments of the project and mark the completion of major deliverables or some other key event in the project. The milestone list documents several things:

• Records the accomplishments
• Documents whether a milestone is mandatory or optional
• Becomes part of the project management plan
• Helps develop the project schedule

Inputs of Sequence Activities

Within the Sequence Activities process, you will use the following inputs:

• Schedule management plan
• Activity list
• Activity attributes
• Milestone list
• Project scope statement
• Enterprise environmental factors
• Organizational process assets

Schedule Management Plan The schedule management plan clarifies the tools and methods to be used in scheduling, which informs how activities may be sequenced.

Activity List To sequence activities, you would first need to acquire the activity list as an input. The activity list includes the activities along with their identifiers and a description of the work’s scope.

Activity Attributes Activity attributes may reveal information on the sequencing of activities, such as through predecessor or successor relationships.

Milestone List Milestone lists may contain milestones with scheduled dates. These dates might impact the sequencing of activities.

Project Scope Statement The product scope description in the project scope statement includes product details that may be used for sequencing activities.

Enterprise Environmental Factors Sequence activities may be influenced by enterprise environmental factors such as government or industry standards, the project management information system, schedule tool, and any company work authorization systems.

Organizational Process Assets The project files found within the corporate knowledge base are used from within the organizational process assets for scheduling purposes.

Tools and Techniques of Sequence Activities

You will need to be familiar with the following tools and techniques of the Sequence Activities process:

• Precedence diagramming method (PDM)
• Dependency determination
• Leads and lags

Precedence Diagramming Method The precedence diagramming method (PDM) uses boxes or rectangles to represent the activities (called nodes). The nodes are connected with arrows showing the dependencies between the activities. This method is also called activity on node (AON). PDM uses only one-time estimates to determine duration.

The following information is displayed on a node:

• Activity name (required)
• Activity number (optional)
• Start and stop dates (optional)
• Due dates (optional)
• Slack time (optional)
• Any additional or relevant information (optional)

The following illustration shows a general example of a PDM, or AON.

The PDM is further defined by the following four types of dependencies, also known as logical relationships:

Dependency Determination Dependencies are relationships between the activities in which one activity is dependent on another to complete an action, or perhaps an activity is dependent on another to start an action before it can proceed. Dependency determination is a matter of determining where those dependencies exist.

The following are four types of dependencies, defined by characteristics:

Arrow Diagramming Method The arrow diagramming method (ADM) technique isn’t used nearly as often as PDM. ADM is visually the opposite of the PDM. The arrow diagramming method places activities on the arrows, which are connected to dependent activities with nodes. This method is also called activity on arrow (AOA). Characteristics of the ADM technique are as follows:

• ADM allows for more than one-time estimates to determine duration and uses only the finish-to-start dependency.
• Dummy activities may be plugged into the diagram to accurately display the dependencies.

The following illustration shows a general example of the ADM method.

The following illustration is meant to help you remember the difference between PDM and ADM for the exam.

Leads and Lags Consider applying leads and lags when determining dependencies:

Outputs of Sequence Activities

There are two outputs of the Sequence Activities process that you should be familiar with:

Project Schedule Network Diagrams Like the WBS, the project schedule network diagrams might contain all the project details or contain only summary-level details, depending on the complexity of the project. Summary-level activities are a collection of related activities also known as hammocks. Hammocks are a group of related activities rolled up into a summary heading that describes the activities likely to be contained in that grouping.

Project Documents Updates The following project documents may require updates as a result of this process:

• Activity lists
• Activity attributes
• Milestone list
• Risk register (for an introduction to the risk register, see “Outputs of Identify Risks” later in this chapter)

Figure 3.12 shows the position of the Sequence Activities process in relation to the other time management processes.

Inputs of Estimate Activity Resources

You should know the following inputs for the Estimate Activity Resources process:

• Schedule management plan
• Activity list
• Activity attributes
• Resource calendars
• Risk register
• Activity cost estimates
• Enterprise environmental factors
• Organizational process assets

Schedule Management Plan To help assist in determining the resources to be estimated, the schedule management plan identifies the level of accuracy and the units of measure.

Activity List The activity list is necessary to know which activities will need resources.

Activity Attributes The activity attributes provide the details necessary to come up with an estimate of the resources needed per activity.

Resource Calendars Resource calendars describe the time frames in which resources are available and include the following:

• Skills
• Abilities
• Quantity
• Availability

Resource calendars also examine the quantity, capability, and availability of equipment and material resources that have a potential to impact the project schedule.

Risk Register The risk register helps inform how risk events can disrupt resource selection and availability.

Activity Cost Estimates The activity cost estimates are necessary to know how cost may impact resource selection.

Enterprise Environmental Factors Information on the resource availability and skills can be obtained through enterprise environmental factors.

Organizational Process Assets Information from previous similar projects, and policies and procedures relating to staffing and equipment purchase and rental, are used from within the organizational process assets.

Tools and Techniques of Estimate Activity Resources

The tools and techniques within the Estimate Activity Resources process include the following:

• Expert judgment
• Alternatives analysis
• Published estimating data
• Bottom-up estimating
• Project management software

Expert Judgment Individuals with experience and knowledge of resource planning and estimating can be tapped for information and guidance used within this process.

Alternatives Analysis Alternatives analysis helps to make decisions about the possible resource types (such as expert or novice) and methods that are available to accomplish the activities. Make-or-buy analysis can also be used for decisions regarding resources.

Published Estimating Data Estimating data might include organizational guidelines, industry rates or estimates, production rates, and so on.

Bottom-Up Estimating Bottom-up estimating is used when an activity cannot be confidently estimated. With the help of experts, the activity is broken down into smaller components of work for estimating purposes and then rolled back up to the original activity level. This is an accurate means of estimating, but it can be time-consuming and costly.

Project Management Software Within this process, project management software can help in the following ways:

• Plan, organize, and estimate resource needs
• Document resource availability
• Create resource breakdown structures
• Create resource rates
• Create resource calendars

Outputs of Estimate Activity Resources

Three outputs result from carrying out the Estimate Activity Resources process:

Activity Resource Requirements Activity resource requirements describe the types of resources and the quantity needed for each activity associated with a work package. The description should include the following:

• How estimates were determined
• Information used to form the estimate
• Assumptions made about the resources and their availability

Resource Breakdown Structure The resource breakdown structure (RBS) is a hierarchical structure that lists resources by category and type. Figure 3.14 illustrates a basic example of what an RBS may look like.

Here are some examples of categories:

• Labor
• Hardware
• Equipment
• Supplies

Here are some examples of types:

• Skill levels
• Quality grades
• Cost

Project Documents Updates Project document updates include updates to the following items:

• Activity list
• Activity attributes
• Resource calendars

Inputs of Estimate Activity Durations

You should be familiar with several inputs of the Estimate Activity Durations process:

• Schedule management plan
• Activity list
• Activity attributes
• Activity resource requirements
• Resource calendars
• Project scope statement
• Risk register
• Resource breakdown structure
• Enterprise environmental factors
• Organizational process assets

Schedule Management Plan The schedule management plan sets the approach used and the level of accuracy required to estimate activity durations including the project update cycle.

Activity List The list of activities is necessary to estimate the activity durations.

Activity Attributes Information included within the activity attributes will influence the activity duration estimates.

Activity Resource Requirements The availability of the assigned resources will impact the duration of the activities.

Resource Calendars Information from the resource calendars that influences this process is as follows:

• Type, availability, and capability of human resources
• Type, availability, capability, and quantity of equipment and material resources

Project Scope Statement Constraints and assumptions are considered when estimating activity durations.

Risk Register The list of risks is necessary, along with the results of risk analysis and risk response planning.

Resource Breakdown Structure The resource breakdown structure provides a hierarchical view of the identified resources. This then provides key information that will help estimate activity durations.

Enterprise Environmental Factors Enterprise environmental factors used include the following items:

• Internal reference data for estimating durations
• External reference data available commercially
• Defined productivity metrics

Organizational Process Assets The following organizational process assets are used:

• Historical information from previous similar projects, including duration information, project calendars, and lessons learned
• Scheduling methodology

Tools and Techniques of Estimate Activity Durations

The six tools and techniques of the Estimate Activity Durations process are as follows:

• Expert judgment
• Analogous estimating
• Parametric estimating
• Three-point estimating
• Group decision-making techniques
• Reserve analysis

Expert Judgment Expert judgment used includes staff members who will perform the activities and is based on their experience with past similar activities. When estimating durations, experts should consider the following:

• Resource levels
• Resource productivity
• Resource capability
• Risks
• Any other factors that can impact estimates

Analogous Estimating Analogous estimating is commonly used when little detail is available on the project. For a complete description of analogous estimating, see “Tools and Techniques of Estimate Costs” later in this chapter.

Parametric Estimating Parametric estimating is a quantitatively based estimating method that multiplies the quantity of work by the rate. It is considered to be a quick and low-cost estimating technique, with a good level of accuracy when used with actual historical data and current market conditions that take inflation or other factors into consideration. The best way to describe it is with an example:

• Activity: install fifteen 10×10 drapes.
• Average time to install one 10×10 drape, based on previous experience: 30 minutes.
• Estimate: Therefore, installing 15 drapes at an average 30-minute installation time per drape results in an estimated duration of 7.5 hours.

Three-Point Estimating Three-point estimating uses the average of the following three estimates to result in a final estimate:

The concept of the three-point estimate comes from the Program Evaluation and Review Technique (PERT), which uses the following formula to determine the weighted average using the three duration estimates:

In the following example, the Most Likely (ML) estimate = 15, the Optimistic (O) estimate = 11, and the Pessimistic (P) estimate = 25.

Thus, the activity duration = 16.

Group Decision-Making Techniques It is helpful to have multiple alternatives for future actions when estimating activity durations, and the group decision-making technique is an assessment process that delivers those alternatives. By engaging team members, it helps to improve estimate accuracy and commitment to the emerging estimates, which has the byproduct of helping win the hearts and minds of those contributing to the project.

Reserve Analysis Reserve time—also called buffer/time reserves or contingency reserve in the PMBOK^® Guide—is the portion of time added to the activity to account for schedule risk or uncertainty. To make sure the project schedule is not impacted, a reserve time of the original estimate is built in to account for the problems that may be encountered.

• Original activity duration to install fifteen 10×10 drapes: 7.5 hours.
• 10 percent reserve time added: 45 minutes.
• Estimate: Therefore, the new activity duration is adjusted to include the reserve, resulting in an estimated duration of 8.25 hours.

Outputs of Estimate Activity Durations

There are two outputs of the Estimate Activity Durations process you should know:

• Activity duration estimates
• Project documents updates

Activity Duration Estimates Activity duration estimates are estimates of the required work periods needed to complete the activity. This is a quantitative measure usually expressed in hours, weeks, days, or months.

Final estimates should contain a range of possible results, such as X hours ± 10 hours, or a percentage may be used to express the range.

• Original activity duration to install fifteen 10×10 drapes: 7.5 hours.
• Final estimate: 7.5 hours ± 1 hour. Therefore, the activity may take as little as 6.5 hours or as much as 8.5 hours.

Project Documents Updates The following information may need to be revisited and updated as a result of this process:

• Activity attributes
• Assumptions made regarding resource availability and skill levels

Inputs of Develop Schedule

The Develop Schedule process has 13 inputs you should be familiar with:

• Schedule management plan
• Activity list
• Activity attributes
• Project schedule network diagrams
• Activity resource requirements
• Resource calendars
• Activity duration estimates
• Project scope statement
• Risk register
• Project staff assignments
• Resource breakdown structure
• Enterprise environmental factors
• Organizational process assets

Schedule Management Plan The scheduling method and tool used to create the schedule, and how the schedule is formulated, is identified through the schedule management plan.

Activity List Developing the project schedule requires the project activities, which are obtained from the activity list developed in the Define Activities process.

Activity Attributes Activity attributes provide the necessary details of the project activities, which will be utilized in creating the project schedule.

Project Schedule Network Diagrams The sequence of events will be important in creating the project schedule. The activity sequence and existing dependencies can be obtained from the project schedule network diagrams. For a more complete description of the project schedule network diagrams, see “Outputs of Sequence Activities” earlier in this chapter.

Activity Resource Requirements Activity resource requirements will provide the types and quantity of resources needed for creating the project schedule.

Resource Calendars Resource calendars display availability of project team members and other resources, which will help to avoid schedule conflicts.

Activity Duration Estimates Activity duration estimates will provide the time to complete each activity that is needed to assign start and finish dates.

Project Scope Statement Constraints and assumptions are used from within the project scope statement. The following time constraints are important to this process:

• Imposed dates to restrict the start or finish date of activities
• Key events/major milestones to ensure the completion of specific deliverables by a specific date

Risk Register Developing the project schedule requires the details of all identified risks and their characteristics that will affect the schedule model.

Project Staff Assignments Developing the project schedule requires the project staff assignments, which specify resource assignments for each activity.

Resource Breakdown Structure Developing the project schedule requires resource analysis and the need to determine organizational reporting, which is provided by the resource breakdown structure.

Enterprise Environmental Factors Existing holidays and other external information that could impact the project schedule may be used from within the enterprise environmental factors.

Organizational Process Assets Within the organizational process assets, project calendars may exist that provide information on working days and shifts that can be used in this process.

Tools and Techniques of Develop Schedule

The Develop Schedule process has several tools and techniques you can use:

• Schedule network analysis
• Critical path method
• Critical chain method
• Resource optimization techniques
• Modeling techniques
• Leads and lags
• Schedule compression
• Scheduling tool

Schedule Network Analysis Schedule network analysis involves calculating early and late start dates and early and late finish dates for project activities to generate the project schedule. In short, it generates the schedule through the use of the following analytical techniques and methods:

• Critical path method
• Critical chain method
• Modeling techniques
• Resource optimization techniques

Critical Path Method Critical path method (CPM), a schedule network analysis technique, determines the amount of float, or schedule flexibility, for each of the network paths by calculating the earliest start date, earliest finish date, latest start date, and latest finish date for each activity. This technique relies on sequential networks and a single duration estimate for each activity. PDM can be used to perform CPM. Here is some information related to CPM that you should know:

• When activities become tasks on the critical path as a result of having used up all their float time
• When a milestone on the critical path is not met

Float There are two types of float time, also called slack time:

• Total float (TF), or the amount of time you can delay the earliest start of a task without delaying the ending of the project
• Free float (FF), or the amount of time you can delay the start of a task without delaying the earliest start of a successor task

Calculating the Forward and Backward Pass A forward pass is used to calculate the early start and early finish date of each activity on a network diagram. To calculate a forward pass, follow these steps:

1. Begin with the first activity.
2. The calculation of the first activity begins with an early start date of zero. Add the duration of the activity to determine the early finish.
3. The early start date of the next activity is the early finish date of the previous activity. Continue calculating the early start and early finish dates forward through all the network paths while following the existing dependencies.
4. When an activity has two connecting predecessors, the early start date would be the early finish of the predecessor that finishes last. (For example, suppose activity A has an early finish of 4 and activity B has an early finish of 5. If activities A and B both converge at activity C, then activity C would have an early start date of 5.)

A backward pass is used to calculate the late start and late finish date of each activity on a network diagram. To calculate a backward pass, follow these steps:

1. Begin with the last activity. The late finish will be the same as the early finish date.
2. Subtract the duration of the activity from the end date to calculate late start. This becomes the late finish of its predecessors.
3. Continue calculating the latest start and latest finish dates moving backward through all of the network paths.
4. When an activity has two connecting predecessors, the late finish date would be the late start of the activity that follows. (For example, if activity C has a late start of 7 and both activity A and activity B connect to activity C, the late finish of both activity A and B would be 7.)

Figure 3.17 summarizes a forward and backward pass.

Calculating the Critical Path A critical path task is any task that cannot be changed without impacting the project end date. By definition, these are all tasks with zero float. To determine the CP duration of the project, add the duration of every activity with zero float.

Another way to determine the critical path is by determining the longest path within the network diagram. This can be done by adding the duration of all the activities within each path of the network.

Using Table 3.2, set up a network diagram using the activity number, activity description, dependency, and duration. Next, practice calculating the early start, early finish, late start, and late finish dates. Check your answers against the dates shown on the chart and by referencing Figure 3.18.

Calculating Expected Value Using PERT PERT and CPM are similar techniques: CPM uses the most likely duration to determine project duration, whereas PERT uses what’s called expected value (or the weighted average). Expected value is calculated using the three-point estimates for activity duration.

Calculating Standard Deviation The formula for standard deviation is as follows:

For data that fits a bell curve, the following is true:

• Work will finish within ± 3 standard deviations 99.73 percent of the time.
• Work will finish within ± 2 standard deviations 95.44 percent of the time.
• Work will finish within ± 1 standard deviation 68.27 percent of the time.

Critical Chain Method The critical chain method is a schedule network analysis technique that will modify the project schedule by accounting for limited or restricted resources. The modified schedule is calculated, and it often changes the critical path as a result of adding duration buffers, which are nonworking activities added to help manage the planned activity durations. The new critical path showing the resource restrictions is called the critical chain.

Critical chain uses both deterministic (step-by-step) and probabilistic approaches. The following are steps in the critical chain process:

1. Construct the schedule network diagram using activity duration estimates (you’ll use nonconservative estimates in this method).
2. Define dependencies.
3. Define constraints.
4. Calculate the critical path.
5. Enter resource availability into the schedule.
6. Recalculate for the critical chain.

A project buffer is placed at the end of the critical chain to help keep the finish date from slipping. After the buffers are added, the planned activities are then scheduled at their latest start and finish dates.

Resource Optimization Techniques Resource optimization techniques are used when the supply and demand of resources necessitate an adjustment to the schedule model. They attempt to smooth out the peaks and valleys of total resource usage through strategic consumption of float while also addressing any overcommitment of individual resources through rescheduling or reassignment. Examples include but are not limited to the following:

Modeling Techniques There are multiple types of modeling techniques that a project manager can use in developing the schedule. Two examples that you should be familiar with for the exam include what-if scenario analysis and simulation.

Leads and Lags A lead accelerates the start date of an activity by the number of days specified, whereas a lag delays the start date of an activity. Leads and lags were first used in the Sequence Activities process, discussed earlier in this chapter.

Schedule Compression Schedule compression is a form of mathematical analysis that’s used to shorten the project schedule without changing the project scope. To be effective, work compressed must be based on those activities that fall on the critical path. There are two types of schedule compression techniques:

Scheduling Tool The scheduling tools used are typically in the form of project management software programs. They will automate the mathematical calculations and perform resource-leveling functions.

Outputs of Develop Schedule

Know the following outputs of the Develop Schedule process:

• Schedule baseline
• Project schedule
• Schedule data
• Project calendars
• Project management plan updates
• Project documents updates

Schedule Baseline The schedule baseline can be described as the final, approved version of the project schedule with baseline start and baseline finish dates and resource assignments. The PMBOK^® Guide notes that the schedule baseline is a designated version of the project schedule that’s derived from the schedule network analysis. The approved project schedule becomes a part of the project management plan.

Project Schedule The project schedule details the start and finish dates for each project activity as well as the resource assignments. In PMBOK^® Guide terms, the project schedule is considered preliminary until resources are assigned. The following are additional elements of the project schedule:

• The project schedule should be approved and signed off by stakeholders and functional managers.
• For functional organizations, confirmation that resources will be available as outlined in the schedule should be obtained.
• The schedule cannot be finalized until approval and commitment for the resource assignments outlined in it are received.
• Once approved, the schedule becomes the schedule baseline for the remainder of the project.

The following are various ways of displaying the project schedule:

Inputs of Plan Cost Management

Know the following four inputs of the Plan Cost Management process:

Project Management Plan The project management plan contains elements used to create the cost management plan focusing on, but not limited to, the following:

• Scope baseline; elements like the project scope statement and WBS provide details for cost estimation and management
• Schedule baseline, which helps clarify when project costs will be incurred
• Other information, including cost-related scheduling, communication decisions, and risk

Project Charter The project charter has the summary budget, a key input to creating the detailed project costs.

Enterprise Environmental Factors Several enterprise environmental factors can influence the Plan Cost Management process, including but not limited to the organization’s culture and structure, marketplace conditions, currency exchange rates (if the project is multinational), published commercial information such as resource cost rate information, and the project management information system.

Organizational Process Assets Financial controls procedures; historical information, including a lessons learned knowledge base; financial databases; and existing formal and informal cost estimating and budgeting-related policies, procedures, and guidelines are a few of the organizational process assets that help shape the Plan Cost Management process.

Tools and Techniques of Plan Cost Management

The three tools and techniques that the Plan Cost Management process uses are expert judgement, analytical techniques, and meetings:

Expert Judgment Expert judgment brings invaluable perspective about prior similar projects attempted, as well as the existing environment that will affect the project. This can also be key in considering whether to combine methods of cost planning and how to best resolve differences between those methods.

Analytical Techniques You may have many strategic options to consider when developing the cost management plan. Those options include self-funding, funding with equity, or funding with debt. Financial options will be influenced by the organization’s policies and procedures, including but limited to payback period, return on investment, internal rate of return, discounted cash flow, and net present value.

Meetings In the course of developing the cost management plan, members of project teams may attend meetings to help with information exchange and decision making. Depending on the meeting, the following members might be a part of the discussion to include: the project manager, the project sponsor, selected project team members, and anyone having responsibility in this area.

Outputs of Plan Cost Management

For the exam, know that the output of the Plan Cost Management process is the cost management plan.

Cost Management Plan The cost management plan should establish the following:

• Units of measure, such as quantity and time measures, and currency to be used
• Level of precision, which is the degree to which activity cost estimates will be rounded up or down
• Level of accuracy, which is the acceptable range used in determining contingencies and realistic activity cost estimates
• Organizational procedures links, where the WBS provides the framework for the cost management plan to help foster consistency with estimates, budgets, and controls
• Control thresholds, which document the identified variation that can occur before some action needs to be taken
• Rules of performance measurement, like the rules for earned value management (EVM), and which techniques to use

• Reporting formats defining the form and frequency of various cost reports
• Process descriptions for the other cost management processes
• Additional details such as explanations of strategic funding choices, how to deal with currency exchange rate fluctuations, and the procedure for project cost recording

Inputs of Estimate Costs

You should be familiar with these seven inputs of the Estimate Costs process:

• Cost management plan
• Human resource management plan
• Scope baseline
• Project schedule
• Risk register
• Enterprise environmental factors
• Organizational process assets

Cost Management Plan The cost management plan is a key input that specifies how project costs will be managed and controlled, including the method to be used and level of accuracy targets required to estimate cost activity.

Human Resource Management Plan For the purposes of the Estimate Costs process, the following elements of the human resource management plan should be considered:

• Personnel rates
• Project staffing attributes
• Employee recognition or rewards programs

Scope Baseline The following are included within the scope baseline and are used in creating cost estimates:

• Project scope statement (key deliverables, constraints, and assumptions)
• WBS, which serves as the basis for estimating costs (project deliverables, control accounts)
• WBS dictionary

Project Schedule Activity resource requirements and activity duration estimates are used from within the project schedule and serve as key inputs when estimating costs.

Risk Register From within the risk register, the cost of mitigating, avoiding, or transferring risks will be used for estimating costs, particularly when the risks have negative impacts to the project.

Enterprise Environmental Factors According to the PMBOK^® Guide, the following enterprise environmental factors should be considered in this process:

• Market conditions, which help you to understand the materials, goods, and services available in the market and what terms and conditions exist to procure those resources.
• Published commercial information, which refers to resource cost rates. These are obtained from commercial databases or published seller price lists.

Organizational Process Assets The organizational process assets include historical information and lessons learned on previous projects of similar scope and complexity. Also useful are cost-estimating worksheets from past projects as templates for the current project.

Tools and Techniques of Estimate Costs

The following list includes the tools and techniques of the Estimate Costs process:

• Expert judgment
• Analogous estimating
• Parametric estimating
• Bottom-up estimating
• Three-point estimating
• Reserve analysis
• Cost of quality
• Project management software
• Vendor bid analysis
• Group decision-making techniques

Expert Judgment Cost estimates from individuals who have had previous experience in the past on similar projects can be used. Information from those who have experience in performing the activities becomes valuable for calculating accurate estimates.

Analogous Estimating Analogous estimating, also called top-down estimating, is a form of expert judgment. This technique uses actual costs of a similar activity completed on a previous project to determine the cost estimate of the current activity. It can be used when the previous activities being compared are similar to the activities being estimated. Analogous estimating may also be useful when detailed information about the project is not yet available. Top-down estimating techniques are also used to estimate total project cost to look at the estimate as a whole. Although analogous estimating is considered to be a quick and low-cost estimating technique, it is low in accuracy.

Parametric Estimating Parametric estimating uses historical information and statistical data to calculate cost estimates. For a complete description of parametric estimating, see “Tools and Techniques of Estimate Activity Durations” later in this chapter.

Bottom-Up Estimating This technique estimates costs associated with every activity individually by decomposing that activity into smaller pieces of work until the cost of the work can be confidently estimated. The costs of the activity are then rolled up to the original activity level.

Three-Point Estimating Three-point estimates are used in this process when the project team is attempting to improve estimates and account for risk by estimating uncertainty.

Reserve Analysis During this process, cost reserves (or contingencies) and management reserves are added. Cost contingencies can be aggregated and assigned to a schedule activity or a WBS work package level. Contingency reserve is added to account for existing known risk, whereas management reserves are added to account for unknown risk.

Cost of Quality The cost of quality (COQ) is the total cost to produce the product or service of the project according to the quality standards. You can find additional information on cost of quality in “Tools and Techniques of Plan Quality” later in this chapter.

Project Management Software The project management software tool can help quickly determine estimates given different variables and alternatives.

Vendor Bid Analysis Vendor bid analysis involves gathering information from vendors to help establish cost estimates. This can be accomplished by requesting bids or quotes or working with some of the trusted vendor sources for estimates.

Group Decision-Making Techniques In this assessment process, an evaluation of multiple alternatives is performed to determine the results future actions might bring. Group decision-making techniques are valuable in improving estimate accuracy and commitment to the determined estimates.

Outputs of Estimate Costs

The following are three outputs that result from the Estimate Costs process:

• Activity cost estimates
• Basis of estimates
• Project documents updates

Activity Cost Estimates Activity cost estimates are quantitative amounts that reflect the cost of the resources needed to complete the project activities. The following resources are commonly needed:

• Human resources
• Material
• Equipment
• Information technology needs
• Any contingency reserve amounts and inflation factors

Basis of Estimates Basis of estimates is the supporting detail for the activity cost estimates and includes any information that describes how the estimates were developed, what assumptions were made during the Estimate Costs process, and any other details needed. According to the PMBOK^® Guide, the basis of estimates should include the following as a minimum:

• Description of how the estimate was developed or the basis for the estimate
• Description of the assumptions made about the estimates or the method used to determine them
• Description of the constraints
• Range of possible results
• Confidence level regarding the final estimates

Project Documents Updates Updates to project documents, as a result of determining cost estimates, commonly include the following to account for cost variances and refined estimates:

• Project budget
• Risk register

Inputs of Determine Budget

The Determine Budget process contains nine inputs:

• Cost management plan
• Scope baseline
• Activity cost estimates
• Basis of estimates
• Project schedule
• Resource calendars
• Risk register
• Agreements
• Organizational process assets

Cost Management Plan As we have seen earlier in the chapter, the cost management plan lays out how project costs will be managed and controlled.

Scope Baseline When determining the budget, the following is used within the scope baseline:

• Project scope statement (describes the constraints of the project)
• WBS (shows how the project deliverables are related to their components and typically provides control account information)
• WBS dictionary

Activity Cost Estimates Activity cost estimates are determined for each activity within a work package and then summed to determine the total estimate for a work package.

Basis of Estimates Basis of estimates contains all the supporting detail regarding the estimates. Assumptions regarding indirect costs and whether they will be included in the project budget should be considered. Indirect costs cannot be directly linked to any one project but are allocated among several projects.

Project Schedule The schedule contains information that is helpful in developing the budget, such as start and end dates for activities, milestones, and so on. Based on the information in the schedule, budget expenditures for calendar periods can be determined.

Resource Calendars Resource calendars help determine costs in calendar periods and over the length of the project because they describe what resources are needed and available for the project.

Risk Register When determining the budget, a review of the risk register will help to compile the costs for risk response.

Agreements Agreements, such as contracts, include cost information that should be included in the overall project budget.

Organizational Process Assets The organizational process assets used include the following items:

• Cost budgeting tools
• Policies and procedures of the organization regarding budgeting exercises
• Reporting methods

Tools and Techniques of Determine Budget

Know the following tools and techniques of the Determine Budget process for the exam:

• Cost aggregation
• Reserve analysis
• Expert judgment
• Historical relationships
• Funding limit reconciliation

Cost Aggregation Cost aggregation is the process of tallying the schedule activity cost estimates at the work package level and then totaling the work package levels to higher-level WBS component levels. All costs can then be aggregated to obtain a total project cost.

Reserve Analysis In this process, reserve analysis outlines contingency reserves for unplanned project scope and unplanned project costs. Contingency reserves are included as part of the cost baseline, whereas management reserves are not.

Expert Judgment Expert judgment in calculating the project budget will include information from those with past experience in conducting similar projects.

Historical Relationships Analogous estimates and parametric estimates can be used to help determine total project costs. Actual costs from previous projects of similar size, scope, and complexity are used to estimate the costs for the current project. This is helpful when detailed information about the project is not available or it’s early in the project phases and not much information is known.

Funding Limit Reconciliation Funding limit reconciliation involves reconciling the amount of funds to be spent with the amount of funds budgeted for the project. The organization or the customer sets these limits. Reconciling the project expenses will require adjusting the schedule so that the expenses can be smoothed. This can be done by placing imposed date constraints on work packages or other WBS components in the project schedule.

Outputs of Determine Budget

There are three outputs of the Determine Budget process:

Cost Baseline The cost baseline provides the basis for measurement, over time, of the expected cash flows (or funding disbursements) against the requirements. Adding the costs of the WBS elements by time periods develops the cost baseline. This is also known as the project’s time-phased budget. Most projects span some length of time, and most organizations time the funding with the project.

Cost baselines can be displayed graphically, as shown in Figure 3.23.

The cost baseline should contain the costs for all of the expected work on the project, as well as the contingency reserves set aside to account for known risks. Large projects may have more than one cost performance baseline.

Project Funding Requirements Project funding requirements describe the need for funding over the course of the project and are derived from the cost performance baseline. Funding requirements can be expressed in monthly, quarterly, or annual increments or other increments that are appropriate for your project.

Figure 3.24 shows the cost baseline, the funding requirements, and the expected cash flows plotted on the S curve. This example shows a negative amount of management reserve. The difference between the funding requirements and the cost performance baseline at the end of a project is the management reserve. Management reserves are set aside to deal with unknown risks.

Project Documents Updates The following project documents require updates as a result of carrying out this process:

• Cost management plan
• Any other project documents that include cost estimates

Organization Charts and Position Descriptions

The following information is presented in organization charts and position descriptions:

Hierarchical Charts Hierarchical charts, like a WBS, are designed in a top-down format. Two types of hierarchical charts that can be used are OBS and RBS:

• Organization breakdown structure (OBS), which displays departments, work units, or teams in an organization and their respective work packages
• Resource breakdown structure (RBS), which breaks down the work of the project according to the types of resources needed

Matrix-Based Charts Matrix-based charts are used to show the type of resource and the responsibility that resource has in the project. You can use a couple of types of matrix-based charts:

• Responsibility assignment matrix (RAM) is displayed as a chart with resource names listed in each column and project phases or WBS elements listed as the rows. Indicators in the intersections show where the resources are needed.

• A RACI chart is a type of RAM. Table 3.6 shows a sample portion of an RACI chart for a software development team. In this example, the RACI chart shows the roles and expectations of each participant.

The letters in the acronym RACI are the designations shown in Table 3.6:

• R = Responsible for performing the work
• A = Accountable, the one who is responsible for producing the deliverable or work package and approves or signs off on the work
• C = Consult, someone who has input to the work or decisions
• I = Inform, someone who must be informed of the decisions or results

Text-Oriented Formats Text-oriented formats are used when there is a significant amount of detail to record. These are also called position descriptions or role-responsibility-authority forms. Text-oriented formats typically provide the following information:

• Role
• Responsibility
• Authority of the resource

Other Sections of the Project Management Plan Other subsidiary plans of the project management plan might also describe roles and responsibilities.

Networking

Networking in this context means human resource networking. According to the PMBOK^® Guide, several types of networking activities exist:

• Proactive communication
• Lunch meetings
• Informal conversations
• Trade conferences
• Symposia

Organizational Theory

Organizational theory refers to all the theories that attempt to explain what makes people, teams, and work units behave.

Expert Judgment

Expert judgment helps inform the human resource management plan by

• Listing the preliminary requirements for the required skills
• Assessing the roles required for the project based on standardized role descriptions
• Determining number of resources and level of effort needed to meet project objectives
• Determining reporting relationships
• Providing guidelines on leading time required for staffing
• Identifying risks associated with staff acquisition, retention, and release plans
• Using programs for complying with contracts, both with government and unions

Meetings

Meetings help in the planning of human resources and allow team members to reach consensus on the human resource management plan.

Communication Requirements Analysis

Communication requirements analysis involves analyzing and determining the communication needs of the project stakeholders. According to the PMBOK^® Guide, there are several sources of information you can examine to help determine these needs:

• Company and departmental organizational charts
• Stakeholder responsibility relationships
• Other departments and business units involved in the project
• The number of resources involved in the project and where they’re located in relation to project activities
• Internal needs that the organization may need to know about the project
• External needs that organizations such as the media, government, or industry groups might have that require communication updates
• Stakeholder information (documented in the stakeholder register and stakeholder management strategy outputs of Identify Stakeholders)

The preceding list goes through analysis to make certain that information that is valuable to the stakeholders is being supplied. It is important to know the number of communication channels, also known as lines of communication, that exist. Figure 3.29 shows an example of a network model with six stakeholders included.

The nodes are the participants, and the lines show the connection between them all. The formula for calculating the lines of communication is as follows (where n represents total participants):

Figure 3.29 shows six participants. When you plug the total participants into the formula, the result is a total of 15 communication channels:

Communication Technology

Communication technology examines the methods (or technology) used to communicate the information to, from, and among the stakeholders. This tool and technique examines the technology elements that might affect project communications.

The following are examples of methods used when communicating:

• Written
• Spoken
• Email
• Formal status reports
• Meetings
• Online databases
• Online schedules

Communication Models

Communication models depict how information is transmitted from the sender and how it’s received by the receiver. According to the PMBOK^® Guide, the key components of a communication model are as follows:

Encode Encoding the message means to put information or thoughts into a language that the receiver will understand.

Message and Feedback Message The result or output of the encoding.

Medium The method used to communicate, such as written, oral, or email.

Noise Anything that keeps the message from being either transmitted or understood.

Decode The receiver translates the information that was sent by the sender.

The sender is responsible for encoding the message, selecting the medium, and decoding the feedback message. The receiver is responsible for decoding the original message from the sender and encoding and sending the feedback message. Figure 3.30 shows this dynamic through the basic communication model.

Communication Methods

Communication methods refer to how the project information is shared among the stakeholders. According to the PMBOK^® Guide, there are three classifications of communication methods:

Interactive Communication Interactive communication involves multidirectional communication where two or more parties must exchange thoughts or ideas. This method includes videoconferencing, phone or conference calls, and meetings.

Push Communications Push communications refers to sending information to intended receivers. It includes methods such as letters, memos, reports, emails, voicemails, and so on. This method assures that the communication was sent but is not concerned with whether it was actually received or understood by the intended receivers.

Pull Communications The likely recipients of the information access the information themselves using methods such as websites, e-learning sites, knowledge repositories, shared network drives, and so on.

Meetings

Meetings are used by the project manager to facilitate conversations with the project team on how project communications should occur throughout the life of the project. According to the PMBOK^® Guide, various types of meeting types can be used, many of which help resolve issues and facilitate decisions.

Inputs of Plan Risk Management

You should know the following inputs of the Plan Risk Management process:

• Project management plan
• Project charter
• Stakeholder register
• Enterprise environmental factors
• Organizational process assets

Project Management Plan For the purposes of risk management planning, it is necessary to consider all other approved subsidiary management plans and baselines. The project management plan sets the baseline for all risk-affected areas, especially scope, schedule, and cost.

Project Charter From the project charter, various inputs can be gleaned, including risks, project descriptions, and requirements, all at a high level.

Stakeholder Register Using the stakeholder register will provide the details related to the project stakeholder, including an overview of their roles.

Enterprise Environmental Factors One of the key elements of the enterprise environmental factors to consider in this process is the risk tolerance levels of the organization and the stakeholders. This is important for evaluating and ranking risk.

Organizational Process Assets Organizational process assets include policies and guidelines that might already exist in the organization. The following should be considered when developing the risk management plan:

• Risk categories
• Risk statement formats
• Risk management templates tailored to the needs of the project
• Defined roles and responsibilities
• Authority levels of the stakeholders and project manager

Tools and Techniques of Plan Risk Management

The Plan Risk Management process has three tools and techniques: analytical techniques, expert judgment, and meetings.

Analytical Techniques To create and communicate the overall risk management context of the project, analytical techniques are used. The risk management context combines the strategic risk exposure of a given project with the stakeholders’ attitude on risk. These assessments will inform the project team on the appropriate resource allocation and allow the team to focus on risk management activities.

Expert Judgment In the creation of a comprehensive risk management plan, the judgment and expertise should be considered from those with specialized training or knowledge in the subject area including but not limited to

• Senior management
• Other project managers who have performed similar work efforts
• Subject matter experts in the field
• Project stakeholders
• Industry groups and consultants
• Technical and professional associations

Meetings The purpose of the meetings is to contribute to the risk management plan. During these meetings, the fundamental plans for performing risk management activities will be discussed and determined and then documented in the risk management plan.

Outputs of Plan Risk Management

The output of the Plan Risk Management process is the risk management plan.

The risk management plan describes how you will define, monitor, and control risks throughout the project. It details how risk management processes will be implemented, managed, monitored, and controlled.

According to the PMBOK^® Guide, the risk management plan should include the following elements:

Methodology Methodology is a description of how you’ll perform risk management, including elements such as methods, tools, and where you might find risk data that you can use in the later processes.

Roles and Responsibilities The risk management plan should include descriptions of the people who are responsible for managing the identified risks and their responses and the people responsible for each type of activity identified in the plan.

Budgeting The budget for risk management activities is included in the plan as well. In this section, you’ll assign resources and estimate the costs of risk management activities and its methods. These costs are then included in the cost performance baseline.

Timing Timing refers to how often and at what point in the project life cycle risk management processes will occur. You may also include protocols to establish contingency schedule reserves.

Revised Stakeholder Tolerances As the project proceeds through the risk management processes, risk tolerances will change. These are documented in the risk management plan. Risk management should be carried out according to stakeholder risk tolerances.

Reporting Formats In the reporting formats section, you’ll describe the content and format of the risk register. You should also detail how risk management information will be maintained, updated, analyzed, and reported to project participants.

Tracking This includes a description of how you’ll document the history of the risk activities for the current project and how the risk processes will be audited.

Risk Categories Risk categories are a way of systematically identifying risks and providing a foundation for understanding. Risk categories should be identified during this process and documented in the risk management plan.

There are multiple ways of displaying risk categories, such as through a simple list or by constructing a risk breakdown structure (RBS), which lists the categories and subcategories. Figure 3.34 shows a sample of an RBS.

The following list includes some examples of the categories you might consider during this process:

• Technical/quality/performance risks
• Project management risks
• Organizational risks
• External risks

Defining Probability and Impact The definitions for probability and impact are documented in the risk management plan as they relate to potential positive or negative risk events and their impacts on project objectives.

• Probability describes the potential for the risk event occurring.
• Impact describes the effects or consequences the project will experience if the risk event occurs.

Probability and Impact Matrix A probability and impact matrix prioritizes the combination of probability and impact scores and helps determine which risks need detailed risk response plans.

Inputs of Identify Risks

You should be familiar with the following inputs of the Identify Risks process:

• Risk management plan
• Cost management plan
• Schedule management plan
• Quality management plan
• Human resource management plan
• Scope baseline
• Activity cost estimates
• Activity duration estimates
• Stakeholder register
• Project documents
• Procurement documents
• Enterprise environmental factors
• Organizational process assets

Risk Management Plan In this process, the roles and responsibilities section of the risk management plan will be used, as well as the budget and schedule set aside for risk activities.

Cost Management Plan, Schedule Management Plan, Quality Management Plan, Human Resource Management Plan, Project Documents An understanding of the project management plans and project documents is necessary for identifying risks. A thorough review of these documents should be carried out to identify risks associated with them.

Scope Baseline The project scope statement, part of the scope baseline, contains a list of project assumptions, which are issues believed to be true. The assumptions about delivery times are reexamined, and it is determined if they are still valid.

Activity Cost Estimates Activity cost estimates may provide insight into the identification of risks if the estimates are found to be insufficient to complete the activity.

Activity Duration Estimates Activity duration estimates may reveal existing risks in relation to the time that has been allotted for completing an activity or the project as a whole.

Stakeholder Register Understanding stakeholder influence is essential to risk management. The stakeholder register provides a list of stakeholders and may list levels of influence.

Procurement Documents When a project requires the use of external procurement of resources, procurement documents are an influential input to the Identify Risks process.

Enterprise Environmental Factors The enterprise environmental factors include aspects from outside the project that might help determine or influence project outcomes. Industry information or academic research that might exist for your application areas regarding risk information is especially relevant.

Organizational Process Assets Historical information, such as from previous project experiences and project team knowledge, is used from within the organizational process assets. Risk register templates can also be used from past similar projects.

Tools and Techniques of Identify Risks

The Identify Risks process includes the following tools and techniques:

• Documentation reviews
• Information-gathering techniques
• Checklist analysis
• Assumptions analysis
• Diagramming techniques
• SWOT analysis
• Expert judgment

Documentation Reviews Documentation reviews involve reviewing project plans, assumptions, and historical information from previous projects from a total project perspective as well as from an individual deliverables and activities level. This review helps the project team identify risks associated with the project objectives.

Information-Gathering Techniques The following information-gathering techniques are used to assist in compiling a comprehensive list of risks:

• Brainstorming
• Delphi technique
• Interviewing
• Root cause analysis

Checklist Analysis Checklists used during the Identify Risks process are usually developed based on historical information and previous project team experience. The lowest level of the RBS or a list of risks from previous similar projects may be used. The WBS can also be used as a checklist.

Assumptions Analysis Assumptions analysis is a matter of validating the assumptions identified and documented during the course of the project planning processes. Assumptions should be accurate, complete, and consistent. All assumptions are tested against two factors:

• Strength of the assumption or the validity of the assumption
• Consequences that might impact the project if the assumption turns out to be false

Diagramming Techniques Three types of diagramming techniques are used in the Identify Risks process:

SWOT Analysis Strengths, weaknesses, opportunities, and threats (SWOT) analysis is a technique that examines the project from each of these viewpoints and from the viewpoint of the project itself. SWOT should also be used to examine project management processes, resources, the organization, and so on to identify risks to the project, including risks that are generated internally. SWOT analysis uncovers the following:

SWOT analysis also determines whether any of the organization’s strengths can be used to overcome its weaknesses.

Expert Judgment Experts for risk identification purposes can include individuals with the following experience:

• Experience with similar projects
• Experience in the business area for which the project was undertaken
• Industry-specific experience

The bias of experts regarding the project or potential risk events should be considered when using this technique.

Outputs of Identify Risks

There is only one output of the Identify Risks process: the risk register.

The risk register contains the following elements:

• List of identified risks
• List of potential responses

List of Identified Risks Risks are all the potential events and their subsequent consequences that could occur as identified during this process. A list provides a means of tracking risks and their occurrence and responses. The list should contain the following items:

• All potential risks
• Tracking number
• Potential cause or event
• Potential impact
• Responses implemented

List of Potential Responses While you’re identifying risks, you may identify a potential response at the same time. If this is the case, these potential responses are documented.

Table 3.7 shows a sample template for a risk register.

Inputs of Perform Qualitative Risk Analysis

Know the following inputs of the Perform Qualitative Risk Analysis process and how they apply:

• Risk management plan
• Scope baseline
• Risk register
• Enterprise environmental factors
• Organizational process assets

Risk Management Plan The risk management plan documents the following, which are used when prioritizing risks:

• Roles and responsibilities of risk team members
• Budget and schedule factors for risk activities
• Stakeholder risk tolerances
• Definitions for probability and impact
• Probability and impact matrix

Scope Baseline Projects that have been attempted before will tend to have better understood risks, whereas projects that are first-of-their-kind or are highly complex will tend to be more uncertain. Through an examination of the scope baseline, these factors will become clearer.

Risk Register The list of risks from within the risk register is used in this process.

Enterprise Environmental Factors As with other processes that we have examined earlier, enterprise environmental factors will provide insight and context to the risk assessment, including studying industry projects of a similar nature and exploring risk databases that may be available from industry or proprietary sources.

Organizational Process Assets Historical information, lessons learned, and risk databases from past projects are used from within the organizational process assets as a guide for prioritizing the risks for this project.

Tools and Techniques of Perform Qualitative Risk Analysis

The following tools and techniques are used in the Perform Qualitative Risk Analysis process:

• Risk probability and impact assessment
• Probability and impact matrix
• Risk data quality assessment
• Risk categorization
• Risk urgency assessment
• Expert judgment

Risk Probability and Impact Assessment This tool and technique assesses the probability that the risk events identified will occur and determines the effect (or impact) they have on the project objectives:

Probability and Impact Matrix The outcome of a probability and impact matrix is an overall risk rating for each of the project’s identified risks. The following are characteristics of the probability and impact matrix:

• The combination of probability and impact results in a classification usually expressed as high, medium, or low.
• Values assigned to the risks determine how the Plan Risk Responses process is carried out for the risks later during the risk-planning processes.
• Values for the probability and impact matrix (and the probability and impact scales) are determined prior to the start of this process.
• The impact and probability matrix is documented in the risk management plan.

Risk Data Quality Assessment The risk data quality assessment involves determining the usefulness of the data gathered to evaluate risk. The data must be unbiased and accurate. Elements such as the following are used when performing this tool and technique:

• Quality of the data used
• Availability of data regarding the risks
• How well the risk is understood
• Reliability and integrity of the data
• Accuracy of the data

Risk Categorization Risk categorization is used to determine the effects risk has on the project.

Risk Urgency Assessment Risk urgency assessment determines how soon the potential risks might occur and quickly determines responses for those risks that could occur in the near term. The following play a role in determining how quickly a risk response is needed:

• Risk triggers
• Time to develop and implement a response
• Overall risk rating

Expert Judgment Expert judgment is used to determine the probability, impact, and other information derived to date from this process. Interviews and facilitated workshops are two techniques used in conjunction with expert judgment to perform this process.

Outputs of Perform Qualitative Risk Analysis

The output of the Perform Qualitative Risk Analysis process delivers project documents updates, including updates to the risk register and assumptions log.

According to the PMBOK^® Guide, the risk register will receive the following updates, which are added as new entries:

• Risk ranking (or priority) for the identified risks
• Risks grouped by categories
• Causes of risk
• List of risks requiring near-term responses
• List of risks that need additional analysis and response
• Watch list of low-priority risks
• Trends in qualitative risk analysis results

The assumptions log will receive updates as new information is made available through the qualitative risk assessment. Assumptions could be incorporated in the project scope statement or in a separate log.

Inputs of Perform Quantitative Risk Analysis

Know the following inputs of the Perform Quantitative Risk Analysis process:

• Risk management plan
• Cost management plan
• Schedule management plan
• Risk register
• Enterprise environmental factors
• Organizational process assets

Risk Management Plan The risk management plan guides the project team in carrying out the risk processes. The following key elements are used from within the risk management plan:

• Roles and responsibilities
• Risk management activities
• Guidelines for setting aside contingency reserves
• RBS
• Stakeholder tolerances

Cost Management Plan The cost management plan provides the necessary information to address cost-related risks so that the project can be kept within budget.

Schedule Management Plan The schedule management plan provides the necessary information to address schedule-related risks so that the project can be kept on schedule.

Risk Register The risk register contains a list of identified risks as well as any other documented information on risks to date.

Enterprise Environmental Factors Enterprise environmental factors contribute insight and context to the risk analysis. Two factors to consider are industry studies of similar projects that are conducted by risk specialists, and a review of risk databases available from the industry or through proprietary sources.

Organizational Process Assets The organizational process assets include historical information from previous projects.

Tools and Techniques of Perform Quantitative Risk Analysis

Three tools and techniques are used in the Perform Quantitative Risk Analysis process:

• Data-gathering and representation techniques
• Quantitative risk analysis and modeling techniques
• Expert judgment

Data-Gathering and Representation Techniques Data-gathering and representative techniques are as follows:

Quantitative Risk Analysis and Modeling Techniques One or more of the following quantitative risk analysis and modeling techniques are used:

Expert Judgment Experts can come from inside or outside the organization and should have experience that’s applicable to the project. When performing quantitative risk analysis, experts can also assist in validating the data and tools used.

Outputs of Perform Quantitative Risk Analysis

Like the process before it, the Perform Quantitative Risk Analysis process contains one output, project documents updates, including the risk register.

The following risk register updates occur as a result of this process:

• Probabilistic analysis of the project
• Probability of achieving the cost and time objectives
• Prioritized list of quantified risks
• Trends in Perform Quantitative Risk Analysis results

Probabilistic Analysis of the Project Probabilistic analysis of the project is the forecasted results of the project schedule and costs as determined by the outcomes of risk analysis. The following are characteristics of probabilistic analysis:

• Results include projected completion dates and costs along with a confidence level associated with each.
• The output is often expressed as a cumulative distribution.
• Results are used along with stakeholder risk tolerances to quantify the time and cost contingency reserves.

Probability of Achieving the Cost and Time Objectives The probability of achieving the cost and time objectives of the project are documented based on the results of performing the quantitative risk analysis tools and techniques.

Prioritized List of Quantified Risks The prioritized list of risks includes the following items:

• Risks with the greatest risk or threat to the project
• Risk impacts
• Risks that present the greatest opportunities to the project
• Risks that are most likely to impact the critical path
• Risks with the largest cost contingency

Trends in Perform Quantitative Risk Analysis Results Trends in Perform Quantitative Risk Analysis appear as the process is repeated. Trends are documented for further analysis and for use in developing risk response plans.

Inputs of Plan Risk Responses

The Plan Risk Responses process contains two inputs that you should be familiar with. Be sure you know how they are used during the process.

Risk Management Plan The following are used from within the risk management plan in carrying out this process:

• Roles and responsibilities that pertain to risk
• Definitions of risk analysis
• Risk thresholds
• Time and budget requirements allotted for risk activities

Risk Register All of the information included within the risk register to date will be used in developing risk responses.

Tools and Techniques of Plan Risk Responses

Tools and techniques of the Plan Risk Responses process that you should know are as follows:

• Strategies for negative risks or threats
• Strategies for positive risks or opportunities
• Contingent response strategies
• Expert judgment

Strategies for Negative Risks or Threats As Figure 3.44 shows, strategies for negative risks or threats include avoid, transfer, mitigate, and accept.

Strategies for Positive Risks or Opportunities Strategies for positive risks or opportunities, as shown in Figure 3.45, include exploit, share, enhance, and accept.

Contingent Response Strategies Contingent response strategies, also known as contingency planning, involves planning alternatives to deal with the risks should they occur. Contingency planning recognizes that risks may occur and that plans should be in place to deal with them.

The following contingency responses are common:

• Contingency reserves, which include project funds that are held in reserve to offset any unavoidable threats that might occur to project scope, schedule, cost, or quality. Also includes reserving time and resources to account for risks.
• Fallback plans, which are developed for risks with high impact or for risks with identified strategies that might not be the most effective at dealing with the risk.

Expert Judgment Expert judgment is used in developing risk responses, including feedback and guidance from risk management experts and those internal to the project qualified to provide assistance in this process.

Outputs of Plan Risk Responses

Here are the two outputs of the Plan Risk Responses process:

• Project management plan updates
• Project documents updates

Project Management Plan Updates The following documents within the project management plan may require updates to reflect the changes in process and practice that are driven by the risk responses:

• Any and all of the management plans, including the schedule management plan, cost management plan, quality management plan, procurement management plan, and human resource management plan
• Any and all of the project baselines, including the scope baseline, schedule baseline, and cost baseline

Project Documents Updates There are several project document updates, with the key update occurring to the risk register. Elements to the risk register can include but are not limited to

• List of identified risks, including their descriptions, what WBS element they impact (or area of the project), categories (RBS), root causes, and how the risks impact the project objectives
• Risk owners and their responsibility
• Outputs from the Perform Qualitative Analysis process
• Agreed-upon response strategies
• Actions needed to implement response plans
• Risk triggers
• Cost and schedule activities needed to implement risk responses
• Contingency plans
• Fallback plans, which are risk response plans that are executed when the initial risk response plan proves to be ineffective
• Contingency reserves
• Residual risk, which is a leftover risk that remains after the risk response strategy has been implemented
• Secondary risks, which are risks that come about as a result of implementing a risk response

Other project documents, such as technical documentation and the assumptions documented in the project scope statement, may require an update after performing this process.

Meeting Attendees

Those who attend a kickoff meeting include, but are not limited to, the following individuals:

• Project manager
• Project team members
• Customer
• Project sponsor
• Department managers
• Other key stakeholders