Team-Based Scheduling the Intel© Way

Abstract

Do you want to unlock the mysteries of project management?…accurately estimate “unknowns”?…get the right resources? Years of experience have shown that mastering Team-based Planning can help you avoid painful, tragic lessons…and accelerate your career! Team-based Planning has been enshrined at Intel^© as part of the required “Make A Plan (MAP) Day” project management procedure. It is part of why Intel corporate results have been the envy of the world for many, many years!

This presentation will teach participants how to apply a Team-based Planning process. The process provides insight into areas that are often vague and have a high probability of becoming problems without effective management. That insight can then be used to avoid obstacles and focus appropriate resources where they can help keep the project on schedule. This unique training experience gives you a solid understanding of project scheduling theory as well as the experience of a comprehensive lab to practice its application!

Introduction

During this presentation you will learn how to apply a Team-based Planning (as enshrined in Intel^©'s Make A Plan (MAP) Day procedure) process to any project. This presentation covers:

• Schedule Creation - Logic Networks define the dependencies between activities accurately. In Teambased Planning it also builds the commitment of each team member to the plan.
• Step-bv-Step Network Diagramming - We will practice techniques for doing logic networks in a teambased process.
• Schedule Analysis ANALYSIS - The Critical Path Method (CPM) processes task information into knowledge about time constraints. Managing the critical path allows a PM to direct resources to best help the project stay on schedule.
• Step-bv-Step CPM - We will look at a five step team-based CPM process.
• Schedule Management - Schedule management looks to find opportunities and identify risks. We will cover specific techniques to do each.

Background

Although it is typical for a project to be assigned to a project manager with a stated completion date, the reality of that completion date needs to be validated or challenged by the results of an effective scheduling process. Therefore, the project team should accept that the preliminary delivery dates for major milestones and project completion won't be known until the schedule creation and schedule analysis steps are finished.

So we begin by asking ourselves, “What is the difference between planning and scheduling?” At its most central and fundamental core, planning decides what must be done while scheduling decides when to do it! In the first instance, we focus on making sure that every important element of the project is identified and grouped by affinity (Work Breakdown Structure (WBS)), to reduce errors, and then has a level-of-effort duration estimated. In the second instance, we focus on making sure that every opportunity to increase the speed and flexibility of project execution (such as lowering cost or integrating with other projects) is identified and exploited.

When we speak of project scheduling we are usually referring to two tools or disciplines. The first discipline is the Logic Network for defining the relationships between activities. The second discipline is the Critical Path Method of calculating and analyzing the time dimension of those relationships. These two disciplines provide insight into areas that are often vague and have a high probability of becoming problems without effective management. That insight can then be used to avoid obstacles and focus appropriate resources where they can help keep the project on schedule.

Schedule Creation

The first tool, a Logic Network, is where the schedule is created. Developing it requires that the dependencies between activities be accurately identified. Those dependencies show what actions impact the start of an activity, and also what subsequent tasks are affected by the completion of an activity. Responding to a flat tire provides a simple example.

As the diagram below (Exhibit 1) indicates, there is a start event – like the sound of a tie exploding – which is identified using a triangle with an “S”, followed by the activities: (1) stop the vehicle, (2) remove the flat tire, (3) replace it with a spare tire, and (4) go back to driving as originally intended. The diagram indicates the process is finished using a triangle identified with the letter “F”.

Exhibit 1 – Flat Tire Logic Network

In Team-based Planning the goal and process of building a Logic Network are focused on creating a single understanding across the team about HOW the project will be executed and WHY the particular choices about the order of execution were made. At Intel^© their famous motto, “Disagree and Commit!” is translated into action during the MAP day process. By creating a logic network with a simple Post-It^© note methodology there is plenty of opportunity to disagree while the choices are being made, but when the project has been “MAPped” every member of the team is required to commit to its execution.

This simple Post-It^© note methodology is accomplished by placing each activity on a separate Post-It note, arranging them according to predecessor-successor relationships on a whiteboard (or flipchart), and drawing arrows that show the type of dependency. Experience has shown that using the manual Post-It^© note method allows the project team to collaborate until a unified vision of project execution emerges. As the team negotiates how task execution is related – adding, removing and rearranging Post-It^© notes – their understanding of project success being related to their interdependency becomes clear. Because it is a simple, graphic, and interactive method, it draws out the optimum level of contribution from each team member. Quite often it also reveals aspects of the interdependence of team members’ responsibilities that weren't apparent to every team member initially.

Of course, since drawing the arrows defines the type of dependency, and since there are four types of dependencies – One-to-One, One-to-Many, Many-to-One, and Many-to-Many – and they are each diagrammed differently (Exhibit 2), it is necessary to know and understand the definitions of each of the types of dependencies.

They are:

• One-to-One means that one, and only one, activity must be completed before the next activity can begin. For example, drywall must be installed before it can be painted (in standard residential construction) but once it is installed painting may begin without the completion of any other activity.
• One-to-Many means that one, and only one, activity must be completed before multiple follow-on activities can begin. For instance, plans must be approved before either permits can be obtained or site preparation can be started (in residential construction).
• Many-to-One means that each and every one of two or more tasks must be completed before a subsequent task can begin. As an example, the completion of both the engineering design and the manufacturing design are required before production is started in many industries.
• Many-to-Many means that each and every one of two or more tasks must be completed before multiple subsequent tasks can begin. As an example, many times both software code and copyright registration must receive final approval before either marketing or production is started.

Exhibit 2 – Relationship Dependencies

Step-bv-Step Network Diagramming

The process of creating a logic network diagram follows three steps: 1. Document the activities. 2. Represent the dependencies using arrows in a diagram. 3. Evaluate the logic for accuracy.

Step 1 – Document Activities

This step of the process is actually simplified by creation of the WBS. Normally, creating the WBS precedes developing the logic network so all that is required is transcribing the activities onto Post-It notes.

Step 2 – Represent the Dependencies

This step is the key to a viable logic network diagram that represents project work execution. Dependencies must accurately depict the relationship between activities, therefore the team arranges and rearranges the Post-It notes on each path until they represent the work execution vision. Then the arrows are drawn to crystallize the vision.

Step 3 – Evaluate the Logic.

The most important purpose of a network diagram is to allow the project manager and team to anticipate problems before they happen, eliminate their causes or mitigate their impact, and decrease the need for crisis management. To do so the PM must understand whether each dependency is subject to “hard” logic or “soft” logic. Hard logic means that due to the relationship between a given activity and subsequent activities, it must precede them. For example, constructing the hull of a ship must occur before building the decks. Soft logic, on the other hand, means that due to the relationship between a given activity and subsequent activities, the order of execution may change from project to project. For example, when building a home, installing the kitchen cabinets may or may not happen before installing the bathroom vanities.

However, in order to be truly professional we need to do more than use intuition or “gut feel” to evaluate the logic network. We need to apply a tool that quantifies and analyzes the time critical elements of the schedule.

Schedule Anaylsis

Understanding and managing the critical path allows a project manager to direct resources to where they can best help the project stay on schedule, while balancing the cost and value of those trade-offs. When a logic network is created it identifies activities happening simultaneously in different facets of the project. For example, there may be activities producing customer deliverables, there may be activities producing supporting documentation, and there may be activities assuring the quality of the other two facets. These different activities often occur on separate “paths” of the logic network running both sequentially and in parallel. In addition, cross-functional dependencies create a potentially intricate web of dependencies crossing between paths.

CPM helps us ascertain two vital pieces of knowledge and communicate them to all stakeholders. First, which activities, if allowed to slip, will cause a directly related slip in the completion date of the project. Second, which activities can directly improve the total performance of the project if different and/or additional resources are applied to them, or if dependencies are changed.

Among the web of paths that represent work execution, one represents the shortest time to complete the project. It is the critical path because if the duration of any activity is under-estimated or there is a delay in beginning any activity on this path, it will cause a delay in the completion of the project. The duration and start date of every activity on the critical path is time critical, regardless of whether the activity is of high importance or mundane.

Step-by-Step CPM

Applying CPM using the Post-It^© note methodology has five steps. 1. Convert the network to a CPM flowchart. Calculate the (2) Forward Pass, the (3) Backward Pass, and the (4) Float. 5. Highlight the Critical Path.

Step 1 – Convert Logic Network to CPM Flowchart.

To convert the network into a CPM flowchart each activity is listed on a separate CPM Diagramming Box which has multiple cells of information (and all of the cells apply to one, and only one, activity).

The process of creating a diagramming box Post-It^© note requires writing the Activity Name, Activity Owner, and Estimated Duration in the proper cells. At first only those three can be provided. Then each of the other cells – Early Start Date, Early Finish Date, Late Start Date, Late Finish Date, and Float – are filled in as the calculations are completed.

The illustration below shows a nine-cell diagramming box (Exhibit 3). One reason this method uses a nine-cell diagramming box is that a (3” x 5”) Post-It^© note can be easily converted by drawing two vertical lines and two horizontal lines. Another reason is that the initial analysis will use eight of the cells, and when we apply more advanced methods the entire nine cells are used.

Exhibit 3 – Nine-cell Diagramming Box

The definitions of the first three cells to be completed are:

• Activity Name is a unique description often in the WBS.
• Activity Owner is the person responsible for the final estimate and reporting work progress during execution. It may be the actual worker or a supervisor who is part of the project team.
• Duration is the level-of-effort required to complete the activity expressed in a consistent unit-of-measure (such as hours, days, weeks, or months).

The definitions of the next two cells to be completed, as part of the Forward Pass calculation, are:

• Early Start Date is the earliest date on which all preceding activities will be complete thereby allowing work to begin on the designated activity.
• Early Finish Date is the earliest date when all work can be completed for the designated activity.

Step 2 – Conduct a ‘Forward Pass’ calculation.

Calculating the critical path begins with a sequential “forward pass” through the entire network. The forward pass calculation applies the equation Early Start plus Duration equals Early Finish (ES + D = EF) through the entire network from the start to the finish. By definition, the early start value of the very first activity is zero.

For one-to-one dependencies, the early finish value for each predecessor is carried forward as the early start value of the successor, as shown in the illustration (Exhibit 4).

Exhibit 4 – Forward Pass, 1 to 1

For one-to-many dependencies, the early finish value of the predecessor is carried forward as the early start value for all successors, as shown in Exhibit 5.

Exhibit 5 – Forward Pass, 1 to Many

For many-to-one and many-to-many dependencies, the largest early finish value from amongst all predecessors is carried forward as the early start value for all successors. In all three cases, the result of each calculation is recorded in the appropriate cell.

The definitions of the next two cells to be completed, as part of the Backward Pass calculation, are:

• Late Start Date is the latest date when work can begin without delaying the completion of the project.
• Late Finish Date is the latest date when work can be completed without delaying project completion.

Step 3 – Conduct a ‘Backward Pass’ calculation.

The next calculation in CPM is the reverse-sequential “backward pass” through the entire network. The backward pass calculation applies the equation Late Finish minus Duration equals Late Start (LF - D = LS) through the entire network, in reverse order, from the finish to the start. By definition, the late finish value for the last activity is derived (or copied) from the early finish value of the same activity. For one-to-one dependencies, the late finish value of the predecessor is carried back from the late start value of the successor (Exhibit 6).

Exhibit 6 – Backward Pass, 1 to 1

For one-to-many dependencies, the late finish value for all predecessors is carried back from the late start value of the successor. For many-to-many and many-to-one dependencies, the late finish value for all predecessors is carried back from the smallest late start value of the successors. The result of each calculation is recorded in the appropriate cell. The entire backward pass calculation should be completed before the float calculation is started.

The definition of the final cell to be completed, as part of the Float calculation, is:

• Float is the number of time periods the early start can be delayed, or duration can be extended, without delaying the completion of the project.

Step 4 – Calculate Float.

The last calculation establishes the Float. The calculation is Late Finish minus Early Finish equals Float (LF - EF = F). The calculation for each activity is independent of every other activity. Therefore, the float calculations may be done sequentially or in parallel. The result of each calculation is recorded in the appropriate cell (Exhibit 7).

Exhibit 7 – Float Calculation

Step 5 – Highlight the Critical Path.

Once the calculations have been completed, the Critical Path can be identified by tracing the path of activities with zero float. The normal convention is to highlight the arrows connecting the activities with a red marker. In the illustration below the Critical Path runs from Check Mirrors to Answer Cell to Steer Car (Exhibit 8).

Exhibit 8 – Highlight Critical Path

Schedule Management

In many organizations when the project is given to the project manager a delivery date has been established. It is precisely this assumption that must be tested, and if the delivery date is unrealistic then the project manager must present a rational for altering that expectation to the customer, marketing team and any other key stakeholders.

Schedule management is where experience and judgment combine with quantified observations to find opportunities and identify risks. Doing the analysis and making any needed changes so the schedule is realistic is the first part of schedule management. Responding to variances in actual work execution and finding ways to maintain adherence to the original schedule is the second part. The third part is developing a revised schedule when a scope change has been authorized by the Customer. When a scope change is approved and a revised schedule developed the feedback loop returns to the second part of the process.

Part One – Analysis of Needed Changes

When the Project Team was estimating durations for each work package, in order to be conservative, more often than not they added some time as a “buffer” against the risk of unexpected issues. The result is a schedule with an oversize buffer due to a “compounding” effect which, while normal, must be eliminated. So even though initial estimates can be done individually, final estimates need to be defined during the team exercise of analyzing the schedule. The final schedule must be the result that integrates all aspects of work execution and consciously inserts buffers that correspond with identified risks.

In practice the team gathers in a conference room and the activity owner explains the work that will be executed to convert the input into the output. The team determines that the same work is not being included twice and that the estimated duration is reasonable. For many team members who have never participated in this type of review before there may be initial shock at how rational the process is, how impartial the calculations are, and how quickly overstated estimates put the activity (and owner) on the critical path for closer scrutiny by the project manager.

The team also considers whether redefining the logic will benefit the work execution. In practice the PM and team move the Post-It notes into different combinations of relationships, adjust the durations to account for any tasks that are added or removed due to the change in execution methodology and then calculate the new schedule to see if the change results in an improved delivery. When they find a schedule they feel represents an improvement they document it as an option. They continue the process until they choose the one they feel represents the best choice for speed and efficiency.

Once the logic has been optimized for efficiency it needs to be reviewed for risk. In practice the first thing to observe is whether the project has multiple critical paths. Having multiple critical paths automatically increases the risk inherent in the project because it explicitly demonstrates that work execution for many work packages is time critical. When this situation exists the PM will usually find it advantageous to maneuver relationships or adapt work packages until the schedule has only one critical path.

A second risk factor to observe is when too many activities on the critical path are the responsibility of the same function or department or person. When this condition exists the PM needs to appraise the risk the situation presents and how to respond appropriately. If this situation exists on the critical path, the PM and team should consider changes that would take the activities off the critical path.

Part Two – Responding to Variances

Once the task of manually creating the schedule has been completed, transferring that data into appropriate software to manage execution – including changes and performance variances – throughout the life of the project is both urgent and important.

Two big advantages emerge from the work done by the project team to develop the logic network and run an initial set of critical path calculations. First, the manual flowchart serves as a proof to error check the results produced by the software. This protects the project from harm caused by reporting from a defective baseline.

With a properly developed Project Baseline correctly recorded in the software the project manager can begin reviewing the results of actual work execution as it is available. The project manager's focus is on whether the schedule is ahead or behind, and whether the budget is under or over, the baseline. To understand the schedule data the project manager will need to analyze if the durations or actual start dates are driving the ahead or behind state. The project manager's response to any of these situations is to decide whether the variance is within tolerable limits and to begin analyzing the possible actions that can be used to return the work execution to the desired state.

Part Three – Revisions for Scope Changes

As the project manager supervises work execution in addition to responding to variances they will encounter situations where the customer requires a significant change to the originally planned project deliverables. These changes may be an increase or decrease in requirements. It is incumbent on the project manager and team to evaluate the changes impact on the time and cost of the project and develop a new schedule for customer approval before it becomes the new baseline. When they do approve it the new schedule needs to be designated as the baseline in the software.

Conclusion

Beyond these basic ideas, advanced schedule management techniques are where we create BIG value, but that is the subject of another paper for another day.