The Busy Person's Project Management Book

Chapter 5 - Finalising the plans

The final process in developing your project plan is to develop the project schedule - the sequencing of the tasks and the allocation of team members and stakeholders to those tasks.

In planning our journey we often tend to plan the schedule for our journey before we've sorted out the estimates, costs, availability of flights and risks. As a result, once we've contacted the airlines, we have to re-plan our entire journey because of costs and schedules.

In planning projects, the scheduling of tasks is the last process of planning. However, as we'll cover later in this Chapter, once we have developed our schedule, we may need to re-schedule certain tasks or people to shorten the schedule or to more efficiently allocate team members across the tasks.

In developing the project schedule, there are three basic steps. The first is to develop the network or relationships between the tasks; the second step is to allocate the people and adjust the estimates for duration (remember that we made our estimates in effort in the previous chapter) and the final process is to adjust the schedule for efficient allocation of resources.

However, before we get into developing the schedule, we need to look at some basic concepts behind the scheduling process.

Task Dependencies and Relationships

The key to scheduling is to determine which tasks require something from other tasks before they can start. That is, you must identify the dependencies between your tasks. For example, in planning our journey, until you've booked your flights you cannot confirm your hotel bookings.

There are two major types of dependency. The first is one task requires the output from another - a delivery or output dependency. In Mary's project, she needs to evaluate the various education vendors and produce a Vendor Report before she and the team can commence the pilot education programme. Alternatively, a task may require a person to finish a task so that they start another task - a resource dependency. Once, Mary has finished producing the Vendor Report, she can begin designing the training programme.

There are different types of relationships between tasks as well. The most common relationship is called a finish-to-start relationship. In this relationship between tasks, one task must finish before the dependent task can start. This relationship is often associated with output dependencies. However, sometimes it is possible to overlap tasks. For example, once Mary has started analysing her current procedures, she can also begin to document the problems of the current statistics processing. This relationship is called a start-to-start. With start-to-task relationships you must identify how long after the first task has started the second task can start.

Figure 16 shows these dependencies and relationships.

Fig. 16 - Task dependencies and relationships

You can also have finish-to-finish and start-to-finish relationships but these are less common in small projects.

Developing the Task Network

The first step in developing the project schedule is to develop a task network diagram. These diagrams are also known as a PERT/CPM (Program Evaluation and Review Technique/Critical Path Method) diagrams. In these diagrams the tasks are shown in boxes and relationships (which are generally assumed to be output or resource) are shown as lines between the tasks. In Figure 16, it is implied that Select Vendor is dependent upon Evaluate Vendor being completed. When there is a number or "lag" shown on the relationship lines a start-to-start dependency is implied. In Figure 16, Document Problems can start 2 days after Analyse Current Processing has commenced.

To develop a network diagram is relatively simple. All you and the team have to consider is (1) which tasks are dependent on other tasks either because of output or resources and (2) can other tasks which can be done while other tasks are being done? While the concepts behind developing a network for your project are easy, the process can be quite complex as there are many options available for the sequencing of the tasks. For example, Mary's team may decide to wait until they have finished their analysis of requirements before they begin to examine alternative implementation options. However, it is also possible to examine some options while analysing requirements. The process must involve an open team discussion to explore all scheduling alternatives and the final choice of network will depend on which people are available and are there some clear output-related dependencies. Figure 17 shows a partial network for Mary's project.

Fig. 17 - Basic network diagram

Factor in Adjusted Estimates and People

Once you have settled on your basic network, you and the team can then add in the estimates and allocate people to each task. Taking each task in turn, you and the team must first adjust the effort estimates that you developed in your estimation process (remember Chapter 4?) to elapsed time or duration.

The key here is to allow for non-project activities and/or work on other projects as you adjust the effort to elapsed. It's a bit strange but while projects involve effort, they are measured in duration or elapsed days. For example, Mary estimates that it will take her 24 hours of un-interrupted effort to Evaluate Training Documentation ( 3 days @ 8 hours per day). However, she has to spend 2 hours a day on keeping the current Industry Statistics processing underway and 1 hour per day on administration and process management. So she only has 5 hours per day for the project and the elapsed duration for Evaluate Training Documentation is 5 days (4 days @ 5 hours per day and 1 day @ 4 hours).

Often, you may also be able to schedule to enable more than one person to work on a task. This adds another dimension to your adjusting the effort to duration. Let's assume that Mary can use Fred to help her to evaluate the training documentation. They have to consider whether the task can be equally divided between them, are there communication overheads as they need to talk with each other and review each other's work and so on? As a result, they decide that the task originally estimated as 5 elapsed days (24 hours effort) with Mary working by herself will take 3 elapsed days with Fred helping. However, the total effort now involves 16 hours of Mary's work and 16 hours of Fred's time. In other words, the duration has been reduced but the cost/effort of the task has been increased from 24 hours to 36 hours. Such is the fun of scheduling. Figure 18 shows the network and adjusted elapsed estimates.

Fig. 18 - Network with adjusted estimates

The adjusted network can be then used to derive or calculate the critical path for the project. The critical path is a mathematical calculation of the longest path (in terms of duration) of tasks and relationships through the network. Finding the critical path is essential to managing your project. If the task Determine Available Training takes 6 days instead of the 5 days estimated then the tasks - Evaluate Vendors, Conduct Pilot Programme and Review Pilot - all slip one day and the whole group of tasks is delivered one day late. However, if the Evaluate Training Documentation slips one day it will not affect the related tasks. All tasks that are not on the critical path have float or slack. Float is the number of days a non-critical path task can slip before it affects the critical path. In the case of Evaluate Training Documentation, it has a float of 7 days.

Once the network has been loaded with the adjusted estimates, you and the team can derive a Gantt or task timeline diagram. This diagram displays the network as a series of bars representing the tasks and their elapsed time against a calendar. The Gantt chart is a direct sub-set of the network diagram and is developed by extracting the tasks from the network and aligning them according to a start date and the calendar.

The Gantt chart also shows tasks with float with a shadow or modified bar as the float time. You and the team will find the Gantt chart as the most useful diagram for monitoring and controlling your project as it clearly shows the tasks against the calendar. What the Gantt chart does not show is the relationships or dependencies between the tasks - only the network diagram shows those. Figure 19 shows the Gantt chart assuming Mary starts on February 25.

Fig. 19 - The "first cut" GANTT

Adjusting the Schedule

If your project has a deadline, the development of your network and Gantt chart will show whether you can make it. If your project cannot make its deadline, then you and the team must re-visit your network diagram and see if you can overlap tasks, change the sequencing of tasks or re-allocate team members to tasks to shorten the schedule.

Let's assume that Mary and her team have to complete the training sub-set of her project by April 15. The initial schedule developed by her team shows the estimated finish date of April 22. In a team discussion, Mary decides that the team can overlap the tasks Determine Pilot Programme requirements and Determine Available Training by 3 days (she changes the finish-to-start relationship between the tasks to a start-to-start with a lag of 7 days). The team also decides that Fred can assist Mary in the task Evaluate Vendors so that the duration is reduced from 10 to 5 days as well as helping her in Evaluate Training Documentation. As a result of the re-scheduling, the team can now meet the deadline as shown in Figures 20 and 21.

Fig. 20 - Adjusting Elapsed

Fig. 21 - Re-scheduled Gantt chart

The most common way of re-scheduling a project is by the techniques used by Mary's team. By over-lapping tasks and by careful allocation of more resources (remember you may shorten the duration but will increase the effort/cost), you can normally optimise the schedule. However, you should be careful as there are some tasks that will not be shortened by adding extra people and, in some cases, adding too many people can actually increase the duration and cost because of administration and communication overheads.

A Note on Scheduling Software

There are a number of PC-based scheduling tools that can assist the team in developing the project schedule. These software packages can automate the processes such as network diagrams and Gantt charts covered in this Chapter. Further, these tools can produce other useful planning and project tracking diagrams such as Gantt charts for each individual, resource loading (who has too much work), task lists including who has been allocated to undertake them and "turn-around" forms which allow you to enter in the actual progress.

Before we continue to look at additional processes and concepts for managing our small projects, let's summarise. At the end of your project planning session, you and your team should have documented the following information:

• project scope;
• project objectives;
• stakeholders and related projects;
• project risks and risk reduction strategies;
• the appropriate project development strategies;
• the tasks required for the project;
• estimates (effort and duration);
• project schedule;
• any constraints and assumptions.

This set of information is often termed the Business Case as it contains information relating to the project management aspects of the project as distinct from the technical details (remember Chapter 1?).

The Business Case would have been developed in a series of team-based sessions as discussed in the earlier chapters. As also discussed, when possible, the various stakeholders of your project would have been involved in these planning sessions. Any problems regarding the details of your project such as the scope, objectives and risks should be raised with your project sponsor for assistance and resolution.

Remember, although there appears to be a lot of information required for the project you're about to undertake, the main reason that you gather this information is to ensure that you, your team, project sponsor and stakeholders are in agreement as to what the project is about and what is likely to happen during the project.

The Business Case is the map for your project journey.

copyright: thomsett INTERNATIONAL 2008 | contact