Project Acceleration

Quick reference

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

Lesson notes are only available for subscribers.