Schedule Model Good Practices Overview PDF

3 SC HE D U L E MODEL GO OD P RAC TI C ES OV ERV I EW This section provides guidance and information on generally accepted good practices associated with the planning, developing, maintaining, communicating, and reporting processes of an effective CPM schedule model approach. This section covers...

3 SC HE D U L E MODEL GO OD P RAC TI C ES OV ERV I EW This section provides guidance and information on generally accepted good practices associated with the planning, developing, maintaining, communicating, and reporting processes of an effective CPM schedule model approach. This section covers the following: 3.1 Schedule Management 3.2 Schedule Model Creation 3.3 Schedule Model Maintenance 3.4 Schedule Model Analysis 3.5 Communication and Reporting This section provides common requirements, terminology, and associated functionality. This section links the discussion of the schedule processes described in Section 2 to the scheduling components defined in Section 4. This section provides an overview, with examples, of how to create and maintain an effective schedule model. 3.1 SCHEDULE MANAGEMENT Schedule management encompasses the scheduling-related efforts of the project team as part of the Develop Project Management Plan process. Schedule management ensures that all applicable Project Management Process Groups and Knowledge Areas are properly integrated within the overall schedule model. The schedule management plan guides the development of the schedule model. A schedule model requires planning and design in the same way that every project deliverable is planned and designed. The project team needs to consider a variety of factors to create a schedule model that can be a useful tool for the project. The schedule model is used by the project team to monitor performance on the project, communicate information regarding the work, and compare the planned work with the actual progress. These concepts are developed in support of the Develop Project Management Plan in accordance with the PMBOK® Guide. 45  Schedule management addresses the following: Training requirements for the project team members, which should include establishing a common understanding uu of scheduling policies, procedures, and software technologies. For example, requirements should address progress reporting, capturing project risks, and reflecting mitigation activities in the schedule model; Processes and procedures for schedule model data management, such as data formatting, versioning, uu accessibility, storage and retrieval of the data, disaster recovery, and business continuity; Policies related to the methodology that will be used in the schedule model development and maintenance, uu such as: nnApplicable performance thresholds typically defined by key performance indicators (KPIs), nnContent and frequency of presentations and reports, nnEarned value management (EVM) and earned schedule implementation and integration, nnCompatibility with other subsidiary project-related plans, nnCoherence with the applicable life cycle and resulting work breakdown structure (WBS), nnRisk tracking, nnActivity granularity, nnConsiderations of contractual obligations, nnConsideration of resource requirements or constraints, and nnPotential contract liabilities (claims, mediation, arbitration, litigation, etc.). Processes and procedures for the following areas should be considered: uu nnPlanning, updating, and maintaining the schedule model during the project life cycle; nnDetermining an appropriate cycle to obtain the project status; nnUpdating the schedule model; and nnPublishing the results to all project stakeholders in accordance with the communication management plan. 3.1.1 SCHEDULE DATA MANAGEMENT PLAN The initial focus for developing a good schedule model is on the design aspects of the model for the specific project. Each project is unique and the schedule model varies from project to project. The project team needs to define some basic schedule model inputs and expected outputs to ensure that the minimum infrastructure needed to support stakeholder requirements, backups and restores, disaster recovery, and business continuity are put into place. The project scope, work breakdown structure (WBS), resource definitions (when required), and other schedule components 46 Section 3 should have already been defined so that the team does not have to define these elements while developing the schedule data management plan. However, if these project elements have not been defined or developed at this point in time, the project team needs to focus on these areas before considering the schedule data management plan. At a minimum, the project team should consider the following when developing the schedule data management plan: Define the list of schedule users, access rights, and responsibilities that each user will have. For example, some uu users provide progress, while others have greater schedule access and are responsible for administrative functions. Still others may be read-only users that cannot add or modify data but can review it and produce reports. Determine the frequency (i.e., daily, weekly, or monthly) for backup of the schedule data. Backups are an uu important part of schedule data configuration management. Required frequencies for backups are often established by stakeholder expectations. This is critical to the concept of business continuity, as it establishes valid recovery periods should some catastrophic data failure occur. It determines how accurate the recovered data will be at any given period. Determine how previous instances of the schedule will be retrieved, by whom, at what intervals, and verify uu that the procedures for data retrieval are accurate. A common mistake made is that backups are performed, but there is no retrieval procedure. This becomes part of the business continuity plan. Determine the data retention requirements for the schedule model data. For some projects, the legal or local uu requirements determine how the project data should be stored and for how long. It should be easy to access at any time for audit purposes. Identify risks associated with the development of the schedule model related to the schedule data management. uu For projects where users are distributed globally, user privileges to access data in different time zones could lead to a conflict between infrastructure availability and the ability to apply infrastructure maintenance activities (i.e., patches and upgrades). Backup, data replication, and high availability as a contingency in a disaster and recovery infrastructure could also be impacted. Protecting the data in the project is key to ensure availability, accessibility, and recoverability of data in the event of equipment failure, intentional or unintentional destruction of data, or disaster of any kind. 3.1.2 SCHEDULE MANAGEMENT PLAN The schedule management plan is a collection of processes, approaches, templates, and tools that comprise the project’s execution strategy and objectives as reflected in the project’s schedule model. The schedule management plan is unique to each project and is comprised of requirements defined by the implementing organization as well as 47 the project scope documents. The schedule management plan defines how the schedule model will be developed, updated, progressed, and shared. The schedule model predicts how the project will react to specific project factors either known now or anticipated in the future. Good practice dictates that, to ensure quality, all schedule models should be guided by a methodology that provides a checklist of requirements for the schedule model. Determine the data hierarchy requirements for reporting purposes (as defined in the communications management plan) and how these requirements impact the schedule data management process and data model. For example, the types of activities shown to the steering committee are different than those shown to the project manager. The schedule management plan requires components that enable the successful achievement of an efficient scheduling process. Such a plan also enables the project team members to perform in a consistent manner. Projects that do not have a schedule management plan tend to be inefficient, which results in higher costs, increased risk, and longer project durations. The schedule management plan includes the elements described in Sections 3.1.2.1 through 3.1.2.12. A master list of the required documents and data should be created to ensure all aspects are covered. 3.1.2.1 SCHEDULING APPROACH The project team should have access to the project documentation that defines the schedule approaches approved by the organization to comply with the organizational and project requirements. Based on this information, the scheduler implements the scheduling approach as determined by the project team. For more information about scheduling approaches, refer to Section 2.2. 3.1.2.2 SCHEDULING TOOL Selection of the scheduling tool is based on the scheduling approach selected and should comply with the organizational and project requirements related to the tool. Careful consideration should be given to any requirements that a selected tool may impose to ensure compatibility. 3.1.2.3 SCHEDULE MODEL CREATION PLAN The project manager, in conjunction with the project team and key stakeholders, determines the plan for schedule model creation. This centers on how the schedule model will be created and how all the parts will fit together. The key considerations include: schedule approach and stakeholder participation in the Develop Schedule process in accordance with the PMBOK® Guide. 48 Section 3 3.1.2.4 SCHEDULE MODEL ID Every schedule model needs to have a unique identification that is specific to the project and does not change. This allows for tracking schedule models over time and allows analysis and discussion of each model without confusion. It also provides an excellent historical catalog for analysis at a later date. Most organizations establish standard naming conventions that allow each project to be uniquely identified over the project life cycle. 3.1.2.5 SCHEDULE MODEL INSTANCE Each instance of the schedule model has a unique identifier. The location of this identifier varies and depends on the organizational process assets and tools used to control it. A unique schedule model instance identifier is essential to allow the proper archiving of project documents and audit processes. The schedule management plan and/or the configuration management plan provides the format for this component to ensure proper file naming conventions, that version control is created and maintained, and that redundant naming does not occur. 3.1.2.6 CALENDARS AND WORK PERIODS A default project calendar is defined. Calendars may also be defined for specific activities or portions of the project including resources. Some of the calendar elements to be defined include: Working days in a week, uu Number of shifts to be worked each day, uu Number of hours to be worked each shift or day, uu Any periods of scheduled overtime work, uu Nonworking time (e.g., holidays, shutdowns, blackout dates, restricted times, etc.), and uu Time zones for geographically distributed teams. This element relates to the way international projects need uu to function when products are being developed and delivered from other locations. There is a timing issue that should be planned for in the model. Special international calendars should be created. These calendar elements play a major role in determining the number and structure of the project calendars required for the schedule. The use of multiple calendars introduces significant complexity to the calculation of float and the critical path. This may be even more complex on a geographically distributed project. However, while scheduling is simplified by using a single calendar, one calendar may be inadequate for managing a project spread across time zones (e.g., a geographically distributed project team with associated local holidays), or where the project team has different work schedules. 49  Generally accepted practice is to use a default project calendar that is adequate and reasonable to perform the work, based on the project’s normal working times. This project calendar is used as the default calendar for project activities. This practice allows the project team to establish and schedule different working periods or calendars, if needed, for certain activities. 3.1.2.7 PROJECT UPDATE CYCLE AND ACTIVITY GRANULARITY The update cycle is the regular interval in which the current status of the project is reported. The appropriate frequency for performing updates and reporting status against the schedule is defined as part of the schedule management plan. This includes determining at what point in the cycle the update occurs and how often the status is reported. The update cycle reflects how management intends to use the data generated from the schedule model. The timing of review meetings, management reporting requirements, and payment cycles are often tied to updates. The update cycle selected should provide management with an optimum level of control information without being overly burdensome to those doing the reporting and analyzing. The optimum update cycle varies with the industry and project—from hourly updates for planned outage projects in manufacturing/production facilities, to weekly or monthly updates for major construction or software development projects. The update cycle selected has a direct relationship to the activity durations contained within the schedule. Experienced practitioners often divide the update cycle into two separate parts: (a) incorporating progress into the model and (b) maintenance (issues discovered in the schedule that are no longer supportive or were input incorrectly, etc.). This serves to reduce the progress reporting time to a minimum period. The choice of update cycle is influenced by several factors, such as the rate of change in the project, the potential impact the changes may have on the project, and the duration of the project. For relatively stable, long-term, low-risk projects, a monthly or bimonthly status cycle may be appropriate. For volatile, high-risk projects, updates may be required for every shift change or on an hourly basis. For maximum visibility and exposure, status information for these projects may be displayed in large meeting rooms. Consideration should also be given to the cycle time between updates. It should be sufficient for the information provided from the last update to be issued, analyzed, and acted upon by the project team prior to the next update. The update cycle established should coordinate with the contract or organizational processes. The project team should consider which timescale to use: hours, days, weeks, or months. The timescale selected depends on the frequency of the control processes and the level of detail needed in the activities. Most of the time, activity timescales remain consistent throughout the project. However, specific project evolutions may require different timescales that are effective for that evolution. 50 Section 3  Consideration should also be given to the granularity of the project activities. Granularity considers how many activities the schedule model contains and maintains. When determining the desired granularity of the schedule, keep in mind that too much detail produces a confusing and overly large schedule model that is difficult and expensive to manage. However, too little detail results in an insufficient flow of information and makes ongoing project control more difficult. The project team should determine the optimum detail, which could be different for every project. Resource scheduling requirements can also impact schedule granularity. The level of schedule detail also impacts the project’s communications management plan. 3.1.2.8 MILESTONE AND ACTIVITY CODING STRUCTURE Understanding the types of reports, analysis, stakeholder/client demands, and management plans for managing and controlling the project data obtained from the schedule model has a large impact on the project coding structure. The coding allows for the creation of presentations (see Section 3.5) of the schedule model and provides guidance on the coding structures that are built into the schedule model. Due to advancements in project analysis tools and software, specific code fields are often used to show the unique location of the work within the project so that 4D models, location-based scheduling (LBS), and other reporting tools can display project progress visually. Well-designed coding structures are also helpful in analyzing project performance data by grouping, selection, and sorting to highlight trends and anomalies. The coding provides assistance in the development and maintenance of the schedule model as identified in the communications management plan, and helps to meet the project reporting requirements. The use of a sound, well-conceived activity coding structure that is separate from the activity identifier is essential. Activities can be coded with more than one code for each activity, with each code holding a separate value, which allows outputs to be customized for different purposes. For example, codes can be used to identify project phases, subphases, locations of work, project events, gates, significant accomplishments, sources of supply, sources of design, and the person or organization responsible to perform the activity. These codes can be used alone or in multiple combinations. To achieve flexibility and enhanced functionality, most scheduling software supports multiple codes for each activity. A structured activity numbering or identity scheme should form part of the overall coding design. The use of a structured activity identification system provides schedule users with a better understanding of how a particular activity fits into the bigger picture by grasping the significance of the activity identifier itself. For example, the identifier scheme can tie back to the project WBS. At a minimum, an activity identifier needs to be unique and follow a scheme appropriate to the project. 51 3.1.2.9 RESOURCE PLANNING The schedule model should include the identification of resources necessary to accomplish the activities. Resources can be of any type (e.g., human resources, machines, materials, location, etc.). The schedule management plan identifies the elements required for resource planning and management. Items to consider are resource availability, resource calendars, and resource skill sets. Understanding the critical resources for a project and how their availability may impact the schedule allows for better management of the overall project. Resource availability, human resource skill levels, and the dates and number of work periods (in calendar units) that a given resource is available have a major impact on projects. While loading specific resources into the model, it is critical to identify specific needs over time to include ramp-ups at the beginning of the project, peak demand periods, and reasonable ramp-downs at the end of the project. Any one of these factors can have an impact on the project. These factors also help to identify and understand the critical issues and mitigate negative impacts to the overall project. Resource-loading curves and reports allow management to look at the resulting projections to determine whether the plan is achievable or whether the end date should be adjusted. These resource curves and the data generated by the model also help to understand the impacts that the project may experience from external influences (e.g., hurricanes, etc.). Although resource loading of the schedule model is not required, it is a good practice. Resources should be considered by the project team when determining activity durations and activity sequencing. A resource-loaded and leveled schedule clearly indicates the interdependencies and impacts that the availability of resources has on project duration and cost. 3.1.2.10 KEY PERFORMANCE INDICATORS To let the stakeholders know how the project is performing, many projects incorporate key performance indicators (KPIs). These enable the project team to measure progress and monitor performance toward predefined project goals (e.g., performance ratings, schedule health, EVM, and earned schedule). Performance issues and schedule health can include tracking the following: Number of activity starts and finishes vs. the expected number of activities in a given period, uu Backlog of activities in progress, uu Percentage growth in activity durations, uu Number of added activities or deleted activities, and uu Any other type of indicator that explains and depicts project performance. uu EVM can combine measurements of scope, schedule, and cost within a single integrated system, which provides cost-based indicators. The application of EVM analysis in the early stages of a project increases the validity and effectiveness of the schedule and cost baseline. Once established, this baseline underpins the understanding of 52 Section 3 project performance during project execution. EVM can be expanded to include the concept of earned schedule, which provides time-based indicators to complement cost-based indicators for project performance. For more information about EVM and earned schedule, refer to Section 3.4.12 and The Standard for Earned Value Management. The project communications management plan may also indicate specific areas of focus with indicators that need to be monitored. These are usually specific project deliverables or aspects that management believes are directly related to the ultimate success or failure of the project. 3.1.2.11 MASTER SCHEDULE MODEL The schedule model is designed and built as a master project containing subprojects. The subprojects can be structured according to the various teams responsible for specific subprojects of the bigger master project scope that comprise the project. Examples of subprojects include phased execution (engineering, production, testing, and integration), globally distributed teams, or the contracting strategy (e.g., multiple projects or multiple project managers). These subprojects should be linked to each other in certain identified delivery/acceptance or interface points to ensure that there is an integration between the plans. The schedule management plan defines the steps used to create, manage, and control the master schedule, subprojects, and project interdependencies. 3.1.2.12 CHANGE CONTROL Project change is inevitable, so it is essential to plan on how to deal with change (see Part 1, Section 4.6 of the PMBOK® Guide). Because projects are highly dynamic and change can occur frequently within the project, the project team needs to plan for and manage change. Good scheduling practice ensures that, as revisions or adjustments are made to the schedule as a result of project changes, the affected schedule activities and subsequent risks are identified and marked as associated with a specific change in accordance with the configuration management plan. This is especially important when the change results in additional work and may affect the project’s schedule or cost. It is also critical when using the schedule baseline (discussed later) for benchmarking. 3.2 SCHEDULE MODEL CREATION This section offers a general overview of the essential elements for developing a sound schedule model. Good practices for each component are contained in the components list in Section 4 of this practice standard. A review of Section 4 is strongly encouraged to understand all aspects associated with each component. It is crucial to take into consideration all of the information, procedures, and restrictions documented in the schedule model management section. 53  A schedule model provides a useful detailed plan that can be used by the project manager and the project team to assist in completing the project successfully. The project team develops the schedule model as a tool that is in alignment with the schedule management plan. The schedule model captures the team’s vision of how the project will be performed and how the project is expected to react to changes over time. The project team modifies the schedule model appropriately to reflect changes (e.g., progress, scope, etc.) throughout the project life cycle. A well-developed schedule model is a dynamic tool that provides a reasonable prediction of when the remaining project work can be expected to be accomplished. It allows the project team to look at the performance of the project to date and use that data to make accurate forecasts for the project evolutions that remain to be accomplished. Once the project has been completed, the schedule model forms the basis for lessons learned activities that become the foundation for similar projects in the future. The schedule model is also a critical component in any forensic scheduling analysis that may be required on the project. The schedule model describes: Work to be done (what), uu Resources required to do the work (who, what, and when), uu Activity durations (how long) based on resource availability and productivity, and uu Optimum activity sequence (when) based on logical relationships between schedule activities, resource uu availability, and calendars. The way to do the work (how) is defined by other documents in the overall project management plan. Establishing a realistic and achievable schedule model is one of the critical initial actions. Some important points to consider during the schedule model creation are: Ensure that the project requirements are understood and satisfied. The project team reviews and uu understands the project’s scope, which provides guidance for the development of a work breakdown structure (WBS). The project’s scope provides the background, information, and understanding needed to develop the schedule model The goal is to ensure that all aspects of the project execution have been adequately defined and included in the schedule model. Activities in the schedule model represent the work that produces the deliverables or work packages identified in the WBS. Therefore, all work packages in the WBS should be directly traceable to a schedule activity or group of activities. The schedule activities can often be organized to reflect the hierarchy of the WBS. Conversely, each activity should roll up into only one WBS element. Verify resource availability and assignments. The project team benefits greatly from a resource-loaded uu schedule. During the schedule model creation process, it is important that the resource availability and assignments are verified. The labor, material, equipment, and infrastructure needed to accomplish project 54 Section 3  activities can be planned in advance, and anticipated problems can be mitigated. A feasible schedule model assumes that sufficient resources are available to accomplish the activities as scheduled. This becomes much easier when the schedule model is resource loaded, since resource requirement curves, burn rate, and other resource-focused reports are then available. For more information on resources, see Section 9 of the PMBOK® Guide on Project Resource Management. In the same way that activity codes are used to classify and organize activities, resource codes (attributes) can be assigned to classify resources according to organization, skill level or type, reporting structure, etc. In addition, resource identifiers (resource IDs) may be structured into a meaningful scheme, similar to activity identifiers (activity IDs). 3.2.1 DEVELOP SCHEDULE MODEL BASELINE The development of a good schedule model is achieved through the consistent application of sound practices. Experience gained over time helps to select appropriate responses to the design requirements for the schedule model. The key steps are explained below in Sections 3.2.1.1 through 3.2.1.9. 3.2.1.1 DEFINE MILESTONES Once there is an understanding of the overall structure for the project data discussed previously, begin to lay out the project’s milestones. A milestone has zero duration, has no resources assigned, is used as a benchmark to measure progress, and may also reflect the start and finish points for various project events. Generally, a milestone represents the start or completion of a portion or deliverable of the project. It may also be associated with external constraints, such as the delivery of specific required approvals or deliverables. Each project should have a start milestone and a finish milestone. See Section 3.5 for an example of a start milestone and finish milestone. The project contains a list of milestones initially developed when the schedule model is created. These may have originated from the customer, team members, or other stakeholders. As the schedule model is developed, additional milestones are added as needed. It is an iterative process. (Note that in some cases, activities may be defined before milestones.) 3.2.1.2 DEFINE THE PROJECT’S ACTIVITIES Create the list of activities that need to be performed to complete the project based on the WBS and elaborated by the team responsible for the execution of the work. These activities should represent the expected sequence of the activities and represent the manner of how the work will occur. An activity is a measurable and discrete element 55 (or block) of work that is a tangible element of the project scope. Activities are specific actions that are performed to produce the project deliverables. The characteristics of a well-defined activity include: Activity owner. Multiple resources may be required to accomplish the activity; however a single person is uu responsible and accountable for its performance. That individual should also report progress on the activity. Activity description. Activities describe the work that needs to be accomplished. As such, the description for uu each activity starts with a verb and contains a unique, specific object. Although “pour wall” may be descriptive of a task, the activity description needs to be more specific. Adjectives may be helpful to clarify ambiguities. For example, “pour east wall foundation from x to y” or “review Section 3 terminology.” Each activity description should be unique and leave no room for confusion; that is, it can be identified without ambiguity, and it should be independent of the schedule presentation grouping or organization. Continuity of work activity. The work represented by an activity, once started, should be capable of proceeding uu to completion without interruption (except for naturally occurring nonwork periods in the calendar). When the work on an activity is suspended or delayed, it is often beneficial for the activity to be split into two or more activities at natural break points. Activity duration. Typically, an activity’s duration should be less than two times the update cycle. This allows uu the reporting of the start and finish of an activity within one or two update cycles, enabling management to focus on performance and corrective actions, if needed. Exceptions to this general rule are continuous activities, some of which are defined below: nnSummary activity. A summary activity is a single representation of activities aggregated by common attributes within the schedule model and can be created in a number of ways: mmThe first example is when the activity describes, in broad terms, the effort to be performed, and the project does not have enough information to break it down into greater detail or does not desire to track it at a lower level of detail. Examples of this are boring a 2-mile-long tunnel or paving several miles of highway. See the first activity in Figure 3-1. In this example, the activity reflects the entire duration of the tunnel work and nothing else. mmThe second method is when the activities are automatically rolled up to create a summary of all the similar activities as shown in Figure 3-1. In this example, the activities under Group A and under Group B are summarized by a single bar shown above the activities to reflect what is shown under that bar and coded to the appropriate group. Note that the start and finish dates reflect the early start date and the early finish date and not the late dates; also the duration reflected on the summary bar matches the elapsed time from start to finish of the group activities. Some software programs accomplish this summarization automatically within the software. In doing so, the software rolls up the data according to specific rules and depicts them as a bar extending over some duration. It is important to fully understand how the particular software is accomplishing this summary so that inaccurate or confusing data are not developed and presented. 56 Section 3  mmA third example of a summary activity is an activity that can take longer than two or three update periods such as a procurement activity performed by someone outside the project and expected on the site at a particular date. The status of the work effort cannot be incorporated in the schedule other than accounting for time until the event occurs. See the last activity in Figure 3-1. Example Project Original 2019 November 2019 December 2019 January 2020 February 2020 March 2020 Activity Name Start Finish Duration 20 27 03 10 17 24 01 08 15 22 29 05 12 19 26 02 09 16 23 01 08 15 2 Summary 75 04-Nov-19 14-Feb-20 14-Feb-20, Summary Bore a Two Mile Long... 75 04-Nov-19 14-Feb-20 Bore a Two Mile Long Tunnel Group A 36 04-Nov-19 23-Dec-19 23-Dec-19, Group A Start of a Project 0 04-Nov-19 Start of Project, 04-Nov-19 Task A 10 05-Nov-19 18-Nov-19 Task A Task C 15 03-Dec-19 23-Dec-19 Task C Task B 10 19-Nov-19 02-Dec-19 Task B Group B 21 04-Nov-19 02-Dec-19 02-Dec-19, Group B Task E 10 19-Nov-19 02-Dec-19 Task E Task F 10 19-Nov-19 02-Dec-19 Task F Task D 20 04-Nov-19 29-Nov-19 Task D Procurement 50 04-Nov-19 10-Jan-20 10-Jan-20, Procurement Fabricate and Deliver... 50 04-Nov-19 10-Jan-20 Fabricate and Deliver a Special Component Figure 3-1. Summary Activities nnLevel-of-effort (LOE) activity. A level-of-effort (LOE) activity is incorporated into the schedule to track, account for, and spread resources over a period of time. However, this does not accomplish a discrete, specific deliverable product. One example of this is accounting for project hours associated with administrative support. In this case, the activity duration should reflect the anticipated time for the activity. Generally, LOE activities should not appear on the project critical path nor drive the project end date. Care needs to be given to LOE activities, because when they are given static durations equal to the length of the entire project, they should never end up on or drive the critical path. By their very nature of supporting detailed work activities, LOEs cannot drive the project duration and cannot be critical; they are supportive in nature. It is a good practice to define LOE activities in such a way that they will take their duration from the detailed activities that they support. Generally, the duration of an LOE is determined by its logical relationships that determine when it starts and finishes. These are typically shown as a start-to-start (SS) predecessor relationship and a finish-to-finish (FF) successor relationship and no others (see Figure 3-2). When completed, the LOE activity 57  Construction 113d A1050 Prep 11d A1060 Excavation 15d LOE A1070 Foundation 16d A1075 EQUIP: Crane 17d A1080 Structural Steel 21d A1090 Roof 11d A1100 Windows 19d A1110 Envelope 25d Figure 3-2. LOE Activity list describes 100% of the work required to be completed for the project, although not all activities need to be fully detailed when rolling wave planning is used as described in Section 2.2.4. Resource leveling should not be performed on LOE-type activities. Constraints should not be applied on LOE activities. LOE activities can have specific assigned resources and calendars to determine their start and finish dates. nnHammock activity. A hammock activity is a bridging activity that uses and is confined by the SS and FF relationships to supporting activities. An LOE activity is unlike a hammock activity because LOE activities may have many types of relationships associated with them. See Figure 3-3. Example Project Original 2019 November 2019 December 2019 January 2020 Activity Name Start Finish Duration 20 27 03 10 17 24 01 08 15 22 29 05 12 19 Group B 21 04-Nov-19 02-Dec-19 02-Dec-19, Group B Task E 10 19-Nov-19 02-Dec-19 Task E Task F 10 19-Nov-19 02-Dec-19 Task F Task D 20 04-Nov-19 29-Nov-19 Task D Group C 30 19-Nov-19 30-Dec-19 30-Dec-19, Group C Task J 10 17-Dec-19 30-Dec-19 Task J Task G 10 19-Nov-19 02-Dec-19 Task G Task H 10 02-Dec-19 13-Dec-19 Task H Hammock 40 05-Nov-19 30-Dec-19 30-Dec-19, Hammock Hammock Activity 40 05-Nov-19 30-Dec-19 Hammock Activity Figure 3-3. Hammock Activity 58 Section 3 3.2.1.3 SEQUENCE ACTIVITIES The sequencing of activities and milestones together with logic is the foundation of any schedule model. The method of connection is defined as a relationship. Every activity and milestone except the first (with no predecessor) and the last (with no successor) should be connected to at least one predecessor and one successor activity. With the exception of the start milestone, a preceding activity needs to finish or start prior to any activity starting, and in turn, that activity should be totally or partially completed to allow another activity to start. See Figure 3-4 for examples of these various types of relationships. Typically, each predecessor activity finishes prior to the start of its successor activity (or activities). This is known as a finish-to-start (FS) relationship. Sometimes it is necessary to overlap activities. In this case, an option may be selected to use start-to-start (SS), finish-to-finish (FF), or start-to-finish (SF) relationships. Figure 3-4 provides examples of the four relationship types in CPM. Most (or in some cases, all) relationships in a detailed schedule model will be FS relationships. FS relationships result in the simplest and least-complicated calculations for the schedule model. When other types of relationships are used, they should be used sparingly and with an understanding of how the relationships have been implemented in the scheduling software. Ideally, the sequence of all activities is configured so that the start of every activity has a logical relationship from a predecessor and the finish of every activity has a logical relationship to a successor. These practices prevent the schedule from being plagued with open ends. See Section 3.4.6 for examples of open ends and virtual open ends. Lag(s) may also be assigned to some relationships. A lag imposes a delay between its preceding activity and its succeeding activity. A lag on an SS dependency delays the start of the successor, and a lag on an FF dependency delays the finish of the successor. For example, if an activity has an SS dependency with a lag of +5 days, it would delay the start of the successor activity until 5 days after the predecessor activity has started. The scheduler should use lags with care and understand their impacts. Lags should only be used to represent delays that are physically necessary, represent no work, and have duration but no resource assigned. Lags should not be used to represent a period of time when work is actually occurring, such as review of a document before the next phase proceeds. It is recommended that this type of work be shown as an activity in the schedule model instead of using a lag. When included, such activities may be coded to show that these are activities for which another party (e.g., the client) is responsible. These activities are sometimes referred to as schedule visibility tasks (SVT). This practice allows for better control of the project and makes it obvious when a specific entity is impacting the project. Using more than one calendar in a schedule model may impact the calculated lag results within the schedule model. Additionally, understanding how different software packages handle multiple calendars is extremely important. It is also possible to assign constraints to activities and milestones that require an activity or milestone to start or finish at specific points in time. It is imperative to study the various types of constraints that are used and understand 59  Finish to Start The initiation of the successor activity FS depends upon the completion of the Activity X Activity Y predecessor activity. In this example, Activity X must be complete before Activity Y can begin. Finish to Finish The completion of the successor activity FF depends upon the completion of the Activity X predecessor activity. In this example, Activity X must be complete before Activity Y can finish. Activity Y Start to Start The initiation of the successor activity depends upon the initiation of the Activity X predecessor activity. SS In this example, Activity Y can start after Activity X has started. Activity Y Start to Finish The completion of the successor activity depends upon the initiation of the Activity X predecessor activity. In this example, Activity Y cannot complete until Activity X has started. SF Activity Y Figure 3-4. Illustrations of Relationship Types in CPM Methodology the effects and nuances their use has upon the schedule model. The generally accepted practice is that constraints and lags should not be used to replace the addition of activities and relationships. However, the use of constraints is generally acknowledged as necessary to meet contractual obligations. Each activity, excluding the initial start milestone, should have a driving predecessor relationship—an F-S or S-S predecessor (?S relationship)—which determines logically when the activity should start. In a similar manner, every activity, excluding the final finish milestone, should also drive a successor activity through an F-S or F-F successor 60 Section 3 relationship (F? relationship). See Figure 3-5. Note that the “?” in the previous statements and in Figure 3-5 can represent either a start (S) or finish (F) type of relationship. The activity requires at least one “?S” relationship Any Typical Activity The activity requires at least one “F?” relationship Figure 3-5. Required Activity Relationships When these types of logical relationships are not found in the schedule, the activities are known as dangling or open. This creates uncertainty and likely presents invalid data into the schedule model, resulting in the production of inaccurate project information. See Section 3.4.5 for more detail that will help to clarify the condition. 3.2.1.4 DETERMINE RESOURCES FOR EACH ACTIVITY Estimate Activity Resources is the process for determining the type and quantities of material, labor, equipment, or infrastructure required to perform each activity. When a project is constrained in terms of resources and the project duration could be impacted, resources should be incorporated into the schedule model. Although sometimes performed together, the Estimate Activity Resource process should be completed prior to Estimate Activity Durations (see PMBOK® Guide for more information and for more clarity concerning resource availability issues). The hours needed for a senior designer to accomplish the activity versus a junior designer to perform the same activity could be considerably different, thus impacting the duration and quality of activity outputs and ultimately the cost of the project. On some projects, especially those of smaller scope, the following activities are so tightly linked that they are viewed as a single process: defining activities, sequencing activities, estimating resources, estimating activity durations, and developing the schedule model. In addition, resources can impact the critical path when not considered by the project team. 61 3.2.1.5 DETERMINE THE DURATION FOR EACH ACTIVITY The duration is an estimate of the working time necessary to accomplish the work represented by the activity. In the case of team resources, the number of resources that are expected to be available to accomplish an activity, together with the standard or expected productivity of those resources, often determine the activity’s duration. A change to a driving resource allocated to the activity will have an effect on the duration, but this is not a simple, straight-line relationship. Other factors influencing the duration are the type or skill level of the resources available to undertake the work, resource calendars, the risk associated with the work, and the intrinsic nature of the work. Some activities (e.g., a 24-hour stress test) take a set amount of time to complete regardless of the resource allocation. While it is feasible to estimate a duration for an activity at any time, generally accepted good practice recommends (a) defining the activity first, (b) tying it logically into the overall schedule sequence, and (c) focusing on activity resources and duration. At this point in time, the relationship between the activity duration and work in the schedule is better understood; so resource flows, activity team sizes, etc. can begin to be determined. The relationship between the activity’s duration and its cost is made explicit in the basis of estimate or assumptions for both the cost and the schedule. This document should be kept current as schedule durations change during schedule model maintenance. See Sections 3.3 and 3.4 for more information. The scheduler should understand the method used by the schedule model in order to plan the activities related to duration estimation for each schedule activity. There are two types of schedule model methods: Deterministic schedule models. Deterministic schedule models are networks of activities connected with uu dependencies that describe the work to be performed, static duration, and planned date to complete the project if everything goes according to plan. Probabilistic schedule models. Probabilistic schedule models are networks with all elements of a deterministic uu schedule model, where the activity duration of the tasks are random variables with assigned minimum and maximum durations and an appropriate probability distribution. For more information about estimating activity duration, refer to the Practice Standard for Project Estimating. For more information on the best practices for project risk analysis using probabilistic schedule models, see The Standard for Risk Management in Portfolios, Programs, and Projects. 3.2.1.6 ANALYZE THE SCHEDULE OUTPUT Once completed, the schedule model contains a set of unique activities that have varying durations and are connected by defined logical relationships. The schedule model provides the project team with information on what needs to be accomplished and the sequence required to accomplish the project deliverables. However, the schedule model does not indicate when these various activities should be performed. In order to acquire that information, the 62 Section 3 scheduling tool is activated to calculate the dates and other values within the schedule model according to the chosen scheduling method. The scheduling function always requires three distinct processes for time analysis, and it requires a fourth process when resource smoothing or leveling is being used. The discrete steps are: Step 1. Assign a start date to the start milestone. Then, moving throughout the network from activity to uu activity (from left to right) and in the sequence defined by the logical relationships, assign start and finish dates for each activity and milestone, as determined by the defined durations. This is called a forward pass. The start and finish dates for each activity are called the early start and early finish dates. When the analysis reaches the end of the schedule model, the software determines the earliest possible finish date for the project and the shortest project duration based on the activity’s estimated durations and logical relationships as defined. Step 2. Assign a finish date to the end milestone. This could be the same date as the one calculated by the uu forward pass or a different date that was applied as a constraint due to contractual requirements, etc. The analysis process then works back through the network from right to left until it arrives back at the start milestone, and the software assigns another set of start and finish dates for each activity. This is called the backward pass and establishes the late start and late finish dates for each activity and milestone. The late start and late finish dates represent the latest dates that each task can start and finish without causing a delay in the finish date of the project. Step 3. Calculate float values by comparing the early and late dates (see Section 3.4.2 for more detail): uu nnTotal float. Calculate total float by subtracting the early finish date from the late finish date (or the early start from the late start). Negative total float means dates are not feasible without changing the plan. Note—Total float is reflected on each activity but is derived from the project as a whole. It indicates the number of days that the critical path of the project may slip (or needs to be recovered) to meet the desired end date. The value is a shared value between all of the activities on a specific path for the project. Thus, any activity on that path may use some or all of it, or recover some or all of it, as needed. nnFree float. Calculate free float by subtracting the early finish date of the activity from the early start of the earliest of its successors. Free float is never a negative value. Note—Free float indicates the amount of time a predecessor may slip before impacting its successor. Step 4. Conduct resource leveling. Once the float values have been calculated, conduct resource leveling uu to minimize resource overallocations or reduce the fluctuations in resource demand. If this process is done automatically, determine the processes and algorithms to be used. Most project scheduling software packages have multiple options and settings that can have a significant impact on the resulting resource-leveled schedule. Regardless of the scheduling software settings, there is a trade-off between allowing the leveling solution to extend the project total duration and allowing the use of more resources than initially allowed. Resource availability may be increased by adding more resources to the team or by using overtime. 63  Review the complete view of resource allocation across all activities before finalizing the overall resource leveling. When a resource-level solution is determined, make manual adjustments to the schedule logic (e.g., increase or decrease durations, add or remove relationships, or insert or delete lags to relationships or resources) as needed in order to capture this leveling effort. Using constraints to lock in the levelized picture is not considered to be good practice since it interferes with the normal schedule calculations. 3.2.1.7 APPROVE THE SCHEDULE MODEL The project team reviews the results of this initial scheduling process to determine the acceptability of the schedule model. The review should consider: Analyzed project end date, uu Milestone completion dates, uu Critical paths (the longest path for the project or as constraint driven), uu Total float values and resource requirements (resource burn rates over the project life cycle), and uu Resource ramp-up rates compared to resource availability, etc. uu When alterations are required, the project team makes changes to the schedule logic, resource allocations and/ or durations, and then reanalyzes the schedule. The most common alteration required involves actions to reduce the overall duration of the schedule or adjustments to resource loading. The key techniques used to compress the schedule are crashing and fast tracking. Crashing. Crashing consists of adding resources to critical activities to shorten their durations (which may uu or may not increase cost) or spending money in other ways to reduce the length of activities (e.g., expediting parts). When adding resources to reduce activity duration, crashing only works for activities that are effort driven. Crashing should only be performed on activities on the critical path and then on only those activities that yield the most cost-effective result. Crashing typically increases project costs by some factor. Fast tracking. Fast tracking consists of changing the logic by overlapping critical activities rather than working uu them strictly in sequence. Fast tracking increases the risk of rework because activities are started before their initial predecessors are completed (see Section 6.5.2.6 of the PMBOK® Guide), and possibly contributes to an increased number of change orders on contracted work. 64 Section 3  Both of these actions may result in a trade-off of cost versus schedule dates. These iterations continue until an acceptable schedule model is developed—one that the key project stakeholders can agree is attainable and affordable. The formal process for the approval of the baseline schedule model is defined in the schedule management plan. 3.2.1.8 BASELINE THE SCHEDULE MODEL Once agreed upon and approved, the first instance of the schedule model is called the project baseline schedule model. This is the version that is developmentally complete and approved for capture or copied for future reference. This baseline becomes the benchmark against which project performance is measured. It is generally accepted practice that every project has a baseline schedule model in place before the project work begins. Once the baseline has been approved through formal procedures, reports are distributed in accordance with the project communications management plan, and changes to the baseline are monitored and controlled through the integrated change control process and configuration management. The baseline schedule model information allows for the determination of the original project critical path and identification of project schedule risks. See Section 3.3.5 for additional information on updating and revising baselines. 3.2.1.9 SCHEDULE LEVELS Schedules can be created and defined at various levels. The project team specifies the rules for the relative granularity of the level’s schedule activities in the overall schedule model. It should be noted that schedule levels can change depending on the approach (e.g., agile), practitioner, and the organizational scheduling requirements. Section 3.5 contains sample reports that may be produced for audiences of various schedule levels. Each level has a general purpose and content as follows: Level 0—Project summary. This report is a single line representing the entire project and is often used for uu comparing projects in a program or portfolio. Audiences for this schedule level include, but are not limited to, strategic partners (e.g., customers), senior executives, portfolio/program managers, and operations managers. Level 1—Executive summary. This report is a high-level schedule that includes key milestones and summary uu activities by major phase, stage, or project being executed. It is typically represented in bar chart format and may originate in a table of key elements or a graphic, but should ultimately be supported by a schedule that contains integrated work evolutions over the project life cycle. Level 1 schedules provide high-level information that assists in the decision-making process (go/no-go prioritization and criticality of projects). Audiences for this schedule level include, but are not limited to, customers, senior executives, and general managers. 65  Level 2—Management summary. This report is generally prepared to communicate the integration of work uu throughout the life cycle of a project. Level 2 schedules may reflect interfaces between key deliverables and project participants (e.g., contractors, consultants, architects, engineers, etc.), which are required to complete the identified deliverables. Typically presented in bar chart format, Level 2 schedules provide high- level information that assists in the project decision-making process (reprioritization and criticality of project deliverables) and is rolled up from more detailed schedule data. Audiences for this type of schedule include, but are not limited to, customers, general managers, sponsors, and program or project managers. Level 3—Publication schedule. This report is generally prepared to communicate the execution of the uu deliverables for each of the contracting parties. The schedule should reflect the interfaces between key workgroups, disciplines, or crafts involved in the execution of the project in a bar chart or CPM network format. Level 3 schedules assist the team in identifying critical paths and activities that could potentially affect the outcome of a stage or phase of work. Level 3 schedules allow for mitigation and course correction while allowing for complete reporting period reports. These reports include monthly reports, commodity curves, and histograms. Audiences for this type of layout include, but are not limited to, program or project managers, and supervisors. Level 4—Execution planning. This report is prepared to communicate the production of work evolutions uu at the deliverable level. The schedule level should reflect interfaces between key elements that drive the completion of activities. Typically presented in bar chart or CPM network format, Level 4 schedules usually provide enough detail to plan and coordinate multidiscipline/craft activities. The period covered by a Level 4 layout or report is usually 1 week to 1 month, supporting the milestones and durations represented in a Level 3 schedule. The basis of the Level 4 schedule is the layouts defined in a database of work packages, lists, or other detailed diagramming method where detailed steps, deliverables, and actions can be communicated over the life of the scheduled items. Audiences for this type of schedule include, but are not limited to, project managers and supervisors responsible for accomplishing the activities. Level 5—Detailed planning. This report is prepared to communicate task requirements for completing uu activities identified in a detailed schedule. A Level 5 schedule is usually considered a working schedule that reflects hourly, daily, or weekly work requirements. Depending on these requirements, Level 5 schedules are usually prepared 1 day or 1 week in advance. The period covered by a Level 5 layout is usually 1 day to 1 week, supporting the milestones and durations represented in the Level 3 or 4 schedules. Typically, Level 5 schedules are presented in an activity-listing format without time-scaled graphical representations of work to be accomplished. Level 5 schedules are used to plan and schedule use of resources (labor, equipment, and materials) for each task. Audiences for this type of schedule include, but are not limited to, supervisors and team members responsible for performing the work. 66 Section 3 3.3 SCHEDULE MODEL MAINTENANCE To ensure successful project execution, effective change control and disciplined update procedures are necessary. Almost every project inevitably experiences change. The key is to determine the manner in which the project approves and tracks changes as they occur throughout the project life cycle. Change can occur when work progresses more quickly or slowly than planned, when changes occur in other elements of the project (e.g., scope changes), and/or when the project team modifies its approach to the project work. Change can also be driven by external project issues that the team has no control over but should react to. Tracking progress begins after the project model is baselined, work begins, and regular monitoring and controlling processes are implemented. These processes are important to help identify problems as early as possible and to minimize their impact on the successful completion of the project. The main steps for tracking progress are as follows: Step 1. Save a baseline schedule model that contains the dates against which progress is compared. The uu current schedule model may be copied and approved as a baseline, or a more suitable schedule model may be approved as a baseline. Step 2. Report schedule progress as of a specific data date, also known as status date, update date, current uu date, time-now date, or as-of date. The data date is a point in time when the status of the project is recorded. The data date includes the date (including time of day) through which the project status and progress is determined and reported. Any data to the left of the data date (earlier) is considered historical information. Any data to the right of the data date (later) is the forecast of remaining work. The data date is also the point at which scheduling and performance measurement analysis are conducted. This reported progress, as a minimum, should include actual start and actual finish dates, remaining durations or work, and percent complete. Step 3. Assign the new data date and recalculate all the activity dates as the last step for progressing the uu schedule model. Steps 2 and 3 of the status/update process occur on a regular basis, which is determined during the project planning process. The steps involved in maintaining the schedule at each status/update are described in Sections 3.3.1 through 3.3.7. 3.3.1 COLLECT ACTUALS AND REMAINING WORK OR DURATION Collect the actual status of the project activities that should occur within the specific project time period being measured. The status information collected includes the actual start dates for all activities that have begun and the actual finish dates for all activities that have been completed as of the data date. When an activity is in progress, 67 determine the amount of actual work, earned value, actual duration accomplished, amount of remaining work, and duration of time needed to complete the remaining effort. Status can also include changes in duration or relationships for future activities assuming that these future changes are modified in accordance with the project change control process discussed in Section 3.3.8. Other information gathered at this time may include data on resource use and costs incurred, provided the data have been tracked at the activity level. Collect the data as of a specific data date (date/time). This data date is the end of the last day of the predetermined time interval, and it reflects the final day of the update cycle to ensure that all progress is reported through this date. 3.3.2 UPDATE THE SCHEDULE MODEL ACCORDING TO THE ACTUALS Incorporate the actual progress accomplished during the current update cycle. Incorporate the information gathered during the periodic update process into the schedule model, analyze any future work efforts, and then create the new schedule model forecast. Also at this time, input changes to future workflows due to scope changes and other issues that were approved by the change control process (see Section 3.3.8.) and that may have a significant impact on the new model forecast. Reschedule all incomplete activities based on the newly assigned remaining durations or work as of the data date. Take care when updating progress because many scheduling software programs allow actual dates to be applied to future work. Ensure quality control practices are in place to identify the entry of actual dates beyond the data date and the percent-complete values being reported that are not valid in relation to the dates. 3.3.3 COMPARE AND ADDRESS ANY DEVIATION Review and compare the newly updated schedule model outputs to the stored baseline. Identify and explain cost and schedule variances (e.g., activities not started or finished on time), quantifiable deviations, departures, or divergences away from a known baseline or expected value. Use variance thresholds and identify acceptable ranges defined in the schedule management plan to determine which activities and conditions require reporting and further analysis and action. This analysis should include discussions of ways to mitigate unfavorable performance trends and slippages. Discussions may also include processes that address change control. A commonly used date variance is the finish variance between early finish and baseline finish, which is usually expressed in units such as working days. Comparing the status of an activity against more than one target may be useful. For example: Current schedule vs. the original plan (the baseline) to see the slippage compared to the original plan. uu Current schedule vs. the last update period to see the changes since the last update for the purpose of uu identifying incremental slippages and trends. 68 Section 3 3.3.4 UPDATE THE SCHEDULE MODEL WITH APPROVED CHANGES Update the schedule model with any approved changes resulting from the overall change control process to ensure the schedule model represents 100% of the current known scope of the project and current project management plan. For additional detail on this process, see Section 3.3.8. The update and adjustment processes may need a number of iterations to maintain a schedule model that remains realistic and achievable. 3.3.5 UPDATE THE BASELINE SCHEDULE MODEL Review the baseline schedule model at regular, periodic intervals. Whenever the project is impacted by major scope changes, either (a) through the formal change control process or (b) by events (e.g., a major redesign or natural disaster) that significantly change the project schedule model, it may be necessary to perform a rebaseline. A rebaseline is needed when the project no longer aligns well with its predefined key performance indicators. It is essential to adequately explain why the rebaseline effort is needed. This typically includes an explanation of the project issues and impacts related to the change that is driving a rebaseline effort as documented in the change control process. A rebaseline effort requires the causes of the project changes to be identified and agreed to by the key project stakeholders. Once everyone agrees that this new schedule model accurately reflects the project path forward, capture it and use it to track performance from that point forward. Generally, this new rebaseline is named sequentially after the first baseline. Archive the original baseline and retain it for records and historical purposes (it is never deleted). It should also be noted that when a rebaseline is performed, performance on all completed activities is accepted and therefore, all remaining work is now shown on schedule at the time. This means that past performance statistics (good or bad) are zeroed out and started again from that point forward. 3.3.6 COMMUNICATE When the current schedule’s update cycle is completed, distribute the reports (see Figures 2-7 and 2-18 for schedule model presentations) in accordance with the schedule management plan and the project communications management plan. See Section 3.5 for more information and examples of typical reports and presentations that may be issued in accordance with the communications management plan associated with the schedule model. 69 3.3.7 MAINTAIN THE RECORDS Proper record management is part of configuration control. Detail the initial logic and major decision points of the project and the thought process that went into creating the baselined schedule flow logic. This helps to support actions taken and lessons learned. It is important to maintain records that explain all changes in activity durations or logic as alterations are being made in the schedule model. Activity log notes are often used for this purpose. These records provide valuable data if it becomes necessary to reconstruct what happened and why. Proper use of various components (such as activity logs/notes/comments) is important for documenting the context as to why a task was delayed or took longer than expected. This information can be used to (a) explain more completely why activities were constrained to a certain date or (b) record any other information that explains what occurred on this activity. Compare the baseline schedule to the last update of the schedule to document changes that have occurred over time and to determine the accuracy of the original baseline. This information can be useful for future projects of similar scope. Many of the good practices and elements described are also included in Section 4 within the details of each component contained in the schedule model components list. A complete understanding of the various components is needed in order to maximize the potential for their proper application and the development of a sound schedule. 3.3.8 CHANGE CONTROL Controlling project changes is one of the most important aspects in keeping the project on schedule and ensuring the schedule model remains relevant in terms of its ability to accurately forecast. For additional information and guidance, see the Practice Standard for Project Configuration Management. Project change can be driven by either (a) internal factors such as a scope change or (b) external factors over which the team has no control. In either situation, proper change control should be an integral part of the ongoing schedule model maintenance process. Use components such as activity logs/notes/comments for documenting the context, identifying why a task was delayed or took longer than expected, and documenting changes to the scheduling model logic. It is important for the scheduling analyst to be able to understand the backward and forward traceability of the schedule model from the baseline and determine how the accepted change maps back to any changes in the scheduling logic. Each schedule model instance captures any changes between the previous instances of the schedule including any existing activity logs/notes/comments when each instance is captured and archived. These logs/notes/comments provide an excellent source of history for anyone trying to determine what occurred during the project’s performance and why. 70 Section 3 3.4 SCHEDULE MODEL ANALYSIS Schedule analysis uses common tools and techniques throughout the project life cycle to identify deviations from the baseline schedule model. Schedule model analysis is the responsibility of the project team. The primary objective of the analysis is the early identification of threats and opportunities to the project objectives. To accomplish this analysis, the schedule model should be capable of forecasting the impacts/results of any changes, either external or internal, to the project’s desired outcomes. These impacts could be positive or negative but are reflected as changes in the project’s forecasted intermediate or final completion points. There are several tools and techniques available to perform schedule model analysis. The specific procedures and policies to be used for a project are described in the project’s schedule management plan. The most common items reviewed during schedule analysis are described in Sections 3.4.1 through 3.4.13. 3.4.1 CRITICAL PATH AND CRITICAL ACTIVITIES This section introduces and explains the difference between a project’s critical path and critical activities in a CPM approach. These are terms that are often misunderstood and used incorrectly when discussing the project. Establishing, identifying, and maintaining the project’s critical path is a key element in monitoring its performance. It is critical to forensic processes. Section 3.4.1.1 discusses the critical path in greater detail, and Section 3.4.1.2 focuses on critical activities. 3.4.1.1 CRITICAL PATH The project’s critical path is one of the key components to understand project performance and accurately monitor its forecasted movements based on inputs made over time to the project. The critical path (project critical path) is the sequence of activities that predicts or defines the longest path and shortest duration calculated for the project. It is the longest path through the project, starting at the earliest milestone and ending at project completion. The critical path determines the duration of the project. The critical path calculations consider activities and constraints to determine the longest path in the project. However, a critical path (specified critical path) can end, for example, on a schedule milestone that occurs at any point within the schedule model and that has a finish-no-later-than date constraint. (Note that constraints are used selectively in schedule models and only after fully understanding their impacts.) A critical path report may also be requested for a specific subproject, phase, craft/discipline, etc., which may or may not relate to the project critical path. 71  Sometimes it is necessary to elevate the importance of seemingly less significant work evolutions due to risk issues or other project-specific requirements. In these cases, the application of constraint(s) can alter the natural or unconstrained critical path of the project, thus causing unexpected changes to project duration and cost. A project can have multiple critical paths provided it has multiple critical sublevel milestones. A project with multiple critical paths has a higher level of risk since the failure to meet any of these might result in failure to complete all project milestones. Regardless of how paths are defined or how many exist, the path from a starting point within the project to that specific ending point can always be determined and monitored. Once a path is defined, it should be reviewed and analyzed after each update to understand and document any changes. Activities that fall on the critical path are critical path activities. 3.4.1.2 CRITICAL ACTIVITIES It is important to distinguish between critical path activities and critical activities: Critical path activities. Those activities contained in the critical path(s). uu Critical activities. Those activities vital to the success of a project, even when they are not on the critical uu path or critical chain. Critical activities are normally high risk in terms of scope, schedule, resources, safety, environment, and/or cost and can cause a delay in the project end date and an increased likelihood of project failure. All activities contained within any critical path are critical path activities and are also considered critical activities. However, critical activities can also be outside the critical path. 3.4.2 TOTAL FLOAT AND FREE FLOAT Free float (FF) represents the amount of time an activity’s early finish date may be delayed without affecting any successor activity’s early start date. FF is a property of an individual activity. Total float (TF) represents the amount of time an activity’s early start date or early finish date may be delayed without impacting the project end point. The TF value is shared among all of the activities in a specific path to either a point where paths merge or to the project end point. When an activity in a path uses some of the available TF, then that amount of TF is also used up for the rest of the activities to the merge point or the project end point. For example, 72 Section 3 in Figure 3-6, each activity in this diagram displays the TF and FF after every activity bar. The TF is listed first and the FF second. For example: Activity A reflects (0, 0), which indicates that both the TF and FF are zero. This means that this activity is on the uu critical path. Any slippage in Activity A’s performance will cause an impact not only to its successor, but to the project end point or associated milestone as well. Activity B reflects (10, 10), which indicates that TF is 10 days and FF is 10 days. This means that Activity B’s uu performance could slip 10 days before an impact to its successor is realized. Activity E reflects (10, 0), which indicates that TF is 10 days and FF is 0 days. This means that any slippage uu in Activity E’s performance will cause an impact to the successor activity’s start date, but it can slip 10 days before an impact to the successor’s late finish date is realized. Day 1 10 Day Free Float A 0,0 15 Day 15 B 10,10 Day 16 5 C 0,0 10 D 0,0 Free Float 15 Total Float E 10,0 2 Duration F 10,10 3 G 0,0 10 Figure 3-6. Total Float and Free Float Total float and free float should be monitored and reviewed after each project update to determine whether they have changed since the previous update. Changes to total float indicate a threat to achieving project completion or specific milestones. uu Changes to free float indicate that a lack of progress may affect immediate successors causing them to start uu or finish later than expected. 73  Total float and free float may also be impacted by external dependencies and other hard constraint dates listed in the schedule model. These external dependencies should be explained in activity logs/notes/comments or linked to external milestones whenever they are applied so that everyone can understand what changes have been made and why. Monitoring and managing these two vital components are critical to completing the project on time and meeting milestones as planned. Decreases to total float and free float are strong indicators of the places where recovery plans may need to be developed. 3.4.3 ESTIMATION OF ACTIVITY DURATIONS The data from available historical information can be used to develop the duration estimates. When there is a great deal of uncertainty in activity duration, a commonly used estimating technique is the three-point estimate. These three points correspond to activity durations defined as optimistic, most likely, and pessimistic durations. Additionally, the risk register may also be used to support estimating the uncertainty in activity durations. In order to quantify uncertainty about the overall project duration, starting from the three-point estimate of every activity, PERT (program evaluation and review technique), which uses an approximation of beta distribution, is most commonly used. PERT activity duration is calculated as [optimistic duration + (4 × most likely duration) + pessimistic duration]/6 in a weighted average distribution and [optimistic duration + most likely duration + pessimistic duration]/3 in a triangular distribution. PERT focuses on activity duration. It allows for random activity duration and weights the activity-estimated duration on the range of duration estimates provided by stakeholders. In Figure 3-7, starting with a precedence diagram, PERT permits activity duration estimates to be determined, allowing for the uncertainty contained in the duration estimating process. Three duration estimates are required for each activity: Optimistic duration. The minimum activity duration under the most favorable conditions. uu Most likely duration. The activity duration that will occur most often. uu Pessimistic duration. The activity duration under the least favorable conditions. uu The durations determined by the referenced equation are used as activity-estimated durations. Generally, durations are established at a specific statistical level of significance (for example, 95% confidence level). The weighting in the equation is a manual approximation of the statistical distribution. With more sophisticated calculations (e.g., using computers), an implementation of statistical or multiple simulations of PERT is possible, which approaches the methods and results of Monte Carlo analysis (see Section 3.4.11). The degree to which the distribution is skewed is suggested by the shape of the curve representing the three estimated durations (such as beta, uniform, or triangular). The distribution relating the three duration estimates (or cost estimates) should be selected to best fit the supporting data for similar activities. 74 Section 3  Higher Most Likely Probability of Occurrence PERT Weighted Average = Optimistic + 4 x Most Likely + Pessimistic 6 Beta Distribution Pessimistic Optimistic Lower Shorter Longer Possible Durations Figure 3-7. Example of Precedence Diagram with PERT Activity Duration Estimates The standard deviation of an activity is reflected in Figure 3-8: Degree of variation from the average (mean), uu Indicates the standard error in the estimate and provides an idea of its accuracy, and uu The larger the standard deviation (spread between the optimistic and pessimistic estimates), the larger the uu risk in the estimate: nn± 1 standard deviation = 68.26%, nn± 2 standard deviations = 95.46%, nn± 3 standard deviations = 99.73%, and nn± 6 standard deviations = 99.999998%. Additional information on estimating techniques is provided in the Practice Standard for Project Estimating. 75  Areas Under the Normal Curve 68.26% 95.44% 99.73% 99.99% Mean + Six Sigma Figure 3-8. Example of Standard Deviation of an Activity 3.4.4 DATE CONSTRAINTS Date constraints restrict a project’s natural flow and logic and its ability to react to changes (both planned and unplanned), disregard the effects of risk, and limit the usefulness of schedule risk analysis. This is sometimes referred to as schedule model flexibility—the ability to absorb changes and still maintain the project end dates and/or major milestones. Date constraints should be avoided whenever possible. Date constraints should only be used in limited application after careful consideration and understanding of how they will impact the project over its entire life cycle. Finally, they should be used only when compatible with a project’s expected course of development. The schedule management plan may provide direction on the use of date constraints. 76 Section 3  One use for a date constraint is to establish a not-earlier-than or a not-later-than date for activities that do not have an effective predecessor or successor in the schedule. An example of this is the delivery of a piece of equipment by a vendor when it is not practical or desirable to include the vendor’s activities in the schedule model. Even in this example, care should be taken so as not to inject a break in the critical path. Specific constraints cause the schedule model to react differently. For example, an as-soon-as-possible type constraint provides complete flexibility without an imposed constraint. However, a start-no-earlier-than type of constraint provides less flexibility since it impacts early start date calculations in some scenarios. Finally, a must- start-on constraint removes all flexibility and forces a date, which makes it very difficult to identify the impacts of the normal changes experienced during a project life cycle. Because constraints ultimately limit scheduling flexibility, they should be used only when schedule logic cannot correctly address the situation. When a date constraint becomes necessary, more flexible constraints are preferred. Finally, whenever a constraint is incorporated into a schedule model, a note explaining the type of constraint added, its intended purpose, and the reason for its use should also be included in the schedule documentation (e.g., in the activity note/ comment/log). This provides a record for use at a later time to explain the rationale that was applied earlier in the project. 3.4.5 OPEN-ENDED ACTIVITIES An open-ended activity is an activity lacking either a predecessor or a successor or both. Open-ended activities obscure the logical relationships between project activities, create a false appearance of float in a project, and reduce the apparent impact of risk during a schedule analysis. In such cases, it brings into question the logical relationship of what is required to start the activity or what this activity accomplishes so that subsequent work evolutions can occur. This lack of logic damages the validity of the entire schedule model. The only open-ended activities in a project should be the start and finish milestones at the beginning and end of the project. Unless linked to other projects, a project’s start and finish milestones always contain open ends. Open ends occur either through omission (the user fails to assign a relationship) or by the result of progress being reported on the project or relationships that do not close a path (see Figure 3-5), sometimes referred to as virtual open ends. Figure 3-9 shows two examples of open ends caused by omission, highlighted by the bold arrows. In this example, Activity C does not have a predecessor, and Activity F does not have a successor. In both cases, the schedule example was created, and the user did not adhere to the requirements concerning relationships (i.e., each activity should have an F-S or S-S predecessor and an F-S or F-F successor). Without these types of logical relationships, the activities are called dangling or open. Uncertainty in the durations of dangling or open activities are not necessarily transmitted to the rest of the schedule model. When progress is reported on the project, the result may cause activities to behave as though they were open ended.