Developing the Project Plan

---

The project plan is not a museum piece. You'll use, wrinkle, update, and depend on your project plan like a playbook for a Super Bowl coach. The project plan is developed with the project team, stakeholders, and management. It is the guide to how the project should flow and how the project will be managed, and it reflects the values, priorities, and conditions influencing the project.

Project plan development requires an iterative process of progressive elaboration. The project manager will revise and update the plan as research and planning reveal more information and as the project develops. For example, an initial project plan may describe a broad overview of what the project entails, what the desired future state should be, and the general methods used to achieve the goals of the plan. Then, after research, careful planning, and discovery, the project plan will develop into a concise document that details the work involved in and expectations of the project; how the project will be controlled, measured, and managed; and how the project should move. In addition, the project plan will contain all of the supporting detail, specify the project organization, and allow for growth in the plan.

Exam Watch

The project plan guides the project manager through the Execution and Control process groups. The project plan is designed to control the project. As a whole, the point of the project plan is to communicate to the project team, stakeholders, and management how the project will be managed and controlled.

Understanding the Project Plan's Purpose

The project plan is more than a playbook to determine what work needs to be accomplished. The project plan is a fluid document that will control several elements:

• Provide structure The project plan is developed to provide a structure to get the project to completion. It is a thorough, but concise, collection of documents that will serve as a point of reference through the project execution.

• Provide documentation 'Noggin Plans'-the kind between your ears-are not good. A documented project plan is needed for truly successful projects-they provide a historical reference and the reasoning for why decisions were made. A project plan must provide documentation of the assumptions and constraints influencing the project plan development.

• Provide communication Project plans are documents that provide the information, explanations, and reasoning underlying the decisions made for the project. The project plan serves as a source of communication among stakeholders, the project team, and management on how the project plan will be controlled.

• Provide baselines A project plan contains several baselines. As the project moves toward completion, management, stakeholders, and the project manager can use the project plan to see what was predicted for costs, scheduling, quality, and scope-and then see how these predictions compare with what is being experienced.

Inputs to Project Plan Development

To effectively develop the project plan, the project manager and the stakeholders must be in agreement with the project objectives. For this agreement to exist, the project manager works with the stakeholders to negotiate a balance of expectations and required objectives. Competing objectives is a recurring theme in project management (and on the PMP exam). Project managers must be able to negotiate among stakeholders for the best solution to the problem or opportunity.

Planning Outputs Serve as Inputs

The outputs of the planning processes serve as an input to project plan development. As a refresher, the processes from the planning process group are shown in Table 4-1.

Table 4-1: An Overview of the Planning Processes

Planning Process	Purpose
Scope Planning	To create a document that will guide project decisions.
Scope Definition	To breakdown the project deliverables into manageable elements. The sum of the smaller elements equate to the project scope.
Activity Definition	To define the required activities, and only the required activities, to complete the project scope.
Resource Planning	To ascertain the resources required to achieve the defined activities for completing the project work. Resources include people, equipment, and materials.
Activity Sequencing	To determine the best sequence of planned activities within the project work.
Activity Duration Estimating	To determine the estimated required work units to successfully complete the defined activities.
Cost Estimating	To determine an estimated amount of monies to complete the project work using the defined facilities, services, and goods.
Risk Management Planning	To determine the risks within the project and how to react to the identified risks.
Schedule Development	To determine the project schedule based on the sequence of activities, the required resources, and the required monies. The Schedule Development process reveals an estimated reflection of when all of the required work can be completed with the given resources.
Cost Budgeting	To determine the estimated cost of the activities to complete the project work.
Project Plan Development	To create a coherent compilation of the other planning processes to guide the project execution.
Quality Planning	To determine the Quality Assurance standards used by the organization. The Quality Assurance standards that are relevant to the project must be planned into the project.
Communications Planning	To determine who needs what, when they need it, and in what modality (paper or electronic, for example) they need it.
Organizational Planning	To determine the project roles and responsibility. This also determines the reporting structure between the project manager, the project team, and management.
Staff Acquisition	To acquire the needed people to complete the determined project work.
Risk Identification	To identify the risks, rewards, and penalties associated with the project.
Qualitative Risk Analysis	To prioritize the impact of the risks on the project (typically in a high, medium, and low ranking).
Quantitative Risk Analysis	To measure and consider the probability and associated impact of the risks on the project.
Risk Response Planning	To avoid, eliminate, reduce, or create a planned reaction to the identified risks within the project.
Procurement Planning	To determine what goods and services must be procured and when they will need to be procured in the project lifecycle.
Solicitation Planning	To determine the possible vendors to provide the goods and services for the project.

Historical Information

Historical information is used as an input to project plan development-and to the planning process group-and is always as excellent source of information to confirm, or deny, assumptions. Historical information can also serve as a point of reference for identifying alternatives during the planning processes. Historical information can come from:

• Previous projects

• Commercially available estimating databases

• Public records

• Organizational archives of past projects

• Performance records of other projects

• Other reliable sources

Exam Watch

Historical information is always a key source for project information-even more important than project team members' opinions. Why? Historical information is proven and documented and from reliable sources. If you must choose, choose historical information as a key input.

Organizational Policies

Consider the performing organization-the company hosting the project. The performing organization may have rules and regulations that the project must follow. During the project plan development consider the following:

• Quality Assurance programs and their influence over the project. The project manager must consider the standard operating procedures (SOPs) the project manager is expected to follow, the expected level of quality, and the target indexes the project manager may be expected to achieve. The QA requirements must be documented in the Quality Management Plan, and its activities must be accounted for in the project schedule.

• Human resource practices and the project manager requirements. An organization may have specific rules on how the project manager may recruit team members, release team members from the project, account for a team member's time, discipline team members, and so on. The project manager and project team must be familiar with the organization's HR practices, and the practices should be documented in the Human Resource Management Plan.

• Financial controls and requirements. An organization will have requirements for the project manager to account for the budget, expenses, and cash flow projections. The project manager will likely have to forecast expenses, account for project time, and have adequate bookkeeping for any project procurement. Throughout the Execution and Control processes (and also in the Closing process), the project manager can expect financial reviews and requests for projections. EVM can assist the project manager by providing time and cost variances, estimates to complete the project work, and information on the likelihood of the project completing on time and on schedule.

Project Constraints

Constraints are any restriction on the project. Constraints may be the availability of project resources, government requirements, budgetary limits, and so on. All projects have at least three constraints (as shown in the following illustration): scope, budget, and schedule. This is also known as the 'triple constraint' of project management. A constraint is any force that may affect when, and if, a project activity can be completed. Consider a project with a deadline-that's a time constraint. Consider a project with a preset budget (I know, that one is tough to imagine)-that's a budget constraint, and it affects staffing, quality, scope, schedule, and more.

And what about a scope constraint? That's a project that has demands for the given requirements regardless of the time or cost to reach the demands. Consider a project to enforce a government regulation within a manufacturing industry. The government regulation must be met, regardless of the cost to enforce it. While projects with scope constraints are not as common as projects with financial and schedule constraints they do exist. Consider smaller projects such as the'Add/Move/Change Projects'. Scope constraints are imposed by projects to implement safety standards, for example, and projects to document business processes within an organization.

On the Job 

The triple constraints of project management provide an excellent negotiation tool. No side of the equilateral triangle can change without affecting the other sides. The goal is for all of the sides of the triangle to always be even. Want to change to project end date to sooner than later? Okay, but we'll have to add more resources to get it done-which will mean more budget. Don't have enough cash in the old budget to complete the work? Okay, we'll just reduce the project scope. The triangle is sometimes called the 'Iron Triangle'.

Project Assumptions

Ever made an assumption? Assumptions are beliefs that are considered to be true, real, or certain for the sake of planning. For example, a project team can make the assumption that the weather will cooperate so that the construction project will finish by a given date. Assumptions should be documented, researched, and proven true-or untrue-as part of the planning process. This is part of progressive elaboration-the farther along the project moves to launch, the more detail the project needs.

Exam Watch

Assumptions should be documented whenever they are used: estimates, planning, scheduling, and so on. Assumptions are considered as risks because false assumptions can alter the entire project.

Applying Tools and Techniques for Project Plan Development

All of the inputs to the project plan should be readily available for the project manager, because he or she may need to rely on this information for additional planning. With all of the 'stuff' the project manager has to work with, it should be a snap to create the actual project plan, right? Well, not exactly. The project manager, the project team, stakeholders, and management will work together to finalize the project plan. The contributions from each include the following:

• Project manager leadership, facilitation, organization, direction, and expert judgment

• Project team members knowledge of the project work, time estimates, and they provide influence on the schedule, advice and opinions on risk, and expert judgment

• Customer requirements, objectives, quality requirements, expert judgment, influence over budget and schedule

• Management influence over budget, resources, project management methodology, quality requirements, and project plan approval

Adopting a Project Plan Methodology

A project plan methodology is a structured approach to developing the project plan. Methodologies can be simple or complex and based on the project type, the requirements of the performing organization, or multiple inputs. Organizations can use hard or soft tools to lead the project plan methodology. In its choice of hard tools, one organization may require the project team to create a project plan based on checklist of plan requirements, while another organization may require project teams to complete a computer-based project template.

Soft tools include project meetings, business analysts to investigate and research all facets of the problem or opportunity, and subject matter experts' interviews of stakeholders and project team members. A methodology to creating the project plan can include:

• Project templates

• Paper and electronic forms

• Monte Carlo simulations for risk management

• Project simulations for expected results

• Design of experiments

• Project startup meetings

• Interviews

Rely on the Stakeholder Skills and Knowledge

Stakeholders are individuals who are involved in the project creation, execution, or control; stakeholders are also the people affected by the project results. The project manager and the project team must consider the effects of the project on the stakeholders, and they must also interview and involve stakeholders so that they can make use of their knowledge of the project work and deliverables. The project manager must encourage participation and contribution from all stakeholders, as stakeholders provide valuable information for the project plan.

Stakeholders can include:

• Sponsor

• Client

• End user

• Team members

• Functional manager

• Vendors, the general public, subcontractors (and other 'external' stakeholders)

Employ a Project Management Information Systems (PMIS)

A PMIS is typically a computer-driven system (though it can be paper-based) to aid a project manager in the development of the project. A PMIS is a tool for, not a replacement of, the project manager. A PMIS can calculate schedules, costs, expectations, and likely results. The PMIS cannot, however, replace the expert judgment of the project manager and the project team.

Exam Watch

Don't worry too much about PMIS brand names like Microsoft Project and Primavera. The exam doesn't fall in love with any PMIS systems-they are just tools for the project manager to work with.

Count on Earned Value Management (EVM)

Earned value management (EVM) is a set of formulas that can measure a project's performance. EVM integrates scope, schedule, and cost to give an objective, scalable point in time assessment of the project. EVM calculates the performance of the project and compares current performance against where it should be. EVM can also be a harbinger of things to come. Poor results early in the project can predict the likelihood of the project's success. We'll cover EVM in Chapter 7.

Getting to Work: Project Plan Development

All the planning is done, right? Of course not. The planning processes are iterative and allow the project manager and the project team to revisit them as needed. But at what point do we push back from the planning buffet and move on with a working, feasible plan? Every project is different when it comes to planning, but a project team will continue in the planning stage until it is knowledgeable about the project work and has a clear vision of what needs to be done.

Figure 4-2 depicts the evolution of the Planning to Action process for a typical technology project. Once the business and the functional requirements have been established, the planning processes move into the specifics. Recall that the business requirements establish the project vision and that the functional requirements establish the goals for the project. The technical requirements and the design plan shift the focus onto the specifics the project will accomplish. Armed with this information, the project team and the project manager create the Work Breakdown Structure (WBS). The WBS is a decomposition of all the deliverables the project will create.

Figure 4-2: The Planning Processes require documentation and a logical, systematic approach.

With the WBS, the project planning continues into schedule development, roles and responsibilities, and task assignments. The project manager must work within the confines of the organizational structure (functional, matrix, or projectized) to assign the project team members to the work. The project manager must consider project priority, availability of resources, and dependency of activities. The project manager must also factor in the demands of management, customers, and stakeholders for events like formal communications, quality assurance program requirements, and project status meetings. As the project plan moves toward reality, the project manager and the project team must evaluate risk, cost concerns, business cycles, procurement, and often a looming deadline.

Evaluating the Outputs of Project Plan Development

The project manager and the project team have finished, for now, a project plan. Before the project team can set about implementing it, the plan must be approved. Let's hear that again: the project plan is a formal, documented plan that must be approved by management. Once management has signed off on the project plan, the work is truly authorized to begin.

Examining the Typical Project Plan

So what's in this project plan, anyway? Let's take a peek:

Project Charter

When you think of the Project Charter, think of a formal document that authorizes the project manager to manage the project. The Project Charter comes from a manager external to the project. This manager must have the power within the organization to grant the project manager the expected level of authority within the organizational structure to apply resources (people, facilities, monies) to the project.

Project Management Approach

So how will the project be managed? The project management methodology is a summary of all the individual plans that comprise the project plan. The project management approach describes how the work will be monitored, measured, and controlled. The project management approach summarizes the methods for QA, EVM, and risk response. Also included is an insight to the project accounting practices, cash flow projections, and expected outcome of the project. In other words, it describes how the project should advance, what the organization is achieving through the project, and how the project will react should things not go according to plan.

Exam Watch

Know this: the Project Charter does not come from the project sponsor; it comes from a manager outside of the project. It may work differently where you serve as a project manager-but on your exam, the charter is from Senior Management. In addition, the Project Charter doesn't launch the project-it authorizes the project manager.

Project Scope Statement

This document establishes the purpose for doing the project and provides a high-level product description. The product description may list elements that are included in or excluded from the project. Its intent is to serve as a reference for future project decisions on what will-and will not-be accomplished within the project. The Scope Statement provides reasons for and justification of the project deliverables. In addition, the Scope Statement should provide detailed information on what the project objectives are, how they will be measured, and the expected level of quality.

Work Breakdown Structure

The WBS is a decomposition of the project work. The WBS should be thorough, organized, and small enough that progress can be measured but not so granular that it becomes a hindrance to implement the work. Tasks should be fully defined, measurable, and not open-ended. A heuristic for WBS work packages is that activities should fit into the '8/80 Rule.' The 8/80 Rule demands that all activities be no smaller than 8 hours and no longer than 80 hours.

Plan Details

Within the project plan, you'll need a system to tie the activities to project team members, vendors, and stakeholders. You'll need to account for time, schedules, and cost. Specifically, you'll need cross-referencing to the WBS activities for the following:

• Cost estimates (and assumptions)

• Schedule estimates (and assumptions)

• Project start and finish dates (all projects have an end)

• Responsibility Assignment Matrix (who does what activities)

Exam Watch

All project managers should know what the WBS is-a tool for listing, organizing, and decomposing the project work. You should know the WBS is an input to many of the Planning, Execution, and Control processes. If you're stumped on a question and one of the answers is WBS, hedge your bets and choose WBS. The WBS is the scope baseline.

Project Schedule

The WBS and the network diagram coupled with the project resources will predict how long the project work should take. Your schedule should provide target dates, estimate the required resources to meet the targeted dates, and predict the project completion date. The schedule should, at a minimum, include target dates for phases and milestones.

Project Baselines

Baselines serve as evidence of what you've planned for. They allow you to compare what has been experienced in the project against what has been planned for in the project plan, with the differences being the variances. You'll need baselines for each of the following:

• WBS-Project scope: Did you deliver what you promised?

• Budget-Cost baseline: Did the project work cost what you estimated?

• Schedule-Schedule baseline: Is the project on the schedule you created?

Staffing Requirements

Who will do the work? The project plan should list the skills required to complete the project work and should indicate when those skills are required. The project plan should also identify the required personnel's time and associated cost. Required personnel may include vendors, subject matter experts, and employees within the company who are not considered project team members. Staff acquisition is an executing process.

On the Job 

Although the staffing requirements refer to personnel issues, don't forget to take into consideration the facilities, their schedules, and associated costs.

Risk Management Plan

The Risk Management Plan will detail the identified risks within the project, the risks associated with the constraints and project assumptions, and how the project team will monitor, react, or avoid the risks. The Risk Management Plan, and the processes to create it, will be detailed in Chapter 11.

Open Issues

Hmm…doesn't it always seem that there are open issues, pending decisions, and 'we'll-see's' on projects? The project plan needs its own special section for pending decisions and open issues. This section of the plan documents issues that have not been resolved but are not preventing the project from starting. These issues should, however, be tied to a target date for a decision, so they do not grow into a halting point for project progress.

Subsidiary Management Plans

Depending on the size of the project, the conditions the project must operate within, and the demands of management and stakeholders, additional plans may be required. These are the subsidiary plans. It is worthwhile to note that each subsequent knowledge area has a subsidiary management plan, as seen in Table 4-2.

Exam Watch

Open issues are acceptable, as long as they are not related to major issues that will prevent the project from moving forward. For example, conflicting objectives and requirements between stakeholders can't be an open issue. A resolution and agreement on project requirements has to be in place before the project work can begin.

Table 4-2: Subsidiary plans support and organize the project work.

Plan	Content
Scope Management Plan	How the project scope will be managedHow scope changes will be integratedAssessment of scope stabilityIdentification and classification of scope changes
Schedule Management Plan	How changes to the schedule will be managed
Cost Management Plan	How cost variances will be managed
Quality Management Plan	How the quality policy will be implementedQuality controlQuality assuranceQuality improvement
Staffing Management Plan	How resources are brought on and released from the teamResource histograms
Communications Management Plan	Information collection and filing structureInformation distribution structureDescription of information to be distributedProduction scheduleMethods to access information between updatesMethods to update the plan
Risk Response Plan	Risk management methodologyRisk roles and responsibilitiesRisk management budgetRisk management timingRisk scoring and interpretationRisk thresholdsRisk reporting formatsRisk tracking
Procurement Management Plan	Types of contracts that will be usedEvaluation criteriaProcurement roles and responsibilitiesProcurement documentsHow to manage multiple vendorsProcurement coordination with project

Scope Management Plan

The Scope Management Plan will detail how the project scope will be maintained and protected from change as well as how a change in scope may be allowed. The plan also provides information on how likely the project scope will change-and if changes do occur, how drastic the changes may be.

For example, a project to install additional electrical receptacles into an office building may have a very tightly controlled project scope that won't change often or much. Another project, to create a ten-acre park in a community, may change based on phase completion, discoveries in the land, natural resources, or conditions of the soil. The likelihood of change is directly related to the demands in the project scope. We'll discuss scope management and change control in Chapter 5.

Schedule Management Plan

The project plan details the scheduled work, milestones, and target completion dates for the project phases and the project itself. The Schedule Management Plan, on the other hand, identifies circumstances that may change the project schedule, such as the completion of project phases or the reliance on other projects and outside resources. The Schedule Management Plan identifies the likelihood that the schedule will change-and the impact of such changes should they occur. Finally, the Schedule Management Plan details the approval and accountability process for changes within the project. We'll discuss schedule management in Chapter 6.

Cost Management Plan

The project plan will include the project budget, cash flow forecast, and procedures for procurement and contract administration. The subsidiary Cost Management Plan explains how variances to the costs of the project will be managed. The plan may be based on a range of acceptable variances and the expected response to variances over a given threshold. For example, the project budget may have a range of variance of -10% to +15%. The following illustration demonstrates a variance range in the project budget.

As an example, a cost variance of $5,000 may prompt a financial audit, whereas a cost variance of $500 may be within the accepted range of variance. The accepted range of cost variance can stem from cost estimates, assumptions, and risk. We'll cover cost management in Chapter 7.

Quality Management Plan

The Quality Management Plan describes how the project will operate and meet its quality expectations. The Quality Management Plan details the quality improvement, quality controls, and how the project will map to the Quality Assurance program of the performing organization. The Quality Management Plan will provide information on the required resources and time to meet the quality expectations. We'll discuss quality management in Chapter 8.

Staffing Management Plan

The project plan will include information on the required resources needed to complete the project work. The Staffing Management Plan, however, provides details on how the project team members will be brought onto the project and released from the project. For example, a project may have a need for an electrical engineer for three months out of ten-month project. The Staffing Management Plan will determine how the engineer's time is accounted for on the project and how the employees can be released when they are no longer needed on the project. We'll discuss staffing management in Chapter 9.

Communications Management Plan

It has been said that project managers spend 90 percent of their time communicating. When you consider all of the different requirements and communications of a project, it is easy to believe that statistic. The Communications Management Plan describes the required communications and how they will be fulfilled. The Communications Management Plan explains the methods used for gathering, storing, and dispersing information to appropriate parties.

In addition, the Communications Management Plan maps out the schedule of when the expected communication needs will be met. For example, milestone reports, timely status reports, project meetings, and other expected communication events are included in the Communications Management Plan. The communication schedule will also include accepted procedures to update, access, and revise communications between scheduled communication events. We'll discuss communications in Chapter 10.

Risk Response Plan

This subsidiary plan, Risk Response, explains the actions the project team and the project manager may take on the basis of the identified risks coming to fruition. In some organizations, the Risk Response Plan is called the Risk Register. The plan includes specific information about the identified risks, their impact on the project, and what may cause the risks to come into play.

Exam Watch

In an ISO 9000 environment, the Quality Management Plan is called the project quality system. Also, an easy way to differentiate between QA and QC, is to remember that QA is organization-wide, and QC is project-wide. The clue is that there is an 'A' in 'organization', but not in project, and that there's a 'C' in 'project' but not in organization.

As part of the Risk Response Plan, the risk owners are identified along with what actions the owners may take should their risk events happen. Initial responses can include avoidance, transference, mitigation, or risk acceptance. We'll cover risk management in detail in Chapter 11.

Procurement Management Plan

If the project includes vendors, the project plan needs a Procurement Management Plan. This plan describes the procurement process from solicitation to source selection. The plan may also include the requirements for selection as set by the organization. The selected offers, proposals, and bids from vendor(s) should be incorporated into the Procurement Management Plan. We'll discuss procurement processes in Chapter 12.

Examining a Project's Supporting Detail

All of the decisions within the project are based on some reference, historical information, or expert judgment. The supporting detail provides the factual reasons for the decisions made in the project plan.

Outputs from Planning

Not every output of the planning process may be included in the project plan. For example, the planning process may have relied on industry whitepapers, vendor brochures, and magazine articles to guide the project planners to the decisions they've made. While all of this information is beneficial, it is not needed directly in the project plan. This research is an output of the planning processes, and may be needed for future reference, but it doesn't need to clutter up the working project plan.

Additional Project Information

The project manager will progressively elaborate the project plan until it is finalized and approved. Through this process. the requirements of the project will become more refined and the project vision will become clear. In addition, new constraints and project assumptions may be factored into the planning processes that were not accounted for in the early cost and time estimates. These additional constraints, assumptions, and requirements must be accounted for and their causes documented.

For example, an internal resource (such as a trainer) needed on the project may not be available during the months when the project schedule calls for the trainer. Now the project will need to hire a contracted resource to complete the work so the project schedule can be met. The new resource has a higher cost than the internal resource, so the cost constraint must be documented and the project costs are adjusted.

Technical Documentation

The technical decisions made in the project are typically based on the requirements of the stakeholders, industry standards and regulations, and project concepts. The information the technical decisions are founded on require documentation for future planning, reference, and inspection. The documentation of the industry standards can be included here or, based on the project type and size, in its own section.

For example, the customer may query why a particular material was used in the project deliverable. The technical documentation will provide the reason the material was chosen, its benefits to the project, and the associated cost to the customer.

Initial Planning Specifications

In the initial planning processes, the project manager and the project team may have ruled out alternatives to the project solution for quality, standards, or other reasons. Or, decisions may have been made to move the project toward a particular solution. These initial planning outputs should be documented to support the decisions that the project manager and the project team have made in the project solution.

Exam Watch

The whole point of the project plan is to communicate something to someone at some time. When stakeholders ask questions about the project, what does the project plan say? When project team members have questions about the project work, what does the project plan say? The only exception to this 'rule' is when it comes to vendor disputes. With vendor disputes, refer to the contract, as it is the legal document for the client-vendor relationship.

For example, a customer may ask the project manager in the final phases of the project why a particular technology was chosen. The answer to the question may be the incompatibility with existing technology in the customer's environment. With appropriate documentation of the initial planning and supporting detail of the project decisions, the project manager can quickly and accurately answer the customer's questions.

Executing the Project Plan

So you've got a project plan-great! Now the work of executing the project plan begins. The project manager and the project team will go about completing the promises made in the project plan to deliver, document, measure, and complete the project work. The project plan will communicate to the project team, the stakeholders, management, and even vendors what work happens next, how it begins, and how it will be measured for quality and performance.

The product of the project is created during these execution processes. The largest percentage of the project budget will be spent during the project execution processes. The project manager and the project team must work together to orchestrate the timings and integration of all the project's moving parts. A flaw in one area of the execution can have ramifications in cost and additional risk and can cause additional flaws in other areas of the project.

As the project work is implemented, the project manager refers to the project plan to ensure that the work is meeting the documented expectations, requirements, quality demands, target dates, and more. The completion of the work is measured and then compared against the cost, schedule, and scope baselines as documented in the project plan. Should there be-GASP!-discrepancies between the project work and the baselines, prompt and accurate reactions are needed to adjust the slipping components of the project.

Evaluating the Project Plan Execution Inputs

For a project to be successful, there must be adequate time allotted for planning. A project manager can't, or shouldn't, accept a project and immediately move into execution without planning. There are, however, additional inputs to the project execution besides planning. This shows the inputs of project plan execution:

Consider the Project Plan

You've spent a great deal of time already in this chapter examining the outputs of planning-specifically, the project plan. The project plan is a composite of individual plans and summaries that guide and communicate the project work. As you may have expected, the project plan serves as a primary input to project execution. As a quick refresher, here are the details of the project plan that will guide the project execution:

• Project Charter

• Project management approach

• WBS

• Cost and schedule estimates

• Roles and responsibilities matrix

• Baselines for cost, schedule, and scope

• Target dates for milestones

• Staffing requirements and associated costs

• Risk Management Plan

• Subsidiary plans:

  • Scope Management Plan

  • Schedule Management Plan

  • Cost Management Plan

  • Quality Management Plan

  • Staffing Management Plan

  • Communications Management Plan

  • Risk Response Plan

  • Procurement Management Plan

  • Open issues at project plan completion

Rely on the Supporting Detail

Remember all of the stuff you based your decisions on in the project plan? That's the supporting detail you'll also use to guide your project execution. For example, if you based a technical solution on an article you read during your research, it'll be handy to have that article as you move in the project plan execution. Also consider historical information that you used to guide your project plan development. Historical information is an excellent guide the project manager can rely on during project planning and execution.

Exam Watch

Don't fall in love with memorizing these different plans. You should be familiar with them and what they accomplish and know which plan you'd rely on in a given situation. On the exam you should choose the most appropriate and specific plan for the condition described. For example, the Risk Management Plan is more specific than the whole Project Plan. Finally, remember that the project plan is a formal, management-approved, document.

Reference the Organizational Policies

Project execution must work with and in organizations. Projects cannot disrupt the ongoing operations of the performing organization. The policies of the performing organization will guide the methods used during the project plan execution. Recall that organizational policies can be formal or informal and can include any of the following:

• Quality management programs: quality expectations, requirements, audits, and documentation

• Human resource management policies: methods by which team members are recruited, released, hired, disciplined, and fired from the project team

• Financial Controls: Project manager responsibility for the project expenses and invoices and generally for the monies spent on the project

Consider the Preventive Actions

Do you wear your seat belt? Take an umbrella when there's chance of rain? These are preventive actions against some risk. In project management, preventive actions are steps the project manager and the project team can take to prevent the negative outcome of possible risk events. Preventive actions are documented methods to avoid risks from influencing the project success in a negative way. Preventive actions are actions to take risk events out of play.

Apply Corrective Action

Things go awry. Corrective actions are methods the project manager and the project team can take to bring the project back into alignment with the project plan. For example, a delay in the project work has now shifted the project schedule by a month. The project manager, the project team, and even the stakeholders can examine the project schedule to see what possible alternatives can be taken in the project schedule to complete the project on time. Solutions may include additional resources, fast tracking, changing the order of work packages, and so on. Corrective actions bring the project performance back in alignment with the project plan. In addition to communicating, project managers spend a great deal of their time applying corrective actions.

Implementing Tools and Techniques for Project Execution

You have completed a workable, approved project plan. Now it's time to implement the thing. This is the heart of project management: taking your project plan and putting it into action. You'll act, do, adjust, and repeat. There are several tools and techniques the project manager will use to execute the project plan.

Using General Management Skills

The arsenal of general management tools help the project manager manage, lead, direct, and accomplish. You do remember the general management skills from Chapter 2, yes? Just in case, here's a brief recap:

• Leading Leadership is the ability to establish direction and align people, while motivating and inspiring them to accomplish.

• Communicating Ah, yes, communicating, the biggest requirement of a project manager is to communicate the correct information to the correct people when they need it. Communication to internal and external stakeholders can be oral or written and in many different modalities (e-mail, memos, reports, and so on). Communicating also includes everyone's favorite activity: managing meetings.

• Negotiating Negotiating is the art of working with others to reach a mutually beneficial and fair agreement. In most cases, the project manager will negotiate on project time, cost, and scope issues.

• Problem Solving This activity is a blend of problem definition, root cause analysis, and decision making. The project manager works with the project team to define the problem-the root of the problem, not the evidence of the problem. Next the project manager makes an educated decision on how best to squelch the problem.

• Influencing the Organization This activity is, as the PMBOK puts it, 'the ability to get things done.' It's the knowledge of how an organization operates: what it takes to get resources, time, and action.

Applying Skills and Knowledge

Here's some common sense: it's the project team that is going to be completing the work in the project, so the project team must know how to do the work. For the project work to be completed with accuracy, quality, and on schedule, the project team must be familiar with how to actually complete the activities in the project plan.

As part of the planning process group, the necessary resources to complete the project are identified. If the project team is lacking the necessary skills to complete the work, project team development is needed: educate the team. The project will obviously suffer if the project team doesn't have the skill set to complete the work you're about to assign to it. An alternative to additional training is to supplement or replace the project team with the appropriate resources to complete the project work.

There is inherent risk to moving into project plan execution with a project team that is unprepared to complete the required work. Delays, quality issues, reworkings, and fines may occur and even lives may be at stake. The project manager must work with the project team for honest assessments of members' abilities, knowledge, and skills needed to complete the project work.

Exam Watch

If the project team is lacking in the skills to complete a portion of the project, train them.

Implementing a Work Authorization System

How will the project team know when they can go to work on their activities? Consider a project with a team that is non-collocated. In this project, a set of activities must be completed in London before the activities in Prague can begin. The coordination between the two cities must be managed, documented, and controlled. A Work Authorization System is a tool that can control the organization, sequence, and official authorization to begin the next piece of the project work.

Work Authorization Systems are typically influenced by the size of the project. For example, a large, non-collocated project may use a formal, documented approach to approve and confirm project work that has been completed. The documentation of completed work is then followed by a document to authorize the next project work package to begin.

In smaller projects, however, an elaborate system to sanction downstream work packages may be counterproductive. In these instances, a verbal authorization system is most appropriate. The project manager must consider the cost of the Work Authorization System against the priority and impact of the project, the effectiveness of such a system, and the overall need to implement the system in any given project.

On the Job 

Collaborative PMIS packages can also serve as a Work Authorization System-if they are configured and used properly. Any PMIS, electronic or paper-based, is only as good as the person (or persons) keeping the information up-to-date.

Hosting Status Review Meetings

The project team is at work completing the project objectives-or so you think. In addition to providing a reason for getting out of the office and inspecting the project work, Status Review Meetings allow the project manager to interact and record the status of the team members' work efforts.

Status Review Meetings are regularly scheduled meetings to record the status of the project work. These common meetings provide a formal avenue for the project manager to query the team on the status of their work, and allows the project team to report delays and slippage These meetings also allow the project manager and the project team to forecast what work is about to begin. The goal of the meeting is to ascertain where the project stands, to hold the team accountable for their work, and to serve as motivation for the project team to complete their work on time.

Status Review Meetings are documented in the Communications Management Plan, as they are regularly scheduled communication events. A typical schedule of these meetings may call for the project team to meet with the project manager on a weekly basis, and the project manager and the project team to meet with customers on a monthly basis. The frequency of the meetings should reflect the project size, demand for status, and requirements of the performing organization.

Using a Project Management Information System

A PMIS is an excellent tool to help execute the project plan. A PMIS can be electronic or paper-based. The goal of a PMIS is to automate, organize, and provide control of the project management processes. A typical PMIS software system has

• WBS creation tools

• Calendaring features

• Scheduling abilities

• Work authorization tools

• EVM Controls

• Quality control charts, PERT charts, Gantt charts, and other charting features

• Calculations for critical path, EVM, target dates based on the project schedule, and more

• Resource tracking and leveling

• Reporting functionality

Organizational Procedures

Every performing organization has rules and regulations that are specific to the industry it operates within. In addition, the performing organization will likely have standard operating procedures that determine the order, approach, and autonomy of the project manager and the project team.

For example, an organization operating within the construction industry must operate according to the laws and regulations of the country, state or province, and city. In addition, the performing organization may require its construction crew to adhere to its safety standards, quality inspections, and other company rules that are not mandated by a government agency. The project manager must work within not only the law, but also the additional constraints the organization has added to the project.

Examining the Outputs of Project Plan Execution

The project is being completed; there is visible evidence that it is moving towards the desired future state. Inspections by the project manager and scope verification by the customer also prove the project team is completing their work as planned. Status Meetings provide opportunity for the project team to report their work and evaluate it against the WBS and the network diagram. Things are moving along smoothly.

And then it happens. The project team begins to slip on the quality of the project work. Team members begin to take longer than what was planned to complete their project work. The scope verification with the clients takes longer-and their satisfaction with the project work begins to wane. What's a project manager to do?

This scenario is typical of project plan execution. The team completes the work, the project manager reviews the work-and then makes adjustments to bring the project back into alignment with the baselines created in the project plan. There are two major components of project plan execution that happen throughout project execution, not just the end:

• Work results

• Change requests

Examining the Project Work Results

The team completes their work based on the project plan. The end result of the work should be measured against the quality metrics, scope requirements, and expected outcomes of the work as defined in the project plan. In addition, the project manager must examine the time and cost required to reach the work results and compare them against the baselines recorded in the project plan. Any difference between what was experienced and what was planned is a variance.

Work results are not always physical, tangible things: the creation of a service, the completion of a training class, the completion of a certification process-these too can be measured as work results.

Examining Change Requests

How many times have stakeholders begged, pleaded, or demanded a change in the project scope? Probably more times than you can count, right? Change requests are any requested deviation from or addition to the project scope, schedule, budget, quality, or staffing. Change requests will predominantly trickle (or flood) to the project manager during project plan execution. Change requests almost always affect one of four facets of a project:

• Schedule A desire to shorten or lengthen the project duration. For example, a key stakeholder would like the project to be completed before a particular business cycle begins. If the project can't be completed by that time, the project will be delayed until the business cycle has completed, so the project won't interfere with the business operations.

• Cost A reduction or increase in the project's budget. For example, the project's priority has been reduced in the organization so the budget may, unfortunately, be reduced as well. Budgets can also be increased: A functional manager may want to spend all of the remaining departmental budget at the end of the fiscal year so that next year's budget may meet or exceed the current year's budget. In this questionable instance, additional funds, new features, and more resources, needed or not, are added to a project's budget to 'help' the functional manager spend the budget.

• Scope The most common instance of change. Stakeholder may request additional features, different features, or small changes to the project product. Each change must be evaluated against the project plan, the project scope, and supporting detail to determine the cost, time, and risks implied.

• Combination A change made to the schedule, cost, or scope affecting more than one facet, as is likely. This goes back to the idea of the triple constraints of project management. For example, a change to finish the schedule faster may be reasonable if more resources are applied to the project to complete the work faster. More resources, in turn, means more money.

Managing Integrated Change Control

Imagine you're the project manager for our old friends at Zings Sweater Works. The project you're working on now, the Customer Satisfaction Project, handles the marketing, customer relationship management, and sales follow-through activities for your organization. One component of this project is to allow customers to easily browse and purchase sweaters online.

The Vice President of Sales approaches you during project execution to congratulate you on how well the project is moving along. The work results are great, quality is proven, and the initial reaction from the stakeholders is outstanding. 'However,' he says, 'I've got a great idea on how we can make the deliverables better.'

Uh-oh…here comes the change request.

Exam Watch

When competing objectives arise, such as fast completion and a small budget, remember: you can have it fast or you can have it cheap, but you cannot have it fast and cheap-unless the scope of the project is reduced to satisfy the available time and the available funds. Time costs money in project management because of the required resources to complete the work.

The VP of Sales wants to include a feature that would allow customers to add sweater choices to a 'wish list' because he saw it on a competitor's site. In addition, the VP wants to add:

• Options to remember users when they come back to the web site

• Options to allow visitors to join a newsletter for coupons and announcements

• Gift-services to remind customers of upcoming events in their personal calendar

• An online reward system that will allow customers to accumulate points as they purchase sweaters online

Now, you've got to deal with these change requests. The changes should flow through a Change Control System, be evaluated, and if approved for this project, be meshed into the existing work. As you're contemplating these change requests, Susan, a developer for the project, pops into your office.

Susan reports that she and the web designers have been adding some features to the web application and thought they should run it by you before proceeding. She says that the development team thought it'd be great to add a feature on each page that would track how long a customer spent on a particular web page. These stats would allow marketing to promote certain sweaters, evaluate sweaters that are being ignored, and track the amount of time a sweater is viewed before it is purchased. 'Pretty clever, huh?' she says. 'And it only takes about five additional minutes per sweater for us to write the code and hook it into a database.'

Sounds good, right? And then you remember that, with all the different colors and sizes, there are at least 3,500 different sweaters in the web catalog. That's a ton of time at five minutes per sweater.

These incidents are reflective of the type of change requests a project manager faces regularly. Changes to the product often stem from the customer of the project. Changes from the project team may also stem from suggestions of the stakeholders-such as small, innocent changes that bloom into additional time and cost. Finally, changes may come from the project team, as with Susan in the above example. When it comes to Integrated Change Control the project manager must provide for:

• An evaluation of the change requests to determine whether changes are needed and wise for the project

• A determination that an unapproved or undocumented change has occurred within the project work

• An acceptance of the change and methods for managing the changes that have occurred or are about to occur

Reaction to Change

When changes are proposed to the project, the project manager must route the proposed changes through a Change Control System (CCS). The CCS may also include the review of proposed changes through a Change Control Board (CCB). Changes may be discarded or approved on the basis of different criteria, such as Benefit Cost Ratios (BCRs), value-added changes, risk, and political capital.

When changes are approved, the project manager must then update the project baselines, as changes will likely affect a combination of scope, cost, and time. The updated baselines allow the project to continue with the new changes fleshed in and provide for accurate measurement of the performance of the project as changed.

This is an important concept: update the project baselines. Consider a project to which work has been added but for which the schedule baseline had not been updated: the project's end date will be sooner than what is possible, because the project baseline does not reflect the additional work that should extend that date. In addition, a failure to revise the project baseline could skew reporting, variances, future project decisions-and even future projects.

Consider a project manager who does not update the project baseline after a change. The completion of the project goes into the archives and can serve as historical information for future projects. The historical information is skewed, as it does not accurately account for the added work and the projected end date or budget.

Changes, small or large, must be accounted for throughout the project plan. Notice how the Integrated Change Control processes influence the communications of the change, including the change approval or denial. That's the whole point: to integrate proposed changes into the project processes. Figure 4-3 details Integrated Change Control.

Figure 4-3: All change requests must pass through Integrated Change Control.

Exam Watch

Current projects become future historical information. Inaccurate data in the project plan, even if it is worked through on the project execution, can cause long-term ill affects in other projects.

Consider the Inputs to Integrated Change Control

As with all processes in project management there are inputs to Integrated Change Control. There are three inputs to consider:

• Project plan Most projects have some change at some point in the project plan execution, so the management of the changes must be planned for. It is not so much the change incident, but the process of approving or denying the change that the project manager must anticipate. Recall that the project plan is the guide for all future project decisions.

• Performance reports The performance of the project is measured against the baselines defined in the project plan. Poor performance, a measurement below the project baselines, must prompt reactions to determine the cause and corrective actions to resolve the problems.

• Change requests Requests to change attributes of the project can come in many different modalities-written, oral, formal, informal, internal, external- and can even result from new laws, regulations, and industry mandates.

Implementing Tools and Techniques for Integrated Change Control

Given that changes, or requests for change, are likely to happen in the project, what tools are available to squelch, evaluate, and approve the proposed changes? And how can the project manager organize change requests in an orderly system so he or she's not constantly evaluating change requests instead of focusing on project completion? And how do change requests get approved, worked into the project plan, and accounted for in costs, schedule, and risk?

There are many tools to apply to requests for change: consistency, scope comparison, benefit-cost ratios, risk analysis, and the estimate of the time and cost to incorporate the change, among others. The tools will guide the project manager, the project team, and stakeholders through the process of approving and declining changes. The best approach for Integrated Change Control is a constant, purposeful process of reviewing, considering, evaluating, and then deciding if the change is needed or not.

Relying on a Change Control System

A Change Control System is a formal process of documenting and reviewing proposed changes. It establishes the flow of change from proposal to decision. The Change Control System is a process that describes how project performance will be monitored, how changes may occur, and then how the project plan may be revised and sent through versioning when the changes are approved.

A Change Control System is a collection of documented activities, factors for decisions, and performance measurements-not a computer program. While many electronic Project Management Information Systems offer a Change Control System, know that a Change Control System is a documented approach to change, not an automated approval structure.

Some organizations may have a Change Control System that is used across all projects and maps to common guidelines within the organization. If the performing organization does not have a Change Control System, it is the responsibility of the project manager and the project team to create one. A Change Control System is mandatory for effective project management.

Within a Change Control System there may be a collection of management, key stakeholders, and project team members that review the changes for approval or denial. This board is defined in the project plan, and its roles and responsibilities are defined prior to project plan execution. Common names for the board include:

• Change Control Board (CCB)

• Schedule Change Control Board

• Technical Review Board (TRB)

• Technical Assessment Board (TAB)

• Engineering Review Board (ERB)

Implement Configuration Management

Configuration management focuses on controlling the characteristics of a product or service. It is a documented process of controlling the features, attributes, and technical configuration of any product or service. When it comes to project management, configuration management has a focus on the project deliverables. In some organizations, configuration management is a part of the Change Control System, while in some industries, such as manufacturing; configuration management is control of existing operations. In a general sense, configuration management consists of the following:

• The documentation of the features, characteristics, and functions of a product or service

• The applied control to restrict changes to the features, characteristics, and function of the product or service

• The process of documenting any changes to the product or service

• The ongoing auditing of products and services to ensure their conformance to documented requirements

Applying Performance Measurement

The end result of project plan execution must be measured to see if the implementation of the plan meets the expected results of the project plan. The most common measurement of project plan execution is Earned Value. Earned Value is a collection of formulas to measure the project worth, performance, and likelihood of the project completing on time and on budget.

Exam Watch

Configuration management is tightly related to change control. The goal of configuration management is to ensure the work of the project is in alignment with the project goals. This is especially important in creating a new product. The design specs, prototypes, and pilot testing must be in alignment with the business objectives of the project.

Revisiting Planning Processes

Planning is iterative. As project plans rarely, if ever, happen exactly the way the project team and project manager planned them, the project freely moves between the controlling, executing, and planning processes. This is most evident when changes enter the project scene. The project manager and the project team must evaluate the proposed changes for additional cost, time, and risk concerns.

If the project work slips from the expected performance, quality, or schedule, adjustments are needed. These adjustments will require consideration of project activities, the critical path, resources, cost, sequence of activities, and other refinements to the project plan.

Evaluating the Outputs of Integrated Change Control

As the project follows the project plan and changes are presented, the project manager will implement Integrated Change Control. Some changes will be denied, documented, and archived for reference if needed. Other changes will be approved and factored into the project scope and have their time, cost, and risks documented and accounted for. The process of Integrated Change Control is ongoing until project closure.

Updating the Project Plan

When changes are allowed into the project, their results must be included in the project plan. Any changes to scope, cost, time, risk, scheduling, and other attributes of the project plan must be revised and documented. In addition to having the project plan updated, any supporting detail used in the decision to include the change should be included in the project planning supporting detail. This may include information on new laws and regulations, proof of concept, rationalization for changes from management, and other information.

Applying Corrective Action

When the project work is measured and variances are evident, corrective actions are required. Corrective actions bring the project work results back into alignment with the project plan, increase project value, and attempt to ensure the project will end on time and on budget.

Inside the Exam

What must you know from this chapter to pass the exam? Know the purpose of the project plan: to guide the project manager through the Execution and Control groups. The project plan is also in place to provide communication to the project team, stakeholders, and management. The project plan guides all future project decisions.

You should know all of the components of the project plan. Know what each of the subsidiary project plans are used for, how they can be updated, and what their objectives are. Remember, the point of planning is to create the project plan. The project plan then is to provide leadership and direction for the project execution and control processes. The project plan is a formal, management-approved document. Once management approves the plan, then work can begin.

Remember the WBS? It's a major piece of the PMP exam. Know the attributes of the WBS, that it serves as an input to the planning process and execution, and that it requires input from the project manager and the project team. The WBS is an input to five planning processes:

1. Cost Estimating

2. Cost Budgeting

3. Resource Planning

4. Risk Management Planning

5. Activity Definition

After the WBS, historical information is another big factor on the exam. Why? Historical information is proof from other project managers. Historical information allows the project manager to rely on what has been proven, what has been accomplished, and what has been archived for reference. And remember: the current project plan will become a future historical reference.

Assumptions and constraints are present on every project. Assumptions are beliefs held to be true, but not proven to be true. Assumptions should be documented in the project plan. Constraints are restrictions the project must operate within. The triple constraint of project management-time, cost, and scope-will visit you on exam day, as will other internal and external constraints.

To begin the project, a project charter is needed. Project charters come from a manager external to the project. Once the charter is present, the project manager is named. The project manager then assembles the project team and begins the planning processes. The primary output of any planning is a project plan. The execution of the project plan cannot begin until management approves the plan. All work described in the project plan must pass through a Work Authorization System, either formal on a larger project, or informal on smaller projects.

Integrated Change Control requires evaluation of change requests to determine their worthiness for approval-or lack thereof for denial. Change requests can be written or verbal, internal or external. Change requests can stem from stakeholders or external sources such as government agencies, laws, or industry mandates.

Documenting the Lessons Learned

The project moves towards completion-what have you learned? Lessons Learned is a formal document that serves as a journal of the experience of the project manager, the project team, and the stakeholders. The project team and the project manager complete the Lessons Learned document. It becomes part of the project archives so that other project managers can learn from their experience. Lessons Learned documents are not completed only at the end of a project, but throughout a project. Lessons Learned can be incorporated into the Communications Management Plan as communication events.

---