You are currently viewing How to handle project schedule overruns
Domino effect

How to handle project schedule overruns

Domomo effect
Domino effect

Missing your project deadline

Delivering a project on-time will always be challenging for project managers. You’re midway through a project and realize that the project will miss a key milestone. You are also afraid that through the domino effect you may also miss the deadline for project completion. There is always a consequence to a schedule overrun. The client is unhappy because she can’t take ownership of a building and is consequently losing money. The contractor and his principal eat into their profit margin for every day of non delivery.

Remedial techniques

In the first instance the initial project planning must be done properly. If the schedule is under estimated or not logical, planning inefficiencies are introduced to the project. Invariably this can lead to delays in the project and increase the initial schedule.

There are two techniques that project managers use to attempt re-mediating project schedule overruns namely compressing and crashing the schedule. In most instances crashing or compressing the schedule are the last options.. Crashing and compressing are scheduling techniques that you may want to implement when the project is behind schedule.

Your initial schedule

The initial schedule should be the best available schedule. Use “what if” scenarios to develop the best schedule for your project.

What-if scenarios change the model. The project team develop the schedule to understand the best option for undertaking the work, testing different sequences and different work or procurement options. Different options are developed and compared. The option offering the best outcome should be selected. However, “best” is not defined simply in terms of the shortest duration. Cost, risk exposure , quality and other factors need to be carefully considered. The final decision on the “best” option is an overall project management decision, not a scheduling decision. The first option is always to have a realistic achievable project schedule where overruns will be unlikely.

Compressing the schedule

Schedule compression is a technique that is used by taking the initial schedule and shortening the project schedule duration.  You do this in a manner which does not reduce and or minimize the project scope in any way.

Compressing a schedule means that you will be conducting project activities in parallel. Task splitting is re-organizing the (usually) larger tasks into several smaller components, so that the follower tasks can begin sooner, after completion of only part of the preceding task.

It is best practice given a choice between crashing and compressing, always attempt compressing first. It is less risky.

Fast tracking
Fast tracking

For example, the painting of a multi-storey apartment building could be done as each floor is completed, rather than waiting until all the floors are complete. Defining painting as a single task in the initial network would force us to consider splitting as a way of saving time, especially if painting was a critical task.

Therefore, in order to split two tasks to shorten the duration of the project, there are three criteria to be observed:

  1. Both tasks must be on the critical path. The longest path through a network determines the project’s duration. Therefore, the critical path must be shortened to save time.
  2. Both tasks must be in sequence.
  3. Both tasks must use independent resources. Otherwise you don’t  have free resources to perform the task that you want to do in parallel.

Risks involved with schedule compression

  • The risk involved is that problems can occur with dependent tasks.If you work on design followed by production your risk is that you need to rework production if the design is changed half way through the process.
  • It is very easy to draw overlapping lines on a bar chart – translating the accelerated work into real performance on the project, makes managing the work more difficult. Fast tracking almost always results in increased risk and may result in rework that will counteract some of the initial gains and reduce the potential savings

Schedule Crashing

Crashing is a resource based methodology, since its inception in the 1940s. “Crashing” has involved adding additional resources at a project to reduce the overall duration of the work. You either work the existing resources harder/longer or get more resources.

The commonest resource to add is human effort, but the principle applies to any active resource. Simply supplying more construction materials will not in itself accelerate a task, but adding another complete standard crew will. “Effort” is the key word.

There are usually various options you can use to crash a project schedule. For example increasing the rate of supply of resources by increasing the size of the crew on the job or adding another crane increases the daily effort applied to a task and shortens its duration. Adding a second shift or working a longer day accomplishes the same thing, but it may be cheaper to add more resources to the day shift.

If we add human resources to the project there must be training and familiarization with the project before they can become productive. Initially the new human resources may slow down the project.

Computing your crash data

The inputs you use are:

  • Activities, normal time, normal cost, crash time and crash cost; to compute maximum time reduction and cost to crash per period
  • You need a crash table to calculate the crash cost for each task. The total crash cost for a certain project duration can then be calculated. Next weigh up the costs against the benefits to decide whether crashing is worth the additional effort and costs.

Rules for crashing

  • Crash only activities that are critical
  • Crash from the least expensive to most expensive
  • Crash an activity only until:
    • It reaches its maximum time reduction
    • It causes another path to also become critical
    • It becomes more expensive to crash than not to crash
  • To accurately evaluate your crash decisions you should review the critical path after every crash

Risks involved with schedule crashing

  • Budget: Since you allocated more resources, you will not deliver the project on-budget
  • Demoralization: Existing resources may get demoralized by the increase in people to complete activities that were originally assigned to them
  • Coordination: More resources lead to an increase in management challenges
  • New resources aren’t going to be familiar with the tasks at hand, so they will probably be less productive than current team members

Ultimate decision to shorten the project schedule

The final decision on the ‘best’ option is an overall project management decision, not a scheduling decision. The first option is always to have a realistic achievable project schedule where overruns would be unlikely.

Sometimes compressing or crashing the project schedule is just not viable or worth the effort and costs. You can’t add more resources to a pregnancy to deliver a baby in 5 months instead of 9 months.

If you want to make planning easier for yourself invest in project management templates from Method 123. It covers all the important issues and serves as a complete reference with tips and hints to guide you in line with worldwide standards.

Comments

I will really appreciate your comments about project schedule overruns in the space provided below.

Introductory Project Management course

If you want to grow in project management and achieve results like a pro enroll for my “Introductory course to project management” course. The course has been internationally presented for many years. You can now do it online. The learning platform is very user-friendly. I will take your hand all the way through the course. You can work on a real-life project and get feedback as you go along.

For more information go to https://www.peterjoubert.com/introduction-project-management/

Subscribe
Notify of
guest

 

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback

[…] How to handle project schedule overruns […]