Set The Baseline Schedule

The baseline schedule is set in most project management software by copying the start and end dates to baseline or planned start and end dates. For international projects these are done separately for each subproject. Now suppose that you have developed the plan using the method (or any method) and you find that the final date for project completion is not acceptable. This must happen almost 100% of the time, don’t you think?

Instead, they linger in the middle, vague zone of tasks. Management pays attention to the tasks in the critical path and ignores the tasks with risk unless they are on the critical path. They try to shorten tasks that have no risk. How can you do this? You cannot. If a task takes 10 days and has no issues, then it will take 10 days unless you make significant changes to the task!

What else can you do? Here is a series of actions you can take to shorten the schedule. It is the combination of the steps that add up to results.

• Divide up tasks in the schedule (including the critical path tasks) to make the work performed more in parallel.

• Consider paths in the project that contain tasks with significant issues. Here is where management and team attention can be employed with advantage. Why? You can examine the tasks that have issues and try to address the issues. By resolving or simplifying the issues, you can develop better and likely shorter durations for the tasks.

• Review carefully dependencies among subprojects and major summary tasks. Can more parallel effort be done here?

How do you use these actions? Bottom up. You begin with the subprojects that have the most risk and issues. Then you progressively analyze and review other subprojects. Since you can link the subprojects together in the project management software, you can always get an overall view of the effects of the changes that you have made.

This approach was employed in a large-scale deployment of satellite television in a major global region. Originally, the plan called for the rollout to be done in 17 months. This was just too long due to competitive pressures. The traditional approach was taken to shorten the critical path by applying more resources. The result was a plan shorter by 4 months, but much higher in cost.

Then the approach in this section was taken. It was found that people had made many assumptions related to dependencies. Also, there were a number of issues that could be resolved in project planning. After 2 weeks of effort by the project leaders, the team, and management the time was reduced by 6 months! Not bad, eh? A side benefit was that people had a much better idea of what was involved in the project— they participated in the analysis and so supported and understood the work involved in more detail.