An example Network Plan
In time, researchers learn how to manage themselves, how to work under the management of another, and how to manage others. Management encompasses planning, organization and control. We start by considering project planning techniques. A plan is a summary of how one intends to carry out a particular task. A plan is a formal statement of the nature of future events and activities and how they are to be carried out to achieve specific goals. A project plan, therefore, includes answers to the following three fundamental questions:
What is going to be done? A statement of the final goal of the project and a series of well defined intermediate tasks needed to achieve that goal. Each of these intermediate tasks should provide some tangible output or deliverable
When is it going to be done? The completion date of each intermediate task, including the completion date of the final project.
Who is going to do it? The need for human resources as a function of time, including the possible need for resources available from outside the organisation or from other departments within the organization.
The skeleton of your plan is derived from the research methods you choose for your project. For example, if you are doing a case study, you will need to include the following stages:
Literature review
Selection of one or more groups to study (i.e. choice of environment, people, task)
Case study design
Questionnaire and interview design
Pilot study
Design refinement
Case study execution: observation and survey
Information analysis
Writing up results
This skeleton should then be fleshed out to be as detailed and specific as possible, and documented as clearly as possible, using charts like those described below. In addition to activities, make sure you are aware of the appropriate programming tools that can reduce your work, and plan which software to use. Plan collaboration with others, work out the roles of team members and plan regular meetings (or other forms of contact, in the case of remote partners). Decide which resources you will use for managing distributed projects, such as coding standards and version control systems. Ensure that resources are available when needed. Research resources can take many forms - finance, equipment, software, literature sources, data sources, research/laboratory assistants, experts/consultants, documents, testers, and so forth. A research plan should be annotated with resource needs, and acquisition of resources included in the schedule where a need is manifested.In order to control a project, account has to be kept, not only of financial expenditure, but also of time spent. This implies that every person involved in the project keeps a personal time record, something which the majority of people abhor and some professional persons do as a rule. Without such a record of time spent on the project by each individual, it is impossible to exercise control.
The Network Plan approach to project planning interprets a project plan as consisting of a collection of events interconnected by activities. The term event" is used to merely indicate the starting and terminating points for one or more activities or a block of activities. The various events are interconnected to form a graphic project Network Plan.
The logical interconnections between activities, or events, express technical, organisational and other conditions. For example, before starting an activity or block of activities, certain other activities have to be completed, certain activities or sequence of activities can be executed in parallel, and so on. There are occasions when the completion of an activity must coincide with or precede the start of an activity in a parallel branch of activities. This dependency is indicated by a broken arrow, indicating an activity which requires no time.
An example of a Network Plan, with events identified by 3-digit numbers and activities labelled with expected number of person-hours, can be seen below.
An example Network Plan
Software packages exist for building and analyzing Network Plans. The features offered differ slightly across tools, and also differ slightly from those discussed here.
There is seldom a single completely natural way in which to partition the work into constituent activities, and in which to connect them. The knowledge about an activity is never complete until the work has been done. Rather than use this as an excuse to avoid planning, a conscious decision has to be made on what activities leading to which events have to be performed, which of the activities are independent and can thus be executed in parallel, and in which sequence to perform the activities.
If several levels of the network chart are necessary, an event on the network chart at level i will expand to a network chart at level i+1. This is a natural process, the amount of detail increasing from the lower levels upwards. Developing a project plan is often a trial--and--error, iterative process, working back and forth between a very general chart, and highly detailed lower-level charts.
After drawing the chart, extend it by estimating the time required for each activity. A network chart extended in this way, is often called a Programme Evaluation and Review Technique (PERT) chart or Critical Path Method (CPM) chart. The difference between CPM and PERT is not fundamental, but rather one of viewpoint. In a PERT type of network chart, events are designated explicitly and emphasized by their placement in boxes. In a CPM plan the events would not be shown; activities would follow directly upon one another. In general, CPM is used by industries like the construction business, where the project includes well defined subtasks, with a low level of uncertainty. PERT charts are more likely to be used in research, where uncertainties abound and responsibilities are seldom well defined.
The first step in introducing time to the chart is to prepare a list of realistic activity times, in consultation with the people allotted the work. A frequent mistake is to assume that the work can always be done during overtime or late at night if the estimate is too low. Make sure that nothing has been overlooked and pay attention to things that may potentially go wrong. Programmers invariably underestimate the time required to perform a task by a factor of 2 or more.
In the Network Plan project planning method, the critical path is the sequence of activities which determines the earliest time at which the project can be completed. Once the critical path is known, one looks for those paths which are not critical but near critical. Such a subcritical path may, due to a missed delivery date, suddenly become the critical path. Or, if the activities along the critical path are expedited, the earliest project completion time may become a function of a subcritical path.
The second step in the chart analysis is to go through the Network Plan and determine for each event the following three times:
The earliest completion time is recorded in the lower lefthand quadrant of each event: the time, assuming that the start is at time zero, when (all its predecessors and) the event can be regarded as completed.
The latest completion time is indicated in the lower righthand quadrant of each event. This is the latest time that an event can be completed without delaying the completion time of the project. Latest completion times are calculated backwards, starting at the end and tracing backwards through all possible paths.
Slack time, the difference between the latest completion time and the earliest completion time, is indicated in the upper righthand quadrant. This is the length of time for which the event could be delayed without holding up the project. The sequence of events for which there is no slack time is the critical path.
The earlier example of a Network Plan is shown here with completion and slack times included.
Network Plan with added times
Using the Network Plan method, it is common and convenient to construct some form of barchart or simplified Gannt chart to graphically illustrate the development of a project with time.
Drawing the Schedule
A barchart has time along the horizontal axis, increasing from left to right. Each activity is briefly described along the vertical axis or rows. The expected start of an activity is indicated by a circle and the expected completion time by a triangle pointing downwards. Once the work on a particular activity has started, the actual start time is indicated by a solid circle; once done, the actual completion time is indicated by a solid triangle. In the event that an activity is rescheduled, the version number is written above the symbols. An example where one activity has been completed, a second started, and two more planned for the future, can be seen here.
An example time schedule
Activities on the critical path can be transferred directly from the Network Plan to the the time schedule. For other activities, a decision as to start time is made, based on the availability of people and other resources. Scheduling is an iterative and a team effort. A skillful manager creates an environment in which the workers feel that the manager is helping them to protect themselves against the consequences of a poor estimate.
Once the schedule is complete, the project manager should determine whether it is realistic, using the following typical set of guidelines:
Is the estimated time for each activity realistic?
Are all assumptions mentioned and valid? It is common to receive underestimated times based upon the existence of resources that have never been explicitly specified and will be unavailable when needed.
The impossible always happens. An estimate based upon the 100 percent availability of equipment or personnel is inviting trouble.
Refer back to the records of previous projects to learn from the mistakes or estimates made there.
If it turns out that the resource or time requirements exceed what is available, the project then has to be scrapped or re-planned, or additional resources motivated for. In the latter case the carefully prepared plan serves as an excellent basis for such a motivation. Even where there are no evident problems, plans put one in an excellent position to ask under what conditions the schedule, cost or requirements can be improved. And when you plan your time upfront in a realistic way, you will not be discouraged during stages of lower productivity, as these will have been recognized and anticipated from the outset.
A plan is of no use unless control is exercised to ensure the plan is adhered to, or that action is taken timeously when this is not the case. Project control thus involves regular checking of progress against the current project schedule, and taking appropriate action wherever tasks are delayed or postponed or producing inferior outputs. If scheduled tasks have not been started as planned, or are taking significantly longer than anticipated, this needs to be carefully considered to identify the cause of the problem and the best remedy. This can mean giving the individual concerned greater assistance, support, encouragement and incentive; it can mean revising the plan in the light of new knowledge or problems; it can mean changing the allocation of people to tasks; etc. It is the nature of research that the process cannot be spelt out in detail at the outset and then simply executed as plan change is to be expected, and plans revised accordingly as the research proceeds and you learn more about the problem. If tasks are being completed on time, project management requires checking that they have been adequately done this can involve using appropriate software testing procedures, obtaining feedback from others through user testing or seminar presentation, etc.
The documents produced during the project planning and scheduling phases form the input to project control. Overall control is guided by regular reports of the variance between actual times spent versus budgeted time (and of financial expenditure vs budget, where applicable). Although these variance reports do not indicate whether the project is on schedule or not, they do indicate whether human resources are being used at the rate predicted. Depending on the reason for a variance, it may serve as a warning of impending problems.
This form must be completed at the end of the planning phase and for each subsequent activity. This report comprises the following fields, as can be seen in the example below:
A Variance Report
Item: The code of the element, task or activity to which the row refers.
Reporting Period: The number of actual hours spent on the item during the current reporting period..
Work in Progress (WIP): The total number of hours spent to date on an item on which work has started but has not yet been completed. This includes the time spent during the current period..
Cumulative: The total number of hours spent to date on the item. Once work on an item has been completed, this number will remain the same from one reporting period to the next. Otherwise it will be the same figure as that in the column marked WIP..
Target: This column contains the original hour estimate for the item at the time of planning or replanning..
Expected: The current estimate of the number of hours required to complete the work on the item. This number may vary from one reporting period to the next as work progresses and new information comes to hand. Such new information may also effect the time estimates for items on which work has not yet started..
Variance: This is the field which contains the difference between the target and expected number of hours.
A/E. If the work on the item is still in progress, an E for expected will be filled in; otherwise A for actual.
The variance report discussed above is the primary source of information concerning the status of the project and how that status was reached. Depending upon the number of person-hours expended per day, a variance report should be completed every one to four weeks.
Negative variances on almost every item of the project imply that work expended is in excess of the target total. If the manager knows that an intense effort has been made to advance the project, the negative variances are a confirmation of this decision. If the increased rate of work was not a conscious decision, it is clearly necessary to determine whether the project is on schedule and not experiencing technical difficulties. If there are severe technical difficulties, another planning iteration is obviously called for. On the other hand, if all items are behind schedule, the negative variances are early warning signals of an important problem. If the project is on schedule and there is a continual pattern of negative variances, the original time estimates may have been too low. Again a new iteration of the planning process is required. A careful audit of the personal time reports of those working on the project may on the other hand reveal a typical human problem. Because the project appeared to be running well, there may have been a tendency to free load on the project, i.e. idle time could be charged to it without arousing suspicion. Equally, the unjustified time charges against the project may have been made by individuals on another project which is in trouble. A manager who uncovers either type of dishonesty should make this discovery known without embarrassing the individuals concerned. The same is true when anyone consistently underestimates the time required for an activity in an attempt to reflect favourably on their own capabilities.
Variances consistently positive indicate that less manpower is being used than originally estimated. If the project is on schedule, all is well. However, little time spent on a project indicates people failing to work on the project at the planned times. This may be because they are stuck with technical problems, lack resources or have been assigned other work. If the job is on schedule and no technical difficulties are reported, then it could be one of those rare situations where things go better than predicted. On the other hand, the original estimates may all be too high. Overestimates are generally troublesome in that more resources may be kept available than are needed. This has direct implications for the productivity of the team which ultimately will effect everyone concerned.
A mix of relatively minor positive and negative variances, in a project that is on schedule, is a cause for rejoicing. But be wary of a natural human tendency to make the actual time expended agree with the estimate. This kind of dishonesty will only become evident in one of two ways: either the original time estimates were close, and the project schedule will eventually suffer; or the original time estimates were too high and will adversely affect productivity of the team.
The basic data used to plot project progress with time are two percentages -Actually completed and Completed + WIP. As an approximation of the status of the project, these are a valuable management tool. Models do not have to be exact analytical representations of the real world; they need only be close enough to be useful as a control tool.
The following are typical patterns which should reveal trouble:
Going nowhere: reporting period after reporting period elapses, but the Actually Completed percentage changes very little.
Forever 95% complete: some tasks, elements or projects move very well up to a high level in terms of Actually Completed percentage and then they just remain there. The Completed + WIP percentage would soon show that the project is behind schedule however, since some activities always seem to be 85% or 95% complete, but never 100%.
Too good to be true: a continual, remarkable high level of agreement between Actually Completed percentage and elapsed estimated time is a clue to dishonest reporting. If allowed to continue, this situation usually degenerates to the forever 95% complete case, since the reported percentages bear little relation to work progress.
Sudden surprises: an activity is making progress as expected in terms of Actually Completed percentages when suddenly a dip occurs. This is quite acceptable as a single occurrence, but it may nevertheless be wise to establish the reason for the sudden lack of progress.
Lack of cooperation: one may occasionally find someone who refuses to give their estimate of the percentage of work completed on an activity. This can be an indication of trouble with the activity or, worse yet, with the individual. Failure to keep or obtain the records discussed leads to a crisis management approach which only compounds the problems in out-of-control situations.
Most creative people have an inherent bias against paper work, and resent the record keeping and analysis required for project control. For this reason those activities should be kept minimal and the reporting processes as simple as possible.