Baseline Plan

Quick reference

• 00:04 Hi, I'm Ray Sheen.
• 00:05 I'd like to talk about another aspect of project planning and project control,
• 00:10 and that's called the baseline plan.
• 00:12 The Project Management Body of Knowledge, the PMBOK Guide, defines a baseline
• 00:17 as the approved version of a work product that can be changed only through formal
• 00:23 change control procedures and is used as a basis for comparison to actual results.
• 00:28 The baseline is the final result of the project planning process.
• 00:31 It is a baseline for
• 00:32 everything that the project team will do and be measured against.
• 00:36 It's sometimes referred to as a performance measurement baseline.
• 00:40 It often expressed with three components that represent the project management
• 00:45 triple constraint.
• 00:46 There's a scope baseline that is the plan for all of the tasks and
• 00:50 activities that identifies the deliverables.
• 00:53 A schedule baseline that shows the start and stop of the activities and
• 00:57 any other project milestones.
• 00:59 And a cost baseline that indicates how much money each of these activities
• 01:03 should cost and when that spending will occur.
• 01:05 The combination of these is the performance measurement baseline that is
• 01:09 put under configuration management control and
• 01:12 cannot be changed without a formal project change being processed.
• 01:16 A project baseline is an integration function of project management.
• 01:20 For very small, one or two person projects,
• 01:23 a formal baseline may not be needed.
• 01:25 But in large projects with many project team members and stakeholders,
• 01:29 the baseline is the integration of the project planning components.
• 01:33 The inputs used to create the project baseline will come from several sources.
• 01:38 The primary source is the project's core team.
• 01:41 Each member will plan the activities for their portion of the project.
• 01:44 The baseline brings these together.
• 01:47 I often have used templates and
• 01:48 checklists to guide the integration of the project planning inputs into a baseline.
• 01:53 I also will use the project charter to be certain the core team didn't overlook
• 01:58 a deliverable and that the resulting integrated project baseline is within
• 02:02 the boundaries and constraints of the charter.
• 02:05 The integration activities of creating a baseline is often a synchronization
• 02:09 activity.
• 02:10 Each element of the projects makes sense by itself,
• 02:13 but it must be blended with the other elements.
• 02:16 For instance, there are linkages between tasks.
• 02:19 One task cannot start until another is completed.
• 02:23 Several tasks must be finished to complete a deliverable.
• 02:27 On an agile project, the backlog of deliverables,
• 02:31 requirements, and stories of the users must be prioritized.
• 02:36 Also, there are often milestones that must be aligned.
• 02:40 Each of the core team members are completing tasks and
• 02:43 preparing deliverables for a project milestone.
• 02:46 The timing of the milestone needs to be synchronized.
• 02:50 A major element of the synchronization is resource usage.
• 02:54 Multiple tasks may require support from the same shared resource pool.
• 02:59 The overlap and timing of these tasks can overload the resource pool and
• 03:04 lead to shortages.
• 03:05 The timing of the use of shared resources is resolved as part of
• 03:10 creating a baseline plan.
• 03:12 Ultimately, the creation of a baseline plan is a risk management activity.
• 03:17 Inevitably, there will be tasks that are not properly linked, not prioritized,
• 03:22 milestones not in alignment, resources that are overallocated.
• 03:26 These are project management risks.
• 03:29 They may not lead to a failure of the project to complete the work, but
• 03:33 they may lead to a failure to complete it on time or within budget.
• 03:37 These risks become evident when integrating the baseline and
• 03:41 can be proactively resolved during planning,
• 03:44 rather than causing an issue during project execution.
• 03:48 So let's discuss how we use a baseline plan.
• 03:51 One way is to communicate the intent of what we will do in the project.
• 03:54 We can communicate with both stakeholders and
• 03:57 team members the expectations for project performance.
• 04:01 In addition, the baseline provides strong guidance to the team.
• 04:05 The baseline is what is expected and what will be measured.
• 04:08 The core team is counting on each person to accomplish their part of the baseline.
• 04:12 Changes can be made but not easily because it begins to affect everyone and
• 04:17 everything else.
• 04:18 The baseline should provide for
• 04:20 some flexibility to manage the day-to-day give-and-take of project work.
• 04:24 I do not put microtask level data in the baseline.
• 04:28 Remember, to change the baseline requires the processing of a formal change request.
• 04:33 I don't want to deal with change requests and
• 04:35 change boards just because someone needs to move a microtask a day or two.
• 04:39 So I leave some level of flexibility for the core team to manage.
• 04:43 This is a judgment call.
• 04:45 Too much flexibility and the project gets out of sync.
• 04:47 But not enough flexibility and project team members start doing stupid things to
• 04:52 meet the baseline details, which leads to reduction in project performance.
• 04:57 An interesting aspect of baseline management that I've observed is that
• 05:01 the more detail you have in a baseline plan, the fewer reviews that are required.
• 05:06 Everyone knows exactly what to do, and they stay in lockstep following the plan.
• 05:11 The project is rigid, but since the expectations are very clear,
• 05:15 integration meetings are only needed for real problems.
• 05:19 When the plan is looser and has more flexibility,
• 05:22 for instance, a typical agile project, more reviews are required.
• 05:26 Inevitably, elements of the project will get out of sync when there
• 05:30 is little detail in the plan.
• 05:31 Therefore, you need frequent reviews to find and fix those issues when they
• 05:35 are small, rather than letting them grow into major problems and risks.
• 05:39 This is what happens in the sprint demo and
• 05:42 refinement process of an agile project.
• 05:45 So you can do a very detailed plan and only a few reviews but little flexibility,
• 05:50 or quickly create a high level plan but then conduct frequent reviews along
• 05:55 the way to integrate project activities and deliverables.
• 05:59 At its core, the project baseline is a risk management tool.
• 06:03 It integrates and synchronizes the project planning elements.
• 06:07 It sets expectations and
• 06:09 is the performance measurement baseline used to check project progress.

Lesson notes are only available for subscribers.