schedule

Document Sample
schedule Powered By Docstoc
					                    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.