Project Planning Lecture Notes 2024 PDF

CHAPTER 5 PROJECT PLANNING Learning outcomes At the end of this chapter, you should be able to: ▪ Understand the purpose and nature of project planning. ▪ Understand the link between project definition, planning, execution and closure. ▪ Use the p...

CHAPTER 5 PROJECT PLANNING Learning outcomes At the end of this chapter, you should be able to: ▪ Understand the purpose and nature of project planning. ▪ Understand the link between project definition, planning, execution and closure. ▪ Use the precedence diagramming method (PDM) and critical path method (CPM) methods to develop a practical project network diagram. ▪ Use the critical path to help manage the project. ▪ Understand how to accommodate uncertainty in project plans. Overview Once a project has been defined and the decision to allocate resources has been made, the project needs to be planned. The project plan is an essential part of the project management process and often marks the difference between success and failure. In fact, a common mantra in project management is to first ‘plan the work and then work the plan’. Mastering the tools and techniques introduced in this chapter and the next will enable the project manager to achieve the project’s objectives and meet stakeholder expectations. This chapter introduces the project manager to a planning model that can be used to bring structure to the planning process. The remainder of the chapter addresses the various activities that will enable the project manager to develop a preliminary project plan. Introduction Project planning is not as clinical as planning theorists would have us believe. In reality, although the end result of the plan is fairly similar, planning is a messy, iterative process that provides better results as the project manager moves through the planning process. In all cases, the project plan is geared towards addressing the key aspects of scope, quality, time, costs, resources, and risks that were introduced in Chapter 1. If the project manager stays focused on this goal, the process will eventually produce a plan that can be confidently used as the basis for monitoring and controlling the project. Finalising the plan and then expecting the plan to remain unchanged throughout the rest of the project is unrealistic. A static planning process is likely to result in sluggish projects that are not well aligned with their environments. In today’s world, this approach will significantly undermine an organisation’s ability to remain competitive. Therefore, as the project progresses, the plan will need to be updated to reflect changes in the environment and to increase the level of precision required to meet the project’s objectives. Since planning cannot continue forever, the nature of the project and the policies of the organisation will dictate when the official planning effort ends. For example, consider how changes in NewTech SA’s environment forced Jabu to consider alternative courses of action in the MoMoDev project when the opportunity to present at the Innovate Africa Expo arose. This view forms the basis of our approach to planning. 1 5.1 A planning model There are several steps required to produce a project plan and that may vary from project to project. Figure 5.1 proposes a model that can be used to conceptualise planning for any project in the context of the project life cycle as discussed in Chapter 1. The figure shows how project definition results in several outputs (scope statement, priorities, work breakdown structure (WBS) and the organisation breakdown structure (OBS)) that form the basis for the planning effort (see Chapter 4). In planning, the project manager should first identify the activities that need to be taken into account. Following this, the activities can be sequenced and estimated in terms of time frames (or durations) and resource requirements. The preliminary schedule that was introduced in Chapter 4 is then developed from the sequence of activities and their estimated durations. Information about resource requirements is used later to develop the resource-constrained schedule (see Chapter 6 for a more detailed discussion on resource-based scheduling). Once the preliminary schedule has been developed, the project manager can conduct an initial risk assessment of the project. This assessment will identify any significant risks that need be taken into account before the project plan can be taken any further (see Chapter 10 for a more detailed discussion on risk management). If the results of the assessment are not satisfactory, the project manager would return to the earlier steps of the project definition and planning process as appropriate – that is, the project manager would iterate (revisit) the relevant steps as required. After finalising the preliminary schedule, the project manager should consider the availability of resources in order to develop a resource-constrained schedule before conducting another (more formal) risk assessment of the project. Planning is then repeated (iterated) to address any concerns that may have arisen from the formal risk assessment. Once these concerns have been addressed, the project manager can document the project plan, which can be baselined (finalised) once it has been reviewed by key stakeholders (see Chapter 11). The project manager will use the baseline plan as the basis for executing, monitoring and controlling the project. As the project manager executes the project, new information and developments about earlier assumptions usually come to light. The project manager will need to update the plan to keep it relevant and will therefore need to replan and revisit (iterate) elements of the planning cycle as the project progresses (this is what is referred to as ‘rolling-wave planning’1). At some point, the project must come to an end and will therefore need to be closed; project closure will also have to be catered for as part of the planning/re-planning cycle. The rest of this chapter focuses on the first part of the planning cycle, which is to get to the point at which the project manager has developed the preliminary schedule and conducted the initial risk assessment of the project. The remaining elements of the planning cycle will be addressed in Chapter 6. As Figure 5.1 illustrates, the first step in the planning cycle is to identify the activities that need to be planned. This is discussed in the next section. 2 A planning model 5.2 Identify the activities Projects generally involve three levels of planning: 1. Project 2. Stage 3. Team. At the project level, the project manager is concerned with major deliverables and milestones and how these come together to achieve the project’s overall objectives. This level of planning typically focuses on the complete WBS as defined during project definition and is 3 considered compulsory for all projects. For example, in the central case study, MoMoDev – Modular Mobile Devices, the project level plan would have focused on major deliverables and milestones for the entire project, rather than being limited to one component of the modular cellular device. At the stage level, the project manager is concerned with one or more major deliverables or specific milestones that need to be reached to complete a segment of the overall project. This level of attention lends itself well to rolling wave planning (see the Food for thought feature, Sequencing activities in large projects, projects with many time frames, or many activities), which emphasises short- to medium-term planning without losing sight of long-term objectives. This level of planning is recommended for most projects and usually focuses on a specific segment of the overall WBS defined during project definition (see Chapter 4). For example, in the central case study, MoMoDev – Modular Mobile Devices, one of the stage level plans would have focused on establishing mobile device standards, while another would have focused on the test plans and evidence for achieving measures of success. At the team level, planning usually focuses on one or more specific work packages in the WBS and is often left to the various teams to whom the project manager has delegated work. While this level of planning is optional, it is often leveraged by the project manager to gain more control over specific elements of the project – but this will depend on the nature of the overall project and the task being delegated. For example, in the case study reflection, MoMoDev – Modular Mobile Devices, the activities required to actually test each component of the new modular mobile device would have been delegated to and specifically planned by a testing team. Jabu, as the project manager, would have agreed the scope, timelines and budget with the testing team, but would not have become too involved in how the testing was completed. To summarise, identifying activities is directly aligned to the level of planning that the project manager is engaged in: at the project level, ‘activities’ are usually made up of all the major deliverables and milestones that define the whole WBS; at stage level, the activities relate to one or more major deliverables and/or milestones; while at the team level, activities relate to the detailed work that a team (or individual) would be required to complete in order to meet the objectives of one or more specific work packages. Regardless of the level of planning under consideration, once the activities have been identified, the project manager can move onto sequencing the activities. This is discussed in the next section. 5.3 Sequence the activities Sequencing implies defining the relationships between the activities used to manage and control the rest of the project. Optimising these relationships will have a significant effect on the overall success of the project. For example, in the central case study, MoMoDev – Modular Mobile Devices, the project manager has to ensure that the mobile device standards would need to be defined before development on any of the components could begin. Similarly, there would have to have been some progress in developing the components before any level of testing could be performed on them. There are several methods that can be used to document the relationships between activities, such as a list of activities with notes about how they relate to one another, or a diagram that illustrates their dependencies. The most common technique used in modern project management is the precedence diagramming method (PDM)3,4 in which the activities (represented by boxes) are presented as a diagram, and the relationships between activities 4 are represented by connecting arrows. The PDM approach is based on the following guidelines: ▪ Guideline 1 – Networks typically flow from left to right, or top to bottom. ▪ Guideline 2 – Activities are represented by boxes (nodes), whereas relationships between activities are represented by arrows. The arrows indicate precedence and flow. ▪ Guideline 3 – If an activity is represented by a node, the left-hand side of the node represents the start of the activity, while the right-hand side of the node represents the finish of the activity. ▪ Guideline 4 – Splitting of activities is not allowed. Therefore, an activity represents an individual process that must carry on continuously without interruption until completion. ▪ Guideline 5 – An activity cannot begin until all its preceding activities have been completed according to the type of relationship that is defined. ▪ Guideline 6 – Each activity should be uniquely identified in ascending order from left to right (or top to bottom, depending on how you have drawn the network). ▪ Guideline 7 – Looping or conditional statements are not allowed. Looping occurs when the network flows from one activity to an earlier activity in order to repeat some work. Conditional statements occur when alternative paths may occur, depending on the outcome of an earlier activity (‘if successful, then do something; if not, then do something else’). ▪ Guideline 8 – A network should begin with a common start node and finish with a common end node. If a project has multiple start or finish activities, the project manager should use dummy activities to create common nodes. For example, project managers often use a box that says ‘Start ’ and another that says ‘Finish’ to link multiple start and finish nodes. Neither of these nodes represents actual activities, so they are referred to as ‘dummy activities’. Figure 5.2 illustrates how these guidelines are incorporated into a PDM network diagram. Note how the guidelines have been differentiated from the other arrows to make them more visible. If the project manager does not adhere to these guidelines, the usefulness of the network diagram is undermined and the project’s overall planning will be diluted. Over and above these guidelines, the project manager should be familiar with several key terms that 5 underpin PDM diagrams (see the Expert tip, Terms the project manager should know concerning PDM diagrams). EXPERT TIP Terms the project manager should know about PDM diagrams In addition to the PDM guidelines, the following concepts form the backbone to effective network diagrams and should therefore be familiar to the project manager (refer to Figure 5.3). Consider a hypothetical project in which you are planning a big concert: ▪ Activity: An activity (often referred to as a task) is any element of the project that consumes time and resources.6 For example, ‘erecting the concert stage’ is an activity because it will consume time and requires people and equipment to be completed. ▪ Event: An event refers to a point in time in which an activity is either started or finished.7 For example, the point in time in which ‘erecting the concert stage’ is either started or finished is referred to as two events. This is different from the term used to describe a concert as an event. In this case, the concert ‘event’ is a type of milestone or deliverable in the project. ▪ Merge activity: A merge activity is an activity that has two or more preceding activities flowing into it. For example, before the concert stage can be erected, the stage scaffolding must be delivered and the construction team must have been recruited. In this context, ‘erecting the concert stage’ is a merge activity because it depends on two activities that come before (precede) it. ▪ Burst activity: A burst activity is an activity that is succeeded by two or more activities that flow from it. For example, once the concert stage has been erected, the lighting equipment and sound equipment can be installed. In this context, erecting the concert stage is a burst activity because it has two activities that depend (succeed) on it. Figure 5.3 Example of a simple PDM network diagram with notes to illustrate key concepts. ▪ Parallel (or concurrent) activity: A parallel activity is an activity that can logically be completed at the same time as another activity; in other words there is no logical dependency between the two activities. For example, there is no logical dependency between installing the lighting and sound equipment, even though both activities depend on the concert stage having been erected. ▪ Path: A path refers to a sequence of connected, dependent activities. For example, since recruiting the construction team, erecting the concert stage and installing the sound equipment are three dependent activities, these are described as a ‘path’ in the network diagram. Similarly, the relationship between delivering the concert stage scaffolding, erecting the stage and installing the lighting equipment, would also be considered a path of activities. 6 In constructing the network diagram, the project manager needs to consider the way in which different activities are related. The most common type of relationship is finish-to-start dependency, which requires that all the activities on which a task depends (preceding activities) must be completed before the task can begin. For example, Jabu would have determined that the development of the MoMoDev spine, brain and heart modules would need to be completed before they could be tested. In practice this may be too limiting though. Consider, for example, how much time could be saved if the project team started testing certain modules shortly after development had begun. Although this approach introduces additional complexities that would need to be managed, the decision could save significant time without (all other things being equal) dramatically increasing the project’s risk profile. There are four types of PDM relationships that are usually combined with lags (a lag refers to the amount of time that needs to pass before a succeeding activity can begin – see the Expert tip, Using different types of relationships to shorten project duration, further on in this chapter) that the project manager can use in the network diagram to take advantage of opportunities like this. These relationships include (see Figure 5.4): ▪ Finish-to-start − Activity B cannot start prior to the completion of Activity A. For example, sound equipment cannot be tested until it has been installed. ▪ Start-to-start − Activity B can only begin once Activity A has already started. For example, exams in venue 2 should only start once exams in venue 1 have already started. ▪ Finish-to-finish − Activity B cannot finish prior to the finish of Activity A. For example, inspecting the quality of paintwork cannot finish until the painting has been completed. ▪ Percentage completed − Activity B cannot start until the related activity A is past a certain percentage of completion. For example, testing the audio and visual equipment can only begin once at least 60% of the concert stage has been erected. Figure 5.4 Types of PDM relationships that can be used to bring projects closer to reality. 7 Over and above the way in which activities are related as presented in Figure 5.4, the project manager should also be aware of the nature of the dependencies between tasks. For example, there is a big difference between a mandatory and discretionary dependency. When it comes to making trade-offs on the project, the project manager cannot change mandatory dependencies, whereas discretionary dependencies may be more negotiable. There are three types of dependencies that the project manager should be aware of (see the Reflection feature, Mandatory and external dependencies, for an example of activities that could reflect a combination of dependency types): 1. Mandatory dependencies (i.e., hard logic): These are dependencies that cannot change, such as erecting the walls of a shopping complex before putting the roof on. 2. Discretionary dependencies (i.e., soft logic): These are the dependencies that are included at the discretion of the project manager or as a result of the methodology being used to complete the project. These dependencies often vary from project to project and may also be introduced to accommodate the client’s preference. As an example, one does not need to purchase all the building material to build the shopping complex before construction begins. Most of the material can be bought in stages as the construction progresses. The project management team may require that all construction material has at least been ordered and delivery dates confirmed before the next stage of construction begins. Although this dependency is not mandatory, it is introduced to this project in order to mitigate the risk that key building material are not available as and when required during construction. 3. External dependencies: These are the dependencies that may be beyond the control of the project manager, such as being dependent on an external contractor for a deliverable that falls outside the scope of the project, but which has significant impact on the success or failure of the project. In the example above, there will be several dependencies on external suppliers to source, transport, and deliver the building materials to the construction site. Reflection Mandatory and external dependencies In practice, the nature of a dependency between two activities could be a combination of mandatory and external dependencies. For example, the project manager may be faced with a dependency that is both mandatory and external. Consider for example the need to secure the appropriate funding or acquire the appropriate building permits before construction on a new shopping complex can begin. These types of dependencies, which are quite common in practice, are prime candidates for risk management (refer to Chapter 10). Identifying and sequencing the activities is an important part of developing the overall plan. However, before any further planning can occur, the project manager needs to estimate duration and resource requirements as discussed in the next section. 5.4 Estimate activity duration and resource requirements Although Figure 5.1 implies that activity durations and resource requirements are completed as separate steps, in reality these steps are often completed at the same time. This makes sense because it is not possible to estimate an activity’s duration without some kind of sense as to the level of resources that would be required For example, developing the MoMoDev spine may take nine weeks to complete with two engineers working on it, but if NewTech SA seconded another engineer to the task, the time taken to complete development may be 8 reduced to six weeks. Estimating the duration of an activity is dependent on the resource assumptions made about the project. To get around this problem, the project manager assumes the normal level of resources that would be available under normal conditions. This is important because normal conditions for one organisation may not be the same as normal conditions for another organisation. In the big concert example introduced in the Expert tip feature, Terms the project manager should know about PDM diagrams, one organisation may only have two sound engineers that are able to install the sound equipment, while another organisation may have four engineers readily available in the normal course of business. Yet another organisation may have six engineers with the required skill, but three of these may be based overseas and would therefore not be available for the project in question (in other words it may not be possible to use these resources on a local project because, under normal conditions, it is not feasible to fly the resources to South Africa). If the assumptions prove to be too restricting, the project manager will have the opportunity to revisit them at a later stage in the planning process (see Figure 5.1). There are several techniques available to the project manager to establish estimates for activity duration and resource requirements. Let us consider some of these techniques in the next section. 5.4.1 Macro estimating (top-down) and micro estimating (bottom-up) There are broadly two approaches to estimating activity durations and resource requirements: macroestimating techniques and microestimating techniques. These approaches reflect the logic represented by the WBS in that macroestimating implies that the project manager works from the highest level of the WBS to the bottom, while microestimating works from the lowest level of the WBS and rolls the estimates up to the major deliverables and project as a whole (see Figure 5.5). The approaches, which represent two extremes, are also referred to as top- down and bottom-up estimating respectively. Although bottom-up estimating tends to provide a more accurate picture about the project, it is not necessarily the project manager’s first choice when making estimates. The decision should balance what the project manager needs to get out of the estimate on the one hand and the level of detail that the project manager can go into on the other. If the project is in its early stages of planning and the decision to fully commit to the project has not been made yet (see Chapter 2), the project manager would be inclined to make top-down estimates. This is because bottom-up estimates involve much more work and detailed investigation, which may be unnecessary at the early stages of the project. However, if commitment to the project has already been secured and detailed planning for the next phase has already begun, the project manager would be more likely to adopt a bottom-up approach to estimating – on the basis that it provides the detail required for effective planning, monitoring and control. See the Expert tip feature, Hybrid estimating, for guidance on how to achieve the correct balance between macro- and microestimating. 9 If macro estimates were used for the purposes of project definition and micro estimates for detailed planning, the project manager should reconcile the differences between the two. This becomes important because the results of the micro estimates are likely to be quite different from the results of the macro estimates. If the merits of the project were sold to senior management on the basis of the macro estimates, the project manager will need to explain the differences between these two perspectives to maintain credibility. The quality of the project manager’s estimates will have a direct impact on the quality and practicality of the rest of the planning process. As a result, due to the uncertain nature of estimates, the project manager is likely to revisit and update his/her assumptions throughout the planning process. The estimates, together with the sequencing of activities discussed earlier in this chapter, form the basis for developing the project’s schedule, which is discussed in the next section. 5.5 Develop the preliminary schedule Once the sequence of activities has been defined, the project manager is in a position to develop the project’s preliminary schedule. The preliminary schedule prompts four questions that need to be addressed: 1. What is the expected duration of the project? 2. What are the earliest start and finish times of each activity? 3. What are the latest start and finish times of each activity (that would not interfere with the project’s duration)? 4. How would the project’s expected completion date be affected if different activities were delayed? The technique used to answer these questions is referred to as the critical path method (CPM), which involves two calculations that are referred to as the forward pass and backward pass. While these concepts are illustrated in Figures 5.6 and 5.7, the forward pass will identify the early start and finish times of each activity. This calculation will determine the project’s overall (expected) duration. The backward pass will identify the late start and finish dates of each 10 activity in such a way that the project’s estimated completion time is not interfered with. Once the forward and backward passes are completed, the project manager will be able to identify the project’s critical path. The critical path is the longest path of activities in the network that determines the project’s estimated completion date. If any activity along the critical path is delayed beyond its start or finish dates, it will have the direct effect of delaying the completion of the overall project. For example, if laying the foundation for a new office building falls onto the critical path, then delaying the activity will have the effect of delaying the entire project’s end date. While the Expert tip feature, Interpreting the project schedule, outlines some of the key concepts that the project manager should understand to correctly interpret the project schedule, the Expert tip feature, A worked PDM and CPM example, further on in the chapter provides an example of precedence diagramming and the critical path method. In order to illustrate the CPM and its calculations and concepts surrounding the project schedule, let us assume a hypothetical project consisting of four activities as represented in Figure 5.6. In this figure, the project’s activities have been organised into a network diagram using the PDM introduced earlier. Each task is represented by a node, using a template that will help complete the relevant CPM calculations. An explanation of the node template is included in the figure. In order to complete the forward pass, the project manager needs to take the estimated duration of each activity into account and apply these to the project’s network diagram. The following steps can then be used to determine the earliest times and estimated project duration. The steps are further illustrated in Figures 5.7 through 5.10 (see the Expert tip feature, an illustration of PDM and CPM, for a more fully developed example of how these calculations are performed in practice). ▪ Step 1: Let the ES of the first activity begin at time = 0. Calculate the EF of this activity by adding its duration to the ES. In other words, EF = ES+DU. In Figure 5.7, activity A has an ES of 0, while its DU is 3. Therefore, the EF is 3. ▪ Step 2: Take an activity that is not yet calculated, but for which the ES and EF for all its preceding activities are known. If no such activity exists, then go to step 3. Otherwise, set the ES of the activity that you are considering as the highest EF of all the activities on which it depends. In Figure 5.8, activity B depends on the completion of activity A, so its ES is set at day 3. Activity C is similarly dependent on activity A and also has an ES of day 3. In Figure 5.9, step 2 is continued and the ES of activity D is determined to be day 7. This is the highest EF of its preceding activities B and C. ▪ Step 3: If the activity that you are considering is the last activity in the network, stop. Otherwise continue with step 2. In Figure 5.10, activity D is the last activity in the network. The forward pass calculation therefore comes to an end and the project’s overall duration is determined to be 12 days. 11 Figure 5.6 A hypothetical project organised into a network diagram using PDM and setup for CPM purposes EXPERT TIP Interpreting the project schedule It is important for the project manager to understand the following key CPM concepts in order to interpret the project schedule: ▪ Duration (DU): The estimated duration of an activity that is used for CPM calculation purposes. ▪ Early start (ES): The ES of an activity refers to the earliest possible start of an activity, given the early start and finish of all its predecessors. ▪ Early finish (EF): The EF of an activity refers to the earliest possible finish of an activity, given the activity’s ES and estimated duration. ▪ Expected time to complete (EC): The EC refers to the project’s earliest completion time, as predicted by the project network. The EC is also referred to as the project’s duration. ▪ Late start (LS): The LS of an activity refers to the latest possible start of an activity that will not impact the project’s EC. ▪ Late finish (LF): The LF of an activity refers to the latest possible finish of an activity that will not impact the project’s EC. ▪ Slack: Slack refers to the amount of time that the start or finish of an activity can be delayed without having an impact on the start of a succeeding activity. Slack is calculated as part of the backward pass that is used to develop the project’s preliminary schedule. ▪ Critical activity: A critical activity is an activity that cannot be delayed beyond its start or finish dates without having an impact on the completion date of the entire project. These activities therefore have zero slack and are determined as part of the backward pass calculation used to develop the project’s preliminary schedule. ▪ Critical path: The critical path refers to the longest path of activities that determine the completion date of the project. Alternatively, it refers to the path of activities with the least amount of common slack. This concept is explored in more detail when we develop the project’s preliminary schedule. 12 Figure 5.7 the forward pass: Step 1 Figure 5.8 The forward pass: Step 2 13 Figure 5.9 The forward pass: Step 2 (continued) Figure 5.10 The forward pass: Step 3 With the forward pass completed, we can perform the backward pass calculation. By beginning with the project’s completion date at the end of the network and working backwards, we will be able to work out what the late finish and late start dates of each activity are expected to be. The calculation will need to take the duration of each activity as well as the relationships between activities into account. The backward pass calculation, which is illustrated in Figures 5.11 through 5.15, is accomplished by following these three steps: 14 Figure 5.11 The backward pass: Step 1 Figure 5.12 The backward pass: Step 2 15 Figure 5.13 The backward pass Step 2 (continued) Figure 5.14 The backward pass: Step 3 16 Figure 5.15 The backward pass Step 3 (completed) ▪ Step 1: Ensure that the LF of the last activity in the network is equal to the EF of the activity. Calculate the activity’s LS as the LF minus the activity’s duration. In other words: LS = LF – DU. in Figure 5.11, the LF of activity D (the last activity in the network) is set as 12, which is the same as the activity’s EF. Activity D’s LS is then calculated as LF (12) – DU (5) = 17. ▪ Step 2: Take an activity that is not yet calculated, but for which the LS and LF for all succeeding activities (i.e., activities that come after it) are known. Set the LF of the activity you are considering as the lowest LS of its succeeding activities. Repeat this step until there are no further activities to calculate LF and LS dates in the network. In Figure 5.12, activities B and C are succeeded by activity D. The LF for B and C is therefore set to day 7, and their LS dates are calculated to be day 5 and day 3 respectively. This is based on the estimated duration of 2 days for activity B and 4 days for activity C. In Figure 5.13, the LF of activity A is expected to occur on day 3. This is because it has two succeeding activities (B and C) and the lowest LS for these activities is day 3. The LS for activity A will be day 0 (day 3 minus the duration of 3 days). As there are not further activities in this network, you can now move on to Step 3. ▪ Step 3: If the activity that you are considering is the first activity in the network (in other words you have reached the beginning of the project), you have completed the backward pass. The project manager is now in a position to identify the project’s critical path. This is determined by calculating the slack of each activity. Slack refers to the difference between the late start or finish of an activity and the early start or finish of each activity. If there is no slack in an activity, it means that the early and late start (or finish) of an activity are the same date. In other words, the project manager will have no room to delay the start (or finish) of the activity without causing a ripple effect across the network diagram and end up delaying the completion date of the project overall project. In Figure 5.14, the slack for the start date of activity A is zero, as calculated by subtracting the ES (0) from the LS (0). Similarly, the slack for activity B is two days, as established by subtracting the EF (5) from the LF (7). Figure 5.15 completes the calculation of slack across the network diagram and identifies the project’s critical path. 17 Expert tip A worked PDM and CPM example In order to illustrate the application of PDM and CPM more clearly, we will use a hypothetical example of producing a television advertisement. In this example, we assume a hypothetical project in which a team has been tasked to develop a television advertisement. Imagine that after having agreed the project’s definition with the customer, the project team held a workshop to begin the planning process. In this workshop, they identified the following activities: After the script has been approved and the locations confirmed (activity A), filming (also referred to as ‘shooting’) of the advertisement can begin. There are six scenes to be filmed (activities B through G) and, due to the nature of the advertisement, there are several dependencies that determine when each activity can be completed. Once the final scene has been filmed, the team will be able to cut and edit the advertisement before presenting it to the client for review. Table 5.1 summarises the activities, estimated durations and resource requirements, as well as precedence relationships that were agreed upon in the workshop. Table 5.1 Summary of findings from the television advertisement planning workshop ID Activity Estimated Estimated resource Activity duration (days) requirements Predecessors A Develop and obtain 2 Director + 3 approval for the script cameraman + customer B Film scene 1 3 Director + 3 A cameraman C Film scene 2 1 Director + 3 A cameraman D Film scene 3 2 Director + 3 B cameraman E Film scene 4 4 Director + 3 B cameraman F Film scene 5 2 Director + 3 B; C cameraman G Film scene 6 4 Director + 3 D; E cameraman H Cut and edit the advert 5 Director F; G I Review with the 1 Director + customer H customer Figure 5.16 below provides an annotated example of the project’s network diagram and the forward pass calculation 18 Figure 5.16 Annotated example of the network diagram with forward pass calculation for the television advertisement example. Figure 5.17 provides an example of the backward pass and highlights activity slacks and the project’s critical path. Figure 5.17 Annotated example of the network diagram with backward pass calculation for the television advertisement example. It is worthwhile highlighting a few points with this example. First, note the template that was used to draw the network diagram and record the findings of the forward and backward pass calculations. This template works well in practice and is often drawn (or printed) onto Post-it® notes to help with the planning process. Second, because the project manager was focusing on the preliminary schedule at 19 this stage (which does not consider resource allocation or constraints), the estimated resource requirements have not been factored into the network diagram (refer to Chapter 6 to see how resource allocation and constraints are dealt with). Third, the forward pass focuses on the early start and finish dates of each activity and therefore uses the top half each activity template; the backward pass focuses on the late start and end dates and therefore uses the bottom half of each activity template. Fourth, the slack of each activity is calculated as the late date less the early date for both the start and finish events of each activity and the critical path is identified as the path of activities that has the least amount of common slack. Finally, the critical path only represents a small subset of activities in the network, but is particularly important to the project manager because if any activity on this path slips passed either its start of finish dates, the whole project will be pushed beyond the estimated completion date of 19 days. When the critical path is known, it provides the project manager with the opportunity to identify those activities that need to be especially closely managed to prevent the project from being delayed. Consider, for example, how Jabu would have managed the critical path in the MoMoDev initiative to manage the project: delays in the project timeline that affected the critical path would have received urgent attention, but if a delay was not critical, then each engineer or work team would deal with it appropriately. Unfortunately, it is not enough to only focus on the critical path as defined in the schedule – the project manager must also be aware of how quickly the critical path in the network can change. This is referred to as ‘network sensitivity’ and is a function of how much slack is built into the rest of the project: the less slack, the more sensitive the network (which means that the critical path could easily change if there is a slight delay of an activity that is not on the critical path). Generally speaking (and all other things being equal), there is a direct link between the sensitivity of a network and the riskiness of the project; the more sensitive the network, the riskier the project (in terms of being able to meet the expected completion date). Sensitive networks are far more difficult to manage and demand significantly more attention on the part of the project manager to ensure the project is completed on time. The Expert tip feature, A practical application of the terms ‘slack’ and ‘float’, provides additional information on the different types of float and slack that can be used to understand a network’s sensitivity. Once the preliminary schedule has been developed, the project manager can take a step back to assess how the project plan is coming together. This is done to get a sense of whether the project is on track to meet the provisions of the project definition (see Chapter 4) and stakeholder expectations (see Chapter 11). If there is poor alignment between the projects, its definition and stakeholder expectations, either the planning process needs to be revisited, or the project manager needs to go back and negotiate around the areas where he/she is experiencing difficulties. This step of the planning process is referred to as a ‘preliminary risk assessment and response plan’ and is discussed in the next section. Expert tip A practical application of the terms ‘slack’ and ‘float’ There are several types of floats or slacks that can be used to measure the different types of possible delays in a project. Originally, the term ‘slack’ was used for events while the term ‘float’ was used for activities. But this distinction seems to have fallen away in modern project management. A distinction that is useful in modern project management is the difference between total and free slack/float. Understanding these differences will enable the project manager to extract even more benefit from the CPM technique. 20 Total slack Total slack refers to the difference between the late and early dates of an activity’s start or finish. The slack for the start of an activity is therefore equal to the LS minus ES, while the slack for the finish of an activity is equal to the LF minus EF. If an activity is delayed beyond its slack, the ES for all the activities that depend on it (succeeding activities) will be delayed and their slack accordingly reduced. This has important implications for the project manager because the ripple effect caused by one delay will have to be coordinated across whole network. Free slack (or float) Free slack is different from total slack in that it refers specifically to the amount of time that an activity can be delayed before it has an impact on the activities that depend on it (successor activities). Free slack, which can never be negative, can only occur at the end of a path of activities (and usually before a merge activity). For example, if a path of activities has 10 days of slack, only the last activity in the chain will have the free slack (refer to Figure 5.17). The advantage of using free slack to manage the project is that it implies less coordination that needs to be done by the project manager to keep the project on track; the project manager will only have to coordinate with the participants of the path of activities under consideration, rather than the participants of the activities throughout the project. The project manager therefore has more flexibility with free slack than he/she has with total slack. 5.6 Preliminary risk assessment and response plan To conduct a preliminary risk assessment, the project manager will review the project in terms of scope, quality, timescale, budget and risk. If any problems become apparent, the planning process will need to be repeated until the issues have been satisfactorily resolved. This will be achieved by either adapting various parts of the plan, or by developing responses to each of the major identified risks (see Chapter 10). Many trade-offs will have to be made when trying to address these complications, and this is where the project manager’s leadership, management, negotiation, change management, and conflict resolution skills start becoming increasingly important (see Chapters 11, 12, 13, 14 and 15). Some of the considerations that the project manager will have to take into account and that were introduced in Chapter 1 are discussed in the next sections. 5.6.1 Scope This is fundamentally a question of whether all the activities required to complete the project and meet its objectives have been identified. It is not a matter of how many activities have been planned, but is a function of how well the WBS is defined. If the WBS is badly defined, the project manager will have difficulty in meeting the project’s scope. On the other hand, a well-defined WBS will easily satisfy the concern. 5.6.2 Quality This perspective prompts the project manager to consider whether he/she has included the necessary activities to ensure that the project will deliver the desired level of quality. If the activities required to review project deliverables against customer expectations have not been planned, it is unlikely they will be done. As a result, this view often prompts the project manager to include additional activities that may have been missed earlier in the planning cycle (identify activities). For example, the project manager may need to introduce additional activities to ‘inspect the concert stage’, or ‘test the sound and lighting equipment’. 5.6.3 Timescale 21 If the project’s timescale extends beyond expectations, the project manager will need to review the elements of the project to shorten its overall duration. While the first point of departure is often to focus on critical activities (activities that fall on the critical path), the project manager may also be prompted to review the project in terms of its underlying approach. For example, the amount of time required to set up a concert venue may be significantly reduced by using more machinery to replace slower labour intensive methods to move and erect heavy scaffolding and other equipment. Alternatively, the project manager could consider the types of relationships that tie the various activities together. For example, the project manager may be able to realise significant benefits by changing a series finish-to- start relationships to a series of start-to-start relationships with lags in between (a lag refers to the amount of time that needs to pass before a succeeding activity can begin – see the Expert tip feature, Using different types of relationships to shorten project duration). Expert tip Using different types of relationships to shorten project duration The project’s network diagram is often initially built on the basis of finish-to-start relationships (refer to Figure 5.4), but there are various techniques that can be used to shorten a project’s duration by using different types of relationships. Two such examples include laddering and concurrent engineering. Both these techniques rely on the use of lags to further constrain the relationships and dependencies between activities. A lag refers to the amount of time that a successor activity is delayed from a preceding activity. Figure 5.18 illustrates the different types of relationships that can be used to shorten a project’s duration and bring the project closer to reality. A simple example of laying a 30 km pipe can serve to illustrate the principle of using different types of relationships to shorten project duration. Consider three tasks, A, B and C. Task A focuses on digging the 30 km trench, while task B focuses on laying the 30 km pipe (in 20 m sections) and task C focuses on covering up the trench once the pipe has been laid down. Each task is expected to take approximately nine days to complete. If the standard finish-to-start relationships are used to plan the project (refer to Figure 5.19), the project is expected to be completed after 27 days. Figure 5.18 Illustration of the different types of relationships between tasks that are typically used with lags. 22 Figure 5.19 Laying a 30 km pipe with finish-to-finish relationships However, if the project manager used the laddering technique to plan the project (refer to Figure 5.20), a different picture emerges; the project is now expected to take only 13 days to complete. Laddering uses a series of start-to-start relationships between tasks rather than the traditional finish-to-finish set of activities. The projected improvement of eight days to complete the project is significant – despite the increased complexity of having to complete selected tasks in parallel. When we ladder the activities, the project’s expected duration is reduced from 27 days (Figure 5.19) to 13 days. Laddering enables tasks to be completed in parallel to one another using different combinations of start-to-start relationships with lags. In this example, the start-to-start relationships are complemented by a series of finish-to-finish relationships. All activities are critical. Figure 5.20 Laying a 30 km pipe by laddering successive tasks and using a series of start-to-start and finish-to-finish relationships 23 Search for the term ‘concurrent engineering’ on the Internet. How does this technique relate to the different types of relationships and the use of lags illustrated in Figure 5.18 and the 30 km pipe example above? Is there scope for concurrent engineering to help shorten the kinds of projects that you are typically involved in? Food for thought Extending lag relationships Having introduced the application of lag relationships to project schedules through the notion of laddering, we are now able to better understand how different forms of lags are integrated into network diagrams. Activity B has a finish-to-finish relationship with activity A, with a lag of 1 day. This means that activity B cannot begin any sooner than 1 day after the completion of activity A. We adapted the network diagram from the television advertisement example we used. In this instance, however, we have inserted some lag relationships to demonstrate how these relationships might have an impact on relationships between activities. The following table sets out the type and nature of the relationship between different activities. Activity Duration Finish-to-start Finish-to-start Other lag relationships Lag (other) predecessor lag A 2 — — Start-to-start A to C 1 B 3 A 0 None 0 C 1 None None None 0 D 2 B 3 Finish-to-finish D to G 8 E 4 B 0 None 0 F 2 B 0 Finish-to-finish F to I 16 C 5 G 4 E 3 None 0 H 5 F, G 0 None 0 I 1 H 0 None 0 The forward pass can be explained as follows: The network diagram starts at activity A, which has no predecessor and an early start of 0. B is dependent on activity A. There is no lag relationship. Therefore, the early finish for A of 2 becomes the early start of B using conventional rules of the forward pass. 24  There is no immediate finish-to-start predecessor for C. However; there is a start-to-start lag relationship between A and C of 1. Therefore, we get the start time of 1 for C by adding the lag of 1 to the early start of 0 of activity A. Activity D is dependent on the completion of activity B. There is, however, a finish-to-start lag relationship of 3 between B and D. Therefore, we get the early start of 8 for activity D by adding the lag of 3 to the early finish of 5 for activity B. Activity E is dependent on the completion of B. There is no lag relationship between these two activities. Therefore, the early start of E is five, which is simply the early finish of B. Activity F is a merge activity and is dependent on the completion of both activities B and C, which means two possible start times for F. There is no lag relationship between B and F. Thus, the first possible start time is the early finish of B, which is 5. There is, however, a start-to-finish lag relationship between C and F of 5. We add 5 to the early finish of 2 for activity C to get the second possible start time of 7 for F. Using the principles underlying the forward pass, we chose the LARGER of the two possible start times. Therefore, the early start for F is 7. Activity G is dependent on the completion of E. There is a finish-to-start lag relationship between E and G of 3 time periods. Therefore, we add this lag to the early finish of 9 for activity E to get our start time of 12 for G. There is a finish-to-finish lag between D and G. This means that there are two possible finish times for G. Using the principles of the forward pass, the first possible early finish would be 16, which we get by adding the early start for G of 12 to the duration of 4 for G. The second possible early finish, however, comes from the finish-to-finish lag relationship between activities D and G. G finishes 8 days after D. Therefore, we add our lag of 8 to the early finish of D to get a possible finish time for G of 18. Again, we choose the largest of the two possible finish times, giving us an early finish for G of 18. What is important to note here is that the finish time for G is NOT, therefore, a typing error, nor is it an error in adding up. The lag has ‘overridden’ the conventional principles we apply in deriving the early finish of an activity by adding the early start to the duration. H is also a merge relationship and is dependent on the completion of F and G. There is no lag relationship. Therefore, we determine its early start by choosing between the finish times for F and G. The larger of the two is 18, which is the finish time for G. This then becomes the start time for H. I is dependent on the completion of H. There is no finish-to-start lag relationship, therefore we simply choose the early finish of H to become the early start of I. However, there is a finish-to- finish lag relationship of 16 time units between F and I, which might potentially have an impact on the completion time of I. Without the lag relationship, the finish time for I would simply be 23 (ES) + 1 (D) = 24. However, you will have noted that the early finish is in fact 25 time units. We get this by adding the lag of 16 to the finish time of 9 for activity F. Again, the conventional way of determining the early finish for I falls away in favour of the larger time. Having completed the forward pass, we will now look at how lag relationships have an impact on the backward pass: For the last activity on the network diagram, activity I, we carry the early finish of 25 down to become the late finish using standard principles for the backward pass. The late start for I of 24 is thus simply worked out by subtracting the duration from the late finish. This late start of 24 is carried backwards to become the late finish for H. At the same time, concerning the finish-to-finish relationship between F and I, on the backward pass we subtract the lag of 16 from the late finish of I to become the late finish of F (i.e., 25(LF) – 16(lag) = 9(LF)). Ultimately, there is a choice of late finish for F, using the late start of H (19) and the lag relationship just discussed. On the backward pass, we always choose the smallest of the values for our finish time, which is the value determined by the lag relationship (9). The late start of H (19) is additionally carried backwards to become the late finish for G. The late start for G of 15 is simply then the late finish of 19 less the duration of 4. The finish-to-start lag relationship of 3 between E and G is then subtracted from the late start of G to derive the late finish for E of 12 (i.e., 15(LS) – 3(lag) = 12(LF)). 25 5.6.4 Risks The project manager will also identify any other major risks that have not yet been taken into account during the preliminary review. While the techniques for assessing risks are addressed in more detail in Chapter 10, it is worth highlighting a few points here: First, at this stage of the planning process, the major risks facing the project arise mainly out of the assumptions that have been adopted to date. The project manager is advised to review these assumptions and assess how realistic they are. If one or more assumptions are blatantly unrealistic, the project manager will have to develop an appropriate response. If the decision is to avoid one or more of these risks, the planning process will have to be repeated (at least for that portion of the plan that would be affected). Alternatively, if the risks cannot be avoided by changing the plan, the project manager will need to consider other responses. For example, even though the project team in the MoMoDev case study did not expect any of the NewTech SA specialists seconded to the project to fall unexpectedly ill, Jabu would need to ensure he had an appropriate response plan ready and waiting just in case this happened. Second, one of the limitations arising from the PDM and CPM methods is that they rely on single-point estimates for task durations. In reality this is a simplistic assumption that, if not properly contextualised when communicating the project schedule (see Chapter 12), could worsen the risk of project failure. This risk will be compounded if we create the impression with our internal and external stakeholders (see Chapter 11) that the project schedule is certain. One way to deal with this problem is to complement the PDM and CPM methods with the programme evaluation review technique (PERT) developed by the US Military in the 1950s.25 Refer to the Expert tip feature, The programme evaluation and review technique (PERT), for more information. Expert tip The programme evaluation and review technique (PERT) Up till this point we have been dealing with single-point estimates for project duration. In practice, not all estimates carry that amount of certainty with them. Project management practitioners have had to develop other techniques to incorporate uncertainty into their project schedule. One of these techniques is the programme evaluation and review technique (PERT) developed by the US Military in the 1950s.26 Instead of using a single estimate for a task’s duration, PERT uses three estimates: optimistic, most likely and pessimistic. The three estimates are used to derive an expected duration based on the following formula: te = (to + 4tm + tp) 6 Where; te is the expected duration of the task given its optimistic, most likely and pessimistic estimates. to is the optimistic (best case scenario) duration of the task. tm is the most likely duration of the task. tp is the most pessimistic duration of the task (worst case scenario). In statistical terms, the formula assumes that the task’s estimated duration adopts a Bell-type distribution27. Expected duration can therefore be skewed towards either the optimistic or pessimistic estimates. The formula’s result can be used as the point estimates in the critical path method (CPM), allowing the PM to estimate the project’s expected date of completion, available slack, and critical path(s). Beyond input into the CPM, the PM can also use the information (and a few more formulae) to gain additional insight into the amount of risk inherent to the project’s schedule. 26 There are three steps required to gain additional insight into schedule risk using results of the PERT calculation: 1 Establish each task’s variance 2 Use the task variances to determine the project’s variance 3 Derive the project’s standard deviation. The formulae for each of these steps are presented in Table 5.2. Table 5.2 Formulae to calculate task variance, project variance and the project’s standard deviation (Copy table 5.2 on page 148) Whereas task variance assumes a beta distribution, we assume that the project variance adopts a normal distribution. This assumption, together with the assumption that activity durations are statistically independent of one another, allows us to use the normal distribution table to determine the probability of a project ending within a certain time frame.28 The normal distribution table is included in Appendix 5.1 at the end of this chapter, and requires the calculation of the Z-score to look up the relevant probability. The Z-score is calculated by using the following formula: z = (Due date – Expected date)/op Where: Due date = the date for which the probability of completing the project by is being queried Expected date = the expected date of completion as determined by the CPM method σp = the project’s standard deviation. The application of PERT is probably best illustrated through the use of an example. Let’s use the same television advertisement example that we used earlier in this chapter to illustrate CPM and PDM. Illustrated example Assume following information from the initial planning workshop, except that the project team has added estimates about the optimistic and pessimistic duration of each task. The estimates are presented in Table 5.3. (Copy table 5.3 on page 149) Limitations of PERT While the theory behind PERT is a step in the right direction in terms of incorporating the effect of uncertainty into our projects, there are several limitations to the technique in practice. The three most common problems associated with PERT are as follows: 1. PERT requires three estimates, which require more time to collect, enter and analyse. As a result of this, the time and effort required to produce a PERT analysis may exceed the potential benefit that could be derived from it. 2. The quality of duration estimates is usually problematic anyway in a project environment. The accuracy of two additional estimates is usually worse. Definitions of 'optimistic' and 'pessimistic' can be inconsistent, arbitrary and confusing. The PERT analysis is therefore often subject to the ‘garbage in, garbage out’ syndrome. 3. Possibly the biggest reason why PERT is not more widely used is the potential for misuse of information. In practice, disclosing optimistic estimates may raise unreasonable expectations about the project schedule and, unless carefully managed, can result in impossible deadlines being set. The link between PERT and risk management 27 Despite the limitations to PERT outlined above, the three-point estimates coming out of the PERT analysis can be enormously useful to the risk management process addressed in Chapter 10. For example, optimistic estimates provide a fertile source for identifying project opportunities, while the analysis of pessimistic (or worst case) estimates provide important insight into negative project risks.30 Refer to Chapter 10 for more information on how the opportunities and threats to a project’s success can be managed through an appropriate risk management process. Third, an obvious issue that is likely to be identified during this preliminary review relates to resource availability. This is significant because until now, the preliminary schedule is based on the fundamental assumption that all resources will be available as and when they are required. This is seldom true in real-world projects, so the project manager will have to consider the impact of resource availability before the project plan becomes practical. This issue is addressed in the next step of the planning process, which focuses on developing the resource-constrained schedule (see Chapter 6). Once the project manager has developed the resource-constrained schedule, a more formal risk assessment is usually conducted (see Chapter 10). SUMMARY This chapter presented the first of two parts on project planning. After providing a general introduction to the topic, the chapter proposed a planning model that provided the link between project definition, planning, execution and closure. Planning begins with the outputs from project definition and identifies the activities that need to be taken into account. Once activity time and resource estimates have been made, the project manager is able to prepare a preliminary schedule against which he/she will be able to conduct a preliminary risk assessment. The preliminary assessment reviews the plan in terms of the project’s constraints around scope, quality, timescale, budget and risks. Once a preliminary plan has been iterated (revisited) to bring the project closer to reality, resource availability can be taken into account to develop a resource-constrained schedule, which in turn provides the basis for a more formal risk assessment. After all the major risks have been taken into account (see Chapter 10), the project manager will be able to baseline (finalise) the plan. The baselined plan is the version that will be used to monitor and control the execution of the project. Even during execution, the plan will need to be constantly revisited to update assumptions, take new developments into account and generally keep the plan up to date. At some point, the project will be brought to a close, which also needs to be properly planned and coordinated. While this chapter addressed the first section of the planning model and ended with a discussion about the preliminary risk assessment, Chapter 6 will address the second part of the planning process by beginning with resource availability and resource-constrained project scheduling. Reflection CPM and PERT A significant downside to CPM is the nature of its basic definitions and rules. In particular, the requirement that an activity can only start once all its preceding activities have been completed, means that it becomes difficult to model real projects. If there are no overlapping activities in the planned projects, the CPM is a perfect and easy-to-understand tool for project managers. In practice however, more and more overlapping and parallel tasks can be used on different projects, which makes CPM difficult to apply.31 Regardless of these limitations though, understanding how CPM works provides the project manager with an important conceptual understanding of tasks, interdependencies, paths, durations, floats, and time/cost trade-offs. The project manager can use this understanding to improve the manner in which projects are planned and executed. 28 Traditional CPM uses point estimates to calculate project duration, slack and the critical path. Experience suggests that estimating task duration is subject to far more uncertainty than this approach would suggest. While the programme evaluation review technique (PERT) provides a useful antidote to this issue, the approach demands a significant amount of time and effort that may outstrip the usefulness of the information gained. The project manager needs to use his/her professional judgement on whether to invest in this effort. Improved understanding of the uncertainty inherent to the project presents significant benefits for negotiating project objectives, identifying risks, and managing stakeholders. Another limitation to the techniques discussed in this chapter relates to the amount of effort required to complete the various calculations and interpret the results. This is particularly problematic in a world where the pace of business seems to continually accelerate and project managers need to be able to rapidly consider alternative scenarios and ‘what-ifs’ in their planning efforts. The use of software applications to help apply these techniques has become an important part of modern project management.32 Project managers should be aware though that using project management software does not guarantee good project management any more than using a good word processing application makes a good author. Overall, project managers have found that planning is a fluid, messy process rather than the clinical, neat process that planning models tend to imply. Notwithstanding the challenges, feedback from experienced project managers has consistently emphasised that one of the most important lessons learned for project management is this: ‘Above all, plan, plan, and plan.’33 KEY TERMS Activity: An activity is any element of the project that consumes time and resources. Baseline plan: A baseline plan represents a moment in the plan’s evolution when it and all its components have reached an acceptable state, such that they can be ‘frozen’ and used for the next step in the project’s life cycle. Burst activity: A burst activity is an activity that is succeeded by two or more activities that flow from it. Critical activity: A critical activity is an activity that cannot be delayed beyond its start or finish dates without impacting on the completion date of the entire project. These activities therefore have zero slack and are determined as part of the backward pass calculation used to develop the project’s preliminary schedule. Critical path: The critical path refers to the longest path of activities that determine the completion date of the project. Alternatively, it refers to the path of activities with the least amount of common slack. This concept is explored in more detail when we develop the project’s preliminary schedule. Duration (DU): The estimated duration of an activity that is used for CPM calculation purposes. Early finish (EF): The early finish (EF) of an activity refers to the earliest possible finish of an activity, given the activity’s ES and estimated duration. Early start (ES): The early start (ES) of an activity refers to the earliest possible start of an activity, given the early start and finish of all its predecessors. Event: An event refers to a point in time in which an activity is either started or finished. In this sense, an event is similar to a milestone (but is very different from the term used in the context of event management). Expected time to complete (EC): The expected time to complete (EC) refers to the project’s earliest completion time, as predicted by the project network. Finish-to-finish: A precedence relationship in which a succeeding activity cannot finish prior to the finish of the preceding activity. Finish-to-start: A precedence relationship in which a succeeding activity cannot start prior to the completion of the preceding activity. 29 Lag: Lag is the delay in the successor activity from its preceding activity. In contrast, a lead is an acceleration of a successor activity relative to its preceding activity. Late finish (LF): The late finish (LF) of an activity refers to the latest possible finish of an activity that will not have an impact on the project’s EC. Late start (LS): The late start (LS) of an activity refers to the latest possible start of an activity that will not have an impact on the project’s EC. Merge activity: A merge activity is an activity that has two or more preceding activities flowing into it. Parallel (or concurrent) activity: A parallel activity is an activity that can logically be completed at the same time as another activity. There is no logical dependency between the two activities. Path: A path refers to a sequence of connected, dependent activities. Percentage completed: A precedence relationship in which a succeeding activity cannot start (or finish) prior to a certain percentage completion of the preceding activity. This relationship may be extended to specify that an activity may not reach a certain percentage completion until activity 1 has reached a certain percentage completion. Slack: Slack refers to the amount of time that the start or finish of an activity can be delayed without impacting on the start of a succeeding activity. Slack is calculated as part of the backward pass that is used to develop the project’s preliminary schedule. Start-to-start: A precedence relationship in which a succeeding activity cannot start prior to the start of the preceding activity. DISCUSSION QUESTIONS 1. How does the WBS differ from the project network? 2. What are the different types of relationships between tasks that can be used by the project manager to bring projects closer to reality? 3. How do the concepts of float and slack help with project management? 4. What is the difference between total slack and free slack? 5. What is the relationship between project definition, stakeholder management and project planning? 6. Why are assumptions important to the planning process? What is the significance of assumptions throughout project execution? 7. How does planning relate to the remainder of the project life cycle? 8. How is risk incorporated into the project planning cycle? 30