Rolling Wave Scheduling - Projects have schedule risk due to uncertainty in the outcomes of future design and risk management actions. Therefore it is not possible to predict long term schedule details with high confidence. If long term schedules are prepared in detail then these details become inaccurate and require rescheduling after a few months of work. The detail schedule should be developed using rolling wave planning to minimize having to rework the detailed planning whenever an unexpected event changes the work and requires replanning of future work in order to meet the intended milestones. Rolling wave planning is a method of managing in the presence of future uncertainty due to risk. Plan the schedule in detail for two to four month periods, e.g. to the next major milestone, and with less detail beyond this period. The schedule should be updated regularly to maintain two to four months of future detailed schedule. This is necessary to identify contentions for critical resources and plan for resolving these contentions. (Recall the value of progressive design freeze discussed earlier.) Note that the NASA Handbook recommends rolling wave scheduling but suggests scheduling in detail for one year periods. A year is too long and results in unnecessary rework of schedules.
A second reason rolling wave planning is effective is that risk mitigation activities should be integrated into the master schedule. Risk management is an ongoing activity; as selected risks are mitigated others take their place. Design decisions can lead to the identification of new risks that must be mitigated. Rolling wave planning and scheduling allows the dynamic risk mitigation tasks to be integrated into the overall project schedule and budget; facilitating effective management. Thus rolling wave planning allows efficient planning in the presence of uncertainty of design results due to the risks inherent in product development.
An Alternative Scheduling Approach - The section on defining and sequencing tasks described how to use N-Squared diagrams to define and sequence project tasks in the optimum sequence. N-Squared diagrams are an alternative to the work flow diagrams described in the NASA Systems Engineering Handbook. Let’s assume that detailed N-Squared diagrams, or work flow diagrams, have been developed for the first phase of a project. This means that there is a top level diagram for the entire project that defines the top level summary tasks and their interrelationships. There are more detailed diagrams for the second and third levels of those top level tasks associated with the first phase of project work, e.g. from project initiation to the first major milestone. Now the job is to convert this task data into a time phased detailed schedule for the first phase of project work.
Assuming that a modern scheduling tool, such as MicroSoft Project, is used it doesn’t really matter whether the final schedule is a Gantt chart or a PERT chart because the scheduling tool can automatically generate one from the other. Thus there are several paths that can be followed from the N-Squared diagrams to the final detailed schedule for the first phase of project work. The N-Squared diagrams contain all the information necessary to go directly to either a PERT or Gantt chart. However, if the person generating the schedule isn’t highly experienced there is an alternate path that is often helpful where there are many feedback loops and possibilities for starting tasks in parallel. This path inserts a second diagram between the N-Squared diagram and the PERT or Gantt schedule.
This second diagram is called a Time Blocked Task List. It’s a simpler form of the work flow diagram or the precedence diagram defined in the NASA handbook in that it only displays sequencing of tasks. Working from the detailed level N-Squared diagrams generate rows of squares with task numbers in each square like the squares and task numbers in the N-Squared diagram. Except now tasks are not confined to the diagonal squares. The idea is to put tasks that feed from one to another in sequence on the same row or adjoining row. If the N-Squared diagrams indicate that two tasks can be started in parallel then put the second task in a row below the row containing the first task and directly below the first task. These are not rigid rules; any form is acceptable as long as each output from each task is separately feeding its appropriate destination task. What is important is positioning the tasks in columns so that the columns are in the sequence the tasks must be performed, hence the name time blocked task list. Arrows are drawn between tasks showing the feed of information from task to task.
If there is a feedback loop where data from a task is needed to replace assumptions or estimates used in earlier tasks and the earlier task must be repeated after the data is available indicate the second pass through tasks with squares following the first pass task and in the same row. Use the same task number but add a letter designator showing that this block is a second pass through the task. An example of a simple time blocked task list is shown in Figure 4-3 for the N-Squared diagram shown in Figure 4-1. This diagram explicitly shows the tasks that must be repeated due to feedback loops. The position of block 4 shows that this task can start at any time between the beginning of the project and just early enough to complete as soon as task 3a completes so that task 5 is not delayed.
Figure 4-3 A Time Blocked Task List explicitly shows sequencing of tasks in feedback loops.
The value of the Time Blocked Task List is that it enables the inexperienced person scheduling tasks to identify more clearly when parallel tasks can be scheduled and it forces recognition that feedback loops require additional time to complete the second pass through the tasks involved. The reason that it’s so important to clearly identify when parallel tasks can be scheduled is that this gives maximum schedule flexibility in scheduling critical resources. Experienced schedulers can skip the Time Blocked Task List but it’s worth the effort for inexperienced schedulers to ensure that parallel tasks are clearly defined as to possible start and finish times and that time is explicitly scheduled for executing feedback loops. There is no need to develop a time blocked task list for an entire project, just block out tasks that have feedback loops and possibilities for parallel starts. Having worked out these details in the simple Time Blocked Task List it is easy to develop accurate Gantt or PERT charts. An example Gantt chart schedule for these tasks is shown in Figure 4-4.
Figure 4-4 An example schedule chart for the six tasks defined and sequenced in Figure 4-1.
No comments:
Post a Comment