So, lets get started!!!
The Project Schedule:
The project work is composed of several individual activities. By using the data we gathered in the previous chapters, you must work out a few schedule-related pieces at the activity level, which come together as the project schedule when you run them through the schedule development process, formally called Develop Schedule. Until you have a realistic project schedule, you do not have a project. A project schedule has schedule activities sandwiched between the project start date and the project finish date.
As always, we have inputs to the develop schedule activity, use some tools and techniques and produce the output. Look at the picture below:
Input to Schedule Development
The following output items from the schedule-related processes discussed in the previous chapters directly support the schedule development process:
• Activity list and activity attributes
• Project schedule network diagrams showing the dependencies among activities
• Activity resource requirements and resource calendars
• Activity duration estimates
Project scope statement - The assumptions and constraints in the project scope statement can affect the project schedule and therefore must be considered in developing the schedule. The following two types of time-related constraints should get special attention.
• Hard deadlines for start and finish dates - Some activities or work packages might have constraints on their start or finish dates. For example, there might be a situation in which an activity cannot be started before a certain date, or must be finished before a certain date, or both. Where do these date constraints come from? They can come from various sources, such as a date in the contract, a date determined by the market window, a date determined by delivery of material from an external vendor, and so on.
• Time constraints on deliverables - These constraints can come from the customer, the sponsor, or any other stakeholder in terms of deadlines for certain major deliverables or milestones. Other projects inside or outside your organization might be depending on these constraints. So, once scheduled, these deadlines are constraints and can only be changed through the approval process.
Enterprise environmental factors and process assets – The environment in which the project is executed and the processes followed in the organization can have a profound impact on the schedule. You can learn more about these by clicking here
Tools and Techniques for Schedule Development
Once you have the network diagrams for the activities, as well as the activity duration estimates, you are well equipped to start scheduling the project. The remaining main concerns include:
• The actual start date
• Uncertainty of the availability of resources
• Identification of and preparation for activities on the critical path
• Risks involved or what-if scenarios
• The hard start/finish dates for activities or for the project that came down the pipeline from very important stakeholders
The tools and techniques discussed in the following paragraphs can be used to address these concerns while you are finalizing the project schedule.
Schedule Network Analysis
Schedule network analysis is a technique used to generate a project schedule by identifying the early and late start and finish dates for the project. The analysis accomplishes this task by using various analytical techniques, such as critical path method, critical chain method, what-if analysis, and resource leveling.
All these techniques will take into consideration a project network diagram. Remember the network diagram we saw in the Sequencing Activities chapter?
We will be using this for our discussion in this chapter as well.
Critical path method - This is the schedule network analysis technique used to identify the schedule flexibility and the critical path of the project schedule network diagram. The critical path is the longest path (sequence of activities) in a project schedule network diagram. Because it is the longest path, it determines the duration of the project and hence the finish date of the project given the start date. The boxes in the image above represent activities, such as Activity A followed by Activity B, and so on. For simplicity lets assume that each activity is going to take 5 days to complete.
Let us look at how long it will take to complete these activities based on the different paths we can take:
1. Start – A – B – Finish = 10 days
2. Start – C – D – E – Finish = 15 days
3. Start – F – H – I – finish = 15 days
This means that if we start the project on 1st June 2011 and take the 1st path (A-B) it will take 10 working days and the project will be over on June 14th EOD (considering the two weekends that come in between)
The second important feature of the critical path method is to identify the flexibility in the project schedule by calculating the early and late start and finish dates of each activity on each path. The schedule flexibility of an activity is measured by the positive difference between the late start date and the early start date for the activity and is called float time or total float.
Let us take the same network diagram above. Since A is the first activity on the path, its early start is Day 0. But, because B depends on the completion of A and A takes 5 days to finish, the early start date for B is the early start date of A + the duration of A, i.e., 0+5 = 5.
The late start and finish dates are calculated using the backward-pass method, which means you start your calculations from the finish point. The project finish date determined by critical path is for ex Day 12, given that the project start date is Day 0. Because Activity B has duration of 5 days, it must be started no later than Day 7 (12-5). Therefore Day 7 is the late start date of Activity B. Now, activity A has duration of 5 days. So, given that B must start on Day 7, A must start no later than Day 2 (7-5). Therefore the late start date for activity A is Day 2.
The float times are calculated as follows:
Float time for A = late start − early start = 2−0 = 2
Float time for B = late start − early start = 7−5 = 2
Note: Each activity on the critical path will always have a float time of ‘0’. This is because we have calculated the early/late start dates based on the critical path estimate and the other paths obviously don't take that much time and hence can afford the float time whereas the critical path activities cannot.
Trivia:
Each activity on a critical path has zero float time and therefore poses a schedule risk. So, you must monitor the activities on all critical paths very closely during the execution of the project.
Critical chain method - This is an alternative schedule network analysis technique that takes into account the uncertainties of the activity durations due the uncertainty of the availability of resources. It uses schedule network diagrams to identify the critical paths and the schedule flexibility, just like the critical path method. The only difference is that in this technique, you work from more than one network diagram. For example, the durations in the first network are based on the planned scenario regarding the availability of resources. You can draw another network diagram based on the pessimistic scenario regarding the availability of resources. The durations of some activities in the second diagram will be longer than the first diagram, and the second diagram might even have a different or an additional critical path. The extra durations in the second diagram are called duration buffers. So, the focus of the critical chain method is on managing the duration buffers and the uncertainties in the availability of resources applied to the planned schedule activities.
Resource leveling - Resource leveling is not an independent schedule network analysis method. It is applied to the schedule that has already been analyzed using other methods, such as the critical path method or the critical chain method. The resource leveling technique is applied to address the resource needs of activities that must be performed to meet specific delivery dates. Resource leveling involves taking a part of the resources from one activity and assigning it to another. This will change the activity durations and can also result in a change of critical paths.
What-if scenario analysis - The purpose of what-if scenario analysis is to calculate the effects of a specific scenario on the schedule. For example, how the schedule will be affected if a vendor does not make the delivery of a major component on the promised date. Because a what-if scenario by definition represents uncertainty, this analysis often leads to risk planning, which might include changing the schedule or changing the network diagram to get a few activities out of harm’s way if possible.
To Summarize:
• The critical path method is used to develop a schedule for given resources
• The critical chain method factors in the uncertainty of the availability of the resources
• The resource leveling technique is used to move the resources around to meet the resource needs of the activities that must be accomplished on a specific date.
In an ideal scenario in which the required resources are guaranteed, you do not need the critical chain method and resource leveling; just the critical path method will do.
Let’s say you have used critical path method to determine the project schedule. You have also applied other techniques like critical chain method and resource leveling. The final realistic schedule that you came up, has a number that is unacceptable (simple example, your manager doesn't approve of the time). What can you do? The Schedule Compression Technique comes to our rescue!!!
Schedule Compression
Schedule compression is an attempt to shorten the project schedule without changing the project scope. It may be necessary in order to deal with schedule-related constraints and objectives. It is true that you, the project manager, build the schedule through cold, hard mathematical analysis, and you don’t just accept whatever schedule goals come down the pipeline from elsewhere (usually the top), such as from the customer or the project sponsor. However, once you have the schedule built through analysis, you can attempt to accommodate some critical stakeholder expectations or hard deadlines, such as a predetermined project finish date.
In the previous section we already saw about Resource Leveling that can be used to accommodate hard deadlines for certain activities. There are two other techniques that can be used for compressing the project schedule. They are:
Crashing - This is a project schedule compression technique in which cost and schedule tradeoffs are analyzed to decrease the project duration with minimal additional cost. A number of alternatives are analyzed, including the assignment of additional resources. Approving overtime pay for project resources is another example of crashing.
Fast tracking - This is a project schedule compression technique used to decrease the project duration by performing project phases or some schedule activities within a phase in parallel that would normally be performed in sequence. For example, testing of a product can start when some of its components are finished, rather than waiting for the whole product to be completed.
Trivia:
Crashing usually involves assigning more resources and hence increases the cost. However, guard yourself against the misconception that additional resources will linearly improve the performance. For example, if one programmer can develop a program in eight days, it does not necessarily mean that two programmers will develop the same program in four days, because there will be overheads, such as the initial less-productive stage of the newly assigned resource, the time taken to reallocate the work, the interaction among the resources, and so on. Remember the example from one of the previous chapters, 10 girls cannot deliver a baby in 1 month.
Other Tools and Techniques
In addition to the main techniques to develop the project schedule, there are some other tools and techniques for developing the project schedule. They are:
Applying leads and lags - Just like in the activity sequencing process, leads and lags can be applied during the development of project schedule. If you applied some leads and lags during the activity sequencing process, it is time to consider whether you need to adjust those. This adjustment might be necessary to create a realistic schedule.
Project management software - After you have the data for the schedule development created by the processes discussed in this chapter, it is a common practice to use project management software to build the actual schedule. Because they are automated, the scheduling tools expedite the scheduling process and reduce the probability of errors in the schedule.
Output of the Schedule Development Process
The output of the schedule development process include:
Project schedule - The project schedule includes a planned start date and a planned finish date for each schedule activity. The schedule will be considered preliminary until the resources have been assigned to perform the activities according to the schedule. Although a schedule for a simple project might be presented in a tabular form, typically a project schedule is presented in one of the following graphical formats:
• Project schedule network diagram - These diagrams present the schedule activities on a timescale with a start and a finish date for each activity and hence show the dependencies of activities on each other. Because they show the dependencies or the logic, they are also called logic charts.
• Bar chart - In these charts the activities are represented by bars, with each bar showing the start date, the finish date, and the duration of the activity. They are easy to read and are often used in presentations.
• Milestone chart - These are typically the bar charts representing only the milestones, not all the schedule activities.
Schedule data - This is the supporting data for the project schedule and consists of the following:
• The essential data consists of schedule activities, schedule milestones, activity attributes, and documentation of all identified assumptions and constraints.
• Resource requirements by time periods.
• Alternative schedules. For ex:, schedules based on best-case and worst-case scenarios.
• Schedule contingency reserves.
Schedule baseline - This is a specific version of the project schedule that is accepted and approved by the project management team as a baseline against which the progress of the project will be measured. This version of the schedule is developed from the schedule network analysis described earlier in the chapter.
Updates to project documents - During the process of developing the schedule, updates to the following documents may happen:
• Resource requirements - The schedule development process might change the initial estimate for the types and quantities of required resources.
• Activity attributes - Resource requirements or any other activity attributes that have changed must be updated.
• Project calendar - Any update to the project calendar must be documented. For example, each project may use different calendar units in the project schedule.
Project schedule development is an iterative process. For example, it might be necessary to review and revise the duration and resource estimates for some activities to create a project schedule that will be approved. The approved project schedule will act as a baseline against which project progress will be tracked.
Prev: Estimating Activity Duration
Next: Project Communication
No comments:
Post a Comment