Forecasting Programs 9780986733925, 098673392X

Citation preview

Forecasting Programs Scheduling Best-Practices for Real-World Programs For Program Managers, Project Managers and Program Support Steps and Screenshots in MS Project 2010/2013/2016, Project Server / Project Online

www.ProjectProCorp.com

Forecasting Programs

Publishing Notice

Publishing Notice Copyright © ProjectPro Corp. ISBN 978-0-9867339-2-5 Uyttewaal, Eric. Forecasting Programs: Scheduling Best-Practices for Real-World Programs 1. Program Management 2. Project Management – Computer Programs Dewey decimal classification number: 658.404 These materials are copyrighted and all rights are reserved. This document may not be copied, photocopied, scanned, reproduced or reduced to any electronic medium or machine-readable form neither in whole nor in part without prior consent in writing from ProjectPro Corp. Please send your requests to the author: Eric Uyttewaal, PMP President ProjectPro Corp Email: [email protected] This document was prepared using Microsoft Word for text entry and layout. The illustrations are made in PowerPoint. The screen and button screenshots are made with SnagIt: • Microsoft is a registered trademark of Microsoft Corporation. • Microsoft Word is a trademark of Microsoft Corporation • PowerPoint is a trademark of Microsoft Corporation • SnagIt is a registered trademark of TechSmith Corporation.

© PROJECTPRO CORP.

PAGE I

Publishing Notice

Forecasting Programs

Disclaimer The author made a sincere effort to ensure the accuracy of the material provided herein. However, the author assumes no responsibility whatsoever for the use of this material or for decisions based on its use. There are no warranties, either expressed or implied, regarding the contents of this product, its marketability or its fitness for any purpose. The author or anyone involved in the creation, the production or the delivery of this material shall not be liable for any reason.

Acclaimer If you find any technical error in this textbook, we will pay you CAD $20 for each technical error (as opposed to language errors!) that we had not found or heard about before and that you report to us at: [email protected]. This does not include technical errors because of changes Microsoft introduced in Project Online after the publication date of this textbook. We feel so comfortable with the quality of this textbook that we challenge you to find any technical errors in it. Any errors found will be published in the download file Forecasting Programs – book download files

PAGE II

© PROJECTPRO CORP.

Forecasting Programs

Publishing Notice

Download Files that Accompany this Book Free added-value materials are available if you leave your name and contact info at: www.ProjectProCorp.com At ProjectPro, we are committed to providing today’s professional with practical, hands-on tools that enhance the learning experience and give readers an opportunity to apply what they have learned. That is why we offer free, additional materials available for download. To download these files: 1. Open your Internet browser and navigate to: www.ProjectProCorp.com. 2. If you have an account already, click the Log in button

at the top right. You

are now prompted for your Log in data. OR If you are a new customer, just navigate our store and buy or download a product; you are asked to create a login account. 3. You can find the download ZIP-file that accompanies this book under the Books menu; look for a product called: Forecasting Programs – book download files The download files available to all readers of this book consist of (subject to modification without prior notice): ◆ Start exercise files and solution files ◆ Files with views, tables and filters described and recommended in this book There is also a solutions manual, with answers to all review questions, designed and written for professors. However, the solutions manual is only available to those professors who make the book mandatory reading for their students in their courses. Professors need to contact the author, Eric Uyttewaal, first at: [email protected]. Join the dialog about this book and about scheduling in general at the LinkedIn Group called Forecast Scheduling.

© PROJECTPRO CORP.

PAGE III

Publishing Notice

Forecasting Programs

Short Table of Contents Publishing Notice

I

About this Book

15

Chapter 1 Program Management

21

Chapter 2 Choosing the Best Scheduling Approach

51

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

87

Chapter 4 Organizing the Program

107

Chapter 5 Consolidating Projects into a Program Schedule

157

Chapter 6 Linking Projects in a Program

177

Chapter 7 Sharing Resources

231

Chapter 8 Optimizing the Integrated Master Schedule

271

Chapter 9 Reporting on Large Schedules

297

Chapter 10 Monitoring Progress in Projects of a Program

333

Chapter 11 Summary

349

Index

363

PAGE IV

© PROJECTPRO CORP.

Forecasting Programs

Publishing Notice

Long Table of Contents Publishing Notice Disclaimer Acclaimer Download Files that Accompany this Book Short Table of Contents Long Table of Contents Dedication Acknowledgements ProjectPro Consulting ProjectPro Training ProjectPro Products

I II II III IV 1 9 10 12 12 14

About this Book The Author and Program Management Learning Objectives of this Textbook Target Group and Assumptions in this Book Conventions in This Book Conventions in This Manual Types of Slides in Our Training Slide Deck

15 15 16 17 17 17 19

Chapter 1 Program Management Learning Objectives Definitions What is a ‘Project’? What is a ‘Program’? What is a ‘Portfolio’? Differences between Project, Program and Portfolio Responsibilities and Skills of a Program Manager Responsibilities of Other Roles Program Life Cycle Phases Integrated Program Management Information System Project Server or Project Online? What is Project Server, Project Online and Project Web App? Project Server / Project Online and PPM Project Server / Project Online and Program Management What Does Project Server / Project Online Add to MS Project? Use Project Server / Project Online for Your Program or Not? Technical Considerations Human Considerations

21 21 23 23 23 24 25 28 31 33 34 35 35 36 40 40 41 41 42

© PROJECTPRO CORP.

PAGE 1

i

Publishing Notice

Forecasting Programs

Financial Considerations Working with Vendors Relentlessly Standardize on Scheduling Software Relentlessly Standardize on a Scheduling Software Release How Can You Standardize on Software and Release? Chapter 2 Choosing the Best Scheduling Approach Learning Objectives Introduction Project Ideals Project Constraints Analyzing your Project Current Scheduling Approaches Agile (AG) Scheduling What is Agile? Assumptions of Agile Best Use of Agile Critical Path Method (CPM) Scheduling What is Critical Path? Assumptions of the CPM-Approach Best Use of Critical Path Resource-Critical Path (RCP) Scheduling What is a Resource-Critical Path? Assumptions of the RCP-Approach Best Use of RCP-Scheduling Critical Chain (CC) Scheduling What is Critical Chain? Assumptions of the Critical Chain Approach Best Use of Critical Chain Scheduling Earned Value (EV) Scheduling and Earned Schedule What is Earned Value? What is Earned Schedule? Earned Value / Earned Schedule Reporting Assumptions of the Earned Value Approach Best Use of Earned Value Earned Work (EW) Scheduling What is Earned Work? Assumptions of the Earned Work Approach Best Use of Earned Work? Choosing the Right Scheduling Approach Combining Approaches Happy Couples PAGE 2

44 46 47 49 50 51 51 53 53 55 56 58 58 58 59 60 60 60 61 62 62 62 63 64 65 65 69 70 71 71 71 71 72 75 75 75 77 78 78 82 82 © PROJECTPRO CORP.

Forecasting Programs

Publishing Notice

CPM happy with EV RCP happy with EV EW happy with EV Simulation is Happy Miserable Couples AG unhappy with any other approach CPM and RCP unhappy with CC CC unhappy with EV Validity of the ‘Project Ideal and Constraint Matrix’? Conclusions Bibliography

82 83 83 83 83 83 84 84 85 85 86

Chapter 3 Agile OR Critical Path? Agile AND Critical Path! Learning Objectives Introduction Agile and Critical Path in One Schedule Compromises Needed from Agile Compromises Needed from Critical Path Can You Live with the Compromises? Agile AND Critical Path in One Schedule: How-To Can Agile Estimates be Converted into Critical Path Estimates? Switching Swiftly Between an Agile and Critical Path WBS Scope Emerges in Agile; Critical Path likes Early and Stable Scope The Struggles of Critical Path All Tasks Need to be Linked Many Dependencies are, in Fact, Resource Dependencies All Tasks Need a Duration Estimate All Tasks are Sequential, Not Iterative Critical Path Expects the Project to be Forecasted to its End Agile Can Help Critical Path with its Struggles The Struggles of Agile The Client Wants the Overall Picture for the Whole Product User Stories Too Big for one Sprint How Can You Coordinate Multiple Sprint Teams? You Must Report Critical Path while You Do Agile Your Program has Agile Parts as well as Critical Path Parts Critical Path Can Help Agile with its Struggles Benefits of Agile and Critical Path in a Single Schedule

87 87 89 91 93 93 94 95 96 97 99 99 99 100 101 101 102 102 102 103 103 104 104 105 105 105

Chapter 4 Organizing the Program Learning Objectives Sizing Up Your Program: Heuristic Metrics Introduction to Scheduling Programs

107 107 109 112

© PROJECTPRO CORP.

PAGE 3

i

Publishing Notice

Forecasting Programs

The Challenge of Scheduling Programs: Size of Schedule Drowning in Data? Are You Really in a Program? Modeling Modeling Examples The Schedule is Not the Program Modeling Theory Scheduling is Modeling Some Rules for the Program Schedule Model When Can You Call Your Program ‘In Control’? Breaking Down the Program Keep One Large Schedule or Divide the Program Schedule? Can your Organization Handle the Scheduling? What Kind of Project Schedule Should You Request? Proficiency Levels Time, Workload and Cost Modeling Three Levels of Proficiency in Scheduling Projects Time Model Example Workload Model Example Cost Model Example Benefits of the Time, Workload and Cost Model Scheduling Maturity Conclusion The Program Work Breakdown Structure (PWBS) Government Archetypical Breakdown Levels Private Sector Archetypical Breakdown Levels Working With our Archetypical Breakdown Structures The Projects The Crucial Level of Breakdown: Projects How Many Projects Should You Have? Possible Orientations for Breaking Programs into Projects Success Criteria for Breaking down a Program Other Requirements for the Breakdown Orientation You Choose Exercises: Breaking down the Program into Projects Case Study 1: National Mail Corporation Case Study 2: Far North Native Community Construction Case Study 3: National Standards Organization Does the Level of Projects Need to Be Clean? One Big-Bang Release or Many Small-Bang Releases? Chapter 5 Consolidating Projects into a Program Schedule Learning Objectives PAGE 4

115 116 117 117 117 119 120 122 122 124 125 125 128 128 128 130 132 133 135 137 140 141 142 143 143 145 146 146 146 146 147 149 150 152 152 153 153 154 155 157 157

© PROJECTPRO CORP.

Forecasting Programs

Publishing Notice

Why (Re)Integrate the Project Schedules? Project Schedules and the Program Schedule Checks to Perform before Consolidating Project Schedules Microsoft’s Object Linking and Embedding Consolidating Project Schedules To Consolidate Projects in a Master Schedule Using MPP-files on your File Server Inserting Project Server or Project Online Schedules Working with a Consolidated Schedule Exercise Creating a Master Schedule Possible Problems with Consolidated Files Chapter 6 Linking Projects in a Program Learning Objectives Dependencies between the Projects in the Program Options for Dependencies between Projects 2 Identify Them and Coordinate Dates Manually and Regularly Exercise: Create Give-And-Get System from single Program Schedule Exercise: Manually Synchronize Dates Give-And-Get System 3 Model them Using the Deliverables Feature Exercise Deliverables 4 Model them Using the ‘Links-Between-Projects’ Feature in MS Project Setting Cross-Project Links Using the Master Schedule File (Recommended) Using ribbon View, button New Window (Not Recommended) Viewing External Tasks in a Project Behind the Screens of an External Dependency To Maintain the Cross-Project Links Exercise: Accepting the Impacts from Links-between-Projects Possible Problems: Circular Dependencies Do’s and Don’ts when Working with Links-between-Projects Advantages & Disadvantages of Links-between-Projects Working Around the Disadvantages 5 CrossLinksPro: Our Solution for Integrated Programs Reducing the Program Model to Something Manageable CrossLinksPro, Solution for Integrated Programs Example Program “Write Book” Excel Spreadsheet to List All Cross-Project Links Program “Write Book”: Updated Schedules CrossLinksPro: Get Latest Dates: Handoff Dashboard CrossLinksPro Creates the Links PathsPro Analyzes the Program Critical Path © PROJECTPRO CORP.

159 159 160 169 171 172 172 173 174 175 175 177 177 179 182 186 188 193 196 197 198 198 199 201 202 203 204 208 209 210 213 215 215 217 218 220 220 221 222 222 224 PAGE 5

i

Publishing Notice

Forecasting Programs

CrossLinksPro Marks Handoffs as Critical in Excel CrossLinksPro Replaces and Removes Links after Optimizing Original Unique IDs from Sub Schedules Shown in Master Typical Weekly Process when Working with CrossLinksPro CrossLinksPro: Advantages and Disadvantages Advantages Disadvantages

224 225 225 227 228 228 229

Chapter 7 Sharing Resources Learning Objectives Limited Resources Pose Resource Constraints What is a Shared Resource Pool? Resource Management in Programs Types of Resources: Generic versus Actual Role Balancing: Finding the Optimum Mix of Roles Workload Leveling: Keeping the Workloads Reasonable Generic and Actual Resource Sharing Situations Reactive or Proactive Workload Leveling across Programs? What are the Options for Creating Shared Resource Pools? Overview Getting Started with Project Online Step 1. What Resources in the Shared Resource Pool? Step 2. Determine What Generic Resources You Will Need Step 3. Create Team Assignment Pools Step 4. Create Generic Resources in Program Resource Pool Step 5. Migrate the Project Schedules to Project Online Step 6. Create the Master Schedule for the Program Sharing Resources Inside versus Outside the Program Sharing Resources with Projects Outside your Program

231 231 233 234 235 236 237 238 240 241 242 243 244 252 255 259 261 263 263 263

Chapter 8 Optimizing the Integrated Master Schedule Learning Objectives Are You in a Portfolio or an Integrated Program Schedule? Critical Path or Resource-Critical Path in Your Program? Critical Path in a Project Program Critical Path Can You Display a Complete Critical Path in a Program? Focus on One Major Milestone at a Time Manual Technique to Find the Critical Path to a Milestone Technique: Sequestering the Subnet Sequestered Subnet Interactive Filter to Display the Sequestered Subnet Exercise Metro Police Dispatch System Automatically Identify Critical Paths on Major Milestones Finding the Resource-Critical Path in Program Schedules

271 271 273 273 274 275 276 277 278 279 279 282 283 287

PAGE 6

© PROJECTPRO CORP.

Forecasting Programs

Publishing Notice

Fragmented Traditional Critical Paths in all Schedules PathsPro for Resource-Constrained Programs Creating and Comparing Multiple Scenarios Comparing the Three Scenarios (Interim Plans) Optimizing the Program Critical Path

287 289 292 293 294

Chapter 9 Reporting on Large Schedules Learning Objectives The Challenges of Reporting on Large Programs Multiple Breakdown Orientations in your PWBS What Breakdown Structures Do You Need? How to Create Multiple Breakdown Orientations in MS Project? Overview: Single-Page Reports in Large Programs 1. Create Tracking-Gantt-like Progress Bars for Projects 2. Major Milestone View Major Milestone View with Filter Exercise: Create a Major Milestones View for the Intranet Program Major Milestones Replicated at the Top of the Program Schedule? Views Format, Bar Styles Dialog Format, Text Styles Dialog Major Milestones View 3. Using Advanced, Custom Filters Some Useful Standard Filters Filters that Use Multiple Fields and Criteria Interactive Filters 4. MS Project Timeline view 5. Swim Lane Chart 6. Earned Value Report Exercise: The Concept of Earned Value Creating Earned Value Charts with MS Project’s Visual Reports Issues with Microsoft Project’s Earned Value Calculations Earned Value Add-Ins and Software Applications

297 297 299 299 301 301 302 303 305 306 308 309 310 311 314 316 318 318 318 320 321 322 324 326 326 329 330

Chapter 10 Monitoring Progress in Projects of a Program Learning Objectives Program Manager’s Responsibility Task Update versus Assignments Update Update Tasks If… Update Assignments If… How Gantt Chart-Literate Are You? Competitors, On Your Mark … Getting at the Truth of a Project

333 333 335 335 338 338 339 342 344

© PROJECTPRO CORP.

PAGE 7

i

Publishing Notice Back in the Executive Boardroom... Exercise 1: What is the Performance of this Program? Exercise 2: Is this Program Schedule Up-To-Date?

Forecasting Programs 345 346 347

Chapter 11 Summary Program Management Scheduling Approach Agile and Critical Path Method (CPM) Organizing the Program Consolidating Projects Linking Projects Sharing Resources Optimizing Reporting Monitoring Closing

349 351 351 353 354 358 358 359 360 360 362 362

Index

363

PAGE 8

© PROJECTPRO CORP.

Forecasting Programs

Publishing Notice

Dedication I dedicate this book to my late father, Toon Uyttewaal, and mother, An Uyttewaal - van Bentum, who passed away in The Netherlands this year at age 97. They taught me the values of working hard, speaking up and aging gracefully.

© PROJECTPRO CORP.

PAGE 9

i

Publishing Notice

Forecasting Programs

Acknowledgements Co-writers: ◆ Erik van Hurck co-wrote the section “What Resources to Create in your Shared Resource Pool?” in chapter 7. Erik is senior PPM consultant and blogger at: www.TheProjectCornerBlog.com. We published that section in the MPUG newsletter as well. Technical Editors: ◆ Angelo Arcoleo edited the entire book: Your vast experience in aerospace programs shines through in several places in this book. You edited the chapter Choosing the Best Scheduling Approach in depth and came up with the great idea to call the matrix of recommendations the ‘PIC-matrix’, among many other things. Thanks for allowing me to pick your great brain. ◆ Michael Wharton has edited most of my books; Thank you for your continued support of my work! Michael tried out and improved the hands-on exercises. Thank you! ◆ B. Sai Prasad: You caught many little errors and provided many extra sources with great information along with a great perspective from the other side of the globe; thank you! ◆ Brian Journeaux: Your sharp observations have made the big picture of this book better! Thank you! ◆ David Peyton: Your examples and corrections have made this book better! ◆ Oliver Gildersleeve: Your candor and emphatic debate on some topics have forced me to sharpen my thinking and statements in many places. Thank you! ◆ Prof. Kurt Gering: Glad to see you are professor now, which has everything to do with your capability for observing sharply. Thank you for sticking with me! ◆ Christine Flora: Sharp as a whip and very knowledgeable about the ‘dark and deep side’ of Microsoft Project, I am privileged to have you on my team! ◆ Matt Piazza: Your extensive work experiences in the defense industry and your willingness to share have truly enriched this book! ◆ Aviva Carmen: Your unfettered and continued support is wonderful and your contributions, now from the inside of Microsoft, were very useful! ◆ Daniel Zitter: Your international perspective and intimate knowledge of project and program management have enriched this book; thank you! ◆ Gord Schmidt: Wish I had more time slices from you between your continuous consulting gigs … in the few you could find, you caught some technical errors! Thank you!

PAGE 10

© PROJECTPRO CORP.

Forecasting Programs

Publishing Notice

◆ Jim Kienhofer: You are a seasoned program management consultant and I certainly wished I could have had more time slices from you, because your contributions were insightful and from many different programs! Thank you! ◆ Al Rusnak edited the Choosing the Best Scheduling Approach chapter in depth. ◆ Ralph Kuhn, P. Eng, PMP, PMI-SP, edited the Agile OR Critical Path - Agile AND Critical Path chapter in depth as well as several other chapters. Then I lost you to your new job … ◆ Larry Christofaro: You have so much work experience in programs and contributed many important things to the book, such as that it should refer to ‘project’ instead of ‘subproject’. Thanks! Language, Graphics and Cartoons: ◆ Barbara Petoskey edited my poor English-as-a-Second-Language again. She pointed out that, Actual Resources need Actual Food!, which shows how far she reached in meeting my deadlines! ◆ Kandoth Abdulla Abdulader designed the front cover and did an amazing job while being patient with my demanding requests. ◆ Paul Mason made me laugh again and lighten up in my fights with technical details whenever a new batch of cartoon drafts arrived in my inbox! Thank you for your loyal support!

© PROJECTPRO CORP.

PAGE 11

i

Publishing Notice

Forecasting Programs

ProjectPro Consulting ProjectPro specializes in the following situations: 1. Scheduling of Programs (with many links between projects) 2. Schedule improvement and raising scheduling maturity 3. Project Server and Project Online Implementations

ProjectPro Training Below, you will find the courses that we offer at our company, ProjectPro Corp.:

We have three courses for people who use MS Project as a standalone tool. They are on the left. Our Project server courses are entirely role-based; you will find a course for each role in a Project Server environment. We will discuss each course in a bit more detail starting from the left column to the right: ◆ Fundamentals of Microsoft Project (Fundamentals) This 2-day course is for new users of Project who want to get started planning their projects in Project. The overall objective of the course is to make participants feel comfortable using MS Project. PAGE 12

© PROJECTPRO CORP.

Forecasting Programs

Publishing Notice

◆ Forecast Scheduling with Microsoft Project (Forecast Scheduling) This 2-day workshop is designed to check-up on your day-to-day scheduling to ensure that you are using the best practices of scheduling with Project. The overall goal of the course is to realize the most benefit from using the tool. ◆ Forecasting Programs This 2-day workshop will prepare program managers, their project managers and support staff for managing programs with MS Project as a standalone tool. ◆ Managing Tasks in Project Web App (Managing Tasks in PWA) This 0.5-day course prepares project team members to manage their tasks and workloads effectively in a Project Online / Project Server environment. ◆ Managing Projects with Project Online / Project Server (Managing Projects) This 3-day course prepares project managers to manage their projects effectively in a Project Online / Project Server environment. It contains the entire Forecast Scheduling course and then the extra things project managers need to know in a Project Online / Project Server environment. ◆ Managing Programs with Project Online / Project Server (Managing Programs) This 2-day course prepares program managers to effectively manage, in a Project Online / Project Server environment, their large projects that need to be broken down into subprojects. This course contains the entire Forecasting Programs course and some extra things people need to know in a Project Online / Project Server environment. ◆ Managing Resources with Project Online / Project Server (Managing Resources) This 2-day course prepares resource managers to effectively manage their resources in a Project Online / Project Server environment. ◆ Managing Portfolios with Project Online / Project Server and Portfolio Server (Managing Portfolios) This 2-day course prepares project portfolio managers and their support staff for managing their portfolio more effectively with the Microsoft enterprise project management tools. ◆ Monitoring Projects, Programs, Portfolios in Project Online / Project Server (Monitoring Projects, Programs, Portfolios) This 0.5-day course prepares executives and sponsors to effectively monitor their project portfolios in a Project Online / Project Server environment.

© PROJECTPRO CORP.

PAGE 13

i

Publishing Notice

Forecasting Programs

ProjectPro Products Textbooks: ◆ Forecasting Programs ◆ Forecast Scheduling with Microsoft Project 2010/2013 ◆ Dynamic Scheduling with Microsoft Project 2000/2002/2003 Add-in applications for Microsoft Project: ◆ Forecast Scheduling App This add-in application complements the book Forecast Scheduling. It automates 60% of the checks that Eric describes in his Forecast Scheduling book and it also greatly assists in performing the remaining manual checks. This tool allows project managers to improve their schedule quickly; it allows PMOs to switch from auditing to enabling / empowering. ◆ PathsPro An add-in that resolves all the problems experienced while finding the Critical Path. It can even find the Resource-Critical Path in a resource-constrained project schedule, as well as the Program Critical Path in an IMS (Integrated Master Schedule). It makes Microsoft Project compliant with the Critical Path 2.0 Standard. ◆ CrossLinksPro An add-in that extends Microsoft Project’s out-of-the-box capacity to handle few cross-project dependencies (i.e., a 1,000-task program) dramatically: CrossLinksPro is used in larger programs of up to 30,000 tasks with 1,500 cross-project links. ◆ CurvesPro An add-in that corrects the errors in Microsoft Project’s Earned Value calculations, creates the S-curve charts, and forecasts the EAC and the project duration (optimistically and pessimistically). It can also produce ‘Earned Work’ charts, an innovation from ProjectPro Corp.

PAGE 14

© PROJECTPRO CORP.

Forecasting Programs

About this Book

About this Book The Author and Program Management Many authors, like Prof. Kathleen Hass for example, seem to think that programs are much more complex than projects. I think, as the author of this book, that programs are inherently NOT more complex than projects, they are just on a higher level of abstraction: ◆ The deliverables in a project are like projects in a program. ◆ Dependencies between activities within a project are now dependencies between projects. ◆ Project ‘objectives’ are called ‘strategic benefits’ in programs and directly relate to corporate strategy. Also, stakeholders are smarter and more assertive in programs. Budgets are much larger. So, programs are definitely more difficult to manage than projects, but programs are not inherently more complex than projects. Program managers who try managing a program like a project are doomed to fail: Program management has its own techniques and tools. So, what are these tools? That is what this book is about! There are now tools for program managers that model the complexity, the interdependency and make them visible, which makes programs more like projects. A lot of the perceived complexity of programs comes from the interdependencies between the projects. We provide in this book a tool to model them as well as a manual technique and an automated tool to find the Program Critical Path. Armed with these specialized tools, the program manager can now have the confidence to keep the program on track. Too many program managers become monthly-messengers-of-bad-news (further slippages and overruns). With the techniques and tools presented in this book, program managers can manage expectations in a more timely fashion at a minimum, and … perhaps even turn into monthly-messengers-of-good-news. The author has been involved as a consultant and trainer in many programs across the world: most notably: ◆ Canadian Forces Supply System Upgrade Program (CFSSU), ◆ IBM Cognos: Business Intelligence (BI) Suite release program, ◆ Northrop Grumman airplane upgrade program, ◆ SanDisk new product development programs for flash-memory products, ◆ Investors Group business transformation program.

© PROJECTPRO CORP.

PAGE 15

i

About this Book

Forecasting Programs

In 1997, he was President of the Ottawa Chapter of PMI, currently serving over 2,000 members. From 2001 until 2004, he served as president of the MPUG-Ottawa chapter. In 2012, Eric received an award from MPUG for his leadership in the Microsoft Project community. From 2010 up to 2017, Microsoft has designated him Most Valuable Professional (‘MVP Project’) in project and portfolio management applications. In 2009, Eric received an award from PMI for his ‘Significant Contribution to the Scheduling Profession’.

Learning Objectives of this Textbook This book is aligned with the following standards from PMI: ◆ PMBOK-Guide®, 6th Edition, 2017 ◆ The Standard for Program Management, 4th Edition, 2017 After reading this book, you will: ◆ Choose the right scheduling approach for your program ◆ Know how to integrate multiple scheduling approaches (if you must mix them), while keeping a single master schedule ◆ Choose the best orientation to break a program schedule down into project schedules ◆ Determine whether to keep one large schedule for the program or split it into sub schedules ◆ Integrate project schedules into an integrated master schedule for the program ◆ Create and monitor dependencies between the project schedules ◆ Identify and optimize the Program Critical Path into any major milestone ◆ Be aware of reporting techniques that create one-page reports for the entire program ◆ Monitor and manage the progress of the projects during the program execution phase This book assumes that you already have a solid working knowledge of MS Project in single projects; you should be able to schedule a project and optimize the schedule with MS Project. In this book, you will be addressed as a program manager. A program manager typically manages several project managers. A program manager deals with different types of questions than a project manager. A program manager typically is concerned with questions like: What scheduling guidelines do I need to give my project managers? How can I roll up all schedules into a master schedule for the program? How can I model cross-project dependencies? How can I find the Program Critical Path? These questions will be discussed in this book, and others. PAGE 16

© PROJECTPRO CORP.

Forecasting Programs

About this Book

Target Group and Assumptions in this Book We will assume you are a program manager (even if you aren’t right now). When we use the word ‘You’ in this book, we address you as if you were a program manager. By default, we will assume that you simply use a central file server on which you save the project schedules and program schedules. We will assume you do not have either Project Server or Project Online, unless we explicitly state that you need it for the topics discussed or a procedure provided. This book will cover all versions of Microsoft Project from 2010 and up. We have marked when a feature was added in the later releases of 2013 and 2016. Microsoft has not made many changes for program managers in the last decade. Hopefully, we will see more in the future …

Conventions in This Book Conventions in This Manual Symbols and Font Style Tip► This marker shows a tip or recommendation to the user. It may be a time saver or a way of achieving better project control information. Trap! This trap marker shows a warning to the user of Project 2013. Heeding the warnings may keep you out of trouble and avoid unexpected results, loss of data or quirks in Project 2013. Pro The Pro marker indicates that these features are only available in the Professional Edition of any version of MS Project. 2016 This marker indicates that the feature is new in the Project 2016 release, in the Project Standard 2016, the Project Professional 2016 edition and the cloud-edition Project Online Desktop Client. If you are upgrading to Project 2016 from Project 2013 and just want to focus on new features, look for this marker. 2016 Pro This marker indicates the features that are new in only the professional edition of Microsoft Project Professional 2016 and Project Online Desktop Client. © PROJECTPRO CORP.

PAGE 17

i

About this Book

Forecasting Programs

2013 This marker indicates that the feature is new in the Project 2013 release, in the Project Standard 2013, the Project Professional 2013 edition and the Project Online Desktop Client edition. 2013 Pro This marker indicates the features that are new in only the professional edition of Microsoft Project Professional 2013 and Project Online Desktop Client. 2010 The 2010 marker indicates that the feature is new in the Project 2010 release;

we have kept these for people upgrading from 2007. 2010 Pro The 2010 Pro marker indicates the features that are new in the Microsoft Project Professional 2010 edition; we have kept these for people upgrading from 2007.

File Words in bold type can literally be found on your screen in MS Project – either as a ribbon button or as a label or phrase in a dialog box. Quote Italicized words are literal references. These can be literal quotes from other books, from other people, data you literally need to enter into MS Project or literal words from the index at the back of the book. The indexed keywords are italicized so that you can find them easily in the text. Any text enclosed within the arrow brackets is text that should not be taken literally, because it refers to another thing. For example, refers to the name of the project file.

Word Choice in Procedural Steps You will notice I use the words MS Project and Project 2016 often. I typically use the term MS Project when the feature was already available in previous releases. I use the term Project 2016 only when it is a feature that is new in Microsoft Project 2016. We have followed very rigid guidelines for formulating the step-by-step instructions. We want them to be as clear and consistent as possible. We know it is difficult enough to interpret technical books and consistency helps. These guidelines are: ◆ To display a ribbon, we always use the verb “Click” as in: Click ribbon File. ◆ For buttons on the ribbons and in dialog boxes, we always use the verb “Click” as in: Click button Save. ◆ For tab pages in dialog boxes, we always use the verb “Click” with the name of the tab as in: Click tab Advanced (in the ribbon File, item Options dialog) PAGE 18

© PROJECTPRO CORP.

Forecasting Programs

About this Book

◆ For a single keystroke on your keyboard, we always use verb “Press” as in Press . ◆ For shortcut key combinations on your keyboard, we use the verb “Hold down” for the first key(s) and “Press” for the last one:  For two keystrokes: Hold down and press .  For three keystrokes: Hold down + and press . ◆ For entering text with your keyboard into fields that have a name, we always use “Key in” as in: Key in the name of the file in field File Name. ◆ For check boxes that are checked or not and where the user can choose one or more, we always use verb “Select” to put a checkmark in the square or “Clear” to remove it. We display the resulting check box as in: Select  Display Help on Startup Clear  Display Help on Startup ◆ For radio buttons where the user must choose only one option from two or more, mutually-exclusive options, we always use the verb “Select” and display the resulting radio button as in: Select  Automatic.

Types of Slides in Our Training Slide Deck The slides come in different kinds. The words in CAPITALS are the first words that you will find in the title of the slide. We added these words to make the intention we have with each slide clear upfront. ◆ REVIEW slides may be presented; we will assume that you know many of those points and will just ask review questions. ◆ Where appropriate an OVERVIEW slide is shown that lists the next topics to be discussed. ◆ Where appropriate a SUMMARY slide is inserted to summarize what was presented. These slides are the same as the overview slides and are therefore not repeated in the book to save some trees. ◆ When the instructor is supposed to demonstrate features in MS Project, DEMO slides are inserted. Participants can sit back and relax and watch the show. These slides are not printed in the book. ◆ After a demonstration, a self-paced exercise often follows, these are called DO-IT. The Do-Its pose a challenge to the students to try out the demonstrated feature on their own. These slides are not printed in the book. ◆ Where appropriate a DISCUSS slide may be introduced to initiate a discussion. ◆ UNDOCUMENTED features are slides that show handy shortcuts only a few people know. To keep them undocumented, they are not printed in the book. These slides have a bright yellow background color that will wake you up in time to take a note. © PROJECTPRO CORP.

PAGE 19

i

About this Book

PAGE 20

Forecasting Programs

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

1

Chapter 1 Program Management

Learning Objectives After this chapter, you will: ◆ Know what a ‘program’ is and how it differs from a ‘project’ and ‘portfolio’ ◆ Know the responsibilities of a program manager, project manager and program support staff ◆ Know the program management process groups (PMI) ◆ Know what a Program Work Breakdown Structure (PWBS or WBS) is ◆ Be aware of considerations to use Project Server or Project Online for your program

© PROJECTPRO CORP.

PAGE 21

Chapter 1 Program Management

Forecasting Programs

An Airplane is 30,000 Parts Flying in Close Formation Bob and Nob are sitting down for coffee. “Bob, how many activities do you have in your program?” “About 30,000 at the moment. Why do you ask?” “How do you coordinate all these activities?” “We created 20 projects in our program with 1,500 activities each on average. The largest has 2,000 activities. I hired solid project managers to take care of those projects. I try not to worry about these projects any longer. I focus on the interfaces between the projects instead.” “What do you mean by ‘interfaces’?” “Oh, these interfaces are dependencies between the projects, typically where something needs to be handed off by one project manager to another. Some people call them handoffs.” This fuels Nob’s curiosity: “How many handoffs do you have?”. “We’re in the process of finding them, but we have about 1,000 at the moment.” “If a front-end project slips, how does this flow through all other projects to the back-end project? If your ‘design’ project slips, how do you know if the ‘integration’ project is affected and by how much? “We purchased a specialized piece of software to create the handoff dependencies in the master schedule when we need them, so we can see where the impact flows through the program!” Bob states with some muted pride in his voice. “And … all that works for you?” Nob asks. “All good so far. You know the saying: An airplane is 30,000 parts flying in close formation? Well: A program is 30,000 tasks performed in close coordination!” PAGE 22

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

Definitions

1

What is a ‘Project’? PMI defines a project in the PMBOK-Guide 6th Edition as: A Project is a temporary endeavor undertaken to create a unique product, service or result. To differentiate a project more clearly from a program and portfolio, we would like to present a modified definition: A project is a set of related activities and deliverables that produce a unique product, service or result.

What is a ‘Program’? A program is: Related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually. 1 There are often dependencies between the projects of a program. The schedule of the program is an integrated program schedule or integrated master schedule (IMS). The latter term IMS seems to have gained popularity in the last few years, perhaps because the program schedule and project schedules have a parent-child relationship: ◆ Changes can be driven down from the program into the project schedules (i.e., optimizations of the Program Critical Path). ◆ Updates in the project schedules roll-up into the master schedule. Throughout this book we will use the term ‘master schedule’ to represent a parent schedule in a parent-child relationship between program schedules and project schedules. Projects can be integrated into a program for a variety of reasons, including: ◆ A need for overall reporting on all projects (program-level reporting): performance, risks, issues and decisions needed

1

The Standard for Program Management, Fourth Edition, PMI, Newtown Square, 2017

© PROJECTPRO CORP.

PAGE 23

Chapter 1 Program Management

Forecasting Programs

◆ A need to model the logical impacts each project has on other projects in the program (cross-project dependencies) ◆ A need to identify the Critical Path across the projects into any one of the major milestones in the program. ◆ A need to monitor resource allocation and utilization when several projects share the same group of resources. When resources are shared, projects will impact each other whenever resources are not available at the time they are needed. Notice that the term ‘program’ is NOT used in this book in the meaning of: ◆ A computer application People in the IT industry use the term program to refer to computer software applications. ◆ Government-subsidized policy vehicle to bring about change in society Government and related agencies use the term program to refer to their initiatives.

What is a ‘Portfolio’? Portfolios are a set of projects and programs that relate to each other by sharing the same pool of dedicated resources: financial, human, facilities, equipment, material or land resources, apart from centrally shared, corporate resources, like HR and Finance. The financial resources can be: budgets, funding, bonds, stocks, loans, mortgages or other vehicles to finance initiatives. The human resources can be: employees, consultants, vendors, contractors and any other people who sell their time for money. Facilities can be: plants, malls, etc. When portfolios are based on equipment, this equipment is often very specialized, such as the test roads for car safety tests, nuclear test labs, etc. When portfolios are based on materials, the companies would often be mining companies. When portfolios are based on land resources, they are geographically organized, like Parks Canada. PMI uses the following definition: A portfolio is a collection of projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives. 2 A portfolio of projects is always supposed to support realizing the strategy of the organization. With portfolio management you optimize the mix of projects to execute given the scarce resources of the organization while maximizing the realization of the strategy. The word ‘portfolio’ is best known from the financial world of stocks, bonds and other investment products: ‘your investment portfolio’ as opposed to a ‘project portfolio’. In 2

The Standard for Program Management, Fourth Edition, PMI, Newtown Square, 2017

PAGE 24

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

this book however, we will use the word solely in the context of project management: When you see the word ‘portfolio’ in this book, you should always interpret this as ‘project portfolio’ and we will omit the word ‘project’ from here on. Portfolios can contain the following components: 3 ◆ programs (integrated program schedules), ◆ projects, ◆ other related work, often support tasks, like administration, quality control or secretarial services. A portfolio reflects investments made or planned by an organization to realize the strategy of the organization. In conclusion, a portfolio is not the same as: ◆ A collection of projects only; a portfolio can have programs and other related work side-by-side with projects. ◆ A financial investment portfolio containing stocks, bonds, etc.

Differences between Project, Program and Portfolio A single project, a program and a portfolio have the following differences: 4 Scope

3 4

Project Projects have defined objectives. Scope is progressively elaborated throughout the project life cycle.

Program Programs have a scope that encompasses the scopes of its program components. Programs produce benefits to an organization by ensuring that the outputs and outcomes of program components are delivered in a coordinated and complementary manner.

Portfolio Portfolios have an organizational scope that changes with the strategic objectives of the organization.

The Standard for Portfolio Management, Second Edition, PMI, Newtown Square, 2013 The Standard for Program Management, 4th Edition, PMI, Newtown Square, 2017

© PROJECTPRO CORP.

PAGE 25

1

Chapter 1 Program Management Change

Project Project managers expect change and implement processes to keep change managed and controlled.

Planning

Project managers progressively elaborate highlevel information into detailed plans throughout the project life cycle.

Management

Project managers manage the project team to meet the project objectives.

Monitoring

Project managers monitor the work of producing the products, services, or results the project was undertaken for.

PAGE 26

Forecasting Programs Program Programs are managed in a manner that accepts and adapts to change as necessary to optimize the delivery of benefits as the program’s components deliver outcomes and/or outputs. Programs are managed using high-level plans that track the interdependencies and progress of program components. Program plans are also used to guide planning at the component level. Programs are managed by program managers who ensure that program benefits are delivered as expected, by coordinating the activities of a program’s components. Program managers monitor the progress of program components to ensure the overall goals, schedules, budget, and benefits of the program will be met.

Portfolio Portfolio managers continuously monitor changes in the broader internal and external environments

Portfolio managers create and maintain necessary processes and communication relative to the aggregate portfolio.

Portfolio managers may manage or coordinate portfolio management staff, or program and project staff that may have reporting responsibilities into the aggregate portfolio. Portfolio managers monitor strategic changes and aggregate resource allocation, performance results, and risk of the portfolio.

© PROJECTPRO CORP.

Forecasting Programs Success

Project Success is measured by product and project quality, timeliness, budget compliance, and degree of customer satisfaction.

Chapter 1 Program Management Program A program’s success is measured by the program’s ability to deliver its intended benefits to an organization, and by the program’s efficiency and effectiveness in delivering those benefits.

Portfolio Success is measured in terms of the aggregate investment performance and benefit realization of the portfolio.

In addition to the differences as outlined by PMI, we would like to suggest the following differences: Project Program Portfolio CompoConsists of one Consists of multiple Consists of multiple nents project projects projects/programs, as well as other operations Focus Delivering the Realizing the Executing the project’s product, benefits sought by strategy service or result the organization ObjecOften has a Often one or more Many different tives single objective related objectives objectives that may even be contradictory DuraDuration shortest Duration longer Duration indefinite tion Finite Has finite end Programs have a No finite end (the 5 End? organization lives finite end on)

5

The Standard for Program Management, Fourth Edition, PMI, Newtown Square, 2017 This edition of the standard, unlike all previous editions, is finally explicit that a program has a finite end. All projects in a program will end, and therefore the program will end as well. In practice, we see two types of programs: Build programs and Operational programs. Build programs, in which something new is built, are finite. Operational programs are indefinite. For example, a government unemployment insurance program needs software built to support it, which is a finite build program. The sending of unemployment insurance checks is an operational program and indefinite. The ‘operational programs’ are not any longer ‘programs’ under the definition of the 4th edition. © PROJECTPRO CORP.

PAGE 27

1

Chapter 1 Program Management Number of Levels in the team Leadership Focus Leadership Output

Usually 2 levels, sometimes 3: project manager, team leaders, team members Focuses on deliverables to meet the success criteria. Team motivation and efforts

Forecasting Programs At least 3 levels: program manager, project managers, team members, but often more than 3. Focuses on realizing benefits for the organization.

At least 4: Portfolio manager, program managers project managers, and team members Focuses on realizing the strategy of the organization.

Benefits to the organization

Ranking of projects and programs realizing the corporate strategy: insight and synthesis

Responsibilities and Skills of a Program Manager In this book, I will address you as the program manager. You have several project managers working for you. Project managers create project schedules, and you receive them from your project managers. As program managers, you are responsible for: ◆ Developing project governance processes and performance metrics ◆ Training on program processes as well as adherence to these processes ◆ Ensuring program objectives are met and benefits realized ◆ Ensuring quality standards of work products/deliverables are met ◆ Identifying and managing the stakeholders in the program ◆ Breaking down a program into projects ◆ Selecting the project managers for the projects in the program ◆ Leading and managing the project managers ◆ Integrating project schedules into a program schedule ◆ Monitoring the transfer of deliverables between projects (cross-project dependencies) ◆ Monitoring and managing the conflicts between all parties in the program ◆ Managing the allocation of resources to the projects ◆ Addressing over-allocations of resources across the projects ◆ Identifying, managing and monitoring the risks and issues of the program ◆ Receiving and processing qualified change requests ◆ Reporting on the program (including all its projects) ◆ Forecasting the program and communicating the forecasts to the stakeholders ◆ Approving deliverables prior to release to the customer

PAGE 28

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

PMI accredits program managers; program managers can attain the Program Management Professional (PgMP) credential from PMI and add the PgMP suffix behind their name. The PMI defines program management ‘work experience’ for attaining the PgMP certification as follows: 6 ◆ Be responsible and accountable for the coordinated management of multiple related projects directed toward strategic business and other organizational objectives. ◆ Build credibility, establish rapport, and maintain communication with stakeholders at multiple levels, including those external to the organization. ◆ Define and initiate projects, and assign project managers to manage cost, schedule, and performance of component projects, while working to ensure the ultimate success and acceptance of the program. ◆ Maintain continuous alignment of program scope with strategic business objectives using benefits realization, and make recommendations to modify the program to enhance effectiveness to achieve the business result or strategic intent. ◆ Be responsible for determining and coordinating the sharing of resources among their constituent projects to the overall benefit of the program. PMI describes program ‘work experience’ in more detail on the web pages where aspiring PgMPs substantiate their work experience in term of actual hours in each of the following five categories: 1. Strategic Program Management Perform an initial program assessment defining the program objectives; ensure program alignment; establish a high-level road map; define the high-level road map/framework; define the program mission statement; evaluate the organization’s capability; develop, validate, and assess the program objectives; identify organizational benefits; estimate the high-level benefits, drive prioritization of projects; evaluate program objectives; obtain organizational leadership approval; identify and evaluate integration opportunities; and exploit strategic opportunities for change. 2. Program Life Cycle  Sub-domain 1: Initiating the Program Develop program charter; translate strategic objectives; create a program scope description; develop an accountability matrix; define standard measurement criteria; monitor and control the program; conduct program kick-off with key stakeholders.  Sub-domain 2: Planning the Program Develop a detailed program scope statement; develop program WBS; establish the program management plan and schedule; optimize the program management 6

See ‘PMI Program Management Professional (PgMP) Handbook’ from the site: certification.pmi.org © PROJECTPRO CORP.

PAGE 29

1

Chapter 1 Program Management

Forecasting Programs

plan; define project management information system (PMIS); identify and manage unresolved project level issues; develop the transition/integration/closure plan; develop key performance indicators (KPIs); monitor key human resources; negotiate contracts.  Sub-domain 3: Executing Execute the Program Charter and initiate constituent projects; establish consistency; establish a communication feedback process; capture lessons learned; lead human resource functions; improve team engagement and achieve commitment; review project managers’ performance; execute the appropriate program management plans; consolidate project and program data; evaluate the program’s status; approve closure of constituent projects; ensure scope is compliant.  Sub-domain 4: Controlling Control the Program Analyze variances and trends; update program plans; manage program level issues by identifying and selecting a course of action; manage changes; conduct impact assessments, recommend decisions, and obtain approval; manage risk.  Sub-domain 5: Closing the Program Complete a program performance analysis report, determine program performance; obtain stakeholder approval, initiate close-out activities; execute the transition and/or close-out of all program and constitute project plans; conduct the post-review meeting; report lessons learned. 3. Benefits Management Develop the benefits realization plan; identify and capture synergies and efficiencies; communicate the benefits realization plan; develop a sustainment plan; monitor the metrics; take corrective actions; verify close, transition, and integration of constituent projects vs. criteria; maintain the benefits register; record program progress; analyze and update the benefits realization and sustainment plans; develop a transition plan to operations. 4. Stakeholder Management Identify stakeholders; create the stakeholder matrix; perform stakeholder analysis; create the stakeholder management plan; negotiate the support of stakeholders; set clear expectations and acceptance criteria; generate and maintain visibility; confirm stakeholder support; define and maintain communications; evaluate risks and incorporate them in the program risk management plan; develop and foster relationships with stakeholders. 5. Governance Develop program and project management standards and structure; select a governance model structure; obtain authorization(s) and approval(s); evaluate key performance indicators; develop and/or utilize the program management information PAGE 30

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

system (PMIS); integrate processes; evaluate risks regularly; establish escalation policies and procedures; develop and/or contribute to information repository; identify and apply lessons learned; monitor the business environment, program functionality requirements, and benefits realization; develop/support the program integration management plan. PMI always performs a detailed Role Delineation Study in support of each credential they offer, so this is what program managers do in practice.

Responsibilities of Other Roles There are other roles associated with programs: ◆ Project managers The program manager assigns a competent project manager to each project. In some cases, one person can be assigned to multiple projects, or the project managers could come from external vendors. The responsibilities of the project managers in a program are (in addition to what the PMBOK-Guide® 6th edition lists as project manager’s responsibilities (see page 54 and following in that Guide):  Understand what benefits are realized by the program and by their project in particular  Break down the work for the project using the high-level PWBS received from the program manager as a starting point  Schedule the project  Recruit the project (team leaders and) team members  Help identify the cross-project dependencies with other projects (interdependencies)  Monitor and manage these interdependencies  Contribute to the risks and issues register for the program, understand how risks and issues impact their project, mitigate risks and issues ◆ Subproject managers (‘control account manager’, ‘deliverable lead’, ‘team leaders’) If a project is further subdivided into subprojects, there is need for subproject managers, though they will definitely not be called that, but rather team leaders or something similar. The subproject managers often come from external vendors or consultants. The responsibilities of subproject managers are very similar to those of project managers just on a subset of the project’s scope (see previous bullet). ◆ Program support staff or Program Support Office (PSO) Since a program is often large and the reporting is challenging, the program manager often needs support staff, often called Program Support Office (PSO) or Program Management Office (PMO). We prefer the former term PSO, because the latter PMO

© PROJECTPRO CORP.

PAGE 31

1

Chapter 1 Program Management

Forecasting Programs

could easily be confused with the more commonly used term Project Management Office (PMO). The PSO is typically responsible for:  Defining program management processes and procedures for program governance  Benefits Realization Analysis  Schedule analysis: ▪ Maintaining the integrated master schedule (IMS) / program schedule ▪ Imposing the scheduling standard for the projects in the program ▪ Checking project schedules against the scheduling standard ▪ Organizing the weekly (/monthly/quarterly) progress reporting by project managers ▪ Integrating the master schedule for the program ▪ Analyzing the workloads and resolving over-allocations ▪ Identifying the Program Critical Path or Program Resource-Critical Path ▪ Optimizing the Program Critical Path or Program Resource-Critical Path  Cost Analysis: ▪ Retrieving the actual expenses from accounting ▪ Checking the actual expenses for the program against the program budget (cost analysis) ▪ Creating the cost reports ▪ Making cost projections ▪ Optimizing the future expenses  Risk analysis: ▪ Identifying the risks and issues ▪ Qualifying and quantifying the risks ▪ Ranking the risks ▪ Creating the risk reports  Support program communications: ▪ Creating Integrated Master Schedule (IMS) reports for Schedule and Cost ▪ Creating and disseminating reports to all program stakeholders ▪ Assisting the program manager in presenting reports to program sponsor and/or clients ▪ Assisting the program manager in communicating results back to project managers

PAGE 32

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

Program Life Cycle Phases

1

In The Standard for Program Management, 4th Edition, introduces the following program life-cycle phases:

In parallel with these process groups, the Standard distinguishes the following activities of benefits management: ◆ Benefits Identification:  Identify and qualify benefits ◆ Benefits Analysis & Planning:  Define and prioritize benefits  Derive benefits metrics  Establish benefits management plan  Map benefits into program management plan ◆ Benefits Delivery:  Monitor components  Maintain benefits register  Report benefits ◆ Benefits Transition:  Consolidate coordinated benefits  Transfer the ongoing responsibilities ◆ Benefits Sustainment © PROJECTPRO CORP.

PAGE 33

Chapter 1 Program Management

Forecasting Programs

Integrated Program Management Information System

The illustration shows the ideal organization with all information systems integrated. Data is never inputted twice and seamlessly flows across the boundaries of each information system to whichever other system needs that data. The program managers can easily retrieve the resource rates from the information system of the HR department. The Informatics department provides user lists needed in a timely fashion. Facility management makes the facilities needed by the program available in the amount needed and when needed. Reservation of facilities is tracked. The program manager can see from the marketing information system at any time what deadlines Marketing has planned or announced for each product or service and can adjust their schedule accordingly. Lastly, program managers can verify in real time in the finance information system that they will have funds available to make their next commitments in their programs. So long for the ideal management information system …

PAGE 34

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

Project Server or Project Online?

1

By default, we will assume you do not have either Project Server or Project Online unless we explicitly state that you need one of these in that section or chapter for the topics discussed. By default, we will assume that you simply use a central file server on which you save all your project schedules and the program schedule. We will explore in this section, though, what Project Server or Project Online could add in terms of benefits. Project Server is Microsoft’s on-premise PPM-tool (Project Portfolio Management). Project Online is the same tool, but it resides in the cloud (like Office 365 being the cloud-based version of Microsoft Office). The ‘cloud’ is the collection of data centers of software companies, like Microsoft, that offer software subscription services to clients on servers running in those data centers. Project Online uses a database in one of the data centers Microsoft has built around the world.

What is Project Server, Project Online and Project Web App? Project Server and Project Online are Microsoft software offerings that allow organizations to perform PPM) in addition to the scheduling with MS Project. Project Web App (PWA) is an internet-based application that runs inside Internet Explorer (and other browsers) and provides front-end application for Project Server and Project Online. Project Server acts as middleware and leverages several Microsoft client and server applications (often referred to as the Microsoft stack) to provide an integrated platform for managing Projects, Programs and Portfolios, including: ◆ MS Project, for project scheduling, ◆ MS Outlook, for email, calendar, task and contact management, ◆ MS Excel, for further interactive analytics of reports and views, and, of course, for budgeting and other calculations that can be published through PWA, ◆ Internet Explorer, as a host for PWA (and for Internet browsing), ◆ SQL Server Database Server, the database back-end where the schedule data are stored, ◆ SQL Server Analysis Server, the data-cube builder for SQL Server and data analysis interface, © PROJECTPRO CORP.

PAGE 35

Chapter 1 Program Management

Forecasting Programs

◆ SQL Server Reporting Services, the report development application for SQL Server, ◆ Windows SharePoint Server, the engine that creates the Project Sites (risks register, issues register, document library, etc.). Since 2016 PWA is now an application that is part of and running inside SharePoint. ◆ Web Server, the engine that puts web pages together, and, ◆ 2016 Power BI, a new tool that allows creation of modern reports with attractive charts in drag-and-drop fashion. Tip► However, Project Server and Project Online are more than just a postal service handling letters and packages (i.e., assignments) back and forth between people (i.e., roles or individuals) across geographical boundaries (i.e., across applications).

Project Server / Project Online and PPM Pro Microsoft Project Professional can save projects in a central database, called Project Server or Project Online to support implementation of Project Portfolio Management (PPM). MS Project Professional is needed if you want to use MS Project with Project Server (on-premise) or Project Online (cloud-based subscription product). Microsoft Project Standard will not work with Project Server or Project Online.

PPM aims to effectively manage portfolios, resources, programs and projects within an organization. The vision of Project Portfolio Management is that: ◆ The organization ensures that it spends its finite resources on those projects that contribute most to the realization of the corporate business strategy. For privately held companies, this is normally the highest return on investment (ROI). The organization carefully evaluates and authorizes projects and programs. ◆ The authorization, suspension or closing of projects is strictly governed by portfolio management processes. ◆ Portfolio managers rank the projects and programs and consider the availability of financing and resources when authorizing projects. ◆ The enterprise resources are listed and maintained in a central, shared resource pool. The data in this resource pool is always accurate. ◆ The variable resource capacity needed for the project portfolio is planned for the longer term (resource capacity planning), or the fixed resource capacity is respected when authorizing new projects (resource demand management). Resource capacity planning has a time horizon from six months to ten years, depending on the industry. ◆ All authorized projects are captured in resource-loaded schedules and stored in a central database repository (PPM software application, like Microsoft Project

PAGE 36

© PROJECTPRO CORP.

Forecasting Programs

◆ ◆ ◆ ◆ ◆

Chapter 1 Program Management

Server, Microsoft Project Online or Oracle Primavera, for example). It is always clear what the latest and single-version-of-the-truth schedule is. Resource managers regularly monitor the resource workloads in the short term and keep them leveled and balanced so everybody has a reasonable workload. Project managers and program managers keep all schedules up-to-date: All actual progress is scheduled in the past, and all remaining work is scheduled in the future. The schedules forecast when the project / programs will be completed. The portfolio managers regularly review the performance of projects and programs, such as every 3 months. The frequency depends on your industry and ranges from 1 to 6 months. The formats and layouts of all reports are agreed-upon and standardized. Metrics and key performance indicators are universally applied across the projects and programs. All data are unique and normalized (i.e. not replicated) and are always easily accessible online (24*7*365). A well-deployed PPM system provides scalability, visibility, traceability, accountability and governance. It allows executives to find out the status of their portfolios, programs and major projects within minutes before they meet with suppliers, clients, shareholders or other stakeholders (unions, etc.).

For the reports and views to produce the information sought, a certain level of standardization is needed for the business case template, budgets, schedule templates for each type of repeatable project, minimum requirements for project schedules, necessary input fields for all reports, resource data, generic resources (roles) needed, project schedule update frequency, and other, less important items. PPM typically consists of the following areas: ◆ Portfolio management Portfolio management carries out the strategy of the organization by carefully selecting the projects and programs to authorize into a balanced portfolio, monitoring them during execution and closing them when done.

© PROJECTPRO CORP.

PAGE 37

1

Chapter 1 Program Management

Forecasting Programs

◆ Resource management Resource Management plans the hiring / purchasing of all resources needed given the portfolio of projects to execute (resource capacity planning) or the staggering of projects and programs to stay within the resource capacity (demand management), as well as the monitoring of resource workload on the shorter term. ◆ Project management Project Management plans the projects and executes the planning. The PPM-system provides ways for the project manager to collaborate with team members and other stakeholders on planning and executing. For simplicity sake in this illustration, we include program management under this label as well. In our mind, there are three levels of ambition you can have with your PPMimplementation: improve collaboration, gain insight & control, and optimize accomplishment of strategic objectives using the insights gained. These levels increase in their degrees of challenge: You start with collaboration, step up with insight & control and put the icing on the cake with optimization. Each new level builds on the previous level. Here is a description of each level. ◆ Collaboration between stakeholders involved in managing the portfolios, resources and projects: The project manager can collaborate with team members to create new tasks, assignments, and documents, as well as evaluating issues and risks. Team members and their resource managers can collaborate on vacation day requests, working hours, workload balancing and leveling, and productivity. Portfolio managers can collaborate with project managers to create solid business cases for each project proposal. Portfolio managers can collaborate with resource managers on authorization and staffing of projects. ◆ Insight & Control of the portfolios, resources and projects: To accomplish insight and control, you first need the overview: You need all projects, programs and resources stored in one central place. When they are in one place, you need some standardization of inputs for the reports needed. Project Server allows you to standardize templates, calendars, views, and performance indicators (fields) to create solid reports. The governance around projects can even be captured in an automated workflow. With centralization and standardization, you will gain insight on your projects, resources and portfolio, which improves the chance for gaining control over them. ◆ Optimization of the accomplishment of strategic objectives by the portfolios, the utilization percentage of resources, and the success in the delivery of projects: Portfolio managers can apply efficient frontier analysis for the project portfolio, which looks at maximizing realization of the corporate strategy through projects and programs when constrained by limited resources. This optimization is achieved by quantifying the strategic value of projects and programs. Resource managers can optimize the number of resources to hire (or fire) based on the capacity needed, given the pipeline of projects and programs being considered PAGE 38

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

for authorization. The project manager can develop what-if scenario analyses in MS Project. For example: What if we add another resource to this project; what will this do in terms of earlier completion, extra cost and additional quality? Portfolio, resource and project management are closely intertwined. In fact, they are dependent upon one another. ◆ If portfolio managers do a bad job and do not prioritize their projects, the resource managers and the project managers will experience difficulties. The resource managers will not know which projects are important and in need of their best resources. Because project managers are evaluated on how well they meet their deadlines, they will fight fiercely to get the best resources on their project regardless of how important their project is for the organization compared to other projects. ◆ If resource managers drop the ball and, for example, do not plan the resource capacity well, then portfolio managers do not know how many projects they can staff and therefore authorize. If project managers cannot rely on getting the right resources at the exact time needed, they will start lobbying and fighting to get the best resources, and when they get them they will protect them and perhaps even hoard them. ◆ If project managers do a bad job and do not deliver projects successfully, the portfolio managers will have a portfolio that does not realize the enterprise strategy they established. If project managers do not model workloads properly, resource managers will be in the dark as to what their resources are really doing and will be unable to monitor resource utilization. As you can see, for the entire organization to be successful, all three roles must be performed by competent people. A PPM system is only as strong as its weakest player!

© PROJECTPRO CORP.

PAGE 39

1

Chapter 1 Program Management

Forecasting Programs

Project Server / Project Online and Program Management For this textbook, we extended this grid with ‘program management’ for program managers (replacing Resource Management we saw earlier). As you can see in the illustration, Project Server (PS) & Project Online (PO), can support programs as well. Tip► If tagged as a program schedule, PO has special features for programs that allow you to view only the program schedule in the Project Center; when you drill down into it, you will see all project schedules that are marked to be part of the program. Similarly, the grid could be expanded with ‘task management’ for team members.

What Does Project Server / Project Online Add to MS Project? Project Server allows standardization on templates, calendars, views and fields across projects and programs. Project Server allows you to create an enterprise-wide resource pool of thousands of people. If you use the shared resource pool feature in MS Project as a stand-alone tool, you cannot exceed 100 resources. After 50 shared resources, MS Project becomes too slow; for example, it would take minutes to open a schedule that uses a shared resource pool with 300 resources shared with 10 other projects. Tip► An MS Project schedule is accessible as read-write to only one concurrent user. Some project managers would like multi-user access to allow team members to update the project schedule. Giving my team members access to my MS Project schedule never seemed like a good idea to me: They often do not know MS Project well enough and can easily wreck my sophisticated forecast model of the project. The timesheet features in Project Web App (Project Server) facilitate updating by all team members without giving them read-write access to your project schedule; the project manager still controls what update information will end up in the project schedule and what will need to be reworked first. PAGE 40

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

Use Project Server / Project Online for Your Program or Not?

1

The decision to adopt Project Server or Project Online for your program has many technical, human and financial implications to consider.

Technical Considerations Here are some of the technical considerations to make while deciding: MS Project standalone

Microsoft Project + Project Server OR Project Online Desktop Client + Project Online (cloud)

1) File system central repository: a) Manual version control b) File names and locations!

1) Central repository of project schedules (database): a) Always contains latest versions of schedules b) Overview entire program c) Clear ownership of schedules: schedule owner 2) Central resource pool a) Resource capacity planning and resource demand management b) Workload management 3) Permission-based access for multiple roles: Program managers, Project Managers, Resource Managers, Team Members, Executives, etc. 4) Out-of-the-box Project Sites: a) Program website for the program: Team Calendar, Risks, Issues, Documents, Status Reports b) Subordinated sites for projects

2) Maximum 50 resources in a shared resource pool (MPP-file) 3) No roles, no permissions

4) Project sites would need to be created manually in SharePoint (issues and risks register, discussion groups) 5) There are some bugs and issues with the standalone shared resource pool: for example, the file size can suddenly explode (because of replicating calendars).

© PROJECTPRO CORP.

5) Even though there are always small issues in software like Project Server / Project Online, none of them are red flags for the typical users.

PAGE 41

Chapter 1 Program Management

Forecasting Programs

Trap! The MPP-file as the shared resource pool in MS Project standalone uses old OLE technology from the 1990’s that has not been enhanced by Microsoft.

For program managers who do not have Project Server, we do recommend considering Project Online regardless. Project Online provides the same functionality as Project Server, but here are some differences: ◆ Tip► You can start and stop the subscription for Project Online at any time, which is helpful for program managers. If the organization does not provide Project Server or Project Online, program managers may be able to buy the licenses needed from their own budget to put their entire program team on Project Online. This service can be started next week and turned off when the program is finished, a very costeffective solution for program managers that share resources across their projects and, therefore, need a shared resource pool and resource-loaded schedules from their project managers. Project Online provides all this. ◆ Microsoft keeps Project Online up and running (99.9 % uptime); you do not need specialized help and you can keep focusing on what you are good at! ◆ Project Online is cloud-based software and, thus, continuously maintained and improved by Microsoft. Microsoft releases new features and hotfixes for bugs first in Project Online and, about six months later, Microsoft releases only the hotfixes as a Service Pack to the on-premise occurrences of Microsoft Project Server. Thus, with Project Online, you always have the latest and greatest features. However, this has also led to some frustration when features are turned on before they are fully mature. ◆ One concern with Project Online: What will happen with your data when you stop the Project Online subscription? Currently, Microsoft does not provide easy offramps for data in Project Online. However, in the case of programs, the data will be mostly the project schedules, which are relatively easy to migrate from Project Online to your local computers.

Human Considerations Apart from technical considerations, there will be dramatic implications for people when you implement Project Server or Project Online: 1. Training People will need to learn the new interfaces of the new PPM system. To train all roles in PPM, you need a comprehensive training curriculum: For an example of such a training curriculum, see our website www.projectprocorp.com under Courses, item Overview. There are multiple levels of proficiency for learning Microsoft Project as a standalone application, listed here in the order of natural progression: Model PAGE 42

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

Time, Model Workload and Model Cost: If you would like to read more on these levels, see page 244 and following. 2. Decrease of Professional Privacy The performance of each PPM-player becomes a lot more visible to a lot more people in an organization that adopts PPM compared to one without PPM. If you are a project manager and your projects perform below average, this will become painfully visible to all people with access to the Project Server / Project Online system. 3. Cultural Co-dependence The success of the entire PPM system is entirely dependent upon the weakest player in the PPM system (see page 36 where we explained some of these co-dependencies). When organizations adopt a new PPM-system, their employees become more dependent upon each other in terms of using best practices and will be asked to meet certain minimum requirements for their project schedules, which is particularly true in the context of a program: a. If resource management is required with the PPM-system, project managers will need to model workloads accurately in their project schedules. If one project manager grossly overstates the workloads, the following benefits of PPM fall apart: resource capacity planning, demand management, workload leveling and utilization optimization. b. Project managers will need to keep their schedules up-to-date. Executives will be able to spot out-of-date schedules easily. One out-ofdate schedule makes it hard to evaluate the performance of the entire portfolio and if new projects can be authorized. c. Resource managers need to address over-allocations. If one resource manager does not address over-allocations, impacts will cascade throughout the entire portfolio and affect the performance in many projects, which in turn will affect the performance appraisals of many project managers. d. Portfolio managers need to review project proposals and authorize new projects regularly and also cancel, terminate or suspend projects with the same regularity. If portfolio managers overload the pipeline with projects, resource management and project performance fall apart. 4. Legal Issues Privacy law issues will occur if actual labor rates are included. Resource salaries are hard to protect, so, the best organizations can do, is using blended rates for resources. As you can see, implementing Project Server requires paying attention to change management, just like with any other major system you implement. © PROJECTPRO CORP.

PAGE 43

1

Chapter 1 Program Management

Forecasting Programs

Tip► On the other hand, even if you do not want the cultural issues or the decrease in professional privacy that comes with Project Server / Project Online, an integrated program will force similar issues onto your team, whether you use the PPM-tool or not, because: ◆ In an integrated program, there will be many handoffs between the projects, and each project will be much more dependent upon other projects in the program and require central coordination (loss of professional privacy and a need for more cultural co-dependence). ◆ Integrated programs, business-transformation programs in particular, often require very specialized skills. These skills are therefore rare and will not always be immediately available when you need them. Programs are often resource-constrained and will require up-to-date schedules and resource managers that address over-allocations. ◆ An integrated program requires a culture of trust between the program manager and project managers, between project managers, as well as between project managers and team members.

Financial Considerations Next, we will give estimated financial numbers per project manager or per end-user, which means that as soon as you know the number of project managers (including the number of program managers) within your organization and you decide the number of other end-users (resource managers, executives, etc.) to engage in the system, you will be able to calculate a rough, order-of-magnitude budget for the implementation of Project Server on-premise or for Project Online. Tip► You will soon find that Project Online will be cheaper-per-user for small- and medium-sized organizations, whereas an all-out Project Server installation on-premise will be cheaper-per-user for large organizations. The financial implications are different for the two distinct implementation options: Project Server on-premise (perpetual licenses, or, more accurately, licenses that last until Microsoft pulls its support for them) or Project Online in the cloud (subscription licenses): 7

7

Note, these numbers date back from 2017 and will change without notice. They are not meant to be a quote or commitment from ProjectPro Corporation. We just provided these numbers for your convenience to help you put together an initial budget request for implementing Project Server or Project Online. If you would like to receive a quote, we suggest you contact us at 613-692-7778 (EST) and request one. The numbers here are based on analysis of past implementations of ProjectPro completed for our clients. PAGE 44

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

Project Server: The one-time, capital expenditure for an on-premise installation of Project Server: ◆ Software:  Server licenses: Windows Server, SQL Server, SharePoint Server,  User licenses: Project Web App - PWA (for all executives, portfolio managers, resource managers, and team members), Project Professional for all project managers, Power BI for all report viewers. ◆ Hardware:  Servers: depending on the size of your program and your uptime and failover requirements, you may need at least one, but likely three to six servers at USD $3,000 - $5,000 each. ◆ Installation and configuration consulting services: budget ranges from USD $4,000 – $10,000 per project manager depending on if you want to implement only project management features (USD $4,000), or also resource management (USD $7,500), or also portfolio management (USD $10,000 per project manager including program managers). ◆ Training services: budget about USD $500 per end-user to be trained. Potential endusers are at least project managers and program managers, but can also include program support staff, executives, portfolio managers, resource managers, team leaders and team members. OR Project Online: The following regular subscription costs were in effect for the cloud-based Project Online as of September 2017 (see website https://products.office.com/en-us/project for the latest rates): ◆ Licenses:  USD $55 per executive / portfolio manager / resource manager per month for Project Online Premium (Project Web App - PWA).  USD $30 per project manager including program managers per month for Project Online Professional (Project Web App - PWA and Project Online Desktop Client).  USD $7 per team member per month for Project Online Essentials (Issues/Risk registers, Documents and PWA Timesheet), which allows team members to report task progress to the project manager (not an absolute necessity for programs), contribute to project risk and issue registers and store/retrieve documents from the Project Site, respectively. ◆ Configuration consulting services: budget ranges from USD $1,500 – $4,500 per project manager depending on if you want to implement project management features only (USD $1,500), or also resource management and portfolio management (USD $4,500). © PROJECTPRO CORP.

PAGE 45

1

Chapter 1 Program Management

Forecasting Programs

◆ Training: budget about USD $500 per end-user to be trained. AND for both Project Server and Project Online: Ongoing costs: ◆ Help desk support for Project Server and Project Online: You will need about one fulltime support staff member for each 100 project managers in your organization. Trap! We have not seen any successful implementation without the ongoing support of an active and responsive help desk: Please, do not cut this expense! ◆ System Administration:  Project Server (‘keeping the lights on and allowing people in’): You will need about one fulltime administrator for each group of 500 users (all roles) plus, for Project Server on-premise, a standby, backup administrator for when your main administrator is away.  Project Online (‘allowing people in’): Administering Project Online is just managing user accounts and maintaining the configuration, which requires less effort. You will need about one fulltime administrator for each group of 1,000 users (all roles) plus a standby, backup administrator. ◆ Upgrades to future releases for Project Server on-premise only: Your guess is as good as ours.

Working with Vendors Most programs have some vendors lurking around. These vendors may be: ◆ Suppliers of off-the-shelf software that needs customization to become a main operating system for the company: e.g., a Point-of-Sale system (POS) for a large retailer, an ERP system for the organization (How many SAP-implementations haven’t we seen in the last two decennia?) ◆ Suppliers of specialized services different from the core expertise of the organization: e.g., security experts, legal experts, world-wide logistics experts, or training experts. ◆ Suppliers of off-the-shelf, key components of the final product under development by the organization: e.g., specialized radar system in an airplane, specialized sensor system in mining operations, GPS system, etc. As a program manager, you will have to figure out how to work with vendors. Here are a few lessons that we have learned over the years by observing many programs and their struggles.

PAGE 46

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

Relentlessly Standardize on Scheduling Software As scheduling experts, we have often been hired to figure out the challenges in scheduling. The most difficult challenge, by far, has always been to convert a project schedule from one scheduling application to another one. Even though the money has been good in this line of work, we must admit that the results have never been satisfactory for the client. Each scheduling application is fundamentally different from another, and schedules never come out the same when you roundtrip them from one application to another and back again. Over the years, a simple test has always served me well. Let’s call the test scheduling applications X and Y. I make a snapshot of the scheduled Start and Finish dates and save them in some extra date field, like Start1 and Finish1 in Microsoft Project (ribbon Project, button Save Baseline, item Save Baseline, select  Entire Project and  Interim Plan). These extra fields are static fields (i.e., the scheduling engine X will never recalculate them), whereas any other date field may be recalculated. Then I import the schedule into application Y and test where dates have changed. If I see changes, I try to isolate what caused the changes. Then I know where the pain points are for conversion from X to Y. Next, I test the conversion back from Y to X. I save the dates once again in a different set of fields, (like Start2 and Finish2 in Microsoft Project) and re-import the schedule back to X and perform the same analysis. I try to isolate the changes again. Here are some of the stunning discoveries we have made over the years: ◆ Microsoft Project and CA Clarity: CA Clarity strongly promotes combining it with Microsoft Project for the scheduling, but here is what we found:  Microsoft Project has three task types (field Type: Fixed Duration, Fixed Units, Fixed Work) whereas CA Clarity (Connector version 13.2) has only two: provided by the option in Clarity of  Fixed Duration that can be turned on or off:  Fixed Duration, which is the same as Fixed Work in Microsoft Project. What does Clarity do with Fixed Units tasks? It converts them to Fixed Work and this where differences can start to appear when converting or uploading schedules.  Furthermore, CA Clarity does not allow assignments of groups of people to activities (like Units = 4 in Microsoft Project) or part-time assignments (like Units = 0.5). What does CA Clarity do with these group and part-time assignments? It changes (not converts!) them all to assignments of 1 fulltime person, which creates huge changes in the schedules. Trap! Because of these two conversions, the Duration of activities with part-time resource assignments explodes, and the Duration of activities with group assignments collapses. We saw such large date differences when converting, that we strongly recommend against ever combining Microsoft Project with CA Clarity © PROJECTPRO CORP.

PAGE 47

1

Chapter 1 Program Management

Forecasting Programs

(Connector version 13.2). Note that this insight dates from the year 2015, so please, check in with CA Clarity to determine what they have done in the meantime to correct this issue. Then test it.  We found other issues that could also affect the schedule in minor ways: ▪ You cannot have local resources in your schedule; all resources need to be matched to the resources in the CA Clarity shared resource pool. ▪ CA Clarity uses the resource Initials field in MS Project to match resources, which is an unfortunate choice because resource Initials are not necessarily unique in MS Project (only Unique IDs are!). ▪ Assignments on summary tasks are not supported in CA Clarity. ▪ Lags entered in Elapsed Days (like ‘4 Edays’) are not supported in CA Clarity. ◆ Microsoft Project and Oracle Primavera:  First, you must interpret the terminology that is different between these applications. Below is a table with some of the most prominent differences; these terms do not lead to a difference in scheduling of activities, unless there is a difference in functionality; only differences in functionality cause problems when converting schedules between applications: Microsoft Project Total Slack Finish No Earlier Than 9 Start No Earlier Than Must Start On

Primavera Total Float 8 Finish On or After Start On or After Mandatory Start

Below, we will list differences in functionality that can cause problems when converting schedules between Microsoft Project and Oracle Primavera.  Primavera has % Duration Complete which has a different definition than % Complete in Microsoft Project.  The word Unit in Primavera means a unit of work, whereas in Microsoft Project, Unit means an amount of a resource.  Microsoft Project has summary tasks and detail tasks (activities), whereas Primavera does not: All line items you create in Primavera will have to be coded with WBS-codes (for example, 3.1.4 indicates that the item belongs to the 3rd deliverable and its 1st component, and is the 4th activity that creates this component). This coding of line items will create a similar work breakdown structure that you see natively in Microsoft Project. This conversion runs well 8

The term Total Float is used in the PMBOK-Guide®, 6th Edition (and earlier ones), whereas Total Slack is not in the PMBOK-Guide®, similarly for Free Float and Free Slack. 9 Negatively stated terms tend to be harder for people to understand; I tend to prefer Primavera’s terminology here. PAGE 48

© PROJECTPRO CORP.

Forecasting Programs

Chapter 1 Program Management

and does not create many problems. You can see, though, how fundamentally different Primavera treats line items compared to Microsoft Project.  Primavera can store an unlimited number of versions (version control) and also an unlimited number of baselines, but it stores these outside the current schedule. Conversion between Microsoft Project and Primavera will lead to a certain loss of versions and a likely loss of baselines, because Microsoft Project has a maximum of 10 baselines.  Primavera allows two dependencies between two tasks, which is useful in many situations where you want the two starts linked AND the two ends linked. You cannot do that in Microsoft Project, and so conversion will lead to different schedules. Trap! You should NEVER believe what any vendor states regarding compatibility with

other software or seamless integrations! You MUST thoroughly test every claim made by any vendor! Remember that salespeople almost always work for commissions that are a percentage of their sales, so they really want to convince you that their software is ‘the-best-thing-ever’.

Relentlessly Standardize on a Scheduling Software Release Whenever Microsoft releases a new version, here’s the first check I do: Has the scheduling engine changed? If the scheduling engine changed (information often communicated poorly or not at all by Microsoft!), the conversion between schedules will pose problems. I test conversion by roundtripping a few complex schedules with many different features from the old release to the new release and back, checking whether any date changes. Often, I find differences that prove Microsoft tinkered with the scheduling engine. The second check I do: Are there new features that affect the scheduling of activities? For example, the 2002 release of Microsoft Project had the feature of Task Calendars for the first time (catching up with Primavera, by the way). Task Calendars, like a Weekend-Only Task Calendar, are very useful for forcing a Go-Live activity into the weekend, such as changing over to a new software, while overriding the resource calendars that are Weekday-Only and forcing the resources to work on the weekend. You can imagine that a new feature like this would cause problems when you allow multiple versions of Microsoft Project in your program and convert back and forth across this new feature. Tip► You MUST standardize not only on the application, but also on the release within that project scheduling application!

© PROJECTPRO CORP.

PAGE 49

1

Chapter 1 Program Management

Forecasting Programs

Trap! The only two alternatives are: ◆ Disallow the people with the new release from using these new features in their schedules. However, based on our experience, even when you do that, somebody will forget this scheduling guideline sooner or later, and you are in trouble once again. It is not a happy place. ◆ Convert all schedules to the lowest common denominator release and encourage people to only save their schedule in that release; later releases can always save-as to earlier releases. If most people have MS Project 2013 and some have MS Project 2016, have MS Project 2016 users save down to MS Project 2013.

How Can You Standardize on Software and Release? The answer is simple: Write it into the contract with the vendor. The vendor will scream at you because, in most cases, they do not want to comply. Why not? Well, it is simple. Each vendor has its own internal scheduling system it is forced to work with by the boss who pays salaries. Vendors must do this internal scheduling of their employees to make sure none of them becomes too overloaded when helping clients. Now they are forced to maintain two schedules in two different software programs. They see this as unnecessary overhead in their project that compromises their ability to compete on price for your work in a public tendering. Therefore, you must write it into your Request for Proposal (RFP) as a mandatory requirement for any vendor. That way, you level the playing field for all vendors to bid on your tender, AND you will end up with schedules that can easily be incorporated into your Integrated Master Schedule (IMS). Of course, the tendered costs will be higher, but the savings will be much higher. Trap! If you did not do this as the program manager, you will now have to deal with the consequences, which are always nasty and will never be resolved satisfactorily, regardless of the scheduling guru you intend to hire. Every month, you now must do this painful conversion and convert each schedule delivered to you in a different format, check for differences, and iron them out before incorporating the vendor schedule into your IMS. This can be a lot of extra work. Vendors deal with the same issue of adopting the scheduling application of clients more often, and if they develop a versatile solution, they can create a unique selling point for their company. It is better to leave it to the vendors to figure it out than for you as the program manager! By the way, versatility is the hallmark of a strong consulting firm. Tip► We recommend you present all subcontractors with a vendor management plan so they understand their role in every aspect of the project execution and know where they must follow current processes and procedures with respect to things like software and release to use, schedule updates, risk management, submitting documents, invoicing, etc.

PAGE 50

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Chapter 2 Choosing the Best Scheduling Approach

Learning Objectives After this chapter, you will: ◆ Know the current approaches to scheduling projects and programs and their assumptions. ◆ Identify the dominant ideal and constraint in your project or program. ◆ Given the dominant ideal and constraint, be aware of the recommended scheduling approaches. ◆ Be aware of happy combinations of scheduling approaches and miserable ones. ◆ Pick the recommended scheduling approach for your project from the Project Ideal and Constraint Matrix (PIC-matrix).

© PROJECTPRO CORP.

PAGE 51

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

We are Repairing the Airplane While it is in Flight… Nob walks around with a dizzy look, his eyes absently staring at the horizon and not contacting human beings around him. Bob startles him: “Hey Nob, what’s going on?” “Oh, we’re in the middle of planning the program and ….” “Your program started a while ago. Weren’t you supposed to be in the execution phase already?” “Yeah … uhh, kinda!” Nob admits. “So, now in the middle of the execution phase, you’re still planning the execution as well?” “Uhh, yes …” “That’s like trying to repair a plane while in flight, isn’t it?” “That’s what it feels like. The amount of data is overwhelming, and we never seem to be getting ahead of the onslaught of our program.” Bob softened his voice. “Feeling overwhelmed?” “Yeah, we’re also still trying to put some contracts in place with vendors. Oh, and the client hasn’t signed off on the requirements yet.” Nob looks miserable.

PAGE 52

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Introduction We have seen a flurry of articles on the versatility of Agile, the solidity of the Critical Path method, the virtues of Critical Chain and the robustness of Earned Value. Is there one approach that is objectively the best? One approach that performs best in any project situation? The original Critical Path does not perform well when resources are very slim. Critical Chain does not perform well when clients are interested in the cost side of projects. Earned Value does not do very well in projects without budgets (i.e., when monetary budgets are managed by people other than the project manager). Agile does not do very well when the client has a clear vision and wants to build the entire envisioned product, not just part of it. We must conclude that there is no single, best way to schedule a project. If there isn’t one-best-way, it begs another question: How can you find out which of the approaches would be the best choice for your project situation? We will use two simple dimensions to characterize projects: project ideal and project constraint.

Project Ideals What is a project ideal? An ideal provides a measure for success. Better achievement of the ideal may satisfy a client, but the project ideal can never be achieved entirely. For instance, doing a project at the lowest-cost-possible is an example of a project ideal, but the cost will never be zero. However, improving on the project ideal gives companies a competitive advantage in the market place. For example, organizations that develop new products often try to be the first-to-market. Their project ideal is shortest-time-possible. These organizations would be very happy if the product development life cycle shrunk from 2 years to 6 months or 3 months or better yet to 1 month, and best of all if it were all done yesterday. This ideal will never be achieved entirely; it guides your direction but is not a destination. When will we have new products that appear instantly after we have come up with the concept? Common project ideals are easily identified. Project managers typically strive toward one of the following: ◆ Highest client satisfaction Some projects have one client with an impossible challenge, such as a new product development manager. Other projects have many clients, and it will be impossible to keep all clients happy. Projects that create new policies, procedures or systems have many clients. A project that changes the salary system in an organization may have as its ideal to maximize the satisfaction of the employees. You will never satisfy all © PROJECTPRO CORP.

PAGE 53

2

Chapter 2 Choosing the Best Scheduling Approach

◆

◆

◆

◆

Forecasting Programs

employees, because they would simply all want a really-high salary, but the challenge is to satisfy as many of them as much as possible. Most Scope and Highest quality for deliverables The competition on scope and quality takes place at the top-end of the market. The competition often focuses on simply and objectively measured quality standards, like processor speed in the computer chip market, storage capacity in flash memory, energy-production in solar panels or energy storage capacity in batteries: Quality will never be high enough. Software development projects often suffer from bugs. Clients desire bug-free software, but that ideal will never be realized, unfortunately. Statisticians have proven this. Shortest time possible R&D organizations that develop new products often try to shorten their development cycle to be the first on the market. If you could deliver yesterday, that would be best. The current race for high-ROI solar panels and the 500-mile car batteries are a few examples. Lowest cost possible Implementation-type projects, like software or hardware upgrades, often are focused on saving cost. The knowledge exists, there are few unknowns and the goal is to do the job most efficiently. If it could be free, that would be best. Maintenance projects and regulatory-compliance projects are often in this category, because they cost money without generating new revenue. Lowest risk possible Situations in which the possible risks are gigantic often require a lowest risk possible approach. Modifications to a nuclear-power reactor would be a prime example. The risk will never be zero, but the closer to zero, the better.

Project managers often know explicitly or intuitively which one of these ideals is most important in their project or for their customer. However, there are some common phenomena: ◆ All ideals are of some interest to each project. If asked, the project manager can often rank the ideals on importance to the project. A project manager who can’t do this had better talk to the project sponsor and other stakeholders to find out. ◆ Throughout the project lifecycle, ranking of ideals and constraints can shift. Early in the project life cycle, many projects tend to be quality oriented. Then reality sets in, and time becomes a factor. During project execution when resources are hired and the burn-rate increases, cost automatically moves up in the ranking. In our experience, shifts are mostly among the ideals of secondary importance, not the primary or dominant one. ◆ Often one ideal remains most important throughout the entire project life cycle. This might be my most daring assumption, but it is a necessary one to make this model easy-to-use. So, please read on and judge this for yourself.

PAGE 54

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Project Constraints How does a project constraint differ from an ideal? Constraints are a measure for failure, whereas ideals are a measure for success. When constraints are met, the project isn’t necessarily successful, but it isn’t a failure either. If you do not stay within the budget, clients may not be happy even though they get to enjoy the new product or service, because they paid too much for it. If you deliver late, the client may not be happy either, because they had to wait too long for it. For clients, ideals are satisfiers, whereas constraints are dis-satisfiers. For project/program managers, ideals are what you work toward and constraints are what you work within. The closer you come to the ideal, the more satisfied the client will be, but the client will not necessarily be happy yet. Only if constraints are met will the client be happy and the project successful. Project managers face the challenge of maximizing the project ideal while respecting project constraints. If all goes well during project execution and you stay within the constraints, the client will certainly be happy. The different types of project constraints are: ◆ Knowledge-constrained Knowledge-projects are constrained by the speed with which new ideas or findings are generated to meet the quality requirements of the project. These are the typical research and development type of programs, including new product development programs. Such programs have many unknowns, and the progress made depends heavily on solving the scientific or technological problems and receiving favorable test results. You can find many knowledge-constrained projects in the pharmaceutical, defense, R&D and high-tech industries. ◆ Time-constrained The project team may face the challenge to finish before a certain hard deadline. The project duration is driven by the logical sequence in which tasks have to be performed. Y2K projects were prime examples of time-constrained projects; if it wasn’t done by the turn of the millennium, the project had failed (so we thought at that time…). ◆ Cost-constrained This type of project has a set budget. There simply is no more money available, and expenses must be tightly managed to stay within the fixed budget. Cost seems to be the main concern, for example, in government projects where yearly budgets are often fixed. Common construction projects, such as bridge building and road pavement (not high-profile construction projects), are often cost-constrained as well. ◆ Resource-constrained In this type of project, the availability of resources is limited and inflexible; you © PROJECTPRO CORP.

PAGE 55

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

must make do with whom you have. Resources cannot easily be found (scarce expertise?), hired (hire-stop?) or trained (expertise, special skill or talent required?). The scarce resources drive the schedule more than the network logic. You will have to make do with the resources available, and if you can’t deliver the project product with the resources you have, the project fails. ◆ Risk-constrained Risks can be of financial, reputational, safety or political. The main concern of the project manager in private companies is to limit the financial exposure to a certain amount. In public projects, the project’s negative public exposure must be kept to a minimum. If a certain threshold of risk is exceeded, the grapevine or the press may expose those who are accountable. Many government projects are risk-constrained projects because if a public project gets negative publicity, the responsible politician may not be re-elected. Some observations: ◆ Constraints may evolve over a project life-cycle as time progresses. Typically, programs start out to be knowledge-driven, then become time- and costdriven during the planning phase and resource-driven during the execution phase. These shifts typically take place in the secondary constraints of the project. ◆ Projects always have more than one constraint that needs to be managed or observed, but the primary or dominant constraint often stays the same during the entire project. This might be another daring assumption, but a necessary one to make this model easy-to-use. Again, please read on and judge for yourself.

Analyzing your Project We can put ideals and constraints in a matrix. I herewith baptize this new framework as the Project Ideal and Constraint Matrix (PIC-Matrix). You should be able to

PAGE 56

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

characterize your own project on these two dimensions discussed. Please identify the cell in which your current project would fit:

2

Let’s consider, for example, a high-tech new product development project. The project creates a new computer product with which the organization tries to be first-to-market. The goal is, therefore, to complete this project in the shortest time possible, and the constraint may be that the product must return at least the investment and operational costs in revenue, which can be construed as a risk constraint. If it looks like the investment cannot be recovered, the project will be canceled. This project is a shortest-time possible, risk-constrained project. Another example is a construction project in which a block of houses is built by a developer. The houses are not extremely fancy, and cost seems to be the biggest issue for buyers. The developer makes sure the contractor constructs at the lowest-cost-possible. st The developer has also set a deadline that houses need to be delivered by October 1 so new owners can move in conveniently before winter. This deadline acts as a timeconstraint. This project is therefore a lowest-cost, time-constrained project. Once we have characterized our projects in terms of its dominant ideal and dominant constraint, we can determine the best scheduling approach for each. I will recommend using a specific scheduling approach for the cell your project is in given the dominant ideal and dominant constraint. These recommendations are by no means scientifically proven but rather based on years of practice observing the jungle of project management and some common-sense thinking.

© PROJECTPRO CORP.

PAGE 57

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

Current Scheduling Approaches Approaches currently used, include the following: ◆ Agile ◆ Critical Path Method ◆ Resource-Critical Path ◆ Critical Chain ◆ Earned Value ◆ Earned Work I will only briefly explain each approach in this chapter, because most of you know them already, except perhaps Resource-Critical Path and Earned Work. If you want to read up on any approach, I will refer you to a book that I have found to be best on that approach. I will just characterize each approach using the following aspects in this chapter: ◆ The health indicator used in each approach that determines if a project is healthy or has fallen sick. ◆ The theoretical and practical assumptions that emerged in practice that the approach was built on. ◆ Examples of typical industries where each approach is used. ◆ Examples of typical projects where each approach is used. ◆ The approach’s place in the Project Ideal and Constraint Matrix (PIC-Matrix). As soon as you have figured out which cell in the PIC-Matrix your project is in, this will eventually become our guide to help us decide which approach to use. This Project Ideal and Constraint Matrix (PIC-Matrix) provides a framework that I herewith offer to the field of practitioners and academics for deeper discussion, further exploration and validation.

Agile (AG) Scheduling What is Agile? Agile is a scheduling approach where a client establishes and maintains a backlog of functional requirements (often captured in the form of user stories or use cases). An Agile team then discusses these requirements and commits to develop a subset of them within a set window of time (often two-weeks to one-month long, called a ‘sprint’). The Agile project keeps going as long as the client can find enough new requirements and funds to legitimize and finance the next sprint.

PAGE 58

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Agile scheduling starts with establishing functional requirements, for software development projects often formulated in the form of user stories or use cases. It allows for continual scope and activity changes throughout the project life cycle and does not require setting a baseline. Basically, this scheduling approach requires the least amount of scheduling effort. Agile strives to deliver a viable product at the end of each sprint that provides value to the client. The project health indicator is the answer to the following question that should be raised at the end of every sprint: Do you have a positive cost-benefit result from the last sprint? The main criteria for the next sprint is: Can we produce a viable product with new features that are of value to the client? Another question could be: Will the client as the sponsor of the project fund the next sprint?

Assumptions of Agile Assumptions of the Agile approach reveal some of its weaknesses: ◆ Agile assumes the client does not have a well-defined vision of the end-product before the Agile project starts, but rather a murky vision at first that will become clearer as the product starts to take shape during the project. Often, the client does not even know if a certain direction is feasible but finds it worthwhile to explore by investing in it. In my experience, many clients have a well-defined vision of the end-product. ◆ Agile assumes you can determine if a project is healthy by judging if the cost-benefit result was positive for the last sprint and if, for the next sprint, the features are of value and the schedule looks feasible. This evaluation requires a lot of insight, technical knowledge and judgment from the team and the client. A weak health indicator clearly is a weakness of this approach. ◆ Agile assumes and requires that the client wants to stay very involved in the Agile project process and have continuous interaction with the project team, looking at the viable product at the end of every sprint and discussing which functional requirements to add during the next sprint. ◆ Agile assumes the client is not interested in the total cost of the new product or the total duration of the project to create it. In my work experience, almost every client wants to know these things even in software development or research projects.

© PROJECTPRO CORP.

PAGE 59

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

Best Use of Agile The best use of Agile Scheduling is in knowledge-constrained projects such as: ◆ New software development projects, particularly when new technologies are used for the first time, such as the latest release of an operating system or new development environment. ◆ Small software enhancement projects: Software applications that are established but need new features are prime candidates for Agile, particularly if each new feature fits within a sprint. Agile allows clients to constantly make a cost/benefit analysis on the next sprint, and typically, a continuous sequence of releases is made. If the software enhancement is large, we recommend other approaches. For example, enhancement to a government employment insurance application is large and should not be scheduled in an agile way, in our opinion, if the enhancement will take many sprints to develop. The entire enhancement needs to be costed, planned and delivered, because unemployment checks still need to go out on time. In this case, Agile makes little sense. ◆ New product development projects, particularly when new scientific insights, materials or processes are tried out and incorporated. ◆ research and development (R&D) projects Agile projects often work at the frontier of human knowledge, where you must be nimble and apply continuous-learning, then incorporating those findings at every turn of events. If you want to learn more about Agile, a good book about a subset of Agile called Scrum is: Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin.

Critical Path Method (CPM) Scheduling What is Critical Path? With the Critical Path Method (CPM) you determine the longest sequence of tasks in a network of dependencies and monitor and manage that critical path closely to finish your project on time. The health indicator is the latest forecasted finish date compared to the project deadline date. If the finish date does not exceed the deadline, the project is healthy. The forecasted finish date is driven by the length of the Critical Path.

PAGE 60

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Assumptions of the CPM-Approach Assumptions of the Critical Path approach reveal some serious concerns. ◆ Critical Path assumes that estimates are normally distributed Critical Path uses single-point estimates, not range estimates like two-point estimates or three-point estimates (optimistic, most-likely, pessimistic). Critical Path practitioners typically use the most-likely, single-point estimate to create their schedule and therefore implicitly assume that the single estimates are normally distributed. Normal distributions have the shape of a perfectly symmetrical bell-curve. When it became clear in practice that the distributions of estimates are often skewed to the pessimistic side, the Program Evaluation and Review Technique (PERT) was developed to quantify that bias in estimating. PERT adds some probability to the Critical Path by asking for three estimates instead of a single-point estimate on activities. The three estimates are: Optimistic, Most-Likely and Pessimistic. It is an important enhancement of Critical Path, because estimates typically skew to the pessimistic side in practice (asymmetrical bell-curve with a long tail to the right). ◆ Critical Path assumes that there is no merge-bias Merge bias is also known as: path-convergence or integration risk. People realized that where two or more paths come together in the network, the merge-bias, causes a decrease in the probability of on-time delivery (an increase in time risk) of the project. For example: Two paths merge into a milestone:  If one path is early, the other path may be late and the milestone will be late: Only if both paths are early or on time will the milestone be on time.  In numbers: If two paths of equal length with a 90% chance of being delivered on-time merge into a milestone, the on-time delivery for the milestone decreases to 90% * 90% = 81%. Simulation software can now quantify the compounded effect of merge bias, as well as the skewedness of the distribution curve of estimates (i.e., address the first assumption as well). This is known as Monte Carlo simulation. ◆ Critical Path assumes that you have unlimited resources available Assuming unlimited resources allows the schedules to be short in duration but unrealistic, because there are still over-allocations. This assumption can be worked around by applying one of the other approaches: Critical Chain or Resource Critical Path. Over the years, many improvements have been proposed to address these concerns. If we combine the CPM-approach with simulation, we can address the first two assumptions. If we replace the Critical Path with a resource-constrained Critical Path (a.k.a. Resource-Critical Path or Critical Chain), we address the third assumption. If we apply simulation on the Resource-Critical Path, we address all three assumptions.

© PROJECTPRO CORP.

PAGE 61

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

Best Use of Critical Path Generally, Critical Path scheduling can be applied best in shortest-time possible projects that are NOT resource-constrained. It can also be applied in time-constrained projects. For example, in the following situations: ◆ Large software enhancement projects, like enhancements to a government unemployment insurance system that take a year. ◆ Government sub contracts: civil works, like roads and bridges. ◆ Infrastructure projects (electricity, water, sewage) ◆ Plant engineering projects ◆ Construction projects There are many books that explain the CPM-approach, but some that I have found particularly useful are Project Planning, Scheduling & Control by James P. Lewis and CPM Mechanics by Murray B. Woolf.

Resource-Critical Path (RCP) Scheduling What is a Resource-Critical Path? The Resource-Critical Path (RCP) approach is an enhancement to the CPM-approach. Unlike the Critical Path, the RCP takes resource dependencies into account (as well as logical dependencies). The RCP-approach identifies the longest path in the network of logical and resource dependencies, which is the Resource-Critical Path. The project manager then monitors and manages this Resource-Critical Path to bring the project in on time.

PAGE 62

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Here is an example of a Resource-Critical Path relative to its Critical Path:

2

The health indicator is the finish date of the regularly updated Resource Critical Path compared to the project deadline date. If the Resource Critical Path finish date does not exceed the deadline, the project is healthy.

Assumptions of the RCP-Approach 1. Estimates are normally distributed. The same discussion under Critical Path Method applies to this RCP approach. 2. There is no merge-bias / path-convergence. The same discussion under Critical Path Method applies to this RCP approach. 3. We can automate identification of the RCP in such a way that it is shown in our project schedules within mere seconds. Finding the RCP manually in large project schedules requires too much effort; in a 100-task schedule, it would take a trained schedule analyst a few minutes to find the RCP. After any change to a duration or effort estimate or to any assignment has been made, the RCP may change as well and will have to be analyzed and identified again. This concept requires automation for it to become a viable approach. Automation requires an infallible algorithm that identifies the Resource Critical Path. Compared to a Critical Path approach, a RCP-approach does not have the assumption that resources are unlimited. If the RCP-approach is combined with simulation, the first two assumptions can be addressed as well.

© PROJECTPRO CORP.

PAGE 63

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

On page 492 in my Forecast Scheduling with Microsoft Project 2013 book, I propose the following algorithm for finding the RCP:

Scheduling software should be able to identify the RCP in a similarly convenient way as it identifies the Critical Path. Only a small number of project scheduling applications on the market today claim to be capable of identifying the RCP in a schedule. Those special software tools currently are: PathsPro (add-in to Microsoft Project from ProjectPro, my company), ProChain (add-in to MS Project from ProChain Solutions Inc.), and Spider Project (fully-featured, scheduling application from Spider, Russia). Trap! Note that the software needs to be able to simulate a workload-leveled schedule to address all assumptions for RCP: For each simulated scenario, the simulation software needs to re-level all workloads first and then determine the RCP in that scenario of the schedule. This disqualifies almost all standalone, simulation software applications, except for our PathsPro application in that scheduling scenario.

Best Use of RCP-Scheduling In general, RCP can best be applied in any projects where specialized and, therefore, scarce capabilities are needed. Those projects are resource-constrained, such as: ◆ Specialized construction projects (oil-rigs, skyscrapers, and process-manufacturing plants) ◆ Projects that have access to internal resources only (and are not allowed to hire externally); we often see this in government projects. ◆ Software development projects on large, in-house systems that require intimate knowledge of these in-house systems. PAGE 64

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

◆ Pharmaceutical projects using researchers and/or rare medical specialists ◆ Leading-edge technology projects Tip► We recommend that you apply a RCP-approach in any situation in which limited resource availability may have a negative impact on your project’s finish date. Tip► The great advantage of a RCP-approach is that it looks and feels (to the uninitiated) as if you are using a regular Critical Path scheduling approach. Consider a schedule with two tasks that compete for the same resource. To level the workloads, you delay one task and schedule it right after the other task. When I asked thousands of students what the Critical Path is in the schedule, the majority always answers that both tasks must be critical because both drive the project end date. Current scheduling software implementing Critical Path, however, will not show both tasks as critical, only the delayed one because there is no logical dependency between the tasks. Intuitively, the RCP-approach makes sense to people. This concept does not require major training for project stakeholders who use CPM. The only people who need training in this concept are schedulers who must learn to identify the Resource Critical Path in their schedule.

There are only a few books that explain the RCP-approach in more detail: Dynamic Scheduling with Project 2000/2002/2003 and Forecast Scheduling with Microsoft Project 2010/2013 by the same author as this textbook.

Critical Chain (CC) Scheduling What is Critical Chain? Critical Chain scheduling is an approach in which: ◆ You find a Resource Critical Path in your project schedule. ◆ You also gather estimates from people assuming they can work on their tasks in a focused way minimizing interruptions and diversions. ◆ You schedule all tasks as late as possible, and you protect the project end date with a project buffer (risk contingency). ◆ You protect the Resource Critical Path by inserting feed buffers in all other paths where they feed into the Resource Critical Path. ◆ You manage the project by monitoring depletion of the buffers as your project moves along. The feed buffers are monitored, but the real health of the project is determined from monitoring your project buffer.

© PROJECTPRO CORP.

PAGE 65

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

The Critical Chain approach takes limited resource availability into account, just like the Resource Critical Path approach, but that’s not all. Critical Chain addresses the negative effects of multi-tasking. When people take multiple-task commitments upon themselves, they will find themselves switching back and forth between the tasks. Every switch requires closing off and cleaning for the previous task and finding the documents for the next task, which results in a loss of productivity. This is why Critical Chain encourages project managers to single task their project team members and ask them to concentrate on that one task until it is finished. Critical Chain also encourages all tasks to be scheduled as-late-as-possible instead of assoon-as-possible as in all other approaches. When tasks are scheduled as-soon-aspossible, it fosters a culture of: ‘Oh, we can start many tasks at the same time; what task would we like to work on today?’ which often leads to multi-tasking. In as-late-aspossible scheduling, the team members are expected to start on the task when the schedule indicates the task should start, leaving little room for procrastination. Of course, the project manager needs buffers (time contingency). A buffer in Critical Chain is a deliberately created time-contingency, the duration set as deemed necessary by the Critical Chain scheduler. Buffers in Critical Chain are therefore different from Total Slack in Microsoft Project, which is calculated by Microsoft Project. Parkinson's Law states that resources will use all the time you give them to complete tasks. If you give a team member 3 weeks to complete a 4 person-day task, the resource will use all 3 weeks. The Critical Chain approach therefore advocates having dedicated project resources work full-time on tasks with durations that are too tight for comfort to combat Parkinson’s Law. To determine the tight estimates, CC-schedulers typically ask about the first estimate provided: What is the probability that you complete this task in that time? The person may answer: 80%. For an aggressive estimate, typically CC-schedulers try to find estimates at the 50% confidence level, which means that the estimate is met 50% of the cases and exceeded in the other 50%. This means project managers cannot micromanage tasks finishing on time, because the baseline finish dates will often be missed. Project managers will have to learn to swiftly forgive team members who slipped their tasks. They can generously do so because they own a substantial project buffer, which is typically 50% of the Critical Chain duration. Using a Monte Carlo Schedule Risk Analysis (SRA) tool, a project manager can double check the buffer estimate to analytically determine the 50% and 90% probability project end dates or Risk Contingency duration.

PAGE 66

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

There are two estimates for each task, the 50% and 90% duration estimate. The 50% estimate is used to build the Gantt Chart. Then a second schedule is built using only 90% estimates; the difference between the 50% and 90% schedules determines the size of the project buffer (risk contingency). The project buffer is added to the schedule of the 50% confidence level Gantt chart. If the buffer depletion is less than a predetermined level that varies throughout the course of a project (often in a linear relationship), the project is seen as ‘healthy’. As-soon-as-possible scheduling fosters a multi-tasking mentality that is contrary to the full- focus and concentrated working that CC project managers try to achieve. CC-advocates therefore suggest you schedule all tasks as-late-as-possible while still protecting the Critical Chain by inserting extra, secondary buffers, called feed buffers at merge points. As-late-as-possible scheduling also minimizes re-work that needs to be done, because you start with inputs that are in their absolute latest version before needing to start your work. Here is an example of what a project with a primary and one secondary Critical Chain would look like:

The health indicator for a Critical Chain schedule is the remaining size of primarily the project buffer and secondarily the feed buffers. The project is healthy if remaining buffers are big enough to protect the project end date for the remaining project duration. The project buffer is monitored by comparing consumption to the ideal line and two

© PROJECTPRO CORP.

PAGE 67

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

linear control limit lines that run parallel to the ideal line in a Buffer Consumption Chart (Risk-Burndown Chart):

The ideal line (green dots) and control limit lines are established at the start of a project. Control limit lines serve to report exceptions: The Yellow Control Limit (small yellow dashes) is a warning while the Red Control Limit (large red dashes) is a critical limit. It is a simple implementation of statistical control. When your project buffer (solid line with square markers) is depleted to the Yellow Control Limit line, you start thinking about a recovery plan. When it drops further to the Red Control Limit line, you execute the recovery plan. One of the major strengths of the Critical Chain approach is its smart and easy-to-use health indicators, which make assessing the health of a large project simple. Critical Chain boils the issue down to verifying the remaining buffer duration. On a 10,000-task schedule, this means you may need to monitor only one project buffer or 50-100 feed buffers at most, a number that decreases as completion milestones are achieved and risks are retired. Buffers are easy to understand, and a simple listing of the remaining buffers compared to the original buffer durations is what many executives like to see on their screen. An important question you must ask yourself when implementing the Critical Chain approach: How should I determine the durations of the Project Buffer and Feed Buffers? PAGE 68

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

You will also need to change several attitudes to successfully implement Critical Chain: ◆ Will you tell team members about the project buffer? If so, how will you tell them? You must protect project buffers in the schedule to meet your project deadline! ◆ How can you make people change from padding their duration estimates to decreasing their estimates (with a lower confidence level)? CC-advocates often talk about going down from a 90% confidence level to a 50% confidence level. Team members basically must give up their personal buffers, which they have gotten attached to. This attitude is usually developed over time, because of project managers’ constant challenging of estimates presented. ◆ What team incentive can you build in for finishing early? How can you get team members to tell you they finished early when estimates are already tight? They may not be impressed if you merely say,“Thank you, you’ve just added two days back into my buffer duration.” How can you maintain healthy levels for the buffers? ◆ How can you ensure buy-in from upper management? Upper management needs to:  Not look at task and milestone finish dates, only the project buffer and project deadline date.  Accept that tasks often finish late (when the probability is 50% for each task).  Monitor buffers instead of milestones. Even though milestones can be used in CC-schedules, their accomplishment should not be monitored by executives, because half of them will slip since they are scheduled based on 50% confidence levels. ◆ Who owns feed buffers and who owns the project buffer? Does the resource manager or project manager own the buffers? Executives or marketing managers may see the buffers as their property. ◆ What will you do when one of the project managers of a project in your program uses more than his buffer and affects the Critical Chain of other project managers? Considering the dramatic change needed in key players’ attitudes, it is obvious that Critical Chain scheduling can only succeed with visible and ongoing executive management support.

Assumptions of the Critical Chain Approach Critical Chain is built on the following assumptions: ◆ Executives’ attitudes will change regarding micro-managing their people to finish all activities on time. ◆ Estimators will stop padding their duration estimates. I observed in a high-tech product-development company that resources were already on a very tight timeline, but were still expected by their executives to decrease their estimates further when they introduced Critical Chain, which created a ridiculous situation. © PROJECTPRO CORP.

PAGE 69

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

◆ You are multi-tasking your resources. If this is not the case, you will not see productivity gains if you change from multitasking to full-focused-tasking in Critical Chain. ◆ Assignments stay fairly constant. If this is not the case, and you switch assignments often, the Critical Chain may flip from one chain to another and buffers may have to be re-evaluated. Project resources should not be constantly diverted to troubleshooting and bug fixing. Instead, a SWAT team should be established to deal with troubleshooting and bug fixing. ◆ You can assess project health based on remaining buffer durations. This is a bit challenging, because if all feed buffers are gone at 80% into overall project duration and the project buffer is at 30% of its original duration, and all system testing still needs to be performed, how healthy is your project? A Risk-Burndown chart that represents time-phased probability driven risk contingency can best answer this question. ◆ Finding the CC can be automated. Currently, there is Prochain as an add-on to MS Project that identifies the Critical Chain.

Best Use of Critical Chain Scheduling In general, Critical Chain can best be applied in shortest-time-possible projects (where the project ideal is time) and in resource-constrained projects such as: ◆ New product development projects ◆ Time-to-market projects Critical Chain schedulers boast shorter durations in projects; for example, they have set the world record on building a house. The approach seems to fit situations best in which time-to-market is important. Time-to-market projects often require very specialized and rare resources, and this approach does take resource constraints into account. Critical Chain is weak in managing cost; it does not have a similar system for cost buffers (cost contingencies) as it does for time buffers (risk contingencies). For this reason, Critical Chain is not e a good fit for cost-constrained or lowest-cost-possible projects. The most useful book on Critical Chain scheduling I found is Project Management in the Fast Lane by Robert Newbold.

PAGE 70

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Earned Value (EV) Scheduling and Earned Schedule What is Earned Value? Earned Value is an approach that establishes a baseline from the cumulated, time-phased costs of an approved project schedule. Earned Value calls these cost values cumulated over the life of a project ‘Planned Values’. The curve is also known as the ‘cost performance baseline’. Project managers then monitor their progress against that cost performance baseline to determine if they are on or behind schedule. They assess project performance by adding up the planned cost values of all WBS-items that are completed, which is known as the ‘Earned Value’. The project health indicator of this Earned Value approach is the comparison of Earned Value to Planned Value. When Earned Value (EV) is equal to or greater than Planned Value (PV), you have earned more than planned and you are ahead of your baseline schedule; the Schedule Variance is then positive. Project managers can also see if they are running under or over budget if they enter actual costs into their scheduling application and compare that to their Earned Value. If Earned Value also exceeds Actual Cost (AC), you have spent less for the progress you made than you had planned to spend; the Cost Variance is positive, and you are making a “profit”.

What is Earned Schedule? Earned Schedule is not a separate scheduling approach but rather an extension of Earned Value that makes the EVM reports easier to read for stakeholders. It stems from the frustration with Earned Value that even schedule slippages are expressed in money rather than in time, like days, weeks or months. Earned Schedule uses formulas like ones in Earned Value to express the Schedule Variance in terms of days (or weeks). Earned Schedule also has similar formulas to predict the total duration for the project.

Earned Value / Earned Schedule Reporting If your clients require you to report project performance in terms of Earned Value, they expect that you present Planned Values, Earned Values and Actual Costs for your project at each reporting interval for the entire project life-cycle. You will have to implement a comprehensive set of rules and guidelines for scheduling that are called Earned Value Management System (EVMS), SAE EIA748C-2013, American National Standards Institute (ANSI), 2013, www.ANSI.org.

© PROJECTPRO CORP.

PAGE 71

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

The Earned Value approach consists of: ◆ Time-Phased storage of the data in the baseline and current schedule. In the baseline, you capture what you ’are supposed to have spent each month for as long as the project lasts. You now have more checkpoints and relevant checkpoints with numbers that can be compared periodically to current actuals. Also, extrapolation and trend analysis are now possible. ◆ Cumulative data: fluctuations are smaller when cumulative numbers are examined instead of per-period numbers. Cumulative data reflect the entire project history. ◆ Charting the Earned Value indicators: Planned Value (PV formerly BCWS), Actual Cost (AC formerly ACWP) and Earned Value (EV formerly BCWP). ◆ Calculating health indicators: CV (Cost Variance), SV (Schedule Variance), CPI (Cost Performance Index), SPI (Schedule Performance Index) and forecast indicators: ETC (Estimate to Complete) and EAC (Estimate at Completion). The latter is compared to your BAC (Budget at Completion), the original approved project budget plus all budget increases, minus decreases from project change requests.

Assumptions of the Earned Value Approach Earned Value approach is built on the following assumptions: ◆ Earned Value is a valid indicator of progress on a project. Research findings are quite convincing on the validity of this approach. ◆ The technique to determine the Earned Value should be agreed upon by stakeholders before the project starts. ◆ Project stakeholders must agree on which method will be used to determine progress. There are several different calculation techniques to establish the value that is earned in a project: percent complete, milestone method, 50-50%, 0-100% and Equivalent Units. These methods are supposed to be inter-subjective methods of determining the Earned Value. Inter-subjectivity is achieved when different people independently arrive at the same Earned Value given a real-life, in-progress project. It is not always possible to achieve consensus on inter-subjectivity. ◆ Stakeholders can agree upon a project’s Earned Value at every reporting period during project execution. Even when a standard technique is used to determine the Earned Value, there may still be contention over the Earned Value of completed work. ◆ Earned Value expressed in dollars is meaningful to all project stakeholders. I have found that this is not always the case. In IT and pharmaceutical projects, budgets are often not allocated, and any progress expressed in dollars has no meaning to stakeholders. Nowadays, we therefore see modifications to Earned Value implementations that use:

PAGE 72

© PROJECTPRO CORP.

Forecasting Programs

◆

◆

◆ ◆

Chapter 2 Choosing the Best Scheduling Approach

 Days/weeks as the unit to express Earned Value, which is called Earned Schedule. You can always combine Earned Value with Earned Schedule to make the reports more meaningful to stakeholders.  Person hours as the unit to express Earned Value (i.e., Earned Work), which requires that you have a resource-loaded schedule and have modeled workloads accurately. Earned Work does not require a bridge with your accounting system, since it does not look at actual cost but at actual hours worked; thus, a timesheet system would be nice to have for Earned Work.  Points as the unit to express Earned Value (i.e., Earned Points), which awards points for starting activities and (more) points for finishing activities. You only need a time model of your project with durations and dependencies, but no resources, assignments, rates or costs. Earned Points is the easiest adaptation of Earned Value and acts as a fallback system that can be applied in almost any situation. Project schedulers and managers know how to implement an Earned Value system. Earned Value follows a well-defined set of rules and requires discipline and diligence. I do come across situations where people violates those rules in the following ways.  Detail tasks that become obsolete are often simply deleted from the schedule (including their baseline values!), rather than inactivated, which affects the cost performance baseline.  The baseline is not supposed to change accidentally or regularly, but only through a formal approval process and formal change requests. Often project managers keep re-baselining their entire project, because it makes them look good every week in terms of Earned Value.  Project change control processes are sometimes not rigorous enough: A scope, quality, schedule, cost and risk impact assessment needs to be made for each change request, which often does not happen.  There are too many overhead activities (meetings etc.) in the project schedule that create too much overhead effort in the schedule. The cost of overhead effort is automatically earned as time goes by. Shrewd schedulers know to stack their schedules with overhead effort. Executives, project owners, sponsors and clients know how to interpret Earned Value indicators. If executives have not been schooled in Earned Value theory, they will not be able to draw valid conclusions from Earned Value reports. Earned Schedule makes reports easier to understand. Performance baseline of a project can be agreed upon. If contracting parties cannot agree upon the performance baseline, which is the foundation of the Earned Value system, EVM falls apart. The progress (Earned Value) can be accessed objectively (when the progress is visible, measurable, verifiable) or at least intersubjectively (when independent

© PROJECTPRO CORP.

PAGE 73

2

Chapter 2 Choosing the Best Scheduling Approach

◆

◆

◆

◆

◆

Forecasting Programs

assessors agree on the amount of progress). Assessing progress is relatively easy in construction, where progress is tangible and can even be made visible during planning using Building Information Modelling (BIM). On the other hand, in software development, progress is not very tangible and requires an expert to evaluate. Therefore, assessing progress in software development is very hard and could become a bone of contention easily. Your scheduling software can generate Earned Value charts and indicators and calculate these values correctly. Not all software applications can do this (e.g., Agile and Critical Chain Applications) or do it correctly (Microsoft Project). On programs with a lot of internal labor, a timesheet system is implemented to determine actual hours worked on the project and the actual cost spent. Many organizations do not collect actual hours worked (via timesheets). Even if there is a timesheet system, it often only feeds the accounting or HR system and not the project management system. Earned Value data is generated in a timely fashion. This is not always the case, I have found, particularly when a project must rely on the accounting department for generating Actual Cost. Actual Costs may only become available halfway into the next month instead of at the start of the month. A procurement and accounting system is implemented to determine actual labor cost, consultant contract cost, fixed-price contract cost, and cost for licenses, equipment and materials for each project. Actual costs need to be transferred into your project schedule. Accounting systems often don’t provide actuals by project that can be fed electronically back into each project schedule and instead require manual data transfer or re-entry effort. Fiscal months are not always aligned with MS Projects calendar month. Bridging software that automates this transfer of data is often very expensive. Formulas to forecast the project end date and final cost are valid. A lot of current empirical research is concentrated around this assumption. Refer to ‘Earned Value Project Management’ by Fleming and Koppelman. Earned Value seems to be losing some fame in recent years, based on the number of jokes and disparaging remarks at conferences on this subject.

As you can see, the list of assumptions for Earned Value is long, and you must carefully examine your situation to confirm it fits your project. Earned Value is easier to implement when companies have solid historical information from previous similar projects. Companies like Bechtel, for example, can pull up records for similar tasks performed with planned versus actual duration and planned versus actual dollars. This makes creating the Planned Values easier, and it makes the Planned Values more reliable.

PAGE 74

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Best Use of Earned Value Earned Value can best be applied in lowest-cost possible projects or cost-constrained projects. This method is often combined with a Critical Path approach when time is of the essence since the Critical Path gives insight into how the project duration can be shortened. Earned Value standards now state explicitly that Earned Value should always be combined with Critical Path, because when Earned Value variances look good and imply that a project is on schedule, your Critical Path may show the project is slipping. This happens when project teams make a lot of progress on non-critical tasks ahead of schedule (which adds to Earned Value), but make little progress on critical tasks that drive overall project duration. Progress on critical tasks is important! Typical projects where Earned Value is used include construction, government subcontracts (such as public works projects) and certain defense contracts (with a low degree of R&D). Government subcontracts are often cost-constrained due to fiscal yearly budgeting of government expenditures; the government often has a strong interest in keeping cost within reason. Furthermore, public opinion is often strong and negative when a government project runs over budget; citizens will say: Our government is wasting our money! An authoritative book on Earned Value is Earned Value Project Management by Quentin Fleming and Joel Koppelman, the inventors of Earned Value.

Earned Work (EW) Scheduling What is Earned Work? Earned Work is a relatively new approach that is similar to EV but expressed in terms of person hours of work rather than in money terms. At each status-point, you determine the Earned Work value and compare it to Planned Work and Actual Work values. The Planned Work values are calculated from detailed resource-loaded schedules. When a schedule baseline is set, time-phased work values are cumulated to Planned Work values over time. Earned Work is the sum of all Planned Work values of completed activities. We developed this new approach at ProjectPro in response to clients that wanted to implement Earned Value but did not have the maturity to do so, or they did not have an accounting system that could transfer Actual Cost values to the scheduling application. Earned Work requires: ◆ A resource-loaded schedule with workloads modeled accurately © PROJECTPRO CORP.

PAGE 75

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

◆ A baseline schedule and maintained integrity of the baseline schedule ◆ Regular updating of the project schedule Output of the Earned Work approach looks like this (Output from CurvesPro, a Microsoft Project add-in from ProjectPro Corp):

Part of the underlying dataset is as follows (this is also output from CurvesPro):

What this table shows: As of the status date, this project team has worked fewer hours (Actual Work) than it planned to work (Planned Work); the cost will therefore end up higher than budgeted on this project. The project team has earned less (Earned Work) than they originally planned (Planned Work); the project is running behind and will take longer than the promised end date.

PAGE 76

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Actual Work value is achieved by regularly updating the schedule, ideally by using a timesheet application (such as Project Online / Project Server from Microsoft) that collects actual hours worked from team members for each assignment and transfers these actual hours back into the Microsoft Project schedule. Regular updates will increase accuracy sufficiently to provide reliable predictions. Update questions to ask: ◆ To collect Actual Durations ask: How many days/hours have you actually worked on this task so far? ◆ To collect Remaining Durations ask: How many more days/hours do you need to complete this task?

Assumptions of the Earned Work Approach Earned Work is built on the following assumptions: ◆ Effort (labor) is the biggest cost factor in the project. Other costs (such as materials, equipment, facilities, travel, licenses, etc.), have less impact than labor cost. ◆ The organization has a system to track actual hours worked by activity in each project, whether by week or by month. The highest accuracy will be achieved with a timesheet system that transfers actual hours by assignment back into the schedule application every week or every month. An example is the timesheet in Microsoft Project Web App from Project Online / Project Server that can transfer actual hours back into Microsoft Project. ◆ Project managers create resource-loaded schedules and model effort on each activity accurately. ◆ Executives can get used to having project progress and performance expressed in terms of earned hours (Earned Work) compared to actual hours (Actual Work) and planned hours (Planned Work). In our experience, this is not a big issue for executives. ◆ This Earned Work method will be proven to be valid in terms of predicting project performance. ◆ As a new approach, unlike Earned Value, no research has yet been performed to validate ProjectPro Corp’s Earned Work approach on project performance predictions. As you can see, this list of assumptions is a lot shorter than the list for Earned Value, demonstrating the broader applications for Earned Work.

© PROJECTPRO CORP.

PAGE 77

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

Best Use of Earned Work? Earned Work can best be used in situations where cost needs to be minimized, because its charts depict labor hours (which directly affect cost in labor-intensive projects, such as software and new product development). For the same reason, we also recommend Earned Work when project cost is a severe constraint. However, when labor costs are minor compared to material, equipment or facility costs, we recommend Earned Value instead. Earned Work is also one of the recommended approaches when resources are very constrained; the project cannot get additional people and must make do with existing available resources. The only books that briefly discuss this approach are my Forecast Scheduling books. This approach has been automated in a new add-in for Microsoft Project called CurvesPro (from ProjectPro Corporation).

Choosing the Right Scheduling Approach There is no single, best approach for all situations. The best approach for scheduling your project depends upon several key factors: 1. What is the purpose of your scheduling effort?  Selling a project,  Delegating activities  Tracking actuals, or  Forecasting the finish date and project cost. To sell a project, you only need a simple Gantt Chart. To delegate activities, you only need a WBS with activities and scheduled dates. Only when you want to track and forecast a project do you need one of the five approaches we discussed. 2. What is the most important ideal in your project? What is the Critical Success Factor in your project?  Highest satisfaction  Highest scope & quality  Shortest time possible  Lowest cost possible  Lowest risk You must ask yourself: Which one of these is dominant? If that is too difficult, allow yourself to choose two factors instead of one. If you still have difficulties, PAGE 78

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

approach it from the opposite side and ask yourself: What is the least-dominant force-factor? 3. What is the most important constraint in your project? What is the Critical Failure Factor in your project?  Knowledge  Time  Cost  Resources, or  Risks 4. What is the current scheduling approach used within your organization? The possibilities include: Agile Scheduling, Critical Path Scheduling, Resource Critical Path Scheduling, Critical Chain Scheduling, Earned Value or Earned Work Scheduling. It is not a smart idea to stray too far from what your organization currently is doing. If you do that, you will end up spending too much time in a political fight on how to control your project instead of actually controlling your project. 5. What is the project management maturity level in your organization? This question has a lot to do with the previous question, but also with a more fundamental question: How much effort is your organization willing to put into project management maturity? The past success and failure rate of programs may be an indication of management’s willingness to invest in advancing your organization’s project management maturity. 6. What is the size of your project? Programs can easily result in very large schedules with 10,000 tasks or more. Is your organization able to support creating AND maintaining such large schedules with a preferred approach? We recommend you experiment with new scheduling approaches first on a small scale using small projects, rather than on your largest program. We often see that an organization suddenly feels the need to enforce strict project controls when a large program comes around, whereas nobody cared when your organization only had small projects. This does not bode well for a program unless specialized consultants are hired. Based on the answers you gave for questions 2 and 3 above, we can make the following recommendations in the Project Ideal and Constraint Matrix (PIC-Matrix). When the name of the approach is shown in a cell, we recommend using that approach in your project. When the name of an approach is struck through like this, we recommend AGAINST using that approach. We use the following abbreviations for each scheduling approach: ◆ AG = Agile ◆ CPM = Critical Path Method © PROJECTPRO CORP.

PAGE 79

2

Chapter 2 Choosing the Best Scheduling Approach ◆ ◆ ◆ ◆ ◆

Forecasting Programs

EV = Earned Value EW = Earned Work CC = Critical Chain RCP = Resource Critical Path SIM = Monte Carlo Simulation: even though Monte Carlo simulation is not an approach for scheduling projects, it can improve many of the other approaches so significantly that we recommend it. Simulation can be performed as a modeling approach by itself using Polaris by Booz Allen Hamilton, RiskyProject by Intaver, or you can use add-ins for Microsoft Project like @Risk and Risk Optimizer by Palisade, or Full Monte by Barbecana.

Sometimes a combination of two methods is the best way to go in a situation (cell in the matrix below) and I indicate this with a plus sign (+). Our recommendations are:

Summarizing the grid: ◆ We recommend Agile (AG) when knowledge is constrained, or when the ideal is the highest satisfaction or highest scope & quality factor, since Agile is a very customeroriented approach. ◆ We recommend Critical Chain (CC) when time is the project ideal, except for when cost is the constraint. CC is a very time-oriented approach to scheduling and has been proven to shorten projects, however, it is not suitable as an approach to control cost. PAGE 80

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

◆ We recommend using Critical Path Method (CPM) when time is the dominant ideal or constraint. ◆ We recommend Earned Value (EV) approach when lowest cost is the project ideal, but notice that we always recommend it to be combined with CPM or RCP. We also recommend EV when cost is the biggest constraint. EV is strong in the cost ideal and constraint, because EV measures cost. The irony is that EV is costly to implement. Earned Value is the only approach that provides integrated time and cost control by itself. Thus, it also fits when time is the ideal and cost is the constraint. ◆ We recommend Resource Critical Path (RCP) approach in any resource-constrained project. ◆ We recommend Earned Work (EW) when lowest-cost is the ideal (except when knowledge is the constraint) or when the cost is the constraint as well as when resources are constrained. ◆ We recommend enhancing the scheduling approaches with simulations (SIM) whenever risk is the dominant ideal or constraint. Simulation of schedules can quantify risk in a project in terms of time and cost. In a Risk-ideal and Riskconstrained project, you can only do simulation or apply other risk management practices not discussed here. Recommendations AGAINST the use of an approach: ◆ We do not recommend EV or EW in knowledge-constrained projects, because it is too hard to create a performance baseline in projects that often change in direction. ◆ We do not recommend Critical Chain whenever cost is an ideal or a constraint. The CC-approach is purely time-oriented and does not provide visibility on the cost side of a project at all. There are no valid indicators for cost in the CC-approach other than actual cost, which is available to any approach. ◆ We do not recommend using CPM when resources are constrained, because the CPM-approach assumes having access to unlimited resources. Additional remarks: ◆ If you categorized your own project and found its cell in the matrix, you probably have found that you are using the approach we recommend. If you are currently using a different approach, you should explore if you can still benefit from switching over to the approach that we do recommend. ◆ None of the approaches we discussed measures satisfaction, quality or risk. ◆ As the saying goes: If you don’t measure it, you cannot manage it. It was therefore harder to recommend any approach in these cells. We must conclude from the matrix that the currently available scheduling approaches seem to short-change highestsatisfaction and highest-quality projects as well as lowest-risk projects:  You will need a quality management system in addition to your project information system. In software development projects, separate systems that track requirements and bugs are often used. © PROJECTPRO CORP.

PAGE 81

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

 For lowest-risk projects, we already recommended simulation, but new techniques like risk event management, expected monetary value and the risk driver approach have been developed. In lowest-risk projects, you will need to combine those techniques with your scheduling approach. ◆ You probably noticed that some cells have very few recommendations. Projects in these cells are very rare, such as a lowest risk, risk-constrained projects.

Combining Approaches Several approaches can be combined (checkmark); other combinations will not be fruitful (x):

You can combine with:

AG

Approach you currently use: AG CPM RCP CC   

EV 

EW 

SIM 



✓

✓

✓

✓

✓

✓

✓



✓

✓

✓

✓

CPM



RCP



✓

CC





✓

EV



✓

✓



EW



✓

✓

✓

✓

SIM



✓

✓

✓

✓

✓

✓ ✓

Some approaches are made for each other and complement each other well; I call these ‘Happy Couples’. Other combinations do not marry very well, and I call those ‘Miserable Couples’.

Happy Couples CPM happy with EV The Critical Path (CPM) and Earned Value (EV) approach are made for each other and often used together on projects. The CPM is a very time-oriented approach and provides ideas on how to improve the time dimension, whereas the EV-approach is very moneyoriented.

PAGE 82

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

The Practice Standard on Earned Value from PMI® even states that Earned Value should always be done in combination with Critical Path, because if you make a lot of progress on non-critical activities and none on critical activities, the EV indicators may be positive but the project will be late.

RCP happy with EV The Resource-Critical Path (RCP) and Earned Value (EV) approach are made for each other in resource-constrained situations where CPM fails. A resource-loaded schedule drives cost, and the cost-curve will be very accurate. Once a resource-loaded schedule is workload-leveled, it is ready to be baselined. The baseline schedule can then be used to establish your cost performance baseline (Planned Values) for Earned Value Management (EVM).

EW happy with EV Earned Work and Earned Value use very similar charts and progress indicators, so you can easily combine them.

Simulation is Happy Simulation can be combined with all predictive approaches to scheduling except the adaptive approach (Agile). Simulation is not a project scheduling approach, but it makes the scheduling approach better and more robust.

Miserable Couples AG unhappy with any other approach The Agile (AG) approach, as the only adaptive scheduling approach, cannot be combined with any other (predictive) approach. The AG-approach allows constant WBS and activity changes. All other approaches require the WBS and activities to stay the same (subject to change requests). Particularly when you apply EV, your change control system needs to be very robust. CPM requires your project to be planned to the finish, while Agile does not require a complete plan to the finish date. In the next chapter (see page 87), we will explore how Agile and CPM can be combined, and what compromises each approach needs to make for the combination to work. Only if both agilists and CPM-proponents are willing to make © PROJECTPRO CORP.

PAGE 83

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

some compromises can Agile be combined with CPM; we will describe in detail what compromises need to be made and how this can work (see page 87). If the WBS is not stabilized in CC, the baseline buffers must be revised constantly, which makes comparing buffers to their original size futile. EV requires a stable baseline of planned values to measure against. If the WBS and activities change constantly, the baseline would change constantly as well and the EV-health indicator would be useless. Maintaining the integrity of the EV-baseline is a lot of work and a real challenge in very turbulent projects, like software. We often see that project managers are unable to maintain the integrity of their schedule baseline. Too many project managers simply re-baseline their entire project over and over, which makes them look good (if nobody pays attention to the issue of moving the target to the project rather than moving the project to the target).

CPM and RCP unhappy with CC Often the CPM and RCP-methods use 90% confidence level estimates, because no effort is made to squeeze 50% estimates out of team members; in contrast, the CC-approach always expects you to use 50% confidence level estimates. A 90% confidence level means that tasks come in at or ahead of their original estimate in 90% of the cases and run over in the remaining 10% of the cases. Because the basis for estimation is often different in either approach, you cannot combine CC with CPM- or RCP-approaches, unless you are willing to maintain two schedules simultaneously and perform double bookkeeping (scheduling), which is too much to ask in most situations.

CC unhappy with EV You cannot combine an Earned Value approach with a Critical Chain approach. Critical Chain schedules tend to be very aggressive, and creating an Earned Value performance baseline based on a very aggressive schedule would cause constant and huge schedule slippages indicated in the Earned Value status reports. As a result, you would be running behind schedule and over budget for the life of the project. Also, it is too difficult to allocate values to be earned to feed buffers and project buffer line items that are artificially inserted in a CC-schedule. In other words, this is not a happy combination for project managers.

PAGE 84

© PROJECTPRO CORP.

Forecasting Programs

Chapter 2 Choosing the Best Scheduling Approach

Validity of the ‘Project Ideal and Constraint Matrix’? I have tested this model in many courses I’ve taught and asked hundreds of students to characterize their projects in terms of dominant project ideal and project constraint. Almost all participants have been able to do this (sometimes with some help). People do not seem to have difficulty categorizing their projects in an empty matrix. That is a sign of validity of the dimensions of ideal and constraint and finding out which one is dominant on each axis. Students first found the cell of our empty Project Ideal and Constraint Matrix (PICMatrix) to which their project belonged. Without my knowing what kind of project, the student was involved in, and without the student knowing my grid full of recommended approaches, I would predict what scheduling approach they were currently using or should consider using (AG, CPM, CC, RCP, EV or EW) and which ideals they tracked closely (requirements, issues, contracts, stakeholders’ satisfaction, publicity). Often, I could also predict what scheduling applications they used (Microsoft Project, Primavera or ProChain) to manage their project, since each application supports some approaches best. I could even predict whether they had considered using or were using Monte Carlo simulation. This experience validated the model in a limited way. When students found that they were using a different approach than recommended, they often seriously considered switching, which convinced me there is validity in this model. In my consulting work, the matrix helps me recognize and categorize projects very quickly after asking just two key questions: What is your dominant project ideal? and What is your dominant Project Constraint? Once I know those, I can immediately be effective as a consultant. I typically get involved in hundreds of different projects and programs every year (through my students and consulting clients) and often only late in the project execution phase when the pain is already felt. Having a quick diagnostic tool helps me recognize problems before knowing all the details of the situation.

Conclusions We have now caged all the wild animals in the zoo of our project management world: Each scheduling approach now has its own cell (cage). Each approach turned out to have its own assumptions, and we’ve revealed them to determine in which situation they can best be used. If you know your dominant project ideal and constraint, you can find the scheduling approach that we recommend in our Project Ideal and Constraint Matrix (PIC- Matrix).

© PROJECTPRO CORP.

PAGE 85

2

Chapter 2 Choosing the Best Scheduling Approach

Forecasting Programs

Our Project Ideal and Constraint Matrix (PIC-Matrix) is a situational framework to determine the best scheduling approach for your project. This matrix and its recommendations seem valid to me but still need to be validated on a larger scale and by other practitioners.

Bibliography Rubin, Kenneth S., Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley Signature Series (Cohn), 1st Edition Fleming, Quentin W. and Joel Koppelman, 2000, Earned Value Project Management, second edition, Newton Square, PA, Project Management Institute Lewis, James P., 1995, Project Planning, Scheduling & Control, Chicago, IL, Irwin professional Publishing Newbold, Robert, 1998, Project Management in the Fast Lane, Boca Raton, FL, CRC Press LLC Uyttewaal, Eric, 2001/2002/2003, Dynamic Scheduling with Project 2000/2002/2003, New York, NY, International Institute for Learning, Inc. Uyttewaal, Eric, 2010/2013, Forecast Scheduling with Project 2010/2013, Ottawa, Ontario, ProjectPro Corporation. Woolf, Murray B., 2012, CPM Mechanics, The Critical Path Method of Modeling Project Execution Strategy, ICS-Publications

PAGE 86

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

3

Learning Objectives After this chapter, you will: ◆ Know the strengths and weaknesses of Agile and Critical Path Approach to Scheduling ◆ Be aware of the compromises needed to convert an Agile schedule to Critical Path ◆ Convert an Agile schedule to a Critical Path AND Agile schedule ◆ Realize the benefits for programs of having Agile schedules that can easily be switched to Critical Path

© PROJECTPRO CORP.

PAGE 87

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

Managing my Program is like Herding Foxes, Roosters, Giraffes, Lions, Rabbits and Bees. Bob asks, “What animals are you dealing with on your program? Your team members, sponsors, stakeholders?” Nob looks confused. “What do you mean ‘animals’?” “I mean it figuratively. Each animal has a certain character. What characters or personalities do you have on your program? Describe them as comparable animals.” “Well, somebody stole my stash of petty cash last month, so I guess I have a fox on my project. One of my stakeholders is such a power monger that I treat him like a lion, the king of the jungle. He could kill anyone. Then I have many worker bees, so bees, I guess.” “Any rabbits?” Bob asks. “Those are the ones who want to go so fast that they don’t pay attention to what really needs to happen, like the tasks on your critical path.” Nob is getting into it now and shares enthusiastically: “Oh, yes, some of those! I have some deer-in-the-headlights too. They’re so overwhelmed that they don’t know where to start. They’re just like … frozen!” “One of my team members just can’t shut up and makes statements when he really shouldn’t. He’s like the morning rooster!” Bob grins. “One of my stakeholders has such overview of the program, she towers above all the rest, just like a giraffe. She can see things coming from far away.”

PAGE 88

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Introduction In the previous chapter, we discussed in which situations Agile makes sense and where not. In this chapter, we will explore the question: Can Agile AND Critical Path co-exist in one schedule? This is an important question we are regularly asked by program managers who struggle with integrating an Agile schedule from software developers with a Critical Path schedule from the hardware engineers. This is an issue in all new product development programs, advanced system programs such as defense systems or aerospace R&D, and any program where hardware AND software are created. Agile scheduling belongs to the school of adaptive scheduling. Critical Path belongs to the school of predictive scheduling. At first sight, this makes them incompatible with each other. A while ago, I heard an Agile presenter say, “Critical Path is anti-Agile!” I don’t think this is true. The reverse, Agile is anti-Critical-Path, isn’t true either. The real dichotomy is Agile versus Waterfall. Waterfall is not Agile, and Agile will never be Waterfall. Agile and Waterfall are opposites! Waterfall schedules stem from an era of sequential system-development lifecycles (SDLC) where a software development project was typically planned out in a sequential way delivering one final product to the client at the end of the project (a.k.a. the Big bang or Big-Design-Upfront approach). The SDCL typically consisted of the following phases: Plan, Design, Build, Test and Deliver. When you put these phases into a schedule, the typical waterfall image appears:

If you look at the next picture of a typical Critical Path network diagram of a Database Application Development Project, you can see that Critical Path scheduling is not the

© PROJECTPRO CORP.

PAGE 89

3

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

same as Waterfall scheduling: All scripting is scheduled in parallel; it does not matter which script you create first. Where is the waterfall in the next picture?

You can see many paths running in parallel, which is typical for Critical Path scheduling. This Critical Path looks like a cross. Critical Path networks seldom look like waterfalls, because networks always have many paths running in parallel. From a high level, most Critical Path networks look like a diamond. Critical Path does not describe what you should do and when you should do it, like Agile does. Critical Path simply expects that you define deliverables (activities) and link them all. In fact, the concept from Agile to ‘create products-of-business-value early’ for the client can be seamlessly captured in a Critical Path schedule; you just need to define your iterations of the products (‘builds’) in such a way that they appear in the WBS, then link them up through their activities. Critical Path and Agile are NOT each other’s opposites!

PAGE 90

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

On a side note: You can even see a clear waterfall in a high-level view of any sprint schedule as illustrated below:

3 Isn’t it somewhat ironic that a high-level Agile schedule with only the sprints showing looks like a waterfall! Am I the only one who thinks that is funny?

Agile and Critical Path in One Schedule Once I figured out that Critical Path Method (CPM) is not the opposite of Agile, I started to explore the following question: Can an Agile schedule be converted into a Critical Path schedule and vice versa (without duplicating the schedule)? In other words: Can we simply apply a Critical Path view to an Agile schedule and see something that looks like a Critical Path? And, of course, the other way around: Can we create an Agile view in a Critical Path schedule that keeps Agile fans happy? Here is what I found in my explorations: ◆ Tip► It is possible to switch between an Agile view and a Critical Path view on your project without having to copy the schedule or even having to re-work it. So, you can keep an Agile view and a Critical Path view on the project in one MPP-file (or in one Project Server / Project Online schedule). You do not need to compromise the unity-of-data principle by replicating your schedule, which would also require you to do double bookkeeping (schedule keeping) from then on. When you update the Agile schedule, you are updating the Critical Path at the same time. ◆ Tip► You can switch back and forth between Agile and Critical Path views with two mouse clicks, so you can keep your Agile stakeholders happy at the same time as you serve your Critical-Path-stakeholders. If you keep the deliverable-oriented WBS in the Task Name field and use a new view for Agile to display the sprint-oriented breakdown of the project, the Critical Path view will look like the screenshot below. Notice the deliverable-oriented WBS in a custom-

© PROJECTPRO CORP.

PAGE 91

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

made view called Gantt Chart – Critical Path. Also notice the custom-made field Sprints in which all line items are mapped to a particular sprint):

Notice the tags entered in this field that prepare this Critical-Path-WBS to be converted to an Agile-WBS with Sprints.

Here is the same schedule in its Agile representation using a custom-made view called Gantt Chart – Agile Sprints (with a custom grouping on the Sprints field to convert the WBS from Critical Path to Agile):

These two fields display how we converted Agile estimates in points to person hour estimates for Critical Path: more on this will follow.

PAGE 92

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

You can explore this conversion yourself by opening the file: Intranet Project - Agile and Critical Path v3.mpp from the download-files that come with this textbook. 10 You can see that this schedule looks like a veritable Agile schedule with: ◆ Sprints that are all one-month long; there is a July and August sprint. ◆ One set of activities fits neatly into the window of July and another set in August. Remaining activities are in the backlog, which can contain an unlimited number of items, theoretically. ◆ There is a backlog with many items in it (even though, only one item fits in the previous screenshot) where items can be added or removed freely. ◆ No dependencies are shown; they were taken off using ribbon Format, button Layout. ◆ Agile estimates are the primary input to arrive at person hour estimates using the input field called Agile Points (3.87h/pt) as shown in the screenshot and one customized field with a formula (called Hours (Agile pts * 3.87); we will explain later how we arrived at the conversion factor of 3.87. Looks pretty good, eh? However, there is bad news too: Both parties need to compromise!

Compromises Needed from Agile Agilists will have to make small compromises without having to give up any of the core concepts of Agile (which has been confirmed by at least 20 Agile project managers I consulted): ◆ Agilists will have to complete their backlog as soon as possible (i.e., do thorough ‘backlog grooming’ upfront) and pay more attention to this than they would otherwise. A complete backlog will allow the project manager to forecast the entire project, not just the next sprint. ◆ Agilists will have to estimate all items in their backlog (using their own way of estimating, like Fibonacci estimating), which should not be a big deal. ◆ Agilists will have to identify all relationships between their user stories and/or activities (just like in a Critical Path schedule) including all items in their backlog.

Compromises Needed from Critical Path Critical Path folks – let’s call them ‘Forecasters’ – will also have to give in a bit. ◆ Forecasters must allow Agilists to have their own WBS view organized by sprints (in addition to their own deliverable-oriented WBS). 10

You can download these files from: www.ProjectProCorp.com under Books, you will find a free Download Files product. © PROJECTPRO CORP.

PAGE 93

3

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

◆ Forecasters must allow Agilists to continue estimating in their own way (such as Fibonacci points) and do the extra work to convert those Agile points into person hours; I will show you how in this chapter. ◆ Forecasters should allow Agilists to continue adding and removing items from the backlog without insisting they fill out Change Request forms. This is not a big compromise unless you also have to do Earned Value Management (EVM), which requires a complete WBS upfront and formal change requests after that. Even if you have to apply EVM, you can still allow Agilists to add and remove items from the backlog as long as they exchange items of equal value (points) every time. To add a new feature (user story), the client will have to drop an item of equal value (points) that is currently in the backlog. In this way, you can keep stability and continuity in your forecasts. ◆ Forecasters should accept a few more Start-No-Earlier-Than (SNET) constraints into their schedule, because each activity needs to be forced into a particular sprint (i.e., month) with a fixed start and fixed end date (rather than letting it be scheduled freely by the Microsoft Project schedule engine). This compromise is somewhat painful, because SNETs can fragment the Critical Path (for more information on this issue, please refer to my other textbook Forecast Scheduling, in which I explain how to handle this). Add-ins can handle these situations gracefully and quickly, like our own PathsPro. 11

Can You Live with the Compromises? Tip► If both parties are willing to live with these compromises, you can have an Agile-view AND Critical-Path-view that live happily side-by-side in your single MPPfile (Project Server / Project Online schedule). So, you can have your cake and eat it too!

One difference between the Critical Path and Agile version of the schedule: in Critical Path schedules, all activities are typically linked up, whereas in Agile scheduling the project manager would only enter the most pertinent links, if any at all. Leaving open ends in the network logic wrecks the Critical Path calculations, so Critical Path requires complete and correct network logic, which results in a network with a single ending point. Thus, the Critical Path view always displays complete network logic. In contrast, the Agile view shows fewer links, and there seem to be many open ends in the network, even though all tasks may be linked in fact. Tip► If it turns out to be too hard to get your Agile team to identify all dependencies

between their activities, you could create dependencies between the Sprint summary tasks instead (violating our best practice to keep logic on activities), but that would be 11

See our website www.ProjectProCorp.com under Software.

PAGE 94

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

our fall-back plan. Also, the sprint breakdown needs to be your primary breakdown, because you cannot create dependencies on group summary line items. Critical Path does not care about Waterfall; it just cares about explaining the project duration by identifying what activities drive the duration and forecasting the project. Wouldn’t you want to be able to forecast your project with Critical Path AS WELL AS manage it in an Agile way? Why would you NOT want the benefits of both Agile AND Critical Path in your project in one schedule, in one file?

Agile AND Critical Path in One Schedule: How-To We have seen the differences between Agile and Critical Path. So how can these seemingly incompatible approaches to scheduling projects be reconciled in one scheduling application and in one file? The real question then becomes: Can an Agile schedule AND a Critical Path schedule live side-by-side in a single schedule file? Can an Agile schedule be converted with a click into a Critical Path schedule? To capture an Agile and a Critical Path schedule in one schedule and still comply with the principle of Unity of Data (no duplication or overlaps between items in both schedules), we will have to bridge several difficulties: ◆ Can Agile estimates be converted into Critical Path estimates? The problem here is that an Agile schedule does not have estimates expressed in time units, such as: ‘This task will take me 5 person days of work.‘ Agile estimators use different units of t-shirt sizes (S, M, L, XL, XXL) or Fibonacci Sequence estimates (1,1,2,3,5,8… summing up the previous two numbers to create the series). Agile estimators often receive a fixed budget (e.g., 1,000 story points) and then must distribute this budget over a certain number of user stories (activities). A Critical Path schedule requires time estimates (person days, business days or calendar days) on each task. The Gantt Chart has a Georgian calendar timescale, so a Gantt Chart can only be created with time estimates, duration or effort estimates. We will discuss how to convert Agile estimates into time estimates in the next section. ◆ How can we swiftly switch from an Agile work breakdown structure to a Critical-Path work breakdown structure and back again? We will discuss this later (see page 97). ◆ Scope emerges in Agile, whereas scope is expected to be determined early in Critical Path, after which it should stay somewhat stable. We will discuss this later (see page 99).

© PROJECTPRO CORP.

PAGE 95

3

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

◆ Can the items in an Agile product backlog be planned such that the Critical Path can be created to the end of the project? To satisfy the need of clients and senior management to see the whole picture of the project to its end, Agilists must be prepared to estimate and plan the items in the product backlog to project the entire endeavor instead of only a small part of it. Agilists must be prepared to use the same estimating techniques they use for the next sprint for the entire product backlog, even if only to get a rough idea for the entire project as it is currently known. We will have to overcome these challenges to be able to create the Agile and Critical Path representations from one project database.

Can Agile Estimates be Converted into Critical Path Estimates? To do this, the Agile points must be captured in an extra number field (Number1, etc.) in Microsoft Project that you rename, for example, ‘Agile Points’. Then you use the conversion factor to convert these points into person days (the unit of measure for effort called Work in MS Project). Then you can copy and paste these effort values into the Work field in MS Project; make sure you first set its default time unit to the right time unit (Hours or Days) in File, Options, tab Schedule, field Work is entered in. Trap! You could Paste Link them to have them automatically updated, but this method makes the screen flash often as all the re-calculations happen, which is not pleasant and we, therefore. do not recommend it. Agile does not like to work with time estimates for effort or duration. Agilists do not like to talk in terms of business days or person days. Agile uses relative sizing of tasks and estimates: If you have 100 points to divide over these 10 user stories (tasks). how many points would you assign to each story (task)? Tip► Let’s not forget, however, that Agilists have already fixed the number of team members in the sprint team to a set number. For our example, let’s consider an Agile team consisting of 8 people. Agilists have also fixed the length of the Sprint window to a certain number of days. If your sprint is four weeks, one person has an average of 20 person-days (minus national holidays), so an Agile team has essentially 8 * 20 = 160 person days of effort to spread across the user stories!

Once you realize this, you can calculate the conversion factor between Agile points and the person days of Critical Path: 100 Agile points = 160 person days, or 1 Agile point = 1.6 person days.

PAGE 96

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

To capture this in another manner, calculate Number2 field (click ribbon Format, button Custom Fields, button Formula) by adding a formula in the Number2 field: [Number1] * 1.6 Tip► Once you have calculated the conversion factor for your project, you can convert the Agile points to person day estimates and enter these effort estimates into your Critical Path schedule. First, make sure the task Type is set to Fixed Units for all tasks. Just copy Number2 values into the field Work, first making sure that the time unit is what you need it to be (ribbon File, item Options, tab Schedule, field Work is entered in). You can copy an entire column of estimates in a single copy & paste operation regardless of how many tasks are in the schedule. Right-click on column heading Number2 and click Copy, then right-click the target column-heading titled Work and click Paste. You will see that all estimates are now transferred from Number2 into Work. (Don’t do this in the master schedule!)

These steps will allow you to convert your Agile estimates into Critical Path estimates.

Switching Swiftly Between an Agile and Critical Path WBS We can solve the battle between two dramatically different breakdown orientations by entering the primary breakdown orientation in the Task Name column in MS Project (either the Agile or the Critical Path WBS) and tagging each item in the original breakdown structure that we want to see in the secondary breakdown structure. You can use one of the extra Text fields to tag all items. With the Grouping feature in MS Project, we can then create a grouping for the second breakdown orientation that other stakeholders want to see. Doing it this way will allow you to swiftly switch back and forth between a Critical Path breakdown structure and an Agile breakdown structure. (BTW this is how I created the previous two screenshots). You can switch between them with only two mouse clicks by switching views. The only questions you then must answer are: Do I enter my Agile sprint breakdown structure into the Task Name field in MS Project or the Critical Path Work Breakdown Structure (WBS)? What do I want to be my primary breakdown structure? The following screenshots in this chapter are, in fact, two different views of the same project schedule file. With two clicks, you can switch back and forth between the Agile and the Critical Path view depending on which stakeholders you are talking to and which orientation they prefer to see. If you create the two representations of your schedule as two separate views in Microsoft Project, you can convert your schedule in a few clicks between Agile and Critical Path. © PROJECTPRO CORP.

PAGE 97

3

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

The steps for creating views are discussed in my Forecast Scheduling books: the 2013 book on page 551 and the 2010 book on page 556.12 The starting Critical Path schedule could like this:

And after clicking ribbon View, bottom part of the button Gantt Chart and clicking the name of the newly created view, you will see this:

12

See www.ProjectProCorp.com under Books.

PAGE 98

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Scope Emerges in Agile; Critical Path likes Early and Stable Scope Methods to address this issue: ◆ Allow customers to swap user stories (features) of equal size: Item X had 50 points and is not needed any longer. The client wants two new items of 25 points each (50 points together), so the client can add these two items in exchange for dropping item X. ◆ Traditional Change Control Process, which must be a lean and mean process or ‘agile’ process ◆ Velocity stabilization after two sprints: After two sprints, the team should have learned the strengths and weaknesses of each team member and have a clearer idea how many points can reasonably be done in each future sprint. Perhaps this new knowledge allows more items to be added if the original velocity was pessimistically estimated.

The Struggles of Critical Path We can go one step further and explore if there are extra benefits to be enjoyed when combining Agile and Critical Path in one schedule. Will this address some of the weaknesses of Agile and Critical Path?

All Tasks Need to be Linked Critical Path needs all activities linked, and these links must be correct. In software projects, activities are often not related and can be done in any order; these activities do not have links. The most extreme case I have come across is in database development projects, where typically many small scripts need to be coded, but these scripts can be completed in any order with no inherent logic to the sequence. So, in database development and software development in general, people think dependencies are not all

© PROJECTPRO CORP.

PAGE 99

3

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

that ‘necessary’, whereas Critical Path still requires the dependencies to be set. People forget that it is entirely legitimate to set the dependencies in the following way:

You can see the many parallels in the network logic; the developer can pick any script to work on first. Huge overallocations for our poor developer.

You can see that: ◆ The network logic is complete and correct (for as much as I know about database application development). ◆ There is a Critical Path: the one database script that takes a little longer (task 12 with 4 days) ends up on the Critical Path. ◆ The workloads for the developer are not leveled and the current finish date for the project of 10/24 (Oct. 24) is not feasible.

Many Dependencies are, in Fact, Resource Dependencies A resource dependency occurs when one resource must do two tasks, A and B at the same time; the resource needs to (arbitrarily) choose to do A first and B next, or the other way around. The perfect example is the database development project schedule we just saw. The Critical Path as it was first formulated in the late 1950s was built on the assumption that the project manager would have access to unlimited resources, and it deals with logical dependencies only, not resource dependencies. For years, schedulers have modeled resource dependencies by creating extra logical dependencies. However, the PAGE 100

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Critical Path 2.0 Standard 13 as formulated in 2011 by an international working group improves the Critical Path to allow for resource dependencies. The previous example looks like this after leveling and after resource dependencies have been identified:

3

After using the automatic workload leveling features in Microsoft Project, the realistic finish date is forecast to be 11/15 (Nov. 15). The schedule now has a Resource-Critical Path (see page 62 for a brief explanation and my book Forecast Scheduling for a more elaborate explanation of the Resource-Critical Path and how to identify it in resource-constrained schedules). The previous chart was created by PathsPro 14, an add-in for Microsoft Project, which can find Resource-Critical Paths in resource-constrained, workload-leveled schedules.

All Tasks Need a Duration Estimate Critical Path needs all tasks to have a duration estimate, because otherwise the scheduling engine cannot perform its forward and backward passes to calculate the earliest and latest finish dates for all activities, and, hence, the Total Slack (Total Float). Software engineers find it particularly hard to predict the future and struggle to come up with decent estimates. Agilists do not tend to estimate the items in their backlog.

All Tasks are Sequential, Not Iterative For scheduling applications to do their work, they must be told in which order to schedule tasks. Scheduling applications cannot handle iterative type of work very well. For example, if you have an unknown number of revisions by the client of the detailed 13 14

See www.ProjectProCorp.com under Articles, item White Papers. See www.ProjectProCorp.com under Software.

© PROJECTPRO CORP.

PAGE 101

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

design document, it is hard, but not impossible, to model this using Critical Path. The only way out of this quandary in Critical Path is by arbitrarily picking a certain number of sequential revisions (iterations).

Critical Path Expects the Project to be Forecasted to its End This has always been a hard requirement to meet for Critical Path, so over the years adaptations have arisen like Rolling Wave planning where only the early part of the project is planned in detail, and the later part is planned only at a very high level, such as deliverables or phases only.

Agile Can Help Critical Path with its Struggles Agile can help Critical Path with the struggles described previously: ◆ Agile does not require all tasks to be linked logically. ◆ Agile does not require the workloads to be leveled in the entire project, just within the next sprint window. ◆ Agile does not require all tasks to have a duration estimate; each task is given a relative weight compared to other tasks. ◆ Agile allows for as many iterations as the client needs, for example to refine features in a software development project. ◆ Agile does not expect the entire project to be planned in detail; it requires detail only for the tasks that are put in the next sprint. Agile keeps the unplanned items in a product backlog.

The Struggles of Agile The ObamaCare government website project, HealthCare.Gov, was botched by the initial consulting company that decided to use an Agile approach in a project that had all the characteristics of being a Critical Path project or perhaps even a Waterfall project. After all, the entire challenge was clear upfront, building half a website was never an option and being able to predict when the entire thing would be ready was paramount for the US Government. Agile should never have been applied to this project. In an article titled ‘Policing the Agile Expressway’ 15 published in PMI’s ‘PM Network’ based on a survey of practitioners, the respondents cited some top concerns about Agile: 15

See PM Network by PMI from November 2013, which was based on a survey done by company VersionOne. PAGE 102

© PROJECTPRO CORP.

Forecasting Programs 1. 2. 3. 4.

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Lack of up-front planning (34 percent of respondents), Loss of management control (31 percent), Lack of predictability (24 percent), and Lack of engineering discipline (20 percent).

When you have your Critical Path, you have up-front planning (concern 1) and predictability (concern 3). When you update your schedule regularly, you will have gained management control (concern 2). As you can see, by combining Agile with Critical Path, you address the three major concerns executives have about Agile. Let’s explore in detail where Agile struggles and see if Critical Path can help in those situations. Agile struggles in the following situations: ◆ The Client Wants the Overall Picture for the Whole Product ◆ User Stories Too Big for one Sprint ◆ How Can You Coordinate Multiple Sprint Teams? ◆ You Must Report the Critical Path while You Manage the Agile Way? ◆ Your Program has Agile Parts as well as Critical Path Parts: New Product Development projects where you have hardware component (Critical Path) and software component (Agile).

The Client Wants the Overall Picture for the Whole Product What if the client wants to see the overall picture for the whole product? What if the client wants to get a forecast on how long the entire system will take or what the entire system will cost? Agile does not answer these questions, because in an iterative mode, you only want to agree upon what will be done in the next sprint window, most often 30 days. Agile is focussed on the next sprint or two, which would make the time-horizon 60 days at most. Agilists do not like to look at the whole product, instead they tend to say: Trust me, it will all work out! Critical Path has a time-horizon that ideally includes the entire project or whatever you can model upfront. Critical Path will help you model the backlog of user stories and get a sense on how big the overall endeavor would be. Agile is a very good task- or team management system, whereas Critical Path is a very good project / program management system.

User Stories Too Big for one Sprint The task list in a Critical Path schedule is grouped by deliverable; after all, a work breakdown structure is a deliverable-oriented breakdown of the work. © PROJECTPRO CORP.

PAGE 103

3

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

The task list of an Agile schedule is grouped by Sprint; a Sprint is a time-oriented breakdown of the work. In many Agile projects, the sprint window is a fixed window of one month. What if a user story is big and requires so many tasks that they cannot possibly fit into a single sprint of one month? You will have to logically group all tasks under one user story and “break” the sprint-orientation of the task list. Or, you must repeat the same user story with new activities in the next sprint. I have seen that done several times in real-life Agile schedules, and it makes me cringe. Neither solution is desirable. What if a single Agile activity takes so much effort that it will span 2 or 3 sprints? In this case, the same activity needs to be duplicated or triplicated for the additional sprints. I have seen this duplication of may tasks across many sprints and do not like that side of Agile scheduling either. Unity-of-data is a principle dear to my heart.

How Can You Coordinate Multiple Sprint Teams? What if the endeavor is so big that you will need multiple sprint teams of 7-9 people to meet this challenge? How are you going to coordinate the multiple teams? Critical Path can address this need, because it will allow you to both map teams and coordinate activities between the teams. You can even model dependencies between the teams when you roll up both schedules into a single master schedule for the program and create an Integrated Master Schedule (IMS). Agilists do prioritize the items in the backlog in collaboration with the client and assign a priority number to each user story (feature) and eventually story points (a measure for effort) as well. If the customer really needs the feature soon, the priority number goes up. The real question might be: Who decides and assigns the priority number?

You Must Report Critical Path while You Do Agile What if you have an Agile project that is required to also produce a Critical Path report? Many government projects and programs are required to report their Critical Path. For example, see: ◆ The Schedule Assessment Guide for capital programs from the General Accountability Office (GAO), USA government ◆ The Earned Value Management System (EVMS), SAE EIA748C-2013 from the American National Standards Institute (ANSI, 2013) used by the US Department of Defense (DoD).

PAGE 104

© PROJECTPRO CORP.

Forecasting Programs

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Your Program has Agile Parts as well as Critical Path Parts What if you are developing software for a product (that you want to do the Agile way), but the product also has hardware parts planned the Critical Path way? In that situation, you need one schedule that facilitates the Agile way of working and produces a credible Critical Path as well. Otherwise, your Agile schedule cannot be incorporated into an integrated master schedule for the product. This is the reality that many high-tech companies face when developing new products that they want to bring to market first.

Critical Path Can Help Agile with its Struggles Critical Path can help Agile in all the struggles previously described: ◆ User Stories being too big for an Agile sprint is not an issue for Critical Path, because Critical Path is not time-boxed in periods of one month. ◆ If the client wants the overall picture (all sprints mapped out upfront), Critical Path could easily deliver. ◆ Coordinating multiple sprint teams is easy in Critical Path, because you can create multiple parallel sprints that may even have some cross-sprint dependencies. ◆ Reporting on the Critical Path is, of course, easy with a Critical Path schedule. ◆ Combining Agile sub schedules into a Critical Path master schedule is possible if the Agile schedule can be converted to a Critical Path schedule.

Benefits of Agile and Critical Path in a Single Schedule The benefits of swiftly converting an Agile schedule into a Critical Path schedule are: ◆ You can do a reality check on your Agile schedule:  Does the total effort of the individuals fit within their availability (considering vacations and time-off on the resource calendar)? Has one individual not taken on too many Agile tasks?  Is the effort equally spread among the Agile team members? ◆ You can determine the (Resource-)Critical Path and forecast the entire project duration. You could even optimize the (Resource-)Critical Path and deliver even more value to the client. If you want to find the Resource-Critical Path, you will need our ProjectPro PathsPro add-in for Microsoft Project. ◆ You can forecast the total effort and, hence, the total cost for the entire project Once you have tentatively mapped out all sprints and scheduled all backlog items, you can basically forecast the entire project. ◆ You can do resource management:

© PROJECTPRO CORP.

PAGE 105

3

Chapter 3 Agile OR Critical Path? Agile AND Critical Path!

Forecasting Programs

 Resource capacity planning: How many people should we hire if we do all these projects? The headcount is treated as a variable in capacity planning.  Resource demand management: When can we start the new project given our fixed headcount?  Resource workload leveling: Given the current assignments, when will our projects finish? ◆ You can do project portfolio planning and management: Which projects should we do? Which projects should we stop? Tip► Why would you NOT want to have these benefits from your Agile schedule? You can have these benefits in one single schedule file, with no need to keep two separate files to meet the diverging reporting needs of your Agile stakeholders and Critical Path stakeholders.

PAGE 106

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

Chapter 4 Organizing the Program

4

Learning Objectives After this chapter, you will be able to: ◆ Size up a program more precisely than you initially thought possible ◆ Avoid drowning in the data ◆ Decide whether to keep a single program schedule or divide it into project schedules: centralized scheduling versus decentralized scheduling ◆ Carefully consider what projects to create: breakdown orientations and their ins and outs ◆ Know what to ask for from project managers: Time Model, Workload Model or Cost Model ◆ Apply constant quality control on project schedules using checklists ◆ Organize the Program Work Breakdown Structure (PWBS) effectively

© PROJECTPRO CORP.

PAGE 107

Chapter 4 Organizing the Program

Forecasting Programs

I Would Like to Slant the Soccer Field Toward Your Goal Nob and Bob meet at Nob’s workstation, and Nob says: “The f…. finance folks imposed their accounting high-level breakdown on my program. Level one is supposed to be labor, services, materials, facilities, licenses!” Bob replies, “That doesn’t make much sense, does it?” Emotions run across Nob’s face. “No, none whatsoever. They want me to break down my program like this, so they can easily get the input for their accounting system! They want me to do their work!” “Yeah, why are THEY paid the big bucks?” “They have no idea about program management. I can’t produce a decent deliverable-oriented breakdown structure! What am I supposed to do?” “Have you heard of the tagging and grouping feature in Microsoft Project? It allows you to create parallel breakdown structures so you can keep everyone happy!” Nob seems relieved. “Show me how to do that!” “Watch. I’ll create a custom field and put all finance expense categories they gave you in this lookup table so I can use this custom field to tag all assignments that carry the costs. I’ll just do a few. Now I create a new view that groups all assignments by category. And voila!” Nob is pleased. “That will make the penny pinchers happy!” “We’re slanting the soccer field toward their goal: guess what? We’re winning!” “Did anyone mention lately, you’re brilliant?” PAGE 108

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

Sizing Up Your Program: Heuristic Metrics We have found interesting heuristic metrics in our 25-plus years of observing programs and helping program managers. Note that our work experience is mostly in IT or software development programs; if your program is in a different industry, you may need to develop your own heuristics. Heuristic metrics for IT-programs: ◆ If you know the number of project managers of an organization, you multiply by 10 to find the total number of employees working on the project/program-side of the organization (as opposed to the operational side). The typical project team size seems to be 10. The span of control of a typical manager in this area also seems to be about 10; the software development folks have brought it down to a maximum of 9 people on an Agile-team. ◆ If you know the total budget of the program WBS, you will roughly know the total number of different resources needed in the program. You will need about 1 resource for each 1M of money in your budget. (This works in the US and in Canada; we are less sure in other currencies.) So, for a $150M dollar program, we expect the program team size to be roughly 150 people. ◆ If you know the number of team members in your program, you will roughly know how many projects you will end up with given the standard span-of-control of 10 people per project. For a 150-person program, you will likely end up with 15 projects, give or take one or two. ◆ If you know the number of projects, you will roughly know the total number of tasks that you will end up with. The average size of a project schedule is about 1,000 tasks. So, if you have 15 projects, you will end up with about 15,000 tasks in your program. ◆ If you know the number of tasks in a program, you will know the number of planning specialists (schedule specialists, cost analysts, risk analysts) needed for the program support team. The number of tasks divided by 1,000 is the number of planning specialists the program support team will need roughly. ◆ If you roughly know the total number of task-related line items in a program WBS that you will end up with, you will roughly know the total number of cross-project dependencies that you will have to deal with. The number of cross-project dependencies will be approximately 5% of the total number of task-related line. So, in a 15,000-task program, you will end up with about 750 cross-project dependencies. ◆ If you know the number of cross-project dependencies, you know if you will need specialized tools to handle those interdependencies. If the total number is less than 30, you can manage them manually. If it is greater than 30, you need specialized program management tools to keep your sanity. © PROJECTPRO CORP.

PAGE 109

4

Chapter 4 Organizing the Program

Forecasting Programs

We have found these numbers in a heuristic way by simply observing well over one hundred different programs over the years. Therefore, as soon as we know the amount of money in the program budget, we can tell fairly well what the eventual program team, schedule and projects will look like and plan for that accordingly as we choose the tools and the number of planning specialists we will need on our program support team. At one client, the program manager on a $150M program continued to insist that there would be no more than about 5,000 tasks in her program, and we said: We think that you are underestimating that number! After more rounds of detailed planning of all work to be done, the program grew to 7,500 tasks, and the program manager thought she was done breaking down the work. Then more requirements came to the surface, and more detailed planning spreadsheets created in Excel turned up unexpectedly, which needed to be converted to Microsoft Project schedules. We were then well over 10,000 tasks, and the program manager was certain she had nailed the scope of the program. We told her: You are not done yet! Sure enough, a whole compliance aspect still needed to be dealt with, because of new finance-tightening rules (a.k.a. ‘Basel 3’: the program was in the banking sector for which financial guidelines are hammered out in the Swiss town of Basel in several rounds of talks!), and, when the planning was all said and done, we ended up with about 15,000 task-related items in the program schedule. Trap! Please note that there is nothing scientific about heuristics (there never is!).

They are very rough metrics; you can probably find several exceptions to these heuristics in your work experience. Our work experience predominantly lies in IT and software development of large systems. If you are outside of that world, you will have to find or develop your own heuristics.

PAGE 110

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

Heuristic Sizing Worksheet for Your IT-Program Note: ◆ These factors are rough averages to assess the order of magnitude aspects of your program in the early stages of program planning in IT-related programs. ◆ © ProjectPro Corporation Nr of Project/Program managers: ………..……………………………………………… *10 = Nr of Employees in projects: ………..……………………………………………… Program Budget: …………………………………………………………………Dollar / 1M = Nr of program resources

………..………………………………………………

/ 10 = Nr of projects

………..………………………………………………

* 1000 = Nr of tasks in program

………..………………………………………………

* 5% = Nr of interdependencies

………..………………………………………………

Check one of the following:



less than 30 interdependencies: you can manually manage your interdependencies,

OR



more than 30 interdependencies: you should purchase specialized tools for interdependencies Nr of tasks / 1000 = Nr of planning specialists needed in program support: ……………

© PROJECTPRO CORP.

PAGE 111

4

Chapter 4 Organizing the Program

Forecasting Programs

Introduction to Scheduling Programs When scheduling a program, you first need to analyze your situation by answering the following questions: ◆ Do you want to keep the program schedule in a single program schedule or split it into multiple project schedules (sub schedules)? If the number of tasks in your IT-program schedule starts to exceed 2,000, you will have to break your schedule into multiple sub schedules. In construction, we have seen schedules with more than 2,000 tasks looked after by a single person, but those schedules had no resources. Without resources, you can perhaps go up to 10,000 tasks in one schedule and have it maintained by a single scheduler. ◆ Do you want to load resources into the schedule? ◆ If so, are these resources dedicated fulltime to your program or are the resources shared with other projects or programs?

Once you have answered these questions, you know if you are in situation A, B, C, D, E or F in the previous grid: A: Single Schedule, No resources This is the easiest situation of the six, and MS Project by itself will probably meet all your needs. B: Single Schedule, Dedicated Resources You now need to model the workloads of the resources. You are not sharing the resources with other projects, because they are dedicated to your project. You can simply enter the resources in the Resource Sheet view of your schedule. C: Single Schedule, Shared Resources You need to model workloads and are sharing resources with other projects or

PAGE 112

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

programs; you need to create a shared resource pool. You will need one of the following:  A shared resource pool file (MPP-file), but this will only work if you share fewer than 50 resources, which will restrict you to only generic resources (see page 236 for what they are and see page 41 for why only 50).  Project Online in-the-cloud or Project Server on-premise, which come with an enterprise resource pool and since 2016 also include the Resource Engagements feature to manage the exchanges between resource managers and project managers.  A specialized tool from a third party, such as CS Resource Management from Campana & Schott, to meet other needs such as resource requests, workload aggregation and approvals. See situation F for how to handle the resource over-allocations in this situation. D: Master with sub schedules, No resources MS Project will meet your scheduling needs when the number of cross-project links is fewer than 30; we will provide a way to manually track those cross-project links using a custom-made view in MS Project (see page 186). When the number of crossproject dependencies exceeds 30, you will need a specialized tool to manage all those interfaces between the projects (handoffs). Some of these tools are:  CrossLinksPro by our company ProjectPro Corporation (Canada), see www.ProjectProCorp.com. To find the Critical Path leading into any major milestone in your program schedule, you may need PathsPro also from ProjectPro Corporation.  MasterLink by Matan (Israel), see www.matan-consulting.com.  CS Program Management by Campana & Schott, (Europe), see www.campanaschott.com. E: Master with sub schedules with Dedicated Resources You will have cross-project dependencies, and you will need tools to manage them as under situation D. You are in a resource-constrained situation. The resources are dedicated to the program, but are the resources also dedicated to the projects in the program?  If so, you can treat them in the same way as under situation B.  If not, you are sharing the resources across the projects in your program (not outside the program) and you now must create a shared resource pool for the projects in the program as under situation C. See situation F for how to handle the resource over-allocations in this situation. F: Master with sub schedules with Shared Resources This is the most challenging situation, which we have only encountered once so far:  You will have cross-project dependencies and you will need tools to manage them as under situation D.

© PROJECTPRO CORP.

PAGE 113

4

Chapter 4 Organizing the Program

Forecasting Programs

 You have resource-constraints that will extend the program schedule because of your limited access to resources: You now must create a shared resource pool for the program as under situation C.  You will need a specialized tool to find the Resource-Critical Paths in your program. The resource constraints may lead to over-allocations that will force you to start using automatic leveling features in MS Project, because manual leveling a large program schedule takes too much of your precious time. However, before you can apply automatic workload leveling to your program, your schedule needs to have complete and correct network logic, among others. After leveling, you have a workload-leveled program schedule. In such a schedule, the traditional Critical Path no longer drives your schedule finish date. The driver is the Resource-Critical Path (see page 62 for more details). In a large program schedule, it will be too hard to find the Resource-Critical Path manually. MS Project does not have a feature to find the Resource-Critical Path in an automated fashion, so you are going to need another specialized tool that can identify the Resource-Critical Path in your workload-leveled program schedule across multiple project schedules. We are aware of only one such tool that can do this across multiple, linked projects in your program: Our own PathsPro from ProjectPro Corporation, see www.ProjectProCorp.com. This tool is currently in use by NASA and by Elon Musk’s Space-X, among others. We provide more information on it in chapter 6 (see page 177). If you would like to read a case study in which we describe how it works, please retrieve the article How to Tame a Gorilla Program – SanDisk case study from our website www.ProjectProCorp.com under Articles.

PAGE 114

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

The Challenge of Scheduling Programs: Size of Schedule The amount of data from the program schedule that fits within the size of your screen is very small:

4

When you try to schedule a program, sooner or later you are likely to find yourself drowning in the data. Imagine managing your program by writing all tasks on the wall of the Empire State building starting at the top and probably ending in the basement of this iconic tower in New York City. Then you try to manage the program schedule by traveling up and down the floors by elevator to look at different places in your huge schedule. This experience is comparable to browsing or scrolling over a large schedule with your small computer monitor that only displays a tiny bit of the Integrated Master Schedule (IMS). Tip► How long will it take you to read through and understand a list of 10,000 tasks? I tried to do this a long time ago thinking it was necessary and it took me a few weeks to read and understand them all. You will quickly overwhelm your capacity to process information and want to go for a long coffee break. After my first few programs, I realized that it did not even make sense to try to understand all tasks in a PWBS, attempting to do so was a waste of time. (I also became lazier over the years.) Now the only thing I try to understand immediately in a new program is what projects it has and why those projects were created in the first place: in other words, the breakdown orientation of the program manager.

© PROJECTPRO CORP.

PAGE 115

Chapter 4 Organizing the Program

Forecasting Programs

Drowning in Data? Have you ever see a screenshot of the Gantt Chart of a 10,000-task program schedule? In my early years as a program scheduler in the 1990s, I saw the following picture appear on my computer screen on more than one occasion while looking at an integrated master schedule of a program:

The multitude of long arrows depicting the cross-project dependencies start to fill up the screen, slowly but surely forming a curtain that hides the regular tasks in the schedule behind it. With the small monitors and lower screen resolutions of the 1990s, this posed a real problem; I was personally confronted with several totally black screens during that decade, their data blacked-out by the massive number of black arrows crossing the screen from top to bottom on their way from one project to another. Tip► There is a relationship between the total number of tasks in a program and the number of its cross-project dependencies: We have found that the number of crossproject dependencies in a program will be about five percent of the total number of tasks, assuming the program is subdivided in a smart way (see page 125 for more on smart breakdown orientations). So, in a 10,000-task program, we expect at least 10,000 * 5% = 500 cross-project dependencies. In a 20,000-task program schedule, we expect about 1,000 cross-project dependencies if broken down in the best way possible. This number of long arrows can easily turn your screen black.

If you find that you have many more than 5% cross-project dependencies, you may not have broken down the program in the best way possible, and we recommend that you reconsider your breakdown orientation before it is too late. Getting the breakdown right

PAGE 116

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

is a critical success factor in program management. Or, in more poetic words: A program can break down with the wrong breakdown.

Are You Really in a Program? If you have less than 5% cross-project dependencies, you either are not aware of the dependencies between the projects (which will come to haunt you), or you may actually be in a portfolio rather than in a program as one ‘program manager’ found out after consulting with us. A program typically has many cross-project dependencies, whereas a portfolio has far fewer of them. On page 23 of this book, we presented definitions of ‘program’ versus ‘portfolio’ that explain this phenomenon fully). To recap: ◆ A program is a set of related projects better managed together than apart, which implies that there will be dependencies between them. Even the smartest way of subdividing a program will still leave you with many cross-project dependencies. ◆ A portfolio is a set of projects and programs that are sharing people or a budget. There may be some dependencies in a portfolio, but if the portfolio is smartly subdivided into programs and projects, the number of dependencies will be minimal. Also, the dependencies in a portfolio are typically of a different kind than in a program: In a program, you will only have the four logical types of dependencies (FS, SS, FF, SF) that can be modeled with current scheduling software. In a portfolio, you have two additional types of dependencies: mutual exclusion (if you do THIS project, you should NOT do THAT one), mutual inclusion (if you do THIS project, you ALSO have to THAT one). The first type of ‘mutual exclusion’ dependencies will never be found in a program, because it compromises the integrity of the program. This book is about programs, so we will assume you are in a real program.

Modeling Modeling Examples How can you deal with the flood of data in programs? Our secret is to build a model of the program. A model is a simplified abstraction of reality built for a purpose. Many different professionals, industries or individuals build models: ◆ Architects build small 3-dimensional (3D) models to show to clients. These models often are exhibited in the place-to-be-built. ◆ Airplane- and boat-fanatics build intricate 3D models of real-time airplanes and boats as a hobby © PROJECTPRO CORP.

PAGE 117

4

Chapter 4 Organizing the Program

Forecasting Programs

◆ Meteorologists build weather-forecast models. ◆ Economists build economic models for countries that produce GDP and debt forecasts ◆ Realistic painters create paintings or sculptures that depict some part of reality. ◆ System analysts build data models of the data to be processed by a new software system. They build flow charts to model the business processes and how these processes interact. ◆ Writers write stories that summarize reality. ◆ Historians write summaries of certain parts of history. ◆ Project and program managers (schedulers) build models of their project and program to forecast continuously. The likely purposes of the previously mentioned professionals are: Group

Model

Purpose

Architects

3D models

Gain trust / confidence from client

Meteorologists

Weather models

Forecast upcoming weather

Economists

GDP forecast models

Help governments plan policies

System analysts

Data models

Provide an overview of all data entities and the relationships between them

Schedulers

Schedules

Forecast the project or program

So, schedulers build a model of the program to forecast the program continuously. As I explain in my Forecast Scheduling books, schedulers build valid, dynamic and robust models of their projects that provide continuous forecasts. The schedule is for the project or program manager what a thermometer is for a doctor: A measuring instrument that provides feedback on if the patient is healthy. The schedule indicates if the program is meeting its deadlines or if it is slipping past them.

PAGE 118

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

The Schedule is Not the Program The illustration here shows a painting by René Magritte. He painted this wonderful pipe as precisely as he could to try and seduce you into thinking it is a real pipe; that’s what’s artful about it. However, Magritte then shakes us awake from our seductive trance by giving it the title “This is not a pipe”. The painting is not the object. The map is not the terrain. The schedule is not the project / program! Yet, the objective of scheduling is still to capture the project or program as accurately as possible!

© PROJECTPRO CORP.

PAGE 119

4

Chapter 4 Organizing the Program

Forecasting Programs

Modeling Theory Modeling deliberately simplifies the reality. I would like you to try modeling yourself and take you out of your comfort zone (for a few minutes). Please model the reality in the next illustration using any means you need:

When I ask my students to model the reality in the illustration, they come up with all kinds of different models: ◆ Some hoist the largest objects out of the mess and re-draw them. ◆ Some pick the most colorful objects and re-draw them. ◆ Some pick the funniest shapes and represent them. ◆ Some describe in words what they see. ◆ One student simply wrote: This is a model of the mess Eric created! This assignment raises the questions: What means should you use? What objects should you pick? These questions are important for scheduling programs as well: What do you pick and put in the schedule? When you schedule for the purpose of forecasting, you need to pick the things that best predict the program as a whole. What are those things from the reality of a program?

PAGE 120

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

In other words, we need to: ◆ Select the right scheduling approach.  Determine the dominant ideal and dominant constraint for your program. The right approach will present the right health indicators to measure progress on the two dimensions of the dominant ideal and dominant constraint.  In chapter 2 we discussed how you could determine the right scheduling approach for your program, see page 51. ◆ Establish scheduling guidelines for the projects. The scheduling approach of the program needs to be transferred to the projects in the program and communicated by the program manager to the project managers. Each approach comes with its own scheduling guidelines that should be followed (see page 51 where we discussed the approaches). ◆ Find the right level of detail for your model. To simplify the reality, we need to deliberately leave things from the reality out of our model. To achieve the right level of detail, you could have made the following choices as shown in the illustration. Model 1 has the least amount of detail and is a high-level model, whereas Model 4 has the most amount of detail and is a lowlevel model. What happens when you add more detail? ◆ You gain short-term predictive power with your detailed model, which does not have much value. For example, you will be able to predict what resource Harry will be working on next week. ◆ You increase the size of the model and have more data in the schedule. You will also have many more dependencies and, therefore, greater complexity. ◆ You will have more detail to explain to your stakeholders. What happens when you decrease the amount of detail? ◆ You will keep your long-term predictive power if you chose the right scheduling approach and modeled your program well. ◆ Less effort will be required to schedule and update the schedule. ◆ Your model will be more abstract and, therefore, be harder to explain to your stakeholders. © PROJECTPRO CORP.

PAGE 121

4

Chapter 4 Organizing the Program

Forecasting Programs

Tip► As you can clearly see, it is important to strike the right balance and find the right level of detail for your program.

Scheduling is Modeling Reality ◆ Is complex ◆ Just is (no obvious purpose)

Model ◆ Is simple ◆ Is an abstract from reality ◆ Built for a purpose ◆ Provides health indicators ◆ Should be easy to maintain

Tip► Models should not replicate reality. The map is not the terrain. The architectural miniature of the building is not the building itself. Similarly, the schedule is not the project, and it certainly should not be as detailed and complex as the reality itself. The model must be so simple that its main report fits within the small size of your computer screen.

Possible purposes for schedules as models of the project realities: ◆ Selling: For example, a consulting firm wants to get a contract but must show the timeline to make a sale. ◆ Delegating: A project manager wants to communicate the assignments to his team members. ◆ Tracking: A project manager wants to know the status of the project. ◆ Forecasting: A project manager wants to know what the current status of the project / program means for the overall project.  What does the current status, whether ahead or behind schedule, mean for the overall finish date?  What does the current status of over- or underspending mean for the overall project cost? Will the project be under or over its budget?

Some Rules for the Program Schedule Model Over the years, we have developed several rules that guide us in developing a schedule model of a program: ◆ As a guideline in a program, you should create at least ten major milestones apart from the multitude of minor milestones (a.k.a. inch pebbles) project managers will PAGE 122

© PROJECTPRO CORP.

Forecasting Programs

◆

◆

◆

◆ ◆ ◆

◆

Chapter 4 Organizing the Program

create in their own project schedules. A major milestone is of interest to all stakeholders, whereas minor milestones may be of interest to some stakeholders or perhaps just some team members. You need to have a major milestone every (few) month(s) to focus the program team on completing a chunk of the program rather than:  Focusing on completing the entire program by using a single program completion milestone that is years away.  Focusing on too many minor milestones that the project managers will stick into their schedules. Example: If you have a program that lasts 3 years, which is 36 months, you need to have a major milestone at least every 3 months; 36 / 3 months = 12 major milestones at minimum. Each major milestone needs a time contingency (buffer) to ensure a 90% on-time delivery of the major milestone. You need to determine the size of the buffer through a scientific and reliable method; we recommend using Monte Carlo simulation for this purpose. You need to have a dynamic, high-level model of the entire program (perhaps deliverables only), a high-level program schedule, and a more detailed, dynamic model to achieve each next major milestone (with all activities leading to the accomplishment of the milestone), a detailed program schedule or integrated master schedule (IMS). This high-level model and detailed schedule are ideally produced from a single schedule (or set of sub schedules) to maintain ‘unity-of-data’ and prevent double bookkeeping. The high-level schedule can easily be created by selectively filtering items from the detailed schedule (see page 305 for exact steps). You need to have a detailed Critical Path into the next one (or two) major milestone(s) at all time. In a resource-constrained program, you need to have a detailed Resource-Critical Path into the next major milestone(s) You need to be able to quickly determine the detailed Critical Path into the next one (or two) major milestone(s); manual schedule analysis of a large schedule takes too much time. You need to have a high-level Critical Path for the overall program, the Program Critical Path (or a Program Resource-Critical Path in a resource-constrained program). The Program (Resource-)Critical Path displays all deliverables that drive the program duration. A high-level Program Critical Path is only truly high-level when it contains only about 100 tasks. After each update to the project schedules, you need to be able to quickly determine the latest, high-level (Resource-)Critical Path for the overall program.

© PROJECTPRO CORP.

PAGE 123

4

Chapter 4 Organizing the Program

Forecasting Programs

When Can You Call Your Program ‘In Control’? Being ‘in control’ relates to the level of confidence you have that you will meet the deadlines. To describe your program as ‘in control’, you will need to have the following confidence levels: ◆ On the next major milestone (i.e., the first milestone when the program just started), you need to have a confidence level of ……. percent for on-time completion. ◆ On the overall program, you need to have a confidence level of ……. percent for on-time completion.

We have not filled in the percentages, because we would like you to think about them for a moment. Please, decide these percentages before reading on… Tip► When prompted, we often suggest that a program is in control when you find that: ◆ You have a 90% likelihood to accomplish the next major milestone on time. ◆ At the start of the program, you have a 50% likelihood of accomplishing the overall program on time. This percentage will increase over the life of the program and approaches 100% likelihood close to the program finish date.

We recommend you schedule your program in such a way that: ◆ You always know your detailed (Resource-)Critical Path into your next one (or two) major milestones. A detailed Critical Path reveals all activities assigned to resources plus minor milestones. ◆ You have inserted time buffers (time contingencies) at the end of the Critical Paths for all major milestones. These time buffers allow you to meet the deadlines of the major milestones with a high probability of 90% (high level of confidence). The size of the time buffers can best be determined by Monte Carlo simulation using add-in applications like @Risk or Full Monte. Tip► If you schedule your program in this way, you just need to accomplish the first milestone on time with 90% confidence and repeat this for as many major milestones as you have identified in your program. If you do this, you will deliver the entire program on time in 9 out of 10 cases (assuming ten major milestones), and it will be completed close to the original target date you promised to your sponsor and client.

PAGE 124

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

Tip► In software development programs, the following guideline is often used: When you finish your design phase, you need to be able to predict the duration of the build phase with a margin of error of 10% (accuracy) for the Build Estimate. This principle of reducing uncertainty over time is known as the cone of uncertainty: The uncertainty reduces when exploratory work has been completed while time goes by: When you hit the last milestones in the program and still have your 90% confidence-level intact and the last time buffer remains, you will bring your program in on time.

Bringing in programs on time is one of the hardest things to do, as the annual Standish Research Reports have taught us over the years. 16

Breaking Down the Program Keep One Large Schedule or Divide the Program Schedule? You may be confused that we bring up the same question a second time, but the first time, we addressed a different question (see page 125): Should we break up the program into projects? Here we deal with the next question: Are you also going to break up the program schedule into multiple sub schedules? Even if you have decided to break the program into projects, you still must decide if you want to put each project into a separate schedule, or if you want to keep them together in one giant, central program schedule. We will answer this question by looking at three aspects of your situation: ◆ Can your organization handle the program schedule and all project schedules? We will discuss this in one of the next sections (see page 128). ◆ What levels of proficiency are there in scheduling projects? We distinguish three hierarchical levels of proficiency: time modeling, workload modeling and cost modeling (see page 128 for more). ◆ What benefits do you derive from creating multiple schedules? We will discuss this next.

16

See, for example, their CHAOS Manifesto 2013 report that is subtitled: Think Big, Act Small: https://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf © PROJECTPRO CORP.

PAGE 125

4

Chapter 4 Organizing the Program

Forecasting Programs

Trap! MS Project is a single-user interface: Only one user can make changes to a schedule at any time, unlike other database applications where multiple users can make changes. Database applications lock data record-by-record, which allows multiple users to make changes to different records concurrently. Records are mostly independent inside most other databases, and therefore the database application can lock data in an optimistic way, i.e. the database locks as little data as possible. In contrast, a project schedule is a dynamic model with every task record related-to or driven-by another task record. Therefore, MS Project locks in a pessimistic way: All tasks relate to each other (in)directly, therefore all task records need to be locked. The entire schedule is locked once it is opened as an MPP-file in your file system or checked out from Project Server. Tip► MS Project applies such broad locking of task records because all task records hang together through the network logic: The task records are not independent from each other, and so any change usually affects most other records. As you can see, an MS Project schedule is fundamentally different from the structured data in a regular database, like a customer database (CRM) or an accounting system (ERP). It is important to understand this unique nature of schedules in a PPM-system, a Project Portfolio Management system.

Keeping this in mind, there are several business reasons why you may choose to divide a program schedule into multiple project schedules: ◆ Delegation of responsibility Creating separate projects allows you to delegate responsibility for scheduling them to specific project managers. Ideally, you as program manager, will have better visibility and control of each part of the program than if all responsibility remained with you (and, of course, your central program support staff). In other words, you are matching accountability for the project with corresponding authority for the schedule, perhaps even for the budget. ◆ Improved visibility Generally speaking, it is desirable to delegate responsibilities as close to where the work is done, which improves the visibility on the work for the program manager. After all, the person who sits closest to the campfire will get the most warmth from it. However, scheduling responsibility must be delegated to people who have enough scheduling maturity (competence and willingness), more on this in the next section starting on page 128. ◆ Multi-user Access Multiple people may need to provide input to the schedule, make changes or update sections. Project managers with their own sub schedule may provide updated information to central program schedulers. ◆ Vendor Access When external vendors are involved, they will want to choose the schedule and scheduling application they use, so they can also use it to manage their own internal PAGE 126

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

operations and model the total workload of their resources across all their own projects and clients. As a result, they will lobby hard to be allowed to use their own scheduling application. It is important for the program manager to standardize on a single scheduling application, whether it be Microsoft Project (USA), Oracle Primavera (USA) or Spider (Russia), to name the leading, program-scheduling applications. Vendors also often have their own working times, holidays, currency and scheduling standard. These are all valid reasons for them to have their own schedule. ◆ Multi-country needs When your program spans multiple countries, you may have to deal with multiple languages, multiple currencies and different national holidays (calendars). For example, a memory stick maker we dealt with had chip designers in California USA, programmers in Israel and manufacturing facilities in India. The program in which one new memory stick was created required schedules from different countries, each with its own currency and perhaps even its own language, in this case English, Hebrew and multiple Indian dialects. The national holidays were different in each country and required a different project calendar for each project (unfortunately named ‘Standard’ in Microsoft Project). Programs that span multiple countries often need multiple projects that allow you to set a different currency, language and calendar for each project. The only ways to accomplish this in Microsoft Project is to have multiple projects or have multiple Task Calendars in a single schedule. ◆ Practical necessity when you have many tasks We refer to the number of task-related line items (“tasks”) in your program and the number of change requests. We will present thresholds that we have found to be true in IT-related projects, where the number of change requests is relatively high. If you are in a different sector, the thresholds may be different; in the construction sector, for example, the threshold numbers are often higher than presented here. Another factor is whether you resource-load your program schedule or not. For resourceloaded, IT-related programs, our thresholds for the maximum number of line items in a program schedule are:  0-1,000 line items: If your schedule grows to over 1,000 line items per year, it becomes awkward to handle in a single file. Special skills are required to manipulate a schedule of over 1,000 line items, and you need to be good at developing custom views with corresponding custom filters (especially the complex ones: multi-field and interactive filters, see page 318 for more). Therefore, we recommend you consider breaking up a schedule into sub schedules once the number of tasks goes over 1,000 line items.  1,000-2,000 line items: If your schedule grows from 1,000 to 2,000 line items per calendar year, your schedule will be a full-time job. Looking after such a large schedule means: You create and maintain it, plus you need to interact with all team members and project stakeholders.

© PROJECTPRO CORP.

PAGE 127

4

Chapter 4 Organizing the Program

Forecasting Programs

 >2,000 line items: If your schedule grows over 2,000 line items per calendar year in resource-loaded IT-schedules, it is no longer possible for one scheduler to maintain it. The workload is too great, and information-overload sets in. For these two reasons, the schedule will need to be broken up into sub schedules, even in organizations that tend to be very centralized by nature, such as military, pharma, banking and emergency-response. Centralized organizations tend to create larger schedules and have a single, central program schedule and scheduling office. Decentralized organizations tend to delegate scheduling responsibilities to the project managers lower in the organization and create smaller projects and schedules, sometimes even subprojects with sub schedules.

Can your Organization Handle the Scheduling? We have found that few individuals feel at ease working on a very large schedule of over 1,000 line items. We have also found that the need for those rare individuals dramatically increases when an organization ventures into undertaking large programs. This illustration shows that: ◆ When schedules grow larger, the number of people who can handle these larger schedule decreases rapidly. ◆ At the same time, when the size of a schedule grows from 1,000 to 2,000 tasks, which is typical for programs, the need to subdivide it into smaller schedules grows exponentially. Tip► This creates a sweet spot for your organization, which your HR-department needs to find or at least approach. This sweet spot is at the intersection of the two curves, where there is a balance between the number of capable schedulers and the number of projects of a particular size to be scheduled.

What Kind of Project Schedule Should You Request? Proficiency Levels Ever wondered what the commonly used terms ‘introductory’, ‘intermediate’ and ‘advanced’ mean in terms of Microsoft Project proficiency? Have you ever had to PAGE 128

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

choose for your own professional development between an ‘introductory’, ‘intermediate’ or ‘advanced’ course in Microsoft Project? Were you forced to read the detailed course syllabus? In this section, we will propose a clearer way of describing the levels of proficiency for project scheduling in general, and Microsoft Project, in particular. Here is what we learned in 2016 during the delivery of 20 courses, each three-days long, with an average of 12 project managers each at a large department in the Federal Government of Canada. These insights may help you strategize your own personal training or help a project management office purchase the right type of training for its community of schedulers (i.e. Microsoft Project users): ◆ The early groups of students we trained were very keen to learn; they picked up concepts quickly and could handle a lot of content. We trained these project managers in most, if not all, features in Microsoft Project, including modeling the time aspect of the project and the workloads of the resources. Some groups even learned how to model costs with a dynamic schedule. The later groups of students were slower leaners, who had often been cajoled by their managers to take the course: They were more intimidated by Microsoft Project and more easily overloaded with information. Some of these project managers were simply ‘not ready’ to load resources into their schedule. We found ourselves as trainers having to switch from ‘effort-based scheduling’ (labeled ‘workload modeling’ in this book from hereon) to a simpler form of scheduling: ‘durationbased scheduling’ (labeled ‘time modeling’ in this book) for these later groups. We made this switch out of necessity, even though everyone really needed to know workload modeling because almost all their projects were software development projects. ◆ All project managers were expected to report on cost every quarter using Excel. They had to provide a cash-flow report on what they had spent and what funding they needed in the remaining quarters of their fiscal year, which caused a lot of additional work whenever delays happened or new deliverables emerged. In other words, doing these reports in Excel required brain surgery every quarter. The cashflow reports could have been maintained much more easily in Microsoft Project, because it reschedules costs automatically when delays happen, and it adds cost when new deliverables are added, all while preserving the original cash-flow in the schedule baseline (that was approved for the project). Why did this organization not expect their project managers to use Microsoft Project instead of Excel to report on cost? The answer: ‘modeling cost’ is the most advanced use of Microsoft Project and requires the highest level of proficiency with this application, and that expertise was not present in this organization or feasible through training in the time given. As you know, there are ‘predictive’ versus ‘adaptive’ approaches to scheduling. The mainstream predictive approaches are Critical Path, Resource-Critical Path, Critical © PROJECTPRO CORP.

PAGE 129

4

Chapter 4 Organizing the Program

Forecasting Programs

Chain, and Earned Value, whereas the adaptive approaches are Agile, Scrum, and SAFe. This text discusses mostly predictive scheduling, after all, you model time, workload or cost typically for forecasting purposes.

Time, Workload and Cost Modeling We would like to present the following definitions for the vague terms ‘introductory’, ‘intermediate’ and ‘advanced’ proficiency levels of using Microsoft Project, which by themselves do not mean anything except a hierarchical ranking between them: 17 ◆ Introductory: model Time only (‘Time Modeling’): You model the duration and finish date of the project to monitor if your project will finish on time. The time model allows you to view the most current duration of the project continuously and, therefore, control the duration of your project better. It increases your chances to finish the project on time. ◆ Intermediate: model Time and Workload (from here on simply referred to as ‘Workload Modeling’): Portfolio and Resource managers may ask you for the resource requirements for your project before approving your project, which requires you to model the workloads in Microsoft Project. Resource requirements are most often reported as number of Fulltime Equivalent employees (FTEs) by role by month. Once the project is approved, you need to model the total workload for each resource in detail to determine if the workloads of all team members are reasonable, and if the workloads are evenly spread among them. This model will tell you if the project is feasible from a resourcing point-of-view. ◆ Advanced: model Time, Workload and Cost (from here on simply referred to as ‘Cost Modeling’): You attempt to model the cost side of your project to monitor if you are staying within the project budget. The cost model helps you control the expenses of your project better and increases your chances to keep the project within its budget. Earned Value Management (EVM) is an example of a specialized case of modeling cost. If you need to implement Earned Value, you will need advanced schedulers who know how to model cost in Microsoft Project. This need may explain why many organizations struggle with making Earned Value truly work, even with the current drive of the US Government to implement it on major capital programs.

17

In my book “Forecast Scheduling with Microsoft Project 2010/2013”, I already used three different approaches to optimizing schedules: ‘Optimizing for Time’, ‘Optimizing for Time and Cost’ and ‘Optimizing for Time, Cost and Resources’. The three levels in the chart were inspired by that threesome, but I flipped the last two levels to bring them in line with the natural progression. PAGE 130

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

Hierarchy There is hierarchy between the different types of modeling. If you want to model workloads, you will have to build a time model as well and probably do that first. If you want to build a cost model, you will have to build a workload model first, which needs a time model. This hierarchy is depicted in the next illustration as the steps of a staircase.

Progressive Elaboration Progressive elaboration is also needed to get from one level to the next: With every step up, people will need to add more data to their schedule model. The illustration indicates what data needs to be added at each level: We estimate that to elaborate a time model and convert it into a workload model requires about 20 times more data; a Time Model typically has 7-9 activities per deliverable plus all resources plus assignments on each activity. If you spent more time planning, a workload model could be transformed into a cost model; we estimate that the amount of required data doubles going from a Workload Model to a Cost Model. Tip► In summary: if you have a time model with 50 pieces of data entered (line items and fields), you will need to enter about 1,000 more pieces of data to get to a Workload Model and then another 1,000 pieces of data to get to the Cost Model, for a grand total of about 2,000 pieces of data, which, by the way, is NOT the number of tasks; the

number of tasks may only be 300 in this Cost Model. You can see that the level of detail and the amount of data grow significantly when progressively elaborating your dynamic models from a Time Model, to a Workload Model and, finally, to a Cost Model. Therefore, you must ask yourself at the start of each project: What do I really need for this project: A Time Model, a Workload Model or a Cost Model? And program © PROJECTPRO CORP.

PAGE 131

4

Chapter 4 Organizing the Program

Forecasting Programs

managers need to ask: What kind of project schedule should I request from each project manager and each vendor?

Three Levels of Proficiency in Scheduling Projects The illustration lists what data should be added at each level of progression: To monitor if a project is on time, you need to capture at least: ◆ Deliverables, ◆ Duration estimates, ◆ Dependencies between the deliverables ◆ Deadline dates, but … ◆ Do not enter Dates in Start or Finish fields, because doing so creates many date constraints and a rigid model. Notice all these words start with a ‘D’, so we normally refer to this with our mnemonic ‘4D-1D scheduling’. To monitor workloads, you need to add to the Time Model the following: ◆ Activities that will create each deliverable. ◆ Availabilities: You need to enter all generic resource roles and/or actual human resources (people of flesh and blood) and their availability to the organization (capacity). ◆ Assignments: Who will do what activity? An assignment is one person working on one activity. An assignment is on a lower level of detail than an activity; one activity can have multiple assignments (i.e. multiple people working on the activity). ◆ Assignment Effort: Assignment Effort is the amount of effort needed for the person on this one activity (=assignment) and can be entered in the field Work on the Task Form. Activity Effort is the total amount of effort needed for all people working on the activity, which is captured in the task-related field Work in Microsoft Project. ◆ Assignment Units: Assignment Units are the number of resources working on the task when assigning generic resources OR the percentage of the availability an individual will work on the task (when assigning individuals). This number is entered in the field Units on the Task Form. There is no activity-related units field, but it can be calculated as an average for all resources working on the activity by: Units (activity-related) = Work / Duration. All these five terms start with an ‘A’, so we refer to ‘workload modeling’ also as ‘5A-scheduling’. To monitor the cost of a project, you need to add more data to the Workload Model: ◆ Capital Available: The capital available is the budget as approved. ◆ Charge Accounts: Account categories from the budget in a lookup table visible in a custom field in Microsoft Project to tag tasks, resources or assignments with these charge accounts. PAGE 132

© PROJECTPRO CORP.

Forecasting Programs

Chapter 4 Organizing the Program

◆ Cost and Material Resources: Cost resources and Material resources to capture all other expenses needed for the project. ◆ Charge Rates: The Standard Rate, Overtime Rate and Cost per Use for each resource Many organizations use so-called blended rates that are average rates for each role, so HR does not need to reveal each person’s salary, which is considered private information. ◆ Cost Accrual: Cost accrual is when the costs should be charged to the project; the options are: At the Start or Finish of an assignment, or Prorated – spread out over the duration of the assignment. ◆ Changing Rates over Time: How rates change each calendar year (a.k.a. rate escalation). All these six terms start with a ‘C’, so we refer to ‘cost modeling’ also as ‘6C-scheduling’. As you can see, each next-level model needs the previous, simpler model(s) as a starting point: ◆ Before you can create a Workload Model, you need to have a complete Time Model. ◆ Before you can create a Cost Model, you need to have a complete Workload Model (that needs a complete Time Model). As you add more data, the schedule model becomes more complex and will require more effort to keep it up-to-date. Tip► As you can see, there is natural progression between these different types of modeling which also applies when learning the scheduling application: We recommend that people start with modeling the time of their project first, then try to model workloads, and, eventually complete their skillset with modeling costs.

Time Model Example We will look at a house renovation project to illustrate each type of model. By the way, this is the project schedule I created for the renovation of my own home, so it is a realworld example.

© PROJECTPRO CORP.

PAGE 133

4

Chapter 4 Organizing the Program

Forecasting Programs

The time model of this project looks like a Gantt Chart with all Deliverables, all Durations and all Dependencies; some of the deliverables have Deadlines but no Start or Finish Dates (4D-1D scheduling):

As you can see, it is a small schedule that fits well within one page, but all pertinent information is there for this 4D-1D time model. Such a schedule is a very simple model of the project that can easily be explained to any stakeholder. Regardless of its simplicity, this schedule allows you to forecast the project: ◆ Deliverables: All deliverables (the things of value to the client) are listed. ◆ Deadline: Deadlines are promised dates, or, in this project, the contractual dates between the owner of the house and the general contractor. The agreed-upon dates are entered for each deliverable as captured in the home renovation contract; they are entered into the Deadline date field. ◆ Durations: The general contractor came back to me with durations estimates for each deliverable and I entered them into the time model. ◆ Dependencies: The relationships between the deliverables are captured on a highlevel: For example, we wanted the Water System and Septic System out of the way before the renovation of our home was started. I used some tricks to make this Gantt Chart look nice: ◆ I colored all milestone text red (ribbon Format, button Text Styles) and all milestone diamonds red (ribbon Format, button Bar Styles) to make them stand out. ◆ I created a new field called: Total Slack until Deadline: Microsoft Project does not calculate the Total Slack from the Deadline date back in the backward pass. Instead, it calculates from the Early Finish date of the project back (which always makes the Total Slack for the project zero and does not provide feedback on how much time buffer is left). So, I added this custom field Text1 with the following formula to see how many days were left before the project deadline as captured in the contract with the general contractor: IIf([Deadline]\myfile\8 that refer to the Project Online / Project Server database. These ID numbers are the real ID numbers that correspond to the ID field. However, ID numbers change constantly and are not suitable to use to organize the data and maintain integrity. MS Project actually uses Unique ID numbers for this, which do not change and are never re-used when deleted. The numbers shown in the fields Unique ID Predecessor and Unique ID Successor fields are Unique ID’s as shown in the project schedule. In the background, MS Project uses the Unique IDs to keep the right tasks linked and re-adjusts the ID numbers constantly. For the user, it is easier to work with ID numbers because they are typically listed sequentially. The Unique ID numbers are very large inside master schedules, as explained earlier (see page 174), and are typically not listed sequentially, which make them hard to work with. ◆ Paths are displayed as absolute paths by MS Project in Predecessor and Successor fields and in screen tips of the project icon , but they actually work as relative paths. An absolute path is when you take the path name literally and navigate through the file system as literally indicated in the path. A relative path is when you interpret it as the location of the directory (folder) relative to the location of the active directory (folder). The path to external tasks in the Predecessor and Successor fields is displayed as an absolute path-reference, such as C:\SoftwareDevelopment\dev.mpp\8, but MS Project actually uses it as a relative path-reference. For example: When the current file directory is C:\Development\, an external link to the file C:\Testing\DevTest.mpp\4 will work in practice as: Go one directory level up to the drive letter C: and then one directory level down again into the subdirectory called ‘Testing’ where you will find the file ‘DevTest.mpp’. Tip► Because of the relative paths, you can move master and project files around in your file system if you maintain their relative folder locations, which is easiest if you simply keep them all in one subdirectory (folder). So even though you can create an intricate system of subdirectories with specific access rights, we recommend that you keep all schedules in one subdirectory if possible. When people cannot be trusted with access to each other’s files, you can create the subdirectories and assign personalized access rights to them. Or if you have a shared resource pool file © PROJECTPRO CORP.

PAGE 203

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

(.MPP), you can protect that file by putting it into a protected file directory. When you find yourself having to make these accommodations, you should really consider getting Project Online in the cloud or Project Server on-premise, because these systems take care of access security for you in an elegant way. ◆ Multiple external Predecessors or Successors are possible on one task. You can give one of your tasks more than one external predecessors or successors. Tip► Note that some fields of the external task contain linked data from the project schedule (which exists in one place, thus maintaining unity of data), whereas one field is replicated and can be edited without changing the linked schedule: the field Notes. The Notes field can be edited in either file separately from the other! This allows both project managers to document their own side of their cross-project link as they deem fit without affecting the linked schedule.

To Maintain the Cross-Project Links 1. Choose ribbon Project, button Links between Projects; the dialog Links between Projects in …. appears as shown here:

2. Click on tab External Predecessors; the list of external predecessors is shown. 3. Select an external predecessor in the list; the buttons at the bottom of the dialog are now enabled. 4. To update the link and accept the differences, click button Accept. To accept all differences, click button All. To delete the link; click Delete Link. To indicate a new location or name of the file; click button Browse. PAGE 204

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

5. View the External Successors and verify if the dependent project manager has resolved the Differences. If you don’t have Read-Write access to the successor project, you don’t have authority to accept or reject changes. Contact the project manager of the external successor to resolve any differences that continue to appear update after update, and urge the project manager to accept the difference or explain why the new date (slippage or earlier date) in your schedule cannot be accepted. Trap! As you can see, Microsoft Project will never be a substitute for communication, which seems to be what some project managers secretly hope for! Trap! Notice that the Accept button is enabled for external successors even though you

should not always accept the decisions of dependent project managers that cause your project to slip. You should not make the differences go away for External Successors. That is NOT your jurisdiction! I commented that there is a fundamental weakness in the way this feature is designed: the project managers decide whether they accept impacts or not, but it should be the program manager who decides which impacts can flow through the program and which impacts should be blocked from flowing through other projects. More on this in the next section on third-party solutions for cross-project dependencies (see page 215).

The Links Between Projects Dialog Trap! The following dialog box is, in my opinion, one of the worst dialog boxes in MS Project in terms of design and user-friendliness.

© PROJECTPRO CORP.

PAGE 205

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

Note that there are two tabs in this dialog box: One for External Predecessors and one for External Successors (currently displayed):

The Start date changed.

The Finish date changed.

The dialog box always has at least two lines for each external dependency. The first line (with the ID number, in this case 86) refers to the internal task (i.e., the task in your project schedule). The next line(s) without ID numbers contain information on the external task(s) in other project schedules. The previous screenshot shows that your task 86 has three external successors: Upfront Installation & Configuration, Develop Upfront Integration and Configuration Test according to. Tip► The dialog has three items that need more explanation: the columns Date and Differences and the text field Path in the bottom of the dialog box: ◆ Date column: In the screenshot you can see what the Date field does; it should be interpreted as the “old date”. Beware:  It can be the old start date if it shows Start on the same line under Differences, for example for task 86.  It can be the old finish date if it shows Finish on the same line under Differences, for example for task 61. ◆ Differences column: contains notices about the cross-project link (see next table). ◆ Path (at the bottom of dialog): click on an external task in the list and check the path and filename of the task at the bottom of the dialog box.

PAGE 206

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

Messages in the Column ‘Differences’

Remark

Explanation

What to do?

None

The link is up-to-date.

Nothing

File not Found

The linked file is deleted or moved to another subdirectory or renamed.

If the file is moved, use the Browse button to indicate a new directory. When the file is found, the message changes to: File Located.

Delete External

The other scheduler deleted the external task (not the link!).

Select it and click Accept to remove your side of the dependency as well as the external, gray ghost-task from your task list.

Create External

A new link was proposed by another scheduler (who only had read-only access to your schedule).

Select it and click Accept to create an external task in your schedule.

Start to

The start date of your dependent task is changed, often driven out (slipped).

Accept the new date if you can manage it within the time buffer of your project (Total Slack). If you can’t accept it, request driving project managers (predecessor) to resolve their slippages.

Finish to

The finish date of your dependent task is changed, often slipped. This can happen when a Finish-to-Finish dependency was used.

Accept the new date if you can manage it within the time buffer of your project (Total Slack). If you can’t accommodate and accept it, ask driving project managers (Predecessor) to resolve their slippages.

Trap! Note that if an external link is deleted on one side (i.e., in one of the two project schedules), it does not cause the message Delete External to be displayed in the other project schedule, which one might expect. Instead it shows up as no difference (None) or as a difference in start date (Start To) or finish date (Finish to); MS Project misleadingly makes you think that the link is still alive. If you double click on such a ghost external task, the dependent schedule comes up and shows the remark Create © PROJECTPRO CORP.

PAGE 207

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

External. This allows you to re-establish the external link in the schedule. The problem is that it is too hard to find orphaned links between projects! Tip► We must conclude here that it is best to maintain the Links-between-Projects in the integrated master schedule (IMS), just like it is best to create them in the IMS in the first place. However, be aware that a project manager could inadvertently delete one side of a cross-project link, so be alert to the Create External message. The inadvertent deletion happens when the project manager: ◆ Deletes the gray external task. ◆ Cuts and pastes the anchor milestone (to which an external task is linked). ◆ Deletes the anchor milestone.

Exercise: Accepting the Impacts from Links-between-Projects 1. Copy the following two files 06 Relocation ABC Inc.mpp and 06 Relocation Devom Inc.mpp onto your hard drive in a directory where they can be opened in a read-write fashion. 2. Insert them both into a new master schedule 3. Use the Link tool (on the Task ribbon) to set a link between the two Move tasks 4. Close the master schedule and save all its (sub)projects. 5. Open 06 Relocation ABC Inc.mpp (predecessor file) and slip some tasks such that the external successor slips as well: You should see that the external task is rescheduled to later in time (to the right in the timescale). 6. Close the predecessor file and save it. 7. Open the successor project; the dialog Links between Projects should appear automatically displaying the impact on the start date for the task Move (if the option ribbon File, item Options, tab Advanced, option  Show ‘Links Between Projects’ dialog box on open is selected). 8. Accept the external impact: select the link to update and click button Accept in the bottom of the dialog and then click button OK. 9. Insert the field Project (right-click on a column heading, select Insert Column) for the external task and check the name of the project of the external task; you should see the name of the predecessor project: 06 Relocation ABC Inc.mpp.

PAGE 208

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

Possible Problems: Circular Dependencies A circular dependency is shown in the following screenshot; you can see that the dependency from the last task 226 at the bottom of the screenshot bends around to the left and routes back into the first task 521 at the top of the screenshot:

6

Trap! It takes an inordinate amount of time to identify all tasks involved in a circular dependency that “should not have been there”; making the circularity as clearly visible as in the above screenshot took me hours of work. Tip► MS Project 98 was the first release that prevented circular dependencies from being created. However, when the feature Links between Projects is used, MS Project will alert you if you are creating a circular relationship only if you are creating the crossproject dependencies in the integrated master schedule file with all its projects opened in it. Trap! Circular dependencies can still happen if you created the cross-project dependencies quickly by temporarily merging two of the project files using Window, New Window, which is why we do not recommend using this method. Instead, you should create and maintain links between projects in the integrated master schedule to prevent the nasty circular links.

© PROJECTPRO CORP.

PAGE 209

Chapter 6 Linking Projects in a Program

Forecasting Programs

When MS Project notices a circular dependency in the master schedule, MS Project used to turn automatic recalculation to manual and display a message in the status bar at the bottom left of your screen to indicate that a recalculation is needed. The 2016 release of MS Project does not do this any longer, so you would not know that you have a circular dependency! Tip► To find the circular dependency, sort all tasks on their Finish date, then look for any dependency that bends around to the left and goes back in time (to the left in the timescale) like in the screenshot above.

Do’s and Don’ts when Working with Links-between-Projects We present here a list of do’s and don’ts that should help you work well with the Linksbetween-Projects feature. However, in our experience, if the number of cross-project links exceeds 30, this feature becomes too arduous, and we recommend you purchase a specialized tool to handle cross-project links in an orderly fashion; we will discuss one of these applications, called CrossLinksPro, next (see page 215). Do’s: ◆ Keep all files in one subdirectory (Create different subdirectories only if you have to). Keeping all files in one subdirectory keeps all relative paths easy to follow and makes it very easy to create backups of all files with a single copy-and-paste maneuver. If people might mess up each other’s files, you can create a different subdirectory for each schedule owner (i.e. schedule with external links), and give each schedule owner read-write access to their own directory and read-only access to the other directories. This also prevents accidental loss of the links between projects. You can still update the impacts across the files by opening the master schedule. The relative path-references will allow you to do this and still allow you to make backup copies easily by copying all subdirectories at once. Pay attention when you do this, because once you end up with links between the backup files and working files, you will spend hours untangling them. When this happens, you can see the path-references in the Successor and Predecessor columns. ◆ Document the links Document the cross-project links by writing a Note on the external task. The Notes field is one of the few fields you can edit for external tasks. The note is stored and visible in your project file only. ◆ Keep the external tasks visible Keep the ribbon File, button Options, tab Advanced,  Show External

PAGE 210

© PROJECTPRO CORP.

Forecasting Programs

◆

◆

◆

◆

◆

Chapter 6 Linking Projects in a Program

Predecessor and  Show External Successor selected. This will help prevent accidentally deleting, cutting and pasting or duplicating tasks with external links. Keep the external task listed next to the internal task Tip► Keep the external task listed next to its internal task by dragging tasks ( Trap! no cutting and pasting!). Keep external predecessors above your task and external successors below. Check the External Predecessors tab often in the Links Between Projects dialog To display the Links-between-Projects dialog, click ribbon Project and button Links Between Projects . You need to stay on top of impacts that are pushed into your schedule and react right away if they push your schedule out too far consuming the entire time buffer you had built into your schedule. Also check on External Successors in the Links-between-Projects dialog As the predecessor project manager, you can see if the successor (dependent) project managers accepted the impacts from your schedule or not and call the successor project manager to resolve issues if the Differences persist. You, as the driving project manager, should not Accept the Differences, because you do not own the driven schedule. This visibility creates peer review and peer pressure to resolve issues and keep all schedules valid. Tip► Make sure your file backup system is reliable Make sure the linked files are backed up regularly and confirm the backup files are healthy by opening them up sometimes. You cannot copy linked files easily (see Don’ts), so people will work continuously with only one file or schedule (which is the standard in Project Online and Project Server); the back-up of this file needs to be reliable. The best way to backup an integrated master schedule including all its project schedules is by copying and pasting the entire directory in which they reside or zipping them into a zip-file. We recommend you append the date (and time perhaps) to the new directory name or zip filename to make it clear visible. Create the cross-project links in the integrated master schedule to the extent possible to prevent circular dependencies.

Don’ts ◆ Trap! Don’t delete a linked task Don’t delete a task with an external dependency, unless you want to break the link as well. ◆ Trap! Don’t delete an external task This breaks the external link as well. ◆ Trap! Don’t cut and paste a linked task Instead of cutting and pasting a linked task with the clipboard tools, move it by dragging the task. Cutting a task temporarily deletes it as far as MS Project is concerned, and the link will be lost as a result. The link may even be rerouted to

© PROJECTPRO CORP.

PAGE 211

6

Chapter 6 Linking Projects in a Program

◆

◆

◆

◆

Forecasting Programs

another task in a best guess from MS Project with AutoLink on (ribbon File, item Options, tab Schedule, option  AutoLink inserted or moved tasks). Don’t create external links on project summary tasks Don’t set the cross-project links between project summary tasks, because the external tasks will not be visible to the other project manager; nothing can be shown above project summary task with ID 0 (zero). Linking to project summary tasks will cause confusion. Trap! Don’t move one of the linked files: the link will be broken. Instead move all linked schedules together as a group that needs to stay together. If you move a linked schedule, the link will be broken, an error message will appear in the Links-between-Projects dialog, and the link will need to be repaired. Trap! Don’t copy one of the linked project files; the external links from this schedule will be duplicated. Don’t copy one of the linked files to a new subdirectory; all cross-project links in that schedule will be duplicated. Instead, close all schedules and copy the entire folder (or tree of folders) in which all linked files are located; the files can be in different subdirectories. The files always need to be copied in such a way that the relative file-references stay intact, otherwise links are broken. MS Project always remembers file locations for the external links first as: “One level up and then one level down into the subdirectory …”. A copied file will keep the links to the original schedule files and can easily duplicate the links. Don’t open two schedules that are read-write on one computer if the files have Differences between them. As soon as you open both schedules (even if you have just read-only rights to the other schedule), all Differences between the two schedules are automatically accepted. Close one schedule before you open the second one. Make a quick screenshot if you want to compare the files. If you have read-write access to both files and save them, all differences will be accepted in the impacted schedule. Notice that when you open the master schedule with projects inserted read-write, all differences will be wiped out automatically! This is good because it allows you to perform Program Critical Path analysis. It may be bad because when you save the projects upon closing the master, all differences will be wiped out forever, perhaps inadvertently!

Tip► As you can see, the number of do’s and don’ts is long. It should be clear at this point that implementing this feature will require a lot of training for the program manager and all project managers. We have found that, even after thorough training, accidents will still happen. It is a hard system to manage, as we learned the hard way when we first tried to use this Links-between-Projects feature in 10,000 task programs with 500 cross-project dependencies; the clients weren’t very happy and neither were we!

PAGE 212

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

Advantages & Disadvantages of Links-between-Projects Even though we presented a short list already of the most important pro’s and con’s for this Links-between-Projects feature in MS Project, we present here a more comprehensive list now that you have gained first-hand experience with this feature in the exercise: Advantages: ◆ Always see the latest impacts You will have automatic, but controlled updates. The links allow you to keep the schedule up-to-date automatically when external forces affect your schedule. The updating is not immediate and happens upon opening the schedule. ◆ Program Critical Path Always see the Program Critical Path in the integrated master schedule (IMS) ◆ Delegate schedule ownership This feature makes it possible to delegate ownership of sub schedules to project managers who are ‘closer to the fire’. Cross-project links allow you to divide the program into projects, which allows you to delegate schedule ownership to the responsible people while maintaining the integrity of the program. Disadvantages: ◆ No overview of all interdependencies There is no overview of all cross-project dependencies, which would be very useful for the program manager. The program manager does not have an overview of whether handoffs between projects are on time or slipping and cannot see the impacts of all cross-project links in one place. ◆ Wrong architecture Project managers make decisions about impacts instead of the program manager, whose primary responsibility it is to manage the coordination between the projects in the program. The project managers are prompted by the tool to accept or reject impacts. This decision should not be up to the project managers but to the program manager, who has the authority to decide if impacts flow through the program or should be stopped. ◆ Project managers feel they lose control: Project managers find it difficult to work with linked schedules; they feel they lose control over their schedule. Some project managers feel that ownership of their schedule is taken away from them because the external links can cause extra variations in their schedule. This feeling is caused by the fact that:  Links-between-Projects dialog box is not intuitive  Sometimes impacts seem to be accepted randomly, when in reality, someone made an error when working with the master schedule or with multiple project schedules.

© PROJECTPRO CORP.

PAGE 213

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

◆ Links-between-Projects are not protected: In practice, anchor milestones (that have external links) often disappear, taking their external links with them. Since the 2003 edition, MS Project prompts when it is about to remove an external dependency. When you break a link, the linked project manager will not see a specific notification in the Links-between-Projects dialog. The dialog just shows None, Start to, or Finish to. External links can also be easily duplicated through copy and paste, for which MS Project does not issue a warning either. All in all, it is clear that these links are not well protected. ◆ Schedules with external links open very slowly When you open a linked schedule, MS Project will briefly open each schedule to which it is linked to retrieve the latest dates of that schedule and calculate the impacts to display in the Differences column in the Links between Projects dialog. This takes time! ◆ Sub schedules have fragmented Program Critical Path Each sub schedule has a fragmented Critical Path when opened standalone to be explained later in more detail (see page 273). The project manager cannot see in his/her own project schedule which tasks are critical from a program point of view. The Program Critical Path is only visible in the integrated master schedule (IMS). ◆ The master schedule always accepts all impacts upon opening As soon as you open the master schedule, you have accepted (but not yet saved!) all cross-project impacts, so you can start identifying and analyzing the latest Program Critical Path. If you save the schedules, all impacts (Differences in the Links between Projects dialog) will be wiped out; and no Differences will show up any longer. ◆ Higher instance of file corruption There seems to be a higher instance of file corruption among linked project files. Even in Project Server, linked schedules corrupt at times. You will notice that a file is corrupted when one of the following occurs:  A schedule suddenly no longer opens.  Scrolling through a project schedule with arrow keys or scroll bars makes the screen suddenly freeze, and it freezes every time at the same spot.  The screen freezes and the application no longer responds; you need to close the application and restart it. When schedules become corrupted, you almost always lose the changes you made since your last save. In the 1990s, the probability of file corruption was so high that we developed an intricate system of making frequent backup copies and tracking in a logbook every change (!) we made in the master schedule, so we could re-create the master schedule quickly from the last backup after it corrupted. We have not used this system in this new millennium, but file corruption still occurs.

PAGE 214

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

Tip► After looking at this long list of disadvantages, we must conclude that this Links-between-Projects feature was not designed for integrated program schedules with more than 1,000 tasks and about 20 cross-project links. It is only workable for small programs.

Working Around the Disadvantages There are ways to alleviate some disadvantages: ◆ You can take your file home or on a trip To get up-to-date information via the cross-project links, the linked file must be accessible to your project file. For this reason, the linked files must both reside on for-each-other readable servers. It is possible, however, to take a project-file home and leave the old file accessible to its counterpart. Upon returning, you can replace and override the old file. We recommend you do this while the master schedule is NOT open! ◆ If you move or rename your project… You can move your project to another location or rename your file, if you tell the other scheduler, who can then refresh the location or filename by opening both files and using ribbon Project, button Links Between Projects, button Browse to point to the new file and directory. The file reference of the link is updated on both sides, if both files are open. If one of them is closed, the link dies and will have to be recreated manually.

5 CrossLinksPro: Our Solution for Integrated Programs At ProjectPro, we developed a unique solution for program managers, called CrossLinksPro, to work around the disadvantages of the Links-between-Projects feature in MS Project. Our solution is targeted at and specifically tested for programs between 1,000 and 50,000 tasks, but is likely suitable for larger programs as well. The main benefits of this solution are that you end up with an entirely integrated master schedule and you can easily identify the Program Critical Path using another application we developed: PathsPro. The solution focuses on the handoff deliverables between the projects, which are the primary concern of the program manager. The design objectives for this solution were: 1. Empower the program manager with a dashboard on cross-project links a. Make the agreed-to date and the latest forecast date for handoff deliverables visible in one central place – a dashboard. This allows program managers to meet one of their prime responsibilities: © PROJECTPRO CORP.

PAGE 215

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

Monitoring the performance of the interfaces between the projects and the handoff deliverables. b. Allow the program manager to perform Program Critical Path analysis within the Integrated Master Schedule (IMS) in Microsoft Project. For this, we use our other PathsPro add-in application with which the program manager (or program support staff) can: ▪ Select any major milestone in the IMS and see the Critical Path leading into it within a minute. ▪ Select the program completion milestone and see the Program Critical Path within minutes. CrossLinksPro empowers the program manager with regular information on any slippages of these handoff deliverables. The program manager can then decide whether to accept or reject the slippages after analyzing if the slippages affect the overall program milestones. The Links-between-Projects feature in MS Project is designed in such a way that it invites the project managers rather than the program manager to decide whether to accept or reject a new impact. In our view, these decisions are the responsibility of the program manager rather than the project managers’. CrossLinksPro makes all new impacts visible in a central dashboard after a schedule update by all project managers, so the program manager can monitor the performance of all interdependencies as well as whether each project manager is sticking to their deadlines ̶ the agreed-upon dates between project managers. 2. Protect the cross-project dependencies 100% As we have seen, the Links-between-Projects feature in MS Project does not protect the cross-project dependencies well; they can easily get lost or duplicated. CrossLinksPro protects the cross-project links 100%. By this we mean: a. Cross-project links will not get lost: If you have hundreds of Links-betweenProjects saved in the project schedules, you are bound to lose one or two dependencies every week as we experienced at one of our first clients. CrossLinksPro does not save the Links-between-Projects in the files; it creates them when needed and removes them before saving. b. Cross-project links will not get duplicated: If people click File, Save As, the links of the project schedule will be duplicated when you use the Links-between-Projects feature in MS Project. With CrossLinksPro, the project files are most-of-the-time unlinked (non-integrated state) and can then be duplicated safely for back-up purposes or even stored in enterprise content management systems that will reject Links-between-Projects.

PAGE 216

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

3. Allow project managers to work independently with their schedules If a schedule has live, external links, it becomes cumbersome to work with; you must follow the list of do’s and don’ts exactly (see page 210); an error can lead to hours of extra work. In addition, you can only store the sub schedule on a file server or in a Project Server/Project Online database, but not in SharePoint or other document management system. 4. Open sub schedules fast Avoid having linked schedules open very slowly. A schedule that is linked to ten other schedules may take about five minutes to open before it is displayed on your screen and ready for editing. 5. Allow for resource-loading of schedule and Resource-Critical Paths The USA General Accountability Office (GAO) Schedule Assessment Guide 25 states explicitly that capital projects in the USA should be resource-loaded in order to determine the feasibility of the program. The standard for the second version of the Critical Path, Critical Path 2.0 26, specifies that schedules should be resourceloaded, and the Program Critical Path could be a resource-constrained Critical Path. Finding the Resource-Critical Path in an integrated master schedule is the most challenging task; we have only had to do that once, during our work at SanDisk on New Product Development programs for flash-memory products that are in an ultracompetitive, time-to-market environment.

Reducing the Program Model to Something Manageable To reduce the amount of data to a manageable amount for the program manager, we can reduce the program to a list of handoffs between the projects and treat each project schedule as a black box for the program manager, as shown in the illustration. The list of cross-project dependencies is the program manager’s model, just as much as a project schedule is the model for the project managers. Tip► If program managers make sure they hire competent project managers for each project, they can stop worrying about the details of each project schedule and delegate

25 26

See GAO website: https://www.gao.gov/products/GAO-16-89G See the website: www.ProjectProCorp.com under Articles, White Papers.

© PROJECTPRO CORP.

PAGE 217

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

this responsibility to their competent project managers. The prime responsibility of the program manager is the coordination across all projects! Tip► Each handoff (dependency) between the projects needs to be identified and defined. Identifying the dependencies works best when you ask each project manager what he or she needs from other project managers. For whatever reason, people seem to be better at defining what they need from others than what other people expect from them. Extrapolating from this funny observation, could we even state perhaps that: People know better how to come up with excuses for their lack of performance than how to be of service to other people? If this is true, this would be a sad observation about the world we live in. So much for this philosophic escapade.

For each handoff, we recommend you create two milestones: ◆ One in the provider schedule (giver that creates the handoff deliverable), and ◆ One in the receiver schedule (getter that needs the handoff as input or necessary supply). Each handoff milestone needs to be coded in both the provider schedule and the receiver schedule. The definition of a handoff would look like this: ◆ A unique name for the handoff to identify it (e.g., ‘DesignDocA’ in the illustration) or a unique code like AB01 ◆ The (unique) name of the providing project or its abbreviation (‘A’ in the illustration) ◆ The Unique ID of the provider (giver) (‘341’ in the illustration) ◆ The (unique) name of the receiving project, or its abbreviation (‘B’ in the illustration) ◆ The Unique ID of receiver (getter): (‘234’ in the illustration) Tip► Note that the Task Names would be nice-to-have when you work with the system, but they are not necessary for CrossLinksPro to work. The Unique IDs are reliable identifiers for the milestones, because they are never recycled or re-used.

CrossLinksPro, Solution for Integrated Programs The CrossLinksPro solution consists of: ◆ Excel spreadsheet to list all cross-project links which will serve as:  Dashboard for the program manager to monitor cross-project links PAGE 218

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

 The dashboard will double up as the input sheet for CrossLinkssPro that contains all definitions of the handoffs (i.e., schedule code, unique IDs, handoff code and/or name) ◆ MS Project Add-In that has the following functions:  Provide an easy-to-use interface that facilitates the creation of new Linksbetween-Projects. You can create new cross-project links by simply dragging between two project displayed side-by-side.  Update the spreadsheet with latest dates and impacts or buffers: The Excel spreadsheet becomes a dashboard that tells the program manager how big the remaining buffers or slippages are on the handoffs after each update cycle (typically every week, or every month at least).  Create the cross-project links in an automated fashion to produce the integrated master schedule If there are impacts that might jeopardize major milestones, the integrated schedule needs to be put together first, after which the new Critical Path can be identified and optimized.  Identify the (new) Program Critical Path  Replace the cross-project links with Start-No-Earlier-Than constraints on the receiving milestones to make the sub schedules independent standalone schedules again, so they can be taken away for the next update or saved in an enterprise content management (ECM) system.

© PROJECTPRO CORP.

PAGE 219

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

Example Program “Write Book” We will illustrate CrossLinksPro with a small program, called Master Schedule Book, with two projects: Front and Back and Middle. The publisher handles the front (outline) and the back (edit, print and distribute) of the program. The lead writer handles the middle part of the program (the writing), as is shown below.

This program schedule has: ◆ Front and Back sub schedule (abbreviated to F&B as its schedule code) managed by the publisher ◆ Middle sub schedule managed by the lead author Notice: ◆ The Start-No-Earlier-Than constraint dates on the tasks Publish, Write X and Write Y; they keep the project activities scheduled where they need to be when there are no cross-project dependencies. ◆ The baseline has just been set; all activities are on schedule. The deadline dates on Write X and Write Y are met.

Excel Spreadsheet to List All Cross-Project Links Both authors obviously need the Outline from the publisher, which creates two crossproject links. The publisher needs to receive the written text from both authors, which

PAGE 220

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

creates another two cross-project dependencies for a total of four dependencies. The Excel Spreadsheet with all cross-project links will then look like this:

As you can see, each dependency is defined as a line item in the spreadsheet. This spreadsheet will be used by CrossLinksPro as its input sheet when it creates the cross-project links in an automated fashion. At the same time, this spreadsheet can function as a dashboard for the program manager to keep track of how much each handoff deliverable is slipping at each update cycle and even see emerging trends.

Program “Write Book”: Updated Schedules The sub schedules have been updated by the project managers in the first update cycle. After these updates, the program schedule may look like this:

The publisher was late delivering the outline. Author X started late and will take longer. Author Y will deliver early. The program manager suspects that there are problems in the schedule but does not know how big the problem is for the program as a whole. Thus, the program finish milestone still seems ‘on schedule’. We need to populate our dashboard in Excel with the latest dates to see the slippages on each handoff. © PROJECTPRO CORP.

PAGE 221

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

CrossLinksPro: Get Latest Dates: Handoff Dashboard CrossLinksPro, our MS Project add-in application, is run to update the Excel spreadsheet with the current dates and slack (buffer) or impact (this feature is called Get Latest Dates in CrossLinksPro):

Now, the program manager can see how big the impacts are on each handoff, which indicates how well each project manager is performing. Still, the program manager does not know exactly by how much the entire program will slip because of small slippages in each project schedule. The integrated program schedule needs to be put together to show this.

CrossLinksPro Creates the Links CrossLinksPro, an add-in to MS Project, is run to create all cross-project links in the master schedule resulting in the integrated master schedule in an automated fashion. This feature is called Create Links and it uses Microsoft Project’s native feature Linksbetween-Projects to create the links:

PAGE 222

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

At this point in time: ◆ The Start-No-Earlier-Than constraint dates on all receivers have been replaced by the cross-project links. The master schedule for the program is converted into an Integrated Master Schedule (IMS). ◆ The Program Critical Path can be identified: It is obvious that in this simple example the Program Critical Path runs through activities Write X (slipping in project Middle), Edit and Publish (project Front and Back). Once we know where the Program Critical Path runs, we can optimize it to compensate for the new slippages experienced. Changes are made in the master schedule and can immediately be saved into sub schedules, such that the project managers immediately continue to work with the optimized schedules in which problems have been resolved. Tip► The unique aspect of CrossLinksPro is that it enhances Microsoft Project but does not take the data out of this scheduling application, which allows you to make the changes directly in the original schedules of the Microsoft Project scheduling application. Tip► The add-in will notice if an entry in the Excel spreadsheet creates a circular dependency. Remember our earlier recommendation: Cross-project dependencies need to be created in the master schedule. CrossLinksPro creates the links in the master schedule. It will notice if links causes circularity and report back which handoff dependency causes circularity by adding Notes to the Handoffs worksheet in Excel. This makes it a lot easier to deal with circular dependencies, because you can easily isolate them and remove them. The steps for this isolation process are:

1. If the handoff dependency seems to be the incorrect circular dependency itself, remove it from the Handoffs worksheet. 2. If not, move the handoff dependency to the top of the table in the Handoffs worksheet, so it will be created first; another handoff dependency will be marked as circular. 3. If needed, remove existing cross-project links by running the Remove Links feature in CrossLinksPro. 4. Run the Create Links functionality again using option  Retrieve and Validate data entered in Excel and override all remarks in the Notes field in CrossLinksPro to force it to re-read the changed handoff data in Excel. 5. Another handoff dependency will then be marked as the circular dependency in the Notes field, and that one should be removed. Or reconsider and remove the original. One of the two must be the circular dependency, unless the logic inside the project schedules is incorrect, which happens in rare cases. In that rare case, the circular dependency is now easier to locate, because it must be in one of the two paths © PROJECTPRO CORP.

PAGE 223

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

between the two handoff dependencies involved in circularity. See also our previous discussion on circularity (page 209) to visually recognize which one is the culprit.

PathsPro Analyzes the Program Critical Path To analyze the Critical Path, we use another add-in called PathsPro, which allows you to identify the Critical Path into any major milestone in the integrated master schedule. PathsPro uses the concept of the Most-Critical Path, which is known for always fully explaining the latest finish date of the analyzed milestone and determining a complete critical path. Tip► PathsPro also marks all critical tasks on the Program Critical Path in one of the extra Flag fields (that you can pick before running PathsPro), which allows the project managers to see if there are any tasks in their project schedule that appear on the Program Critical Path. This allows all project managers in the program to be proactive by further optimizing these program-critical tasks with their own project team so they never let the program slip beyond its deadline date. Here the CrossLinksPro and PathsPro solution provides perhaps the greatest advantage for program manager. This is how we turn program managers, who are always forced to report further slips and are, hence, perceived as messengers-of-bad-news, into messengers-of-good-news.

CrossLinksPro Marks Handoffs as Critical in Excel CrossLinksPro can write the results of the Program Critical Path analysis to the Excel spreadsheet and mark the handoffs that were on the Program Critical Path as critical handoffs. A Critical Handoff is an integration milestone that appeared on the Program Critical Path and drives the duration of the program schedule. This feature is called Critical Handoffs, and it fills in a column in the Excel Spreadsheet called Critical Handoff. Tip► After the next update cycle, the program manager can see if new slippages have appeared on critical handoffs, which increase the need for re-integrating the master schedule again. If slippages appear on non-critical handoffs, there is not much need to re-integrate the master schedule.

PAGE 224

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

CrossLinksPro Replaces and Removes Links after Optimizing Finally, using CrossLinksPro, the cross-project links are replaced with Start-no-Earlier-Than constraint dates and broken again by the Remove Links feature in CrossLinksPro: The project schedules are now standalone schedules again, which open fast and are much easier for project managers to work with. The optimized schedules are now standalone schedules again, and ownership of the schedules can be given back to the project managers. The result will look like in the next screenshot:

6 Optionally, this application feature updates the agreed-upon baseline dates on the handoff milestones in the providing schedules captured in the Excel spreadsheet; this feature is called Refresh the Baseline Dates. Sometimes new agreements on dates are struck between the project managers facilitated by the program manager.

Original Unique IDs from Sub Schedules Shown in Master Notice that in the following screenshot task 1 is a project called 01_Sys Eng Schedule_GRCS, and the Unique ID numbers are new numbers inside the master schedule.

© PROJECTPRO CORP.

PAGE 225

Chapter 6 Linking Projects in a Program

Forecasting Programs

Large numbers starting with the seed number 8389470 in this case:

MS Project’s default renumbering of Unique IDs inside the master schedule: large cumbersome numbers Custom Number field with a formula to display the original Unique ID number inside the master schedule

Trap! Microsoft Project renumbers the Unique ID numbers of tasks as soon as you insert the project schedule into a master schedule, changing the original Unique ID numbers into really large numbers often in the 8,000,000 range. It does this to make sure each Unique ID is unique inside the master schedule. This makes sense but is very annoying if you use the Unique ID to refer uniquely to the task in a sub schedule, as we do in our CrossLinksPro application, because you cannot find the Unique ID in the Excel spreadsheet easily in the master schedule. The spreadsheet in our solution uses the original Unique ID numbers from the project schedule to keep track of the cross-project links, not the new Unique IDs from the master schedule. Therefore, we want to see the original Unique ID numbers inside the master schedule as well (making sure you are looking at the right sub schedule). Tip► We can display the original Unique ID numbers inside the master schedule by creating a custom Number field (e.g. Number20) and calling it Unique ID in Subschedules in each project schedule with the following formula: [Unique ID]

For Calculation for Task and Group Summary Rows: select  Use Formula. This formula copies the Unique IDs into an extra field that is static and therefore displays the same Unique ID number inside the master schedule. Customize the same Number field in the master schedule and give it the same name: Unique ID in Subschedules. Enter the same formula in this field and display this field in the master schedule as well (right-click on a column heading, select item Insert Column); the master schedule will now display the original Unique IDs of the tasks as they appear in the sub schedules as shown in the previous screenshot.

PAGE 226

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

Typical Weekly Process when Working with CrossLinksPro There is a typical weekly (or monthly) process when working with CrossLinksPro. As ProjectPro consultants, we typically run this process for four consecutive periods on behalf of our client in collaboration with the Program Support Office (PSO). After that, the PSO typically has gained enough confidence to continue the following process on its own (and we go on to our next gig): 1. The first step is to get the project managers to update their schedules and submit the schedules to the repository, which can be a central file server or the Project Online / Project Server central database (SQL Server). We always recommend the PSO to be relentless and persistent in this effort and be like pit bull terriers without ever showing their teeth. 2. Next, the PSO takes ownership of all project schedules in the program and integrates the schedules to an Integrated Master schedule (IMS) by running the Create Links feature in CrossLinksPro. 3. The PSO now finds and validates the Program Critical Path. Validation is important because there may be garbage on the Program Critical Path, such as incorrect dependencies, overhead tasks, recurring tasks, or other tasks that normally would not appear on the Program Critical Path or will not be accepted as critical by stakeholders. We use our PathsPro application to identify and understand any gaps or overlaps on the Program Critical Path. Once it is validated and we see the latest slippage, the optimization can start. We typically ask project managers to be on standby during the optimization, because we may need any permutation of them to help us optimize the Program Critical Path to shorten it and reduce the slippage. We may need to identify multiple Critical Paths:  Primary, secondary or tertiary Program Critical Paths: the primary program critical path is the path with the least time buffer (Total Slack), the secondary is the one with the second-least time buffer (Total Slack), etc.  Critical Paths into the next two or three major milestones that are coming up in the next few months. 4. Once the Program Critical Path(s) have been optimized and the reports have been created, the IMS can be dis-integrated to become a set of standalone schedules again. The ownership can now be transferred back to the project managers.

© PROJECTPRO CORP.

PAGE 227

6

Chapter 6 Linking Projects in a Program

Forecasting Programs

5. Handoff milestones and major milestones may have been moved, and the new dates need to be communicated carefully to the involved project teams and program stakeholders. The differences between handoff milestones and major milestones are:  Handoff milestones are milestones only created for modeling handoff dependencies. They are captured in the Handoffs worksheet in Excel that acts as the dashboard for the program manager and as input for CrossLinksPro.  Major milestones are identified by major stakeholders as milestones they want to be reported on regularly. The major milestones are in the Major Milestones worksheet in Excel, where CrossLinksPro can update the latest forecast dates to compare against the original baseline dates.

CrossLinksPro: Advantages and Disadvantages The following advantages and disadvantages are relative to the other options with which you can manage cross-project links (see page 182 where we have outlined them all).

Advantages ◆ Provides program manager an overview of all handoffs and their performance ◆ Allows program manager to identify and optimize the Program Critical Path so they can:  Decide which impacts to accept and which to reject  Check overall impact of slippages on the program  Compensate for slippages that occur  Communicate back to project managers which of their tasks are critical in the program as a whole ◆ Easier to use for project managers because they always work with standalone schedules! ◆ Each sub schedule highlights tasks critical from the program perspective! Our add-in PathsPro will mark them in a Flag field in each project schedule, which is saved and will appear when the project manager opens the schedule. ◆ Cross-project links are well protected and never duplicated accidentally ◆ Significantly lower probability of file corruption with file servers but also in a Project Server environment ◆ Project schedules open fast ◆ Relative to using the Links-between-Projects feature that is native in MS Project, CrossLinksPro only requires a small training investment; there are not many do’s and don’ts for CrossLinksPro. ◆ Project schedules can be stored in an Enterprise Content Management (ECM) system, such as SharePoint Server

PAGE 228

© PROJECTPRO CORP.

Forecasting Programs

Chapter 6 Linking Projects in a Program

Disadvantages ◆ CrossLinksPro needs to be purchased separately ◆ CrossLinksPro takes some time to create and remove the cross-project links; for example, it takes about four minutes to create 500 cross-project links in MPP-files. ◆ Ownership of schedules needs to be organized and coordinated Trap! Note that opening the master schedule in read-write fashion locks all project managers out of their schedule. So, it is important to organize and communicate: Who owns the schedule when? If either the project manager or the Program Support Office (PSO) has read-write access at any point, time sharing needs to be carefully organized and coordinated. Ownership must be handed back and forth between the project managers (who update the project schedules) and the Program Support Office staff (who perform integration, Critical Path analysis and optimization). If we do this on a weekly basis, the PSO often owns the schedules on Monday and Tuesday, the rest of the week the project managers own their schedules.

© PROJECTPRO CORP.

PAGE 229

6

Forecasting Programs

Chapter 7 Sharing Resources

Chapter 7 Sharing Resources

7 Learning Objectives After this chapter, you will: ◆ Realize that each program faces limited resources ◆ Be able to decide whether to use or create a shared resource pool ◆ Be aware of the options you have for creating a shared resource pool and their pro’s and con’s ◆ Perform resource balancing and workload leveling in a program ◆ Know how to configure Project Online for resource sharing ◆ Be aware of the difference between generic and actual resources ◆ Know when to use generic versus actual resources

© PROJECTPRO CORP.

PAGE 231

Chapter 7 Sharing Resources

Forecasting Programs

One Boy is a Whole Boy, Two Boys are Half-a-Boy, Three Boys are No-Boy-at-All! Bob asks Nob, “What is the optimum number of resources you would like to have on your project?” “There is no optimum. There is only the maximum.” “No, really?” Nob responds with fire and conviction, “Yeah, it’s obvious. I want as many as I can get my hands on.” “Oh, really? I always find that people start to get in each other’s way. If you put more than 3 painters in one room, it becomes a mess quickly. You probably heard the old farmers’ saying: One boy is a whole boy, two boys are half-a-boy, three boys are no-boy-at-all! “ Nob sits up now: “Oh no, the more the merrier! I don’t care if people take it easy at work. Give them a break! Some of them have been breaking their backs for our company in the past. Their broken backs deserve a break!” Bob is taken aback: “Wow man, have you always done that? No wonder it’s always so damn difficult to get enough people on my projects.” Nob is unrepentant. “Having a bigger team gives me more status too. Bigger is always better!“

PAGE 232

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Limited Resources Pose Resource Constraints Have you ever been involved in a program where you could spend whatever amount of money you needed to spend? If so, let me know, because I would like to work in such an environment for once in my life. In reality, every program is limited in terms of resources it can access, be they human resources, material resources or financial resources. In one type of program, this is very clear: Emergency relief programs for earthquakes, floods, tsunamis, hurricanes, tornados, forest fires, mud slides, war zones, civic unrest, terror attacks and mass migrations. Médecins sans Frontières (MSF or Doctors without Borders) is an organization active in this line of work, and in a letter of January 2012, Marilyn McHarg, Executive Director, MSF-Canada explained it like this: “In the crisis environment where Doctors without Borders typically responds, there are often more people in need of our medical assistance than we can treat. For those we do reach, we often face the added stress of insufficient resources and capacity to manage everything their treatment might require. This combination means constantly facing our limitations, and with that, constantly confronting the sense that we are falling short.” Most program managers are not facing a reality in which they are constantly falling short. Still, most program managers would acknowledge that if they had more money, they could add another feature to the software or use a more beautiful material in a building; there is never a lack of ideas on what would be the next best thing in programs, in my experience. Most of the time, program management is not an exercise in perfection, but an exercise in ‘good enough’, even in programs where ‘Failure is NOT an option!’ to quote Gene Kranz, NASA Flight Director for the Apollo 13 near-catastrophe. Perhaps, ‘good enough’ needs to be stretched to ‘as perfect as possible given the resources we have’. Tip► In general, programs attempt to move reality closer to the ideal (utopia) while having too few resources. This is why program managers need to load their schedules with resources and model the workloads of resources accurately to explore what the limit on resources means for the overall program schedule. Program managers need a tool that can aggregate workloads and solve any severe over-allocations that appear. In the illustration, © PROJECTPRO CORP.

PAGE 233

7

Chapter 7 Sharing Resources

Forecasting Programs

this is situation C or D, where resources are shared in the project schedules and their total workloads are leveled (otherwise, there is little reason to load resources into the schedules in the first place). When should you add resources and model their workloads and/or costs? When you expect that limited resources will affect your program schedule, you need to add resources and model their workloads. When you expect that limited or delayed funding will affect your program, you need to model cost. Tip► If you want to be efficient at workload modeling, you could decide to focus on the resources you expect to be the bottleneck resources and only model their workloads, leaving all other resources out of the model. It is often easy to recognize which roles are the bottleneck in an organization by simply listening carefully to their project and program managers. For example, when everybody complains about having to wait for legal opinions, the legal department is the bottleneck. When people complain about procurement, the bottleneck is the contracting specialists. The Theory of Constraints and Critical Chain focus on finding the critical resources in projects and programs (see page 65 for more).

In this chapter, we will explore the issues around having limited resources available to the program or having resources available to the program only part-time, because they are shared with external projects or shared with the operations side of the organization.

What is a Shared Resource Pool? A program shared resource pool is a centralized list of resources typically maintained by the Program Support Office (or enterprise project management office – EPMO - or a central IT department). The PSO will add generic resources and actual resources (named resources or individuals) that project managers may need. Project managers can ask the program support staff to add resources, if they cannot find the resources required. The program support staff need the proper access rights to edit the enterprise resource pool. People designated to maintain the enterprise resource pool can access it in Project Online by clicking Resources. You can add a new resource by clicking ribbon Resources and then button New Resource. If this button is not available, you probably do not have the privileges to edit the shared resource pool, which should be kept clean. PAGE 234

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Resource Management in Programs Resource management is a complex subject. There are many aspects to resource management using Project Online or Project Server: ◆ Resource Finding: Finding the right resource for a project or program, which is what headhunters and large consulting firms, like E&Y, Deloitte, PWC, Accenture and McKinsey, often do. ◆ Resource Capacity Planning: Determining the right number of resources by role for the organization in the long term ◆ Resource Demand Management: Staggering the projects in such a way that the demand for resources does not exceed the resource capacity fixed in the medium term. Demand management is the opposite of capacity planning: You will not vary your capacity but instead adjust the demand for resources by staggering the start dates of projects in such a way that you stay within this fixed resource capacity. In other words: You manipulate the demand for resources by scheduling projects carefully. Tip► Capacity planning and demand management are the flip-side of the same coin of keeping workloads within capacity. Whether you should do capacity planning or demand management is imposed by your situation. If you can hire more resources, you must do resource capacity planning. If you cannot hire more resources, you must do demand management. In most cases, organizations do a mix of capacity planning and demand management. ◆ Resource Role Balancing: Determining the ideal composition of the project or program team in terms of number of Full-Time Equivalent people (FTE) in each role. ◆ Resource Allocation: Finding the right resources for all projects and authorizing the project managers to use them ◆ Resource Usage Optimization: Maximizing the workload of resources within their availability in the short term ◆ Resource Workload Leveling: Keeping the workloads within the capacity of the (generic or actual) resources These are just some of the terms and responsibilities that you need to be aware of when venturing into resource management. A Resource manager is a person who owns resources in an organization and can direct them to do what the Resource manager deems necessary and serve as the referee when there is a fight over resources. In our view, the program manager has two main responsibilities from this complete list of responsibilities for resource managers: ◆ Resource Role Balancing: Finding the optimum mix of specialist roles in their program (see next section). For example, it is very important for program managers © PROJECTPRO CORP.

PAGE 235

7

Chapter 7 Sharing Resources

Forecasting Programs

to find out whether they need 3 system analysts, 5 developers and 4 testers or if the right balance is 2 system analysts, 6 developers and 3 testers. Finding the right balance of resources typically leads to the shortest program and the most efficient use of resources. Balancing is an activity that typically takes place first (i.e., early during the planning phase of the program). The program manager must do it proactively and needs resource-loaded detailed schedules for this and generic resources only. ◆ Resource Workload Leveling: Keeping the workloads of the resources leveled during the program execution (see page 206 and following). In practice, this is done mostly reactively during the program execution; you let the over-allocations accumulate for a regular period and then you sort them out. You can also do it pro-actively as we will see later (see page 238). Tip► Program managers share these responsibilities with the resource managers who eventually own the resources; program managers need to collaborate with the resource managers from whom they get their resources. If the resource managers assign their resources on a fulltime basis to the program, the program managers take over the responsibility from the resource manager to direct the day-to-day activities of the resource for as long as the program lasts (or any term agreed upon with the resource manager).

Typically, program managers first need generic resources in their program schedules for role balancing, then actual resources to keep the workloads leveled.

Types of Resources: Generic versus Actual There are two types of resources found in shared resource pools: ◆ Generic resources: Generic resources are roles: A role is a set of related skills to perform a certain function. A program often has a small number of generic resources; we have seldom seen the list of generic resources exceed 50. Generic resources are useful for:  Capacity planning: vary and optimize resource capacity to maximize the benefits  Demand management: stagger projects to respect the fixed resource capacity.  Role balancing: keep workloads evenly spread among the different resource roles in the program ◆ Actual Resources Actual Resources are people of flesh and blood; they are named individuals that contribute in projects. A program often has many actual resources, often in the hundreds, sometimes thousands. Identification of actual resources occurs in a much more refined type of resource management and allows you to look at an individual’s PAGE 236

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

to-do list and aggregated workload across all their projects. Actual resources allow workload management:  Workload leveling: Does every resource have a reasonable workload?  Workload optimizing: Are the resources assigned to the activities they are best at?

Role Balancing: Finding the Optimum Mix of Roles Specialists are often called different names in different industries. For example, they are called: ◆ ‘Trades’ in the construction industry: the carpentry trade, the electricians trade, etc. ◆ ‘Experts’ or ‘Subject Matter Experts’ (SME) in a variety of industries, such as IT, government and research ◆ ‘Roles’ in HR, World Bank, IMF and international development Each industry develops insights into the optimum mix of resources for their projects and programs. These are often determined by heuristics, the critical observation and analysis of practice to determine the inherent rules of the situation and generalize them. For example: ◆ Software development: For software development projects, SEI’s Watts Humphrey has developed a unique way to forecast the quality of the final software from the initial project schedule. 27 He found that the ratio of developers to testers needs to be 2:1. In other words, you need to spend 50% of the effort you spend on coding to test the code; Watson found with fewer testers than that, the quality of the software suffers. ◆ Construction: Building or renovating a family home: The carpenters need to build the wooden frame before electricians have any place to attach their electrical boxes and wires and before plumbers have any place to attach water and sewage pipes. From personal observation, I have found the optimal number of tradespeople for construction or renovation of a family home to be 3 carpenters, 3 electricians, 1 plumber, 1 HVAC installer, 2 drywall installers, 1 trimmer and 2 painters. Each of these trades will spend a different amount of time on the construction site, which makes it more variable, but there are some minima; for instance, carpenters and electricians need to work in pairs to be productive. ◆ Telecommunications: Crews to lay fiber-optic lines in suburban neighborhoods for Internet access: From personal observation in my own neighborhood, I concluded that the following composition of the team is balanced and works well: 1 supervisor, 2 crews of 27

See www.sei.cmu.edu for more information on the Personal Software Process (PSP) and the Team Software Process (TSP) developed by Watts Humphrey © PROJECTPRO CORP.

PAGE 237

7

Chapter 7 Sharing Resources

Forecasting Programs

2 people each operating one drill that pulls underground cables, 2 people installing the fiber-optic boxes from which each home can be hooked up, 1 front-loader tractor operator to fill in holes, plus two assistants with shovels to level them. The optimum mix of specialists in your program team depends on your industry and your specific situation. You will know the mix of specialists on your program team is optimal when: ◆ Each person on your team is equally busy: Nobody is working noticeably harder than other team members, and no person is taking it easy. ◆ No specialty (trade) is slowly getting ahead of other specialists (trades) creating a pile of interim deliverables for other specialists to catch up with. ◆ No specialty becomes the bottleneck slowing everyone else down. ◆ No arguments break out between team members over not making enough progress or delivering poor quality workmanship. The hallmark of a properly-balanced program team is that nobody is croaking under a crushing workload AND nobody is goofing off and taking their workload and responsibilities too lightly. If you do not already know the approximate number of specialists you need on your team in each role, you will need to find out by trial and error. How can you do this? First, load your project schedules with generic resources only, then level the workloads in the program schedule and analyze the delays on the activities to find the most critical resources. Next, develop different scenarios in which you vary the number of people in each role. Then observe the duration of your program schedule for each scenario, and view the workload histograms to see how occupied everyone is, and assess the quality and risk of each scenario. When determining the optimum mix of resources in your program (balancing resources), we can ignore the world outside the program.

Workload Leveling: Keeping the Workloads Reasonable When we share resources with the world outside the program, we need to keep the workloads of our part-time program resources leveled inside as well as outside our program. Resources can be shared between: ◆ All projects within an organization (enterprise resource pool): In this case, there probably is an Enterprise Project Management (EPM) system in which all projects of the entire organization are stored. This organization will likely have an on-premise installation of Project Server (which is often cheapest for large deployments). PAGE 238

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

◆ All projects and programs within a portfolio (line of business, branch, department, division or profit center): In this case, there is probably a Project Portfolio Management(PPM) system installed at the level of this portfolio in the organization. It may not include all projects and programs from the entire organization, only a subset. ◆ The projects in the program: Sharing resources in a program is only important if you expect sharing to cause major delays in your project schedules. If you expect some resources will be in high demand and short supply, modeling workloads across the projects and having a central resource pool aggregate these workloads across the projects will add value, because you can monitor the resource workloads, explore how they affect major milestone accomplishment, and create what-if scenarios to find the optimum resource allocation. Tip► If your program is sharing resources across only its projects and you do not have an EPM or PPM system in place that you can piggy-back on, your best option is to purchase a subscription to Microsoft Project Online (or any similar offering) for the duration of your program. With Project Online you can have a shared resource pool in a matter of minutes at a reasonable cost, and you can terminate your subscription when your program is over. A second-best option would be using the shared resource pool feature in MS Project as a standalone application: ribbon Resource, button Resource Pool, item Share Resources. We have discussed the ins and outs of each option previously (see page 41).

© PROJECTPRO CORP.

PAGE 239

7

Chapter 7 Sharing Resources

Forecasting Programs

Generic and Actual Resource Sharing Situations

Your options for shared resource pools depend on: ◆ Whether you are sharing the resources within your program or also outside ◆ What type of resources you intend to model: Generic Resources or Actual Resources or both You can share both generic AND actual resources, but that is like sharing just actual resources, at least in terms of the amount of data to process. You can see that the amount of data to handle in each situation is dramatically different. Therefore, each situation will require using a different option to address the resource sharing issues adequately.

PAGE 240

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Reactive or Proactive Workload Leveling across Programs? To keep the workloads reasonable in the shared resource pool, you can take one of two diametrically opposed approaches: either let overallocations happen and then resolve them (reactive), or prevent them from being created in the first place (proactive). The key people in a proactive approach would be the project managers; if they always check if a resource is available before assigning it, overallocations will not happen. Resource managers also play a role; they should not allocate a resource to a project if the resource is already fully occupied. Instead, they should hire enough resources (resource capacity planning). Portfolio managers play a role as well; they cannot authorize too many projects and stuff the pipeline and over-allocate resources. We suggest you choose either the reactive or proactive approach to overallocations: ◆ Reactive workload leveling: project managers simply assign actual (non-generic), enterprise resources to the tasks without checking their availability first. As a result, over-allocations will occur, and workloads will need to be checked at regular intervals. This check is typically the responsibility of the project office. A meeting is called in which project managers and resource managers sort out the over-allocations and make decisions regarding which project gets access to the over-allocated resources first. The tasks in the other projects are delayed by entering delays in the task field Leveling delay for the lower-priority projects. This is what most organizations currently do. These organizations need to create a new role of enterprise resource pool analyst, to constantly monitor workloads in the pool and develop solutions when over-allocations occur. This analyst is also the liaison with the HR-department for the long-term resource-capacity-planning. ◆ Proactive workload leveling: project managers always check on availability of the resource before assigning the resource using the Assign Resource dialog. Each project manager can see the total workload of a resource across the entire portfolio in the Resource Usage view in the project they are scheduling. (We discussed how project managers can check availability proactively on page 360 of the book Forecast Scheduling with Microsoft Project 2013). If the resource is available, project managers can assign it. If not, project managers have two choices:  Leave the generic resource on the task and raise an issue if they believe they should be given priority access to the actual resource.  If project managers believe they will not gain priority access to the resource, they can apply leveling delay to the task and find an opening in the workload © PROJECTPRO CORP.

PAGE 241

7

Chapter 7 Sharing Resources

Forecasting Programs

graph of the resource, thus moving the workload into the first window of opportunity in the future. The proactive approach has the following advantages: ◆ Severe over-allocations will never occur and the (often painful) workload leveling meetings are not necessary. There will still be small over-allocations when tasks and their workloads shift during project execution, but painful situations in which four project managers are fighting vigorously for the same resource will not occur. Small over-allocations can typically be ironed out as follows: When one schedule slips and needs the resource later, another schedule can possibly use that resource earlier than originally planned. Real over-allocations only occur if a task takes longer, which will make the other tasks slip. ◆ Project managers are encouraged to load resources in their schedules earlier and further ahead, which is good thing. When a project manager has assigned and claimed a resource for a certain time period, it is hard for other project managers to get the resource released by that project manager. Once all project managers realize this, they start to load actual resources in their schedules as early as possible, thus making capacity problems visible much earlier. The organization benefits because more problems can be dealt with through Human Resource initiatives, such as (re)training and hiring. HR departments typically need a lead time of 2-4 months to adjust to variations in resource demand, and HR can now offer solutions in a timely fashion. If your organization takes the reactive approach to workload leveling in the enterprise, you need to know how to level the workloads across all your schedules as we discussed earlier (see page 238).

What are the Options for Creating Shared Resource Pools? Your options for creating a shared resource pool for your program are listed below. If you do not have an EPM- or PPM-system in place, we recommend the first option most: ◆ Project Online ◆ Project Server ◆ Microsoft Project: You can create a shared resource pool in Microsoft Project as a standalone application, but you cannot share more than 50 resources in it. This maximum is not a technical limit published by Microsoft, but based on our experience, beyond 50 resources, project schedules open too slowly.

PAGE 242

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

In the first chapter, we discussed some ins and outs of using these different shared resource pools (see page 41). Tip► We concluded on those pages that, if a program manager does not currently have access to an on-premise Project Server shared resource pool, the best option is to rent a Project Online shared resource pool in the cloud for the duration of the program. Project Online allows you to perform resource capacity planning or demand management, as well as workload management. Tip► If you cannot find the money to pay for subscription fees for Project Online, you will need a Plan B. Your second-best option is to create a shared resource pool in Microsoft Project as a standalone application. However, if you do this, you can only have a maximum of 50 resources and, therefore, must use generic resources only, which means you will not be able to perform workload management for individuals.

For this reason, we think Project Online is a very viable option for many program managers, and we will discuss this option in more detail in the remainder of this chapter. You may also consider Office 365 to create a central communications and collaboration platform for your program team. Since Office 365 is not much more expensive than Project Online, we recommend you consider this.

Overview Getting Started with Project Online We will now perform the following procedures to configure Project Online and to get our project and program schedules into Project Online: 1. Clarify what type of resources to create: actual resources or generic resources or both (see next section). 2. Determine what generic resources you will need We will provide Standard lists of Generic Resources by Type of Program (see page 244). 3. Create Team Assignment Pools: Basic configuration of Project Online: Create some custom fields for the resources in Project Online: Team Name for which we will need a new lookup table Teams (see page 255). 4. Create the generic resources as Team Assignment Pools using the custom field and lookup table (see page 259). 5. Migrate the project schedules that are part of the program into Project Online (see page 261).

© PROJECTPRO CORP.

PAGE 243

7

Chapter 7 Sharing Resources

Forecasting Programs

6. Create the master schedule for the program in Project Online, and we are ready to analyze and optimize (see page 263).

Step 1. What Resources in the Shared Resource Pool? Resource management is a complex subject. Resource management has many aspects: 28 resource finding, capacity planning, demand management, balancing, allocation, optimizing and leveling are just some of the terms you need to be aware of when venturing into resource management with Project Online or Project Server. Project Online/Server offers different methods to capture resource capacity and demand. The obvious choices available to you are: A) Use Generic Resources Only (see next section) B) Use Actual Resources Only (see page 246) C) Combine Generic and Actual Resources (see page 248) We will then discuss a solution to all problems noted along the way and discuss creating generic resources as Team Assignment Pools (see page 249).

A) Use Generic Resources Only If you are only interested in the allocation of roles or functions, you could populate the resource pool with only generic resources (i.e., resources that are roles, not people of flesh and blood). For roles, you can use generic resource names such as carpenters, programmers or trainers. You can indicate to MS Project that a resource is generic by setting the field Generic to Yes in MS Project or selecting  Generic in PWA when creating new resources. Generic resources are great for capturing future demand for certain roles. A role is a set of related skills needed to perform the role. You will (hopefully) never meet a generic resource in the hallways of your organization, because generic resources are an abstract concept without physical presence, which is why some people jokingly call generic resources ‘zombies’. Other people call them ‘clones’, because of the ease with which you can increase or decrease the number of them in what-if scenarios. In this situation, should your generic resources have 0% Max. Units, or Max. Units set to the number of resources in that role present in your organization?

28

Just look at the Managing Resources course from ProjectPro Corp that outlines those aspects: www.ProjectProCorp.com under Courses, click Overview. PAGE 244

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

The Max. Units in Microsoft Project represent the percentage of time a resource is expected to work on projects. A manager might only work on projects for 40% (i.e., two days a week). A consultant may be full time on projects (Max. Units = 100%). In the situation where you ONLY work with generic resources, we recommend that you set the Max. Units to represent the number of resources you have in a certain role. For instance, if you have 5 carpenters in your company, you set the Max. Units to be 5 (or 500% expressed as a percentage). In the screenshot below, you can see we assigned Carpenters in increasing numbers to their activities, but with 500% Max. Units there is only an over-allocation when the sum exceeds capacity (5 + 2 = 7 carpenters):

The over-allocation happens when two parallel activities generate a sum of carpenters greater than 5.

What happens if you set Max. Units for the generic resource to 0%? You are telling MS Project that the resource doesn’t have any availability to work on projects. Every allocation with a generic resource with 0% will also show a burning man (red man) in the task-related field Indicator to tell you there is an over-allocation, even though there really is no issue; after all, there really are 5 carpenters that can work on the tasks:

© PROJECTPRO CORP.

PAGE 245

7

Chapter 7 Sharing Resources

Forecasting Programs

Project is now only capturing demand, but no capacity, as you can see in the screenshot from Project Online below:

You can see in the chart at the top that the capacity line is at zero. In the bottom table you can see that the capacity numbers are zero as well.

A final problem: using Max. Units = 0 for generic resources makes assigning them hard, because it introduces a 0 (zero) for Units in the formula: Duration * Units = Work. MS Project assigns by default the Max. Units (unless you enter the number of units on an activity), so assigning generic resources becomes much more difficult; once introduced, it is hard to get rid of a zero. We can conclude from this discussion that if you work with generic resources ONLY, you need to ensure that Max. Units represent the number of resources you have available to your project in that role. Tip► If skill level is an issue, you could model this with two generic resources instead

of one, such as Senior Java Programmer and Junior Java Programmer, instead of using actual resource names.

B) Use Actual Resources Only Actual resources are the Tom, Dick and Harry’s, actual people of flesh and blood, not ‘zombies’ or ‘clones’. Actual resources are on a finer level of detail when using them for purposes of resource management. After all, you may have a single generic resource titled ‘Java programmer’, but you may have Mary, Charles, John, Megan and Chase as your Java programmers. As you can see, the amount of data to handle has just exploded PAGE 246

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

by a factor of five when switching from generic resources to actual resources. Actual resources are needed when you want to model workloads on an individual-by-individual basis, or if you want to create to-do lists for individuals. Actual resources are the default type, so you just need to enter their Resource Name in MS Project. If you use Project Online / Project Server, make sure you retrieve the actual resources from the shared resource pool (ribbon Resource, button Add Resources, item Build Team from Enterprise). Using actual resources gives you get a better understanding of over/under-utilization of individuals. For instance, Mary may be the favorite Java Programmer, but if you didn’t have Mary as an actual resource in the schedules, you would not know she is constantly overallocated. Some other resources may be flying under the radar, while as a group their workload looks healthy. Another upside is that you can specify hourly rates more accurately with actual resources. Mary might be a senior programmer while Chase might be junior. You can see the aggregated workloads for the team in the next stacked-bar chart, where each color represents the workload for one person on the team:

The problem with actual resources ONLY is that they make long-term planning of capacity hard. It’s very difficult to plan all work for a two-year timeframe and capture all demand at the start of those two years. How can you assign actual resources many © PROJECTPRO CORP.

PAGE 247

7

Chapter 7 Sharing Resources

Forecasting Programs

months ahead when you do not know if they will still be around or still working in their current role? There is too much re-work in scheduling with actual resources only. In conclusion: Working with actual resources only makes it hard to capture demand and capacity for the longer term. You will probably NOT be able to get a clear allocation and thereby capacity planning for the longer term.

C) Combine Generic and Actual Resources After considering the dilemma with actual resources ONLY, we can look at a solution where we enter both actual and generic resources into our shared resource pool. As we will see, there’s a downside to this as well. When we had generic resources only, we concluded that we need to set the Max. Units of generic resources to the number of resources working in that role. However, a generic resource called Java programmers with Max. Units equals 5 as a decimal (or 500% as a percentage) artificially doubles the resource capacity for that role, because Mary, Charles, John, Megan and Chase are also in the resource pool as actual resources, so Project Online / Project Server ‘sees’ a total of eight people in the capacity of Java programmers and ‘thinks’ there is double the actual resource capacity:

Obviously, this wrecks our capacity planning and demand management; the capacity line is twice as high as it should be: (5 actual resources + 5 generic resources) * 176 hours/month = 1760 hours, which should have been 880 hours.

PAGE 248

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

There is a fourth, better option that we recommend when you combine actual and generic resources in your shared resource pool. We need to talk about a little-known feature in Project Online / Project Server called Team Assignment Pool.

Team Assignment Pool Resources Tip► The beautiful thing about Team Assignment Pool resources is that their capacity is set to zero by default. Creating team assignment pool resources in Project Online / Project Server requires two steps: Create the team resources first, then associate them with the generic resources:

1. Create team resources: a. Create a Team lookup table (in PWA, click Server Settings, item Enterprise Custom Fields) and create items in the lookup table for each role (generic resource) you will need. b. Link that new lookup table to the Team field that comes standard with Project Online / Project Server. 2. Create generic resources and associate them with their team: a. Create corresponding generic resources for all roles (in the lookup table). b. For each generic resource you create, select the checkbox  Team Assignment Pool and select its corresponding Team Name (the lookup table presents itself in this pick list). You should set the Team Name correctly for every generic resource that you associate with a specific team (role). The next screenshot shows this section in the new resource screen for ‘developers’:

3. For actual resources, you keep the checkbox clear:  Team Assignment Pool! Tip► Generic resources marked as a Team Assignment Pool do NOT have any

capacity of themselves (not 0%, not 400%), which is hard-coded into Project Online / Project Server. Additionally, when you assign Team Assignment Pool resources to activities, you can enter the number of units, so you can assign, say, 5 carpenters to the activity Frame the walls.

© PROJECTPRO CORP.

PAGE 249

7

Chapter 7 Sharing Resources

Forecasting Programs

This means that you will see a clean capacity overview of all resources with a correct representation of the capacity of all resources. Two advantages make this solution superior to all other options we reviewed: ◆ You can easily assign the exact number of generic resources to the activities. ◆ You get an accurate capacity overview when all resources are in a report, such as in the next screenshot. This report only contains generic resources (Team Assignment Pools), and their capacity line is at 0 FTEs (full-time equivalent resources, a.k.a. ‘heads’):

PAGE 250

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Tip► Best of all, you can now capture demand early, because you can use the team-assignment-pool generic-resources for the long term until you replace them with actual resources of flesh-and-blood. We’ve observed that organizations finalize assigning actual resources only in the short term, typically for the next one or two months, as illustrated:

7

Tip► We recommend you promise all your employees that you will not change their

assignments in the next two weeks, so they can plan their personal lives with their families and friends and honor their commitments (See Frozen Assignments). In the 1-2 month look-ahead window, you need to have actual resources assigned and communicate these assignments to the resources. In the 2-4 (or 3-6) month look-ahead window, there should only be Generic resources (as Team Assignment Pools) in the schedules. As time goes by, those assignments will move into the 1-2 months look-ahead window, and the generic resources should then be replaced by actual resources. In the 4-6 months look-ahead window, you should start defining the detailed activities in authorized projects. Beyond 6 months, this planning is likely too difficult, and you may only know the deliverables to create, which can often be copied from the project charter or scope statement. This process of progressive elaboration over time is also known as Rolling Wave planning, a great way to plan at the right time: Not too soon and not too late either.

© PROJECTPRO CORP.

PAGE 251

Chapter 7 Sharing Resources

Forecasting Programs

Step 2. Determine What Generic Resources You Will Need Based on our experience capturing generic resources for several different industries, the next lists are close to complete, and we rarely add or delete more than a few line items from the following lists. (Where we provide more than one item per line, you need to choose the label commonly used in your organization). Tip► We recommend using the following terminology: ◆ Lower case names for generic resources, so they stand out from the capitalized names of individuals, the actual resources. ◆ Use ‘managers’ rather than ‘management’ and ‘administrators’ rather than ‘administration’; in other words, we prefer the plural noun for the group of people rather than the singular, general reference for the role, because a generic resource refers to a group of people working in a role. Plural also makes them stand out from individuals. ◆ The plural form of the noun to indicate more than one person can be in the role. Here are lists of generic resources we have assembled over the years: Software development: project managers, PM, schedulers, MSP, P3, P6 managers, executive, management, CIO, CFO, CEO, COO, architects analysts, BA, SA programmers, coders, developers, JAVA, C+, C++, C#, COBOL, VB, PHP, PERL, admins, administrators, SQL, ORACLE, DB testers, inspectors, quality, QA, QR, QC users, clients, teams, prime, FTE trainers, educators, facilitators, communicators, participants, students, scholars, implementers, implementation, installers, installation, deployers, deployment, clients, users, resources, teams, SME, stakeholders, officers, safety, security, vendors, suppliers, consultants, specialists, SME, employees, departments, third-parties, 3rd parties, administrators, administration, human resources, HR,

PAGE 252

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Legal project managers, PM, managers, executives, management, CIO, CFO, CEO, COO, lawyers, legal, paralegals, barristers, notaries, mediators, mediation, arbitrators, arbitration, facilitators, facilitation, Marketing project managers, PM, managers, executives, management, CIO, CFO, CEO, COO, marketers, marketing, sales, sales representatives, CRM, representatives, agents, supporters, public relations officers, public relations, PR, publicity, designers, creative,

7

Financial project managers, PM, managers, executives, management, CIO, CFO, CEO, COO, banks, lenders, budgets, finance, human resource officers, human resources, HR, IPO, Publishing project managers, PM, writers, authors, columnists, bloggers, journalists, vloggers, designers, reviewers, editors, publishers, printers, Construction project managers, PM, schedulers, MSP, P3, P6 owners © PROJECTPRO CORP.

PAGE 253

Chapter 7 Sharing Resources

Forecasting Programs

contractors, design-build, builders, carpenters, masons, electricians, plumbers, metal sheet workers, HVAC, installers, roofers, landscapers, painters, grinders, cutters, scaffolders, joiners, fitters, welders, ironworkers, labourers, operators, cleaners, maid service, agents, representatives, realtors, movers, supervisors, telephone installers, telephone, fax, cable, telecommunications, audio-visual installers, audio-visual, AV, Emergency Relief project managers, PM, warehouse managers, storage supervisors, logisticians, logistics, distributors, distribution, rescuers, searchers, firefighters, police officers, police, security officers, security doctors, physicians, paramedics, nurses, Just copy the appropriate list of generic resources from the previous lists and remove any duplicate labels, picking the label most commonly used in your organization.

PAGE 254

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Step 3. Create Team Assignment Pools As we saw in the section on What Resources to Create… (see page 244), we first need to create the list of team assignment pools before we can populate them with resources: 1. We need the menu item Server Settings to create the list of team assignment pools, which is not visible in the out-of-the-box Project Online. Make this menu item visible by clicking in the menu on the left: The Modify Quick Launch Items screen appears:

7

2. Select all menu items / quick launch items you would like to see, making sure you select Server Settings. Click button Save & Close when done.

© PROJECTPRO CORP.

PAGE 255

Chapter 7 Sharing Resources

Forecasting Programs

3. Click Server Settings and the PWA Settings screen appears:

PAGE 256

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

4. Under Enterprise Data, click item Enterprise Custom Fields and Lookup Tables and the same-named screen appears:

7

5. In the middle of the screen, click button New Lookup Table and call the table Teams. You would enter the generic resource roles in this lookup table for your own program, but, if you would like to work with our exercise files, create the following items under section Lookup table in the column Value: project managers system analysts system architects developers testers roll-out managers program managers 6. Click Save and the Enterprise Custom Fields and Lookup Tables screen reappears.

© PROJECTPRO CORP.

PAGE 257

Chapter 7 Sharing Resources

Forecasting Programs

7. Now, we need to associate the out-of-the-box field Team Name with the lookup table we just created: Click the hyperlink Team Name and the next screen appears:

This is where you associate the new lookup table Teams with the standard Team Name field. Mark this field also to be used for role-based scheduling since all roles you need are in the list.

8. Under  Lookup Table select Teams. Select  Use this field for matching resources; it contains all the roles in our program, so we can use this field for both team assignment pools and for roles (sets of skills for role-based scheduling). We have completed the basic resource configuration in Project Online and are ready to create generic resources we will need in our program.

PAGE 258

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Step 4. Create Generic Resources in Program Resource Pool 1. In Project Online, in the side menu on the left, click Resources and the following screen appears:

7

2. Since we will only use generic resources, there is no Active Directory group to synchronize with, so we must enter the resources manually and individually. Click the Resources tab and its ribbon appears, click button New and the New Resource

© PROJECTPRO CORP.

PAGE 259

Chapter 7 Sharing Resources

Forecasting Programs

screen appears:

Select this checkbox for Generic Resources.

3. Select  Generic, which will make the  Associate resource with a user account disappear because generic resources will not be logging into Project Online … that would be eerie! 4. As we have seen in the section on What Resources to Create… (see page 244), it is important to mark all these generic resources as Team Assignment Pools; under Team Details select the option  Team Assignment Pool for each generic resource you create, and in the list Team Name select the corresponding team.

PAGE 260

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Exercise: Create the Generic Resources for the Program Using the previous procedure, create the following generic resources for the program as  Generic resources and as  Team Assignment Pool resources: Resource Name project managers system analysts system architects developers testers roll-out managers program managers

Max. Units

Standard Rate

Overtime Rate

100% 100% 100% 100% 100% 100% 100%

$250/hr $150/hr $180/hr $120/hr $120/hr $180/hr $300/hr

$375/h $225/h $270/h $180/h $180/h $270/h $450/h

Step 5. Migrate the Project Schedules to Project Online To migrate schedules created in Microsoft Project as a standalone application into Project Online (or Project Server), we typically take the following preparation and migration steps. There are more steps than you might expect, because the custom fields and resources need to be matched with the fields and resources in Project Online. Preparation steps: 1. Explore custom fields (Display Custom Fields dialog and arrow through the Type list). 2. You may have custom fields in the project file: Which of these fields have data that you need to import? 3. Do matching fields exist for these in Project Online / Project Server? a. If yes, migrate the following data, noting that, for programs, you may need to migrate the data in the custom fields (if you use our methodology): Major Milestones Handoffs Schedule b. If no, should you create a new enterprise field in Project Online / Project Server or remove the data (i.e., not migrate the data)? Original Unique ID (because it has a formula in Enterprise as well) 4. Do matching views and calendars exist in Project Online / Project Server? If not, re-create them. © PROJECTPRO CORP.

PAGE 261

7

Chapter 7 Sharing Resources

Forecasting Programs

Migration steps: 1. Detach the MPP-file shared resource pool, if any, click ribbon Resource, button Resource Pool, item Share Resources; the dialog Share Resources appears, select the option:  Use own resources 2. Remove any funny characters from the filename and from the Title field (Click ribbon File, item Info, list button Project Information, item Advanced Properties, tab Summary). Characters to remove include long dashes, commas and colons. You can keep only regular dashes! 3. Explore views, tables, filters, calendars: Do enterprise substitutes exist? If no, re-create the objects in the Enterprise Global (in PWA, go to Server Settings). If yes, delete them. To delete objects: a. Switch to an enterprise view, like Enterprise Gantt, to avoid being unable to remove an item when it is (part of) the active view. b. Delete by clicking ribbon File, item Info, item Organizer, button Organizer: Remove the following including Modules and  Resource-related Filters, Tables and Groups): …………………………………………………………………. ……………………………………………………………………………………………… 4. Modify the resource names in the project to match exactly the names of the resources in the shared resource pool. Make the generic resource names plural where needed (lowercasing will happen automatically!). 5. Clean up project-level info: click ribbon File, item Info, list button Project Information, item Advanced: wipe out all entries in the following fields if data are not needed any longer: Tab Summary: Fields: Title, Subject, Author, Manager, Company, Category, Keywords, Comments 6. Save the file (still as MPP-file), so if the file needs to be imported again for whatever reason, you do not need to repeat all these preparatory steps. 7. Save to Project Online: a. Click File, item Save As to Project Online using the  Import Wizard and click button Save. b. Respond to the prompts in all steps of the import wizard displayed in the left side pane. c. Click File, item Info, button Publish to make the project visible in the Project Center in Project Online / Project Server.

PAGE 262

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

Step 6. Create the Master Schedule for the Program We have discussed this previously (see page 157).

Sharing Resources Inside versus Outside the Program When resources are shared only inside the program, the program manager can decide which projects get the best resources or get resources first. Tip► The program manager will most likely have the best resources work on activities that are on or near the Program Critical Path. When resources are shared outside the program, the program manager’s challenge to manage workloads becomes much more difficult. The program manager will need a ranking of all projects and programs, including his or her own, that are sharing resources. Only when there is a ranking of projects/programs can resource conflicts be resolved in a manner that best supports accomplishing the corporate strategy. The guiding principle will or should be: The best resources work first on the highest-ranked projects/programs!

Sharing Resources with Projects Outside your Program There are two possible situations: ◆ A corporate-wide ranking of projects and programs does exist Tip► In this case, the fight for the scarce resources can be resolved cleanly; the higher-ranked project or program gets the resources first. ◆ A corporate-wide ranking of projects and programs does NOT exist This is the most-challenging situation. Many organizations have multiple portfolios, typically one in each business line (revenue/profit center). Often portfolio managers have ranked the projects within their portfolio, but not across all portfolios, which leaves program managers the tricky task of figuring out how to get and keep resources in their program. For example, large telecommunications firm we consulted with had four portfolios, and each portfolio manager had ranked his or her own projects and programs, but neither the four portfolio managers nor the executives had ranked the projects corporation-wide. We were engaged by the manager of the Enterprise Project Management Office (EPMO). With regret, he admitted he could not get the portfolio managers or executives to rank all projects across the entire enterprise. We suggested he approach a corporate-wide ranking by looking at the revenue stream of each business line and using that as the weighting factor for all intra-portfolio rankings of all projects/programs to arrive at a © PROJECTPRO CORP.

PAGE 263

7

Chapter 7 Sharing Resources

Forecasting Programs

corporate-wide ranking. After all, the more revenue a business line brings in, the more important that business line is for the survival of the corporation as a whole, making this a defendable way to achieve a corporate-wide ranking of projects. Of course, this strategy still may not work in one of the following situations: ◆ If one of the portfolio managers does not have a ranking of projects and programs, even this fallback plan is not possible. Executives may be able to help and may get all portfolio managers to rank their projects/programs. ◆ If one of the revenue streams is dramatically higher than the rest, only the projects from that business line will be authorized. In this case, you need to make some adjustments to the weights of the revenue streams. ◆ If your organization is a government department or semi-government agency, there will be no revenue streams. In this case, all projects/programs could be scored on their ‘benefit to society’ by a carefully selected group of decision-makers. The benefit to society will become the weight of each business line (branch?) within that department.

Large Delays When You Level One Enterprise Schedule Notice that when you level the workloads of a single schedule retrieved from Project Online / Project Server, MS Project assumes that the workloads coming from other schedules cannot be moved (delayed), and the workloads will be treated as a constraint that this schedule must work around. The leveling algorithm looks at the earliest possible places where it can fit in the workloads of all resources needed in this project, based on where the other projects left some availability. In the illustration, you can see that My Project almost doubled in duration when MS Project leveled the workload of Harry, Tom and Di in My Project, illustrating there is little value in leveling the workloads of a single schedule opened from Project Online / Project Server (a.k.a. an ‘enterprise schedule’). Trap! You will often find huge delays if you completely level a single enterprise schedule by itself. Project managers who experience these huge delays for their schedule should raise an issue to make resource managers in a matrix organization aware of by how much they will miss their deadline if the resource manager does nothing about the over-allocation. After all, the project manager is responsible for getting their project

PAGE 264

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

done on time … with or without the right resources. Accomplishing fixed deadlines is a lot easier with the right resources. We recommend that you clear the leveling after you have seen how far your project is delayed. There is little gain in trying to level the workloads in one enterprise schedule by itself. If other project managers do the same thing in their schedule, they will also be raising issues. Project managers who try to resolve the overallocations among themselves will go after each other, and if they succeed, will establish the de facto ranking of the enterprise projects, which is not in their mandate. We recommend that the portfolio managers supported by the enterprise project management office (EPMO) get involved and start leveling the workloads in all projects that intensely share resources while taking the project ranking into account. The project portfolio managers have done their jobs, they should have determined the ranking of each authorized project and published their project ranking to the resource managers and project managers. If portfolio managers do this, they may find that the project managers will stop fighting with each other and with resource managers; project managers may also renegotiate deadlines if they find they cannot get the right resources and can prove this with their schedule. Tip ► If you search for the Resource-Critical Path after leveling, you will find that it switches back and forth between the enterprise schedules that use the most critical resources, which can be seen in the previous illustration.

© PROJECTPRO CORP.

PAGE 265

7

Chapter 7 Sharing Resources

Forecasting Programs

Have MS Project Level Workloads of Shared Resources Tip ► To optimize the scheduling of the tasks and associated workloads in all schedules, you must level the workloads of most (if not all) projects that are sharing resources at the same time. You can even assign Priority numbers to the projects to make sure that the high-priority projects are delayed the least and have MS Project take these priorities into account. These priority numbers should come from the portfolio managers and match their rank. The art in enterprise leveling is to identify the schedules that share the greatest number of critical resources (i.e., the ones in highest demand and/or least supply). For instance, if you want to level the workloads of the IT-resources only, you may be able to focus on just the IT-projects. It is hard to know which projects are really sharing resources. However, if there are over-allocations left at the last step of the next procedure, you will know that you have overlooked certain projects. You may have to repeat this procedure a few times. The procedure works as follows: Open the schedules that compete for the same resources, merge them into one temporary master schedule, assign a Priority to each project, and level the workloads based on the priority numbers. You could even develop what-if scenarios using project priorities and extra resources. We recommend that portfolio managers and resource managers collaborate on finding an optimal scenario. Trap! You can merge almost 1,000 (actually 998) schedules into one master schedule. Make sure you use a powerful computer for the leveling, which requires major number crunching. We also recommend a computer with the 64-bit versions of all software applications installed, which are better at major number crunching. Here are the steps for leveling the workloads of shared resources: 1.

Tip ► Use the Project Center in PWA to open the files quickly, and insert them all into a master schedule needed for the leveling operation. You can do this by selecting multiple projects: Select randomly from the projects listed by clicking the first one desired and holding down the key and clicking on each next project to include OR Select contiguously by clicking on the first project desired and, while holding down the key, clicking on the last project desired. Then click ribbon Projects, button Open, item In Microsoft Project for Editing. All schedules you selected will appear as projects in one new, large, master schedule. OR

PAGE 266

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

In MS Project, open all projects across which you want to level the workloads. Then create a temporary master schedule from these schedules by clicking ribbon View, button New Window and the New Window dialog appears. Select the files to merge by clicking on the first one and holding down the key before clicking on the last one or using the to select singular files: Select all schedules to include into the temporary master schedule.

7 2. Click OK; the schedules are now merged into a new master project. You don’t need to save it; you just use it temporarily to get the workloads leveled. 3. Check if you excluded the projects that you don’t want to incorporate in the leveling. If you find any, delete them from the master schedule (which does not affect the files in your file system or your schedules in Project Server). Select them and press

on your keyboard.

4. The workload leveling needs to be performed based on the ranking of the projects as published by the portfolio managers. To set the priorities for each project: Insert the field Priority in the Gantt Chart view in the master schedule and enter the priorities for each project, i.e. the line items with in the Indicators column. OR Switch to each project (already open) and click ribbon Project, button Project Information and enter a number in the Priority field: Enter a number between 0 and 1000; the higher the number, the higher the priority. The higher the priority, the more the schedule will stay the same. If you enter priority 1000, you are telling MS Project to keep the schedule as it is. The lower the priority, the more tasks will be delayed and the more the schedule extends. Click OK to close the Project Information dialog. Repeat this step to set the priority for each project.

© PROJECTPRO CORP.

PAGE 267

Chapter 7 Sharing Resources

Forecasting Programs

5. You can save the schedules and their new priority numbers at this point if you may need to do this again soon. 6. Click ribbon Resource, button Leveling Options; the Resource Leveling dialog appears. 7. Select the following settings for the leveling: 29 Tip ► Make sure you use the Leveling Order called Priority, Standard to have MS Project incorporate the project priorities as the most important factor while leveling. Trap! Note that MS Project will not level the workloads of Proposed resources unless you select the leveling option  Level Resource with the proposed booking type. If this option is not selected, MS Project will only level the workloads of Committed resources (check the assignment-related field Booking Type in either Resource Usage or Task Usage view). 8. Click button Level All, which will start the automatic leveling process. The leveling is performed only once and not performed continuously ( Trap! This happens if you select  Automatic Leveling, which we certainly do not recommend in such a large master schedule). 9. Check if there are any over-allocations left. See the next section for possible explanations. If none of these reasons apply and you still see over-allocations, you likely forgot to include some projects that are also sharing resources. If that happened, start this procedure over again and include these projects in the leveling process.

When there are Over-Allocations Left… MS Project cannot resolve the following over-allocations: ◆ Some over-allocations may be left, because you did not include all the project schedules that are sharing resources. Open them up and repeat the previous procedure. ◆ You assigned somebody at more than 100% of a task, the maximum units value for a full-time resource. If you exceed the maximum, MS Project will have to skip this assignment during the leveling process. Similarly, if the maximum units are 50%, and you assigned the resource at 80% to a task. MS Project cannot solve these overallocations. You must solve them yourself as the project manager.

29

See page 467 in the book Forecast Scheduling with Microsoft Project 2013 for an explanation of each option in this dialog. PAGE 268

© PROJECTPRO CORP.

Forecasting Programs

Chapter 7 Sharing Resources

◆ The schedule has hard constraint dates (i.e., No-Later-Than and Must-constraints) that do not allow MS Project to delay tasks beyond those hard dates when leveling the workloads. This is one of the reasons we recommend you limit the use of constraints to where you absolutely need them to create a valid schedule, particularly the hard constraints that can create schedule conflicts and limit the ability of MS Project to resolve all over-allocations. ◆ You assigned a resource to a summary task and to its detail tasks at such percentages that it creates an over-allocation (i.e., the sum is greater than 100% or greater than the maximum units). If you allowed yourself to assign resources to summary tasks, you will likely find that you have sometimes assigned the same resource to a summary task and its own detail task, which causes an over-allocation that MS Project cannot resolve. Or you may have assigned the resource to a summary task and to one of its higher-level summary tasks, which creates a similar inherent over-allocation. This is why we recommend that you only assign resources to detail tasks. If you level the workloads in your program automatically by MS Project, you will have to identify the Resource-Critical Path in your schedule rather than the Critical Path. We already defined a Resource-Critical Path (see page 62), and more information on Resource-Critical Paths in project schedules can be found in my Forecast Scheduling books. A White Paper on this topic titled Critical Path 2.0 is available on our website. 30 We will explain how to find the Resource-Critical Path in an Integrated Master Schedule (IMS) in the next chapter (see page 271).

30

See: www.ProjectProCorp.com under Articles, item White Papers.

© PROJECTPRO CORP.

PAGE 269

7

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

Chapter 8 Optimizing the Integrated Master Schedule

8 Learning Objectives After this chapter, you will: ◆ Realize the difficulty of displaying the Program Critical Path in a large program schedule ◆ Know when you can consider the program to be ‘in control’ ◆ Know how to analyze large schedules manually one major milestone at a time ◆ Be familiar with sequestering the subnetwork for a major milestone to find its Critical Path ◆ Be aware of automated solutions to find the Program Critical Path ◆ Track the impact of changes you make in a large program schedule ◆ Know how to create and compare what-if scenarios in a program schedule

© PROJECTPRO CORP.

PAGE 271

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

Round Bales versus Rectangular Doors Bob passes by Nob’s cubicle and sees him focused on one of two large LCD-screens he uses. “Hey Nob, what are you staring at?” “I’m trying to shorten my program Critical Path!” “Still haven’t found enough time in your schedule?” “No,” says Nob, “it’s like fitting a square peg into a round hole! I’d like to add resources but with the hiring freeze, that’s a no go. My current resources can’t work more overtime than they already do.” “Let me have look.” “See, the path runs through development and testing. I currently have 6 developers but only 2 testers, and they are slowing everything down. I wanted to hire another tester.” “Developers can also do testing. Have you thought of rebalancing your team by switching one developer to testing?” “No, I hadn’t. Let’s try that out. Good thing I only have generic resources in my schedule. I just need to adjust the Max Units for the developers and testers. All right, let’s run the automatic leveling again and see where that gets us.” Nob’s mood brightens. ”Look, that did the trick! You’ve made me a happy man! Square pegs do fit into round holes after all!”

PAGE 272

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

Are You in a Portfolio or an Integrated Program Schedule? We have found that people who insert subprojects into a master project may be in either a portfolio or a program. The first thing you need to do is find out which one you are in. Portfolio of Projects and Programs: ◆ Multiple independent projects and programs (i.e., the projects / programs have no or very few dependencies between them) ◆ Multiple Critical Paths: One in each project / program in the portfolio: You can display them all by switching an option: click ribbon File, button Options, tab Advanced,  Calculate multiple Critical Paths. Program with projects (Integrated Master Schedule (IMS) or Integrated Program Schedule) ◆ Multiple dependent projects (i.e., projects that should have many cross-project links between them) ◆ One Program Critical Path with one milestone that is most challenging We will not discuss optimizing portfolios any further; for that, you need to buy a different textbook.

8

Critical Path or Resource-Critical Path in Your Program? We discussed this illustration before (see page 112). Here we will discuss situation B: Having a master project with subprojects (program with projects) and no resources loaded into the schedule; you need to find the Critical Path in your program. Later, we will discuss loading resources into your program (see page 287); that is when you need to identify the Resource-Critical Path in your program rather than your traditional Critical Path.

© PROJECTPRO CORP.

PAGE 273

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

Critical Path in a Project Program Critical Path Trap! In our experience, many program managers mistakenly believe that the sum of the Critical Paths in the projects equals the Critical Path in the program. Thus, they believe if they ask their project managers to optimize the Critical Paths as seen in their project schedules, the program is optimized as well. This is NOT true as you can see in the next illustration:

In the illustration, the Critical Paths in projects A, B and C have white bars. Each project has a Critical Path that leads into the finish milestone of the project, which is not necessarily critical from a program point of view. Instead, the Program Critical Path can run through any of the integration points with other schedules and any of the handoff deliverables. You can see the Program Critical Path runs via other activities (darkest color in the illustration) than the Critical Paths in the projects, and they only come together in the program finish milestone. Tip► As you can see, the only way to find the Program Critical Path is in the Integrated Master Schedule (IMS).

PAGE 274

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

Can You Display a Complete Critical Path in a Program? If you have a truly integrated program schedule with a series of projects that are all dependent upon one another, there should be only one Critical Path. All paths should come together in the program finish milestone. As shown in the next screenshot, it is almost impossible to display the complete Critical Path in a Program Schedule; only a few critical tasks typically fit inside your screen:

8

Often between 10% and 20% of the tasks in a schedule are critical, so the Critical Path in a large schedule of 10,000 tasks can easily comprise 1,000 or more tasks. A thousand tasks are too many to make sense of within the narrow confines of a computer screen, so we must change the way we analyze the Critical Path in a large schedule. We propose that, as a program manager, you focus on the first few major milestones, find the Critical Path into those milestones, and optimize it in such a way that you will meet the promised dates on those milestones, with a time buffer on each deadline. Furthermore, you should make sure that the rest of the program schedule is an entirely dynamic model of the program, so the program schedule will also tell you if the entire program will finish on time.

© PROJECTPRO CORP.

PAGE 275

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

Tip► If a program manager always has firm control over the achievement of the next few milestones and has reliable feedback on when the entire program will finish, he or she is in control of the entire program (see page 122 for a detailed discussion).

Focus on One Major Milestone at a Time Large program schedules should have at least ten major milestones or gates with contractually agreed upon delivery dates. In construction programs, these major milestones will normally have penalties associated for missing the contractual deadline date. In any type of program, we recommend that you always focus on the next major milestone to achieve, and that you find and optimize its Critical Path. In a 10,000-task program, you have on average 1,000 tasks per major milestone, of which 10% typically are critical (about 100 tasks). Therefore, if you focus on the major milestones, you will only have to deal with about 100 tasks on the Critical Path, which is manageable. Here are some ways people have tried to find the Critical Path on a major milestone: ◆ Manually find the Critical Path on a major milestone by looking at the amount of Total Slack of its predecessors and identifying the tasks that have the same or smaller (or more negative) amount of Total Slack; that predecessor is driving this gate milestone. Even though this method seems simple at first, it is a lot of work, for two reasons:  The Total Slack number can change several times on the Critical Path (when there are constraint dates, task or resource calendars, elapsed durations or lags, or one of the other seven things that can fragment a Critical Path, see my Forecast Scheduling books 31).  The Total Slack number displayed on a major milestone may not be driven by its own target date, its deadline, or its date constraint. The Total Slack number, in fact, can be driven by any deadline or date constraint further downstream (later) in the entire program (see next section) that is harder to meet (i.e., that puts more backward pressure on the network). ◆ Automate tracing the Critical Path in the integrated master schedule using the Visual Basic for Applications (VBA) macro programming language. However, in MS Project, it is very difficult to have a macro trace a path across projects. 31

In these books in chapter 9, I provide a list of seven factors that can fragment the Critical Path that MS Project displays and discuss them in more detail. PAGE 276

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

At ProjectPro, we took a long time to develop a VB.NET application, called PathsPro, that can find the Critical Path across projects (see page 224 for more information about this add-in). To determine the best way to find the Critical Path, we need to answer the question: Can we manually find the Critical Path into the next major milestone without the help of any third-party tools? We will approach the issue from a different angle, which will take a few pages to discuss.

Manual Technique to Find the Critical Path to a Milestone This technique requires you to understand how Total Slack numbers are calculated in a large IMS, so we will delve into that topic first. Why is it that the Total Slack on any given major milestone may not be driven by its own Deadline or Constraint Date in MS Project? Let’s look at the next illustration and ask ourselves: Does Deadline Y or Z Determine Total Slack on Task X? The Total Slack number on any given milestone is determined by the most challenging deadline in the program schedule further downstream, not just the deadline or constraint date of that milestone. In the situation above, the most challenging deadline is the deadline on milestone Z, which is missed by 30 days: So, what will MS Project display as the Total Slack on activity X and milestone Y? Why? …………………………………………………………………………………………… ……………………………………………………………………………………………

© PROJECTPRO CORP.

PAGE 277

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

Technique: Sequestering the Subnet In the previous illustration, we saw that the Total Slack on milestone Y and on activity X was -30 days for both. It was driven by the most challenging deadline on milestone Z (-30 days), as shown in the next illustration, rather than the -10 days on milestone Y: Because the Total Slack numbers may or may not be driven by challenging Deadlines or Constraint Dates further downstream in the schedule, the field Total Slack is not useful by itself for manual Critical Path analysis, UNLESS we force the deadline of that major milestone to become the most challenging deadline. To do this, change the Deadline date on the milestone Y to one year earlier than what it is currently; for instance, if it is now May 8, 2019, you change it to May 8, 2018. What happens to the Total Slack numbers on all three major milestones if we arbitrarily and temporarily move the deadline date on major milestone Y to one year earlier? Why? Total Slack on X will be: ……. because: ……………..………………………………… Total Slack on Y will be: ……. because: ……………..………………………………… Total Slack on Z will be: ……. because: ……………..………………………………… In this test, the Total Slack numbers are recalculated and turn to large negatives for all activities and milestones upstream from the adjusted milestone (X and Y), its Critical Path. Downstream from milestone (Z), the Total Slack numbers stay the same. The deadline should be set in such a way that the Total Slack numbers are by far the lowest in the entire schedule; if this is not the case, make the deadline date another year earlier than what it is. The critical tasks on the major milestone will then have the lowest Total Slack numbers, which can easily be filtered out, displayed and subsequently optimized. By adjusting the Total Slack number that you filter on, you can see: ◆ All tasks that drive the major milestone (the subnet) ◆ All near-critical tasks ◆ The critical tasks only We call this technique of making a deadline dramatically earlier sequestering the subnet 32 , because it isolates the entire subnetwork of dependencies from the overall 32

This technique was developed by the author Eric Uyttewaal, PMP from ProjectPro.

PAGE 278

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

network logic of the entire program. This isolated network can be recognized by looking at the Total Slack numbers.

Sequestered Subnet This illustration shows the new situation. After we sequester the subnet of major milestone Y, three paths lead into it: Path A: the tasks have -260d of Total Slack Total Slack Path B: the tasks have -180d of Total A -260d Slack B Path C: the tasks have -240d of Total -180d Slack C -240d We must find which of these paths needs our attention first: Path A, B or C? Major Milestone Y First, we need to realize that Total Slack is expressed in business days; if the Total Slack = -260 days, it means the deadline will be missed by 260 business days (i.e., more than a calendar year!). Questions: 1. Which one path (A, B or C) is the Most-Critical Path that needs to be optimized first to accomplish the milestone on time? Why? ………………………………………………………………………………………… 2. If we sequestered the subnet by pulling the deadline date on the major milestone back by one year (assume that one year = 250 business days), by how many business days would we have to optimize this Critical Path to achieve the major milestone on time and make the schedule healthy? Why? …………………………………………………………………………………………

Interactive Filter to Display the Sequestered Subnet On the previous page, we saw that the Most-Critical Path is the path with the lowest Total Slack number (Path A with Total Slack = -260d). If the Total Slack is -260 days in a sequestered subnet, the real Total Slack = -260 + 250 = -10 days, which means that you must optimize that subnet by 10 days merely to make it meet the deadline date and even further to give it a time buffer and make it healthy. An interactive filter that prompts for the number of Total Slack that we want to filter on would be a great help

© PROJECTPRO CORP.

PAGE 279

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

(see page 310 for more on interactive filters). We will explain here how to create this interactive filter: 1. Click ribbon View, display list of Filters, select New Filter; the Filter Definition dialog appears. 2. Enter the following:

Notice that the prompt is enclosed by double quote signs and that the last character is a question mark; this is the syntax you need to follow to create an interactive filter.

3. When you apply this filter, the following prompt will appear:

With this filter, we can display the sequestered subnet to the major milestone quickly and then further refine it to display the most-critical path to that milestone. In the previous example, this would be the path A with -260 days of Total Slack, which is the

PAGE 280

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

value to enter in the previous dialog in that schedule. The result of this for the next exercise would look like:

You can see a beautiful Critical Path on one of the first major milestones in this program schedule.

8

The Total Slack numbers are very negative because the deadline on milestone 151 was moved one year earlier. The deadline pulled back by one year.

© PROJECTPRO CORP.

PAGE 281

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

Exercise Metro Police Dispatch System Objective: Sequester the subnet on a major milestone in a large schedule and find the most-critical path leading into that major milestone. 1. Open the schedule Metro Police Dispatch System.mpp. Verify how many tasks this schedule has; you should find almost 500 tasks. 2. Apply the view PD Summary; notice the major milestones identified. 3. We will analyze the Critical Path on line item 151 Milestone # 6, Message Switch Ready. 4. What is the lowest number of Total Slack? You should find that the lowest Total Slack number is 0d. To find this, activate AutoFilter and click the AutoFilter button in the Total Slack field; you now see a sorted list displayed with all values in the Total Slack field. 5. Enter a deadline on the line item 151 Milestone # 6, Message Switch Ready that is one year earlier than its current finish date: You need to change the current finish date of March 13, 2003 to one year earlier: March 13, 2002. Notice that the Total Slack value on the milestone and its predecessors have become very negative, because you have increased the pressure on this subnetwork by about 250 business days. You have now sequestered the subnet leading into this milestone, and with a filter we can now find all those tasks because of their large negative Total Slack numbers. 6. Apply the filter Total Slack is less than... (this filter was prepared for you for this exercise) and enter 0d. You now see all the tasks leading into the milestone (i.e., the entire subnet). How many parallel paths lead into the milestone? ……………. You should find that there are 3 or 4 parallel paths, and the most Critical Path is still hard to identify. 7. Navigate to the top of the schedule and determine what the lowest (i.e., most negative) Total Slack numbers are on the earliest tasks in the schedule. You should find that the lowest Total Slack value is -242d. What is the second lowest Total Slack value? It is -222d, which means that we can optimize the primary Critical Path or Most-Critical Path by 20 days before this secondary path becomes equally critical as the Most-Critical Path. 8. Reapply the filter Total Slack is less than... and enter -240d as the value; this value seems to filter out the Most-Critical Path on the milestone. You can now see a single critical path that is easy to analyze and optimize; you have successfully sequestered

PAGE 282

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

the subnet! You can now start working on shortening the Most-Critical Path by 20 days. 9. You can compare to our solution file Metro Police Dispatch System - Solution.mpp. 10. What ideas for shortening this Critical Path do you have? ………………………………………………………………………………………… ………………………………………………………………………………………… 11. In practice, you could mark all these critical tasks in one of the extra Flag fields and change the deadline on the milestone back to its original date, one year later. Or you could have a handy add-in, called PathsPro, do this for you.

Automatically Identify Critical Paths on Major Milestones We just saw a manual way to find the Critical Path leading to a major milestone, but there are also automated solutions to do this. Our application PathsPro allows you to select a major milestone and then have PathsPro display its most-critical path. We deliberately call this the Most-Critical Path, because this path can have some time buffer on its first tasks while still being the path that drives the milestone deadline. If you would like to try the following procedure yourself, you can download a 30-day, free version of this application at www.ProjectProCorp.com under Software; you need to install this add-in before starting the exercise. For the same schedule used in the previous exercise: 1. Open the exercise file Metro Police Dispatch System.mpp, select the milestone to analyze: 151 Milestone # 6, Message Switch Ready.

© PROJECTPRO CORP.

PAGE 283

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

2. Click ribbon Add-ins and click button PathsPro, and PathsPro notices that the workloads are not leveled in this program and displays the following dialog:

PAGE 284

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

3. For now, we will ignore the over-allocations and click the button Skip Leveling and analyze Critical Path and the ProjectPro PathsPro main screen appears:

These are the options we recommend.

4. Select the options: Under Search for, select:  The Critical Path and Display 1 near Critical Paths. Under Do you want to, select  Find the Paths into the selected task

© PROJECTPRO CORP.

PAGE 285

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

Click button OK, and PathsPro will start analyzing the schedule and display the following Most-Critical Path to this milestone:

The next nearest Critical Path only has 2 days of buffer, so if you optimize this path by 2 days or more, you need to re-run the PathsPro add-in because you will then have a new Critical Path.

5. As you can see, PathsPro also explains any issues it found along the Critical Path using green text to the right of the task that is special (e.g., task 8: Gap caused by leveling delay 9 edays). PathsPro finds the Critical Path much faster than our manual technique allows, and you can start optimizing this Critical Path right away, because it is displayed in MS Project itself. This path only needs to be shortened a bit, because the next-nearest Critical Path is only 2 days away, as annotated in the screenshot: 2 d buffer. Once the Critical Path has been shortened by 2 days or more, the PathsPro add-in needs to be run again to find the new Critical Path. Tip► Having an automated method, like PathsPro, identify the Critical Path on a major milestone and the next-nearest Critical Path in an IMS is important, because as you optimize one Critical Path, another path may become more critical. If you can easily display the next-nearest Critical Path as well, you will clearly see when this is the case. Once you have shortened the current path as needed, a picture emerges that clearly shows how the nearest Critical Path has taken over as the Most-Critical Path, at which point, you need to run PathsPro again.

PAGE 286

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

Finding the Resource-Critical Path in Program Schedules So far in this chapter, we assumed having access to unlimited resources, which allowed us to do the traditional Critical Path analysis. In the previous procedure, we skipped looking at the over-allocations and analyzing how they may (or may not) have affected the Critical Path. In a workload-leveled program schedule, you will have to find the ResourceCritical Path rather than the Critical Path, and the PathsPro application provides that option as well. While it is possible to find the Resource-Critical Path in a large program schedule by hand (see page 62 for the manual procedure), it is too hard to do so. If you find that limited resource availability affects the program schedule and delays it to a later date, we recommend you purchase an application that can display the ResourceCritical Path in any major milestone in an automated way. Very few applications can do this, because it is the most advanced schedule analysis on the leading edge of project scheduling: ◆ PathsPro from ProjectPro Corporation (see www.ProjectProCorp.com under Software) used by NASA and Space-X. ◆ Aurora, a high-end, expensive project scheduling application from Stottler Henke Associates Inc. that is used by NASA (see www.StottlerHenke.com). This software even allows you to maximize the use of 3-dimensional space, an important constraint in advanced technology situations.

Fragmented Traditional Critical Paths in all Schedules If you rely on Microsoft Project by itself to perform workload leveling across the projects in a program that share resources with other projects and programs, you, as the program manager, will end up with a fragmented Critical Path in your program schedule.

© PROJECTPRO CORP.

PAGE 287

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

In a multi-project environment that shares resources, the Critical Path in one schedule will start showing gaps, and, once again, you may have what looks like a fragmented Critical Path, which does not explain the Time entire program duration (see illustration) Fragmented and is of little use. A fragmented Critical Critical Path Path does not reveal to the program manager all tasks that should be monitored very closely to prevent slippages in the WBS project, nor does it reveal where the program manager should start optimizing the schedule. Trap! In a program, the Critical Path 1.0 technique as first invented in the late 1950s

loses a lot of its merit. What we need in such an environment is the Critical Path 2.0 technique 33 to produce a Resource-Critical Path that also reveals when the Critical Resources are used in other projects with a higher priority. Then project managers can plan and optimize their resource assignments in such a way that they will be delayed the least by other higher-priority projects or programs that steal their resources temporarily.

33

See the White Paper on our website www.ProjectProCorp.com under Articles, item White Papers. PAGE 288

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

PathsPro for Resource-Constrained Programs In the previous section, we saw that leveling the workloads of program resources led to difficulties finding the Program Critical Path. At ProjectPro, we have developed an innovative add-in called PathsPro 34 that can take care of most of these problems. Tip► PathsPro can level workloads in a program schedule even when you are sharing resources outside the program! It will also show you the Resource-Critical Path in your program or the Resource-Critical Path into any major milestone in your program. Here’s how the tool works: ◆ PathsPro first automatically identifies other schedules with which it shares resources in the future; you do not need to determine this manually, which is hard to do. ◆ If PathsPro does not find the priority numbers filled in (ribbon Project, button Project Information, field Priority) for those sharing projects / programs, it will prompt for relative priorities: Are the projects that share the same resources lower or higher in rank? You just need to know if the other projects that compete for the same resources are more important (higher-priority ranking) or less important (lower-priority ranking) than your program. ◆ PathsPro will then temporarily merge the sharing schedules together in a master project and level the resource workloads based on their relative ranking. Higher-priority projects get the resources first and may delay your program. Lower-priority projects will be delayed if they compete for resources with your program. ◆ Finally, PathsPro finds the Resource-Critical Path in the current schedule, reports which other higher-priority schedules interrupt its Resource-Critical Path, and clearly marks those impacts, including identification of the other project/programs to which your program loses its resource(s). Here are more details and some screenshots: If PathsPro notices you are sharing resources with other projects in Project Online / Project Server, it will automatically list them for you. It will prompt you to indicate the priority of the other projects / programs

34

See our website www.ProjectProCorp.com under Software: You can download a free, 30-day evaluation version or buy a license right away. © PROJECTPRO CORP.

PAGE 289

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

relative to your program by dragging those projects / programs above or under your program (Software Development DEF in the following dialog box):

There is only one project with a higher priority that will get its resources before our program.

Our program, the Software DEF Development program that shares resources with other projects and programs listed in this dialog

There are many projects with a lower priority that will get their resources after our program is resourced.

PathsPro will create a temporary master schedule in which it inserts all projects/programs your program shares resource with, then level all workloads and analyze the Resource-Critical Path for you. PathsPro will also indicate where other, higher-priority projects steal the resource away from your project, which creates a gap in

PAGE 290

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

your Program Resource-Critical Path. The output of our add-in PathsPro looks like this screenshot:

The generic resource system analysts will work on another, higher priority project first.

You can see in the screenshot that the generic resource ‘system analysts’ are working on another project, named Software ABC Development, that has a higher priority, which delays your program. Tip ► You can then perform an optimization of the Program Resource-Critical Path to shorten your program schedule, while monitoring other higher-priority projects or programs as you go along. Upon seeing this screenshot, the program manager has two possible courses of action: ◆ The program manager could lobby HR and/or executives to hire or train an extra system analyst, because the limited number of available system analysts is delaying this program by about one month (as shown in the previous screenshot). Depending on how important the program is strategically for the organization, the program manager may succeed. ◆ If that fails, the program manager can explore how the responsibilities of the busy system analysts can be minimized or perhaps transferred to a business analyst. Tip► Every time a change is made to assignments in a resource-constrained program, the program manager needs to repeat this analysis, which is why automated tools are a necessity. By repeating this process regularly, you can perhaps stay ahead of persistent slippages and bring in your program on time. You might even turn from a monthlymessenger-of-bad-news into a monthly-messenger-of-good-news; at minimum, you can manage the expectations of your stakeholders proactively rather than reactively surprising them.

© PROJECTPRO CORP.

PAGE 291

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

Creating and Comparing Multiple Scenarios When you start leveling workloads in your program, you may end up with several scenarios that you would like to compare side-by-side. Trap! MS Project is shipped with extra fields to store entire scenarios of your schedule dates. Up to ten scenarios of a schedule can be stored in one project file using the interim plan feature: Ribbon Project, button Set Baseline, item Set Baseline and the Set Baseline dialog appears, choose the option  Save interim plan; this feature copies the Start and Finish dates into one of the extra sets of dates available. Beware that if you store scenarios in a master schedule, only the dates of the tasks that are owned by the master schedule (often none or very few) will be copied, whereas you need all dates in all subprojects to be saved. If you need to do this in a master schedule, please copy entire columns instead using the procedure described in the next section. Tip► Storing the what-if scenarios inside a master schedule needs to be done differently, because the Save Interim Plan feature only saves the baseline for tasks owned by the master schedule, not tasks owned by the project schedules. The following technique does save the dates for all line items in a master schedule:

1. Right-click on the Start column heading, the column to copy. 2. Select Copy from the pop-up menu. 3. Insert the column into which to paste: e.g. Start1. 4. Right-click on the paste column heading: Start1. 5. Select Paste from the pop-up menu; all values for master and project schedule tasks in the entire column are overridden and display the pasted values. 6. Repeat the same procedure for the column Finish pasting the dates into the field Finish1. Trap! Please note that the same restrictions apply here as with the Save Interim Plan feature: ◆ Do not copy the dates back into the Start and Finish columns, because those are calculated fields. ◆ Do not copy dates to the Baseline Start or Baseline Finish fields either in this way: The two date fields (Start, Finish) are a subset of the five baseline fields (Start, Finish, Duration, Work and Cost), which is a subset of all schedule data (that also includes data on assignments, dependencies, constraint dates, resources, various calendars, etc.).

PAGE 292

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

Comparing the Three Scenarios (Interim Plans) When you level the workloads, you often create two or three scenarios: ◆ No leveling ◆ Leveling as many overallocations as possible but up to a certain hard constraint date ◆ Full leveling You can display all three leveling scenarios in one Gantt Chart. Each task will have three task bars, each of which represents one scenario. By giving each scenario a differently colored task bar, you can easily analyze the differences between the scenarios. To quickly analyze the differences between scenarios, we recommend using a view that shows the differences next to each other in the time scale. You can show up to three scenarios in the time scale. 1. Create a new view: Create a new view by clicking ribbon View, button Other Views, item More Views. Copy the Gantt Chart or Tracking Gantt chart. Click OK and click Apply. 2. Click ribbon Format, button Format, item Bar Styles. Enter the settings for scenario 1, scenario 2 and scenario 3 (or enter more descriptive names for each scenario) as shown in the following dialog. You should while:  Select a different color task bar for each scenario;  Use the thinnest line for each scenario, and  Use the top, middle and bottom bars (if you use the same bar, all bars will overlay each other and only one will be visible).

© PROJECTPRO CORP.

PAGE 293

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

3. Click OK. 4. The result of such an exercise will look like this:

At the start of the program, all scenarios are still the same, near the middle of the program (at the bottom of this screenshot with a portion of the schedule), scenario 2 and 3 are much later than scenario 1.

Optimizing the Program Critical Path Thus far, we have focused all efforts on finding the Critical Path or Resource-Critical Path in the program. It is now time to validate and optimize the (Resource-)Critical Path. Validating the Critical Path may seem unnecessary, but our experience shows that validating takes a fair bit of effort simply because suddenly ‘some poor activities’ in the project schedules are pushed onto the big stage and into the bright spotlight of the Program Critical Path. These activities may not have been carefully scheduled or linked into the network logic by the project manager, who never suspected they would end up on the Program Critical Path. If this is the case, the scheduling of those activities first needs to be improved in such a way that eventually everybody feels comfortable looking at a sequence of activities linked with valid dependencies that determines the program duration.

PAGE 294

© PROJECTPRO CORP.

Forecasting Programs

Chapter 8 Optimizing the Integrated Master Schedule

To validate the (Resource-)Critical Path: ◆ Check if all dependencies are either practically-necessary relationships or organizationally-imposed relationships. If you model projects (rather than simply and arbitrarily sequence activities), dependencies will always be of a practically-necessary or organizationally-imposed nature; there are no other types of dependencies in modeling projects! For a more nuanced and detailed discussion on this topic, see my other books on Forecast Scheduling. I will only summarize it here. Practically-necessary relationships are dependencies that follow the laws of nature, laws of physics or simply common sense, for example:  You must write text before you can print it,  You must build the foundation before you can put walls on top of it, you must build the walls before you can put a roof on top of them.  You must code software features before you can test the code. Organizationally-imposed relationships are processes or procedures imposed by the executives of an organization, for example:  You must have the corporate lawyer review a publication before it can be distributed to the public.  You must check the accounting reports against GAAP-rules (Generally Accepted Accounting Practices) before releasing any financial report to shareholders or the public.  You must submit the design documents and source code to the central quality-assurance department before releasing the code to the client. ◆ Check if the tasks that appear on the Critical Path are the type of tasks that you would expect (or tolerate) on the (Resource-)Critical Path. The following are examples of tasks that we would normally not expect or tolerate on the (Resource-)Critical Path (copied from the Forecast Scheduling books):  Summary tasks The (Resource) Critical Path can only consist of activities and milestones. Summary tasks cannot be on the (Resource) Critical Path if you followed our recommendation to keep dependencies and resources on detail tasks only.  Overhead tasks Tasks like technical support and project management are tasks with start and finish dates determined by other activities, which is why they are also called hammock tasks. Overhead tasks cannot be critical; if they are, their durations need to be shortened until they are not critical.  Recurring tasks Regularly scheduled tasks, such as status meetings, should not be on the Critical Path. Any recurring detail tasks like status meetings that appear on the Critical Path should be removed from the schedule.  Tasks that normally have large time buffers For example, write test plan in a software development project normally has a big buffer. © PROJECTPRO CORP.

PAGE 295

8

Chapter 8 Optimizing the Integrated Master Schedule

Forecasting Programs

At this point in time, we have a valid Program (Resource-)Critical Path, and we are ready to optimize it. Notice that I deliberately use the word ‘optimize’ and not ‘minimize’ or ‘make it as short as possible’, because shortening the Critical Path is almost always a matter of trading off against: ◆ Scope: the list of deliverables you are committed to produce. ◆ Quality: the quality requirements (checklists) with respect to all deliverables as well as the end-product, service of result of the program. ◆ Cost: the total expenditure for the program. ◆ Resources: the material, equipment, facilities and human contributors to the program. ◆ Risk: the total exposure of the program to cause injuries, damages, defamation or other liabilities the organization will be responsible for. ◆ Procurement: all contractual obligation flowing form the program initiative. ◆ Communication: the management of all expectations of all stakeholders involved in or affected by the program. For each optimization decision, an assessment needs to be made if the gain in time weighs favorably against the loss in quality, the increase in risk or any other effects that gain may cause. In this book, we will not discuss optimization techniques because they have been covered in detail in my Forecast Scheduling textbook in chapter 9. I recommend you use that book in combination with this Forecasting Programs book, because they are truly complimentary. Forecast Scheduling is about creating a valid, dynamic and robust model of the individual projects to forecast them continuously, whereas this textbook, Forecasting Programs, is about modeling and managing the set of related projects in a program. 35

35

If you need a copy, please refer to: www.ProjectProCorp.com under Books.

PAGE 296

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

Chapter 9 Reporting on Large Schedules

Learning Objectives

9

After this chapter, you will: ◆ Understand the need for one-page reports even on large programs ◆ Know what to do when stakeholders insist on different work breakdown orientations ◆ Develop multi-field and interactive filters for analysis of large program schedules ◆ Be aware of a variety of options to produce one-page reports ◆ Develop a major-milestones view to display the program in a concise way

© PROJECTPRO CORP.

PAGE 297

Chapter 9 Reporting on Large Schedules

Forecasting Programs

People Plan, God Smiles… Bob meets Nob in the lunchroom on Tuesday and asks, “Hey, Nob, what were you up to this weekend?” “Well, I tried to replace one of my septic tanks. I had the job all planned. I had all the supplies and I scheduled three days, from Friday to Sunday, to dig up the leaky, concrete tank and put in the new plastic tank.” “Did you get the job done?” “The main powerline ran between the tanks; who would have thought that! On Friday evening, we suddenly saw sparks from our powerline, and we had to get the Hydro guys to come and fix it. They came Friday night and repaired the line in three places, even though we thought we had been very careful with it while digging. On Saturday, we realized the new tank had to be buried one meter deeper than we planned, because the feed pipe could only be inserted in the top. We started digging and soon we hit rock, so we had to get out to rent a jackhammer to split the rock in small pieces that we could handle.” “Did that work?” “Yes, it did, but very slowly. Some rocks took me several hours to remove. Then we discovered a really big rock near the bottom. We dug a long time on Saturday, then finally on Sunday we hired a young guy with a strong back – my wife’s fitness instructor – to help us out. He threw those rocks almost into the neighbors’ yard. “ “Is your septic up and running now? Can you shower and go to the toilet?” “No, we dug and dug until Sunday at 9 PM to reach the depth we needed for the plastic tank. By then, we realized we were too tired to lower the tank, afraid we would damage the power line again or the pipes from the weeping bed, so we decided to postpone that 30-minute job to Monday. My wife had taken another day off work.” “So???” “If you recall, it rained really badly on Sunday night, and the over two-meter-deep hole filled up with water. We had to rush out to rent a trash pump, and we were lucky to get one of the last ones. We’ve been pumping ever since. The rain is not going to stop anytime soon.” “Wow, that was the Project-From-Hell!”

PAGE 298

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

The Challenges of Reporting on Large Programs The real challenges for reporting on large programs are: ◆ How to summarize an ocean of data within the limited confines of a small screen or a single page? We will discuss this later (see page 299). ◆ How to address the need to provide each stakeholder with a relevant report and maintain multiple breakdown-orientations that are dramatically different within a single schedule? We will discuss this next.

Multiple Breakdown Orientations in your PWBS There are several options to work this magic as a program scheduler. The goal of creating multiple breakdown structures in your PWBS is to address the often-conflicting reporting needs that program managers experience. Wouldn’t it be nice if we could present two breakdown structures side-by side in one schedule and have the flexibility to switch between them with a few clicks? This is possible in all leading scheduling applications like Oracle Primavera and in Microsoft Project as we speak. For example, in a new product development program, you may have a hardware component planned in a waterfall way and a software component planned in an agile way. Now, the program manager faces the challenge to present the program in an agile way to the software stakeholders, particularly the team of programmers, and present the program in a waterfall way to the hardware folks. How can the program manager do this? The following illustration provides an example of two breakdown structures living peacefully, side-by-side: The one on the left is the primary deliverable-oriented breakdown structure; the one on the right is the financially-oriented breakdown structure to satisfy the financial folks who are interested in seeing OPEX (operational expenses that are fully deducted) versus CAPEX (capital expenses that are deducted over multiple

© PROJECTPRO CORP.

PAGE 299

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

years and for which there may be government grants): Deliverable-Oriented Breakdown

The tags of the secondary breakdown structure in this custom Outline Code field

Subtotals by deliverable in the primary breakdown structure

Financially-Oriented Breakdown

The tags from the original, primary breakdown are always accessible in the field Task Summary Name.

New subtotals by financial charge code

As consultants, we’ve had to create such screenshots when the finance guys come into the office of the program manager and demand that the top-level breakdown orientation of the PWBS needs to follow a breakdown that they have already set up in the SAP ERP-system in the project system module. They say to the poor program manager: You must use this top-level breakdown because otherwise we cannot provide you with important financial reports on your program that the CFO will be looking for. Would you succumb to this demand that implicitly comes from the CFO? You are damned if you do and damned if you don’t, because program managers cannot afford to lose their deliverable-oriented breakdown, and the finance guys cannot afford to lose their financial reports. Our answer: No, you do not need to succumb, because it is actually not a yes-or-no situation. You can have your cake and eat it too, because most schedule applications (like Microsoft Project and Primavera) allow you to create and maintain multiple breakdown structures that live side-by-side in a single schedule.

PAGE 300

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

What Breakdown Structures Do You Need? 1. First, you need to determine the best breakdown orientation for managing your program to successful completion. We recommended the orientation we talked about before (see page 147), where you break down the program into projects that are as autonomous as possible, creating autonomous teams that can make progress without the help of others. Then break down each project into deliverables. This is your primary breakdown structure, which you capture in the Task Name field in Microsoft Project. 2. Next, list all reporting needs for your program and ask yourself the following question: OK, what breakdown structure is needed for that report? Once you have all the breakdown orientations you need (secondary, tertiary breakdown structures, etc.), you know how many Outline Code fields you need to customize in Microsoft Project or Enterprise Outline Code fields in Microsoft Project Server or Project Online.

How to Create Multiple Breakdown Orientations in MS Project? The overall process in Microsoft Project to customize one field and meet one reporting need is as follows; if you need more detailed how-to steps, please refer to my Forecast Scheduling books: 36 1. Customize one field for each alternative breakdown structure you need. We recommend using the extra fields that are meant for customization: Outline Code 110 for multiple breakdown levels, or Text1-Text30 for a single-level of breakdown. Then rename it and create a list for it in a Lookup table, in which you enter the categories/tags/items of your breakdown structure. Click ribbon Format, button Custom Fields to access the Customize Fields dialog box; for more detailed steps, see my Forecast Scheduling 2013 book (page 556) or the 2010 book (page 557). 2. Tag each task in your current breakdown structure with the values you have entered in the new Lookup table. This can be a lot of work in a 2,000-task schedule. You also must decide if you will tag the tasks or the lower level of assignments: A 2,000-task schedule may have 3,000-4,000 assignments. It is possible that from a financial point of view, your deliverable-oriented view does not have all items to tag; in that case you may also need to add some dummy items to your WBS to accommodate this and satisfy the financial folks. For the tasks that cannot be tagged, you have two options:  Leave them blank and they will end up in a separate ‘Blank’ group automatically created by Microsoft Project. 36

You can purchase it at: www.ProjectProCorp.com under Books.

© PROJECTPRO CORP.

PAGE 301

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

 Add a rest category to your lookup table, such as ‘Other’, or use a more descriptive name to catch those items. In the primary breakdown structure, there are always a few outliers that do not fit in the secondary breakdown structure, and vice versa. 3. Microsoft Project then allows you to report on each breakdown structure separately by using the View feature, which allows each view to have its own Grouping, so you can create a new view with its own grouping built in. Base the grouping on the new field that you just customized specifically for this report. Click ribbon View, list button Group By, and item New Group By or item More Groups to get to the right dialogs. Microsoft Project will calculate subtotals for each group as well, which is a nice bonus. If you need more detailed how-to steps and background information, see my Forecast Scheduling 2013 book (page 556) or the 2010 book (page 551).

Overview: Single-Page Reports in Large Programs Tip► Even though the amount of data in a program schedule is much larger than in a project schedule, we still recommend creating one-page reports as we did for projects in the Forecast Scheduling books.

The following are different ways to compress a large program schedule into a one-page report: 1. Create Tracking-Gantt-like progress bars for Projects in MS Project 2. Major Milestones View in MS Project 3. Using Advanced, Custom Filters in MS Project 4. MS Project Timeline view: the 2016 edition of MS Project can now display multiple Timelines with which you can create reports like swim lane charts. 5. Swim Lane Chart using OnePager 6. Earned Value Report using MS Project or CurvesPro One-by-one, we will provide the how-to steps for these one-page reports.

PAGE 302

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

1. Create Tracking-Gantt-like Progress Bars for Projects By default, MS Project offers this Tracking Gantt view, which is not very useful for program managers since the baseline is missing:

While this report has the benefit of showing the latest forecasts this view does not display the original schedule, the Schedule Baseline; executives cannot see the original commitment relative to the most recent forecasts shown in the previous Tracking Gant chart. We can adjust the view to show the baseline bars as well. In the following chart, you can see the latest forecasts (top bars in blue) with the baseline schedule shown as a separate gray bar below the blue bar:

This chart has these unique features: ◆ A baseline bar for each project in your program, so you can compare how a project was supposed to progress (bottom gray bar = baseline schedule) versus how it is progressing (top blue bars = dynamic, forecast model).

© PROJECTPRO CORP.

PAGE 303

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

◆ Progress bars (Actual Duration, dark blue) and Remaining Duration bars (light blue) for each project: Actual Duration + Remaining Duration = Duration, which is the latest forecasted duration for the project. To create this view for project schedules that will be inserted into a master project, you need to make the following changes to the Tracking Gantt view: click ribbon Format, button Bar Styles, item Bar Styles to display the following dialog and enter the following settings:

Remove all entries from the Show For … Tasks and change CompleteThrough to Summary Progress

Notice that the field Actual Duration is not an item in the lists in this dialog. For the entire project, Actual Duration is the number of business days that have gone by from the project Start date up to the project Status Date, a useless number for program performance calculations. On the level of activities, Actual Duration is a more useful construct: ◆ For a completed activity, it is the real number of business days an activity took. ◆ For an in-progress activity, it is the number of business days a person has worked on the activity so far (i.e., until the project status date). For example, if a person was supposed to start on the activity last Monday and today is Friday of that week, you can ask: Did you work on Monday on this activity? If so, the Actual Duration is 1 day at the end of Monday. Did you work on Tuesday on this activity? No, you were sick at home, so the Actual Duration at the end of Tuesday is still 1 day. If the person worked on Wednesday, Thursday and Friday on the task as well, the Actual Duration is 4 days to be entered into MS Project.

PAGE 304

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

As you can see, the Actual Duration entered on the level of detail activities is a much more useful metric to collect. The challenge is then to roll it up onto all higher levels of summary tasks. For this, Microsoft developed nifty formulas that will do this number crunching and present them as project-level metrics. They are: ◆ CompleteThrough is a date calculated by subtracting the project’s Remaining Duration from the latest forecast Finish date for the project: CompleteThrough = Finish - Remaining Duration Microsoft Project arrives at the Remaining Duration for the project in this way: Remaining Duration = Duration – Actual Duration Where:  Duration = the latest forecast Duration for the project in business days  Actual Duration = the number of business days between the project Start date and current Status Date. ◆ 2010 Summary Progress (i.e., the progress on a summary task) is calculated as: Summary Progress = (sum of the Actual Durations of all its detail tasks) / (sum of all the Durations of all its detail tasks) * summary task Duration While not perfect, Summary Progress is better than CompleteThrough and much better than Actual Duration for progress bars on Summary Tasks. However, there are problems with using Summary Progress, which has turned out to be not precise enough for Earned Value calculations for the entire project. After all, Earned Value calculations really need to happen by aggregating all Earned Values from the detail tasks (or, better yet, from one level lower, the assignments as we have done in our CurvesPro reporting tool, an add-in to Microsoft Project 37). The way Microsoft Project calculates the aggregated Summary Progress and the project % Complete is somewhat arbitrary and has not met the strict standards 38 for Earned Value. For more on Earned Value, see page 324.

2. Major Milestone View For a milestone chart, you handpick the major milestones from the hundreds of milestones in your program schedule and bring them together in a one-page view of the

37

For more information, see our website www.ProjectProCorp.com under Software. It can create traditional Earned Value charts directly from your schedule, or, a newer concept, Earned Work charts. 38 See for example: Earned Value Management System (EVMS), SAE EIA748C-2013, American National Standards Institute (ANSI), 2013, www.ANSI.org © PROJECTPRO CORP.

PAGE 305

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

program. If one of the milestone diamonds is off its baseline, you can provide just enough detail to explain why that milestone is off. This concept is illustrated in: You can see the Roofing deliverable missed its baseline finish date (the framed diamond is to the left of the solid black diamond, the latest forecast finish date). The detail provided shows that the frame took longer as did the shingle. Together the overview and the supporting detail tell the whole story about this project. In a program, a similar technique can be used to distill the program performance into a single-page report. Tip► Milestones allow you to chart the important events within a program. A large program schedule may have hundreds, perhaps even thousands of milestones. If you carefully identify some of the many milestones in your program as major milestones, you can create a one-page report on the program as shown in the illustration. Aim at marking at least ten milestones as major milestones, but not more than 50 to stay within one page.

For each discrepancy with baseline dates, you can provide just enough supporting detail to explain the entire discrepancy. All of this often fits on one page or a few pages.

Major Milestone View with Filter We recommend you leave the major milestones in the sub schedules (not replicating them at the top of the master schedule) and tag them using one of the extra flag field, like Flag1. Then create a major milestone view that filters all major milestones into one screen, which can look like this Major Milestone view 1:

OR Major Milestone view 2 with the corresponding summary tasks also shown, like this:

PAGE 306

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

To create a view like this: 1. Create a new view Major Milestones: a. Switch to the Tracking Gantt view by clicking ribbon View, click the bottom of the button Gantt Chart to display the list and select Tracking Gantt. We use the Tracking Gantt here as the basis because we want to display the baseline diamonds in the report; the Tracking Gantt displays the baseline bars, and the regular Gantt Chart does not. b. Click bottom of button Gantt Chart to display the list of Gantt Charts and click item Save View and the Save View dialog appears. c. Select  Save as new View and enter in Name the label Major Milestones. 2. Customize one of the extra Flag-field and rename it to Major Milestones: a. Right-click on the column heading where you want this new field and select Insert Column. b. Select from the list item Flag1 (or any other Flag field not in use). c. Right-click on the column heading Flag1 and select Custom Field from the popup menu, the Custom Fields dialog appears. d. Select the Flag1 field in the list and click button Rename and rename the field to Major Milestones. Click button OK and OK again; you are now back in the Gantt chart view. © PROJECTPRO CORP.

PAGE 307

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

e. Display only the columns ID, Indicator, Task Name, Major Milestones, Baseline Finish, Finish and hide all other columns. 3. Mark all major milestones in your task list with Yes in this custom field Major Milestones. Again, the aim is to tag about 10-20 milestones as major milestones. 4. Develop a new filter Major Milestones that displays all major milestones: a. Click ribbon View, display the list under Filter, click item New Filter and the New Filter dialog appears. b. Enter as the name Major Milestones and the following filter definition:

Select this to display corresponding Summary Tasks for the milestones (to see context).

The second line ‘Or ID is less than 1’ makes sure that the project summary task is shown as well. c. If you keep the  Show related summary rows cleared, you will only see milestones in the view: Major Milestone view 1. If you select  Show related summary rows, you will see the second example of a major milestones report with the summary tasks: Major Milestone view 2. d. Click button Apply and the report is shown and ready to be applied at any time with three clicks: click ribbon View, click the bottom of the button Gantt Chart to display the list and select Major Milestones.

Exercise: Create a Major Milestones View for the Intranet Program 1. Open the exercise file Intranet Program.mpp.

PAGE 308

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

2. Create a major milestone view that displays all milestones in this small program and the project summary task. Use the previously listed steps to accomplish this. 3. Compare your results with the solution file: Intranet Program - solution Major Milestone view.mpp.

Major Milestones Replicated at the Top of the Program Schedule? There are pro’s and con’s for listing the major milestones at the top of the master schedule: Pro’s People expect it at the top like a Table of Contents in a book.

Con’s It creates long dependency arrows that obscure the schedule; it draws a curtain in front of the schedule.

People can easily find the most important milestones without any further knowledge of MS Project. US Defense subcontractors often put the CDRL items (Contract Data Requirements List) at the top of the list as well. Some even include the Givers and Receivers (the handoff milestones with cross-project dependencies). Many program schedulers insert the major program milestones at the top of their schedule to make it easy for any executive to find the major milestone chart for the program, as shown in the next screen shot:

© PROJECTPRO CORP.

PAGE 309

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

The major milestones are duplicated at the top, and they only have one arrow going into them. If the major milestones are not replicated but are all gathered at the top, you end up with very long dependency arrows going two ways. These long arrows also make it very difficult to analyze the Critical Path for the entire program as you can see in this illustration:

It is as easy to create a view with a filter that displays all major milestones in one screen and in the exact format ready for print and distribution, see the next sections for the steps to create this view. Tip► We therefore recommend leaving all major milestones in the task list in the sub schedules, where they fit naturally, instead of gathering them all at the top.

Views We have created several views that we use when creating reports for clients. These reports have some settings in common for Bar Styles and Text Styles, which we will discuss first before discussing the views. We developed these formats for two main reasons: ◆ The default summary task bars do not provide a good way to display all three data points of interested: baseline, actual duration and remaining duration. ◆ Programs have so many outline levels that you end up seeing only summary task bars in high-level views. PAGE 310

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

The following settings resolve these issues.

Format, Bar Styles Dialog This dialog provides millions of possible permutations, and over the years I have tweaked this dialog many times to get what I want. I established these basic guidelines: ◆ The Tracking Gantt chart needs to print beautifully in black and white as well as in color. ◆ The level of importance (which is related to, but not equal to level-of-indentation) is currently depicted by different task bars, meaning project-level tasks have bars different from summary tasks which have different bars than activities. Program schedules have so many levels (at least 5 or more) that all these different task bars are confusing. The task bars need to be the same in that they should all display current schedule, progress and baseline (which is not the case for summary tasks). The best depiction for this is the Tracking Gantt bars for activities: I want to use this depiction on every summary level. ◆ Still, I wanted to see the different levels of importance and easily recognize if a bar is a project bar (highest level), a summary bar (intermediary level) or an activity bar (lowest level). I decided to depict these levels of importance by using different colors and choosing a relaxing color for the lowest level and increasingly brighter colors for the higher-level items (without using red, which is already in use for critical tasks). Hence, my color choices became:  Project Summary Tasks: pink (but not eye-blinding pink!)  Summary Tasks: purple (often deliverables!)  Activities: blue (that we are all used to already) ◆ The baseline bars (for activities and summary tasks) and baseline diamonds (milestone) need to be visible in every view. The color of the baseline diamonds needs to be solid black (unlike default settings), because solid black is the color for the baseline bar of activities. The default milestone diamond is framed. It also displays the date, which is good. ◆ Progress is indicated on the bars through a darker version of the same color. Dark corresponds to heavy, factual actuals that belong to the past. Light corresponds to guesstimated future projections. These guidelines led to the following settings that can be found in the ProjectPro Tracking Gantt view in the download file with the same name; click ribbon Format, button Format, item Bar Styles to access this dialog. However, to understand my settings, you first need to know how this dialog and its features function: ◆ The item at the top of the list is drawn first in the chart by MS Project and may be overridden (superimposed) by items lower in the list. As a result, you may never see the bars that you put at the top of the list, because something else is on top of it. © PROJECTPRO CORP.

PAGE 311

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

◆ CompleteThrough only shows up in this dialog. It is a calculated value explained elsewhere (see page 303) that represents the progress on summary tasks. ◆ You need to think about on which item you display text, such as the date text for milestones, because text can easily overlap with the diamonds when they slip or pull ahead. If you assume that projects typically slip, the text needs to be shown on the regular item (latest forecast), which is displayed furthest to the right in the timescale. If your projects are typically ahead, you want to instead show the date on the baseline diamond to avoid overlaps between diamonds and text. Here are the settings we use in two screenshots because the list is long:

PAGE 312

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

Here are the invisible tricks I applied in this Bar Styles dialog box: ◆ I removed all bars related to manually scheduled tasks, because I will never use those in program schedules. ◆ Milestones:  Out-of-the-box, there are three line items for milestones in the Tracking Gantt view, but you only need two line items (because of an error by Microsoft in the default To settings for the baseline; Baseline Estimated Start should have been Baseline Estimated Finish). You can see that we use four milestones (baseline, critical, non-critical, completed) as shown in the dialog; make sure you set the From - To dates as shown in the screenshot.  I colored the regular Milestone item light blue, just like regular tasks, and added a line item for Milestone Progress with the same color as progress on regular tasks (Task). Type is Solid; not Framed (default).  I added a line item for Milestone critical and made it the same red as the bars of critical tasks (Critical); Type is Solid; not Framed. ◆ I position the baseline line items always at the bottom of the multiple line items for each type of task, because I found that if I put it elsewhere, the other bars do not always show up with the same height (caused by a small overlap between the current schedule/progress bars and the baseline bars), which looks odd. ◆ I always use the third option in the Shape list (the top bar of half height) as the shape for the current schedule and progress bars that need to be at the top.

© PROJECTPRO CORP.

PAGE 313

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

◆ I always use the fifth option in the Shape list (the bottom bar of half height) as the shape for the baseline bar that need to be at the bottom. ◆ For colors, I always use the following in every view in terms of RGB (Red, Green, Blue) that you enter in the Colors dialog box: ribbon Format, button Format, item Bar Styles; the Bar Styles dialog appears, at the bottom display the list Color and select item More colors… and click tab Custom. My rationale for these choices in color: The colors blue, purple and pink look nicely together, and the more important the line item, the brighter the color (blue  purple  pink): Blue Bars (Activities) Regular

Purple (Summaries) Progress

Regular

Pink (Projects) Progress

Regular

Progress

Red

172

59

204

112

255

255

Green

207

135

153

48

153

25

Blue

242

212

255

160

255

255

Format, Text Styles Dialog Now that we can communicate the importance of each task through color rather than through different bars styles, we would like to color the text in a similar way: Click ribbon Format, button Text Styles and the Text Styles dialog appears; display the list Item to Change and In the same Text Styles dialog, select the item Summary Tasks and select the following: ◆ Under Font and Size, wipe out any entries so they revert to the default system settings. ◆ Under Font Style select Bold to keep the project summary tasks bolded. ◆ Under Color, select More Colors… and the Colors dialog appears; select tab Custom. Select the following RGB-settings: Red: 112 Green: 48 Blue: 160 Notice there is no item for project-level items in the list, so we will present a workaround for that by marking them in field Marked and formatting Marked Tasks: PAGE 314

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

◆ Under Font and Size, wipe out any entries so they revert to the default system settings. ◆ Under Font Style select Bold to keep the project summary tasks bolded. ◆ Under Color, select More Colors… and the Colors dialog appears; select tab Custom. Select the following RGB-settings (notice that we chose brighter pink for text because text is thin on a bright white background that makes colors pale): Red: 204 Green: 0 Blue: 204 We need to mark the few project-level tasks still, so the coloring comes through: ◆ Insert the field Marked. ◆ Enter a Yes in this field for any project-level task (there are only a few!) including the program summary task; their bars should now turn pink. We now have an attractive Gantt-based chart that looks like the next screenshot (even though in the black-and-white paper version of this book, you will not be able to enjoy the color scheme):

9

© PROJECTPRO CORP.

PAGE 315

Chapter 9 Reporting on Large Schedules

Forecasting Programs

Major Milestones View

Tricks I used to create this view: ◆ Created custom enterprise task-related Text-field called Schedule to capture the code for each project schedule in the program. This is needed for analyzing the Program Critical Path where activities may be hoisted from any of the project schedules without any contextual information for those activities; at minimum, you need to know what schedule each critical activity comes from. ◆ Created a custom view called Major Milestones to display all major milestones:  Switch to Tracking Gantt view, because it displays the baseline.  Click ribbon View, bottom part of button Gantt Chart, click Save View.  Enter name Major Milestones for the view and click OK; this also creates a new table with a similar name. ◆ Created custom enterprise task-related Flag-field called Major Milestones to capture which of the milestones (inch pebbles) should be tagged and become visible as major milestones. Inserted this field in the view. ◆ Created a filter for the view and added an extra criterion to also display the Project Summary Task:  Click ribbon View, display list of Filter, select New Filter; the Filter Definition dialog appears.  Enter the following: And/Or Or

PAGE 316

Field Name Major Milestones ID

Test Value(s) Equals Yes is less than 1

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

Trap! Normally, you would do: ‘Or ID equals 0’ but I received error messages on this sometimes; the solution you see here is a workaround that always seems to work. ◆ Removed the dependency arrows: ribbon Format, button Layout, first option under Links. ◆ Removed the indentation of the milestones because it looks disorganized. This is a little-known feature I had almost forgotten about until I really wanted it for this view. Here is where I found it again:  Click ribbon File, item Options; the Project Options dialog appears, click tab Quick Access Toolbar;  At the top, in the list Choose commands from, select Commands not in the ribbon, in this list, select item Indent Name and click button Add>> to copy it into the list on the right called Customize Quick Access Toolbar and click OK; this button is now shown on your Quick Access Toolbar at the top left of your screen.  Click button Indent Name and the indentation will disappear providing a much cleaner view. ◆ Format the bar styles is such a way that they display the baseline diamonds for milestones. The Tracking Gantt chart displays diamonds for the baseline milestones, but if you missed our first step, you will now have to add them back in. Click ribbon Format, bottom of button Format, select Bar styles. Scroll down in the main list to the section of the milestones and enter the following settings for items , Baseline Milestone, Milestone as shown in the next screenshot: Notice this change!

© PROJECTPRO CORP.

PAGE 317

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

◆ Format the bar styles for summary task bars such that the baseline and progress is displayed on the Project Summary Task as shown in the previous screenshot for the items: Summary, Summary Progress and Summary Baseline.

3. Using Advanced, Custom Filters Filters in Microsoft Project come in a wide variety: ◆ Standard, out-of-the-box filters (some of which are useful for programs) ◆ Custom-made, new filters that have two subtypes of interest to program managers:  Multi-field filters that filter on more than one field with And / Or logic (Boolean logic)  Interactive filters: Filters that prompt for input from the users before retrieving records from the database (task, resource or assignment records).

Some Useful Standard Filters Useful filters that come with MS Project for analyzing the progress are: ◆ Late Tasks: displays tasks with remaining durations in the past. ◆ Slipping Tasks: displays tasks with Finish date that is later than Baseline Finish. ◆ Slipped/Late Progress: displays tasks with finish date that is late and tasks with an Earned Value (BCWP) less than the Planned Value (BCWS); these are related to Earned Value Management, for more on this, see page 324. ◆ Cost Over budget: displays tasks with a forecasted Cost greater than its Baseline Cost.

Filters that Use Multiple Fields and Criteria In program schedules with thousands of tasks, you will often need filters that filter out tasks on more than one field or attribute. For example, if you want to see all the deliverables that cost more than $10,000: ◆ The deliverables are (supposed to be) summary tasks; the task-related field Summary is a yes/no field that indicates if a task is a summary task or not. ◆ To check the second condition, that the deliverable task costs more than $10,000, we filter on the field Cost at the same time.

PAGE 318

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

The definition of this two-field filter would be:

You can even use more than one set of multiple conditions separated by an “Or”. For example, if you want to see all expensive and all long-duration deliverables, you need to filter out all deliverables (captured as summary tasks) that have more than $10,000 cost and deliverables with duration longer than 1 month. The definition of this filter would be:

9

Notice that: ◆ Even though in natural language, you would say: I want to see all expensive AND all long tasks, you need to use an OR here in the filter definition to make them both © PROJECTPRO CORP.

PAGE 319

Chapter 9 Reporting on Large Schedules

Forecasting Programs

appear! To keep these straight, I use this mnemonic trick: If I want to see more tasks, I use OR; if I want to see fewer tasks, I use AND. ◆ You need to repeat the Summary equals Yes criterion because, in both cases, you only want to see the summary task deliverables (not activities or milestones). ◆ The Or is outdented and has a gray background color.

Interactive Filters We can make the previous filter even fancier by requiring it to ask us what threshold it should use every time we apply it. In this way, we don’t need to create many filters for the different thresholds we typically use, we need just one smart filter called an interactive filter. This interactivity is very useful in programs, because you often need to try a few different values before you see what you want to see, as was the case when we filtered on Total Slack in our pursuit of the Critical Path (see page 279). To make the filter interact with us, we must provide two things: ◆ We must change the filter such that it does not filter on a specific value or string, but instead asks a question. MS Project recognizes this when there is a prompt enclosed by double quote signs and a question mark in the Value(s) field in the Filter Definition dialog. ◆ The prompt or question must be taken literally by MS Project and must be enclosed in double quote signs followed by a question mark sign, as in: “What is the cost threshold”? ◆ It is customary to append three trailing dots to the name of the filter to indicate it is an interactive filter.

PAGE 320

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

The definition of this filter would be: Trailing dots behind the name indicate the filter is interactive.

Prompt enclosed by double quote signs followed by a question mark makes the filter interactive.

Trap! Notice that the question mark must come after the closing double quote sign. You will receive the following prompt every time you apply this interactive filter:

9 Trap! The feature of filters comes with the restriction that you cannot use MS DOS wildcard characters like ? (question mark) and * (star) in the Value(s) field.

4. MS Project Timeline view 2010 This view, first featured in the 2010 release of MS Project, is a great view that can summarize a program succinctly:

© PROJECTPRO CORP.

PAGE 321

Chapter 9 Reporting on Large Schedules

Forecasting Programs

2016 In 2016, a new feature that allows adding multiple timelines to a single schedule was added, so you can emulate a swim lane chart with a hardware and a software swim lane, for example:

5. Swim Lane Chart A swim lane chart lets you tag items (summary tasks and/or milestones) into new groups and display these new groups to summarize the program. Some new groupings that program managers have asked us for are: ◆ Streams: related sets of milestones cutting across the projects ◆ Products: milestones that relate to particular products ◆ Stakeholders: milestones that relate to particular stakeholders ◆ Modules: milestones that relate to modules, which are semi-autonomous entities (i.e., components in a system) ◆ Stages: milestones that relate to stages as defined in the stage-gate methodology of the organization 39 ◆ Releases: feature milestones that will be deployed in a particular release These new groupings are then displayed in the report as new summary task bars, or swim lanes, such as this release-oriented grouping:

39

See Stage-Gate International (www.stage-gate.com) for more information about Stage-Gate methodology. PAGE 322

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

This chart contains the major stages and milestones tagged in the MS Project schedule. The chart was created by a tool called OnePager by Chronicle Graphics (www.ChronicleGraphics.com). You can even make an animated slideshow (movie) of what happened in the project, including major events with a textual (from emails or documents) or a spoken explanation (from recordings) with Supporting or proof documents, like email or spreadsheet artifacts. This movie will play the program back as it unfolded in reality. Even though MS Project can also create different groupings as we discussed (see page 299), OnePager has extra capabilities to represent the program in a single page with an attractive format. Some things that this application can do over and above what MS Project can do: ◆ Display multiple milestones within one row, as you can see in the previous chart, putting the text on the left for the first milestone on the left and on the right for the second milestone on the right, so the text never overlaps. ◆ Wider variety of coloring and bar shapes © PROJECTPRO CORP.

PAGE 323

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

◆ The ability to display actual progress bars (the narrow light [yellow] bars in the previous screenshot), which is sorely lacking in the timeline views in MS Project, as we will see in the next section.

6. Earned Value Report The Earned Value Management technique is perhaps best at summarizing a large program schedule in a one-page performance chart while providing an insightful assessment of the program. The Earned Value Management system has several performance indicators for both budget and schedule performance reporting.40 These indicators are widely accepted in government, defense and construction circles. The format of an Earned Value chart for a project typically looks like this:

Earned Value charts indicate how the progress and the spending compare to the original plan; this project is close to its target.

Notice that the value earned by the project team (Earned Value or BCWP - Budgeted Cost of Work Performed) is below the Planned Value (BCWS - Budgeted Cost of Work 40

For more information on Earned Value Management, see: - Guide to the PMBOK®, Sixth Edition, PMI. - Practice Standard for Earned Value Management, Second Edition, PMI - Earned Value Project Management, Fleming, Quentin W. and Koppelman, Joel, Third Edition, PMI, Newton Square, PA, USA, 2005. PAGE 324

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

Scheduled), which means the progress is behind schedule. The Earned Value is a little below the Actual Cost (ACWP - Actual Cost of Work Performed), which means the project is slightly over budget. From these values, you can calculate variances: Schedule Variance (SV) = Earned Value – Planned Value Cost Variance (CV) = Earned Value – Actual Cost If the variances are positive, life is good. If they are negative, things are bad and the project is in trouble. The variances are shown in the next bar chart:

In the screenshot, you can see two major projects (programs), one of them, the Satellite Radio Product Program, is in trouble in terms of progress. Both are doing well in terms of cost. You can also calculate indices from the three values of Planned Value (BCWS), Earned Value (BCWP) and Actual Cost (ACWP): ◆ Schedule Performance Index (SPI) = Earned Value / Planned Value ◆ Cost Performance Index (CPI) = Earned Value / Actual Cost If the indices are greater than 1, you are doing fine. If they drop below 1, you are in trouble. Looking at how the indices develop over time will give you an idea whether the situation is deteriorating or ameliorating. If an index drops below 1 and stays below 1 or, worse, keeps dropping, the trend is bad.

© PROJECTPRO CORP.

PAGE 325

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

Within MS Project itself you can easily create a one page report in a Task Sheet view that displays all Earned Value indicators. It could look like this:

Exercise: The Concept of Earned Value A simple Earned Value chart for a program may look like this:

How is the program doing? …………………………………………………………………………………………… ……………………………………………………………………………………………

Creating Earned Value Charts with MS Project’s Visual Reports The following lengthy procedure describes the steps to create an Earned Value chart using Visual Reports in Project and Excel (releases 2010 or later): 1. If you want to try out these steps using our exercise file, use the Forecast Scheduling exercise file 11B Relocation Project - Earned Value.mpp that will show some differences between AC, PV and EV! PAGE 326

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

2. In Project 2010, click ribbon Project, button Visual Reports. In Project 2013 or later, click ribbon Report, button Visual Reports. 3. Click button New Template; the Visual Report – New Template dialog appears: a.

 Excel

b. Data Type: Assignment usage c. Click button Field Picker and select under Available Fields the following fields: Actual Cost, Planned Value, Earned Value and Baseline Cost, click OK. Note that there is no difference between AC, ACWP and Actual Cost (apart from the theoretical difference); even when the rates that you pay are different from what you had planned to pay, the AC = ACWP. d. Click button OK and OK again to build the OLAP-cubes and to create the new report in Excel. 4. In Excel, format the report: a. In the PivotTable Field list: under Ʃ Values select the fields Actual Cost, Baseline Cost and Earned Value in this order, and under Time select Weekly Calendar; the Pivot Table starts to display values now. b. Drill into 2020 and into Q3 to display the weeks 32 – 39. c. Select all values (including row headings and column headings, but excluding the Totals columns) in the pivot table and Copy them. 5. Add the missing data: a. Create a new worksheet and click ribbon Home, bottom half of button Paste, item Paste Special, select  Values: the table is now pasted and is not any longer a pivot table. b. Delete the zeroes for Actual Cost and Earned Value. c. Add a row to the table and name it: Planned Values. For this new row, develop a formula to cumulate the Baseline Cost numbers the end of the project; this formula should look like this:

© PROJECTPRO CORP.

PAGE 327

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs Formula that will cumulate the Baseline Cost values to become the Planned Values.

Copied from B5

d. Add another row named Actual Cost and develop formula to cumulate the time-phased Actual Cost to Week 35 including. e. Remove all decimals for the numbers: select the numbers and click ribbon Home, button f.

.

Make sure you have automatic calculation on in Excel (ribbon Formulas, button Calculation Options,  Automatic to see the following results:

Data Actual Cost Baseline Cost Earned Value Planned Values Actual Cost

Week 32 4088 4088 4088 4088 4088

Week 33 6113 7238 10200 11325 10200

Week 34 563 563 15263 11888 10763

Week 35

Week 36

Week 37

Week 38

Week 39

41175 58925 16875 26513 11888 53063 111988 128863 128863 10763

6. Create the Earned Value S-curve chart with the following steps: a. Select the entire table (all numbers including the column headings and row headings) and click ribbon Insert, button Line Chart (not stacked) b. Remove the Baseline Cost and Actual Cost lines (the one that goes up and down) by right-clicking the line and selecting Delete.

PAGE 328

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

c. Add a title, the Data Table and add markers for each line, and the result should look like:

d. You can compare your results to the solution file: 11B Relocation Project Earned Value - Solution.xlsx.

Issues with Microsoft Project’s Earned Value Calculations First, you must realize the Earned Value calculations that MS Project performs are incorrect. These are the major issues I have been reporting to Microsoft since 2005: 1. Microsoft is still using the old terms: BCWS = Planned Value, BCWP = Earned Value, ACWP = Actual Cost. 2. You must enter a Status Date (on the Project ribbon) before MS Project will calculate Planned Values, and the status date must be later than the project start date. It is odd that the status date is needed for planned values which can be calculated for the entire program a soon as the baseline is set: They are cumulated Baseline Cost numbers. 3. The Planned Values (BCWS) are only calculated up to the status date, whereas you need planned values to the program end date to create a complete performance baseline, the target. As a workaround, you can take the time-phased Baseline Cost values and cumulate them yourself in MS Excel and chart them. © PROJECTPRO CORP.

PAGE 329

9

Chapter 9 Reporting on Large Schedules

Forecasting Programs

4. You will not get any Earned Value (BCWP) from MS Project for tasks you completed ahead of schedule (i.e., with baseline dates that are after the status date). Trap! This is an error from Microsoft that tends to understate the real value you earned in your program and make you look bad as the program manager: Your Earned Value can fall behind but never catch up. You should, of course, get paid (and earn value) when you completed work, regardless when that work was supposed to be completed, either in the past or in the future. 5. MS Project allows you to delete tasks too easily when you perform Earned Value. Deleting tasks inadvertently removes the baseline values as well, which affects the charts over time and wrecks the trend charts. MS Project should protect the cost performance baseline much better than it does currently. Even the feature new in 2010 Pro that allows PMOs to protect the baseline schedules does not protect against inadvertent deletion of tasks. Tasks should only be deleted after making an impact analysis, submitting a change request form and getting an approval on the change request. Tip► Issues 3 and 4 can be worked around simply by changing the Status Date temporarily to the project Finish date. You can then generate reliable Earned Value reports with MS Project itself. Other issues remain if you use (advanced) features like: deleting baselined tasks, Cost resources, Accrue At: Start or End, actual hourly rates different from planned hourly rates, Inactive tasks. Work contours. For these reasons, we recommend you purchase an add-in or application if you need robust Earned Value reports (see next section).

Earned Value Add-Ins and Software Applications If you want to have an easier life and happier stakeholders, we recommend you purchase one of the following applications: ◆ Affordable Earned Value solutions that are add-in applications to Microsoft Project:  CurvesPro from ProjectPro, see www.projectprocorp.com under Software.  Kidasa, see www.kidasa.com ◆ High-Quality Earned Value solutions to meet your Earned Value needs. If you must meet the ANSI 748 standard on Earned Value 41, which is common on USGovernment sponsored capital investment programs, we recommend you purchase one of the following standalone software applications:  Deltek, see: www.deltek.com: Deltek has a long reputation of deploying Earned Value and has the widest choice of EVM-applications: Cobra, MPM or Winsight 41

Earned Value Management System (EVMS), SAE EIA748C-2013, American National Standards Institute (ANSI), 2013, www.ANSI.org PAGE 330

© PROJECTPRO CORP.

Forecasting Programs

Chapter 9 Reporting on Large Schedules

 DecisionEdge: see www.decisionedge.com  PlanView, see: www.planview.com  Oracle Primavera, see www.oracle.com: they bought the ProSight application The latter two are application suites that can replace Microsoft’s suite entirely. We recommend you request an online demonstration for some of these applications or suites to find how they compare to each other. Here is an example of the output from CurvesPro:

9

© PROJECTPRO CORP.

PAGE 331

Forecasting Programs

Chapter 10 Monitoring Progress in Projects of a Program

Chapter 10 Monitoring Progress in Projects of a Program

Learning Objectives After this chapter, you will: ◆ Be aware of two options to update the schedule:  Update tasks  Update assignments in a project schedule using paper or electronic timesheets ◆ Decide which update method makes the most sense for your particular program ◆ Determine if the projects in a program are up-to-date ◆ Monitor the progress in projects and determine corrective actions

© PROJECTPRO CORP.

PAGE 333

10

Chapter 10 Monitoring Progress in Projects of a Program

Forecasting Programs

My Program Feels Like Being in a Meteor Shower Bob and Nob are having a coffee in the local hangout. Bob starts the conversation. “Well, we have a new boss! Donald didn’t last long … only 7 months!” “Yeah, they come and go these days!” “Donald had big ideas. He wanted new hiring practices and a big new office, and he lobbied for lower taxes!” “No lack of ideas there.” “What did he really accomplish?” “Not much!” “But he did get his big departure bonus!” “Yeah, I call that ‘seagull management’. The seagull swoops in, shits on you, steals your bread and flies away!”

PAGE 334

© PROJECTPRO CORP.

Forecasting Programs

Chapter 10 Monitoring Progress in Projects of a Program

Program Manager’s Responsibility Program managers and program support staff typically do little updating of the schedule themselves, because they have delegated most if not all responsibility for scheduling to the project managers. Sometimes, the program support staff keeps the responsibility for the so-called ‘backend schedule’ which, depending on the type of program, covers: ◆ All the assembly of the product, ◆ The integrations of the new business system, or ◆ The user acceptance tests by the end-user is managed. The program manager’s focus is then restricted to some distinct responsibilities when it comes to keeping the program up-to-date: ◆ Decide which update method should be used by the project managers and put in place a system of checks and balances to ensure that this method is implemented rigorously. ◆ Monitor the progress in the program: Analyze the latest updates from the project managers and assess their compounded impact on the program as a whole and on major milestones coming up. ◆ Re-optimize the program: Identify the (new?) Program Critical Path and (new?) Critical Paths leading into the next major milestones, analyze the total amount of slippage on the major milestones and program finish milestone, and develop what-if scenarios to compensate for the slippages experienced. We discussed this previously in chapter 8 (see page 271) and will not discuss it here. In this chapter, we will focus on the responsibilities in the first two bullets.

10

Task Update versus Assignments Update For the how-to steps of updating project schedules, we also refer to the Forecast Scheduling book. This section is a summary of the Up-to-Date Schedule chapter 11 in

© PROJECTPRO CORP.

PAGE 335

Chapter 10 Monitoring Progress in Projects of a Program

Forecasting Programs

the Forecast Scheduling book, which will help a program manager determine what type of updating to do in the program and what to communicate to the project managers.

Assignments Updated by MS Project

You Update Tasks actual start actual duration remaining duration actual finish

actual hours remaining hours

by task

by resource by day or week by assignment

Tasks Updated by MS Project

You Update Assignments

There are two different strategies for updating your schedule: updating tasks or updating assignments. An assignment is always a combination of a task and a resource. Since one task can have multiple assignments, assignments are on a more detailed level than tasks.

◆ Updating tasks This means updating a maximum of four fields for each task; you need to choose between duration (business days) or work (effort in person hours): Actual Start Actual Duration

Actual Work

Remaining Duration

Remaining Work

Actual Finish ◆ Updating assignments When you update assignments, you typically update every assignment of the resource. For this large amount of data, you need an electronic timesheet to capture and transfer the data into the schedule. We recommend you collect:  Actual hours by day to be entered into the timescale field Actual Work Note that there is also an Actual Work field in the spreadsheet that displays the total of all the timescale entries; we are not referring to that field here.  Remaining hours by assignment to be entered into the field Remaining Work in the spreadsheet. The illustration at the start summarizes the two ways of updating the schedule. If you update tasks, MS Project can update the assignments for you. If you update the assignments from the timesheets, MS Project can update the tasks. MS Project will do this for you if you maintain the check on the option ribbon File, button Options, tab

PAGE 336

© PROJECTPRO CORP.

Forecasting Programs

Chapter 10 Monitoring Progress in Projects of a Program

Schedule,  Updating task status updates resource status checked. If you clear this option, you can update tasks and update assignments in parallel, if you so desire. Updating the tasks is quick and easy. You only need to enter actual and remaining durations, and in most cases, you can do that with the mouse. You can also enter the Actual Start date for the task, which is the date on which the work started. MS Project arbitrarily calculates and spreads the actual hours in the timescale. Because of its arbitrary quality, this method is less precise than updating assignments by entering actual hours worked from timesheets, but if you update regularly, it is precise enough, even for Earned Value Management. As you go along, the precision increases because differences average out. Furthermore, there are options in ribbon File, button Options, tab Advanced that can improve the precision of the automatic spreading. Updating assignments requires more numbers to process at every update and, therefore, more work during the busy project execution. To illustrate this, consider the following situation. You have a schedule with 300 tasks and 10 weekly reporting periods, which means that every week you must update an average of 30 tasks, 20 of which are typically completed during that week. If you do a task update, you must: ◆ For the 20 completed tasks, you collect their actual duration equal to at least 20 actual durations. ◆ For the 10 tasks in progress, you collect actual duration and remaining duration equal to at least 10 actual durations and 10 remaining durations. The grand total for updating tasks, therefore, is 20 + 20 = 40 pieces of data. For an assignment update, we will have to make more assumptions to calculate the number of data points to process at each update. Let’s assume the average task duration is 4 days and the average number of resources per task is 1.5: ◆ For the 20 completed tasks: 20 tasks * 4 days * 1.5 resources = 120 pieces of data ◆ For the 10 tasks in progress: 10 tasks * 2 days progress * 1.5 resources = 30 pieces of data ◆ For the 10 tasks in progress: 10 * 1.5 resources = 15 remaining work estimates The grand total for updating assignments is: 120 + 30 + 15 = 165 pieces of data. Tip► As you can see, if you choose to update assignments instead of tasks, you are processing four times as much data during project execution when you are already very busy managing the project.

© PROJECTPRO CORP.

PAGE 337

10

Chapter 10 Monitoring Progress in Projects of a Program

Forecasting Programs

Update Tasks If… We recommend you use the strategy of updating tasks in these instances: ◆ If you don’t have an electronic timesheet system in place. Paper timesheets will drown you in data. Data entry takes (too) much effort, and often project managers can’t keep up, even if they need to review the data only on a weekly basis. We haven’t even mentioned the double data-entry and its probability of errors. Electronic timesheets do cost money, even though Microsoft now has a special low rate for team members who only need to fill in timesheets (in Project Web App – PWA) and contribute to the risk and issues register (by accessing the Project Site). ◆ If updaters do not have access to Project Online or Project Server (PWA) Often when there are many vendors involved in the program, they cannot be given access to Project Online or Project Server, because of security considerations, high cost or the temporary nature of the access. ◆ No transfer of update data into schedules If your timesheet system does not allow you to automatically transfer both actual hours worked and remaining work estimates into your project schedules in MS Project. Trap! We have observed that too many project managers stop updating their schedules at some time during the project execution, because they: ◆ Fail to get enough information from their team members, or ◆ Drown in the flood of data, or ◆ Discover the tedious data entry generates so many errors that sorting out the mistakes takes too much time.

If you abandon updating your schedule, you lose the model that provides you with up-to-date forecasts and allows you to do what-if scenarios to determine the best course of action when things slip. Slowly but surely, you lose your grip on the project and program. It is better to have a less precise grip than no grip at all.

Update Assignments If… Pro Project Professional with Project Online or Project Server provides an electronic timesheet system that supports updating assignments. Project Server’s electronic timesheet offers the following benefits: ◆ Collecting status from your team members is much easier.

PAGE 338

© PROJECTPRO CORP.

Forecasting Programs

Chapter 10 Monitoring Progress in Projects of a Program

◆ Automatic transfer of data back into your schedule is possible, which prevents double data entry. Many timesheet systems currently on the market do not put the update information back into the schedules and are, therefore, not useful for project managers. These timesheet systems may service HR-systems, the salary system or accounting, but not project management. ◆ Submitting performance reports to executives and clients is much easier. Tip► If you have Microsoft Project Online or Project Server (or an equally efficient electronic-timesheet system), we recommend you use the strategy of updating assignments. In any other situation, we recommend updating tasks!

How Gantt Chart-Literate Are You? If you have opted for either task updates or assignment-updates, you will see that the project schedules in the program are being updated. In this section, we will see what things you, as a program manager, need to look for after the flood of update data has arrived in the project schedules. During a training session with executives of a Fortune 500 company, I noticed – to my astonishment – that several executives couldn't interpret Tracking Gantt charts correctly. They had just invested $400,000 in purchasing and installing Microsoft Project Server, the perfect time for a select group of well-educated, highly paid and time-pressured people to try making sense of charts that their new project management information system produced straight out-of-the-box. Unfortunately, several of them failed the test, and I realized that all program managers need to learn the skills that follow. Many of them are intuitive, but some aren’t. Before we start, let’s make sure that we all use the same terms, so we all start from the same starting line, making this virtual 400m hurdle race as fair as possible. Please, refer

© PROJECTPRO CORP.

PAGE 339

10

Chapter 10 Monitoring Progress in Projects of a Program

Forecasting Programs

to the next illustration, in which you see the Tracking Gantt bars reflecting one project in the program:

Each project in the program can be represented with the bars shown above, and there are many data points reflected in this image: ◆ The Data Date called Status Date in MS Project is the date on which we report the performance for the project (latest progress and forecasts). ◆ The Actual Duration (dark blue in MS Project) reflects the actual progress of the project. On the project-level it, is a value that MS Project calculates from the lower levels of detail (i.e., the updated tasks or assignments). We explained the calculation earlier (see page 303). It is important to understand that this calculation allows us to draw important conclusions from the Actual Duration indicator:  If the end of the Actual Duration task bar is flush with the Status Date, the schedule is up-to-date.  If the end of the Actual Duration task bar is earlier than (i.e., to the left of) the Status Date, the schedule is out-of-date or not updated correctly (remaining work left scheduled in the past).  If the end of the Actual Duration task bar is later than (i.e., to the right of) the Status Date, the schedule is incorrectly updated, with tasks marked as complete left scheduled in the future (where they certainly were not completed unless that project manager has a time machine!). Trap! Some people see Actual Duration as the time that has passed in the project as per the Data Date (PMBOK Guide®), or Status Date (Microsoft Project), in which case the Actual Duration task bar is always flush with the Data Date / Status Date. PAGE 340

© PROJECTPRO CORP.

Forecasting Programs

◆

◆ ◆

◆ ◆

◆ ◆

Chapter 10 Monitoring Progress in Projects of a Program

Even though conceptually this is correct, it is not the way MS Project works. The Actual Duration would be a useless indicator in that case. The Remaining Duration (light blue in MS Project) is an estimated duration to complete for the project and is re-estimated and reviewed on each periodical data date. This remaining duration should be reviewed at each status cycle and revised often. It should include all experiences and insights collected so far in the project, such as:  Problems with the technology, systems, equipment, facilities, etc.  Actual skill level of the team members who do the work as opposed to the skill level promised by resource managers during the planning phase.  The actual performance of suppliers, vendors and subcontractors.  The number of times that the client changes the requirements, which should also be reflected in a revised Baseline Duration. Duration of the project = Actual Duration + Remaining Duration The Duration will be regularly recalculated by MS Project because of revisions to the Remaining Duration. The Baseline Duration is the amount of time to which the client (or sponsor) of the project has agreed. The Baseline Duration is the target duration of the project and, therefore, the yardstick against which to measure the performance of the project in terms of time. The Baseline Duration can best be compared to the Duration to assess if the project will take longer or not. The Actual Start date is the date on which the project really started. Typically, this is the date on which the first work listed in the work breakdown structure (WBS) of your project was performed. The Baseline Start is the date on which the project was supposed to start. The Baseline Start can best be compared to the Actual Start to assess if the project started on time or not:  If Actual Start is later than Baseline Start, the project started late. This creates an immediate slip in the project from which it is hard to recover. Project managers should make sure their project starts when it is supposed to.  If Actual Start is equal to the Baseline Start, the project started on time.  If Actual Start is earlier than Baseline Start, the project started early. This can be problematic if project managers start their projects before the gunshot (i.e., before they were supposed to start). The Finish date is the currently forecasted date on which the project is expected to end. The Baseline Finish is the date on which the project was supposed to end. The Baseline Finish can best be compared to the latest forecasted Finish date to assess if the project will finish on time or not:  If Finish is later than Baseline Finish, the project will likely finish late.

© PROJECTPRO CORP.

PAGE 341

10

Chapter 10 Monitoring Progress in Projects of a Program

Forecasting Programs

 If Finish is equal to the Baseline Finish, the project is forecasted to finish on time.  If Finish is earlier than Baseline Finish, the project is forecasted to finish early. This is normally advantageous to all stakeholders involved in the project (except perhaps the team members) and should be encouraged always (provided that the program manager always carefully examines the proposed Baseline Durations and verifies that they are not overstated by project managers). To keep you interested and allow you to determine your own level of Gantt Chart literacy, I will present you with some charts and ask you to interpret them before giving you my interpretation.

Competitors, On Your Mark … Following are several small Gantt Charts for you to interpret. The correctness of your interpretations can be checked against the solution that we have captured in the download files called Forecasting Programs – book download files that accompany this textbook. 42 At this point, we should all be at the same starting line. The starter raises the gun and fires the starting shot for this interpret-the-progress challenge: We will start with an easy first hurdle. What does the following Tracking Gantt chart mean?

What is the performance of this project? …………………………………………………………………………………………… …………………………………………………………………………………………… The only way to interpret Figure 2 is as follows: The schedule of this project is up to date and the project is on schedule. The Actual Duration is running all the way up to the Data Date, and the current forecasted Finish date is still where the baseline finish date is.

42

You can download these files from our website at www.ProjectProCorp.com under Books.

PAGE 342

© PROJECTPRO CORP.

Forecasting Programs

Chapter 10 Monitoring Progress in Projects of a Program

I hope you and I can quickly agree on this first one, because the hurdles are only going to get higher from here on. Here's the next one:

What is the performance of this project? …………………………………………………………………………………………… …………………………………………………………………………………………… In the previous illustration, we can see that the project didn't start when it was supposed to start (Actual Start later than Baseline Start). This has an impact on our Finish date, which is now later than the Baseline Finish. A good question to ask here: Is the project diverting from the agreed upon period, the Baseline Duration? When you compare the length of the bar Duration with the length of the bar Baseline Duration, you'll see that they're the same size, and from that perspective there's no problem. If you're not sure, check the exact numbers in the table: Baseline Duration and Duration are both 20 days. At this point, most of my executives were still in the race. I hope you also passed this hurdle; it was still an easy one, but that will change with the next one:

10 What is the performance of this project? …………………………………………………………………………………………… …………………………………………………………………………………………… The hurdle in the previous illustration tripped several of my executives. They stated that this project was on schedule by looking at the Actual Duration bar only. As you can see, the bar for Actual Duration is, indeed, running all the way up to the data date, which to some of these executives meant that the project was on schedule. I thought to myself: “They are overpaid for their position, because they overlooked an important detail!” Other executives stated that this project was running late by looking at the

© PROJECTPRO CORP.

PAGE 343

Chapter 10 Monitoring Progress in Projects of a Program

Forecasting Programs

Finish date, which is now later than the Baseline Finish date. These executives are earning their pay. I pointed out to all executives that the Actual Duration is just what it is and what it always should be: The Actual Duration should always run all the way up to the data date. If you don’t agree with this statement, please remember that the definition of Actual Duration was straightforward: How much time has passed by in the project? There's no indicator of performance in an Actual Duration on the summarized level of a project. On the project level, the Actual Duration always changes with time simply passing by. However, there's a measure of performance in the Remaining Duration on this aggregation level. The Remaining Duration is extending beyond the Baseline Duration, and the project is forecasted to take longer than it should. You can also glean this from the bars by comparing the Finish date with the Baseline Finish date and from comparing the Baseline Duration (20d) with the currently forecasted Duration (25d). Are you still in the hurdle race? Only half of my Fortune 500 executives were still in the race at this point; elsewhere, injured bodies lay scattered along the course.

Getting at the Truth of a Project Let’s take the next hurdle, which turns out to be even more challenging. What does the following Tracking Gantt chart mean? Figure 5

What is the performance of this project? …………………………………………………………………………………………… …………………………………………………………………………………………… This is the first situation in which the Actual Duration doesn't run up to the data date. This hurdle turned out to be the hardest to clear. So, how should we interpret this strange situation? How can time pass by slower than it really does? Well, it sometimes happens that project managers did not update their schedules in the last period, or progress in the project is slower than it should be according to the schedule.

PAGE 344

© PROJECTPRO CORP.

Forecasting Programs

Chapter 10 Monitoring Progress in Projects of a Program

Unfortunately, you can't tell from the chart which case is true without asking the project manager some clarifying questions. If the project manager isn't available to consult, the only conclusion you can draw from this chart alone is that the schedule is not updated or not properly updated. So, what we see here is that Actual Duration is only an indicator for the reliability of the latest update. If the Actual Duration ends before the data date, there are two possibilities: ◆ There may be unfinished work scheduled before the data date that should be brought forward to the future. The Finish date is too soon and biased optimistically. The schedule isn't reliable, and the forecast dates are too early. ◆ The schedule may be out-of-date, and we should ask the project manager to update it. This type of situation – which isn't uncommon – has led, I believe, to the marked increase in adoption of Earned Value performance measurement. Earned Value doesn't care if the Actual Duration ends before, on, or after the data date. It always provides solid forecasts for the project. Earned Value forecasts are relentlessly revealing and reliable as early as 15% into the project duration, according to empirical research from Quentin Fleming and Joel Koppelman as captured in their authoritative textbook, Earned Value Project Management. However, we don’t necessarily need Earned Value to provide us with accurate forecasts if project managers update their schedule correctly. A correctly updated schedule has: ◆ All completed work scheduled in the past (i.e., before or to the left of the data date, often that day), when the work really happened, and ◆ All still-to-be completed work scheduled in the future (i.e., after or to the right of the data date, often today), when it will happen (if at all). If you make sure that the network logic in the schedule is complete and correct, your schedule by itself will always produce accurate forecasts. This is the point I first made in 2000 with the publication of the first edition of my first book series, Dynamic Scheduling with Microsoft Project. If you set up your schedule properly, the schedule will give you accurate and reliable forecasts by itself.

Back in the Executive Boardroom... There was a telling silence among our executives as they waited to hear from me before they were willing to jump this oddly shaped hurdle and explain the previous Tracking Gantt chart. I lost another couple of executives on this hurdle; more injured bodies were strewn along the course. This leads me to pose these questions to you: Are your executives Gantt Chart literate? How about you?

© PROJECTPRO CORP.

PAGE 345

10

Chapter 10 Monitoring Progress in Projects of a Program

Forecasting Programs

Exercise 1: What is the Performance of this Program? Please provide an explanation of the performance of the following program consisting of three projects, including suggested action items for the program manager. To keep it simple, you should assume that each project manager has complete and correct network logic in his or her schedule, so the schedule by itself forecasts the project: 43

Let’s see who can clear this final hurdle and win the race: What is the performance of the projects in this program? …………………………………………………………………………………………… …………………………………………………………………………………………… …………………………………………………………………………………………… ……………………………………………………………………………………………

43

You will find the answers to this question in the download file called Forecasting Programs book download files that you will find on our website www.ProjectProCorp.com under Books. PAGE 346

© PROJECTPRO CORP.

Forecasting Programs

Chapter 10 Monitoring Progress in Projects of a Program

Exercise 2: Is this Program Schedule Up-To-Date? Here is the Tracking Gantt Chart of an 11,000 task, real-life program that has been updated as per the data date shown in the following screenshot:

The Tracking Gantt chart is an excellent place to check if the sub schedules are up-todate. If the progress bar on the project summary tasks does not run all the way up to the status date (vertical dashed line), the sub schedule is not up-to-date. This can mean one of two things: ◆ The project manager is behind in updating the schedule. ◆ The schedule is incorrectly updated with remaining durations left scheduled in the past (to the left of the data date, the status date) In neither situation can the forecasts be trusted. In this situation:

10

1. Which project managers should the program manager go and talk to? …………………………………………………………………………………………… 2. In which order? …………………………………………………………………………………………… 3. What should the message be to each of these project managers based on their schedule update? …………………………………………………………………………………………… ……………………………………………………………………………………………

© PROJECTPRO CORP.

PAGE 347

Forecasting Programs

Chapter 11 Summary

Chapter 11 Summary

Throughout this book we have made many recommendations to show how you can model the reality of your program and forecast it continuously. We present here an overview of the most important recommendations.

11

© PROJECTPRO CORP.

PAGE 349

Chapter 11 Summary

Forecasting Programs

Doing Things as Slowly as Possible for as Long as Possible Bob goes for coffee to the local watering hole. The place is busy, and he ends up sharing a table with a gentleman of possible retirement age who appears to be fatigued by the walk. ”Enjoying your coffee?” Bob asks. ”Yes, I’m really enjoying it!” ”My name is Bob. What’s yours?” ”My name is Sean Low.” ”Please to meet you, Sean. Are you tired or re-tired?” ”I’m still tired AND retired from my government job!” ”Have you gotten used to being retired yet?” Well, I’m doing things as slowly as possible for as long as possible!” ”It must have been very different while you were working, wasn’t it?” ”No, it was the same …” the man replies with a subtle smile. Bob tries to figure out if he had just heard a joke or a revelation of truth from mister S. Low.

PAGE 350

© PROJECTPRO CORP.

Forecasting Programs

Chapter 11 Summary

Program Management Have you averted schedule conversion issues through explicit agreements in vendor contracts? Because of problems with converting files, we strongly recommend against combining: ◆ Microsoft Project schedules with CA Clarity as the PPM-system ◆ Microsoft Project with Oracle Primavera as the PPM-system ◆ CA Clarity schedules with Microsoft Project Online / Project Server as the PPMsystem ◆ Primavera schedules with Microsoft Project Online / Project Server as the PPMsystem

Scheduling Approach Have you identified the recommended scheduling approach for the projects in your program by analyzing each project to identify its dominant ideal and constraint? We presented a framework called the Project Ideals and Constraints matrix (PIC-matrix) with which you can analyze your situation. The PIC-matrix led us to the following recommendations: ◆ We recommend Agile (AG) when knowledge is constrained or when the ideal is the highest satisfaction or highest scope & quality factor, because Agile is a very customer-oriented approach. ◆ We recommend Critical Chain (CC) when time is the project ideal, except when cost is the constraint. CC is a very time-oriented approach to scheduling and has been proven to shorten projects, however, it is not suitable as an approach to control cost. ◆ We recommend using Critical Path Method (CPM) when time is the dominant ideal or constraint. ◆ We recommend Earned Value (EV) approach when lowest cost is the project ideal, but notice that we always recommend it to be combined with CPM or RCP. We also recommend EV when cost is the biggest constraint. EV is strong in the cost ideal and constraint, because EV measures cost. The irony is that EV is costly to implement. Earned Value is the only approach that provides integrated time and cost control by itself. Thus, EV is also appropriate when time is the ideal and cost is the constraint. ◆ We recommend Resource Critical Path (RCP) approach in any resource-constrained project. ◆ We recommend Earned Work (EW) when lowest-cost is the ideal (except when knowledge is the constraint) or when the cost is the constraint as well as when resources are constrained. ◆ We recommend enhancing the scheduling approaches with simulations (SIM) whenever risk is the dominant ideal or constraint. Simulation of schedules can © PROJECTPRO CORP.

PAGE 351

11

Chapter 11 Summary

Forecasting Programs

quantify risk in a project in terms of time and cost. In a Risk-ideal and Riskconstrained project, you can only do simulation or apply other risk management practices not discussed here. Have you leveraged the synergy between certain scheduling approaches in your program? ◆ The Critical Path (CPM) and Earned Value (EV) approaches are made for each other and often used together on projects. The CPM is very time-oriented and provides ideas on how to improve the time dimension, whereas the EV approach is very money-oriented. The Practice Standard on Earned Value from PMI® even states that Earned Value should always be done in combination with Critical Path, because if you make a lot of progress on non-critical activities and none on critical activities, the EV indicators may be positive but the project will be late. ◆ The Resource-Critical Path (RCP) and Earned Value (EV) approaches are made for each other in resource-constrained situations where CPM fails. A resource-loaded schedule drives cost, and the cost-curve will be very accurate. Once a resourceloaded schedule is workload-leveled, it is ready to be baselined. The baseline schedule can then be used to establish your cost performance baseline (Planned Values) for Earned Value Management (EVM). ◆ Earned Work and Earned Value use similar charts and progress indicators, so you can easily combine them. ◆ Simulation can be combined with any scheduling approach and will make your forecasts more accurate in general. Have you avoided problems that occur when you combine two scheduling approaches that are incompatible for the projects in a program? ◆ The Agile (AG) approach, as the only adaptive scheduling approach, cannot be combined with any other (predictive) approach. The AG-approach allows constant changes to the WBS, which are not allowed in other approaches, even though we do present a way of making this combination work if both parties are willing to live with certain compromises (see next section). ◆ You cannot combine CC with CPM- or RCP-approaches, because their bases for estimation are different:  The CPM and RCP-methods often use 90% confidence level estimates, because no effort is made to squeeze 50% estimates out of team members. A 90% confidence level means that tasks come in at or ahead of their original estimate in 90% of the cases and run over in the remaining 10% of the cases.  The CC-approach always expects you to use 50% confidence level estimates. ◆ You cannot combine an Earned Value approach with a Critical Chain approach. Critical Chain schedules tend to be very aggressive, and creating an Earned Value performance baseline based on a very aggressive schedule would cause constant and huge schedule slippages to be indicated in the Earned Value status reports. As a PAGE 352

© PROJECTPRO CORP.

Forecasting Programs

Chapter 11 Summary

result, you would be running behind schedule and over budget for the life of the project. Also, it is too difficult to allocate values to be earned to feed buffers and project buffer line items that are artificially inserted in a CC-schedule.

Agile and Critical Path Method (CPM) If you are you in a program where you it seems best to combine Agile in one or more project schedules with Critical Path in other schedules, such as in new product development program with a software component (Agile) and a hardware component (Critical Path): ◆ Are the Agilists willing to make the following compromises?  Agilists will have to complete their backlog as soon as possible (i.e., do thorough ‘backlog grooming’ upfront) and pay more attention to this than they would otherwise. A complete backlog will allow you to forecast the entire project, not just the next sprint.  Agilists will have to estimate all items in their backlog (using their own way of estimating, like Fibonacci estimating), which should not be a big deal.  Agilists will have to identify all relationships between their user stories and/or activities (just like in a Critical Path schedule) including all items in their backlog. ◆ Are the forecasters (Critical Path) willing to make the following compromises?  Forecasters must allow Agilists to have their own WBS view organized by sprints (in addition to their own deliverable-oriented WBS).  Forecasters must allow Agilists to continue estimating in their own way (such as Fibonacci points) and do the extra work to convert those Agile points into person hours.  Forecasters should allow Agilists to continue adding and removing items from the backlog without insisting they fill out Change Request forms. This is not a big compromise unless you also must do Earned Value Management (EVM), which requires a complete WBS upfront and formal change requests after that. Even if you must apply EVM, you can still allow Agilists to add and remove items from the backlog if they exchange items of equal value (points) every time. To add a new feature (user story), the client will have to drop an item of equal value (points) that is currently in the backlog. In this way, you can keep stability and continuity in your forecasts.  Forecasters should accept a few more Start-No-Earlier-Than (SNET) constraints into their schedule, because each activity needs to be forced into a sprint (i.e., month) with a fixed start and fixed end date (rather than letting it be scheduled freely by the Microsoft Project schedule engine). This compromise is somewhat painful, because SNETs can fragment the Critical Path (for more information on this issue, please refer to my other textbook Forecast Scheduling, in which I © PROJECTPRO CORP.

PAGE 353

11

Chapter 11 Summary

Forecasting Programs

explain how to handle this). Add-ins can handle these situations gracefully and quickly, like our own PathsPro. 44 These compromises will make it possible to integrate both types of project schedules into a single integrated master schedule for the program.

Organizing the Program Central repository and configuration management: ◆ Are you keeping all project schedules in one central place? ◆ Are you applying the principle of maintaining unity of data (i.e., no replication of any project data)? ◆ Is there always a single version of the truth in your program management information system? Is it always clear which version of a document is the latest? Is your program ‘in control’ from a planning perspective? ◆ Have you created at least 10 major milestones in your program? ◆ Have you protected the two major milestones that are coming up next with a time contingency (buffer) in such a way that you can attain the milestone with a confidence level of 90%? Each major milestone needs a time contingency (buffer) to ensure a 90% on-time delivery of the major milestone. You need to determine the size of the buffer through a scientific and reliable method; we recommend using Monte Carlo simulation for this purpose. ◆ Have you protected the overall program completion milestone with a time contingency that, at the start of the program, provides a 50% confidence level that your program will be completed on time? Again, we recommend you use Monte Carlo Simulation to verify this. As the execution of the program progresses, the confidence level should slowly but surely grow; the level of confidence should reach 90% when the next major milestone is the program completion milestone. ◆ If these criteria cannot be met, have you communicated with the stakeholders and negotiated for more time in your program as soon as you became aware of the necessity? Have you created enough project schedules in your program? The following numbers apply to IT-related programs; in construction programs, these thresholds may be higher:

44

See our website www.ProjectProCorp.com under Software.

PAGE 354

© PROJECTPRO CORP.

Forecasting Programs

Chapter 11 Summary

◆ 0-1,000 line items: We recommend you consider breaking up a schedule into sub schedules once the number of tasks goes over 1,000 line items. ◆ 1,000-2,000 line items: If your schedule grows from 1,000 to 2,000 line items per calendar year, your schedule will become a full-time job. Looking after such a large schedule means you create and maintain it, plus you need to interact with all team members and project stakeholders. ◆ >2,000 line items: If your schedule grows over 2,000 line items per calendar year in resource-loaded IT-schedules, it is no longer possible for one scheduler to maintain it. The workload is too great, and information-overload sets in. For these two reasons, the schedule will need to be broken up into sub schedules, even in organizations that tend to be very centralized by nature, such as military, pharma, banking and emergency-response. As program manager, have you asked your project managers for the right type of project schedule: a time model, a workload model or a cost model? ◆ The right type of model depends on the scheduling maturity of the project manager: You cannot ask novice schedulers to create a cost model, the most difficult and intricate model of project. We recommend that people start with modeling the time of their project first, then try to model workloads, and, eventually complete their skillset with modeling costs. ◆ The right type of schedule also depends on your needs as the program manager: If you are in a time-constrained program, a time model may suffice. If you expect that limited access to resources will play a significant role in your program, a workload model may be the right model. If cost is the dominant constraint, a cost model will be needed, which may require major training for project managers. ◆ You can mix and match by creating time models for some projects and workload and cost models for some other projects. Having time models for all projects in a program is the absolute minimum requirement for creating integrated master schedules (IMS). Workload and cost models contain a time model. Have you at least attempted to break down you program using a benefits-orientation? Programs are about benefits realization and, ideally, the first breakdown level should be the benefits the program seeks to attain. If this strategy allows you to create a logical hierarchy with benefits at the highest level, this is what we would recommend, since it keeps everyone focused clearly on benefits realization. However, in practice, we have often found that benefits and projects in a program have a many-to-many relationship: ◆ One benefit may require more than one project. ◆ One project can serve more than one benefit. If you find this to be the case, using benefits as the first level of breakdown will not work well. If it does work, we recommend it.

© PROJECTPRO CORP.

PAGE 355

11

Chapter 11 Summary

Forecasting Programs

Program Breakdown Structure: ◆ Can you summarize all items on a level within a branch with one word? To keep the levels pure, keep these labels in the forefront of your mind when breaking down the work and producing multiple items on each level. ◆ Have you kept the level of projects (subprograms) in your program breakdown structure? ◆ Have you kept a level of Deliverables inside the work breakdown structures of all projects in the program? Have you tried to minimize the number of cross-project dependencies between the projects in your program? ◆ Managing the cross-project dependencies is one of the biggest challenges in managing the program in its entirety; therefore, we recommend you minimize the number of cross-project dependencies to create, monitor and manage. Teams often use ‘We were waiting for something’ from some other team as an excuse for a lack of progress. ◆ Create teams that are as autonomous as possible, so teams can make progress even if the rest of the program is slowing down or halted. Obviously, projects within a program cannot be entirely independent from each other, since they all need to come together prior to the program finish milestone (or program back-end schedule). Have you applied the best-practice checks from a scheduling methodology to all projects in your program? There are several scheduling methodologies around: ◆ Forecast Scheduling by Eric Uyttewaal (which we used in this textbook): This methodology consists of 86 checks:  49 for time models  75 for workload models  86 for cost models ◆ Practice Standard for Project Scheduling, 2nd Edition from PMI ◆ The 14-point checklist from the Defense Contract Management Agency (DCMA) ◆ The USA GAO Schedule Assessment Guide This guide has about 150 checks for program schedules catered to capital investment programs of governments. Have you Created Natural Checks and Balances in your Program Breakdown Structure? The ‘taxpayers’ cannot be on the same team as the ‘tax inspectors’. As citizens, we all know what that would lead to: No taxes being paid to government at all. I call them natural checks and balances, because there are many examples from nature for this. For PAGE 356

© PROJECTPRO CORP.

Forecasting Programs

Chapter 11 Summary

instance, if farmers eliminate all wolves that eat their cows, deer will increase in numbers that will eat their crops. There needs to be a balance. Have you used a single breakdown orientation of deliverables in the PWBS? The WBS-field in MS Project is called ‘Task Name’ in MS Project. Use a single breakdown orientation consistently throughout the entire Program Work Breakdown Structure (PWBS) on each level down. A single orientation is clean and can easily be understood by any stakeholder or outsider. Many programs are visible to society at large, and therefore it is important that an average citizen can understand your PWBS without further explanation from you. Multiple orientations, such as phase- and deliverableorientations within one PWBS, often require a lot of explanation. Also, it is often difficult to be consistent with multiple orientations at each level of the PWBS, particularly when two orientations start to fight with one another. This happens, for example, when you can only identify one deliverable for a certain phase. (You are supposed to have at least two deliverables for each phase, otherwise you should not create the next lower level!). In this case, we recommend you drop one of the two orientations entirely; for instance, you should drop the phase-orientation in the previous example and keep the deliverable-orientation. The concept of Phases is fuzzy; phases need to be defined and described carefully before they start to make sense to insiders or outsiders. Have you avoided mixing multiple breakdown orientations within one level? Avoid mixing breakdown orientations within one level. We recommend against mixing two different orientations on one level in the breakdown structure as much as possible, because it is very hard for people to understand when there are two things of a distinct nature side-by-side on one level in your PWBS. Multiple breakdown orientations often start to fight with one another and cannot live peacefully within your PWBS. For example, if you combine a phase-orientation with a deliverable-orientation, you need to be able to identify at least two deliverables for each phase to legitimize the existence of that extra, breakdown level. If you cannot do this, the two orientations are fighting with one another and you need to drop one. To test if you applied this rule, try to summarize each level (within a branch) using a single word or label. If you can do this, you have a clean level in the PWBS. If you need more than one word to describe the things you see on a level (within a branch), your PWBS fails this criterion. Have you created enough early Integration points in your program schedule? In software development, these are known as ‘builds’ that precede the ‘go-live’ and ‘releases’ several times. In product development programs, the integration points are known as ‘proof of concept’, ‘prototypes’ or ‘product assembly’ integration points. Integration points have the following advantages:

© PROJECTPRO CORP.

PAGE 357

11

Chapter 11 Summary

Forecasting Programs

◆ They force project managers to demonstrate early on and regularly thereafter what they accomplished since the last progress meeting and the business value of that progress to the client (product owner). The demonstrations increase the chance that the product will meet the needs of the client. ◆ The challenge to demonstrate a working model is very motivating and challenging and often leads to higher productivity and coordination between team members and between teams. ◆ Integration points make sure these interim products start adding value to the business of the client sooner rather than later. Product owners typically want the most urgently needed functionality in the first builds for software that is used for their core operations. Have you avoided saving linked cells in Microsoft Project? Linked cells are created with Paste Link so they will be automatically updated, but this feature is known to increase the chance for schedule corruption. The feature Links-between-Projects is also a form of linked cells; we do not recommend saving Links-between-Projects in your schedules. Instead, we recommend you use an add-in like CrossLinksPro that allows you to create links when you need them and remove them when you are getting ready to save the schedules.

Consolidating Projects In Microsoft Project, have you linked to the project schedules using the option:  Link to Project. The link will keep the data in the program schedule up-to-date and ensure that the start date of the project, calendar and option settings (Hours per day) do not change. It will also prevent duplication of data.

Linking Projects As a program manager, have you modeled the cross-project links between the projects in your program? The program manager’s prime responsibility is to coordinate and integrate all projects in the program. A model of the dependencies between projects is the program manager’s prime model for coordination and integration. Have you checked on loose ends in the network logic of the program schedule? The integrated master schedule should not have any ‘loose ends’ (‘open ends’ or ‘danglers’) in its network logic just as we recommended for a single project Are you modeling and managing the cross-project dependencies?

PAGE 358

© PROJECTPRO CORP.

Forecasting Programs

Chapter 11 Summary

◆ Identify them and coordinate their dates manually and regularly if you have 30 or fewer cross-project dependencies. ◆ Model them using the Links-between-Projects feature in MS Project if you have 50 or fewer cross-project dependencies. ◆ Use specialized applications if you have more than 50 cross-project dependencies:  CrossLinksPro and PathsPro from ProjectPro Corporation, see www.ProjectProCorp.com.  MasterLink by Matan (Israel), see www.matan-consulting.com.  CS Program Management by Campana & Schott, (Europe), see www.campana-schott.com. Cross-project dependencies: ◆ Are you creating the cross-project dependencies in the master schedule to prevent circular dependencies? ◆ Have you created two milestones for each handoff:  One in the provider schedule (giver that creates the handoff deliverable), and  One in the receiver schedule (getter that needs the handoff as input or necessary supply). ◆ Have you coded (tagged) each handoff milestone so you can easily find the integration points in your master schedule?

Sharing Resources Do you share resources across the projects in your program or with outside projects or programs? If so, we recommend that you create a shared resource pool: ◆ In Project Server or Project Online ◆ With Microsoft Project as a standalone tool if:  You do not have Project Server or Project Online, AND  You do not have more than 50 resources to share, which means in most cases you must restrict yourself to using generic resources only.  In any other situation, we recommend purchasing a temporary subscription to Project Online to create the shared resource pool. Modeling Resources: ◆ If you ONLY work with generic resources, have you set the Max. Units to represent the number of resources you have in a certain role? ◆ If you ONLY work with actual Resources, have you set the Max. Units to reflect the availability of the individual to the program? ◆ If you work with both generic and actual Resources, have you created the generic resources as Team Assignment Pools so their capacity is zero?

© PROJECTPRO CORP.

PAGE 359

11

Chapter 11 Summary

Forecasting Programs

Resource management in programs: ◆ Are you balancing the resource roles in your program during the program planning? Have you tried to find the right mix of people in each role in your program? ◆ Are you always keeping the workloads of your resources within reason? We suggest that workload should not exceed 150% of someone’s availability on a day-to-day basis and not exceed 120% on a week-by-week basis. These maxima come from my Forecast Scheduling books. ◆ When leveling the workloads with outside projects and programs:  Is leveling performed based on priority numbers (ranking) for all projects and programs involved?  Was the ranking established by the appropriate level of management?  Is the leveling performed using automated workload leveling applications?

Optimizing Critical Paths: ◆ Do you have always a detailed Critical Path into the next one (or two) major milestone(s) that are coming up? In a resource-constrained program, you need to have a detailed Resource-Critical Path into the next major milestone(s). ◆ Do you have an automated method to identify the (Resource-)Critical Path? You need to be able to quickly determine the detailed Critical Path into the next one (or two) major milestone(s); manual schedule analysis of a large schedule takes too much time. ◆ Do you always have a high-level (Resource-)Critical Path for the overall program? You should have a Program Critical Path or a Program Resource-Critical Path in a resource-constrained program. The Program (Resource-)Critical Path displays all deliverables that drive the program duration. A high-level Program Critical Path is only truly high-level when it contains only about 100 activities. ◆ After each update to the project schedules, can you quickly determine the latest, high-level (Resource-)Critical Path for the overall program?

Reporting Have you used tagging and grouping to report on other breakdown orientations needed for reports? Multiple breakdown orientations are possible and can co-exist peacefully in a single PAGE 360

© PROJECTPRO CORP.

Forecasting Programs

Chapter 11 Summary

schedule using extra fields that you can customize in MS Project. If you have multiple reporting needs that break down the program in different ways than you have chosen for your PWBS, you will need to implement multiple breakdown orientations in one schedule. For example, you can have a deliverable-oriented breakdown of a project co-exist side-by-side with an Agile breakdown of the project in a single MPP-file. You can have a deliverable-oriented breakdown of a project (Critical Path) living side-by-side with a team-oriented breakdown of the project (Agile). See page 87 and page 299 for more-detailed how-to steps. ◆ You should customize one of the extra fields and create a pick list for it with the categories/tags/items of your secondary breakdown structure. In Project Server or Project Online you can add as many breakdown structures in parallel as you need to report on. ◆ You can tag each task line item in your primary work breakdown structure (as captured in the Task Name field) with the values you have entered in the pick list. ◆ Microsoft Project then allows you to report on each breakdown structure separately by using the View feature that allows each view to have its own Grouping. You base the grouping on the field you customized for this report. Therefore, the choice is not EITHER one OR the other breakdown orientation, but rather: What should be your primary breakdown orientation and what should be your secondary breakdown structure? In other words, what breakdown will you use most often? Typically, this is the project-breakdown orientation and, on a lower level, the deliverable-breakdown orientation that tends to minimize the interdependencies and create autonomous teams at the same time, which are both desirable. However, the program manager will likely have other reporting needs, typically one from each stakeholder: ◆ The program manager may need a report by charge account for the finance department (orientation 3 in the previous table, see page 147). ◆ The program manager will need product-oriented reports for product managers (orientation 4+5). ◆ The program manager may need a report by client (orientation 8). We recommend creating all these reports by using the View and Grouping features mentioned above and maintaining unity of data always by keeping a single schedule from which all reports can be generated. At times, program managers have to fend off powerful stakeholders, like the ‘finance folks’, who are known to enter your office and put their foot down and impose a certain top-level breakdown structure of the work in the PWBS, ‘otherwise any integration with our financial system will be lost which you cannot afford yourself’. We have shown you how to resist the urge to give in to powerful stakeholders, even if their title is CFO (Chief Financial Officer). Tip► Program managers should never compromise on what has turned out to be the best primary breakdown structure for any program (i.e., the autonomous-teams and deliverable-oriented breakdown orientations).

© PROJECTPRO CORP.

PAGE 361

11

Forecasting Programs Are you creating one-page reports for your program? The following are different ways to compress a large program schedule into a one-page report: ◆ Create Tracking-Gantt-like progress bars for Projects in MS Project ◆ Major Milestones View in MS Project ◆ Using Advanced, Custom Filters in MS Project ◆ MS Project Timeline view: the 2016 edition of MS Project can now display multiple Timelines with which you can create reports like swim lane charts. ◆ Swim Lane Chart using OnePager ◆ Earned Value Report using MS Project or CurvesPro

Monitoring Monitoring the projects in a program: ◆ Do your project managers update their schedules at the agreed-upon frequency? ◆ If you are updating assignment, are you using an electronic timesheet system for this that transfers the update data back into the project schedules? ◆ If you are in any other situation; are you updating tasks? ◆ Are you collecting revised duration or work forecasts in your update system?

Closing If you have any additional questions about either program management of MS Project, or if you have suggestions for this textbook, please do not hesitate and send an email to: Eric Uyttewaal at [email protected]. Thank you! Eric Uyttewaal, PMP President ProjectPro Corp. Ottawa, Canada 613-692-7778 (EST)

PAGE 362

© PROJECTPRO CORP.

Forecasting Programs

Index

Index @ @Risk, 80 1 100% rule, 151 4 4D-1D scheduling, 132 5 5A-scheduling, 132 6 6C-scheduling, 133 A absolute paths, 203 Active Directory, 259 actual cost (task field), 325, 329 actual duration, 336, 340 actual hours, 336, 337 actual resources, 234, 236 actual work, 336 ACWP (task field), 325, 329 adaptive scheduling, 89 Agile, 58, 155 sprints, 104 agile scheduling, 299 and/or logic, 318 application development programs, 160 architects, 188 assignment units (assignment field), 135 assignment work, 135 assignments, 336 updating assignments, 336 Aurora, 287 auto filters, 186 awareness campaigns, 144 © PROJECTPRO CORP.

B backend schedules, 335 Barbecana, 80 Basel 3, 110 baseline cost (task field), 329 BCWP (task field), 324, 329 BCWS (task field), 324, 329 benefit to society, 264 big bang approach, 89, 156 big-design-upfront, 89 BIM, 74 blended rates, 133 boolean logic, 318 Booz Allen Hamilton, 80 bottom-up checks, 151 breakdown orientations avoid mixing breakdown orientations, 357 multiple, 360 breakdowns top-level, 361 buffer consumption charts, 68 build estimates, 125 build programs, 27 building information modelling, 74 builds, 155, 357 C calendars project, 163 campaigns awareness, 144 Campana & Schott, 113, 185, 359 Canada Post transformation program, 154 capacity planning, 236 cases PAGE 363

In

Index use, 59 CDRL, 309 CFO, 361 change control, 99 charters project, 251 charts risk-burndown, 68 checks bottom-up, 151 top-down, 151 chief financial officers, 361 chunking, 155 circular dependencies, 166, 209, 223 civil works, 62 clients, 162 codes outline, 301 Cognos IBM, 184 competition, 149 components hardware, 299 software, 299 cone of uncertainty, 125 consolidated schedules, 159 constraint dates, 167 as few as possible, 167 constraints project, 55 start-no-earlier-than, 181 construction, 237 construction projects, 57, 62 contract data requirements lists, 309 control account managers, 31 corporate standards, 154 Corporations Campana & Schott, 113 ProjectPro, 113 corruptions file, 170, 184, 214 schedule, 170, 214 PAGE 364

Forecasting Programs cost modeling, 125, 130, 141 cost models, 140 cost performance index, 325 cost variance, 71, 325 costs model, 43 CPI, 325 CPM, 60 critical handoffs, 224 Critical Path, 167, 288 program critical paths, 223 program resource-critical paths, 291 Critical Path fragmentation, 167 Critical Path Method, 60 critical paths, 123, 273, 360 critical, 123, 360 detailed critical path, 123, 360 high-level, 123, 360 latest, 123, 360 primary, 227 program critical paths, 123, 360 program resource-critical, 123, 360 resource-critical paths, 123, 360 secondary, 227 critical resources, 234, 265, 288 CRM, 126 CrossLinksPro, 113, 180, 185, 215, 218, 359 cross-project dependencies, 113, 166, 180 cross-project impacts, 180 cross-project links, 177, 179, 180 CS Program Management, 113, 185, 359 CS Resource Management, 113 CV (task field), 325 D danglers, 181, 358 dangling tasks, 164 data dates, 340 status dates, 304 © PROJECTPRO CORP.

Forecasting Programs database application development projects, 89 dates data, 340 status, 340 deliverable leads, 31 deliverables, 146, 183, 196, 356 complete list, 162 lean list, 162 out-of-scope, 162 demand management, 236 dependencies circular, 166, 209, 223 cross-project, 113, 166, 180 cross-project links, 179, 180 external, 164 finish-to-finish, 165 gives and gets, 180 handoffs, 180 interdependencies, 180 intradependencies, 180 links duplicated, 184 links lost, 184 links protected, 185 links-between-projects, 180 multiple external predecessors, 204 multiple external successors, 204 mutual exclusion, 117 mutual inclusion, 117 start-to-start, 165 dependency-days, 187 detailed critical paths, 123, 360 detailed program schedules, 123 developers, 188 DoD, 104 duration-based scheduling, 141 durations actual, 340 remaining, 341 dynamic, 166 dynamic scheduling, 166

© PROJECTPRO CORP.

Index E Earned Points, 73 Earned Schedule, 71, 73 Earned Value, 305, 324, 329, 345 Earned Value Management, 318, 324, 337 Earned Work, 73 ECM, 182, 184, 219 effectciencies, 144 effectiveness, 144 efficiency, 144 efficient frontier, 38 effort-based scheduling, 141 Elon Musk, 114 embedding, 169, 172, 176 ends loose, 181 open, 181, 358 engagements resource, 113 enterprise content management, 182, 184, 219, 228 enterprise outline codes, 301 enterprise project management, 238 enterprise project management offices, 263, 265 enterprise resource pool analyst, 241 enterprise schedules, 264 EPM, 238 EPMO, 263, 265 ERP, 126 escalations rate, 133 estimates build, 125 gross working time, 163 normally distributed, 61 PERT, 61 pure working time, 163 three-point, 61 two-point, 61 event programs, 156 PAGE 365

In

Index execution, 337, 338 expenses software, 182 external dependencies, 164 external successors, 206 external tasks, 211 F features deliverables, 183 Fibonacci, 93, 353 fields (task-related) Actual Duration, 336 Actual Finish, 336 Actual Start, 336 Actual Work, 336 Remaining Duration, 336 Remaining Work, 336 file corruptions, 170, 184, 214 files corruptions, 184 subproject, 174 filters auto, 186 interactive, 127, 318 interactive filters, 320 multi-field, 127, 318 regular, 186 finance folks, 361 finish-to-finish (dependency field value), 165 first-to-market, 53 flash-memory products, 217 forecast reports, 168 forecast scheduling, 168 Full Monte, 80 functions, 236 G games Olympic, 156 PanAm, 156 PAGE 366

Forecasting Programs GAO, 104, 179, 217 gates, 276 General Accountability Office, 104, 179, 217 generic resources, 234, 236, 252 getters, 186, 187 Give & Get System, 186 givers, 180, 186, 187 gives and gets, 180 go-live, 155, 357 government policy interventions, 145 gross working time estimates, 163 GUID (task field), 175 H hammock tasks, 295 handoff milestones, 218, 228 handoffs, 180, 196, 309 critical, 224 hanger tasks, 164 hardware components, 299 heuristics, 237 high-level program schedules, 123 HPE Content Manager, 184 HR-departments, 128 I IBM Cognos, 184 ID (task field), 174 ideals project, 53 impacts cross-project, 180 impressions, 144 IMS, 32, 104, 115, 123, 159, 161, 164, 165, 166, 176, 177, 179, 182, 183, 184, 185, 208, 216, 223, 269, 273 IMS, 213 inch stones, 122 infrastructure projects, 62 inspectors tax, 149 © PROJECTPRO CORP.

Forecasting Programs Intaver, 80 integrated master schedules, 23, 32, 104, 115, 123, 159, 161, 164, 165, 166, 173, 176, 177, 183, 184, 185, 208, 213, 215, 216, 222, 223, 269, 273 integrated program schedules, 23, 273 integrated states, 179, 185 integration points, 155 integration risks, 61 interactive filters, 127, 318, 320 interdependencies, 180, 183, 192 internal tasks, 211 Internet Explorer, 35 intradependencies, 180, 192 L lanes swim, 322 leaders team, 31 level of confidence, 124 Leveling delay (task field), 241 levels deliverables, 146, 356 projects, 146 lifecycles project, 54 system-development, 89 linkedin group, III linking, 169, 172, 358 object, 169 links cross-project, 177, 180 duplicated, 184 losts, 184 protected, 185 links-between-projects, 180, 181 lists generic resources, 252 live-run-throughs, 156 logic boolean, 318 © PROJECTPRO CORP.

Index network, 181, 358 logical hierarchy, 162 logical overlaps, 151 loose ends, 164, 181, 358 loose starts, 164, 181 loose strands, 181 M maintenance programs, 156 maintenance projects, 54 major milestones, 123, 124, 228, 276, 306 management ostrich, 182 managers program, 187 project, 31 subproject, 31, 187 master projects, 179 master schedules, 159, 167, 173, 183, 185 permanent, 171 temporary, 171, 173 MasterLink, 113, 185, 359 Matan, 113, 185, 359 matrices requirements, 145 merge-bias, 61 methodologies stage-gate, 322 MicroFocus, 184, 185 Microsoft Office, 35 Microsoft Project, 127, 242, 299, 301 Microsoft Project Online, 301 Microsoft Project Server, 301 Microsoft stack, 35 Microsoft Visio, 152, 153, 154 milestones, 122, 163 handoff, 218, 228, 309 inch pebbles, 122 major, 122, 123, 124, 228, 306 minor, 124 PAGE 367

In

Index program completion, 123 minimum viable product, 155 minor milestones, 124 model costs, 43 model time, 43 model workload, 43 modeling, 120 cost, 125, 130, 141 time, 125, 130, 141 workload, 125, 130, 141 models, 117 cost, 140 time, 140 workload, 136, 140 modules, 322 Monte Carlo simulation, 61, 123, 354 most-critical paths, 195, 224, 279, 282, 283 MS Excel, 35 MS Outlook, 35 MS Project, 17, 18, 35 multi-field filters, 127, 318 multiple breakdown orientations, 360 multiple external predecessors, 204 multiple external successors, 204 mutual exclusion, 117 mutual inclusion, 117 MVP, 155 N named resources, 234 names task, 357 NASA, 114 nesting, 160 network logic loose ends, 164 loose starts, 164 network logics, 181, 358 networks danglers, 181, 358 loose ends, 181, 358 PAGE 368

Forecasting Programs loose strands, 181 open ends, 181, 358 new product development, 60 new product development programs, 217, 299 new product development projects, 57 non-cooperation, 149 non-integrated states, 179, 185, 216 O object linking, 169 object linking and embedding, 169 Office 365, 35 OLE, 169 OLE-links, 185 Olympic Games, 156 Olympics, 156 online project, 42 open ends, 181, 358 OpenText, 184, 185 operational programs, 27 Oracle Primavera, 127, 299 orientations multiple breakdown orientations, 360 ostrich management, 182 outline codes, 301 out-of-scope, 162 overhead tasks, 164, 165, 295 overlaps logical, 151 P Palisade, 80 PanAm games, 156 path-convergence, 61 paths absolute, 203 critical, 273 most-critical, 195, 224, 279, 282, 283 © PROJECTPRO CORP.

Forecasting Programs relative, 203 resource-critical, 62, 101, 105, 114, 273 PathsPro, 64, 105, 113, 114, 185, 195, 215, 224, 283, 287, 359 PCubed, 180, 186 performance baseline, 329 performances slow, 184 permanent master schedules, 171 PERT, 61 PgMP, 29 phases, 357 planned value (task field), 329 planned values, 324 planning Rolling Wave, 102 plant engineering projects, 62 plant shut-downs, 156 plants, 154 PMO, 31, 32 points integration, 155 Polaris, 80 portfolio management, 24, 37 portfolios, 25, 27, 117 project, 273 Power BI, 36, 45 PPM, 126, 239 predictive scheduling, 89 primary breakdown structure, 301 primary critical path, 282 primary program critical paths, 227 Primavera Oracle, 299 principles unity-of-data, 123, 150 proactive workload leveling, 241 ProChain, 64 product assemblies, 155, 357 product development programs, 155, 357 © PROJECTPRO CORP.

Index products, 322 viable, 59 program completion milestones, 123 program critical paths, 123, 161, 167, 182, 183, 185, 188, 195, 215, 216, 223, 274, 289, 360 primary, 227 secondary, 227 program evaluation and review technique, 61 program management, 38 program management offices, 31 program management professionals, 29 program management systems, 103 program manager’s models, 180 program managers, 187 Program Planning Professionals, 186 program resource-critical paths, 123, 291, 360 program schedules, 32, 159 program sponsors, 32 program support offices, 31, 227, 229 program support staff, 31 program WBS, 143 program work breakdown structures, 143, 357 programs, 25, 27, 117 application development, 160 awareness campaign, 144 build, 27 Canada Post transformation program, 154 critical path, 273 events, 156 maintenance, 156 new product development, 217, 299 Olympics, 156 operational, 27 product development, 155, 357 publications, 156 resource-constrained, 123, 360 resource-critical paths, 273 PAGE 369

In

Index service development, 160 shut-downs, 156 software development, 155, 179, 188 system development, 156 Project Microsoft, 299 Professional, 18 Standard, 18 Project 2013, 18 Project 2016, 18 Professional, 17 Standard, 17 project calendars, 163 project charters, 251 project constraints, 55 project ideals, 53 project lifecycles, 54 project management, 38 project management offices, 32 project management systems, 103 project managers, 31 Project Online, 35, 42, 113, 204, 239, 338 Project Online, 242 Project Online Desktop Client, 17 Project Online Desktop Client, 18 Project Online Essential, 45 Project Online Premium, 45 Project Online Professional, 45 project portfolio management, 35, 36, 126, 239 project portfolios, 25, 273 Project Professional, 17, 18, 36 Project Server, 35, 42, 113, 204, 242, 338 project sites, 338 project sponsors, 162 Project Standard, 17, 18, 36 project status dates, 304 Project Web App, 45 ProjectPro CrossLinksPro, 185, 359 PAGE 370

Forecasting Programs CrossLinksPro, 180 PathsPro, 185, 359 ProjectPro Corporation, 113, 114, 287 projects, 25, 27, 146 civil works, 62 construction, 57, 62 database application development, 89 infrastructure, 62 maintenance, 54 master, 179 new product development, 57, 60 plant engineering, 62 R&D, 60 regulatory-compliance, 54 research and development, 60 software development, 54, 60 software enhancements, 60, 62 proof of concepts, 155, 357 prototypes, 155, 357 provider schedule, 218, 359 providers, 186 PSO, 31, 227, 229 publications programs, 156 pure working time estimates, 163 PWA, 45, 338 PWBS, 143, 357 100% rule, 151 chronological breakdown, 151 logical overlap, 151 logical overlaps, 151 R R&D, 60 rate escalations, 133 rates blended, 133 RCP, 62 reactive workload leveling, 241 receiver schedule, 218, 359 receivers, 180, 186 recurring tasks, 164, 165, 166, 295 © PROJECTPRO CORP.

Forecasting Programs recurring detail task, 167 regular filters, 186 regulatory-compliance projects, 54 relative file referencing, 174 relative paths, 203 releases, 155, 322, 357 remaining duration, 336, 341 remaining hours, 336 remaining work, 336 reports Earned Value, 324 forecast, 168 status, 168 request for proposal, 50 requirements, 145 requirements trace-matrix, 145 research and development, 60 resource capacity planning, 36 resource demand management, 36 resource engagements, 113 resource management, 38 resource-constrained programs, 123, 360 resource-critical paths, 62, 101, 105, 114, 123, 265, 273, 289, 360 resources actual, 234, 236 critical, 234, 265, 288 generic, 234, 236, 252 named, 234 unlimited, 61 return on investment, 36 RFP, 50 Risk Optimizer, 80 risk-burndown charts, 68 risks integration, 61 RiskyProject, 80 rivalry, 149 ROI, 36 role delineation studies, 31 roles, 236 © PROJECTPRO CORP.

Index Rolling Wave, 102 Rolling Wave planning, 251 roll-up, 160 roll-up schedules, 159 S SanDisk, 217 scenarios, 292 Schedule Assessment Guide, 179, 217 schedule baselines, 303 schedule corruptions, 170, 214 schedule performance index, 325 schedule variance, 71, 325 schedules backend, 335 baseline, 303 detailed program schedule, 123 enterprise, 264 high-level program schedule, 123 integrated master schedules, 123, 222 master, 167, 173, 183, 185 program, 32 provider, 218 provider schedule, 359 receiver, 218 receiver schedule, 359 sub schedules, 167 templates, 176 valid and dynamic model, 166 scheduling 4D-1D, 132 adaptive, 89 agile, 58 duration-based, 141 effort-based, 141 forecast, 168 predictive, 89 scheduling applications interactive, 127 Microsoft Project, 127 oracle primavera, 127 PAGE 371

In

Index spider, 127 scope statements, 251 Scrum, 60 SDLC, 89 secondary program critical paths, 227 sequestering the subnet, 278 servers project, 42 SharePoint, 184 service development programs, 160 shared resource pool Microsoft Project, 242 Project Online, 242 Project Server, 242 shared resource pools, 113 SharePoint, 185 SharePoint Server, 184 shut-downs plant, 156 simulation Monte Carlo, 61, 123, 354 skills, 236 slow performances, 184 software components, 299 software development, 54, 60, 237 builds, 155, 357 go-live, 155, 357 releases, 155, 357 software development programs, 155, 179, 188 software enhancements, 60, 62 software expenses, 182 Space-X, 114 span-of-control, 109, 147 specifications, 145 SPI, 325 Spider, 127 Spider Project, 64 sponsors, 162 program, 32 sprints, 58, 104 SQL Server Analysis Server, 35 PAGE 372

Forecasting Programs SQL Server Database Server, 35 SQL Server Reporting Services, 36 stage-gate methodologies, 322 stages, 322 stakeholders, 322 standards corporate, 154 Standish research reports, 125 start-no-earlier-than constraints, 181 start-to-start (dependency field value), 165 statements scope, 251 states integrated, 179, 185 non-integrated, 179, 185, 216 status dates, 304, 340 status reports, 168 stones inch, 122 stories user, 59 Stottler Henke Associates Inc., 287 strands loose, 181 streams, 322 sub schedules, 167 subproject, 160 subproject file (task field), 174 subproject managers, 31, 187 subproject tasks, 164, 165, 166 successors external, 206 summary tasks, 164, 165, 295 SV (task field), 325 sweet spots, 128, 147 number of subprojects, 147 subproject schedulers, 128 swim lanes, 322 system cut-overs, 156 system development programs, 156 system-development lifecycles, 89 © PROJECTPRO CORP.

Forecasting Programs systems program management, 103 project management, 103 task-management, 103 team-management, 103 T task name (task field), 357 task-management systems, 103 tasks dangling, 164 external, 211 hanger, 164 internal, 211 overhead, 164, 165 recurring, 164, 165, 166, 167 subproject, 166 updating tasks, 336 tax inspectors, 149 tax payers, 149 team assignment pools, 244 team leaders, 31 team-management systems, 103 telecommunications, 237 template schedules, 176 temporary master schedules, 171, 173 testers, 188 Theory of Constraints, 234 three amigos, 188 three-point estimates, 61 time model, 43 time buffer, 166 time modeling, 125, 130, 141 time models, 140 timeline, 302, 362 time-to-market, 217 top-down checks, 151 top-level breakdown structures, 361 total slack, 166 Tracking Gant charts, 303 two-point estimates, 61 © PROJECTPRO CORP.

Index U Unique ID (task field), 174, 203, 225 Unique ID Predecessor (task field), 203 Unique ID Successor (task field), 203 units assignment, 135 unity-of-data, 104, 123, 150, 160, 169, 170, 200 unlimited resources, 61 updating Actual Duration, 336 Actual Finish, 336 Actual Start, 336 Actual Work, 336 Remaining Duration, 336 Remaining Work, 336 updating assignments, 336 updating tasks, 336 US Department of Defense, 104 use cases, 59 user stories, 59 V valid, 166 version controls, 150 viable products, 59 Visio Microsoft, 152, 153, 154 W Waterfall, 155 waterfall scheduling, 299 WBS, 143, 162, 357 deliverable-oriented, 162 logical hierarchy, 162 WBS Schedule Pro, 152, 153, 154 Web Server, 36 what-if scenarios, 39 windows of opportunity, 167 Windows SharePoint Server, 36 work (assignment field), 135 work (task field), 132 PAGE 373

In

Forecasting Programs work breakdown structures, 143 workload balancing, 236 workload leveling, 237 proactive workload leveling, 241 reactive workload leveling, 241 workload modeling, 125, 130, 141 workload models, 136, 140 workload optimizing, 237 workloads model, 43

PAGE 374

© PROJECTPRO CORP.

Forecasting Programs

In

© PROJECTPRO CORP.

PAGE 375