How to tame a gorilla program
This article discusses the scheduling of a new product development program at SanDisk, a major designer of Flash Storage products. The program had about 5,000 tasks and 250 cross-project dependencies. The program was considered to be in control when the forecast completion dates of the next major milestone would display a high probability in Monte Carlo simulations of its detailed critical path. The program and particularly the critical path needed to be resource-loaded and leveled. Because of the first-to-market nature of SanDisk's business, the critical path needed to be as short as possible. This article describes how SanDisk was able to meet these scheduling requirements and maintain an important program in control with the help of some state-of-the-art software from ProjectPro.
In this article, we will discuss a product development program at SanDisk of 5,000 tasks broken down into eight subprojects, with 250 dependencies between the subprojects. The scheduling application used at SanDisk was Microsoft Project. We will present insights that are important to programs of similar size and nature.
When Can You Call a Program “In Control?”
The amount of data in the SanDisk program schedule is mind-boggling. To help you imagine how big it is: If you were to write all 5,000 task names in the Empire State building on its walls starting at the top, you would end up in its basement. You can then travel by elevator from floor to floor to analyze the schedule. This is how it feels when you look with your 22-inch monitor at the program schedule; you can always see only a fraction of it. How are you going to prevent drowning in the data? When can you proclaim the program to be “in control?”
In each client engagement at ProjectPro, we first try to gain an understanding of when the client regards the program “in control.” At the SanDisk engagement, we agreed to consider the program “in control” when:
We created at least ten major milestones in the program schedule. The ten major milestones divide the network of dependencies into ten sub networks.
All subproject schedules were dynamic models that forecast the subprojects. Too many schedulers create very static, rigid schedules that merely reflect how a project should unfold rather than how it is unfolding. You will need to know how the program is unfolding if you want to gain control over the program. It is our experience that schedules only reflect how the project is unfolding if they are set up as dynamic models; see the book “Forecast Scheduling with Microsoft Project 2010” for a checklist.
We had a detailed critical path to the next two major milestones. A detailed critical path is a path that consists of activities rather than deliverables. This critical path can and will run across more than a subproject schedule.
We had a 90% confidence level that the next two major milestones would be completed when promised. The detailed critical path should have enough buffer time to make it probable. The tasks on the critical path should be resourced and the likelihood that the resources are available when needed must be high.
We had a high-level critical path to the last major milestone (program finish) The program often has only high-level deliverables in the back end, so the critical path for the entire program will only show deliverables rather than activities.
Why Break a Program Down into Subprojects?
From past experience with other companies, ProjectPro has come across several program schedulers that desperately try to contain all tasks in one, large schedule. One person we met was even looking after a program schedule with 33,000 tasks. These overworked people often argued that they did not have enough people proficient enough to handle schedules of 1,000 tasks. In other cases, people argued that the software does not deal well with cross-project dependencies that come with multiple subprojects. They seemed convinced that keeping all tasks in one schedule was the only way it would work.
Here are our reasons why it makes sense to break up a program schedule into multiple subproject schedules:
Delegate to a scheduler who is closer to the work. You can delegate the responsibility for the schedule to people who are “closer to the fire.” In theory, people who are closer to the work being done should be able to report on it better. In practice though, you have to make sure that these people are well trained in the scheduling software and follow scheduling guidelines.
Multiple people need to update the program schedule. MS Project is a single-user application and, if it is determined that more than one person owns (sections in the) schedule, you are better off breaking it down. Otherwise, somebody will only have access to the schedule on Sunday.
People are in different countries, in different time zones, and speaking different languages. Even though the time zones make it easier to schedule access to one file, the different countries require local calendars (local work weeks, national holidays), language and schedule communications. All these make it more practical to divide the schedule into multiple sub schedules. The SanDisk program was partly performed in Israel and California. Israel has a workweek running from Sunday through Thursday, whereas California's work week is Monday through Friday. The scheduled holidays were a major difference.
You have more than 2,000 tasks in the program schedule. A schedule with 2,000 tasks is a full-time job in our mind. If you have more tasks, you have to break the program schedule up into more than one subproject schedule.
SanDisk already had the program broken down into eight sub schedules.
Work Breakdown Orientations: Good and Bad
The way the program is broken down is very important. In our opinion, it is important to minimize cross-project dependencies and create autonomous teams as much as possible. The breakdown must be oriented to deliverables rather than to departments, phases, products or other alternatives. At the SanDisk program, we created a standard high-level breakdown structure for the subprojects that consists of:
Level 0 - Subprojects: Major component of the new product: Use nouns (without verbs);
e.g., ASIC, Firmware, Parts, Test Software, Reliability, Tested Parts
Level 1 - Subcomponents in the major component: Use nouns (without verbs);
e.g., for ASIC: Multiple Subsystems and Top Design
Level 2 - Function: Use nouns (without verbs);
e.g., for ASIC: Logic Design, Physical Design, FPGA Design (Field Programmable Gate Array), Documentation, Verification, Test Preparation, Package, Foundry, and Design Validation
Level 3 - Tangible Deliverables: Use nouns (without verbs);
e.g., For ASIC: Preliminary, Trial and Final RTL; Preliminary, Trial and Final Synthesis and Layout; RTL and Gate Level Verification and multiple FPGA releases.
Lowest Level - Work packages/Activities/ Tasks: Use verbs to describe the activities.
As you can see, there is a lot of room for schedulers to fill in intermediate levels, but there had to be one intermediate level with deliverables only, and the lowest level should always be activities.
Consequences of Breaking a Program into Subprojects
There are two main consequences of breaking a program schedule into subproject schedules:
You end up with dependencies between schedules and a critical path that runs across schedules. Subprojects have dependencies between them, which are called cross-project dependencies or interdependencies. Interdependencies are harder to handle than intra-dependencies (dependencies within one schedule). Mainstream scheduling software does not handle interdependencies well.
A critical path running across multiple schedules will look like as shown in Exhibit 1 :
Exhibit 1: Integrated Master Schedule (IMS)
You are now often sharing resources across subprojects, perhaps even across programs. As soon as you break a schedule into multiple sub schedules, you will often end up in a situation where resources are shared across the subprojects, even if it is just for reviewing each other's documents or designs. Rarely will each subproject have its own dedicated resources that can work entirely independently from each other.
Multiple schedulers have to adhere to centralized scheduling guidelines. At the SanDisk engagement, this is where we had a lot of work, because each department involved in the program had developed their own set of scheduling guidelines, which were mostly centered on managing the resources. We needed schedules that would support managing the program as the primary objective instead of managing the resources. Some schedulers needed to reorganize the structure of their schedules and required training. Some departments had no schedulers, but were willing to participate in the development of their schedules with help because of the ability to see the advantage of generating a complete and interactive schedule. All of this required executive support.
Creating the Integrated Master Schedule (IMS) — Re-integrating Subproject Schedules
At SanDisk, we created a master schedule with all its sub schedules. We modeled the cross-project dependencies using an add-in for Microsoft Project, called ProjectPro Program Management Solution (PPMS) that is able to handle hundreds of cross-project dependencies. This add-in creates the cross-project dependencies in an automated fashion and, thus, creates the integrated master schedule. When the critical path is checked and optimized, the add-in also removes the cross-project dependencies but maintains the dates from the cross-project dependencies. In this way, all subproject managers are always working with standalone schedules with valid dates instead of linked schedules, which made their lives a lot easier. As the program management office, we could have our integrated master schedule whenever we needed it and we typically created it every week.
Hunting for the Critical Path in an IMS
Finding the critical path in your integrated master schedule is much more difficult than in a single project. First of all, a subproject schedule is different than a single-project schedule. A single-project schedule has one ending point, whereas a subproject schedule typically has multiple ending points, which are deliverables that need to be handed off to other subprojects in the program. Technically, this is known as a cross-project dependency. At SanDisk, the scheduling software had to be able to handle hundreds of cross-project dependencies.
Another difference between an IMS and a single project is that the manager of a single project is interested in one critical path, whereas the program manager is interested in multiple critical paths, the paths into each major milestone.
The critical path in an IMS often consists of activities from multiple subproject schedules, but not necessarily all subproject schedules. As a result, an activity that may be on the critical path in the subproject schedule (when analyzed by itself), may not be on the critical path of the program. The scheduling software needs to be able to find the program critical path across all subproject schedules through cross-project dependencies. The software also needs to be able to mark those critical activities in the subproject schedules in such a way that each subproject manager can see which activities in their schedule are critical from a program point of view. This is where scheduling software often disappoints program managers.
SanDisk is a firm that produces high-tech products such as SSDs, Embedded Storage, Memory Cards, and USB Flash Drives. Like all high-tech companies, SanDisk's goal is to be the first-to-market with new products, which requires them to be very schedule sensitive. Optimization of all resources is crucial. The program managers at SanDisk are sharing scarce resources across their programs, which creates resource dependencies on top of logical dependencies (for a full explanation of what resource dependencies are, please refer to “Forecast Scheduling with Microsoft Project 2010”). There are few scheduling applications capable of handling resource dependencies on the critical path.
For your convenience, we have summarized the differences between scheduling a single project and scheduling the Integrated Master Schedule, see Exhibit 2:
Exhibit 2: Differences between a Single Project and an Integrated Master Schedule (IMS)
At SanDisk, we needed to find software capable of meeting all these requirements; we used the Complete Critical Paths (CCP) add-in for Microsoft Project (from ProjectPro). This add-in allows you to select a major milestone and it produces the critical path that drives this milestone even when cross-project dependencies and resource dependencies are involved. It also displays the near-critical paths, so we always knew how much we could easily gain without being surprised by other paths that suddenly became critical.
Validating the Critical Path
When you see the critical path in a program for the first time as a scheduler, you will immediately notice errors on it that need to be cleaned up:
You will see dependencies that do not reflect a practical necessity (like building walls before you start roofing). At SanDisk, we found ourselves cleaning up the logic with the help of the subproject managers.
You will see tasks that are valid, but should not be on the critical path. Adding resources or changing the priority of the tasks minimizes the duration of the critical path.
You will see tasks that you do not want to see on your critical path: summary tasks, level-of-effort tasks, overhead tasks, secondary tasks (e.g., write test plan) etc.
You will see tasks with part-time assignments. These need to be changed into full-time assignments; you want people to work full-time on critical activities.
As a result, it took several iterations before we found the critical path in the first major milestone. Then we had to optimize the critical path for which we used the table with 15 methods from the book “Forecast Scheduling with Microsoft Project 2010,” which deals with optimizing resource-constrained critical paths, exactly what we needed.
Dealing with Sharing Resources across Programs
SanDisk wants to be the first company to the market with new products in order to capture the market and provide long-term revenues. Therefore, it needs to develop new products as quickly as possible. SanDisk is sharing the same resources across multiple programs and has to allocate resources carefully across these competing initiatives.
One of the first thing schedulers need to do is provide a time-phased resource requirements spreadsheet to executives. However, until the critical path has been validated, optimized, and stabilized, the resource requirements continue to be adjusted to find out how the program can be delivered in the fastest way. This requires tedious adding of resources on the critical path and removing of resources from non-critical paths until the resourcing is perfectly balanced. The spreadsheet displays the number of resources needed in each skill and for how many months. A balanced spreadsheet shows peaks that aren't too steep and a lack of deep valleys because it is important that the work is consecutive as much as possible. This balancing of resources is best done with generic resources assigned to the tasks rather than named resources. It takes too much effort to add Tom, Dick, and Harry to the many tasks compared to raising the number of system analysts by three.
This process is tedious but provides SanDisk with huge savings on their programs that deliver their new products to sell.
Simulating the Critical Path
SanDisk had an extra requirement to simulate the critical path and determine appropriate project buffers for each major milestone using Monte Carlo simulation. There is no software on the market that can simulate a resource-constrained critical path in Microsoft Project and we custom developed this software to address this need. Having a solid time buffer for each milestone allowed SanDisk to predict a high confidence target date and to control the program by monitoring the rate at which the project buffer was consumed.
Program Forecast Reports
SanDisk wanted to use buffer charts that depict the consumption of the buffer for their programs. These charts allow them to extrapolate the consumption of the buffer into the future and predict if the program would be delivered on time. An example of a buffer rundown chart used at SanDisk is shown in Exhibit 3:
Exhibit 3: Buffer Rundown Chart
This buffer chart is produced by the Complete Critical Paths add-in from ProjectPro. As you can see in the chart, this project started late, is consuming its buffer faster than planned, and will finish late as a consequence.
In Summary: Our Recommendations
From the experiences we gained from this program and engagement, we would like to make the following recommendations:
Achieve agreement among stakeholders on when the program is “in control.” SanDisk considers their program in control when they have at least ten major milestones, a detailed critical path into the next major milestone, and a high level of confidence the major milestone date can be met.
Protect unity of data
We see too many program managers fall prey to schedulers who split the schedule in a high-level schedule and detailed schedule and save these in two different files or databases. This requires double bookkeeping and a lot of extra, unnecessary effort. Always extract the high-level views in reports from the low-level detailed schedules. Otherwise, you may become a victim of the two-versions-of-the-truth problem.
Create autonomous subproject teams (minimize cross-project dependencies) Autonomous teams will proceed at their own pace and compete with other teams to stay off the critical path or be on the critical path for as little time as possible. This will benefit the entire program.
Use the right tools
SanDisk looked long and hard before committing to the toolset that could meet all their requirements. The challenging requirements were: many cross-project dependencies, resource-constrained critical path, simulating the resource-constrained critical path, and producing buffer charts to monitor progress and to forecast.
When you are in a time-to-market organization, use generic resources first to optimize the program, balancing the resource needs and then communicate exact resource needs.
DCMA (2009). DCMA 14 Point Assessment materials, DCMA, USA (http://guidebook.dcma.mil/79/Online Version IMP-IMS 11 21 09.pptx)
National Defense and Industry Association (2012). Planning and Scheduling Excellence Guide (PASEG), NDIA, USA.
Project Management Institute (2011). Practice standard for scheduling—Second edition. Newtown Square, PA: Author.
U.S Government Accountability Office (2012). General best practices for project schedules—exposure draft, GAO, USA. Retrieved from http://www.gao.gov/products/GAO-12-120G
Uyttewaal, E. (2010). Forecast scheduling with Microsoft Project 2010, Canada: ProjectPro.
© 2012, ERIC UYTTEWAAL, PMP, MVP PROJECT
ORIGINALLY PUBLISHED AS A PART OF THE 2012 PMI GLOBAL CONGRESS PROCEEDINGS – VANCOUVER, CANADA