Chapter 24

Chapter 24

Project Scheduling 

CHAPTER OVERVIEW AND COMMENTS

This chapter describes many of the issues associated with building and monitoring schedules for software projects. Students will need to be shown the process of building a schedule for a case study to really understand how it's done. They should be required to build a schedule for one of their own projects early in the semester. Ideally, all scheduling work should be performed using a scheduling tool.

24.1     Basic Concepts

This section is intended to motivate the student's interest in project scheduling by describing several reasons why software projects are not completed on time. There is also a description of a proactive way to deal with unrealistic customer deadlines (based on detailed estimates and use of incremental development to deliver critical functionality on time). Scheduling is no longer a seat of the pants activity. There are many excellent tools that can be used to make the process easier. The basic idea to get across to the students is to break the software project into well-defined tasks, determine the interdependencies among the tasks, determine the time duration for each task, and assign the tasks to project team members. Each task must have defined outcomes and be associated a meaningful project milestone.

24.2     Project Scheduling

Section 24.2.1 introduces a set of basic principles that guide software project scheduling. Each should be discussed during lecture.

The most important point to get across in Section 24.2.2 is that adding people to a project in an arbitrary manner does not reduce the project completion time (and may in fact lengthen the completion time). There are times when a project schedule has slipped so badly that adding people can not save it and the only option a manager has is to renegotiate the completion date with the customer. The effort distribution model presented in this section is a good guideline for students to follow when they build their first project schedules.

Be certain that your students understand that the 40-20-40 rule is a rule of thumb, not a concrete “rule” that must be applied for every project.

24.3     Defining a Task Set for the Software Project

A "task set" is a collection of engineering tasks, milestones, and deliverables. The software process model selected for project provides much guidance in determining the task set. Task set is also dependent on the project type and degree of rigor desired. Students should be familiar with the five project types described in this section. The method used for determining degree of rigor should be demonstrated for case study.

Scheduling involves taking the software engineering task set and distributing it on the project time line. The details of how to do this will depend on whether the software process model is linear, iterative, or evolutionary. The example discussed in this section describes the major tasks for a concept development project. It may be worthwhile to show students the task sets from the adaptable process model available through the SEPA Web site.

Section 24.3.2 contains an example of refining a major scheduling task (concept scoping) into the smaller activities needed to create a detailed project schedule. Students may need to see additional examples of task refinement. 

24.4     Defining a Task Network

Building a task graph or activity network is the key to building a feasible schedule. The task graph represents inter-task dependencies very clearly. This allows managers to determine which tasks may be done in parallel and which tasks need to be done first.

24.5     Scheduling

This section recommends the use of project scheduling tools for any non-trivial project. The PERT (program evaluation and review technique) and CPM (critical path method) are mentioned in the section, but no examples are given. It may be a good idea to show students a simple project activity graph and then show them how to use CPM to determine the critical path and compute minimum project completion time.  Timeline (Gantt) charts are fairly easy for students to understand and are often available as output from scheduling tools like Microsoft Project. The time-boxing procedure described at the end of this section is a time management strategy that students should made aware of.

24.6     Earned Value Analysis

Earned value analysis is an example of a quantitative technique for monitoring project completion to date. If students are able to estimate total project completion time they should be able to compute the percentage of the total project time associated with each project task. The progress indicators discussed in this section are fairly easy for students to compute and interpret.