Project Acceleration

Quick reference

• 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.