Abstract
Project management is about optimizing time, cost, and quality performance on projects. These three variables are intrinsically linked. Changes in requirements of these variables frequently occur and the project manager has to be able to re-plan the project accordingly and provide revised estimates for the linked variables.
In practice the most common requirement for project re-planning calculations concern time and cost. Clients often ask for projects to be speeded up and need to know how much of an increase in speed is possible as well as what it will cost.
The analysis and execution of this time change, and its attendant impact on cost, is commonly known as crash analysis. In crash analysis, a project manager offers re-planning advice based on the functional relationship between time and cost. The objective is to look at that relationship for the process concerned and to generate an alternative cost and time scenarios. The client can see how much it will cost to meet a range of different time options.
Introduction
The planning process is concerned with taking the project statement of work (SOW) and breaking it down through a work breakdown structure (WBS) into separate work packages, and then calculating the precedence logic of these activities so that a network can be produced using critical path method (CPM) or program evaluation review technique (PERT). The end result is a project schedule. This schedule defines the main time and date milestones that will apply to the project as it is originally envisaged.
As soon as the schedule has been established, things immediately begin to change. For example, clients often ask for projects to be speeded up and need to know how much of an increase in speed is possible and what it will cost. The analysis and execution of this time change, and its attendant impact on cost, is commonly known as crash analysis.
Crash Analysis
In crash analysis, the project manager offers re-planning advice based on the relationships between time and cost. This of course assumes that performance or quality criteria are fixed, as is the case in most projects. In most cases the specified outcome is fixed.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition defines crashing as, “A schedule compression technique in which costs and schedule tradeoffs are analyzed to determine how to obtain the greatest amount of compression for the least incremental cost.”
As a compression technique, crashing concentrates on the project schedule in an effort to accelerate the project's completion date. Plausible examples of crashing include:
Over-time
Allocating additional resources to specific activities
Hiring additional resources
Incentive payments for early completion
Subsequently outsourcing portions of the project to be completed within a shorter time period than would have been possible if the same work was to be completed by internal resources.
Crash analysis would be used, for example, where a project manager produces a project schedule that is not acceptable to the client. The project manager's calculations may indicate that the project will take 45 weeks to complete at a cost of $1.9 million.
The client may not be able to accept the 45-week duration, as completion earlier may be critical to the continued success of the business product line. The client may ask the project manager to increase the resources on the project and complete in no more than 38 weeks. Generally, if time for completion is reduced, the project will cost more as additional resources have to be introduced. The project manager has to be able to calculate the optimum combination of resource increases required to meet this shortened project duration.
To reduce the duration of the project, it is necessary to concentrate on reducing the critical path. The critical path is the shortest time that the project can be completed. An attempt to shorten noncritical tasks would be ineffective, as this will not allow the project to be completed any sooner. Generally, a project will have clearly defined time and cost performance at the start. If it is assumed that the project is subject to the classical time, cost and quality success criteria, then it is possible to consider time and cost as a function. This is done most simply if we assume that the third variable, namely quality, is fixed. If this assumption is made, then cost can be considered as a function of time, and the relationship between the two can be plotted as a curve.
A typical curve for the time–cost function of a project is shown in Exhibit 1. Generally, a time–cost curve will typically have a starting point at the agreed tender or project price. This usually represents the minimum or near-minimum cost value and the near-optimum time values. In Exhibit 1, this position is represented as point A and is typical of optimum time and cost considerations for most types of project.
In order to reduce the time estimate and save time on the project, there will almost certainly be a requirement to increase resources. This will allow the project to finish more quickly but will result in a cost increase. If a project manager is looking for different ways to achieve this, the most obvious way is to work out which activity can be speeded up at least cost, and then crash (i.e., reduce the overall activity duration) that one first, followed by the next cheapest, and so on. This will result in the typical negative time–cost curve shown in Exhibit 1, increasing in gradient as overall time for the project decreases. This curve will reach a point where all critical-path activities have been speeded up as far as possible. Beyond this point, no further time can be saved on the project. Any further crashing will result in cost increases, and no further time will be saved. The curve will therefore be vertical.
Thus, Exhibit 1, point (A) represents the original starting point, where the project will take 30 weeks to complete. This is the agreed tender amount and the agreed project duration. In this case, the tender amount is $60,000 and the project duration is 30 weeks. Point (B) is where the time allocated is reduced to 20 weeks, and the cost increases to $80,000. Point (C) represents the shortest time possible, in this case 15 weeks, and cost increases to $150,000. Beyond point (C), no further time-savings are possible. One reason for this could be that all the critical-path activities have already been fully compressed.
Exhibit 1 - Typical Time-Cost Curve.
The classical time-cost curve is one example of a trade-off curve. They allow the project manager to consider different scenarios when contemplating changes to time, cost or quality performance.
The basic process involved in generating a time-cost (crash) curve is to:
Define the project logic;
Add the duration for each activity;
Establish the project critical path;
Calculate the cost of crashing each activity;
Calculate the cost of crashing per unit time;
Calculate the most cost-effective crash sequence;
Check the critical path;
Crash the network up to crash limit.
Each of these steps is described in more detail below.
Define the project logic. The project precedence diagram can be developed, based on either logic driven or resource-driven constraints, once the WBS is known.
Add the duration for each activity. Determine each activity's duration and assign accordingly.
Establish the project critical path. The forward pass and backward pass would then be performed. In terms of project crashing, the critical path is of primary importance. There is no point in crashing any non-critical activities, as this will simply increase costs while giving no time saving. In most crash calculations, the starting point would be a list of all the critical activities, as identified by the forward and backward passes.
Calculate the cost of crashing each activity. The cost of crashing is a function of resource limits and availability. There will be limits on the amount of resource that can be applied to any given activity. Additional resources may be immediately available at the same or greater unit costs, or available later at the same or increased unit cost, etc.
It is generally possible to establish crash costs for most activities in a project schedule. The crash cost for increasing the rate at which trenches are being excavated by machine would be the hire rate of bringing on another machine plus any other overheads such as driver costs and fuel.
In most cases there will be a number of different activities on the critical path and therefore a number of options relating to which items to crash first and what the subsequent sequence should be. The sequence can be isolated relatively easily by converting the crash cost to a cost of crashing per unit time.
Exhibit 2 – Crash Costs Example.
Exhibit 2 lists a number of activities with normal and crash durations and costs. Activity A–B has a normal duration of eight weeks, and a crash duration of six weeks. The normal activity cost is $20,000 and the crash cost is $40,000. This means that activity A–B costs $20,000 to complete working at planned speed and with planned resources. If there is a need to increase the rate at which A–B is completed, then the activity can be speeded up to finish in a minimum of six weeks. However, this will involve allocating additional resources to the activity and this in turn will lead to an increase in the cost of the activity. The new cost allowing for full crashing will be $40,000.
Calculate the cost of crashing per unit time. The cost of crashing for most activities can be calculated relatively easily. Crash A may cost $20,000 and save 2 weeks. Crash B may cost $24,000 and save 2 weeks. The cost of crashing per week will therefore be $10 000 per week for Crash A and $12,000 per week for crash B. It would obviously be preferable to crash A before B if possible, as the cost increase per unit of time is considerably lower. The cost of crashing per unit of time is shown in Exhibit 3.
Exhibit 3 – Cost of Crashing Per Unit Time.
Calculate the crash sequence. The crash sequence will usually start with the cheapest unit-crash-cost item and progress to the most expensive unit-crash cost item. From the example, the obvious order for crashing is therefore A–B, B–C, D–E, E–F, and C–D.
This will generally appear as a negative curve, rising more and more steeply away from the origin (which represents original project time and cost). The curve should always rise more and more steeply as the unit crash cost increases for the later items, producing a cumulative effect that is more and more costly.
In practice, it may not be necessary to crash the entire sequence. The re-planning process might only require a time saving of (say) four weeks, in which case it would be sufficient to crash the first two activities only. This would save the required four weeks at an overall cost increase of +$44,000. Once this kind of trade-off curve can be generated, different scenarios can be given showing potential changes in time or cost in relation to the consequences of achieving them. Exhibit 4 shows the most logical crash sequence and the corresponding cost increases for the project.
Exhibit 4 – Cost of Crashing Per Unit Time With Cumulative Project Cost and Duration Totals.
Check the critical path. Muir's Law states that “When we try to pick out anything by itself, we find it hitched to everything else in the universe.” As critical path items are crashed, the overall length of the critical path will reduce. In most cases, this means that at some point the original critical path will no longer be critical, because it will become shorter than one or more parallel paths through the network. It is therefore important that the critical path is checked after each crash to ensure that it is still critical. And if a parallel path becomes critical before the crash limit has been reached, then the process has to be repeated so that a new critical path can be identified.
In some cases, two critical paths may appear. If this occurs, it is no longer viable to crash a single critical path. It now becomes necessary to crash both critical paths at the same time. This involves identifying those activities on each critical path that have the lowest cost of crashing per unit time and then crashing them simultaneously. Once this has been done, the next lowest pair is crashed at the same time, and so on. Once any critical path becomes fully crashed, that is the end of the process.
Crash the network up to the crash limit. The crash limit is the point at which no further crashing of activities can take place. The most common form of limitation is by critical path. All the activities on the critical path could be crashed and it still remains the critical path. There is no point in crashing alternative non-critical activities. The crash curve will therefore adopt the classical profile shown in Exhibit 1. Each event on the curve shows one crash or time-cost trade-off alternative for the client. The main points on the curve will be the following:
Optimum cost point. This is the project starting point. The lowest cost will be established for a given time. In order to reduce time, costs will have to increase as more resources will be required. If more time is taken, the project cost may not reduce because of fixed or overhead costs.
First crash point. This is the point (point A) to which the project can be crashed using the cheapest crash cost per unit of time for a critical path component. It therefore generates a negative curve with a shallow angle. The next part of the curve is normally steeper.
Maximum crash point. The maximum crash point (point D) is the point at which all critical path activities have been crashed right up to their limits. The only other items that can still be crashed after this are non-critical ones. Crashing these will result in cost increases but no time savings because the items are non-critical. This area corresponds to the vertical section of the curve.
Fixed overhead curve. This is the region in which additional time is allowed for the project although no extra resources are injected. Fixed overheads continue to accrue, and hence overall costs increase.
Conclusion
A compression technique such as crashing allows the project manager to offers re-planning advice based on the functional relationship between time and cost. Objectively, the project manager can generate alternative cost and time scenarios. Furthermore, crashing the schedule provides the client with feasible options. At a glance they can review and accept a range of time saving alternatives and their cost implications.
Knowing the critical path in the project schedule is key. This will dictate the current finish date for the project. It will also identify the activities that need to be reduced if the project is to be completed sooner that what was first envisaged. By assessing the associated costs of reducing the critical activities, it is possible to select the most cost effective crash sequence.
