Scheduling Practice Standard PDF

PRACTICE STANDARD FOR SCHEDULING I Library of Congress Cataloging-in-Publication Data Names: Project Management Institute. Title: Practice standard for scheduling / Project Management Institute. Description: Third edition. | Newtown Square : Project Management Institute, 201...

PRACTICE STANDARD FOR SCHEDULING I Library of Congress Cataloging-in-Publication Data Names: Project Management Institute. Title: Practice standard for scheduling / Project Management Institute. Description: Third edition. | Newtown Square : Project Management Institute, 2019. | Revised edition of Practice standard for scheduling, c2011. | Includes bibliographical references and index. Identifiers: LCCN 2019009443 (print) | LCCN 2019010321 (ebook) | ISBN 9781628255621 (ePub) | ISBN 9781628255638 (kindle) | ISBN 9781628255645 (Web PDF) | ISBN 9781628255614 (paperback) Subjects: LCSH: Project management--Standards. | BISAC: BUSINESS & ECONOMICS / Project Management. Classification: LCC HD69.P75 (ebook) | LCC HD69.P75 P653 2019 (print) | DDC 658.4/04--dc23 LC record available at https://lccn.loc.gov/2019009443 ISBN: 978-1-62825-561-4 Published by: Project Management Institute, Inc. 14 Campus Boulevard Newtown Square, Pennsylvania 19073-3299 USA Phone: +610-356-4600 Fax: +610-356-4647 Email: [email protected] Internet: www.PMI.org ©2019 Project Management Institute, Inc. All rights reserved. Our copyright content is protected by U.S. intellectual property law that is recognized by most countries. To republish or reproduce our content, you must obtain our permission. Please go to http://www.pmi.org/permissions for details. To place a Trade Order or for pricing information, please contact Independent Publishers Group: Independent Publishers Group Order Department 814 North Franklin Street Chicago, IL 60610 USA Phone: +1 800-888-4741 Fax: +1 312-337-5985 Email: [email protected] (For orders only) For all other inquiries, please contact the PMI Book Service Center. PMI Book Service Center P.O. Box 932683, Atlanta, GA 31193-2683 USA Phone: 1-866-276-4764 (within the U.S. or Canada) or +1-770-280-4129 (globally) Fax: +1-770-280-4113 Email: [email protected] Printed in the United States of America. No part of this work may be reproduced or transmitted in any form or by any means, electronic, manual, photocopying, recording, or by any information storage and retrieval system, without prior written permission of the publisher. The paper used in this book complies with the Permanent Paper Standard issued by the National Information Standards Organization (Z39.48—1984). PMI, the PMI logo, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION and the slogan MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS. are all marks of Project Management Institute, Inc. For a comprehensive list of PMI trademarks, contact the PMI Legal Department. All other trademarks, service marks, trade names, trade dress, product names and logos appearing herein are the property of their respective owners. Any rights not expressly granted herein are reserved. 10 9 8 7 6 5 4 3 2 1  N OT IC E The Project Management Institute, Inc. (PMI) standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While PMI administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications. PMI disclaims liability for any personal injury, property or other damages of any nature whatsoever, whether special, indirect, consequential or compensatory, directly or indirectly resulting from the publication, use of application, or reliance on this document. PMI disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. PMI does not undertake to guarantee the performance of any individual manufacturer or seller’s products or services by virtue of this standard or guide. In publishing and making this document available, PMI is not undertaking to render professional or other services for or on behalf of any person or entity, nor is PMI undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication. PMI has no power, nor does it undertake to police or enforce compliance with the contents of this document. PMI does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to PMI and is solely the responsibility of the certifier or maker of the statement. III  TABLE O F CO NTENTS 1. INTRODUCTION.........................................................................................................................1 1.1 Project Scheduling.........................................................................................................2 1.2 Why Scheduling?............................................................................................................3 1.3 Overview.........................................................................................................................5 1.4 Purpose...........................................................................................................................7 1.5 Applicability....................................................................................................................7 2. SCHEDULE MODEL PRINCIPLES AND CONCEPTS.....................................................................9 2.1 Overview.........................................................................................................................9 2.2 Project Life Cycles and Scheduling Approaches.........................................................10 2.2.1 Critical Path Approach.....................................................................................14 2.2.2 Critical Chain....................................................................................................18 2.2.3 Adaptive Life Cycle...........................................................................................21 2.2.4 Rolling Wave Planning.....................................................................................23 2.2.5 Other Approaches and Emerging Trends.........................................................25 2.3 Scheduling Tool............................................................................................................28 2.4 Schedule Model............................................................................................................29 2.5 Schedule Model Instances and Presentations............................................................30 2.6 Agile..............................................................................................................................31 2.6.1 Tracking and Presentation...............................................................................38 V  3. SCHEDULE MODEL GOOD PRACTICES OVERVIEW..................................................................45 3.1 Schedule Management.................................................................................................45 3.1.1 Schedule Data Management Plan...................................................................46 3.1.2 Schedule Management Plan............................................................................47 3.1.2.1 Scheduling Approach........................................................................48 3.1.2.2 Scheduling Tool.................................................................................48 3.1.2.3 Schedule Model Creation Plan..........................................................48 3.1.2.4 Schedule Model ID............................................................................49 3.1.2.5 Schedule Model Instance.................................................................49 3.1.2.6 Calendars and Work Periods............................................................49 3.1.2.7 Project Update Cycle and Activity Granularity.................................50 3.1.2.8 Milestone and Activity Coding Structure.........................................51 3.1.2.9 Resource Planning............................................................................52 3.1.2.10 Key Performance Indicators...........................................................52 3.1.2.11 Master Schedule Model..................................................................53 3.1.2.12 Change Control................................................................................53 3.2 Schedule Model Creation.............................................................................................53 3.2.1 Develop Schedule Model Baseline...................................................................55 3.2.1.1 Define Milestones.............................................................................55 3.2.1.2 Define the Project’s Activities..........................................................55 3.2.1.3 Sequence Activities...........................................................................59 3.2.1.4 Determine Resources for Each Activity............................................61 3.2.1.5 Determine the Duration for Each Activity........................................62 3.2.1.6 Analyze the Schedule Output............................................................62 3.2.1.7 Approve the Schedule Model............................................................64 3.2.1.8 Baseline the Schedule Model...........................................................65 3.2.1.9 Schedule Levels................................................................................65 3.3 Schedule Model Maintenance......................................................................................67 3.3.1 Collect Actuals and Remaining Work or Duration..........................................67 3.3.2 Update the Schedule Model According to the Actuals...................................68 VI Table of Contents  3.3.3 Compare and Address Any Deviation..............................................................68 3.3.4 Update the Schedule Model with Approved Changes.....................................69 3.3.5 Update the Baseline Schedule Model..............................................................69 3.3.6 Communicate...................................................................................................69 3.3.7 Maintain the Records.......................................................................................70 3.3.8 Change Control.................................................................................................70 3.4 Schedule Model Analysis.............................................................................................71 3.4.1 Critical Path and Critical Activities..................................................................71 3.4.1.1 Critical Path.......................................................................................71 3.4.1.2 Critical Activities...............................................................................72 3.4.2 Total Float and Free Float.................................................................................72 3.4.3 Estimation of Activity Durations......................................................................74 3.4.4 Date Constraints...............................................................................................76 3.4.5 Open-Ended Activities......................................................................................77 3.4.6 Out of Sequence (OOS) Logic...........................................................................79 3.4.7 Leads and Lags................................................................................................81 3.4.8 Start-to-Finish Relationship............................................................................82 3.4.9 Links to/from Summary Activities...................................................................83 3.4.10 Schedule Resource Analysis..........................................................................83 3.4.11 Schedule Risk Assessment............................................................................83 3.4.12 Earned Schedule............................................................................................85 3.5 Communication and Reporting....................................................................................88 4. SCHEDULING COMPONENTS...................................................................................................93 4.1 How to Use the Components List.................................................................................94 4.1.1 Component Name.............................................................................................94 4.1.2 Required, Conditional, or Optional Use............................................................94 4.1.3 Manual or Calculated.......................................................................................94 4.1.4 Data Format......................................................................................................95 4.1.5 Behavior............................................................................................................95 4.1.6 Good Practices.................................................................................................95 VII  4.1.7 Conditional Note/Associated Component.......................................................95 4.1.8 Definition..........................................................................................................95 4.2 List of Components by Category..................................................................................96 4.3 Detailed Components List............................................................................................98 5. CONFORMANCE INDEX.........................................................................................................137 5.1 Conformance Overview..............................................................................................137 5.1.1 Categories of Components.............................................................................138 5.1.2 Use of Schedule Components........................................................................138 5.1.3 Conformance Assessment.............................................................................139 5.2 Conformance Assessment Process...........................................................................140 APPENDIX X1 THIRD EDITION CHANGES........................................................................................................143 APPENDIX X2 CONTRIBUTORS AND REVIEWERS OF THE PRACTICE STANDARD FOR SCHEDULING – THIRD EDITION...............................................................................................145 X2.1 Practice Standard for Scheduling – Third Edition Core Committee......................145 X2.2 Reviewers.................................................................................................................146 X2.2.1 SME Review..................................................................................................146 X2.2.2 Final Exposure Draft Review.......................................................................146 X2.3 PMI Standards Program Member Advisory Group (MAG).......................................148 X2.4 Consensus Body Review..........................................................................................148 X2.5 Production Staff.......................................................................................................149 APPENDIX X3 CONFORMANCE ASSESSMENT SCORING TABLE.....................................................................151 APPENDIX X4 CONFORMANCE ASSESSMENT WORKSHEETS.........................................................................159 VIII Table of Contents APPENDIX X5 FORENSIC SCHEDULE ANALYSIS..............................................................................................165 REFERENCES............................................................................................................................169 GLOSSARY................................................................................................................................171 INDEX.......................................................................................................................................195 IX  LIST OF TA BL ES AND F I GU RES Figure 1-1. Schedule Model Development and Use....................................................................6 Figure 2-1. Life Cycle Continuum..............................................................................................10 Figure 2-2. Example of Predictive Flow Diagram.....................................................................11 Figure 2-3. Iterative Flow Diagram...........................................................................................11 Figure 2-4. A Life Cycle of Varying Size Increments................................................................11 Figure 2-5. Adaptive Flow Diagram..........................................................................................12 Figure 2-6. Combined Predictive and Adaptive Approaches Used..........................................13 Figure 2-7. Schedule Model Flow..............................................................................................15 Figure 2-8. F low Diagram for the Schedule Model Mapped to PMBOK ® Guide Knowledge Area Processes..........................................................16 Figure 2-9. Example of CPM Diagram.......................................................................................18 Figure 2-10. Feeding Buffers.....................................................................................................20 Figure 2-11. Project Buffers......................................................................................................21 Figure 2-12. Diagram of Uncertainty........................................................................................22 Figure 2-13. Examples of Agile Approaches.............................................................................23 Figure 2-14. E xample of Rolling Wave Planning—Planning Package 1 Decomposed.......................................................................................24 Figure 2-15. E xample of Rolling Wave Planning—Planning Package 2 Decomposed.......................................................................................24 Figure 2-16. Location-Based Schedule Example.....................................................................25 XI Figure 2-17. Schedule Model Instances and Presentations....................................................30 Figure 2-18. Example of Multiple Iterations or Sprints............................................................32 Figure 2-19. Typical Adaptive Life Cycle...................................................................................33 Figure 2-20. Results of Sprint (Iteration) Planning Meeting....................................................34 Figure 2-21. Scrum Board Displaying Sprint (Iteration) 1.......................................................35 Figure 2-22. Kanban Board.......................................................................................................36 Figure 2-23. Example of Functional Dependencies between Requirements...........................37 Figure 2-24. Typical Burndown Chart with Planned Work.......................................................38 Figure 2-25. Burndown Chart with Remaining Work...............................................................39 Figure 2-26. Burndown Chart with Progress Smoothed-Over Iteration..................................40 Figure 2-27. Burndown Chart—Commitment Not Met.............................................................40 Figure 2-28. Burndown Chart with Remaining Work...............................................................41 Figure 2-29. Burndown Chart with Commitments Met............................................................41 Figure 2-30. Example of a Burnup Chart..................................................................................42 Figure 2-31. R  elationships between Product Vision, Release Planning, and Iteration Planning..........................................................................................43 Figure 3-1. Summary Activities................................................................................................57 Figure 3-2. LOE Activity.............................................................................................................58 Figure 3-3. Hammock Activity...................................................................................................58 Figure 3-4. Illustrations of Relationship Types in CPM Methodology......................................60 Figure 3-5. Required Activity Relationships.............................................................................61 Figure 3-6. Total Float and Free Float.......................................................................................73 Figure 3-7. E xample of Precedence Diagram with PERT Activity Duration Estimates.................................................................................................75 XII List of Tables and Figures Figure 3-8. Example of Standard Deviation of an Activity.......................................................76 Figure 3-9. Example of Open Ends by Omission.......................................................................78 Figure 3-10. Virtual Open Example...........................................................................................79 Figure 3-11. Out of Sequence Logic Example...........................................................................80 Figure 3-12. Progress Override vs. Retained Logic..................................................................81 Figure 3-13. Leads vs. Lags......................................................................................................82 Figure 3-14. Resource Leveling................................................................................................84 Figure 3-15. Example Duration Probability Distribution for a Single Activity.........................85 Figure 3-16. Relationship between ES, PV, and EV...................................................................86 Figure 3-17. Earned Schedule Reporting..................................................................................87 Figure 3-18. Sample Project Schedule Presentations..............................................................91 Figure X4-1. Base Worksheet..................................................................................................160 Figure X4-2. Resource-Required Example Worksheet...........................................................161 Figure X4-3. Resource-, EVM-, and Risk-Required Example Worksheet...............................162 Figure X4-4. Resource- and Risk-Required Example Worksheet..........................................163 Figure X4-5. Non-Scored Example Worksheet.......................................................................164 Table 3-1. Earned Schedule Formulas......................................................................................88 Table 3-2. Levels of Schedule Model Instance Presentations.................................................90 Table 4-1. List of Components by Category..............................................................................97 Table 5-1. Number of Components by Category.....................................................................140 Table X3-1. Sample Conformance Assessment Scoring Table..............................................152 XIII 1 IN TRODUCTI ON The Practice Standard for Scheduling provides the framework to create, manage, and maintain schedules in a project environment. This practice standard contains five main sections. Each section provides additional information on the content and terminology used in this practice standard: Section 1—Introduction. This section provides an introduction to scheduling and its benefits, as well as an overview of the development and use of schedule models. Section 2—Schedule Model Principles and Concepts. This section provides guidance and information on the principles and concepts associated with schedule model creation and use within predictive, adaptive, or hybrid environments. Section 3—Schedule Model Good Practices Overview. This section provides guidance and information on generally accepted good practices associated with the planning, developing, maintaining, communicating, and reporting processes of an effective critical path method (CPM) schedule model approach. Section 4—Scheduling Components. This section provides a detailed catalog of the potential components of a CPM scheduling tool. Section 5—Conformance Index. This section provides an overview of the conformance index process. It provides a method for assessing how well a CPM schedule model incorporates the components, guidelines, definitions, behaviors, and good practices outlined in this practice standard. Appendixes contained in this practice standard are: Appendix X1—Third Edition Changes Appendix X2—Contributors and Reviewers of the Practice Standard for Scheduling – Third Edition Appendix X3—Conformance Assessment Scoring Table Appendix X4—Conformance Assessment Worksheets Appendix X5—Forensic Schedule Analysis 1  This practice standard includes adaptive approaches such as agile (see Sections 2.2.3 and 2.6). However, the majority of the content of this practice standard, except where indicated, describes a traditional (i.e., predictive) approach to scheduling using CPM. Additional information on agile may be found in the Agile Practice Guide.1 Section 1 provides an overview of the content of this practice standard and is divided as follows: 1.1 Project Scheduling 1.2 Why Scheduling? 1.3 Overview 1.4 Purpose 1.5 Applicability 1.1 PROJECT SCHEDULING Project scheduling ensures the development of effective schedule models through the application of skills, tools, techniques, and intuition acquired through knowledge, formal and informal training, and experience. A schedule model rationally organizes and integrates various project components (e.g., activities, resources, and logical relationships) to optimize the information available to the project management team and facilitate the likelihood of a successful project completion within the approved schedule baseline. Key schedule model terms are defined as follows: Milestone. The PMI Lexicon of Project Management Terms defines a milestone as: A significant point or uu event in a portfolio, program, or project. For the purposes of this standard, a milestone is a significant point or event in a project defined with a duration of zero time periods. Activity. The Lexicon defines an activity as: A distinct, scheduled portion of work performed during the uu course of a project. For the purposes of this standard, an activity is a unique and distinct scheduled portion of work with a duration greater than zero time periods, to be performed during the course of a project. Resource. A skilled human resource (specific disciplines either individually or in crews or teams), equipment, uu services, supplies, commodities, materials, budgets, or funds required to accomplish the defined work. Logical relationship. A dependency between two activities or between an activity and a milestone. uu 1 The numbers in bracket refer to the list of references at the end of this practice standard. 2 Section 1  The terms scheduling tool, schedule model, schedule model instance, and schedule presentation are defined in the glossary of this practice standard and described as follows: Scheduling tool. A tool that provides schedule component names, definitions, structural relationships, formats, uu and algorithms for schedule calculation that support the application of a scheduling method. Schedule model. A representation of the plan for executing the project’s activities including durations, uu dependencies, and other planning information, which is used to produce a project schedule along with other scheduling artifacts. The schedule model is dynamic and is developed and maintained by the project team with input from key stakeholders. It applies a selected scheduling approach to a scheduling tool using project-specific data. The schedule model can be processed by a scheduling tool to produce various schedule model instances. Schedule model instance. A version of the schedule model that has been processed by a scheduling tool uu based on inputs and adjustments made to the project-specific data within the scheduling tool. The scheduler saves the schedule model instances as project records and for reference, including data date, version (based on a completed update cycle), target schedule models, and the baseline schedule model. The instances can produce various schedule presentations. When used together, the instances support report generation and analysis, such as variance and risk analysis. Schedule presentation. An output published from a schedule model instance used to communicate project- uu specific data for reporting, analysis, and decision making. Presentations may include bar charts, critical paths, near critical paths, resource profiles, activity assignments, baselines, record of accomplishments, risks/issues, etc. Presentations can also provide time-based forecasts and identify performance deviations throughout the project’s life cycle. 1.2 WHY SCHEDULING? Projects are complex temporary endeavors; however, a detailed schedule model that contains logically related work allows the project to be simplified into manageable phases or groupings of activities. These phases or groupings allow management to optimize the trade-offs between scope, cost, and schedule. Project performance is reported and monitored when progress against these activities and milestones is recorded within the schedule model. As progress is recorded on a project, the remaining effort, as defined in the approved baseline, requires reassessment. The execution of a project often proceeds differently than the initial plan and baseline. In a typical project environment, it becomes necessary to refine the schedule model because of (a) incomplete or inadequate planning, (b) further decomposition of the project scope, (c) significant project changes, (d) organizational changes, or (e) environmental changes. This iterative evolution is required to predict, recognize, and address those evolving factors and issues that could potentially affect project performance. 3  The key to project success is applying knowledge and experience to create a credible project management plan. The project management plan optimally balances cost, resources, scope, and time-based performance with the project team’s commitment to execute the project in accordance with the plan. Scheduling is one of the basic requirements of project planning and analysis. The schedule model, once completed, becomes an effective planning tool for (a) engaging communications that focus on optimizing future actions, (b) assisting proactive collaboration, and (c) creating a project performance management system. Scheduling provides the detail that represents who, how, where, and when the assigned project resources will deliver the products, services, and results defined in the project scope. The detailed plan serves as a tool for managing the activities to be performed, communications, and stakeholder expectations. It also serves as a basis for performance reporting. The project manager together with the project team use the project schedule (baseline and actual progress) as a primary tool for planning, executing, and controlling all project-based evolutions. The schedule model is used to track, forecast, and monitor project performance throughout its life cycle. The dynamic nature of a project’s execution is best served by a tool that allows for modeling of the project, the project’s internal and external dependencies, and analysis due to the impact of progress and risk events. The model concept looks for the schedule model to react to inputs (progress updates, progressive elaboration, changes to scope definition (WBS), etc.) as the project team expects the project to perform based on those inputs. The following are examples of how the schedule model supports the project by allowing for: Time phasing of required activities; uu Constraints that limit the options for managing a portfolio, program, project, or process; uu Resource planning; uu Mobilization of planned resources in a most efficient manner; uu Coordination of events within the project and among other projects; uu Visual representation of these schedule issues to the stakeholders; uu Early detection of risks, problems, issues, or opportunities; uu Implementation of actions to achieve the project objectives as planned; uu What-if and variance analysis; uu Cost planning; and uu Forecasting of estimate at complete and to complete. uu 4 Section 1 1.3 OVERVIEW This practice standard describes schedule model components (see Section 4) and generally recognized good practices for scheduling processes. Generally recognized means that the knowledge and practices described are applicable to most projects most of the time. Additionally, there is consensus about the value and usefulness of knowledge and practices. Good practice means that there is general agreement that the application of these skills, tools, and techniques can enhance the probability of success over a wide range of projects. Good practice does not mean the knowledge described should always be applied uniformly to all projects—it means the project team is responsible for determining what is appropriate for any given project. The proper use of the components and their practices results in a schedule model usable for planning, executing, monitoring, and closing, in addition to the delivery of the project scope to stakeholders. Although additional schedule approaches and life cycles are included, this practice standard describes a traditional (i.e., predictive) approach to scheduling using the CPM approach. Schedule model creation begins with selecting a scheduling approach and a scheduling tool that support the desired scheduling approach. Next, starting with the WBS, project-specific data are incorporated within the scheduling tool to create a unique schedule model. Schedule model instances are snapshots captured from the schedule model. Schedulers produce various presentations from these schedule model instances based on the project-specific data. See Figure 1-1 to better understand the interrelationships of the schedule model creation concepts and terminology. This process results in a schedule model for project execution, monitoring, and control that responds predictably to progress and changes. The model is also used for engaging communications toward proactive optimization of future actions. The scheduler should regularly update the schedule model to reflect progress and changes such as scope, durations, milestones, allocated resources, productivity rates, means of accomplishment, variances, risk evaluations, and scheduling logic. This practice standard also provides an assessment that can be used to determine how well the schedule model conforms to this practice standard. A conformance index (see Section 5 of this practice standard) is developed by determining which components are used and how they are used within the schedule model. In order to obtain an acceptable conformance assessment, a schedule model, at a minimum, should contain all of the required components described in Section 4 and Appendix X3. The selection of an appropriate scheduling software tool provides access to the required components necessary to develop the schedule model. The use of this practice standard, along with experience, skill, and organizational maturity, provides the appropriate guidance for application of the components. The inclusion of a component in this practice standard does not necessarily bear any relation to the issues of project size or complexity. This practice standard assumes that all schedule models need to have the required components, basic behaviors, and good practices. Project size and complexity only result in changes in scale and repetition of the required components. A Guide to the Project Management Body of Knowledge (PMBOK ® Guide) provides processes to address the factors regarding project size and complexity. In addition, the definition of generally recognized also 5  Project-Specific Data (e.g., WBS, activities, resources, durations, dependencies, constraints, calendars, milestones, lags, etc.) Scheduling Scheduling Schedule Approach Tool Model Project Information For example, CPM, agile Schedule Model Instances Examples of Presentations Network Diagram To Do Doing Done 1 5 11 5 4 1 11 4 2 13 8 2 13 13 21 14 13 Bar Chart 18 18 20 Activity List Kanban Board Figure 1-1. Schedule Model Development and Use 6 Section 1 assumes that there are no significant differences for the use of the required components regarding the scheduling practices of various industries. As practices evolve and develop within the project management community after the publication of this practice standard, the definition of generally recognized will also evolve. More components may be added to the core set, and good practices should become less subjective. 1.4 PURPOSE This practice standard provides standards and guidelines using effective schedule management for a project by providing knowledge on the creation and maintenance of schedule models. This practice standard expands on the information contained in Section 6 of the PMBOK ® Guide. This practice standard establishes a core set of required components to be used in order to establish a schedule model that meets a minimum acceptable level of maturity (see Section 3), and a method to assess a schedule model for conformance to this standard. The goal of this practice standard is to create schedule models that are of value for the projects they represent. This practice standard is not intended to provide a comprehensive guide on how to develop a schedule model. For comprehensive instructions on developing a schedule model, refer to courses and textbooks on the subject. 1.5 APPLICABILITY This practice standard applies to project management practitioners who are knowledgeable about the fundamentals of project scheduling as described in this practice standard. For the purposes of this practice standard, these practitioners will be known as schedulers. This practice standard focuses on approaches used in a predictive life cycle (specifically CPM), but includes considerations as they relate to approaches used in adaptive life cycles (specifically agile). CPM is the most common approach for project scheduling, but the prevalence of adaptive life cycles such as agile has increased significantly since the previous edition of the practice standard, especially in software development. Approaches used in an adaptive life cycle define a plan, but acknowledge that once work starts, the priorities may change, and the plan needs to reflect this new information. These approaches also work well for projects experiencing high levels of uncertainty and unpredictability in competitive global markets. Finally, this practice standard includes expanded consideration for some of the emerging practices for project scheduling approaches, such as location-based scheduling. 7  It is the premise of this practice standard that: (a) the reader has a basic working knowledge of the Project Management Process Groups and Knowledge Areas defined in the PMBOK ® Guide, (b) the project has a work breakdown structure (WBS) that conforms to the processes defined in the Practice Standard for Work Breakdown Structures , and (c) sufficient planning has been done. As schedule development progresses, related practice standards such as the Agile Practice Guide , The Standard for Earned Value Management , and The Standard for Risk Management in Portfolios, Programs, and Projects may be applied. This practice standard is applicable to individual projects only—not to portfolios or programs. However, because portfolios and programs are collections of individual projects, any individual schedule model within those structures should make use of and be evaluated according to this practice standard. An organization that embraces the principles and good practices outlined in this practice standard and applies them globally across the organization ensures that all schedule models developed in support of the organization’s strategic value proposition are done in a consistent manner throughout the organization. 8 Section 1 2 SC HE D U L E MODEL PRINCI P LES AND C ONC EP TS This section provides guidance and information on the principles and concepts associated with schedule model creation and use within predictive or adaptive environments. This section covers the following topics: 2.1 Overview 2.2 Project Life Cycles and Scheduling Approaches 2.3 Scheduling Tool 2.4 Schedule Model 2.5 Schedule Model Instances and Presentations 2.6 Agile Sections 2.2 through 2.5 link the processes described in this section to the good practices described in Section 3 and the scheduling components defined in Section 4. 2.1 OVERVIEW The schedule management plan identifies the scheduling approach and the scheduling tool used to create the schedule model. Schedule model creation incorporates the defined processes associated with the project scheduling effort during planning. A process to create a schedule model that meets the needs of the project and its stakeholders begins during project planning. Section 2.2.1 provides an overview of schedule model creation. Schedule model principles and concepts with considerations related to adaptive and other emerging approaches appear in Sections 2.2.3 and 2.2.4. 9 2.2 PROJECT LIFE CYCLES AND SCHEDULING APPROACHES No single type of life cycle is perfect for all projects or for all portions of a project. Instead, each project life cycle falls within the continuum shown in Figure 2-1, which provides an optimum balance of characteristics for its context. Various scheduling approaches may be used within the life cycles described. High Incremental Adaptive Frequency of Delivery um ti nu C on Predictive Iterative Low Low High Degree of Change Figure 2-1. Life Cycle Continuum The four life cycles shown in Figure 2-1 are as follows: Predictive life cycle. Figure 2-2 illustrates a typical predictive flow diagram. This life cycle takes advantage of uu projects or products that are known and proven allowing the major planning to occur prior to project execution. This reduces uncertainty and complexity and allows teams to segment work into a sequence of predictable groupings. CPM is a predictive approach. 10 Section 2  Analyze Design Build Test Deliver Figure 2-2. Example of Predictive Flow Diagram Iterative life cycle. Figure 2-3 represents a typical iterative flow diagram. This life cycle allows feedback on uu partially completed or unfinished work to improve and modify that work. Refine Refine Refine Analyze Develop Proof Design Build Deliver of Concept Test Figure 2-3. Iterative Flow Diagram Incremental life cycle. Figure 2-4 shows a typical incremental flow diagram. This life cycle provides finished uu deliverables that the customer may be able to use immediately, creating early value for the project. Analyze Analyze Analyze Design Design Design Build Build Build Test Test Test Deliver Deliver Deliver Figure 2-4. A Life Cycle of Varying Size Increments 11  Adaptive life cycle. Figure 2-5 represents a typical adaptive life cycle. This life cycle leverages the aspects uu of both iterative and incremental characteristics. When a team uses adaptive life cycles, it iterates throughout the project to create finished deliverables. The team gains early feedback and provides customer visibility, confidence, and control. The project may provide an earlier return on investment because the team can release earlier and deliver the highest-value work first. This life cycle works well when the level of uncertainty is high. Agile is an adaptive approach. Iteration-Based Agile Requirements Requirements Requirements Requirements Requirements Requirements Analysis Analysis Analysis Analysis Analysis Analysis Repeat Design Design Design Design Design Design as needed Build Build Build Build... Build Build Test Test Test Test Test Test NOTE: Each timebox is the same size. Each timebox results in working tested features. Flow-Based Agile Requirements Requirements Requirements Requirements Requirements Analysis Analysis Analysis Analysis Analysis Design Design Design Design Design Repeat Build Build Build as needed Build Build Test Test Test... Test Test the number of the number of the number of features the number of the number of features in the features in the in the WIP limit features in the features in the WIP limit WIP limit WIP limit WIP limit NOTE: In flow, the time it takes to complete a feature is not the same for each feature. Figure 2-5. Adaptive Flow Diagram 12 Section 2  Hybrid life cycles. Figure 2-6 shows a typical hybrid flow diagram. It is not necessary to use a single life cycle uu for an entire project. Projects often combine elements of different life cycles in order to achieve certain goals. A combination or hybrid use of predictive, iterative, incremental, and/or adaptive may be appropriate for stages or portions of a project. Adaptive Adaptive Adaptive Predictive Predictive Predictive Adaptive Adaptive Adaptive Predictive Predictive Predictive Figure 2-6. Combined Predictive and Adaptive Approaches Used A key point regarding the life cycles mentioned previously is that each type shares the element of planning. What differentiates one type from another is not whether planning is done, but rather how much planning is done and when. The scheduling approach provides the structure for the creation of the schedule model. The most common scheduling approach, supported by most scheduling tools, is the precedence diagram method (PDM). PDM is a technique used for constructing a schedule model in which activities are represented by nodes and are graphically linked by one or more logical relationships to show the sequence in which the activities are to be performed. PDM is commonly referred to as CPM. CPM may use critical chain, rolling wave planning, program evaluation and review techniques (PERT), and integrated master scheduling (IMS). Critical interdependencies between activities and subprojects are required to be included in the schedule. The first step in schedule model creation is selection of an appropriate approach. Some organizations standardize on a specific software tool and define their own preferred scheduling approaches, applying standards for their use. In that case, the scheduling approach decision has often already been made, as it is inherent in the tool, and does not need to be made again. Since it is the most commonly used approach, this practice standard focuses on CPM (a predictive approach) with considerations related to agile and other emerging approaches. 13 2.2.1 CRITICAL PATH APPROACH CPM refers to the prevalent approach used in modern scheduling tools and helps to identify the shortest time to complete the project. The critical path approach is used to derive the critical activities that cannot be delayed without delaying the end date of the project. A basic principle of CPM is that each activity is driven by one or more preceding activities. The pure CPM network allows only zero or positive total float on the project critical path. Modern CPM tools accommodate a variety of features to enhance project schedule viability. These features include resources, calendars (project, activity, and resource), constraints, varying definitions of criticality, elapsed durations, lags, leads, external dependencies, activity priorities, and the assignment of actual start and finish dates to activities. These additional features introduce the possibility of negative and varying float values along the critical path. Generally, the approach used in these tools is the precedence diagramming method (PDM). This practice standard follows that common usage convention but uses the term CPM. Figure 2-7 illustrates an overview of the schedule model flow. Within this modeling process, all of the required project activities and milestones are defined and sequenced to achieve the project objectives. Schedule model creation includes the following processes related to the Project Schedule Management and Project Resource Management Knowledge Areas in the PMBOK ® Guide (see Figure 2-8): Define Activities, uu Sequence Activities, uu Estimate Activity Resources, uu Estimate Activity Durations, and uu Develop Schedule. uu The schedule model generates schedule model instances from which presentations are created (See Figure 2-7). The schedule model instances may represent the approved baseline, selected targets, or what-if schedule models. Schedule model creation results in an approved schedule model used by the processes in the Executing and Monitoring and Controlling Process Groups (see the PMBOK ® Guide). The schedule model reacts predictably and logically to project progress and changes. Once created and approved (baseline established), the scheduler updates the schedule model in support of the project’s regular reporting intervals according to the schedule management plan and to reflect progress and changes. 14 Section 2  Project Start Critical Path Method, Precedence Diagramming Method, or Critical Chain Method, for example. This approach is often inherent with scheduling tool selection, as most modern scheduling tools are software Select implementations of a particular Scheduling scheduling approach. Many companies Approach have already made this selection for all projects. Select Selection of a scheduling approach Scheduling may limit the choice of tools. Many companies have already made this Tool selection for all projects. Enter Project-Specific Data Schedule Schedule Model Model Instances and Presentations Update and Status Project Complete Figure 2-7. Schedule Model Flow 15  Schedule Model Management PM Processes Schedule Model Creation Project Name Define Project Milestones Schedule ID Define Define Scope Activities 5.3 6.2 Sequence Activities 6.3 Create WBS 5.4 Estimate Activity Resources 9.2 Acquire Resources Estimate Activity 9.3 Durations 6.4 Develop Conduct Schedule Procurements 6.5* 12.2 Analyze Schedule Model Output Enterprise Environmental Factors/ Organizational Process Assets Approve the Schedule Model PM Processes Schedule Model Maintenance Develop Project Management Baseline the Plan Schedule Model 4.2 Direct and Manage Control Project Work Schedule 4.3 6.6* * These processes are defined in the Enterprise Environmental Factors/ PMBOK® Guide and cannot be changed; Organizational Process Assets however, what is being developed and controlled is the schedule model. Figure 2-8. Flow Diagram for the Schedule Model Mapped to PMBOK ® Guide Knowledge Area Processes 16 Section 2  CPM determines the minimum total project duration and the earliest possible finish date of the project. CPM also determines the amount of scheduling flexibility (total float) in the schedule model. To apply CPM, a schedule model that is comprised of project activities is developed. Early start and finish dates are calculated for each activity by means of a forward pass from a specific project start date. Late start and finish dates are determined for each activity by means of a backward pass, starting from the project early finish date determined during the forward pass calculation or from a specific project finish date (constraint). To establish a meaningful critical path, it is necessary to develop a logic-based network of activities with empirically derived durations for execution in a realistic and practical manner. These logical relationships can be of a physical nature (need for supporting structures, arrival of necessary resources, etc.) and the desired sequence from the execution plan (north to south, inside to outside, etc.). In building out the schedule network, a loop may unintentionally be created, where a path of activities returns to itself. In most cases, the scheduling tool will stop calculating and provide a notification of the detected loop. Open ends in a schedule are those activities that lack a predecessor and/ or a successor activity, thereby creating a hole or gap in the schedule logic from project start to finish. The only open ends that are acceptable are the project start and project finish milestones. The use of constraints, including leads and lags, should be restricted to those conditions that cannot be adequately defined and modeled by the application of activity logic. CPM illustrates the relationships between activities left to right (time-phased), allowing project activities to flow from a project start milestone to the project complete milestone. Relationships between time-phased activities are represented by directional arrows. The logical relationships need to be satisfied. In CPM, an activity can be connected from either its start or its finish. This allows a start-to-finish logic presentation with no need to break the work down further. Another characteristic of CPM diagrams is the use of lead and lag components. An example of a network diagram is shown in Figure 2-9. 17  Activity B Start Activity A Activity D Finish Activity C Activity Duration Early Start (Days) Early Finish Link(s) from Link(s) to Predecessor(s) Successor(s) Activity Name (Include appropriate Grouping IDs) Total Float (Days) Late Start Late Finish Cost (Currency) Figure 2-9. Example of CPM Diagram 2.2.2 CRITICAL CHAIN Critical chain focuses on the project schedule model activity and resource dependencies. The critical chain effectively eliminates most resource contention before the project starts and uses buffers for project control. It reduces project changes and the major source of project cost overruns by improving schedule performance. It accomplishes these results by changing the project measurement and control system along with certain behaviors of the project team and supporting personnel. 18 Section 2  Resource availability competes with the ability to execute tasks on the planned dates. As such, many software programs allow resources to be leveled (so that they are not overburdened), which may stretch the project duration and scheduled start and finish dates for activities. Considering the availability of resources, the resultant schedule model may contain a resource-constrained critical path, and it is the starting point for critical chain scheduling. The critical chain approach is developed from CPM and considers the effects of resource allocation, resource leveling, and activity duration uncertainty on the CPM-determined critical path. Critical chain creates an aggressive (but not necessarily detailed) resource-leveled project schedule. The underpinning principle of the critical chain process lies in the fact that within a systemic chain of actions there is almost always one action that is constrained or limited by resources, impacting the throughput of the entire chain. The project end date is defined as the end of the critical chain, including the buffers to account for project risks, uncertainties, and slippages. During project execution, when activities consume a longer duration than predicted by the critical chain, the project buffer is gradually consumed. According to the degree of buffer consumption, the project team can address necessary corrective actions; from “no need to react” to “planning the response” to “executing the planned response to recover project buffer.” As long as the total of slippages is less than the buffer, there is a limited effect on project scope, duration, and budget. This approach is called buffer management. The longest resource-leveled path through the schedule, including buffers, is the critical chain. The critical chain is often different from the critical path in CPM. The defining factors in the critical chain are buffer activities, resources that are not multitasked, resource leveling, and buffer management. Critical chain starts with a CPM schedule model, but differs from CPM in four main aspects: The critical chain assumes that significant, unexpected risks that were unforeseen will materialize during a uu project and necessitate proactive actions. The focus of managerial attention remains fixed throughout the project on the critical chain and rate of project uu buffer consumption. The critical chain considers the magnitude of resource contention (based on the theory of constraints) in the uu calculation of project duration and scheduling of activities. Instead of margins being distributed and hidden in individual activities, the margins are exposed and aggregated uu in buffers, thus reducing risk exposure to the project. 19  The buffers are taken from the planned activity durations and do not increase the project duration. The critical chain introduces three types of buffers: feeding buffers, resource buffers, and project buffers as follows: Feeding buffers. As shown in Figure 2-10, feeding buffers are buffers (in duration) added to the schedule uu model where chains of noncritical tasks feed into a critical chain task. 15 days late 20-day buffer Path A Buffer On schedule Path B Buffer 15 days early Start 5 days early Path C Merged Path Figure 2-10. Feeding Buffers Resource buffers. Resource buffers act as early warning signals that ensure the timely availability of project uu resources by notifying the team of these resource requirements. They are set along the critical chain to ensure resources are available to work on the activities as soon as they are needed. Unlike project buffers and feeding buffers, resource buffers are not safety times added to the project, and they do not change the elapsed time of the project. Project buffers. Typical project buffers are shown in Figure 2-11. Project buffers are durations added to the uu end of the project between the last project activity and the final delivery date or contracted completion date. Buffers can be statistically determined, but are mostly defined by using rules of thumb (half of the activities’ duration). Aggregated safety margins are assigned to individual chains of activities. Buffers are created by (a) assigning aggressive activity realization times to remove any hidden safety margins and (b) aggregating the resulting savings of planned times into buffers. The amount of project buffer can be derived as the schedule contingency resulting from the quantitative risk (e.g., Monte Carlo) analysis. Instead of spreading the safety margins among all activities, a safety margin is concentrated at the end of a chain and used only if risk materializes (whatever it may be, resulting in resource and duration uncertainties). This effect of managing the rate of buffer consumption is similar to managing the total float and free float in the CPM approach, but often more effective and efficient. 20 Section 2  Critical Path Method Activity A Activity B Critical Chain Method Activity C Activity A Activity D Activity B Activity C Activity D Buffer Figure 2-11. Project Buffers 2.2.3 ADAPTIVE LIFE CYCLE Projects range from definable work with known scope requirements to high-uncertainty work where the project scope and approaches are not as well known (see Figure 2-12). Definable work projects are characterized by procedures and processes that have proved to be successful on similar projects in the past. The production of a car, electrical appliance, building, or home after the design is complete are examples of definable work that uses a linear approach. The production domain and processes involved are usually well understood, and the amount of uncertainty and risk is typically manageable. New designs, problem solving, and projects not done previously are considered exploratory. They require subject matter experts to collaborate and solve specific problems to create a solution. Examples of high-uncertainty work includes software engineering and product design. As more definable work is automated, project teams are undertaking more high-uncertainty projects that require the approaches more suited to an adaptive approach like agile. 21  High Uncertainty Ch ao Fundamentally s risky Co Requirements Uncertainty m pl ex Co m Adaptive pl approaches ica work well here te d Si Low Uncertainty m Linear pl approaches e work well here Low Uncertainty High Uncertainty Technical Degree of Uncertainty Figure 2-12. Diagram of Uncertainty High-uncertainty projects have high rates of change, complexity, and risk. These characteristics can present problems for traditional predictive approaches that aim to manage the bulk of the requirements up front and control changes through a change request process. Agile is an umbrella term for many adaptive approaches. It allows project managers to quickly adjust to stakeholder needs, as well as any feedback the team receives internally or externally. There are many approaches under the agile umbrella as reflected in Figure 2-13. Two of the more popular approaches are Scrum and Kanban. 22 Section 2  Lean Agile Kanban ScrumBan Crystal AUP Scrum FDD XP DSDM Figure 2-13. Examples of Agile Approaches 2.2.4 ROLLING WAVE PLANNING Rolling wave planning is an iterative planning technique in which the work to be performed in the near term is planned in detail, while work in the future is planned at a lower level of detail. The rolling wave planning technique, sometimes referred to as “progressive elaboration,” assumes the project team is very likely to have accurate and detailed information concerning the near-term activities of the current wave and less information about activities in the future waves of the project. When using rolling wave planning, it is important to perform the detailed planning at regular intervals. The detailed planning for the next interval needs to be completed before the start of the next wave’s execution. The wave durations define the boundaries within which the detailed work will be added at a later date. 23 For periods beyond the detailed planning wave, activities are listed as planning packages with much less detail. These planning packages contain cost and resource information, which becomes fixed in the baseline duration and cost for a CPM approach. When detailed planning takes place, it replaces the planning packages with additional details. Figures 2-14 and 2-15 illustrate an example of rolling wave planning. Rolling wave planning concepts also apply to some adaptive approaches. March April May June July Augu 18 25 4 11 18 25 1 8 15 22 29 6 13 20 27 3 10 17 24 1 8 15 22 29 5 Planning Package 1 Activity A Activity B Activity C Activity D Planning Package 2 Planning Package 3 Figure 2-14. Example of Rolling Wave Planning—Planning Package 1 Decomposed March April May June July Augu 18 25 4 11 18 25 1 8 15 22 29 6 13 20 27 3 10 17 24 1 8 15 22 29 5 Planning Package 1 Activity A Activity B Activity C Activity D Planning Package 2 Activity E Activity F Activity G Planning Package 3 Figure 2-15. Example of Rolling Wave Planning—Planning Package 2 Decomposed 24 Section 2 2.2.5 OTHER APPROACHES AND EMERGING TRENDS Other approaches and emerging trends for scheduling are: Location-based scheduling. Location-based scheduling (LBS) was developed to help project managers in the uu construction industry with workflows and planning. LBS is also known as vertical production method, linear scheduling, repetitive scheduling method, even flow production, and flowline scheduling. The LBS scheduling approach develops a schedule that shows the location and time of an event, in addition to the movement of the crews through time and space (see Figure 2-16). This approach focuses on optimizing production rates for many resources working in parallel, often on multiple work fronts. The different tasks in the project should proceed in the same flow to create a constant progression without wasted time. Frequently, the model contains a geographical location of the activities in the project. LBS is used to plan or record progress on multiple activities that are moving continuously in sequence. The method is visualized by a graphical tool. The main attraction of this method over CPM is its underlying idea of optimizing resource utilization. The progress of the work is easily seen, and the sequence of different work activities is easily understood. This approach is predominately used in large-scale, horizontal construction projects (e.g., railways, highways, pipelines, transmission lines), and vertical construction projects (e.g., floor-by-floor fitouts of skyscrapers). Industrial projects sometimes use a hybrid of this approach. Time Excavation Installation Location-Based Schedule Model 2,200 M1 250 2,000 1,800 M2 670 250 1,600 M3 830 670 1,400 Location 1,200 M4 1,010 830 1,000 800 M5 1,400 1,010 600 M6 1,543 1,400 400 200 M7 1,715 1,543 0 M1 M2 M3 M4 M5 M6 M7 M8 M9 M8 2,020 1,715 Time M9 2,020 Excavation Installation Figure 2-16. Location-Based Schedule Example 25  On-demand scheduling. On-demand scheduling is typically used in an adaptive environment. On-demand uu approaches are based on pull-based scheduling concepts from lean manufacturing. The purpose of on-demand scheduling is to limit a team’s work-in-progress (WIP) in order to balance the demand against a team’s delivery throughput. It is preferable that the project team is agile and responsive so that the work product can be delivered “just in time.” Demand and capability are always fluctuating; therefore, balancing occurs when the work enters the system, not before. Other scheduling approaches make assumptions about work products, which makes it difficult to take any balancing actions once the work is put into a project. Using a pull approach, the downstream work takes (pulls) work from upstream only when the downstream has the capability to proceed with new work. Pull systems require that work stages have limits for work-in-progress (WIP-limits). Once a flow is established, it helps to estimate the completion of work. Such systems are more predictable and have fewer unwanted variations, which minimizes waste in the process. Planning removes bottlenecks, thereby driving the value of the schedule model. Once the bottlenecks or constraints are removed, an efficient process flow is created, which balances delivery throughput. Lean scheduling. Lean scheduling is based on the principles of lean project delivery (on-demand scheduling) uu and designed to minimize waste in order to maximize value. To achieve this goal, deliverables are not assigned to the team. Lean scheduling principles point to the importance of limiting queues by pulling work when there is capacity to place the work into the process. The project team members collaborate in pull planning sessions where the essential activities, durations, and handoffs between trades to complete milestones are defined. The main steps are: nnMaster scheduling. Identifies key milestones, essential activities, and phases. This detailed schedule is created by the project team. nnPhase scheduling. Uses phases identified from the master schedule. Working backward (pulling), the duration, sequences, constraints, and coordination in each phase are collaboratively established. The team agrees on the plan and executes as a team. The output from this phase schedule is used to generate look-ahead schedules. nnLook-ahead planning. Maximizes reliability by matching workflow with capacity. Detailed plans for work to be done are established using weekly work plans, and a backlog of ready work is maintained. Intelligent systems. Intelligent systems consider artificial intelligence applied to project scheduling that is uu based on machine learning. Machine learning uses algorithms to parse data, learns from it, and then makes a determination or prediction. Based on that, instead of performing a sequence of activities manually, it enters a set of assumptions and activity requirements, such as constraints, hard logic, resources, and conditions (IF-THEN-ELSE). As an emerging trend, intelligent systems have been widely applicable across all industries. For scheduling purposes, one possible scenario is that the schedule model learns from progress made and proposes a new sequence of relationships based on the inputs for activities that remain to be performed. Another possibility is that the schedule model learns from other projects’ schedule models, and based on identified patterns, the schedule model recommends the level of contingency avoidance for materials, vendors, 26 Section 2  or workers. Algorithms identify clusters of activities with specific behaviors and identify patterns where the activities can be analyzed to understand how to avoid or exploit such patterns. Line of balance. Line of balance (LOB) was initially developed for planning and controlling manufacturing uu industrial processes. Later, its use was expanded as a method for planning and controlling projects with repetitive or long-duration activities. LOB’s focus is on production rates (units) over time for repetitive activities, rather than on defining and tracking discrete activities over time. This results in a visualization that shows the flow of work and units produced. LOB shows repetitive work in the project as a single line on a graph rather than a series of individual activities on a bar chart. This line represents the rate that the work needs to be performed to stay on schedule. LOB can help expose process bottlenecks. The main advantage of LOB is that it calculates productivity along with time in an easy graphical representation. Building information modeling. Building information modeling (BIM) is a process that creates and manages uu information regarding the physical and functional characteristics of a building. It is used to support decision making during a building’s entire life cycle. The collection of project information in a central repository provides an opportunity to integrate the project’s 3D design model (height/width/depth) and the schedule model. BIM software allows the identification of sequences for the design objects which become the underlying logic for the schedule model. In BIM, time is considered the fourth dimension. Adding the dimension of time to BIM allows the schedule to be linked with data objects at an appropriate level of detail and the project to be built virtually. It also allows for testing different options before deciding the best approach from a scheduling perspective. Cost can be incorporated as a fifth dimension. An integrated BIM approach supports the following: nnCost estimating, nn3D coordination, nnTimely procurement/prefabrication, nnConstruction planning and monitoring, nnVisualization of a 4D model of planned execution, and nnRecord model of the owner’s life cycle use. 4D BIM modeling visualization incorporates start and finish date data for the supply and installation of construction components and reveals the importance of them in relation to the overall project. BIM removes the challenge brought about by the lack of visualization that is associated with traditional scheduling of construction sequences. BIM software tools in the construction/engineering/infrastructure field save significant amounts of time and money on projects that use it. This approach can substantially reduce both costs and schedule, thereby reducing construction claims. Major companies and governments worldwide are beginning to mandate the use of BIM on large projects. 27 2.3 SCHEDULING TOOL A scheduling tool is typically a software application that contains algorithms, components, features, and rules to input and manipulate activities, dependencies, resources, and their assignments to create schedule model instances and schedule presentations. Scheduling components are easily visualized by running a scheduling software application and observing the functionality in the scheduling tool that is available to build the schedule model. The scheduling tool is the platform upon which the schedule model is assembled. This platform provides the means to adjust various schedule parameters and components within the model and analyze trends and performance. For example, the scheduling tool for a CPM approach includes the capability to accomplish the following: Select the type of relationship (such as finish-to-start or finish-to-finish) between activities; uu Add lags and leads between activities; uu Add supplementary information to activities that aids in analysis, reporting, and grouping; uu Apply resources to the activities and use resource information along with resource availability to adjust the uu scheduling of activities; Assign priorities to activities that use the same resources over the same period; uu Add constraints to activities where logic (e.g., precedence relationships with other activities) alone is not uu adequate to meet the project requirements, especially when considering external schedule drivers and resource availability; Capture a specific schedule model instance as a baseline; uu Record the actual progress of scheduled activities; uu Perform various what-if-analysis scenarios within the schedule model to obtain different project end dates; uu Analyze the impact that potential schedule model changes would have on the project objectives; uu Compare the most recent schedule model instance against a previous schedule model instance or against the uu approved baseline instance to identify and quantify variances and trends; and Verify the validity of the resulting schedule model. uu 28 Section 2 2.4 SCHEDULE MODEL The introduction of project-specific data (e.g., work packages, activities, durations, resources, relationships, dependencies, and constraints) into the scheduling tool creates a schedule model for the given project that is independent of the approach and its requirements. The schedule model is a management tool containing information related to the project execution plan. The schedule model simulates distinct scenarios and situations that predict milestones and completion dates according to the project’s actual and future data input by the project team. It is an important tool used for communication and managing stakeholder expectations. The schedule model is guided by a schedule management plan that identifies (a) the scheduling approach used; (b) the scheduling tool used; and (c) how the activities, planned dates, durations, resources, dependencies, and constraints should be addressed. Schedule model creation incorporates sequences, durations, resource requirements, and schedule constraints for project execution in addition to monitoring and controlling. As a result, it generates a schedule model with planned dates for completing the project activities. Schedule model creation results in an approved schedule model used by the processes in the Planning and Monitoring and Controlling Process Groups (see Section 6 in the PMBOK ® Guide), which reacts logically and predictably to project progress and changes. Schedule model analysis compares changes in the schedule model to the baseline based on updates of progress, cost, and scope with the project team’s expectations of the impact of these changes. The changes in scope, through formal changes or evolution, need to be included concurrently in the WBS and the schedule model. The project team uses the schedule model to predict project finish dates in the form of schedule model instances. The schedule model provides time-based forecasts, and responds dynamically to inputs and adjustments made throughout the project’s life cycle. In schedule model creation, milestones and defined activities, which are based on the project WBS and WBS dictionar