Inputs of Plan Scope Management

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

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

Project Management Plan The project management plan more closely defines what the project is intended to accomplish. This plan, with all of its approved subsidiary plans, is used to help create the scope management plan. In particular, the following components of the project management plan are referenced:

• Quality management plan
• Project life cycle description
• Development approach

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 three tools and techniques that the Plan Scope Management process uses are expert judgement, data analysis, 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.

Data Analysis Alternatives analysis is a helpful data analysis technique that can be used to develop the scope and requirements management plans. The plans often document the various types of techniques that will be used to collect requirements and develop scope.

Meetings In the course of developing the scope management plan, members of project teams may attend meetings to facilitate information exchange and decision making. Depending on the meeting, the following members might be a part of the discussion: project manager, project sponsor, selected project team members, and anyone having responsibility in this particular 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.

Scope Management Plan The components of the scope management plan include processes for the following activities: 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

Requirements Management Plan The requirements management plan defines how the requirements will be analyzed, documented, and managed throughout all phases of the project. The type of phase relationship used to manage the project will determine how requirements are managed throughout the project. A requirements management plan includes the following components:

• How planning, tracking, and reporting of requirements activities will occur
• How changes to the requirements will be requested, tracked, and analyzed along with other configuration management activities
• How requirements will be prioritized
• Which metrics will be used to trace product requirements
• Which requirements attributes will be documented in the traceability matrix
• The structure that will be used to help create the traceability matrix

Inputs of Collect Requirements

Know the following inputs of the Collect Requirements process:

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

Project Management Plan The project management plan contains the scope, requirements, and stakeholder engagement plans, which are useful for gathering requirements.

• Scope Management Plan The scope management plan provides direction on how members of the project pick the type of requirements that need to be collected for the project.
• Requirements Management Plan The requirements management plan helps define and document the stakeholders’ wants and needs.
• Stakeholder Engagement Plan We will cover the stakeholder engagement plan in Chapter 6. For the Collect Requirements process, the stakeholder engagement 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 Documents 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. In addition to this document, the assumption log and lessons learned register are helpful in identifying requirements.

Business Documents The business case can offer insight and criteria for meeting business needs.

Agreements When agreements exist, they are key since they often contain project and/or product requirements.

Enterprise Environmental Factors Enterprise environmental factors applicable to collecting requirements include things like organizational culture, marketplace conditions, infrastructure, and personnel administration.

Organizational Process Assets Historical information from past similar projects can be very useful, such as archived requirements documentation. Lessons learned, policies, and procedures are other types of assets that can be used.

Tools and Techniques of Collect Requirements

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

• Expert judgment
• Data gathering
• Data analysis
• Decision making
• Data representation
• Interpersonal and team skills
• Context diagrams
• Prototypes

Expert Judgment Subject matter experts and experienced project participants can impart a lot of information, particularly in topics such as business analysis, requirements elicitation and analysis, and facilitation.

Data Gathering There are several data gathering techniques that can be used to collect requirements. The PMBOK^® Guide highlights the following:

• Brainstorming Brainstorming involves getting together to generate ideas and gather the project requirements.
• Interviews Interviews are a way of collecting information from subject matter experts quickly. 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. The participants then engage in discussion and conversation as a way of imparting their feedback about a project’s end result.
• Questionnaires and Surveys Questionnaires and surveys allow you to query a group of participants and apply statistical analysis to the results as needed. This tool is considered to be a quick way of obtaining feedback from a large number of stakeholders.
• Benchmarking Ever wish to see how you measure up against other organizations or internal projects? Benchmarking compares 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.

Data Analysis Another technique used in the identification of requirements is document or data analysis, where existing documentation is reviewed to see if there is information relevant to completing the requirements. According to the PMBOK^® Guide, a variety of documents can 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

Decision Making Throughout the requirements gathering process, decisions will need to be made. There are a variety of techniques that can be used to aid decision making, such as voting and multicriteria decision analysis.

• Voting According to the PMBOK^® Guide, several methods of reaching a decision can be 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
  • Autocratic, where one person makes the decision on behalf of the group
• Multicriteria Decision Analysis With multicriteria decision analysis, a decision matrix is used for establishing criteria for a systematic analytical approach.

Data Representation Data representation techniques referenced by the PMBOK^® Guide as examples for collecting requirements include mind mapping and affinity diagrams.

• Idea/Mind Mapping In idea/mind mapping, participants use a combination of brainstorming and diagramming techniques to record their ideas.
• Affinity Diagrams Affinity diagrams sort ideas into related groups for further analysis and review.

Interpersonal and Team Skills Several interpersonal and team skills are needed to collect requirements, such as the nominal group technique, observation and conversation, and facilitation.

• Nominal Group Technique Nominal group technique works to engage all participants through an idea-gathering or structured brainstorming session and ranking process.
• Observation/Conversation Observation and conversation consists 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.
• Facilitation 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 the participants’ issues.
  • A consensus is reached more easily than through other methods
  • Some additional examples of facilitation include joint application design/development (JAD), quality function deployment (QFD), and user stories.

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.

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.

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. Requirements can be progressively elaborated, meaning that they start out as high-level requirements, then are specified in greater detail as more is known. Examples of what may be captured are as follows:

• 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

The PMBOK^® Guide highlights the fact that requirements can be grouped into classifications. Examples of classifications are business requirements, stakeholder requirements, solution requirements (such as functional and nonfunctional requirements), transition and readiness requirements, project requirements, and quality requirements.

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 or not 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 work breakdown structure (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 five inputs you should know:

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)

Project Management Plan The primary document utilized from within the project management plan is the scope management plan. The scope management plan outlines how the Define Scope process is to be carried out.

Project Documents Project documents typically used to define scope include the assumption log, requirements documentation, and the risk register. In particular, 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.

Enterprise Environmental Factors Enterprise environmental factors that apply to the Define Scope process typically include the organizational culture, infrastructure, marketplace conditions, and personnel administration.

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 Expert judgment plays an important role in the definition of scope. Sources of expert judgment used in this process include the following sources:

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

Data Analysis Alternatives analysis is a data analysis technique used for discovering different methods or ways of accomplishing the work of the project. Examples of alternatives analysis 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.

Decision Making An example of a decision-making technique noted earlier in this chapter that can be used to define scope is multicriteria decision analysis.

Interpersonal and Team Skills Facilitation, a form of interpersonal and team skills, involves stakeholders coming together to discuss and define requirements that affect more than one department.

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

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
• Acceptance criteria
• Project deliverables
• Project exclusions

Product Scope Description The product scope description describes the characteristics of the product, service, or result of the project.

Acceptance Criteria Acceptance criteria include the process and criteria that will be used to determine whether the deliverables and the final product, service, or result of the project is acceptable and satisfactory.

Project Deliverables Deliverables are measurable outcomes, measurable results, or specific items that must be produced to consider the project or project phase completed. Deliverables should be specific, unique, and verifiable and may include supplementary outcomes.

Project Exclusions Project exclusions are anything that isn’t included as a deliverable or work of the project. Project exclusions should be noted in the project scope statement for stakeholder management purposes.

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:

• Assumption log
• Stakeholder register
• Requirements documentation
• Requirements traceability matrix

Inputs of Create WBS

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

Project Management Plan The scope management plan, which is a component of the project 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 Documents Project documents used as part of this process typically include the project scope statement and the requirements documentation. The project scope statement contains information valuable to creating the WBS, most notably the list of project deliverables. 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: expert judgment and decomposition.

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 they can be created by your organization as a result of experience gained from performing similar projects.

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.

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:

• Major Deliverables The major deliverables of the project are used as the first level of decomposition in this structure.
• Subprojects Another way to organize the work is by subprojects. Each of the subproject managers will develop a WBS for their subproject that details the work required for that deliverable.
• Project Phases Many projects are structured or organized by project phases. Each phase listed here would be the first level of decomposition, and its deliverables would be the next level.

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

Level 1 According to the PMBOK^® Guide, Level 1 of the WBS is the project level. The first level of decomposition, however, may be the second level of the WBS, which could include deliverables, phases, and subprojects—see Figure 3.5 for an example.

Level 2 Level 2 and levels that follow show more and more detail. Each of these breakouts is called a level in the WBS. See Figure 3.6 and Figure 3.7 for examples.

Lowest Level The lowest level of any WBS is called the work package level. The goal is to construct the WBS to the work package level where cost estimates and schedule dates can be estimated reliably and easily.

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:

WBS Templates Work breakdown structures can be constructed using WBS templates or the WBS from a similar completed project. Although every project is unique, many companies and industries perform the same kind of projects repeatedly.

Rolling Wave Planning Rolling wave planning is a process of elaborating deliverables, project phases, or subprojects in the WBS to differing levels of decomposition depending on the expected date of the work.

Unique WBS Identifiers Each element at each level of the WBS is generally assigned a unique identifier according to the PMBOK^® Guide. Figure 3.8 shows what a WBS with unique identifiers displayed might look like.

WBS Dictionary The WBS dictionary is where work component descriptions are documented. According to the PMBOK^® Guide, the WBS dictionary should include the following elements for each component of the WBS:

• Code of accounts identifier
• Description of the work of the component
• Organization responsible for completing the component
• List of schedule milestones
• Schedule activities associated with the schedule milestones
• Required resources
• Cost estimates
• Quality requirements
• Criteria for acceptance
• Technical references
• Contract information

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

• Requirements documentation
• Assumption log
• 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 Charter In 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.

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 management plan provides information on how scope will be defined, which can aid in the process for defining the schedule itself. The project management plan also contains a summary of the development approach, which is an important input for determining how the schedule should be approached.

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, data analysis, 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.

Data Analysis Most analytical techniques used here involve picking between different options, and it is no different for this process. Plan schedule management might require 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 progresses, the schedule management plan might 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 be included: 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. According to the PMBOK^® Guide, 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:

Project Management Plan The critical input from this plan is the defined level of detail needed to manage the work. This is taken from the schedule management plan. The scope baseline, another essential input from the project management plan, takes into account the following:

• Work packages, from within the WBS
• Deliverables, 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 four tools and techniques in the Define Activities process:

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

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.

Meetings Meetings can be a useful tool for getting experts together to decompose work. A variety of meeting types, such as virtual, face to face, or a combination of the two, can be used.

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. The list includes a scope-of-work description for each activity and a unique 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 does 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

Change Requests Change requests become applicable after the project scope and schedule have been baselined and progressive elaboration occurs. As a result, new activities may be defined over time.

Project Management Plan Updates Just as with change requests, updates to the project management plan may be required after the project has been baselined and new work is identified through progressive elaboration. As change requests are approved through the formal change control process, updates to the plan will be necessary. Typically, this includes updates to the schedule baseline and cost baseline.

Inputs of Sequence Activities

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

• Project management plan
• Project documents
• Enterprise environmental factors
• Organizational process assets

Project Management Plan The schedule management plan, a component of the project management plan, clarifies the tools and methods to be used in scheduling, which informs activity sequencing. The scope baseline can also be used when sequencing activities and identifying dependencies. Through this baseline, the deliverables, constraints, and assumptions are considered.

Project Documents To sequence activities, there are several project documents that may be useful, such as the activity list, activity attributes, milestone list, and assumption log.

• Activity List The first document utilized tends to be the activity list. 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.
• Assumption Log Assumptions recorded in this log may influence how activities need to be sequenced as well as any leads or lags necessary.

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. Templates and lessons learned, in particular, can be very useful, as well as any other documented policies or procedures that exist for sequencing activities.

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 and integration
• Leads and lags
• Project management information system

Precedence Diagramming Method The 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)

Figure 3.12 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:

• Finish-to-Start The finish-to-start (FS) relationship is the most frequently used relationship. In this relationship, the predecessor activity must finish before the successor activity can start.
• Start-to-Finish In the start-to-finish (SF) relationship, the predecessor activity must start before the successor activity can finish. This logical relationship is seldom used.
• Finish-to-Finish In the finish-to-finish (FF) relationship, the predecessor activity must finish before the successor activity finishes.
• Start-to-Start In the start-to-start (SS) relationship, the predecessor activity must start before the successive activity can start.

Dependency Determination and Integration 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 their characteristics:

• Mandatory Dependencies Mandatory dependencies, also known as hard logic or hard dependencies, are defined by the type of work being performed. The nature of the work itself dictates the order in which the activities should be performed.
• Discretionary Dependencies Discretionary dependencies are defined by the project team. Discretionary dependencies are also known as preferred logic, soft logic, or preferential logic. These are usually process- or procedure-driven or best-practice techniques based on past experience.
• External Dependencies External dependencies are external to the project. The PMBOK^® Guide points out that even though the dependency is external to the project (and therefore a non-project activity), it impacts project activities.
• Internal Dependencies Internal dependencies are internal to the project. These dependencies involve a precedence relationship between project activities that are within the project team’s ability to control.

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.

Figure 3.13 shows a general example of the ADM method.

The information in Figure 3.14 can help you remember the difference between PDM and ADM for the exam.

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

• Leads Leads speed up the successor activities and require time to be subtracted from the start date or the finish date of the activity you’re scheduling.
• Lags Lags delay successor activities (those that follow a predecessor activity) and require time added either to the start date or to the finish date of the activity being scheduled.

Project Management Information System Tools such as scheduling software are often used to assist in developing the schedule.

Outputs of Sequence Activities

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

Project Schedule Network Diagrams The project schedule network diagram provides a visual view of the activities within the schedule, including the existing sequence, dependencies, leads, and lags. 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
• Assumption log
• Milestone list

Figure 3.15 shows the position of the Sequence Activities process in relation to the other related processes that produce the schedule.

Inputs of Estimate Activity Resources

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

• Project management plan
• Project documents
• Enterprise environmental factors
• Organizational process assets

Project Management Plan Two elements of the project management plan provide inputs for this activity. The resource management plan assists in determining the resources to be estimated. This plan documents how this estimating process is to be carried out and includes the methods used to quantify resources needed.

The scope baseline captures the project and product scope required to achieve project objectives. This information helps identify what resources will be needed.

Project Documents Among the various project documents that are generated within a project, the following can be used to help estimate resources: activity list, activity attributes, assumption log, cost estimates, resource calendars, and risk register.

• Activity List The activity list is necessary to know which activities will need resources.
• Activity Attributes The activity attributes provide the details necessary to estimate the resources needed per activity.
• Assumption Log Assumptions and constraints documented may include information useful for resource estimation, such as availability, cost estimates, and approaches that may influence the type and number of resources.
• Cost Estimates The activity cost estimates are necessary to know how cost may impact resource selection.
• 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 Risks documented within the risk register may influence resource estimates. The risk register helps inform how risk events can disrupt resource selection and availability.

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
• Bottom-up estimating
• Analogous estimating
• Parametric estimating
• Data analysis
• Project management information system (PMIS)
• Meetings

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

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.

Analogous Estimating Analogous estimating involves using information from past similar projects to calculate estimates for the existing project. This is useful when minimal information is known (it is not as precise a method) or estimates are needed quickly.

Parametric Estimating Parametric estimates use information from past similar projects and other variables to calculate an estimate that is considered to be a relatively good confidence level. For example, if past experience tells you that three testers are needed to test 500 lines of code, then you may assume six testers are needed for 1,000 lines of code within a similar time frame.

Data Analysis Alternatives analysis, a form of data 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.

Project Management Information System 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

Meetings Meetings are commonly used to bring experts together during the estimation process.

Outputs of Estimate Activity Resources

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

Resource Requirements 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

Basis of Estimates Basis of estimates captures the additional information associated to the estimates developed. This may include things such as the following items:

• Any known constraints or assumptions
• Range of estimates
• Confidence level
• Methods used to develop the estimates
• Who produced the estimates
• Any risks associated with the estimates

Resource Breakdown Structure The resource breakdown structure (RBS) is a hierarchical structure that lists resources by category and type. Figure 3.17 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 documents updates include updates to the following items:

• Activity attributes
• Assumption log
• Lessons learned register

Inputs of Estimate Activity Durations

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

• Project management plan
• Project documents
• Enterprise environmental factors
• Organizational process assets

Project Management Plan There are two key inputs used that are part of the project management plan: the schedule management plan and the scope baseline. The schedule management plan sets the approach used and the level of accuracy required to estimate activity durations, including the project update cycle.

Project Documents Several documents can be referenced and used to help pull together the estimated duration of activities, such as those noted below:

• 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.
• 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
• Assumption Log Constraints and assumptions are considered when estimating activity durations.
• Milestone List The list of scheduled dates for specific milestones is necessary to estimate the 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.
• Project Team Assignments Team assignments include those assignments that have already been officially made, along with the named resources.
• Lessons Learned Register Lessons learned captured throughout the project can help estimate durations as the estimates are progressively elaborated.

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
• Any existing policies and procedures for developing estimates

Tools and Techniques of Estimate Activity Durations

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

• Expert judgment
• Analogous estimating
• Parametric estimating
• Three-point estimating
• Bottom-up estimating
• Data analysis
• Decision making
• Meetings

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” in Chapter 4.

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 15 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:

• Most Likely (ML) The estimate assumes there are no disasters and the activity can be completed as planned.
• Optimistic (O) This represents the fastest time frame in which your resource can complete the activity.
• Pessimistic (P) The estimate assumes the worst happens and it takes much longer than planned to get the activity completed.

There are two formulas that can be used with these three estimates: beta distribution and triangular distribution. Triangular distribution calculates a simple average of these three variables, as depicted in the following formula:

Beta distribution uses a weighted average, assigning a greater weight to the most likely estimate. The concept of the beta distribution 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.

Bottom-Up Estimating Bottom-up estimating involves calculating estimates at a granular level and then aggregating all of the estimates up to the work package level. This is helpful when it is difficult to come up with an estimate. In these cases, breaking up an activity into smaller pieces of work may allow the team to come up with an estimate at a higher degree of confidence.

Data Analysis Data analysis often includes the use of the alternatives analysis and reserve analysis techniques.

Alternatives analysis compares resource capability or skills as well as schedule compression techniques.

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 15 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.

Decision Making It is helpful to have multiple alternatives for future actions when estimating activity durations. Decision making is an assessment process that delivers those alternatives. By engaging team members, it improves estimate accuracy and commitment to the emerging estimates. This has the by-product of helping to win the hearts and minds of those contributing to the project.

Meetings Meetings help bring team experts together during the estimating process. Meetings are used in combination with other estimating techniques.

Outputs of Estimate Activity Durations

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

• Duration estimates
• Basis of estimates
• Project documents updates

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. Percentages also may be used to express the range.

• Original activity duration to install 15 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.
• Final estimate example using a percentage range: 7.5 hours ± 10%. Therefore, the activity may take as little as 6.75 hours or as much as 8.25 hours.

Basis of Estimates Basis of estimates includes all of the information and details used to develop the duration estimates. It is important to capture and archive this information for future use and reference. Examples of what may be captured include how the estimates were developed, the assumptions made, known constraints, the range of possible estimates, the confidence level for each estimate, and the identified risks.

Project Documents Updates The following information might 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 five inputs you should be familiar with:

• Project management plan
• Project documents
• Agreements
• Enterprise environmental factors
• Organizational process assets

Project Management Plan The scheduling method and tools used to create the schedule and a description of how the schedule is formulated are identified through the schedule management plan. In addition to this plan, the scope baseline is a key input to assembling the schedule. Both these elements are part of the project management plan.

Project Documents There are several documents used and referenced to develop the schedule. Some of these are outputs of the other scheduling processes covered thus far.

• 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.
• Assumption Log Constraints and assumptions recorded in the assumption log are used. The following time constraints are important to this process:
  • Imposed dates that restrict the start or finish date of activities
  • Key events/major milestones to ensure the completion of specific deliverables by a specific date
• Basis of Estimates If needed, the basis of estimates can provide additional detail on how duration estimates were developed.
• Project Schedule Network Diagram 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 diagram. For a more complete description of the project schedule network diagrams, see “Outputs of Sequence Activities” earlier in this chapter.
• 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.
• Duration Estimates Activity duration estimates will provide the time to complete each activity that is needed to assign start and finish dates.
• Lessons Learned Register As the project progresses, lessons learned are captured. These aid in carrying out this process as it occurs throughout future phases of the project.
• Milestone List The milestone list provides specific dates for documented milestones, which are important in assembling the schedule.
• Risk Register Developing the project schedule requires the details of all identified risks and their characteristics that will affect the schedule model.
• Project Team Assignments Developing the project schedule requires the project staff assignments, which specify resource assignments for each activity.

Agreements If vendors are engaged within the project, schedule information such as date commitments made by vendors is typically captured within the vendor’s agreement.

Enterprise Environmental Factors Existing holidays and other external information that could impact the project schedule may be used from within the enterprise environmental factors. Government or industry standards might also apply and should be referenced.

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
• Resource optimization
• Data analysis
• Leads and lags
• Schedule compression
• Project management information system
• Agile release planning

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 The 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:

• Critical Path The critical path (CP) is generally the longest full path on the project. Any project activity with a float time that equals zero is considered a critical path task. The critical path can change under the following conditions:
  • 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) is the amount of time you can delay the earliest start of a task without delaying the ending of the project
• Free float (FF) is 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 one. Add the duration of the activity and then subtract one to determine the early finish. This is based on the concept of calendar days.
3. The early start date of the next activity is the early finish date of the previous activity plus one. 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, plus one. (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 6.)

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 date will be the same as the early finish date.
2. Subtract the duration of the activity from the end date and add one to calculate late start. Take this number and subtract one to calculate 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 minus one of the activities 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.20 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. Float can be calculated for each activity by subtracting either the early start from the late start or early finish from the late finish (both will give you the same answer). 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.21 . In this example, the bottom path, or the following activity path, would be your critical path: 1, 4, 5, 6, 7, 8, 9 totally 101 days.

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 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:

• Resource Leveling Resource leveling attempts to smooth out the resource assignments to get tasks completed without overloading the resources and while trying to keep the project on schedule. This typically takes the form of allocating resources to critical path tasks first.
• Here are some examples of resource leveling:
  • Delaying the start of a task to match the availability of a key team member
  • Adjusting the resource assignments so that more tasks are given to team members who are underallocated
  • Requiring the resources to work mandatory overtime
• Resource Smoothing Resource smoothing is a technique that adjusts the schedule model by arranging the activities so that the requirements for resources do not exceed the constraints of the project. The key difference between resource smoothing and resource leveling is that, with resource smoothing, the critical path of the project remains unchanged. The ability to delay an activity is limited by the amount of an activity’s free and total float.

Data Analysis 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.

• What-If Scenario Analysis What-if scenario analysis evaluates different scenarios in order to predict their positive or negative effect on project objectives. According to the PMBOK^® Guide, this is an analysis of the question, What if the situation represented by scenario X happens? To support this effort, a schedule network analysis is performed using the schedule to calculate different scenarios, like the delay of a deliverable or a major weather event for a construction project.
• Simulation Taking different sets of activity assumptions, simulation calculates multiple project duration models using probability distributions constructed from three-point estimates to account for uncertainty. Simulation techniques such as Monte Carlo analysis use a range of probable activity durations for each activity, and those ranges are then used to calculate a range of probable duration results for the project itself. Monte Carlo runs the possible activity durations and schedule projections many, many times to come up with the schedule projections and their probability, critical path duration estimates, and float time.

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:

• Crashing Crashing is a compression technique that looks at cost and schedule trade-offs. This involves adding resources to critical path tasks in order to shorten the length of the tasks and therefore the length of the project. Crashing the schedule can lead to increased risk, increased costs, and a change in the critical path.
• Fast-Tracking Fast-tracking is performing two tasks in parallel that were previously scheduled to start sequentially. Fast-tracking can increase project risk and cause the project team to have to rework tasks, and it only works for activities that can be overlapped.

Project Management Information System 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.

Agile Release Planning When using Agile, this technique provides the release schedule and the number of iterations or sprints within the release, based on the product road map and product vision.

Outputs of Develop Schedule

Know the following outputs of the Develop Schedule process:

• Schedule baseline
• Project schedule
• Schedule data
• Project calendars
• Change requests
• 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:

Bar Charts Also known as Gantt charts, these tools are commonly used to display schedule activities. They may show activity sequences, activity start and end dates, resource assignments, activity dependencies, and the critical path. Figure 3.22 shows a simple example that plots various activities against time.

Project Schedule Network Diagrams Project schedule network diagrams usually show the activity dependencies and critical path. They will work as schedule diagrams when the start and finish dates are added to each activity.

Milestone Charts Milestone charts mark the completion of major deliverables or some other key events in the project. They can be displayed in a bar chart form, similar to a Gantt chart, or in a simple table format, as shown in Table 3.3 . As the milestones are met, the Actual Date column within the table is filled in.

Schedule Data The schedule data refers to documenting the supporting data for the schedule. At least the following elements must be included within the schedule data:

• Milestones
• Schedule activities
• Activity attributes
• Assumptions
• Constraints
• Any other information that doesn’t fit into the other categories
• Resource requirements by time period, often in the form of resource histograms (suggested by the PMBOK^® Guide)

Project Calendars A project calendar is a template of sorts that clarifies the working days and shifts that are available for scheduling activities.

Change Requests After the project is baselined, changes may come about as a result of progressive elaboration. Changes to the schedule may also result from approved changes to the scope of the project.

Project Management Plan Updates Updates may be made to the schedule baseline, the cost baseline, and/or the schedule management plan.

Project Documents Updates Updates may be made to the following project documents:

• Resource requirements
• Activity attributes
• Assumption log
• Duration estimates
• Lessons learned register
• Risk register