|
|
Introducing Project Management
Concepts
White Pages | Index | Introduction | Basics | Creating Plans | Scheduling the Project
More Advanced Topics
Reduce Project Time
Reduce Project Time
Hornet may be used to develop a project plan and identify how the project time can be reduced. The stages involved are:-
You produce an initial plan to find a project's critical path, this indicates how long the project will take to complete. Your initial plan may show up a number of logic errors, such as logic loops. Hornet warns you when it finds errors, such as logic loops, during scheduling and indicates which activities are involved. You may then examine the activities and correct the error. Reduce project time Your next planning task is to use the initial plan to see how you can reduce the project time. Projects vary greatly, so we cannot advise you specifically how to reduce your project time. Asking a series of what if? questions, will enable you to work towards a most effective solution for your project. Questions you could ask may include: what would happen if we carried out this activity before that one?; what would happen if we performed an activity this way rather than that way? Hornet can produce schedules quickly, allowing you to ask as many of these questions as you like, and get answers, without spending too much time doing so. This would be impossible manually. Resources Resources are crucial to the process of reducing project time. It is accepted practice in project management first to work out a time schedule, and second to consider the effect of resources. This is because it is important not to allow resource considerations affect your initial network logic. While you are determining your project's activities, you may assume that because two activities require the same item of equipment, one cannot start before the other is finished. This assumption would be reasonable if the equipment were irreplaceable, for example if it were very old and no longer available. If the equipment was available, it might be more efficient to buy more of it rather than delay an activity. If you allow resource constraints to affect your network logic (by making two activities that require a replaceable piece of equipment take place one after the other), you impose an artificial constraint on the project. Hornet's resource scheduling facilities are valuable in that they act as a modelling facility at this stage in your project. By using them to test options, you can find the most efficient way of scheduling the project. Projects may be time-limited or resource-limited. In most projects there is a balance between the two extremes. Some resources are very limited and some are freely available. One of the values of the time schedule is that, by showing which activities are critical, it points to activities that may benefit from increased resources. It is usual to establish a time schedule first. This shows the activity dates only and ignores resources. The time schedule effectively shows what would happen if the resources were infinitely available. Time-limited projects A project in which time, rather than resources, is the major constraining factor. Such projects must be completed by a specific date and are completed by acquiring whatever resources are necessary. In some projects, this is the case. For example, if you are absolutely committed to complete a project by a given date as in a time limited project, you will get all the resources needed to do so. Resource-limited projects Some projects are completely limited by the resources available. For example, if one person is writing a book, the project will take as long as it takes that person to write it: bringing in extra resources will not help. Thus, after producing your initial plan, the what-if? questions can include questions such as: what if we hired more men to work on this critical activity?; what if we spent more money on that critical activity?; what if we hired another lorry to move that piece of equipment? You answer such questions using Hornet's resource scheduling facilities. However, in order to do so, you must determine the resource availabilities first. You also have to determine what work the resources will be required to perform. Because you have already established the activities in the project, this task is actually to decide how much of each resource each activity will require. These resource requirements can then be balanced against the availabilities. You then use Hornet’s resource scheduling facility to study the effect of resources on the project by showing how long the project will take to complete, given the resource availabilities and limits. Resource scheduling is important in determining the final plan. Final Plan Having spent some time considering options, you then establish the project plan. You should spend long enough on this to make sure that resource use is efficient while also retaining some slack. It is a good idea to leave some leeway in resource use to allow for contingencies such as illness or bad weather. Once you have determined the plan, you can archive it in Hornet. This means you can permanently store it away, to be retrieved during the implementation stage and compared with ongoing events. Project Monitoring Hornet's second major function is monitoring progress - continually comparing current reality with the plan. At regular intervals during implementation you update the activities by entering into Hornet the dates on which they actually started and finished. Each time you do so, if you run the project through one of Hornet's scheduling routines, the result is a picture of current reality, showing which activities have finished, which are working, and which are still in the future. The archived bar chart is a typical monitoring tool. Each activity is represented by a set of two bars that show the original archive schedule (the final plan) and the current results. By using this report, you can see if your project is progressing as planned. In order to interpret schedules such as this before and after implementation you need to know more: first about network logic, and second about the special types of activities you can build into your project.
Special Types of Activities
A ladder is a series of activities that run in parallel, each linked by a start-to-start and finish-to-finish link. For example, we could represent the activities ‘Dig trench’, ‘Lay pipe’ and ‘Refill trench’ as shown below:
The ladder is a very useful device in a network. However, you have to be careful when interpreting ladders in schedules if the duration of each activity in the ladder is dissimilar. Ladder Example This example consists of building walls, which will take eight days, plastering them, which will take five days, and painting them, which will take only three.
As enough of the walls should be built by the end of day 3 to allow the plastering to start, there is a three-day delay between building and plastering. As two days should be enough to allow the plaster to dry, the painting can start two days later. The forward and backward passes yield the following early and late start and finish dates.
The earliest start of 'Plaster walls' is day 4 and its earliest finish is day 11, yet its duration is only 5 days. This indicates that, as it cannot possibly finish before day 11, there is no point in starting it until day 7. This waiting period, from day 4 to day 6, is sometimes known as enforced lag time. On a Hornet bar chart, it shows as preceding float. Both 'Plaster walls' and 'Paint walls' show preceding float.
If you wish to avoid this situation, where the plasterers and painters could apparently be kept waiting for four days, you might choose one of several solutions.
The ladder example shows one illustration of a ladder. Alternatively, you could redefine your activities slightly. Suppose that, instead of thinking merely about 'build/plaster/paint', we thought of the different walls separately. We could then join these activities into a special type of ladder that would look like this.
FS links Here, instead of one activity we have three. Thus, instead of 'Build walls', we have 'Build A', 'Build B' and 'Build C', all linked by finish-to-start links. In addition, 'Build A' is linked to 'Plaster A' and 'Paint A', again all joined by finish-to-start links. The original purpose of the logic delay between 'Build walls' and 'Plaster walls' was to represent the time it would take to build enough wall to begin plastering. However, because, under the new logic, 'Plaster A' cannot start until 'Build A' is finished, the delays are no longer necessary. As a result, we have omitted the logic delays. In addition, because building each wall will only take one third of the time it would take to build all three, the duration of 'Build A' is now one third of the duration of 'Build walls'. Caution This type of arrangement can be very useful when a series of activities is repeated over and over. However, please note that since this arrangement increases the number of activities in the network we recommend that you only use it when necessary.
A hammock is an activity that represents a series of other activities. For example, suppose you were an architect in a large company and had been asked to submit a plan for a new plant. The first phase of the job might be to design the plant, make a model of it, and submit it for approval. You could make phase 1 a hammock.
Phase 1 has a start-to-start link with Design and a finish-to-finish link with Approve. In addition, there are finish-to-start links between Design and Model and between Model and Approve. (Note that there is no link between Model and Phase 1). Purposes If you did this with all the phases of the project, you could later produce a concise report that only shows 'Phase 1', 'Phase 2', 'Phase 3', etc. This is the principal use of hammocks. Hammocks are also used in cases where an activity's duration cannot be precisely estimated because it is dependent on other activities. For example, suppose we were planning the launch of a new product. One activity in our network might be 'Prepare magazine ads', which could represent a series of other activities such as planning the different advertisements, getting approvals, writing the copy, and so on. Zero duration Because the duration of the activity 'Phase 1' would be dependent on the other activities, it could make sense to make it a hammock and give it a duration of zero. If you give a hammock an estimated duration, it must always be less than its actual duration. In fact, it is best to make it zero. For example, suppose Phase 1 were a hammock and had an estimated duration of 20 days, while the combined durations of the Plan/Model/Approve group was 15 days. Hornet would show a stretched logic link on Approve Plant to the end of the hammock.
This is meaningless because the purpose of a hammock is to represent the other activities. The hammock must stop when the last of the activities it represents stops.
Some projects contain important events that mark milestones in their progress. For example, Start, Completion, or End of Phase One. Key activities usually have zero duration. If you have milestone activities such as this in your projects, you can use select and sort criteria to produce reports that only show the key events, or you can highlight the key events.
Interpreting Schedules
Schedules show the results of the forward and backward passes. At the same time, they show any special features such as dummies, hammocked or key activities. A schedule is a picture of the factors you have built into your project, spread over time. Bar charts A bar chart is a way of viewing a schedule. If you understand networking, principally network logic, you should be able to interpret bar charts and other schedules. Although Hornet offers other types of reports such as data lists, we use the bar chart as an example here because it is representative of the alternative reports. Certain anomalous situations appear in schedules. Except for negative float, you cannot specifically see these situations on a bar chart, but scheduler messages issued during scheduling warn you when they occur. These situations are:
A logic loop occurs because of logic errors in the original network diagram. In such situations, the forward pass cannot be performed, and Hornet displays an error message indicating which activities are causing the problem. You may have made a typing error entering the activities. Otherwise the loop must be part of the original network, which must be examined carefully in order for you to find the loop. Logic loops can occur relatively easily in large or complex networks and are a common error of novices and experienced planners alike. Moreover, logic loops can be more complex than they initially appear.
When creating a network containing this configuration, it would be easy to enter the links according to this logic:
Because each activity is a precedent of the other, Hornet cannot work out the logic. It is wise to watch out for this type of situation if logic loops appear. Solution To solve this problem, add a dummy activity after A.
Leading activities and trailing activities show up on bar charts as activities with very long float. The first activity in every network is, legitimately, a leading activity and the last is a trailing activity. However, activities with excessive float either from the project start or to the project end may reflect logic errors. Consider this network.
Here, activity 140 is a legitimate trailing activity. Because it is the last activity in the network, it has no succeeding activities. Similarly, activities 90 and 100 are leading activities (they have no precedents). However, activity 120 is more suspect. If you forgot to enter its link with activity 100 (shown by a dotted line), it would have no precedents. Therefore Hornet would schedule it to start at the beginning of the project and, due to its finish-to-start link with 140, to end when 140 starts.
Conversely, any activity with no successors would be scheduled to end on the last day of the project and would show very long preceding float. Thus, any activity that shows float from or to the project end may conceal a logic error in the network.
Although it sounds like a contradiction in terms, critical activities can occasionally have float when start-to-start links are involved. The following example illustrates the type of situation in which it can occur. Imagine a section of a larger network in which we are building two houses: one big one, and one smaller one with a garage.
We can start building both houses at the same time, but cannot build the garage until the second house is finished. Therefore, there is a start-to-start link between 'Build house 1' and 'Build house 2', and a finish-to-start link between the 'Build house 2' and 'Build garage'. During the backward pass, Hornet calculates that 'Build house 2' finishes when 'Build garage' begins because of the FS link between the two activities. However, as there is no link to indicate when 'Build house 1' must finish, Hornet assumes it will finish at the end of the project. This gives this bar chart.
However, the dates for 'Build house 1' are:
Because the finish of 'Build house 1' is not constrained by any logic link, Hornet has calculated its late finish is the project end, day 11. It has also calculated that the late start is the earlier of:
As a result, the early and late start of 'Build house 1' are both day 1. One criterion for criticality is that an activity's early and late start should be same, which is the case for this activity. However, another criterion is that the activity must not have float - but 'Build house 1' does have float. In fact, as this example demonstrates, critical activities can have float under certain circumstances. In this case, the activity's early and late start dates are the same, but its finish is not constrained. By the same token, critical activities whose starts are not constrained can show float. It is important to be aware of this when interpreting bar charts and other reports.
By default, Hornet does not show negative float, and unless you particularly want it to do so, we recommend that you do not enable it when creating the project. However, if you use target dates in your projects, you may wish to consider using it. For example, we will examine this very simplified network. It contains three activities which have finish-to-start links and whose durations are 5, 11 and 14 days respectively. The first activity has a target start of day 15.
If you run this network through Hornet's time scheduler, you obtain these dates:
Suppose, however, you give activity C a target finish date of day 39. Working backwards from day 39 to find the late dates gives this result.
The activities' late dates are now earlier than their early dates. In other words, the earliest they can start is later than the latest they must start in order to respect the target finish. This is an impossible situation: the activities simply cannot be completed within the target you have specified.
The negative float starts on the activity's late start date and runs to its early start date. It effectively shows the amount of time by which the target date cannot be met. When you schedule the network before producing this bar chart, Hornet will display an analysis report informing you that the target finish cannot be met.
|
