Project scheduling assignment

Chapter6.docx

Home >Business & Finance homework help >Management homework help >Project scheduling assignment

188 Chapter 6

Chapter 6

I keep six honest serving-men (they taught me all I knew); their names are What and Why and When and How and Where and Who.—Rudyard Kipling6.1 Developing the Project Network The project network is the tool used for planning, scheduling, and monitoring project progress. The network is developed from the information collected for the WBS and is a graphic flow chart of the project job plan. The network depicts the project activities that must be completed, the logical sequences, the interdependencies of the activities to be completed, and in most cases the times for the activities to start and finish along with the longest path(s) through the network—the critical path. The network is the framework for the project information system that will be used by the project managers to make decisions concerning project time, cost, and performance. Developing the project networks takes time for someone or some group to develop; therefore, they cost money! Are networks really worth the struggle? The answer is Projectnetworks6Managingrisk7Monitoringprogress13Teams11Outsourcing12Projectmanager10Strategy2Introduction1Organization3Scheduleresources & costs8Internationalprojects15Agile PM16Projectclosure14Estimate5Reducingduration9Deﬁneproject4

definitely yes, except in cases where the project is considered trivial or very short in duration.1 The network is easily understood by others because the network presents a graphic display of the flow and sequence of work through the project. Once the net-work is developed, it is very easy to modify or change when unexpected events occur as the project progresses. For example, if materials for an activity are delayed, the impact can be quickly assessed and the whole project revised in only a few minutes with the computer. These revisions can be communicated to all project participants quickly (for example, via e-mail or project website). The project network provides other invaluable information and insights. It provides the basis for scheduling labor and equipment. It enhances communication that melds all managers and groups together in meeting the time, cost, and performance objectives of the project. It provides an estimate of project duration rather than picking a project completion date from a hat or someone’s preferred date. The network gives the times when activities can start and finish and when they can be delayed. It provides the basis for budgeting the cash flow of the project. It identifies which activities are “critical” and, therefore, should not be delayed if the project is to be completed as planned. It highlights which activities to consider if the project needs to be compressed to meet a deadline. There are other reasons project networks are worth their weight in gold. Basically, project networks minimize surprises by getting the plan out early and allowing correc-tive feedback. A commonly heard statement from practitioners is that the project net-work represents three-quarters of the planning process. Perhaps this is an exaggeration, but it signals the perceived importance of the network to project managers in the field.6.2 From Work Package to Network Project networks are developed from the WBS. The project network is a visual flow diagram of the sequence, interrelationships, and dependencies of all the activities that must be accomplished to complete the project. An activity is an element in the project that consumes time—for example, work or waiting. Work packages from the WBS are used to build the activities found in the project network. An activity can include one or more work packages. The activities are placed in a sequence that provides for orderly completion of the project. Networks are built using nodes (boxes) and arrows (lines). Integrating the work packages and the network represents a point where the man-agement process often fails in practice. The primary explanations for this failure are that (1) different groups (people) are used to define work packages and activities and (2) the WBS is poorly constructed and not deliverable/output oriented. Integration of the WBS and project network is crucial to effective project management. The project manager must be careful to guarantee continuity by having some of the same people who defined the WBS and work packages develop the network activities. Networks provide the project schedule by identifying dependencies, sequencing, and timing of activities, which the WBS is not designed to do. The primary inputs for devel-oping a project network plan are work packages. Remember, a work package is defined independently of other work packages, has definite start and finish points, requires spe-cific resources, includes technical specifications, and has cost estimates for the package. However, dependency, sequencing, and timing of each of these factors are not included in the work package. A network activity can include one or more work packages. Understand the linkage between WBS and the project network.6-1LO1 This process could be clariﬁed and improved by using a simple responsibility matrix (see Chapter 4).

164 Chapter 6 Developing a Project Plan definitely yes, except in cases where the project is considered trivial or very short in duration.1 The network is easily understood by others because the network presents a graphic display of the flow and sequence of work through the project. Once the net-work is developed, it is very easy to modify or change when unexpected events occur as the project progresses. For example, if materials for an activity are delayed, the impact can be quickly assessed and the whole project revised in only a few minutes with the computer. These revisions can be communicated to all project participants quickly (for example, via e-mail or project website). The project network provides other invaluable information and insights. It provides the basis for scheduling labor and equipment. It enhances communication that melds all managers and groups together in meeting the time, cost, and performance objectives of the project. It provides an estimate of project duration rather than picking a project completion date from a hat or someone’s preferred date. The network gives the times when activities can start and finish and when they can be delayed. It provides the basis for budgeting the cash flow of the project. It identifies which activities are “critical” and, therefore, should not be delayed if the project is to be completed as planned. It highlights which activities to consider if the project needs to be compressed to meet a deadline. There are other reasons project networks are worth their weight in gold. Basically, project networks minimize surprises by getting the plan out early and allowing correc-tive feedback. A commonly heard statement from practitioners is that the project net-work represents three-quarters of the planning process. Perhaps this is an exaggeration, but it signals the perceived importance of the network to project managers in the field.6.2 From Work Package to NetworkProject networks are developed from the WBS. The project network is a visual flow diagram of the sequence, interrelationships, and dependencies of all the activities that must be accomplished to complete the project. An activity is an element in the project that consumes time—for example, work or waiting. Work packages from the WBS are used to build the activities found in the project network. An activity can include one or more work packages. The activities are placed in a sequence that provides for orderly completion of the project. Networks are built using nodes (boxes) and arrows (lines). Integrating the work packages and the network represents a point where the man-agement process often fails in practice. The primary explanations for this failure are that (1) different groups (people) are used to define work packages and activities and (2) the WBS is poorly constructed and not deliverable/output oriented. Integration of the WBS and project network is crucial to effective project management. The project manager must be careful to guarantee continuity by having some of the same people who defined the WBS and work packages develop the network activities. Networks provide the project schedule by identifying dependencies, sequencing, and timing of activities, which the WBS is not designed to do. The primary inputs for devel-oping a project network plan are work packages. Remember, a work package is defined independently of other work packages, has definite start and finish points, requires spe-cific resources, includes technical specifications, and has cost estimates for the package. However, dependency, sequencing, and timing of each of these factors are not included in the work package. A network activity can include one or more work packages. Understand the linkage between WBS and the project network.6-1LO1 This process could be clariﬁed and improved by using a simple responsibility matrix (see Chapter 4).Lar66093_ch06_162-205.indd 16415/10/16 2:04 PM174Larson FIGURE 6.1WBS/Work Packages to Network CircuitboardLowestelementDesigncostaccountOrganizationUnitsProductioncostaccountTestcostaccountSoftwarecostaccountAD -1-1D -1-2DesignWP D-1-1 Speciﬁcations WP D-1-2 Documentation Production WP P-10-1 Proto 1WP P-10-2 Final Proto 2Test systems WP T-13-1 Test Software WP S-22-1 Software preliminary WPS-22-2 Software ﬁnal version BP -10-1CS -22-1DP -10-2Activity network for circuit board work packages FS -22-2KT -13-1ASpeciﬁcationsand documentation2BProto 15CSoftwarepreliminary3DFinalproto 24FFinalsoftware2KTest3 Figure 6.1 shows a segment of the WBS example and how the information is used to develop a project network. The lowest level deliverable in Figure 6.1 is “circuit board.” The cost accounts (design, production, test, software) denote project work, organiza-tion unit responsible, and time-phased budgets for the work packages. Each cost account represents one or more work packages. For example, the design cost account has two work packages (D-1-1 and D-1-2)—specifications and documentation. The software and production accounts also have two work packages. Developing a network requires sequencing tasks from all work packages that have measurable work. Figure 6.1 traces how work packages are used to develop a project network. You can trace the use of work packages by the coding scheme. For example, activity A uses work packages D-1-1 and D-1-2 (specifications and documentation), while activity C

uses work package S-22-1. This methodology of selecting work packages to describe activities is used to develop the project network, which sequences and times project activities. Care must be taken to include all work packages. The manager derives activ-ity time estimates from the task times in the work package. For example, activity B (proto 1) requires five weeks to complete; activity K (test) requires three weeks to complete. After computing the activity early times and late times, the manager can schedule resources and time-phase budgets (with dates).6.3 Constructing a Project Network Terminology Every field has its jargon that allows colleagues to communicate comfortably with each other about the techniques they use. Project managers are no exception. Here are some terms used in building project networks.Activity. For project managers, an activity is an element of the project that requires time. It may or may not require resources. Typically, an activity consumes time—either while people work or while people wait. Examples of the latter are time waiting for contracts to be signed, materials to arrive, drug approval by the government, budget clearance, etc. Activities usually represent one or more tasks from a work package. Descriptions of activities should use a verb/noun format: for example, develop product specifications. Merge Activity. This is an activity that has more than one activity immediately preceding it (more than one dependency arrow flowing to it).Parallel Activities. These are activities that can take place at the same time, if the manager wishes. However, the manager may choose to have parallel activities not occur simultaneously. Path. A sequence of connected, dependent activities. Critical Path. When this term is used, it means the path(s) with the longest dura-tion through the network; if an activity on the path is delayed, the project is delayed the same amount of time. Burst Activity. This activity has more than one activity immediately following it (more than one dependency arrow flowing from it).Basic Rules to Follow in Developing Project Networks The following eight rules apply in general when developing a project network:1. Networks flow typically from left to right.2. An activity cannot begin until all preceding connected activities have been completed.3. Arrows on networks indicate precedence and flow. Arrows can cross over each other.4. Each activity should have a unique identification number.5. An activity identification number must be larger than that of any activities that precede it.6. Looping is not allowed (in other words, recycling through a set of activities cannot take place).7. Conditional statements are not allowed (that is, this type of statement should not appear: If successful, do something; if not, do nothing).8. Experience suggests that when there are multiple starts, a common start node can be used to indicate a clear project beginning on the network. Similarly, a single project end node can be used to indicate a clear ending.

Read the Snapshot from Practice 6.1: The Yellow Sticky Approach to see how these rules are used to create project networks.6.4 Activity-on-Node (AON) Fundamentals Historically, two methods have been used to develop project networks: Activity-on-node (AON) and Activity-on-arrow (AOA). Over time the availability of advanced computer graphics improved the clarity and visual appeal of the AON method. Today, the activity-on-node method has come to dominate nearly all project network plans. For this reason, we have limited our discussion to AON methods. Figure 6.2 shows a few typical uses of building blocks for the AON network In practice small project networks (25 to 100 activities) are frequently devel-oped using yellow Post-it® stickers. The meeting requirements and process for the project team are described herein. The following are the requirements for such a project:1. Project team members and a facilitator.2. One yellow sticker (3 × 4 inches or larger) for each activity with the description of the activity printed on the sticker.3. Erasable whiteboard with marker pen (a long, 4-foot-wide piece of butcher paper can be used in place of the whiteboard).All of the yellow stickers are placed in easy view of all team members. The team begins by identifying those activity stickers that have no predecessors. Each of these activity stickers is then attached to the white-board. A start node is drawn, and a dependency arrow is connected to each activity. Given the initial network start activities, each activ-ity is examined for immediate successor activities. These activities are attached to the whiteboard and dependency arrows drawn. This process is continued until all of the yellow stickers are attached to the white-board with dependency arrows. (Note: The process can be reversed, beginning with those activities that have no successor activities and connecting them to a proj-ect end node. The predecessor activities are selected for each activity and attached to the whiteboard with dependency arrows marked.) When the process is complete, the dependencies are recorded in the project software, which develops a computer-designed network along with the critical path(s) and early, late, and slack times. This methodol-ogy sensitizes team members early to the interdepen-dencies among activities of the project. But more importantly, the methodology empowers team mem-bers by giving them input to the important decisions that they must implement later.SNAPSHOT FROM PRACTICE 6.1The Yellow Sticky Approach (for Constructing a Project Network)© Image Source/Alamy

FIGURE 6.2Activity-on-Node Network FundamentalsABCA is preceded by nothing B is preceded by A C is preceded by BXZYY and Z are preceded by XY and Z can begin at the same time, if you wish(A)(B)X is a burst activityM is a merge activity(C)(D)KMLJJ, K, & L can all begin at the same time, if youwish (they need not occur simultaneously)butAll (J, K, L) must be completed before M canbeginXZYAAZ is preceded by X and YAA is preceded by X and Yconstruction. An activity is represented by a node (box). The node can take many forms, but in recent years the node represented as a rectangle (box) has dominated. The dependencies among activities are depicted by arrows between the rectangles (boxes) on the AON network. The arrows indicate how the activities are related and the sequence in which things must be accomplished. The length and slope of the arrow are arbitrary and set for convenience of drawing the network. The letters in the boxes serve here to identify the activities while you learn the fundamentals of network construction and analysis. In practice, activities have identification num-bers and descriptions. There are three basic relationships that must be established for activities included in a project network. The relationships can be found by answering the following three questions for each activity:1. Which activities must be completed immediately before this activity? These activi-ties are called predecessor activities.2. Which activities must immediately follow this activity? These activities are called successor activities.3. Which activities can occur while this activity is taking place? This is known as a concurrent or parallel relationship.

Sometimes a manager can use only questions 1 and 3 to establish relationships. This information allows the network analyst to construct a graphic flow chart of the sequence and logical interdependencies of project activities. Figure 6.2A is analogous to a list of things to do where you complete the task at the top of the list first and then move to the second task, etc. This figure tells the project manager that activity A must be completed before activity B can begin, and activity B must be completed before activity C can begin. Figure 6.2B tells us that activities Y and Z cannot begin until activity X is com-pleted. This figure also indicates that activities Y and Z can occur concurrently or simultaneously if the project manager wishes; however, it is not a necessary condition. For example, pouring a concrete driveway (activity Y) can take place while landscape planting (activity Z) is being accomplished, but land clearing (activity X) must be completed before activities Y and Z can start. Activities Y and Z are considered paral-lel activities. Parallel paths allow concurrent effort, which may shorten time to do a series of activities. Activity X is sometimes referred to as a burst activity because more than one arrow bursts from the node. The number of arrows indicates how many activi-ties immediately follow activity X. Figure 6.2C shows us activities J, K, and L can occur simultaneously if desired, and activity M cannot begin until activities J, K, and L are all completed. Activities J, K, and L are parallel activities. Activity M is called a merge activity because more than one activity must be completed before M can begin. Activity M could also be called a milestone—a significant accomplishment. In Figure 6.2D, activities X and Y are parallel activities that can take place at the same time; activities Z and AA are also parallel activities. But activities Z and AA cannot begin until activities X and Y are both completed. Given these fundamentals of AON, we can practice developing a simple network. Remember, the arrows can cross over each other (e.g., Figure 6.2D), be bent, or be any length or slope. Neatness is not a criterion for a valid, useful network—only accurate inclusion of all project activities, their dependencies, and time estimates. Information for a simplified project network is given in Table 6.1. This project rep-resents a new automated warehouse system for picking frozen food package orders and moving them to a staging area for delivery to stores. Figure 6.3 shows the first steps in constructing the AON project network from the information in Table 6.1. We see that activity A (define requirements) has nothing preceding it; therefore, it is the first node to be drawn. Next, we note that activities B and C (assign team and design hardware) are both preceded by activity A. We draw two arrows and connect them to activities B and C. This segment shows

6.1Network Information AUTOMATED WAREHOUSE Order Picking System Activity Description Preceding ActivityA Deﬁne Requirements NoneB Assign Team AC Design Hardware AD Code Software BE Build and Test Hardware CF Develop Patent Request CG Test Software DH Integrate Systems E, F, G 170 Chapter 6 Developing a Project Planthe project manager that activity A must be completed before activities B and C can begin. After A is completed, B and C can take place concurrently, if desired. Figure 6.4 shows the completed network with all of the activities sequences and dependencies. The information in Figure 6.4 is tremendously valuable to those managing the proj-ect. However, estimating the duration for each activity will further increase the value of the network. A realistic project plan and schedule require reliable time estimates for project activities. The addition of time to the network allows us to estimate how long the project will take. When activities can or must start, when resources must be avail-able, which activities can be delayed, and when the project is estimated to be complete are all determined from the times assigned. Deriving an activity time estimate neces-sitates early assessment of resource needs in terms of material, equipment, and people. In essence the project network with activity time estimates links planning, scheduling, and controlling of projects.Automated Warehouse Order Picking SystemDeﬁneRequirementsDesignHardwareAssignTeamBACFIGURE 6.3Automated Warehouse—Partial NetworkAutomated WarehouseOrder Picking SystemAFDevelop PatentRequestCEHDeﬁneRequirementsDesignHardwareBuild & TestHardwareIntegrateSystemsAssignTeamCodeSoftwareDGTestSoftwareBFIGURE 6.4 Automated Warehouse—Completed NetworkLar66093_ch06_162-205.indd 17015/10/16 2:04 PM180Larson

Calculate early, late, and slack activity times.6-3LO6.5 Network Computation Process Drawing the project network places the activities in the right sequence for computing start and finish times of activities. Activity time estimates are taken from the task times in the work package and added to the network (review Figure 6.1). Performing a few simple computations allows the project manager to complete a process known as the forward and backward pass. Completion of the forward and backward pass will answer the following questions: Forward Pass—Earliest Times1. How soon can the activity start? (early start—ES)2. How soon can the activity finish? (early finish—EF)3. How soon can the project be finished? (expected time—TE)Backward Pass—Latest Times1. How late can the activity start? (late start—LS)2. How late can the activity finish? (late finish—LF)3. Which activities represent the critical path (CP)? This is the longest path in the network which, when delayed, will delay the project.4. How long can the activity be delayed? (slack or float—SL)The terms in parentheses represent the acronyms used in most texts and computer pro-grams and by project managers. The forward and backward pass process is presented next. Forward Pass—Earliest TimesThe forward pass starts with the first project activity(ies) and traces each path (chain of sequential activities) through the network to the last project activity(ies). As you trace along the path, you add the activity times. The longest path denotes the project completion time for the plan and is called the critical path (CP). Table 6.2 lists the activity times in workdays for the Automated Warehouse project example we used for drawing a network. Figure 6.5 shows the network with the activity time estimate found in the node (see “DUR” for duration in the legend). For example, activity A (define requirements) has an activity duration of 10 workdays, and activity E (build and test hardware) has a duration of 50 days. The forward pass begins with the project start time, which is usually time zero. (Note: Calendar times can be computed for the project later in the planning phase.)

mated Warehouse example, the early start time for the first activity (activity A) is zero. This time is found in the upper left corner of the activity A node in Figure 6.6. The early finish for activity A is 10 days (EF = ES + DUR or 0 + 10 = 10). Next, we see that activity A is the predecessor for activities B (assign team) and C (design hardware). Therefore, the earliest activities B and C can begin is the instant in time when activity A is completed; this time is 10 days. You can now see in Figure 6.6 that activities B and C have an early start (ES) of 10 days. Using the formula EF = ES + DUR, the early finish (EF) times for activities B and C are 15 and 35 days. Fol-lowing the same process of moving along each network path, the early start and finish times for selected activities are shown here:Activity D: ES = 15EF = 15 + 20 = 35Activity F: ES = 35EF = 35 + 15 = 50Activity E: ES = 35EF = 35 + 50 = 85Activity G: ES = 35EF = 35 + 35 = 70 Activity H (integrate system) is a merge activity because it is preceded by more than one activity. The early start (ES) of a merge activity depends on the early finish (EF) of all activities that merge to it. In this project activity H is preceded by activities E, F, and G. Which activity controls the ES of activity H? The answer is activity E. In Figure 6.6 the EF times are 85, 50, and 70. Since 85 days is the largest EF time, activ-ity E controls the ES for activity H, which is 85. If activity E is delayed, activity H will be delayed. The early finish for activity H or the project is 100 days (EF = ES + DUR or 85 + 15 = 100).FIGURE 6.5 Activity-on-Node Network Automated WarehouseOrder Picking SystemA10IDLegendDUR ESLSEFLFSLF15E50H15B5D20G35DeﬁneRequirementsBuild & TestHardwareIntegrateSystemsAssignTeamCodeSoftwareTestSoftwareDevelop PatentRequestDesignHardware

The forward pass requires that you remember just three things when computing early activity times:1. You add activity times along each path in the network (ES + DUR = EF).2. You carry the early finish (EF) to the next activity where it becomes its early start (ES), or3. If the next succeeding activity is a merge activity, you select the largest early finish number (EF) of all its immediate predecessor activities.The three questions derived from the forward pass have been answered; that is, early start (ES), early finish (EF), and the project expected duration (TE) times have been computed. The backward pass is the next process to learn.Backward Pass—Latest TimesThe backward pass starts with the last project activity(ies) on the network. You trace backward on each path subtracting activity times to find the late start (LS) and late finish (LF) times for each activity. Before the backward pass can be computed, the late finish for the last project activity(ies) must be selected. In early planning stages, this time is usually set equal to the early finish (EF) of the last project activity (or in the case of multiple finish activities, the activity with the largest EF). In some cases an imposed project duration deadline exists, and this date will be used. Let us assume for planning purposes we can accept the EF project duration (TE) equal to 100 workdays. The LF for activity H becomes 100 days (EF = LF) (see Figure 6.7).Automated WarehouseOrder Picking SystemA10100F355015E503585H8585507010015B10155D153520G357035Build & TestHardwareIntegrateSystemAssignTeamCodeSoftwareTestSoftwareDevelop PatentRequestDesignHardwareC251035IDLegendDURDescriptionESLSEFLFSLDeﬁneRequirementsFIGURE 6.6 Activity-on-Node Network Forward Pass

d pass is similar to the forward pass; you need to remember three things:1. You subtract activity times along each path starting with the project end activity (LF − DUR = LS).2. You carry the LS to the preceding activity to establish its LF, or3. If the next preceding activity is a burst activity; in this case you select the smallest LS of all its immediate successor activities to establish its LF.Let’s apply these rules to our Automated Warehouse example. Beginning with activ-ity H (integrate systems) and a LF of 100 workdays, the LS for activity H is 85 days (LF − DUR = LS or 100 − 15 = 85). The LS for activity H becomes the LF for activi-ties E, F, and G. Moving backward on the network the late starts for E, F, and G are shown here (LS = LF − DUR):Activity E: LS = 85 − 50 = 35Activity G: 85 − 35 = 50Activity F: LS = 85 − 15 = 70At this point we see that activity C is a burst activity that ties to (precedes) activities E and F. The late finish for activity C is controlled by the LS of activities E and F. The smallest LS of activities E and F (LS’s = 35 and 70) is activity E. This establishes the LF for activity C. The LS for activity C becomes 10. Moving backward to the first project activity, we note it is also a burst activity that links to activities B and C. The FIGURE 6.7 Activity-on-Node Network Backward Pass B52530AssignTeamC251035A1001010253570DeﬁneRequirementsD203050CodeSoftwareE503585Build & TestHardwareF157085DevelopPatent RequestH1585100IntegrateSystemsG355085Automated WarehouseOrder Picking SystemIDLegendDURDescriptionESLSEFLFSLDesignHardwareTestSoftware

Developing a Project Planas those activities that also have LF = EF or a slack of zero (LF − EF = 0 or LS − ES = 0). The critical path is the network path(s) that has (have) the least slack in com-mon. This awkward arrangement of words is necessary because a problem arises when the project finish activity has a LF that differs from the EF found in the forward pass—for example, an imposed duration date. If this is the case, the slack on the critical path will not be zero; it will be the difference between the project EF and the imposed LF of the last project activity. For example, if the EF for the project is 100 days, but the imposed LF or target date is set at 95 days, all activities on the critical path would have a slack of minus 5 days. Of course, this would result in a late start 5 days for the first project activity—a good trick if the project is to start now. Negative slack occurs in practice when the critical path is delayed. In Figure 6.8 the critical path is marked with dashed arrows—activities A, C, E, and H. Delay of any of these activities will delay the total project by the same num-ber of days. Since actual projects may have many critical activities with numerous preceding dependencies, coordination among those responsible for critical activi-ties is crucial. Critical activities typically represent about 10 percent of the activi-ties of the project. Therefore, project managers pay close attention to the critical path activities to be sure they are not delayed. See Snapshot from Practice 6.2: The Critical Path. We use the term sensitivity to reflect the likelihood the original critical path(s) will change once the project is initiated. Sensitivity is a function of the number of critical or near-critical paths. A network schedule that has only one critical path and noncritical activities that enjoy significant slack would be labeled insensitive. The critical path method (CPM) has long been considered the “Holy Grail” of project management. Here are comments made by veteran project managers when asked about the sig-niﬁcance of the critical path in managing projects:•□I□try□to□make□it□a□point□whenever□possible□to□put□my□best people on critical activities or on those activities that stand the greatest chance of becoming critical.•□I□pay□extra□attention□when□doing□risk□assessment□to□identifying those risks that can impact the critical path, either directly or indirectly, by making a non-critical activity so late that it becomes critical. When I’ve got money to spend to reduce risks, it usually gets spent on critical tasks.•□I□don’t□have□time□to□monitor□all□the□activities□on□a□big project, but I make it a point to keep in touch with the people who are working on critical activi-ties. When I have the time, they are the ones I visit to ﬁnd out ﬁrsthand how things are going. It’s amazing how much more I can ﬁnd out from SNAPSHOT FROM PRACTICE 6.2The Critical Pathtalking to the rank and ﬁle who are doing the work and by reading the facial expressions of people—much more than I can gain from a number-driven status report.•□When□I□get□calls□from□other□managers□asking□to□“borrow” people or equipment, I’m much more generous when it involves resources from working on noncritical activities. For example, if another project manager needs an electrical engineer who is assigned to a task with ﬁve days of slack, I’m will-ing to share that engineer with another project manager for two to three days.•□The□most□obvious□reason□the□critical□path□is□impor-tant is because these are the activities that impact completion time. If I suddenly get a call from above saying they need my project done two weeks ear-lier than planned, the critical path is where I sched-ule the overtime and add extra resources to get the project done more quickly. In the same way, if the project schedule begins to slip, it’s the critical activ-ities I focus on to get back on schedule.Lar66093_ch06_162-205.indd 17615/10/16 2:04 PM186Larson Conversely, a sensitive network would be one with more than one critical path and/or noncritical activities with very little slack. Under these circumstances the original critical path is much more likely to change once work gets under way on the project. How sensitive is the Automated Warehouse schedule? Not very, since there is only one critical path and the two other noncritical paths have 15 and 35 days of slack, which suggests considerable flexibility. Project managers assess the sensitivity of their network schedules to determine how much attention they should devote to man-aging the critical path.Free Slack (Float)Free slack (FS) is unique. It is the amount of time an activity can be delayed without delaying any immediately following (successor) activity. Or, free slack is the amount of time an activity can exceed its early finish date without affecting the early start date of any successor(s). Free slack can never be negative. Only activities that occur at the end of a chain of activities, where you have a merge activity, can have free slack. See Figure 6.8, the Automated Warehouse project. In Figure 6.8 activity G has free slack of 15 days, while activities B and D do not. In this case, activity G is the last activity in the upper path, and it merges to activity H. Hence, to delay activity G up to 15 days does not delay any following activities and requires no coordination with managers of other activities. Conversely, if either activ-ity B or D is delayed, the managers of following activities need to be notified that the slack has been used so they can adjust their start schedules. For example, if activity B is delayed 5 days, the manager of activity B should notify those in charge of the fol-lowing activities (D and G) that their slack has been reduced to 10 time units and their early start will be delayed 5 days. In this example, activity D cannot then start until day 20, which reduces activity D slack to 10 days (LS − ES = SL or 30 − 20 = 10). Free slack for activity G is also reduced to 10 days. Free slack occurs at the last activity in a chain of activities. In some situations the “chain” has only one link. Activity F in Figure 6.8 is an example. It has free slack of 35 days. Note that it needs no coordination with other activities—unless a delay exceeds the free slack of 35 days. (Note: The moment you exceed all free slack avail-able, you delay the project and must coordinate with others who are impacted.) The distinction between free and total slack at first glance seems trivial, but in real-ity it is very important. When you are responsible for a late activity that has zero free slack you impact the schedules of subsequent activities. You should notify the manag-ers of the remaining activities in the chain that you will be late. Again, note that total slack is shared across the whole path. Alternatively, if you are responsible for an activ-ity that has free slack when you start, you do not need to notify anyone as long as your work does not absorb all of the slack!6.6 Using the Forward and Backward Pass InformationReturning to the Automated Warehouse project network in Figure 6.8, what does a slack of 35 days for activity F (develop patent request) mean for the project manager? In this specific case it means activity F can be delayed 35 days. In a larger sense the project manager soon learns that free slack is important because it allows flexibility in scheduling scarce project resources—personnel and equipment—that are used on more than one parallel activity or another project.6-5LODistinguish free slack

Developing a Project Plan 177Conversely, a sensitive network would be one with more than one critical path and/or noncritical activities with very little slack. Under these circumstances the original critical path is much more likely to change once work gets under way on the project. How sensitive is the Automated Warehouse schedule? Not very, since there is only one critical path and the two other noncritical paths have 15 and 35 days of slack, which suggests considerable flexibility. Project managers assess the sensitivity of their network schedules to determine how much attention they should devote to man-aging the critical path.Free Slack (Float)Free slack (FS) is unique. It is the amount of time an activity can be delayed without delaying any immediately following (successor) activity. Or, free slack is the amount of time an activity can exceed its early finish date without affecting the early start date of any successor(s). Free slack can never be negative. Only activities that occur at the end of a chain of activities, where you have a merge activity, can have free slack. See Figure 6.8, the Automated Warehouse project. In Figure 6.8 activity G has free slack of 15 days, while activities B and D do not. In this case, activity G is the last activity in the upper path, and it merges to activity H. Hence, to delay activity G up to 15 days does not delay any following activities and requires no coordination with managers of other activities. Conversely, if either activ-ity B or D is delayed, the managers of following activities need to be notified that the slack has been used so they can adjust their start schedules. For example, if activity B is delayed 5 days, the manager of activity B should notify those in charge of the fol-lowing activities (D and G) that their slack has been reduced to 10 time units and their early start will be delayed 5 days. In this example, activity D cannot then start until day 20, which reduces activity D slack to 10 days (LS − ES = SL or 30 − 20 = 10). Free slack for activity G is also reduced to 10 days. Free slack occurs at the last activity in a chain of activities. In some situations the “chain” has only one link. Activity F in Figure 6.8 is an example. It has free slack of 35 days. Note that it needs no coordination with other activities—unless a delay exceeds the free slack of 35 days. (Note: The moment you exceed all free slack avail-able, you delay the project and must coordinate with others who are impacted.) The distinction between free and total slack at first glance seems trivial, but in real-ity it is very important. When you are responsible for a late activity that has zero free slack you impact the schedules of subsequent activities. You should notify the manag-ers of the remaining activities in the chain that you will be late. Again, note that total slack is shared across the whole path. Alternatively, if you are responsible for an activ-ity that has free slack when you start, you do not need to notify anyone as long as your work does not absorb all of the slack!6.6 Using the Forward and Backward Pass InformationReturning to the Automated Warehouse project network in Figure 6.8, what does a slack of 35 days for activity F (develop patent request) mean for the project manager? In this specific case it means activity F can be delayed 35 days. In a larger sense the project manager soon learns that free slack is important because it allows flexibility in scheduling scarce project resources—personnel and equipment—that are used on more than one parallel activity or another project.6-5LODistinguish free slack from total slack.Lar66093_ch06_162-205.indd 17715/10/16 2:04 PMProject Management: The Managerial Process, Seventh Edition187 Knowing the four activity times of ES, LS, EF, and LF is invaluable for the plan-ning, scheduling, and controlling phases of the project. The ES and LF tell the project manager the time interval in which the activity should be completed. For example, activity G (test software) must be completed within the time interval 35 and 85 days; the activity can start as early as day 35 or finish as late as day 85. Conversely, activity C (design hardware) must start on day 10, or the project will be delayed. When the critical path is known, it is possible to tightly manage the resources of the activities on the critical path so no mistakes are made that will result in delays. In addi-tion, if for some reason the project must be expedited to meet an earlier date, it is pos-sible to select those activities, or combination of activities, that will cost the least to shorten the project. Similarly, if the critical path is delayed and the time must be made up by shortening some activity or activities on the critical path to make up any negative slack, it is possible to identify the activities on the critical path that cost the least to shorten. If there are other paths with very little slack, it may be necessary to shorten activities on those paths also.6.7 Level of Detail for ActivitiesTime-phasing work and budgets of the project mandate careful definition of the activi-ties that make up the project network. Typically an activity represents one or more tasks from a work package. How many tasks you include in each activity sets the level of detail. In some cases it is possible to end up with too much information to manage, and this can result in increased overhead costs. Managers of small projects have been able to minimize the level of detail by eliminating some of the preliminary steps to drawing networks. Larger firms also recognize the cost of information overload and are working to cut down the level of detail in networks and in most other dimensions of the project.6.8 Practical ConsiderationsNetwork Logic ErrorsProject network techniques have certain logic rules that must be followed. One rule is that conditional statements such as “if test successful build proto, if failure redesign” are not permitted. The network is not a decision tree; it is a project plan that we assume will materialize. If conditional statements were allowed, the forward and backward pass would make little sense. Although in reality a plan seldom materializes as we expect in every detail, it is a reasonable initial assumption. You shall see that once a network plan is developed, it is an easy step to make revisions to accommodate changes. Another rule that defeats the project network and computation process is looping. Looping is an attempt by the planner to return to an earlier activity. Recall that the activity identification numbers should always be higher for the activities following an activity in question; this rule helps to avoid the illogical precedence relationships among the activities. An activity should only occur once; if it is to occur again, the activity should have a new name and identification number and should be placed in the right sequence on the network. Figure 6.9 shows an illogical loop. If this loop were allowed to exist, this path would perpetually repeat itself. Many computer programs catch this type of logic error.

Activity NumberingEach activity needs a unique identification code—a letter or a number. In practice very elegant schemes exist. Most schemes number activities in ascending order, that is, each succeeding activity has a larger number so that the flow of the project activities is toward project completion. It is customary to leave gaps between numbers (1, 5, 10, 15 . . .). Gaps are desirable so you can add missing or new activities later. Because it is nearly impossible to draw a project network perfectly, numbering networks is fre-quently not done until after the network is complete. In practice you will find computer programs that accept numeric, alphabetic, or a com-bination of activity designations. Combination designations are often used to identify cost, work skill, departments, and locations. As a general rule, activity numbering systems should be ascending and as simple as possible. The intent is to make it as easy as you can for project participants to follow work through the network and locate specific activities.Use of Computers to Develop NetworksAll of the tools and techniques discussed in this chapter can be used with computer software currently available. Two examples are shown in Figures 6.10 and 6.11. Figure 6.10 presents a generic AON computer output for the Automated Warehouse Picking Sys-tem project. Observe that these computer outputs use numbers to identify activities. The critical path is identified by the nodes (activities) 2, 4, 6, and 9. The activity description is shown on the top line of the activity node. The activity start time and identification are on the second line. The finish time and duration are on the third line of the node. The project starts on January 1 and is planned to finish May 20. Note this sample computer network has included non-workdays of holidays and weekends. Figure 6.11 presents an early start Gantt chart.2 Bar charts are popular because they present an easy-to-understand, clear picture on a time-scaled horizon. They are used dur-ing planning, resource scheduling, and status reporting. The format is a two-dimensional representation of the project schedule, with activities down the rows and time across the horizontal axis. In this computer output the shaded bars represent the activity durations. The extended lines from the bars represent slack. For example, “test software” (ID # 8) has a duration of 35 days (shaded area of the bar) and 15 days slack (represented by the extended line). The bar also indicates test software has an early start of February 19 and would finish April 8, but can finish as late as April 29 because it has 15 days of slack. When calendar dates are used on the time axis, Gantt charts provide a clear overview of the project schedule and can often be found posted on the walls of project offices. Unfor-tunately, when projects have many dependency relationships, the dependency lines soon become overwhelming and defeat the simplicity of the Gantt chart. Project management software can be a tremendous help in the hands of those who understand and are familiar with the tools and techniques discussed in this text. How-ever, there is nothing more dangerous than someone using the software with little or no FIGURE 6.9 Illogical Loop ACB2 Gantt charts were introduced over 100 years ago by Henry Gantt.

knowledge of how the software derives its output. Mistakes in input are very common and require someone skilled in the concepts, tools, and information system to recog-nize that errors exist so false actions are avoided.Calendar DatesUltimately you will want to assign calendar dates to your project activities. If a com-puter program is not used, dates are assigned manually. Lay out a calendar of workdays (exclude non-workdays), and number them. Then relate the calendar workdays to the workdays on your project network. Most computer programs will assign calendar dates automatically after you identify start dates, time units, non-workdays, and other information.Multiple Starts and Multiple ProjectsSome computer programs require a common start and finish event in the form of a node—usually a circle or rectangle—for a project network. Even if this is not a require-ment, it is a good idea because it avoids “dangler” paths. Dangler paths give the impression that the project does not have a clear beginning or ending. If a project has more than one activity that can begin when the project is to start, each path is a dangler path. The same is true if a project network ends with more than one activity; these unconnected paths are also called danglers. Danglers can be avoided by tying dangler activities to a common project start or finish node. When several projects are tied together in an organization, using a common start and end node helps to identify the total planning period of all projects. Use of pseudo or dummy wait activities from the common start node allows different start dates for each project.6.9 Extended Network Techniques to Come Closer to RealityThe method for showing relationships among activities in the last section is called the finish-to-start relationship because it assumes all immediate preceding connected activities must be completed before the next activity can begin. In an effort to come closer to the realities of projects, some useful extensions have been added. The use of laddering was the first obvious extension practitioners found very useful.LadderingThe assumption that all immediate preceding activities must be 100 percent complete is too restrictive for some situations found in practice. This restriction occurs most frequently when one activity overlaps the start of another and has a long duration. Under the standard finish-to-start relationship, when an activity has a long duration and will delay the start of an activity immediately following it, the activity can be bro-ken into segments and the network drawn using a laddering approach so the following activity can begin sooner and not delay the work. This segmenting of the larger activity gives the appearance of steps on a ladder on the network, thus the name. The classic example used in many texts and articles is laying pipe, because it is easy to visualize. The trench must be dug, pipe laid, and the trench refilled. If the pipeline is one mile long, it is not necessary to dig one mile of trench before the laying of pipe can begin or to lay one mile of pipe before refill can begin. Figure 6.12 shows how these overlap-ping activities might appear in an AON network using the standard finish-to-start approach.

Developing a Project Plan 183Use of Lags to Reduce Schedule Detail and Project DurationThe use of lags has been developed to offer greater flexibility in network construction. A lag is the minimum amount of time a dependent activity must be delayed to begin or end. The use of lags in project networks occurs for two primary reasons:1. When activities of long duration delay the start or finish of successor activities, the network designer normally breaks the activity into smaller activities to avoid the long delay of the successor activity. Use of lags can avoid such delays and reduce network detail.2. Lags can be used to constrain the start and finish of an activity.The most commonly used relationship extensions are start-to-start, finish-to-finish, and combinations of these two. These relationship patterns are discussed in this section.Finish-to-Start RelationshipThe finish-to-start relationship represents the typical, generic network style used in the early part of the chapter. However, there are situations in which the next activity in a sequence must be delayed even when the preceding activity is complete. For example, removing concrete forms cannot begin until the poured cement has cured for two time units. Figure 6.13 shows this lag relationship for AON networks. Finish-to-start lags are frequently used when ordering materials. For example, it may take 1 day to place orders but take 19 days to receive the goods. The use of finish-to-start allows the activity dura-tion to be only 1 day and the lag 19 days. This approach ensures the activity cost is tied to placing the order only rather than charging the activity for 20 days of work. This same finish-to-start lag relationship is useful to depict transportation, legal, and mail lags. The use of finish-to-start lags should be carefully checked to ensure their validity. Con-servative project managers or those responsible for completion of activities have been known to use lags as a means of building in a “slush” factor to reduce the risk of being late. A simple rule to follow is that the use of finish-to-start lags must be justified and approved by someone responsible for a large section of the project. The legitimacy of lags is not usually difficult to discern. The legitimate use of the additional relationship shown can greatly enhance the network by more closely representing the realities of the project.Start-to-Start RelationshipAn alternative to segmenting the activities as we did earlier is to use a start-to-start relationship. Typical start-to-start relationships are shown in Figure 6.14. Figure 6.14A FIGURE 6.12 Example of Laddering Using Finish-to-Start Relationship Trench1/3Trench1/3Lay pipe1/3Trench1/3AON networkLay pipe1/3Reﬁll1/3Lay pipe1/3Reﬁll1/3Reﬁll1/3FIGURE 6.13Finish-to-Start Relationship XLag 19YLar66093_ch06_162-205.indd 18315/10/16 2:04 PMProject Management: The Manag

Developing a Project Planshows the start-to-start relationship with zero lag, while Figure 6.14B shows the same relationship with a lag of five time units. It is important to note that the relationship may be used with or without a lag. If time is assigned, it is usually shown on the depen-dency arrow of an AON network. In Figure 6.14B, activity Q cannot begin until five time units after activity P begins. This type of relationship typically depicts a situation in which you can perform a por-tion of one activity and begin a following activity before completing the first. This relationship can be used on the pipe-laying project. Figure 6.15 shows the project using an AON network. The start-to-start relationship reduces network detail and project delays by using lag relationships. It is possible to find compression opportunities by changing finish-to-start relations to start-to-start relationships. A review of finish-to-start critical activities may point out opportunities that can be revised to be parallel by using start-to-start relationships. For example, in place of a finish-to-start activity “design house, then build foundation,” a start-to-start relationship could be used in which the foundation can be started, say, five days (lag) after design has started—assuming the design of the foundation is the first part of the total design activity. This start-to-start relationship with a small lag allows a sequential activity to be worked on in parallel and to compress the duration of the criti-cal path. This same concept is frequently found in projects in which concurrent engi-neering is used to speed completion of a project. Concurrent engineering, which is highlighted in the Snapshot from Practice 6.3: Concurrent Engineering, basically breaks activities into smaller segments so that work can be done in parallel and the project FIGURE 6.14Start-to-Start Relationship ActivityMActivityNActivityPAActivityQBLag 5FIGURE 6.15Use of Lags to Reduce Project Duration Trench1 mileLay pipe1 mileLag 3Reﬁll1 mileLag 3Lar66093_ch06_162-205.indd 18415/10/16 2:04 PM194Larson In the old days, when a new product development project was initiated by a ﬁrm, it would start its sequential journey in the research and develop-ment department. Concepts and ideas would be worked out and the results passed to the engineering department, which sometimes reworked the whole product. This result would be passed to manufacturing, where it might be reworked once more in order to ensure the product could be manufactured using existing machinery and opera-tions. Quality improvements were initiated after the fact once defects and improvement opportunities were discovered during production. This sequential approach to product development required a great deal of time, and it was not uncommon for the ﬁnal product to be totally unrecognizable when compared to original speciﬁcations. Given the emphasis on speed to the market, com-panies have abandoned the sequential approach to product development and have adopted a more holistic approach titled concurrent engineering. In a nutshell, concurrent engineering entails the active involvement of all the relevant specialty areas throughout the design and development process. The traditional chainlike sequence of ﬁnish-to-start relationships is replaced by a series of start-to-start lag relationships as soon as meaningful work can be initiated for the next phase. Figure 6.16 summarizes the dramatic gains in time to market achieved by this approach. Within the world of project management this approach is also called Fast Tracking. General Motors used this approach to design the very ﬁrst American hybrid car, the Chevy Volt. From the very beginning specialists from marketing, engineering, design, manufacturing, quality assurance, and other relevant departments were involved in every stage of the proj-ect. Not only did the project meet all of its objectives, it was completed ahead of schedule.*“Chevrolet Volt Hits Road, Ahead of Schedule,” The New York Times, June 25, 2009; accessed online June 2, 2011.SNAPSHOT FROM PRACTICE 6.3Concurrent Engineering*Engineeringdesign &developmentEngineeringdesign &developmentProductplanningProductplanningSystemsengineeringSystemsengineeringTimeProcurementProcurementManufacturing& productionManufacturing& productionQualityassuranceQualityassuranceReleaseTraditional Sequential ApproachConcurrent Engineering ApproachReleaseFIGURE 6.16 New P

expedited (Turtle, 1994). Start-to-start relationships can depict the concurrent engineer-ing conditions and reduce network detail. Of course, the same result can be accom-plished by breaking an activity into small packages that can be implemented in parallel, but this latter approach increases the network and tracking detail significantly.Finish-to-Finish RelationshipThis relationship is found in Figure 6.17. The finish of one activity depends on the fin-ish of another activity. For example, testing cannot be completed any earlier than four days after the prototype is complete. Note that this is not a finish-to-start relationship because the testing of subcomponents can begin before the prototype is completed, but four days of “system” testing is required after the prototype is finished.Start-to-Finish RelationshipThis relationship represents situations in which the finish of an activity depends on the start of another activity. For example, system documentation cannot end until three days after testing has started (see Figure 6.18). Here all the relevant information to complete the system documentation is produced after the first three days of testing.Combinations of Lag RelationshipsMore than one lag relationship can be attached to an activity. These relationships are usually start-to-start and finish-to-finish combinations tied to two activities. For exam-ple, debug cannot begin until two time units after coding has started. Coding must be finished four days before debug can be finished (see Figure 6.19).An Example Using Lag Relationships—The Forward and Backward PassThe forward and backward pass procedures are the same as explained earlier in the chapter for finish-to-start relationships (without lags). The modifying technique lies in the need to check each new relationship to see if it alters the start or finish time of another activity.FIGURE 6.17Finish-to-Finish Relationship PrototypeTestingLag 4FIGURE 6.18Start-to-Finish Relationship TestingSystemdocumentationLag 3FIGURE 6.19Combination Relationships DebugLag 2Lag 4Code

Developing a Project Plan expedited (Turtle, 1994). Start-to-start relationships can depict the concurrent engineer-ing conditions and reduce network detail. Of course, the same result can be accomplished by breaking an activity into small packages that can be implemented in parallel, but this latter approach increases the network and tracking detail significantly. Finish-to-Finish Relationship This relationship is found in Figure 6.17. The finish of one activity depends on the fin-Ish of another activity. For example, testing cannot be completed any earlier than four days after the prototype is complete. Note that this is not a finish-to-start relationship because the testing of subcomponents can begin before the prototype is completed, but four days of “system” testing is required after the prototype is finished. Start-to-Finish Relationship This relationship represents situations in which the finish of an activity depends on the start of another activity. For example, system documentation cannot end until three days after testing has started (see Figure 6.18). Here all the relevant information to complete the system documentation is produced after the first three days of testing. Combinations of Lag Relationships More than one lag relationship can be attached to an activity. These relationships are usually start-to-start and finish-to-finish combinations tied to two activities. For exam-ple, debug cannot begin until two-time units after coding have started. Coding must be finished four days before debug can be finished (see Figure 6.19).An Example Using Lag Relationships—The Forward and Backward Pass The forward and backward pass procedures are the same as explained earlier in the chapter for finish-to-start relationships (without lags). The modifying technique lies in the need to check each new relationship to see if it alters the start or finish time of another activity. FIGURE 6.17Finish-to-Finish Relationship PrototypeTestingLag 4FIGURE 6.18Start-to-Finish Relationship TestingSystemdocumentationLag 3FIGURE 6.19Combination Relationships Debug Lag 2Lag 4CodeLar66093_ch06_162-205.indd 18615/10/16 2:04 PM196Larson An example of the outcome of the forward and backward pass is shown in Fig-ure 6.20. Order hardware depends upon the design of the system (start-to-start). Three days into the design of the system (activity A), it is possible to order the required hard-ware (activity B). It takes four days after the order is placed (activity B) for the hard-ware to arrive so it can begin to be installed (activity C). After two days of installing the software system (activity D), the testing of the system can begin (activity E). System testing (activity E) can be completed two days after the software is installed (activity D). Preparing system documentation (activity F) can begin once the design is com-pleated (activity A), but it cannot be completed until two days after testing the system (activity E). This final relationship is an example of a finish-to-finish lag. Note how an activity can have a critical finish and/or start. Activities E and F have critical finishes (zero slack), but their activity starts have 4 and 12 days of slack. It is only the finishes of activities E and F that are critical. Conversely, activity A has zero slack to start but has five days of slack to finish. The critical path follows activity start and finish constraints that occur due to the use of the additional relationships available and the imposed lags. You can identify the critical path in Figure 6.20 by following the dashed line on the network. If a lag relationship exists, each activity must be checked to see if the start or finish is constrained. For example, in the forward pass the EF of activity E (test system) (18) is controlled by the finish of activity D (install software) and the lag of two time units (16 + lag 2 = 18). Finally, in the backward pass, the LS of activity A (design system) is controlled by activity B (order hardware) and the lag relationship to activity A (3 − 3 = 0).

Developing a Project Plan Hammock Activities Another of the extended techniques uses a hammock activity. This type of activity derives its name because it spans over a segment of a project. The hammock activity duration is determined after the network plan is drawn. Hammock activities are frequently used to identify the use of fixed resources or costs over a segment of the project. Typical examples of hammock activities are inspection services, consultants, or con-struction management services. A hammock activity derives its duration from the time span between other activities. For example, a special color copy machine is needed for a segment of a tradeshow publication project. A hammock activity can be used to Indi-cate the need for this resource and to apply costs over this segment of the project. This hammock is linked from the start of the first activity in the segment that uses the color copy machine to the end of the last activity that uses it. The hammock duration is simply the difference between the EF for the last activity and the ES of the first activity. The duration is computed after the forward pass and hence has no influence on other activity times. Figure 6.21 provides an example of a hammock activity used in a network. The duration for the hammock activity is derived from the early start of activity B and the early finish of activity F; that is, the difference between 13 and 5-, or 8-time units. The hammock duration will change if any ES or EF in the chain-sequence changes. Hammock activities are very useful in assigning and controlling indirect project costs.3 Another major use of hammock activities is to aggregate sections of a project. This is similar to developing a subnetwork, but the precedence is still preserved. This approach is sometimes used to present a “macro network” for upper management lev-ells. Using a hammock activity to group activities can facilitate getting the right level of detail for specific sections of a project. FIGURE 6.21 Hammock Activity Example H4212125250A5IDLegendDur.ESLSEFLFSLDescriptionB1C5D4F30055666141018556611111018132100088E10111121210HammockG85133 In order to designate G as a Hammock activity in MS Project 2012 you would copy and paste for activity G the start date of activity B and the ﬁnish date for activity F (http://support.microsoft.com/kb/141733).