Retired course
This course has been retired and is no longer supported.
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.docx61.4 KB Project Acceleration - Solution.docx
60.5 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 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.
Login to download- 00:05 Hi, I'm Ray Sheen.
- 00:06 Sometimes it becomes necessary to accelerate a project.
- 00:10 When this happens, you need to do it in a way that maintains project control.
- 00:14 There are five methods that I've used, each will add an element of risk.
- 00:18 You'll need to decide if the risk is worth the reward of acceleration.
- 00:23 Let's look at each of these techniques.
- 00:25 The first one is called float acceleration.
- 00:29 It will shorten the project's schedule, but
- 00:31 it magnifies any little schedule problem on the project.
- 00:34 This approach accelerates the project by taking a schedule that was risk mitigated,
- 00:39 and removing the float used for risk mitigation.
- 00:42 Float may have been added following a high-risk task to be prepared for
- 00:45 anything that may go wrong.
- 00:47 Or float may have been embedded in a schedule estimate
- 00:50 if resource availability was uncertain.
- 00:52 You must remove float from task on the critical path to impact
- 00:55 the project finish date.
- 00:57 The critical path is the longest path in the project, and
- 00:59 therefore the only one that affects the end date.
- 01:02 Since the float was added to reduce risk, eliminating the float increases risk, and
- 01:06 the risk register should be updated.
- 01:08 Let me illustrate.
- 01:10 Here's a simple little project where we have to quantify a supplier,
- 01:13 bring in some parts, build prototypes, and
- 01:15 run tests to be certain that the new parts will work as expected.
- 01:19 Since this was a new supplier, one week of float was inserted
- 01:22 following that procure parts task in case the supplier was late.
- 01:26 The project is expected to end on November 21st.
- 01:29 Removing that float will accelerate the project end date to November 14th.
- 01:34 However, now the parts must arrive on time to maintain the schedule.
- 01:38 Schedule delivery should now be placed on the risk register.
- 01:41 This is an easy approach, but it does increase schedule risk.
- 01:45 The next approach is called crashing.
- 01:47 This is a cost versus schedule tradeoff.
- 01:50 The schedule is accelerated by placing extra resources on scheduled task
- 01:53 on the critical path In order to complete them sooner.
- 01:57 Some tasks cannot be accelerated with extra resources, but some can.
- 02:01 If the project has access to resources, this is a very viable approach.
- 02:05 It usually leads to higher cost project in order to pay for
- 02:08 the extra resources often requiring over time where premium work.
- 02:13 Continuing with our new supplier project,
- 02:15 the task build prototype is scheduled to take two weeks.
- 02:19 However, if we add a second ship for that task, we can get it done in just one week.
- 02:23 Instead of finishing on November 14th, we can finish on November 7th.
- 02:27 However, we have added cost risk to the project.
- 02:30 The third technique is called fast tracking.
- 02:33 This is a schedule versus scope risk tradeoff.
- 02:36 The scope risk is the risk that some of the tasks may need to be repeated.
- 02:40 With this technique, you start a task on the critical path early,
- 02:44 even though you don't have everything that's needed to complete the task.
- 02:48 Your network diagram had a dependency between two tasks and
- 02:51 you modify that dependency.
- 02:53 This can be done if the predecessor task has some preliminary information or
- 02:56 deliverable that can be used to initiate the successor task.
- 02:59 Of course the risk is, that the final result from the predecessor task is
- 03:03 significantly different from the preliminary deliverable,
- 03:06 the work of the successor task may need to be restarted.
- 03:10 Adding more more work not scope creep, but rather scope repeat.
- 03:14 Let's look at our project and
- 03:15 the dependency between the qualified supplier and procure parts tasks.
- 03:20 Our experience has shown that we will know within the first few days if we will not
- 03:23 qualify a supplier.
- 03:25 We need the full two weeks to complete the audit paper work, but
- 03:28 after the first week, we'll know if the supplier will be approved or not.
- 03:32 So we'll start the procurement after the first week,
- 03:35 even though the qualification is not officially done.
- 03:38 This will allow us to accelerate the end date from November 7th to October 31st.
- 03:43 Of course, the danger is that if a surprise is found at the end of the audit,
- 03:46 we'll need to go find a new supplier and the parts we just bought can't be used.
- 03:51 The concern with this approach is the possibility of repeating tasks
- 03:54 if the preliminary deliverable is wrong.
- 03:57 Our next method is called split release.
- 04:00 This is also a scope versus schedule tradeoff.
- 04:03 In this case, it's a prioritization of deliverables
- 04:06 that result in a reduced scope for an early release.
- 04:10 We look at the project deliverables and divide them into multiple releases.
- 04:14 This can often be done if the project has multiple goals or objectives.
- 04:18 Effort is on focused on one set of deliverables to finish that earlier.
- 04:22 Of course, since the full scope of the project has now been reduced,
- 04:26 this can often lead to a delay in the final completion of the project, but
- 04:30 at least some of it is done sooner.
- 04:32 But this can only be done if the deliverables are separable
- 04:35 with separable priorities.
- 04:37 Let's look at our project again.
- 04:39 We're building multiple prototypes for
- 04:40 different uses that have different purposes.
- 04:43 As soon as one prototype is tested,
- 04:45 we can start to use some of the parts in that productions.
- 04:48 So we'll focus the prototype build activity on just one prototype and
- 04:52 test that one, and then come back and build a second prototype and test it.
- 04:55 This accelerates the initial completion from October 31st to October 29th.
- 05:00 The downside is that it delays the overall project completion to November 5th.
- 05:05 This will only work if the activity in question supports
- 05:08 multiple deliverables that have unique priorities.
- 05:11 So although this accelerated the first release for the project,
- 05:14 it will normally delay final project completion.
- 05:18 The final method is mainline-offline scheduling.
- 05:21 Acceleration comes by removing generic offline portions of a task from
- 05:25 the critical path task of that project, and
- 05:27 completing those ahead of when they're needed.
- 05:29 To do this, determine what portions of the task do not require specific information
- 05:33 from a predecessor task, separate those out and
- 05:36 turn those into a separate subtask.
- 05:39 We then do the offline subtask early in parallel with the predecessor
- 05:43 critical path task, which results in the acceleration of the critical path.
- 05:49 Looking at our project once more, we recognize that the testing task includes
- 05:53 both test setup and the conduct of the test.
- 05:57 We can split out the test setup and
- 05:59 have that ready to go before the testing portion of the task starts.
- 06:03 We have to add the test setup task, but this now reduces the test activity by
- 06:07 another 2 days, and completes the first phase of the project by October 27th.
- 06:12 The caution with this technique, we need to decide to do this early enough so
- 06:16 that there's time to do the offline task.
- 06:19 This means that we need to plan ahead for this one and
- 06:22 not react when there is a crisis.
- 06:24 Which technique you use or combination will depend on your project conditions.
Lesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.