How to tame a gorilla program

Abstract

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.

Introduction

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:

img We created at least ten major milestones in the program schedule. The ten major milestones divide the network of dependencies into ten sub networks.

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

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

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

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

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

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

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

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

img Level 0 - Subprojects: Major component of the new product: Use nouns (without verbs);
e.g., ASIC, Firmware, Parts, Test Software, Reliability, Tested Parts

img Level 1 - Subcomponents in the major component: Use nouns (without verbs);
e.g., for ASIC: Multiple Subsystems and Top Design

img 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

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

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

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

Integrated Master Schedule (IMS)

Exhibit 1: Integrated Master Schedule (IMS)

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

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

Differences between a Single Project and an Integrated Master Schedule (IMS)

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:

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

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

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

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

Buffer Rundown Chart

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:

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

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

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

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

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

References

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.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2012, ERIC UYTTEWAAL, PMP, MVP PROJECT
ORIGINALLY PUBLISHED AS A PART OF THE 2012 PMI GLOBAL CONGRESS PROCEEDINGS – VANCOUVER, CANADA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.