From time to time we are all faced with the requirement
to develop a schedule. This happens over and over again throughout our lifetime.
Most of the schedules we create are short in duration, are developed mentally
and never committed to writing. This non committal mental scheduling device is a
human safety feature we all carry with us (it helps us keep our sanity). Mental
scheduling is safe because we never really accomplish our tasks in the
procedural pattern in which we conceive them
In today's working environment, projects require team work;
and team work requires community communication planning. Scheduling is a key
part of the planning requirement. Scheduling needs to be committed to writing so
that the project team can share and continually communicate the goals of the
project. The technical personnel on a project must create the data for the
project schedules. The question which most often arises is - "How do I
develop schedule data?" "Where do I begin?" "What tools do I
need?" These questions will be answered, if the steps outlined below are
followed and you adhere to a little discipline. This outline will provide you
with everything you need to know about developing a schedule.
Rule 1: Obtain schedule information
from the people who are going to perform the work.
Generally
you are the source of the information needed for the schedule, because you and
your colleagues have the responsibility to accomplish the work scope. If you are
providing a support role on the project, then you will need to make an
appointment with the individual who is in charge of the work scope and support
the development of the schedule. Either way this is a team effort with the owner
of the work scope providing the basic information needed for the schedule.
Rule 2: Start with the work scope
definition.
The
work scope definition is very important and vital. Definition of what has to be
done needs to be written down, reviewed and agreed to between the party
requesting the work to be accomplished and the party who will accomplish the
work. The work scope should be written to encompass all of the effort intended
to be accomplished in the given phase of the project, and it should be stated
plain enough that all parties are assured that the task is understandable and
correctly communicated. A good work scope definition is normally written by a
team between the project office and the individual who will assume the
responsibility for accomplishing the work scope. The work scope definition is
very important. Without the documented work scope, the proper scheduling of the
tasks cannot begin. If the work scope is not properly defined, the schedule for
the work scope is meaningless.
Rule 3: Establish a start date and a completion date for the
total work scope.
Most
of the time, a start and a completion date will be provided to you. However,
sometimes we are only given a completion date - "please complete this work
scope on or before 17 July 1996." If the start and completion dates are not
provided, then the person providing the source of the scheduling information
must provide these. The contract itself will be one source for valid start and
stop dates. The boss is another source for valid start and stop dates. In
scheduling terms a start/stop date provided by the contract or the boss is
called a "Directed Date".
Rule 4: Make a list of the activities which are essential to
completing the work scope.
Rule 4
will always work best in the sterile environment, however, in today's business
climate a sterile environment may be hard to find. Start with a clean sheet of
paper in a quiet office area and just make a random list of all the individual
task you will need to achieve for the success of the given scope of work. This
list of tasks does not need to be in the order of accomplishment; the list just
need to be a task listing of all the items the "performer" believes to
be essential. Each task list will be totally dependent on the work scope, but an
average work scope in the Aerospace environment should produce about 17
activities; you may have more than 17 and you may have fewer than 17. You
should, however, arrive at more than ten work tasks. If you have over 25 work
tasks, you need to examine the work scope for clarity, or the task list for
citing the correct number of steps needed to be taken to achieve the defined
goals. If you approach 40 task items you probably have two scopes of work and
not a single scope, or the work scope falls into more than one phase of the
project. What you are attempting to do is arrive at a sensible set of tasks
which can be controlled within a reasonable time frame. Your list probably looks
a little ugly right now, but that is fine ... ... neatness starts to count later
on.
Rule
5: Scrub the task list and remove those tasks which are not essential in the
main path to the end goal.
Go
though the task list you have defined and scratch out the excess. You are
required to have no more than ten (10) events on your list of tasks to be
accomplished when you have completed this step. Do not, I repeat, do not destroy
the original listing. What you are doing is taking the task list of ± 17 events
and scrubbing it so that the boss only has to be concern with the key items.
You, the owner of the work scope, are still responsible for the entire list.
Rule
6: Assign a schedule start date and a scheduled completion date to each work
task.
The
boss has been known to issue instructions contrary to the rules. On a piece of
scratch paper in a column headed "Schedule Date", next to the list of
the selected ±10 task, enter all the calendar dates that you expect to either
start the task or finish the task, but do not intermingle start and stop dates.
Drawing on experience, the author would recommend using a set of completion
dates over a set of start dates, but you the owner of the work scope may choose
the style which you like. After you have created the set of completion or start
dates, place the ±10 task in chronological completion or start date order by
number in a column headed "Item Number". This process will produce a
waterfall milestone schedule.
Rule
7: Place the schedule information in a graphic format, i.e., - GANTT,
Milestones, Bar Chart.
Graphics
is always a good idea for schedules as it makes communications easier with
individuals who can not grasp what you are doing. Also, the simpler the graphic
presentation can be made, the easier it is to get individuals to pay attention
to the schedules.
Workscope
Leader"s Schedule: If
the work scope schedule is to be placed on a predetermined format, then you are
to use the format required and the symbology established for the format.
Neatness starts to count from now on. The Workscope Leader"s Schedule is a
formal project document, and therefore once it is created and approved the basic
plan, referred to as a schedule baseline, cannot be change, except by
negotiations.
Project
Master, Intermediate,
& Detailed Schedules: If the work scope schedule is to be placed on a
Project Master Schedule, Intermediate Schedules, or Detailed Schedules, then the
task list which you created should be turned in to the designated program
scheduler for finalization.
The
scratch paper base data which you have created should be filed and held as a
prize possession. Do not destroy, mutilate or loan out the base data. Keep it
handy for reference purposes as you begin to complete the work. When you stray
from the plan a wee bit; go back and review your scratch paper notes, and you
may be surprised on how they will clear up your thinking and get you back on
track.
Conclusion:
You have now completed all of the basic steps required to
complete any schedule. Everything you do with the base scheduling data from now
on will be "scheduling techniques" applied to the basic steps outlined
above. A computer software program can provide aid in schedule techniques and
schedule analysis, but a software program cannot schedule. In case you did not
read this correctly, COMPUTER SOFTWARE PROGRAMS CANNOT SCHEDULE! If you
use a computer to schedule without first accomplishing the Seven Rules stated
above, your schedule will fail at the earliest available opportunity; it"s
Murphy"s law again.
|
|
[Home] [About
Us] [Services] [Events] [Register] [search] [Contact
us] [Members] [Web
board] |