EE Senior Project Control Documents.
Document Title: Project Schedule
Background:
The program schedule is probably the most visible document in any project. Once management buys off on the project plans, and commits resources to the program, then the only question in their mind is "are they going to complete the project on time." Of course the cost of the program, and the product features are also major concerns, but the schedule stills gets the major scrutiny.
To do a good project schedule requires a great deal of background information. One doesn’t just sit down and lay out the plans without doing lots of data gathering and planning. The data to make a schedule comes from several sources. It also takes two different types of information to make up a good schedule, the break down of the project into the various tasks, and the estimation of the time to complete any particular task. The team members themselves provide the main inputs, especially if they are experienced designers with several projects under their belts. Unfortunately, many designers, even those with past project experience have not kept good records of their past projects, and have a difficult time estimating the time to complete the pieces of the program.
The first step is to decompose the project into several levels of tasks. At the highest level, the project is made up of major blocks in a system design. Then each of these blocks is broken down into its key pieces. This process is continued until the project is broken down to a level where the tasks can be assigned to individuals. This process is usually done with all the team members involved, and hopefully with the help of information from past projects. In larger projects, it is very difficult to estimate all the details at the beginning of the project. This is why projects are broken into separate phases. Teams will develop detailed schedules for the activities in their current phase, but only have a high level schedule for other future phases of the program.
Once the project is broken into individual tasks, then starts the hard part of estimating the times for each task. Engineers are usually too optimistic about estimating the time required to complete a sub-task, and generally don’t take into account any unforeseen problems that may arise. It is the job of a good project manager to add in some contingencies so that the schedule is actually realistic. Unfortunately, the definition of "realistic" varies among management teams, and is heavily weighted by the company philosophy about schedule accuracy vs. time-to-market. This is the area where having some past knowledge of actual projects is invaluable. If the team can draw on past data, then they can make decisions based on experience vs. gut feelings.
Once the tasks are broken out and times assigned then the iterative part of the scheduling occurs. This is where the various project sub-tasks are moved around in the schedule to try and balance the resources against the job at hand. The concept of a "critical path" comes from the effort to make sure that each project resource is equally busy in getting the total project completed. The critical path is the linking of tasks across the schedule, where there is no slack time in any path. Luckily, we have several good software scheduling packages that do most of calculations for this problem. The Microsoft "Project" package is a good example of such a tool.
Document Objective:
As stated above, the purpose of the Project schedule is to provide a planning tool for the team, to make sure that they have covered all the required tasks, and that they can meet the required schedule dates. It also provides management visibility on the progress of the team, and the quality of planning that was done. The schedule is an integral part of the project contract. The FSD sets the objectives for "what" will be done, and the schedule establishes the "when".
Document Requirements:
For the EE Senior Projects use the Microsoft Project software. Since the project has a short duration, and most of the information is available about the project, only the detailed schedule is required. It should contain information about the tasks and task assignments. The critical path should be highlighted. This schedule will be used at the scheduled design reviews to assess team progress.
Summary:
The Project Schedule is an important planning tool. Often it is seen as only a tool for management to hold the team's feet to the fire, but in fact, it has more value to the team in doing the essential planning to smoothly complete a project. It is living document that should be updated when program changes are made, and reviewed at every major checkpoint.