Subscriber only lesson.

Sign up to the Project Management for Experts course to view this lesson.

View pricing

About this lesson

There are several approaches a project team can take to accelerate project tasks.  Each approach has its own unique characteristics and risks.

Exercise files

Download this lesson’s related exercise files.

Project Acceleration.docx
205.2 KB Project Acceleration - Solution.docx
204.6 KB

Quick reference

Project Acceleration

There are several approaches a project team can take to accelerate project tasks.  Each approach has its own unique characteristics and risks.

When to use

Project acceleration techniques are often applied at the time of project planning.  In this case, after an initial project plan is created; the total project time from start to finish exceeds the allowed time in the project goals.  The project manager and core team can apply the project acceleration techniques to create a project plan that is faster, but usually that means it also has more risk. 

Once a project plan is baselined, there are two conditions that can lead to the need to apply project acceleration techniques.  In one case, a delay occurs on a project task.  The project team attempts to overcome the impact of that delay by accelerating other tasks.  In the other case, due to business or industry conditions, the need for project completion is accelerated.  The project team must then accelerate the remaining tasks on the project.

Instructions

There are five techniques that can be used to accelerate tasks on a project.  Two of the five are acknowledged by the Project Management Institute, Inc.  There are two key points to keep in mind.  First, acceleration techniques must be applied to critical path tasks to impact the end date of the project.  It is only the critical path tasks that drive project end date.  Second, if you accelerate the critical path enough, it becomes faster than other paths and you have a new critical path. 

There are very few instances in a project when all of the techniques can be used, normally only two or three of the techniques are practical.  Select which technique or combination of techniques provides the lowest total risk and yet is practical from a project and organization perspective.

Float Acceleration

Float acceleration is the removal of float that has been inserted into tasks or paths for risk mitigation.  This often results in the creation of a “best case” schedule.  This approach increases the risk of missing a targeted date.  However, the accelerated completion date can be used as a target and will sometime motivate team members to speed through tasks.  For many tasks, there is no float embedded in the estimate, so the technique cannot be used on those.  When there is float and the technique is used, be certain to update the risk register with the increased risk of schedule delay.

Crashing

Crashing is the application of additional resources to selected tasks to complete them sooner – in essence throwing money at the problem.  Some tasks can be accelerated with extra resources.  If the project has available management reserve, or if the benefit of acceleration outweighs the cost, this is a very practical acceleration technique. Crashing is a recognized technique by the Project Management Institute, Inc.

Fast Tracking

Fast tracking is essentially a scope completion versus schedule trade-off.  With fast tracking, a task is started before the predecessor task is fully complete.  There is a “preliminary deliverable” from the predecessor task that can be used to start the next task.  This allows tasks that were sequential to now overlap.  This approach is not practical for all tasks, but is it practical when there is a “preliminary deliverable” and the resources working on the two tasks are different.  The danger with this technique is if the final task deliverable of the predecessor task deviates significantly from the “preliminary deliverable,” then some of the work from the successor task may need to be repeated with the input from the final deliverable.  Fast tracking is a recognized technique by the Project Management Institute, Inc.

Split Releases

Split releases are a scope versus schedule trade-off.  The project objectives are divided into multiple releases. One of those releases can be accelerated by diverting all the effort to completing that release.  Once the first release is completed, the resources are assigned to the next release.  While this accelerates the first release, it often leads to a delay in final project completion.  However, if the project has multiple separable goals, this can be an effective technique for accelerating the accomplishment of at least one of the goals.

Mainline – Offline Scheduling

The mainline – offline scheduling technique requires that tasks on the critical path be divided into two parts.  One part is that which can only be done when the unique results from a previous task are complete – the mainline subtask.  The other is a portion of the task that can be done “generically” ahead of time, the offline subtask.  For example a testing task could be separated into a test setup and calibration portion that is done ahead of time and the testing of the actual device or code as soon as the device is available.  By doing the offline portion ahead of time, the duration of the mainline portion is often shortened.  The difficulty with this is that the analysis must be done far enough in advance to have time to do the offline portion prior to the task starting.  Therefore this technique is more often used when accelerating a plan than when trying to accelerate a task while it is underway.

 

 

  • 00:03 Hi, this is Ray Sheen.
  • 00:05 Sometimes it becomes necessary to accelerate a project.
  • 00:07 When this happens, you need to do it in a way that maintains project control.
  • 00:11 There are five methods that I have used.
  • 00:13 Each will add an element of risk, but
  • 00:15 if that risk is manageable, you may gain significant acceleration and
  • 00:19 the completion of the project for very little increase in project risk.
  • 00:23 Let's look at each of the techniques.
  • 00:25 The first one is called float acceleration.
  • 00:28 It will shorten the project schedule, but
  • 00:30 it magnifies any little schedule problem on the project.
  • 00:33 This approach accelerates the project by taking a schedule that
  • 00:36 was risk mitigated and removing the float used for risk mitigation.
  • 00:40 Float may have been added following a high risk task to prepare for
  • 00:44 what may go wrong, or float may have been embedded in the schedule estimate if
  • 00:48 resource availability was uncertain.
  • 00:50 You must remove float from tasks on a critical path to impact the project
  • 00:54 finish date.
  • 00:55 Since the float was added to reduce risk,
  • 00:57 eliminating the float increases risk and the risk register should be updated.
  • 01:02 Let me illustrate.
  • 01:04 Here's a simple little project where we have to qualify a supplier,
  • 01:07 bring in some parts, build prototypes and
  • 01:09 run tests to be certain that the new parts will work as required.
  • 01:14 Since this was a new supplier, one week of float was inserted following the procure
  • 01:18 parts task in case the supplier was late.
  • 01:21 The project is projected to end on November 21st.
  • 01:25 Removing that float would accelerate the project end date to November 14th.
  • 01:29 However, now the parts must arrive on time to maintain the schedule.
  • 01:34 This is an easy approach, but it does increase schedule risk.
  • 01:38 The next approach is called crashing.
  • 01:40 This is a cost versus schedule tradeoff.
  • 01:42 The schedule's accelerated by placing extra resources on selected tasks on
  • 01:46 the critical path in order to complete them sooner.
  • 01:50 Some paths cannot be accelerated with extra resources, but some can.
  • 01:54 If the project has access to resources, this is a very viable approach.
  • 01:58 It usually leads to higher cost project in order to pay for
  • 02:02 the extra resources, often requiring overtime or premium work.
  • 02:06 Continuing with our new supplier project, the task,
  • 02:09 build prototypes, is scheduled to take two weeks.
  • 02:12 However, if we add a second shift for that task, we can get it done in just one week.
  • 02:17 Instead of finishing on November 14th, we finish on November 7th.
  • 02:21 However, we have added cost risk to the project.
  • 02:24 The third technique is called fast tracking.
  • 02:27 This is a schedule for scope risk tradeoff.
  • 02:30 The scope risk is that some of the tasks may need to be repeated.
  • 02:33 With this technique, you start a task on the critical path early even though you
  • 02:38 don't yet have everything needed to complete the task.
  • 02:41 Your network diagram had a dependency between two tasks and
  • 02:44 you'd modify the dependency.
  • 02:46 This can be done if the predecessor task has some preliminary information or
  • 02:50 deliverable that can be used to initiate the task.
  • 02:53 Of course, the risk is that if the final result from that predecessor task is
  • 02:57 significantly different from the preliminary deliverable,
  • 03:00 the work of the successor task may have to be restarted, adding more work.
  • 03:05 Not scope creep, but rather scope repeat.
  • 03:08 Let's look at our project and the dependency between qualified supplier and
  • 03:12 procure parts task.
  • 03:14 Our experience has shown us that we will know within the first few days if we'll
  • 03:17 not qualify a supplier.
  • 03:19 We need the full two weeks to do all the audit paperwork, but after the first week,
  • 03:24 we will know that that supplier will be approved or not.
  • 03:27 So, we will start the procurement after the first week even though
  • 03:30 the qualification is not a officially done.
  • 03:33 This will allow us to accelerate the end date from November 7th to October 31st.
  • 03:37 Of course, the danger is that a surprise is found at the end of the audit.
  • 03:41 We will need to go find a new supplier then and
  • 03:44 the parts that we just bought cannot be used.
  • 03:46 Our next method is known as split releases.
  • 03:50 This is also a scope versus schedule tradeoff.
  • 03:52 In this case, it is a prioritization of deliverables that results in
  • 03:56 a reduced scope for an early release.
  • 03:58 We look at the project deliverables and divide them into multiple releases.
  • 04:02 This can often be done if the project has multiple goals or objective.
  • 04:06 Effort is then focused on one set of deliverables to finish them earlier.
  • 04:10 Of course, since the full scope of the project has not been reduced,
  • 04:14 this can often lead to a delay in the final completion of the project, but
  • 04:17 at least some of it is done sooner.
  • 04:20 This can only be done if the deliverables are separable with separable priorities.
  • 04:25 Let's look at our project.
  • 04:26 We're building multiple prototypes for
  • 04:28 different uses that have different purposes.
  • 04:30 As soon as one prototype is tested,
  • 04:32 we can start to use some of the new parts in production.
  • 04:36 So we will focus the prototype build activity on just one prototype and
  • 04:39 test that one, then come back, build the second prototype and test it.
  • 04:43 This accelerates the initial completion from October 31st to October 29th.
  • 04:49 The downside is that it delays the overall project completion to November 5th.
  • 04:54 The final method is mainline-offline scheduling.
  • 04:58 The acceleration comes by removing generic offline portions of
  • 05:01 a task from the critical path tasks of the project and
  • 05:03 completing those generic portions ahead of when they are needed.
  • 05:07 To do this, determine what portion of the task do not require specific
  • 05:10 information from predecessor tasks.
  • 05:13 Separate those out and turn them into separate tasks.
  • 05:16 We then do the offline tasks early in the project in parallel with predecessor
  • 05:21 critical path tasks, which results in acceleration of the critical path.
  • 05:25 Looking at our project once more, we recognize that
  • 05:28 the testing task includes both test setup and the conduct of the test.
  • 05:32 We can split out the test setup and have that ready to go for the testing tasks.
  • 05:37 We have to add the test setup tasks, but this now reduces the test activity by
  • 05:41 another two days and completes the first phase of the project on October 27th.
  • 05:47 A caution with this technique.
  • 05:48 We need to decide to do this early enough so
  • 05:51 that there is time to do the offline task.
  • 05:53 This means that we need to plan ahead for
  • 05:55 this one, not react when there is a crisis.
  • 05:59 Which technique you use or combination will depend upon your project conditions.

Lesson notes are only available for subscribers.

PMI, PMP and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course