Key Analysis of the Core Planning Process

At this point, we've described the core planning process, and we've noted the importance of understanding each process step and the corresponding outputs for the exam. Our experience has shown us that this learning process can be accelerated, if there is clarity on a few key definitions and on the differences among these process steps. These next subsections will review these key learning points.

Project Plan It's Not a Microsoft Project File

Because the end goal for the entire project planning activity is a project plan, let's review the standard PMI definition. A project plan is the document (or set of documents) that describes the complete project, including work, costs, resources, performance baselines, and project management processes. Recommended components of a project plan include the following:

• Assumptions and constraints

• Project charter

• Scope statement

• Work Breakdown Structure (WBS)

• Cost estimates and cost baseline

• Key resources and team members

• Major milestones and target dates

• Project schedule

• Project Management Approach

• Risk management plan

• Open issues and pending decisions

• Communications plan

• Cost management plan

• Scope management plan

• Schedule management plan

• Quality management plan

• Staffing management plan

• Risk response plan

• Procurement management plan

Many organizations use the term project charter to describe the PMI definition of a project plan. What's more, many organizations use the term project plan to refer to a work plan, schedule, or task list. All of these usages are incorrect.

Differences Among the Project Charter, Scope Statement, WBS, Activity List, Project Schedule, and Project Plan

Given the PMI definition of a project plan, and the assumption that this definition may not be consistent with your experiences, let's review the PMI definitions of all the key scope and work-related project planning outputs and the key differences between them. Table 4.2 describes these definitions and differences.

A Microsoft Project file (or anything else resembling a project schedule or WBS) is not a project plan.

Table 4.2. Summary of Scope and Work-Related Project Planning Outputs

Tool	Definition	Notes
Project charter	A project charter authorizes the project and PM role. It includes a high-level product description and project objectives.	Results from project initiation.
Scope statement	A scope statement lists the product and major subproducts of the project. It is also used as a basis for future scope decisions.	An MS Word document. Results from scope planning.
Work Breakdown Structure (WBS)	The WBS is a deliverable-oriented grouping of project components. The lowest level items of a WBS are known as work packages.	Usually presented in a hierarchical chart. Results from scope definition.
Activity list	An activity list details the steps required to complete each work package listed in the WBS.	Each activity normally lasts between 4 and 80 hours.
Project schedule	A project schedule applies the activity list, duration estimates, and activity relationships to a calendar with certain dates for completion.	Presented using a project-scheduling tool such as MS Project.
Project plan	A project plan is an all-encompassing document that is used as the basis for project controlling and executing.	Normally an MS Word document with references to other files/documents.

Differences Among the Project Initiation, Scope Planning, and Scope Definition

Another common source of confusion for project managers new to the PMBOK is understanding the differences between the three project scope management processes: project initiation, scope planning, and scope definition. Two of these happen to be part of the core project planning process. The main reason for the confusion is in the "real world" these activities are frequently performed in combination. Logically, the PMBOK processes make sense:

• First, authorize the project (initiation).

• Second, perform an assessment on the targeted product and project alternatives (scope planning).

• Third, decompose the approved work scope into work packages that can be assigned, estimated, and managed (scope definition).

For many project managers, their organizations' processes may combine some or all of these steps into one activity. Therefore, the PMBOK definition is not always "intuitive" at first.

Differences Between the Scope Definition and Activity Definition

Another common area of confusion for project managers studying the PMBOK and the core project planning process is the difference between the scope definition (PMBOK 5.3; subdividing the major project deliverables into smaller, more manageable components) and the activity definition (PMBOK 6.1; identifying the specific activities that must be performed to produce those deliverables). At first glance, these processes seem to be very similar, because both involve breaking down something large into smaller, more manageable components (decomposition) and both provide similar benefits.

The similar benefits of scope definition and activity definition are as follows:

• They improve accuracy of cost, duration, and resource estimates.

• They define a baseline for performance measurement and control.

• They facilitate clear responsibility assignments.

However, the "key difference" is the target of the decomposition. In scope definition, the scope statement is decomposed and captured in the WBS. The WBS may actually represent a "program" rather than just a single project. In activity definition, the WBS work packages are decomposed into a list of activities that can be used for project scheduling:

1. Identify major deliverables, including project management.

2. Decide if adequate costs and duration estimates can be made. If yes, proceed to step 4 (verifying correctness).

3. Break down each deliverable into subcomponents; repeat step 2.

4. Verify the correctness of the decomposition using the following questions:

   • Are lower-level items necessary and sufficient?

   • Are items clear and complete?

   • Can each item be scheduled, budgeted, and assigned to a responsible party?

When decomposing work packages into activities, you should ask additional questions to verify the correctness of the decomposition. These include the following:

• Can this activity be logically subdivided further?

• What does this activity "deliver?"

• Can this activity be performed within the "rule of thumb" duration used for project activities (less than 80 hours, 4 40 hours, 8 80 hours, and so on)?

Know the "80-hour rule." This heuristic (rule of thumb) recommends that each lowest-level task/activity on a project schedule (or WBS) should take no more than 80 hours to complete.

Now that we've reviewed the steps and the key terms involved in the core project planning process, let's move on to a few other key concepts related to core project planning that you'll need to know for the exam. The first key concept to discuss is the WBS.