CERTIFICATION OBJECTIVES
4.01 Developing the Project Charter
4.02 Developing the Project Management Plan
4.03 Directing and Managing the Project Work
4.04 Managing Project Knowledge
4.05 Monitoring and Controlling the Project Work
4.06 Performing Integrated Change Control
4.07 Closing the Project or Phase
Two-Minute Drill
Q&A Self Test
What the heck is project integration management? Project integration management is the heart of project management and comprises the day-to-day processes the project manager relies on to ensure that all of the parts of the project work together.
Put simply, project integration management is the way the gears of the project work together.
Within any project are many moving parts: schedule management, cost management, schedule conflicts, human resource issues, iterative planning, alternative methods of doing the project work, and much, much more. Project integration management is the art and science of ensuring that your project moves forward and that your plan is fully developed and properly implemented. Project integration management requires that your project—regardless of its size and impact—meshes with the existing operations of your organization. This knowledge area encompasses integrated change control, too; you’ll need to manage changes that are bound to happen within your project.
Project integration management requires finesse. As the project manager, you will have to negotiate with stakeholders to resolve competing project objectives. This requires organization, since you’ll have to develop, coordinate, and record your project plan. It requires the ability to accomplish your project plan. It requires leadership, record-keeping, and political savvy, given you’ll have to deal with potential changes throughout your project implementation. And, perhaps most importantly, it requires flexibility and adaptability throughout the project plan execution.
In this chapter, we’ll cover the big topics you have to master to pass your PMP exam, as well as the skills necessary to implement projects successfully out in the real world. These topics include the following:
Developing the project charter
Developing the project plan
Directing and managing the project work
Managing project knowledge
Monitoring and controlling the project work
Managing integrated change control
Closing the project or the project phase
As you’ve learned already, all projects need a project plan—it’s up to the project manager and the project team to create one. Then the project manager must work with the project team to ensure that the work is being completed as planned. You’ll also manage the information that comes into the project and seek out information that’s needed for the project to be successful. Finally, the project manager must work throughout the project to control changes across all facets of the project. Figure 4-1 shows the complete picture of project integration management.
FIGURE 4-1 Project integration management coordinates the project from launch to close.
Of all the project management knowledge areas, project integration management is the one that’s totally managed by the project manager. Cost management, schedule management, risk management, and other knowledge areas can be managed within the project by specialists from your organization. But project integration management is totally led by the project manager—in fact, it’s the day-to-day work of the project manager. And like most things in project management, the larger and more complex the project, the more detail, organization, and sophistication is needed within project integration management.
Project integration management is the only knowledge area that has processes in each of the five process groups. We’ll explore seven processes in this chapter:
Develop the project charter (Initiating)
Develop the project management plan (Planning)
Direct and manage the project work (Executing)
Manage project knowledge (Executing)
Monitor and control the project work (Monitoring and Controlling)
Perform integrated change control (Monitoring and Controlling)
Close project or phase (Closing)
With the exception of creating the project charter, the processes in this knowledge area are broad, iterative in nature, and really coordinate the activities of the project. You’ll plan, execute, control, and close phases many times. To be clear, these processes are iterative, so you’ll always move to the most appropriate process depending on what needs to be done next in the project. Although there is a logical progression of moving through the five process groups, the process groups are not phases of the project.
One of the nice things about project management is that it’s not concrete; it’s fluid, evolving, developing from year to year and between organizations. Project management can be adapted, twisted, pared down, or sized up. There’s no law or regulations from stopping you from managing a project however you best see fit. Several trends have found success and favor in the project management community when it comes to project integration management.
Because project integration management is all about coordinating the other knowledge areas, there is lots information to gather, store, process, and share. You should explore the following emerging trends in project integration management:
Automation Software tools, such as Microsoft Project and Basecamp, help with the scheduling, cost tracking and estimating, workflow management, and communications. These tools are commonly called the project management information system (PMIS), and that’s how you’ll see it referenced throughout the balance of this book. You won’t be tested on any specific PMIS for your exam.
Visual management tools In the olden days, I used giant sheets of paper to map out project schedules, task lists, and deliverables. Not anymore. Now it’s dashboards of these items. Visual management tools provide a quick way of seeing project status, activities in motion, issues, and other project information. Visual management tools can be customized for your project and help you share information quickly with the entire project team.
Project knowledge management All projects create data that needs to be managed to be useable information. The information needs to be available: reports, electronic viewing, and even mobile access. And you’ll have to control who has access to what data. This is a new process in the PMBOK Guide, sixth edition.
Project management responsibilities Traditionally project initiation, business case development, and benefits management were outside of the project manager’s responsibility. Today, that’s changing. Project managers often help management, the project management office (PMO), and the steering committee to define objectives, build requirements, work with stakeholders, and create benefits for the organization.
Hybrid approaches to project management New practices in project management, such as agile and Extreme Programming (XP), are being utilized by more than just software development project managers. Organizations are cherry-picking the best of these approaches and melding them with other practices to streamline projects, have more control, and create a project management system that works in their environment.
No two projects are identical—there are always one or more different factors that distinguish one project from projects that have happened in the past. Because of this unique nature of projects, it’s not uncommon to tailor the project integration management processes to fit the project and the organization. The goal of project management isn’t to fall in love with the project management processes or the bureaucracy of a framework, but to get things done.
Tailoring the project integration management processes help organizations better manage the project with an eye toward balancing the need for process and the need to work expediently in the execution of the project work. Consider these points for tailoring project integration management:
Project life cycle The project life cycle is made up of the phases of the project. In your industry, the phases may be predefined and readily identified. In other projects, you may need to identify logical phases that aren’t too large or small, that create a deliverable, and that serve as ideal segments to the project.
Development life cycle You may need to identify how the project output will be built. You may use a traditional predictive life cycle, where you plan most everything up front in the project. Or you may embrace the adaptive life cycle, where you’ll move through increments or iterations to define what’s most important and what should be created next.
Management approach Larger projects require more detail than smaller projects. Depending on the size of your project, your organization, and the project management framework your organization utilizes, you may need to tailor the management approach to keep the project moving quickly without heavy, unneeded processes.
Knowledge management Project managers need a systematic way of collecting, distributing, and storing information. They also need to control who has access to the information, when the information is needed, and what directions are needed for stakeholders to get information they need quickly. This is knowledge management.
Change management The PMBOK Guide (and this chapter) will define a generally accepted practice of change management. The model I’ll discuss is fine, but chances are that in your organization you’ll need to tweak this model to work best for you and your projects. Change isn’t unusual in a project—in fact, it’s expected—but how you manage the changes is entirely up to the project manager and the organization.
Governance Every organization needs some governance for the project. Governance needs to be defined and communicated, and its expectations must be met. Governance includes steering committees, change control boards, user groups, or whatever entity is required in your organization that sets the rules that you need to follow. Governance will control how you manage the project and what the project team does, and it will greatly influence communication of project status.
Lessons learned Lessons learned is knowledge that the project manager and the project team create throughout the project, not just at the end. Your tailoring will define the lessons learned creation, where the information is stored, and how you and others may access the information.
Benefits management Projects create benefits, and you’ll need to define when the benefits will become available. On some projects, there may be intermittent benefits that the stakeholders can begin using as the benefits become available. Other projects, such as a technology cutover project, won’t have benefits available for the stakeholders until late in the project.
Although project integration management is the focal point of work for project managers in a predictive approach, it’s a bit different in an agile or adaptive environment. In an agile environment, the project team members have much more control over the integration of project management plans and project components. Agile is more fluid than the predictive environment, so documentation isn’t a value-added component to the project.
Though the project manager still oversees the coordination of the project management knowledge areas, the agile and adaptive approaches rely more on the project team defining what needs to be done at the current point of the project, and the team plans and does the work accordingly. The project manager doesn’t necessarily control and direct the project work, but ensures that the project team has what it needs to get the work done.
CERTIFICATION OBJECTIVE 4.01
Let’s not linger. You know what the project charter is and what it does: It authorizes the project and enables the project manager to assign resources to the project work. It’s all about power. The project manager is officially identified in the project charter, though the project manager should be selected as early as possible during the project—hopefully while the charter is being developed—but she must be identified before project planning commences. The project charter also demonstrates the organization’s commitment to the project and the investment in the endeavor.
The project manager, however, doesn’t issue the project charter. Nope. The project charter comes from outside of the project. The project manager may help develop the project charter, but it’s not signed or issued by the project manager; the charter needs the authority of someone in the organization who has oversight of the needed resources and finances the project will require. The project manager is, though, accountable for the project charter getting issued. Specifically, the project charter should be issued outside the confines of the project by any of the following:
Sponsor
Project management office
Portfolio governing body, such as a steering committee
Program organization
Portfolio organization
Authorized organizational representative
And the reason why a project is chartered? It can be because of opportunities, problems that need to be solved, business requirements, and lots of other reasons. The project manager or business analyst may create a business case that defines why a project needs to be chartered. A business case determines whether the investment in the project is worth making. The business case will define the project purpose and characteristics, such as the following:
Market demand
Business need
Customer request
Technological advance
Legal requirements
Ecological impacts
Social need
The point of the charter, other than authorizing the project and the project manager, is to launch the project officially and to enable the project manager to go about the business of getting the project work planned and then finished. The charter gives the project a definite start and maps out the high-level objectives for the project. The project charter needs to communicate all of the following directly or through references to other documents:
Project purpose The charter needs to answer why the project is being launched and why it’s important to the organization.
Project requirements for satisfaction The charter must identify what it’ll take to complete the project—in other words, it should identify the metrics for success.
High-level project description The charter provides a description of what the project will create and what the project boundaries may be, and it provides an overview of the key project deliverables.
High-level requirements The charter should identify the high-level purpose of the project, the business need the project aims to accomplish, and/or the product requirements the project will create.
High-level risks Any of the known risks should be referenced in the project charter.
Milestone schedule Milestones are timeless events that show the progress within a project.
Summary budgetThe charter should have preapproved financial resources.
Stakeholder list The charter needs to identify the key stakeholders who will influence the project.
Project approval requirements The project charter needs to state clearly what it takes for the project to be successful and who signs off on project deliverables, project decisions, and project completion.
Exit criteria The project charter defines what constitutes completion of the project and, in some cases, what scenarios would cause the project or phase to be cancelled.
Project manager The project charter defines who the project manager is and what level of power the project manager has in the project.
Project sponsor The project charter defines who the project sponsor is; if the project sponsor is not the person signing the project charter, it should define who is authorizing the project (it’s almost always the project sponsor who signs the charter). The sponsor has the authority to authorize the project and to help resolve project issues during execution.
To develop the project charter, the project manager will most likely rely on expert judgment. Expert judgment, a tool and technique you’ll see often in project processes, simply means the project manager is relying on someone with more knowledge and wisdom to help make the best decisions for the project. For the project charter, expert judgment can be from people with insight into the organization’s strategy, benefits management techniques, technical knowledge, estimating skills for schedule and costs, and risk management.
The project charter will also need data in order to communicate the goals of the project. Data-gathering techniques for creating the project charter include the following:
Brainstorming A group of people generates as many ideas as possible about the project. The first step of brainstorming is the most common: generate ideas. The second step, unfortunately, is often overlooked: analyze the ideas.
Focus groups A focus group of stakeholders has a conversation about the project, its goals, any concerns, and other project charter attributes. You’ll see focus groups again when I discuss the project scope creation.
Interviews Unlike a focus group with its conversational approach, an interview is a one-on-one discussion with stakeholders to gather data through specific questions.
During this early process, the project manager will need to implement meeting management skills to keep people on track and keep the charter creation process moving forward. The project manager may also need some conflict management skills to manage disagreement among stakeholders; I’ll discuss this in more detail in Chapter 9 on project resources. Finally, the project manager may be serving as a facilitator when meeting with large groups of project stakeholders.
Before the project charter is created, the organization may have created a business case and a benefits management plan. The business case justifies the investment in the project and often is the document upon which the project charter is based. The business case also defines the cost-benefit analysis of doing the project, project boundaries, and why the project should be initiated. The benefits management plan defines when the project benefits will be delivered to the organization. This document contributes to the project charter.
If your company is completing projects for other entities, your contract will probably define what your company will provide for the client and what the client will pay for the work and contribute to the work, and other terms. Your project charter may reference the details of the contract directly, define the agreements of the contract, and include service-level agreements, letters of intent, a memorandum of understanding, or even just a verbal agreement for the work. Your company might also use this approach if you’re operating in a functional environment and completing work for other lines of service within your business. In any case, if there’s an agreement, written or verbal, between the project initiators and the project customer, it should be documented and referenced as part of the project charter.
Project managers know that many things influence a project’s success; it’s not all planning, execution, and good luck. Projects take place within organizations, and many components of any organization can, and will, affect a project’s success. These enterprise environmental factors have to be considered throughout the project and should be identified in the project charter. Enterprise environmental factors include the following:
Government and industry standards
Regulations or legal requirements
Marketplace conditions
Organizational governance, culture, political climate, and framework
Stakeholder risk tolerances
Has anyone in the organization ever done something like this project before? Historical information is an organizational process asset that resource project managers can use to make decisions about their current projects. Historical information provides proven documentation of the success or failure of performance and can be referenced for project selection criteria. For instance, has management squelched similar projects for specific reasons? Historical information can be referenced for comparable projects to see how they performed through to execution, as well as how the deliverables of the project performed according to prediction.
In addition, historical information is one of the key elements in determining whether an existing project should move forward into the next project phase. If the completed project phase has proven successful and provided some merit or value, it’s likely to move forward. Projects that don’t prove valuable—based on the performance of the phase or less-than-desirable phase results—will likely be axed.
Organizational process assets can also include the standard policies of your organization, reporting methods, and templates your organization may rely upon.
Project selection methods are about resolving the unknown, predicting the likelihood of project success, and determining the expected value of that project’s success—or the cost of its failure. The process of selecting those projects to keep and those to discard is based on the following two methods:
Benefit measurement methods
Constrained optimization methods
Benefit measurement methods are the most common approaches to project selection and are usually defined before the project charter and documented in the business case and the benefits management plan. Benefit measurement methods are tools that enable management and key stakeholders to examine the benefits of a project and how the project completion will contribute to the organization. Constrained optimization methods are also tools for selecting projects, but their approach is much more scientific and math-driven. Don’t worry—you won’t need to know much, if anything, about constrained optimization on the PMP exam. We’ll examine both selection types later in this chapter.
Project selection is also known as “Go/No Go decision-making.” Projects with many variables are excellent candidates for phase gates. The project is allowed a Go decision to the end of the first phase. Another Go/No Go decision happens at the end of each phase based on the performance and deliverables.
Meet Tracy. Tracy has a great project she’d like to see authorized. She has to “sell” the project to management in order to have it authorized. She needs to determine what’s so great about her project and why management should buy into it. She is looking for project selection criteria—reasons why her project should be authorized. Following are some possible considerations Tracy can include:
Return on investment
Realized opportunities
Market share
Customer perspective
Demand for the product
Social needs
Increased revenues
Reduced costs
Regulatory compliance
The various benefit measurement methods are all about comparing values of one project against the values of another. As you might expect, the projects with higher, positive values typically get selected over projects with low values. The following sections describe some common benefit measurement methods you may encounter.
Scoring models (sometimes called weighted scoring models) use a common set of values for all of the projects up for selection. For example, values can be profitability, complexity, customer demand, and so on. Each of these values has a weight assigned to it—values of high importance have higher weights, while values of lesser importance have lower weights. The projects are measured against these values and assigned scores by how well they match the predefined values. The projects with high scores take priority over projects with lower scores. Figure 4-2 demonstrates the scoring model.
FIGURE 4-2 The weighted model bases project selection on predefined values.
Just like they sound, benefit/cost ratio (BCR) models examine the cost-to-benefit ratio. For example, a typical measurement is the cost to complete the project plus the cost of ongoing operations of the project product compared against the expected benefits of the project. For example, consider a project that will require $575,000 to create a new product, market the product, and provide ongoing support for the product for one year. The expected gross return on the product, however, is $980,000 in year 1. The benefit of completing the project is greater than the cost to create the product.
How long does it take the project to “pay back” its costs? For example, the AXZ Project will cost the organization $500,000 to create over five years. The expected cash inflow (income) on the project deliverable, however, is $40,000 per quarter. From here, it’s simple math: $500,000 divided by $40,000 is 12.5 quarters, or a little over three years to recoup the expenses.
This selection method, while one of the simplest, is also the weakest. Why? The cash inflows are not discounted against the time it takes to begin creating the cash. This is the time value of money. The $40,000 per quarter five years from now is worth less than $40,000 in your pocket today. Remember when sodas were a quarter? It’s the same idea. The soda hasn’t gotten better; a quarter is just worth less today than it was way back then.
See the video “Time Value of Money.”
Discounted cash flow accounts for the time value of money. If you were to borrow $100,000 from your uncle for five years, you’d be paying interest on the money, yes? (If not, you’ve got a terrific uncle.) If the $100,000 were invested for five years and managed to earn a whopping 6 percent interest per year, compounded annually, it’d be worth $133,822.60 at the end of five years. This is the future value of the money in today’s terms.
The magic formula for future value is FV = PV (1 + i)n, where
FV is future value
PV is present value
i is the interest rate
n is the number of time periods (years, quarters, and so on)
Here’s the formula with the $100,000 in action:
1. FV = 100,000(1 + 0.06)5
2. FV = 100,000(1.338226)
3. FV = 133,822.60
The future value of the $100,000 five years from now is worth $133,822.60 today. So how does that help? Now we’ve got to calculate the discounted cash flow across all of the projects up for selection. The discounted cash flow is really just the inverse of the preceding formula. We’re looking for the present value of future cash flows: PV = FV ÷ (1 + i)n.
In other words, if a project says it’ll be earning the organization $160,000 per year in five years, that’s great. But what’s $160,000 five years from now really worth today? This puts the amount of the cash flow in perspective with what the projections are in today’s money. Let’s plug it into the formula and find out (assuming the interest rate is still 6 percent):
1. PV = FV ÷ (1 + i)n
2. PV = 160,000 ÷ (1.338226)
3. PV = $119,561
So, $160,000 in five years is worth only $119,561 today. If we had four different projects with various times to completion and various costs, and we expected project cash inflows at completion, we’d calculate the present value and choose the project with the best PV, since it’ll likely be the best investment for the organization.
The net present value (NPV) is a somewhat complicated formula, but it allows a more precise prediction of project value than the lump-sum approach of the PV formula. NPV evaluates the monies returned on a project for each time period the project lasts. In other words, a project may last five years, but there may be a return on investment in each of the five years the project is in existence, not just at the end of the project.
For example, a retail company may be upgrading the facilities at each of its stores to make shopping and purchasing easier for customers. The company has 1000 stores. As each store makes the conversion to the new facility design, the project deliverables will begin, hopefully generating cash flow as a result of the project deliverables. (Uh, we specifically want cash inflow from the new stores, not cash outflow. That’s some nerdy accounting humor.) The project can begin earning money when the first store is completed with the conversion to the new facilities. The faster the project can be completed, the sooner the organization will see a complete return on its investment. In this example, an interest rate of 6 percent per year is assumed.
The following outlines how the NPV formula works:
1. Calculate the project’s cash flow per time unit (typically quarters or years).
2. Sum the cash flows for all time units; this yields the total cash flow.
3. Calculate the present value of each cash flow.
4. Sum the present value of each time unit; this yields the total present value.
5. Subtract the investment for the project from the total present value, this yields the NPV.
6. Take two aspirins.
7. Examine the NPV. An NPV greater than zero is good and the project should be approved. An NPV less than zero is bad and the project should be rejected.
When comparing two projects, the project with the greater NPV is typically better, although projects with high returns (PV) early in the project are better than those with low returns early in the project. The following is an example of an NPV calculation:
I bet you’re wishing you could try some of these out for yourself, right? You’re in luck. I’ve created for you a Microsoft Excel file called “Time Value of Money” that has a few exercises and all of the formulas to test your work. Enjoy!
The last benefit measurement method is the internal rate of return (IRR). The IRR is a complex formula used to calculate when the present value of the cash inflow equals the original investment. Don’t get too lost in this formula—it’s a tricky business, and you won’t need to know how to calculate the IRR for the exam. You will need to know, however, that when comparing multiple projects’ IRRs, projects with high IRRs are better choices than projects with low IRRs. This makes sense. Would you like an investment with a high rate of return or a low rate of return?
Constrained optimization methods are complex mathematical formulas and algorithms that are used to predict the success of projects, the variables within projects, and the tendencies to move forward with selected project investments. For the exam, thankfully, all you need to know about these selection methods is that they are not typically used for most projects, being instead utilized for multiphase, complex projects. The following are the major constrained optimization methods:
Linear programming
Nonlinear programming
Integer algorithms
Dynamic programming
Multiobjective programming
CERTIFICATION OBJECTIVE 4.02
The project plan is not a museum piece. You’ll use, wrinkle, update, and depend on your project plan like a Super Bowl coach depends on the playbook. 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. The project plan should be baselined to show the expectations for schedule, costs, and scope.
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 the 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 details, specify the project organization, and allow for growth in the plan through a disciplined change control process.
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 that advances the project toward completion. It is a thorough but concise collection of documents that will serve as a point of reference throughout the project execution, monitoring and controlling, and project or phase closing.
Provide documentation A documented project plan is needed for truly successful projects. They provide a historical reference and the reasons why decisions were made. A project plan must provide documentation of the assumptions and constraints influencing the project plan development. The size of the project, the application the project exists within, and enterprise environmental factors can all affect the depth of detail the project management plan provides.
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 regarding 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 as far as costs, scheduling, quality, and scope—and then see how these predictions compare with what is being experienced.
To develop the project plan effectively, the project manager and the stakeholders must be in agreement about 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. The project plan is created based on the organization’s project management methodology, the nature of the work to be implemented, and the overall scope of the project.
To develop the project management plan, you’ll need the project charter, enterprise environmental factors, organizational process assets, and outputs from other processes. Because project management planning is an iterative process, you won’t know everything as you begin the creation of the plan. Outputs from other processes, such as risk identification, will then require you to go back to your project management plan and update it accordingly. All of the ten knowledge areas (project integration management, scope, time, cost, quality, resources, communications, risk, procurement, and stakeholder management) will have processes that contribute to the comprehensive project management plan.
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-3 depicts the evolution of the planning to action process for a typical technology project. Once the business and the functional requirements have been established through iterations and revisions, the planning processes move into the specifics. Recall that the business requirements establish the project vision and 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.
FIGURE 4-3 The planning processes require documentation and a logical, systematic approach.
All of the inputs to the project plan should be readily available for the project manager, because 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 tools and techniques for developing the project management plan are simply expert judgment and facilitation techniques. Expert judgment isn’t just the project manager’s job alone; it involves several stakeholders: the project manager, the project team, stakeholders, and management 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 and time estimates; also influence the schedule, provide advice and opinions on risk, as well as expert judgment
Customer Objectives, quality requirements, expert judgment, and some influence over budget and schedule
Management Budget, resources, project management methodology, quality requirements, and project plan approval
Facilitation techniques require the project manager to direct and control the planning meetings and to use different techniques to encourage participation among the stakeholders participating in the planning. Common interpersonal and data-gathering techniques are interviews, focus groups, checklists, brainstorming, facilitation, conflict resolution, and good meeting management to help the stakeholders reach a consensus on what should be included in the project management plan.
The PMBOK Guide will repeatedly recommend using a PMIS. Here’s the scoop: The PMIS is an automated system to create, manage, and streamline the project management processes quickly. In the development portion of the project, the PMIS can be used to help the project management team create the schedule, estimates, and risk assessments, and to gather feedback from stakeholders.
The PMIS also includes a configuration management system. Configuration management is an approach for tracking all approved changes, versions of project plans, blueprints, software numbering, and sequencing. A configuration management system aims to do the following:
Manage functional and physical characteristics of the project deliverables
Control, track, and manage any changes to the project deliverables
Track any changes within the project
Allow the project management team to audit the project deliverables to confirm conformance to defined criteria for acceptance
Let’s say that, for the moment, the project manager and the project team have finished their project plan. Before the project team can set about implementing it, the plan must be approved, even though the project manager is accountable for the plan itself. 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.
The project plan is actually a collection of subsidiary plans and documents. Which ones, you ask? Well, let’s take a peek.
The scope management plan details how the project scope should 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 it is that the project scope will change, and if changes do occur, how drastic those changes may be. We’ll discuss scope management and change control in Chapter 5.
The requirements management plan works in tandem with the scope management plan. It defines how requirements will be identified, prioritized, documented, and then managed throughout the project. This plan also addresses the process for when changes are approved for a requirement and how the project team will manage new changes within the project. We’ll discuss scope management and change control in Chapters 5, 6, 7, and 12.
Changes are likely to happen within a project, so you’ll need a clearly defined plan that describes how to manage the changes. Ideally, all changes follow the change control process before they’re implemented in the project, but some changes do bypass the process, and this can mean corrective actions for the unapproved change. The change management plan also addresses the change control board (CCB), if your company uses one, and how stakeholders can submit and query changes to the project. Changes can affect the entire project, but they stem from four specific areas: scope, costs, schedule, and contract.
Configuration management ensures consistency and makes certain that the customer receives exactly what was expected and defined. Configuration management is concerned with controlling and documenting the features and functions of the product the project is creating. This plan defines the elements of the product that are configurable and that will require change control should the elements change or be desired to be changed. This plan is tightly linked to the change management plan and the project’s scope 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 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. Along with the schedule management plan, the project manager creates the schedule baseline. We’ll discuss the schedule management and schedule baseline in Chapter 6.
The project plan includes the project budget, the 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. This plan may be based on a range of acceptable variances and the expected response to variances over a given threshold. The cost management plan also includes a cost performance baseline to measure accuracy of estimates and budgeting. Variances are revealed by comparing the actual project costs to the original cost performance baseline. We’ll cover cost management in Chapter 7.
The quality management plan describes how the project will operate and meet its quality expectations. It details the quality improvement and quality controls, and how the project will map to the quality assurance program of the performing organization. The quality management plan provides information on the required resources and time to meet the quality expectations. We’ll discuss quality management in Chapter 8.
The project plan includes information on the resources needed to complete the project work. The resource management plan, however, provides details on how the project team members and other physical resources will be brought onto the project and released from the project. For example, a project may have a need for an electrical engineer and a set of electrical tools for three months during a ten-month project. The resources plan will determine how the engineer’s time and the tools are accounted for on the project and how the engineer can later be released and tools refurbished/repaired and returned to general stock; it also considers an accounting of the depletion of consumables when they’re no longer needed on the project. We’ll discuss resource management in Chapter 9.
It’s been said that project managers spend 90 percent of their time communicating. When you consider all of the different communication requirements for a project, it’s easy to believe that statistic. The communications management plan describes the required communications and how they will be fulfilled. It also 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 also includes accepted procedures to update, access, and revise communications between scheduled communication events. We’ll discuss communications in Chapter 10.
The risk management plan details 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.
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.
Stakeholders need to be engaged and included in communication throughout the project. This plan defines the approach the project manager and the project team will take with the project stakeholders. The stakeholder engagement plan defines the level of engagement, the interrelationships among stakeholders, communications requirements, and the timing of stakeholder engagement. This plan may contain sensitive information about the project stakeholders, so it’s often guarded rather than openly distributed to all of the project stakeholders.
Loads of project plans and documents are covered in this chapter. I highly recommend that you remember all of the project plans and documents. Knowing these documents will help you in all of the other knowledge areas, too, as you’ll see these plans there. Keep at it—if it were easy, everyone would do it.
The project management plan also includes four baselines. The most prevalent baseline is the project’s scope baseline. This baseline is made up of the project’s scope document, the project work breakdown structure (WBS), and the WBS dictionary. These three documents are used to compare what was promised to the project customer and what the project delivered. A difference between the two can mean quality errors or scope validation rejections.
The cost baseline and the schedule baseline help show project performance. The cost baseline reflects the project’s accumulative costs in relation to the project’s predicted cost. Like the cost baseline, the schedule baseline is also used to compare the project’s planned schedule against the actual progress. A difference between what was planned and what was experienced is called a variance. Variances mean that the project is losing money, is off schedule, or both.
The performance measurement baseline is a combination of the scope, schedule, and cost plans. Project measurement and performance are compared to the performance measurement baseline for an overall view of how well the project is doing. The integrated nature of time, cost, and scope are the reason for this baseline view; events in one of these three knowledge areas will likely directly affect the other two knowledge areas.
In addition to the compilation of project management subsidiary plans, you’ll rely on many project documents that help you plan and execute the project. These are not officially part of the project plan, but you should be familiar with them for your PMP exam.
Activity list This is a shopping list of all the activities the project team must complete to satisfy the project. This list is an input to the project network diagram.
Activity attributes Activities are documented in the activity list to include a coding structure, successor and predecessor activity identification, resource requirements, imposed dates, constraints, assumptions, and other pertinent information.
Assumption log This document clearly identifies and tracks all constraints and assumptions that are made in the project. All assumptions need to be tested for their validity, and the outcomes of the tests should be recorded.
Basis of estimates This document contains an explanation of how you and the project team arrived at the predicted cost and duration of the project.
Change log As changes to the project time, cost, or scope enter the project, they should be recorded with their status in the change log for future reference.
Cost estimates The cost of resources, including materials, services, and, when warranted, labor should be estimated.
Cost forecasts This document predicts what the project and its activities will cost based on current project performance. Forecasting may also include when the costs will happen.
Duration estimates This document includes a prediction of how long the project activities will take to complete.
Issue log Issues are conditions or situations that need decisions. They are recorded in the issue log, along with an issue owner designation, an issue date for resolution, and the eventual outcome of the issue.
Lessons learned register Lessons learned are recorded in the lessons learned register throughout the project.
Milestone list This is a listing of the project milestones and anticipated completion dates.
Physical resource assignments This document indicates when people and facilities are available or scheduled to work on the project. Materials, equipment, and facilities may need to be procured and scheduled in the project.
Project calendar You’ll need to define when the project work will take place. This includes any special accommodations, such as working weekends or after hours, holidays, or pauses in the project so as not to interfere with operations.
Project communications The project manager, team, and stakeholders will generate much information and communication throughout the project. This information should be organized and kept as part of the project.
Project schedule Predictions of when project events will happen, such as milestones accomplished, phases completed, and project closed.
Project schedule network diagram This diagram illustrates the flow of the project activities and reveals the project’s critical path and opportunities for float.
Project scope statement This document defines the project scope—major deliverables the project is required to create in order to satisfy the project objectives, along with the assumptions and constraints.
Quality control measurements Quality control is an inspection-driven process; quality control measurements are predefined values that signal problems with quality within the project deliverables. These can vary, based on the discipline the project centers on—for example, manufacturing or information technology.
Quality metrics These are predefined values that the results of project work should match in order to be acceptable for the project deliverables and project performance.
Quality report This report communicates how well the project is adhering to the quality requirements. These documents are ideal for repetitive activities to ensure that each activity is done identically to the other activities in the project. They are also ideal for safety procedures.
Requirements documentation These documents include a refined list of requirements of the product scope. They include everything the project is expected to create by the project closing.
Requirements traceability matrix This table identifies all of the project requirements, when the requirements are due, when the requirements are created, and any other pertinent information about the requirements.
Resource assignments These define who will do what in the project activities and may include a roles and responsibility matrix chart.
Resource breakdown structure This chart identifies the resources utilized in the project in each section of the WBS.
Resource calendars This document indicates when people and facilities are available or scheduled to work on the project.
Resource requirements The identification of what resources are needed to complete the project work is required as a supporting document for planning. This includes people, materials, equipment, facilities, and services.
Risk register A risk is an uncertain event or condition that can have a positive or negative effect on the project. All risks, regardless of their probability or impact, are recorded in the risk register, and their status is kept current.
Risk report This document communicates the status of risk events that are pending, passed, or are in motion within the project.
Schedule data This document stores raw data about the activities, project progress, and schedule information.
Schedule forecast This forecast predicts when events are going to happen in the project, such as milestone achievement, project phase completion, and project completion.
Stakeholder register All stakeholders, their positions within the project, contact information, and other characteristics are recorded in this document.
Team charter This document defines the team values, meeting guidelines, communication rules, and agreements among the project team.
Team resource assignments The team resource assignments list who will do what activities during project execution.
Test and evaluation documents These documents define what will be tested and evaluated during the project and the results of the testing.
CERTIFICATION OBJECTIVE 4.03
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 timing 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 scope, time, and cost baselines, prompt and accurate reactions are needed to adjust the slipping components of the project.
Executing the project plan includes the following:
Doing the work to satisfy the project objectives
Managing the project knowledge
Spending funds to satisfy the project objectives
Managing, developing, and leading the project team
Completing procurement requirements and managing the vendors and buyers
Acquiring, managing, and using resources such as materials, tools, facilities, and equipment to get the project work completed
Implementing risk responses
Incorporating approved changes into the project
Managing communications
Collecting project data on schedules, costs, quality, and overall project progress—and then reporting on these components
Managing the project stakeholders to keep them engaged and supportive of the project work
Completing lessons learned documentation
Things go awry. Corrective actions are methods the project manager and the project team can undertake to bring the project back into alignment with the project plan. For example, if a delay in the project work has 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 changes can be made in the schedule to complete the project on time. Solutions may include adding resources, fast tracking, changing the order of work packages, and so on. Corrective actions bring the project performance back in line with the project plan. In addition to communicating, project managers spend a great deal of their time applying corrective actions.
Do you wear your seatbelt? Take an umbrella when there’s a chance of rain? These are preventive actions. In project management, preventive actions are steps the project manager and the project team can take to help ensure that potential problems don’t affect the project. The project manager is taking action to make sure that future work is done properly and in accordance with the project management plan.
Sometimes the project team will screw up. Defect repair is the action required to fix the problem and to fix it correctly. The project manager will need to ensure that the actions taken to fix the problem have indeed corrected the defect and allowed the project to move forward as planned. Sometimes when a project team member faces a defect, he or she will rush through the defect repair, causing more errors and waste. The project manager must work with the project team to ensure that the defect is fixed efficiently and properly.
As the project team completes the work, the project manager will be faced, challenged, or even bombarded with change requests. Part of project execution is to evaluate the worthiness of the proposed change, feed the change through the change control system, and then act on the approval or denial of the change request. All change requests are documented for future reference, while approved changes are incorporated into the project plan. Change requests can include the following:
Any change that affects the project’s schedule, cost, or scope baseline
Contract changes from the vendor or client
Updates to project assets, such as the project plans or documents
Corrective action to bring the project work back into alignment with the project plan
Preventive action to take new steps to prevent problems from entering the project
Defect repair to fix a mistake in the project deliverables
Changes to project policies and procedures
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. The project manager will use several tools and techniques to execute the project plan.
It should come as no surprise that one of the leading tools and techniques required to direct and manage the project work is expert judgment. You’ll use your experience, savvy, and management abilities to communicate what actions need to take place in the project based on current project conditions. But it’s not all up to you—you’ll also rely on guidance and know-how from your project team, as they’re closest to the work being performed. You may also seek expert judgment for this process from lines of service within your company, consultants, professional organizations to which you subscribe, and project stakeholders.
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. It is a tool for, not a replacement of, the project manager. A PMIS can calculate schedules, costs, expectations, and likely results. It cannot, however, replace the expert judgment of the project manager and the project team.
The goal of the system is to automate, organize, and provide control of the project management processes. A typical PMIS software system offers the following:
Work breakdown structure creation tools
Calendaring features
Scheduling abilities
Work authorization tools
Earned value management controls
Quality control charts, program evaluation and review technique (PERT) charts, Gantt charts, and other charting features
Calculations for the critical path, earned value management (EVM), target dates based on the project schedule, and more
Resource tracking and leveling
Reporting functionality
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.
Project managers need to meet with the project team, vendors, managers from other business units in the organization, and other stakeholders as the work is being executed. Meetings help the project manager, the project team, and other key stakeholders come together and form a consensus on how the work in the project management plan is about to commence. As a project manager, you’ll go to lots of meetings to discuss the project work, ensure communication, and maintain stakeholder buy-in for the project. It’s best for all meetings to have an agenda and for someone to keep minutes to ensure that documentation exists regarding what’s to be discussed and what was accomplished in the meeting.
The project is being completed, and you have visible evidence that it is moving toward the desired future state. Inspections by the project manager and scope verification by the customer also prove the project team is completing work as planned. Status meetings provide opportunities for the project team members 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 scheduled 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, and then the project manager reviews the work and makes adjustments to bring the project back into alignment with the baselines created in the project plan. Several major components of project plan execution happen throughout project execution, not just at the end:
Project deliverables
Change requests
Project management plan updates for approved change requests
Work performance information
Project document updates
Project management plan updates
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 can also be measured as work results.
Executing the project plan will also create work performance data. Work performance data are observations, measurements, and facts that aren’t necessarily useful without some context. You’ll see coming up that work performance data is analyzed and processed into work performance information. Work performance information will then help you create work performance reports to communicate information about your project. A little tip—these happen in alphabetical order: data, information, and then reports.
Issues will happen throughout the project and these issues need to be documented and added to the project’s issue log. Whenever there are inconsistencies between what was planned and what was experienced, you’ve likely got an issue. You can sometimes refer to issues as risk events: problems, conflicts, gaps. When you document the issue in the issue log, you’ll also assign an issue owner and a target resolution date for the issue. Each issue in the log should include the following:
Classification of the issue
Person who identified the issue
Description of the issue
Priority level
Issue owner
Resolution date
Status
Final solution or outcome
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 resources. Change requests will predominantly trickle (or flood) in to the project manager during project plan execution. Change requests almost always affect one of four facets of a project:
Schedule This is 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 This involves 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 the entire 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 This is the most common instance of change. Stakeholders 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 details to determine the cost, time, and risks implied.
Combination This is a change made to the schedule, cost, or scope that may affect more than one facet of the project. This goes back to the idea of the “Triple Constraints of Project Management” and the project’s performance measurement baseline. For example, a change to finish the schedule more quickly may be reasonable if more resources are applied to the project. More resources, in turn, mean more money.
Change is expected in projects, though it’s not always welcome. When changes are approved, the project management plan should be updated to reflect the approved changes. This means that the project management scope baseline, schedule baseline, cost baseline, and the performance measurement baseline should all be updated to reflect the new project deliverables. You’ll also need to update the project activities lists to reflect the new activities the project changes will require, and, in turn, you’ll update the project network diagram. You may also need to update the assumptions log, activity list, lessons learned register, risk register, and the stakeholder register. Finally, changes can cause a ripple effect into the project management subsidiary plans and the project documents, which all need to be updated to reflect the changes in the project.
CERTIFICATION OBJECTIVE 4.04
When you manage a project, you’ll rely on your existing knowledge, based on your education and experience, but you might also learn new things to manage the project better. That’s what this new to PMBOK Guide, sixth edition, process is all about—managing both existing knowledge and new knowledge while managing the project. It’s not just about documenting information, but documenting knowledge to share with others openly in the current project, future projects, and in operations to support the solution the project creates.
There are two types of knowledge you’ll need to know for you exam:
Explicit knowledge Knowledge that can be quickly and easily expressed through conversations, documentation, figures, or numbers
Tacit knowledge Knowledge that’s more difficult to express, because it’s about personal beliefs, values, knowledge gained from experience, and know-how when performing a task
Though it’s tempting to lump this process into lessons learned, it’s actually more than documenting what was learned in the project. Lessons learned includes more explicit knowledge because it’s easily codified, but often lacks the deeper understanding that tacit knowledge provides. Tacit knowledge is more difficult to communicate through lessons learned, but it might be expressed by working alongside an experienced project team member or through in-depth training.
It’s difficult to set start and end points for managing knowledge within a project because a project is an ongoing, iterative activity. There are, however, several inputs that can help you manage knowledge within a project:
Project management plan All parts of the project management plan are inputs to managing knowledge.
Lessons learned register The lessons learned register defines what’s worked well in the project (and other projects in the organization).
Project team assignments Team assignments are made according to identified skills needed in the project and any skills that might be missing in the project.
Resource breakdown structure This visualizes the utilization of resources, but also what knowledge may be collectively used based on the composition of project team resources.
Source selection criteria When choosing a vendor, this component can help you identify what knowledge you’re obtaining from an outside resource.
Stakeholder register This help you understand what knowledge stakeholders bring to the project.
Understanding the project deliverables can help you ascertain knowledge. Project deliverables are the products, results, or services that are created as a result of the project work. Deliverables take knowledge to create; therefore, understanding the nature of the deliverables, how the deliverables were created, and what it will take to support and maintain the deliverables will help you better manage the knowledge surrounding project deliverables. While deliverables are usually things the customer of the project receives, they can also be documents and items from the project management plan.
As with most process inputs, knowledge management can also rely on enterprise environmental factors and organizational process assets. For enterprise environmental factors, the culture of the customers, organization, and stakeholders can contribute to knowledge management. You’ll also consider the geography of facilities and resources, rely on organization experts, and align with any legal and regulatory requirements. For organizational process assets, you’ll consider policies, processes, and procedures. Organizational process assets also include personnel administration, communication requirements, and formal knowledge-sharing procedures (such as learning reviews throughout the project).
One of the primary knowledge management tools you’ll use is your expert judgment. You’ll also work with people who are skilled in knowledge and information management. This may include trainer and instructors, technical writers, or people who are skilled in knowledge management software. Whatever approach you take to knowledge management, the goal is the same: to capture, document, and share knowledge in the project.
Knowledge management can also depend on the size of the project and the number of stakeholders involved. Projects with a large number of stakeholders will likely need a more formal knowledge management strategy than what’s required for a smaller project. Although expert judgement is an accessible tool for knowledge management, many other tools and techniques are available to consider, especially in a larger project:
Networking (live and web-based) Informal conversations and questions can occur live or via intranet or the Internet.
Communities of practice Sometimes called special interest groups, these communities can be live or web-based.
Meetings Both live and web-based meetings help inform and educate.
Work shadowing and reverse shadowing Following, or shadowing, an expert can help you learn new skills. In reverse shadowing, the expert follows you as you perform tasks to learn new skills; in this case, the expert can offer coaching or feedback at the end of the session.
Discussion forums and focus groups Like communities of practices, these can be live or online to help participants learn from others in an informal setting.
Training events Seminars, conferences, workshops, and training require participants to interact with one another.
Storytelling By using storytelling, team members and experts can help other learners better relate to tacit knowledge.
Creativity and ideas management techniques Blogs, journals, meeting scribes, and even software tools can help the project manager, team, and stakeholders capture their ideas from brainstorming and planning sessions.
Knowledge fairs and cafes Like a traditional fair, participants can move between “tents,” or stations, to learn quick lessons about a topic from a trainer. Knowledge fairs and cafes are a fun and quick way to learn lots of information, at a high-level, from a variety of speakers and on a variety of topics.
Another tool and technique in knowledge management is information management. Information management helps link people to the information they need. These tools are useful for providing fast and direct access to document explicit knowledge, such as adding or accessing information in the lessons learned register. Depending on the size of your organization, you may also have library services for information. Of course, a robust PMIS can include document and information management as well.
Information management is often driven by a tool such as software, but knowledge management shouldn’t be just data-driven. People have knowledge, not machines. Interaction with others and working process owners in the organization can often provide a richer, more meaningful way to learn and share information than a search engine. Face-to-face communication, active listening, facilitation, and leadership are all people skills. With such skills, people on both ends of the knowledge management equation will need political awareness of what’s being asked and what information is being provided.
Knowledge management creates three outputs, but these three items will be appended and updated throughout the project; they are not the final outputs of a simple process. As more knowledge becomes available, you’ll need to revisit knowledge management and then update these three items accordingly:
Lessons learned register This is an register of knowledge management that you’ll create early in the project, not at closing. Your lessons learned register can be a simple recording of what’s been learned in the project—or, more likely, you can create categories of learning, the effects of what was learned, and any recommendations you and the team have for different scenarios.
Project management plan updates You’ll see project management plan updates as an output of many processes, and knowledge management is no different. Note that when you need to change the project management plan, you’ll follow the project’s change management system.
Organizational process assets updates When a project creates new knowledge, that knowledge can be used not only in the current project, but in future projects and operations. New knowledge can be documented, shared, and implemented as a benefit of doing the current project.
CERTIFICATION OBJECTIVE 4.05
Sure, sure, it’d be nice to have a project plan and a team that follows orders and to have all the work requests completed on budget and on time every time—but this book isn’t fiction. One of the key activities for the project manager is to monitor the project team and control the work that they complete as part of the project. This is the hands-on portion of project management. By monitoring and controlling the project, you help stakeholders see where the project is and better understand what’s needed to keep the project in alignment with the project plan.
Monitoring and controlling the project work is a process that happens with project execution. There is overlap between the two process groups: the project is executed according to the plan, and the project is monitored and controlled according to the plan.
Throughout the project, you will monitor and control the process. You and the project team will consistently measure, examine, and inspect the project work to make certain it is correct and in accordance with the project plan. These iterative processes help ensure that the project is done properly and that you’re meeting objectives for the project stakeholders. To monitor and control the project, you’ll use several inputs throughout the life of the project:
Assumptions log
Basis of estimates
Cost forecasts
Issue log
Lessons learned register
Milestone lists
Quality reports
Risk register
Risk report
Schedule forecast
The project manager, with this list and the project management plan in hand, will examine what was promised in the plan and what’s been executed by the project team. This means the project manager needs work results to compare to the plan to ensure that the project is being completed as planned. The project manager will examine the forecasted schedule milestones, cost estimates, changes that have been approved for the project scope, and actual project deliverables as part of this process.
Recall that work performance data is just data—raw, unprocessed data, facts, and figures. Work performance data comes from executing processes. This data is shuffled over into the monitoring and controlling processes, where it is analyzed by comparing the raw data against what was planned and expected to ensure that what’s being created is actually what’s needed in the project.
Consider the metrics established in the project performance measurement baseline: time, cost, and scope. The data gathered will include facts about the percentage of activities complete, the running cost of project work, and the amount of time utilized to complete the project work. That data will then be compared against the goals for the project to determine whether the project is off schedule, off budget, or out of scope. Through analysis during monitoring and controlling, the gathered data becomes information. You’ll see more about work performance data and work performance information throughout this book and in the PMBOK Guide.
Three other inputs to monitoring and controlling the project are somewhat more flexible. First, if your project involves vendors, you’ll have contracts and agreements with them. When you create an agreement with the vendor, it will include terms and conditions that both parties must adhere to. Agreements could apply to a portion of the project, which means the subcontractor must abide by the terms of the contract, which should also support the goals of the project. In some instances, your company may be completing a project for a client, which will also require a contract that includes terms and conditions with which your company must comply in order for the project to be successful.
Other inputs for monitoring and controlling the project work are your enterprise’s environmental factors. You’ll use the tools required by your organization to track costs, schedule the project work, manage resources, and track the project’s performance. Enterprise environmental factors can also include the stakeholder’s expectations regarding what the project will create and how the project will perform. In addition, your organization may have rules regarding risk tolerance (which we’ll dive into in Chapter 11). Your industry may also be required to work with certain regulations in order to meet compliance requirements.
The final inputs, which you’ll see over and over, are organizational process assets. The organizational process assets you’ll consider for monitoring and controlling the project work are the policies, processes, and procedures unique to your organization. They can include how your organization manages finances, contracts, accounting codes, and human resources. Organizational process assets can also include tools and approaches used by your organization for reporting project status and conditions, issue management, defect management, and how you’ll track these items throughout the project.
Recall that the product scope is the vision of what the customer expects, while the project scope is the work completed by the project team to create the product scope. If the project team is completing activities outside of the project scope, they are not contributing to the project scope, which in turn means they’re creating a product scope that’s different from what the customer is expecting. Not a good thing. This leads to waste, frustration, delays, and unhappy customers—and unhappy project managers. We don’t want this. We want control and accuracy.
You may need help to monitor and control the project work, and this means working with experts. Specifically, you may call upon experts to help with earned value management (EVM), data analysis, cost and duration estimating, and trend analysis. Experts can also be from your discipline, including those who have insight into best practices, risk management, and even contract management. You’ll see that expert judgment is a common tool and technique used by many processes in a project.
Based on current conditions in the project, you may be able to forecast future performance and outcomes in the project. Analytical techniques can help the project manager and experts predict the likelihood of success, or failure, based on what’s happened in the project to date. For the PMP, you should be topically familiar with these analytical techniques:
Alternatives analysis When something goes awry in your project, you’ll need to consider the different corrective and prevent actions that you can take to fix the current problem, but also to prevent the problem from happening again in the project.
Cost-benefit analysis In monitoring and controlling, this involves the examination of the cost of the proposed corrective actions you may take and the consideration of the benefit these actions will bring to the project.
Earned value analysis This suite of formulas helps to show project performance on time and costs. We’ll discuss this in detail in Chapter 7, but know that the analysis of this data helps you gain insight to scope, schedule, and cost performance in the project.
Root cause and causal analysis This approach aims to determine what activities, people, organizational processes, or other factors are contributing to an effect in the project. Through analysis, which is really detective work, you’ll determine contributing causes and causal factors. This approach helps you identify actual causes, not just symptoms of the cause, so that you can take recommended corrective and preventive actions. One approach is to ask “why?” five times to help lead you to the root cause.
Trend analysis This analysis technique examines recurring problems, threats, and even opportunities, so that you can react to the situation based on the trends you’ve identified.
Variance analysis The difference between what was planned and what was experienced in the project will reveal a variance. Variance analysis can be performed on duration estimates, costs, resource utilization, overall project costs, technical performance, and other project aspects. You’ll use variance analysis throughout the project and in each knowledge area.
You’ll host meetings to discuss and review the status and conditions within the project. In these meetings, you’ll be reviewing the project, issues, and any problems that must be addressed. Most likely, you’ll be using expert judgment and meeting with team members and stakeholders. Recall that expert judgment is simply relying on a resource who is especially knowledgeable in one or more areas to help the project manager make the best decision. Expert judgment can come from many different sources:
Third-party consultants
Subject matter experts
Project team members
Stakeholders
Individuals within the organization who may not be directly affected by the project
As a project moves toward completion and the project manager monitors and controls the project, there will be evidence of the project’s success, failures, or, at a minimum, some results of the work as performed by the project team. Here’s the business you can expect to be tested on when it comes to the PMP exam:
Work performance reports The work performance data is analyzed and becomes useable work performance information. Then the work performance information is formatted, combined, and made readable in work performance reports. These are the project reports you’ll distribute to help management, customers, and stakeholders make decisions about project work and stay informed. We’ll talk more about reports and the communications management plan in Chapter 10.
Requested changes Yep, change requests can come out of monitoring and controlling. Change requests usually mean that the project scope will widen—although in some instances, the project scope may be trimmed due to lack of funds, time constraints, or other reasons. Change requests can also affect the schedule and costs. All requested changes should be documented and passed through integrated change control. Change requests can also include the following:
Recommended corrective actions Corrective actions must be followed to bring future project results into alignment with expected project performance. To implement these corrective actions, documented change requests are required.
Recommended preventive actions These actions ensure that mistakes don’t get repeated within a project. For example, if a piece of electrical equipment fails because it overheats, the project manager and the project team will take action to ensure that the equipment doesn’t overheat and delay the project work. To implement these actions, documented change requests are required.
Recommended defect repair Quality control is an inspection-driven process of finding mistakes or errors with the project work results before the customer does. When a defect is found, the project manager should document the defect and then, usually, ask the project team to fix the problem. To implement defect repairs, documented change requests are required.
Project management plan and project document updates When project work changes, the project manager must update the corresponding project documents and project plans. Updates can include updates to cost and schedule forecasts, the issue log, the risk register, and the lessons learned register. This is a recurring theme throughout project management, so you can bet dollars to donuts you’ll see this concept on your PMP exam.
CERTIFICATION OBJECTIVE 4.06
Integrated change control examines a change request to determine the total effect the change may have on all parts of the project: deliverables, project documents, and the project management plan. It determines the value of the change on the project to help determine whether the change should be approved, declined, or postponed. Integrated change control examines changes that stem from scope, cost, schedule, and contract, though scope changes are the most common (and we’ll discuss these in detail in Chapter 5).
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 enable the project to continue with the new changes incorporated into the project 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 scope to which requirements have been added but for which the schedule baseline has not been updated: The project’s end date will thus be sooner than what is possible, because the project baseline does not reflect the additional work that would 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 performance measurement baseline after a change. The completion of the project goes into the archives and can serve as historical information for future projects. In such cases, the historical information would be skewed, since it doesn’t 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. While change requests can start out with a verbal change request, the change request must be documented and entered into the change management system. 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-4 details integrated change control.
FIGURE 4-4 All change requests must pass through integrated change control.
Given that changes, or requests for change, are likely to happen during the project, what tools are available to evaluate and squelch or approve the proposed changes? And how can the project manager organize change requests in an orderly system so he is 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?
Many tools can be applied to requests for change: consistency, scope comparison, BCRs, risk analysis, and an estimate of the time and cost to incorporate the change, among others. The tools will guide the project manager, the project team, and the stakeholders through the process of approving and declining changes. The best approach for integrated change control is a constant, purposeful process of reviewing, considering, and evaluating, followed by a decision as to whether the change is needed.
A seemingly tiny change in costs, schedule, scope, or a contract can mushroom into large problems throughout the project. Integrated change control examines a change to determine what effect it will have on all parts of the project:
Project scope
Project schedule
Project costs
Project quality
Project resources
Project communications
Project risks
Project procurement
Project stakeholder management
A change control system (CCS) is a formal process of documenting and reviewing proposed changes. It establishes the flow of change from proposal to decision. The CCS process 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 CCS is a collection of documented activities, factors for decisions, and performance measurements—it is not a computer program. Although many electronic project management information systems offer a CCS, know that a CCS is a documented approach to change, not an automated approval structure.
Some organizations may have a CCS that is used across all projects and maps to common guidelines within the organization. If the performing organization does not have a CCS, it is the responsibility of the project manager and the project team to create one. A CCS is mandatory for effective project management.
Within a CCS may be a collection of management, key stakeholders, and project team members who review the changes for approval or denial. This group is defined in the project plan, and its roles and responsibilities are defined prior to project plan execution. Common names for the board include the following:
Change control board (CCB)
Schedule change control board
Technical review board (TRB)
Technical assessment board (TAB)
Engineering review board (ERB)
While the change control system addresses project changes, the configuration management system addresses changes to the product. The product—the thing the project is creating as the end result of the project—directly correlates to the project scope. Imagine a house construction project. If the homeowners want wood floors now instead of tile, or they decide to add a swimming pool, or they choose a different cabinet type, these are all changes to the product and need to be documented in the configuration management system. Changes to the product pass through the configuration management system to document and control the changes. Approved changes to the product scope will require a corresponding change to the project scope.
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 focuses on the project deliverables. In some organizations, configuration management is a part of the CCS, but in other industries, such as manufacturing, configuration management refers to the control of existing operations. In a general sense, configuration management consists of the following:
Configuration item identification The documentation and labeling of the features, characteristics, and functions of a product or service.
Configuration item status accounting The management and coordination of efforts to change the product or service. This includes status of proposed changes, both pending and implemented.
Configuration item verification and audit The process of documenting any changes to the product or service. It is the ongoing auditing of products and services to ensure their conformance to documented requirements, including tracking approved changes to the product’s features and functions.
The configuration management system and the change control system work together to control and identify changes within the project and product. All changes should be identified, documented, and then moved through the appropriate system. A decision-maker, or group of decision-makers, will determine whether the change is approved, declined, or deferred. You’ll also have to track changes and communicate the outcome to the appropriate project stakeholders. Change management happens throughout the project.
When it comes to making a decision about the change, I purposefully used the term “decision-maker.” This may or may not be the project manager; it could be the project sponsor, a change control board, or some other entity unique to your project and organization. Some organizations allot change power based on the price or impact of the change. For example, a change less than $10,000 and/or two weeks of duration could be within the power of the project manager to approve, decline, or defer. Changes above that threshold would be escalated to the CCB, PMO, or steering committee.
When making a decision about change, the group can use a voting approach, as discussed earlier, or a multicriteria decision analysis. A multicriteria decision analysis relies on a matrix of possibilities and outcomes for the change, and this provides a more systematic, analytical approach to the change decision. The matrix could have qualifiers or dequalifiers included, such as time, cost, amount of labor, risks, and any other factor the organization elects to use. Changes that exceed a qualifier or combination of qualifiers could be declined.
All changes can also move through alternative analysis as part of the research to determine whether or not the change can be implemented. Alternative analysis could determine whether the change is approved, declined, or needs to modified and negotiated before it can be approved. You’ll also implement a cost-benefits analysis of changes to analyze what the change will cost the project; this determines financial concerns, but also other costs such as labor, morale, and schedule.
Planning is iterative. Because a project rarely, if ever, happens exactly the way the project team and project manager planned it, 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. Planning also considers the effect of a risk that a new change can introduce. These adjustments will require the consideration of project activities, the critical path, resources, cost, sequence of activities, and other refinements to the project plan.
As the project follows the project plan and changes are presented, the project manager will implement integrated change control. Some changes will be denied or deferred, and archived for reference if needed. Other changes will be approved and factored into the project scope and have their schedules, costs, and risks documented and accounted for. All changes—approved, declined, and deferred—should be documented in a project’s change log for reference and supporting detail. The process of integrated change control is ongoing until project closure. Integrated change control can spur the following:
Approved change requests
Rejected change requests
Change log updates
Project management plan updates
Project scope statement updates
Approved corrective actions
Approved preventive actions
Approved defect repair
Project deliverables
CERTIFICATION OBJECTIVE 4.07
The project management plan defines what the project or phase is, how the project or phase will be completed, and finally—the good part—how the project or phase will be closed. The close project processes are activities that the project manager, the project management team, vendors, and the organization’s management will undertake to close out the project work. If a project has multiple phases, as most projects do, the closing processes will be implemented at the end of each phase.
The project manager must rely on several documents to prepare the close project processes. Specifically, the project manager relies on the project management plan to guide the required actions needed to close out the project. The project manager will review the results of the project with the project management plan to ensure that all of the requirements of the project have been met.
While project managers often think of closing as the end of the project, it also includes closing a phase. When closing a phase, the project manager should define the required phase exit criteria to move onto the next phase of the project. Administrative closure of a phase, and also at the conclusion of the project, require the following:
All documents updated
All issues resolved
Customer approved and accepted the deliverables
Vendors work formally accepted
Open claims are closed
Contractual information archived
Project records gathered for archive
Project or phase audit completed
Knowledge shared and transferred
Lessons learned identified
Project information archived to be part of the organizational process assets
Of course, other components contribute to the start of the closing processes:
Project charter The project charter defines what the project will accomplish, what constitutes project success, and who will sign off on the project completion.
Project management plan The project management plan includes the project scope, the project requirements, and expectations for the project objectives. When a project is being completed for another organization, the contract serves as a guide for how the project may be closed. The project plan may also reference the enterprise environmental factors to consider as part of project closing.
Project documents You may rely on some (or all) of the project documents to close the project. This can include the assumptions log, basis of estimates, change log, issue log, lessons learned register, milestone list, communications, quality control measurement, quality reports, requirements documentation, risk register, and any risk reports.
Deliverables The project has to create something, so it’s no surprise that the deliverables serve as input to the project closing processes.
Business documents The business case that justified the need for the project and the benefits management plan are referenced in closing.
Agreements Any contracts that need to be closed are included as part of the closing project phase or project process. The terms of contract closure are part of the contract.
Procurement documentation Along with the contract, all procurement documents are gathered and filed. This includes all vendor performance, contract change information, payments, and inspection results. Your project may also have “as-built” or “as-developed” plans, drawings, and documentation that also need to be archived.
Organizational process assets An organization may have procedures and processes that every project manager must follow to close a phase or project. These can include financial, reporting, and human resource obligations.
Formally closing the project or phase involves documenting and archiving all of the work necessary to formalize the closing process. The formal closing process updates the organizational process assets as the current information about the project’s performance, lessons learned, and other documents becomes future historical information. This requires more than just the project manager and involves the project team, project sponsor, key stakeholders, and vendors. The project manager may rely on expert knowledge for management control, audits of the project and vendors, legal and procurement issues, and any legislation or regulations that are required as part of project closing.
Administrative closure includes all of the following activities:
Collecting and assembling all project records
Analyzing the project’s success or failure
Gathering lessons learned documentation
Archiving project information for future reference
At the end of the project, project teams and the project manager are often rewarded. How will you reward yourself for finishing the project to pass your PMP exam? Set a reward for earning your PMP—you’ll deserve it!
Data analysis is also a result of closing your project. In data analysis, four techniques can be utilized:
Document analysis Review the available project documentation to help with lessons learned and knowledge sharing activities for future projects within the organization.
Regression analysis Study the interrelationships of the project variables to determine how the different components of the project affected one another. This understanding will help with future projects.
Trend analysis Identify trends in the project performance at closure so that the project manager and stakeholders can see what went awry and when. This also helps with future projects.
Variance analysis Analyze project variances in schedule, costs, scope, and performance to help the organization better understand root causes and plan more accurately in future projects.
The final closure of the project creates four official items for the project and the organization:
Project document updates All of the project documents are updated as needed to reflect the final results of the project. These should be stamped as “Final” so that future projects referencing the outcome of this project have a clear sense as to what the final results were.
Final product, service, or result transition This is the primary objective of the project that is then transitioned from being owned by the project to now being owned, managed, and maintained by the organization, the customer, or some other entity according to the project management plan.
Final project report This report summarizes the project or phase; defines the completed scope objectives and exit criteria, quality objectives that were met, and schedule results (including planned and actual dates); and summarizes the final product benefits, how the final product will or will not achieve the business benefits the project aimed to achieve, and the project risks, their outcomes, and how the risks were managed.
Organizational process assets updates Current project information becomes future historical information. Historical information is part of the organizational process assets. You’ll update, distribute, and archive a copy of the project documents, operational and support documentation, project and phase closure documentation, customer acceptance documentation, and the lessons learned register.
The two favorite days in a project are the day the project is launched and the day the project is closed. The business in between is project management. Should a project be cancelled before successfully reaching its objectives, the project manager should still move through the closing activities. This will include a report on why the project was terminated and what benefits were transitioned to the organization or customer. Projects can be cancelled for a number of reasons, and it’s important to document why the project ended, even if it the end wasn’t a happy one.
Project integration management is an ongoing process the project manager completes to ensure that the project moves from start to completion. It is the gears, guts, and grind of project management—the day-in, day-out business of completing the project work. Project integration management takes your project plans; coordinates the activities, project resources, constraints, and assumptions; and massages them into a working model.
Of course, project integration management isn’t an automatic process; it requires you, the project manager, to negotiate, finesse, and adapt to the project’s circumstances. Project integration management relies on general business skills such as leadership, organizational skills, and communication to get all the parts of the project working together.
The process of project management can be broken down into three chunks:
Developing the project charter and plan The project charter authorizes the project and names the project manager. You’ll usually create only one charter in a project, but an organization could also create a charter for each phase within a project. Project plan development is an iterative process that requires input from the project manager, the project team, the project customers, and other stakeholders. It communicates the details of how the project work will accomplish the project goals.
Directing and managing the project workAfter the plan has been created, the project execution processes authorize the work to begin, enabling the project manager to manage procurement and quality assurance, host project team meetings, and manage conflict between stakeholders. On top of managing all these moving parts, the project manager must actively work to develop the individuals on the project to work as a team for the good of the project.
Managing changes to the projectChanges can kill a project. Change requests must be documented and sent through a formal change control system to determine their worthiness for implementation. Integrated change control manages changes across the entire project. Change requests are evaluated and considered for impacts on risk, costs, schedule, and scope. Not all change requests are approved—but all change requests should be documented for future reference.
As the project moves from start to completion, the project manager and the project team must update the lessons learned register as part of managing project knowledge. The lessons learned serve as future historical information to the current project and to future projects within the organization. The project manager and project team should update the lessons learned at the end of project phases, when major deliverables are created, and at the project’s completion.
Project integration management relies on project plan development, project plan execution, and integrated change control. Integrated change control manages all the moving parts of a project.
Project integration management is a fancy way of saying that the project components need to work together—and the project manager sees to it that they do. Project integration management requires negotiation between competing objectives.
Project integration management calls for general management skills, effective communications, organization, familiarity with the product, and more. It is the day-to-day operations of the project execution.
On your exam, you’ll need to know that planning is an iterative process and that the results of planning are inputs to the project plan. The project plan is a fluid document, authorized by management, and it guides all future decisions on the project.
The project plan is a fluid work in progress. Updates to the plan reflect changes to the project, discoveries made during the project plan execution, and changes to the conditions of the project. The project plan serves as a point of reference for all future project decisions, and it becomes future historical information to guide other project managers. When changes occur, the cost, schedule, and scope baselines in the project plan must be updated.
All projects have one or more constraints in time, cost, and scope. Constraints are factors that can hinder project performance:
Time constraints include project deadlines, availability of key personnel, and target milestone dates. Remember that all projects are temporary: they have a beginning and an end.
Cost constraints are typically predetermined budgets for project completion. It’s usually easier to get more time than more money.
Scope constraints are requirements for the project deliverables, regardless of the cost or time to implement the requirements (safety regulations or industry mandates are examples).
Integrated change control is the process of documenting and controlling the features of a product, measuring and reacting to project conditions, and revisiting planning when needed.
Projects need change control systems to determine how changes will be considered, reviewed, and approved or declined. A change control system is a documented approach to how a stakeholder may request a change and then what factors are considered when approving or declining the requested change. There are four project change control systems: scope, schedule, cost, and contract.
Configuration management is part of change control. It is the process of controlling how the characteristics of the product or the services the project is creating are allowed to be changed.
If you’re serious about passing the PMP exam, memorize these terms and their definitions. For maximum value, create your own flashcards based on these definitions and review them daily.
activity attributes Activities that have special conditions, requirements, risks, successor activities, predecessor activities, coding structure, and other conditions should be documented.
activity list A shopping list of all the activities the project team must complete in order to satisfy the project. This list is an input to the project network diagram.
alternative analysis Data analysis technique used to consider the corrective and preventive actions to take in the project. You are analyzing the different options available.
assumption log A document that clearly identifies and tracks all constraints and assumptions that are made in the project. All assumptions need to be tested for their validity, and the outcome of the tests should be recorded.
basis of estimates Explanation of how the activity duration and cost estimates were created.
benefit/cost ratio Shows the proportion of benefits to costs; for example 4:1 would equate to four benefits and just one cost.
benefit measurement methods Project selection methods that compare the benefits of projects to determine into which project the organization should invest its funds.
benefits management The management and control of when the benefits of the project will become available. Some projects have benefits only once the project is complete; other projects will have intermittent benefits for the organization.
brainstorming People generating as many ideas a possible and then analyzing the ideas.
burndown chart A graph that tracks the project’s completeness, including scope changes, in a downward curve against the project timeline.
burnup chart A graph that tracks the project’s completeness in an upward curve against the project timeline.
causal analysis The analysis of why a problem exists to understand why the problem is happening. Root cause analysis defines the problem, or the effect you’re trying to resolve, and then identifies all of the causal factors that may be independently or collaboratively contributing to the defect.
change control board A group of decision-makers that reviews proposed project changes.
change control system A predefined set of activities, forms, and procedures that establishes how project change requests may proceed.
change log As changes to the project time, cost, or scope emerge during the project, they should be recorded with their status in the change log for future reference.
communications management plan Defines the required communications and how they will be fulfilled, and explains the methods used for gathering, storing, and dispersing information to appropriate parties. In addition, it maps out the schedule of when the expected communication needs will be met.
configuration management The control and documentation of the project’s product features and functions.
constraints Anything that limits the project manager’s options; time, cost, and scope are always project constraints.
contract A legally binding agreement between the buyer(s) and seller(s) that defines the roles and responsibilities of all parties in the agreement.
corrective actions Actions taken to correct problems and to ensure that the project work is in alignment with the project management plan.
cost-benefit analysis A data analysis technique used to examine of the cost of the proposed corrective actions you might take and the consideration of the benefits these actions will bring to the project.
cost management plan A subsidiary plan of the overall project management plan that defines how cost management will be planned, how costs will be structured, and how they will be controlled. This plan addresses 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.
defect repair Actions taken to fix defects within the project or product. Defect repair will also require validation that the defects were corrected properly.
development life cycle One or more phases of the project life cycle that define how the product, service, or result will be built The life cycle is typically a predictive or adaptive life cycle depending on the project and the enterprise environmental factors of the organization.
duration estimates The prediction of how long the project work will take to complete based on the resources available, nonworking hours, and other factors.
earned value management A suite of formulas used to measure the project’s overall performance for time, costs, and progress.
exit criteria Defines the criteria that must be present for the project to move from one phase to the next.
explicit knowledge Knowledge that can be quickly expressed through documentation, conversations, facts, and figures.
focus groups A meeting for stakeholders to have a conversation about the project goals, concerns, requirements, and other project information.
forecast Throughout the project, the project manager will create forecasts about the expected project’s completion date and projected project costs.
future value A formula used to predict the future value of a current amount of funds. The formula is Future Value = Present Value (1 + i)n, where i is the interest rate and n is the number of time periods.
historical information Any information created in the past that can help the current project succeed.
integrated change control The analysis of a change’s effect on all components of the project. It examines the proposed change and how it may impact scope, schedule, costs, quality, resources, communications, risk, procurement, and stakeholder management.
internal rate of return A benefit measurement formula to calculate when the present value of the cash inflow equals the project’s original investment.
interview Formal, direct discussion used in project integration management as part of the data gathering technique to create the project charter.
issue log Issues are conditions or situations that need decisions. They are recorded in the issue log, along with an issue owner designation, an issue date for resolution, and the eventual outcome of the issue.
knowledge management A systematic way of collecting, distributing, and storing useable knowledge in the project.
lessons learned register A log of the ongoing collection of documentation regarding what has and has not worked in the project; the project manager and the project team participate in lessons learned creation.
net present value A benefit measurement formula that provides a precise measurement of the present value of each year the project generates a return on investment.
payback period The duration of time it takes a project to earn back the original investment.
performance reports Formal reports that define how the project is performing with regard to time, cost, scope, quality, and other relevant information.
present value A benefit measurement formula to determine what a future amount of funds is worth today. The formula is Present Value = Future Value / (1 + i)n, where i is the interest rate and n is the number of time periods.
preventive actions Actions taken to ensure that potential problems don’t enter the project and that future project work is in alignment with the project management plan.
procurement documents All of the documents for purchasing, such as request for quotes, invitation to bid, request for proposal, and the responses, are stored as part of the project documentation.
procurement management plan Describes the procurement process, from solicitation to source selection. The plan may also include the requirements for selection as set by the organization.
project baselines Four baselines in a project are used to measure project performance: cost, schedule, scope, and the performance measurement baseline.
project charter A document that authorizes the project, defines the high-level requirements, identifies the project manager and the project sponsor, and provides initial information about the project.
project funding requirements In larger projects, this document identifies the timeline of when capital is required for the project to move forward. This document defines the amount of funds a project needs and when the project funds are needed in order to reach its objectives.
project integration management The art and science of ensuring that your project moves forward and that your plan is fully developed and properly implemented. Ten knowledge areas (project integration management, scope, time, cost, quality, resources, communications, risk, procurement, and stakeholder management) have processes that contribute to the comprehensive project management plan.
project knowledge management The project management process of managing all knowledge within the project. This includes refining the knowledge, documenting what was learned, making the information available to others, and archiving the documentation to be part of organizational process assets.
project management information system A PMIS is typically a software system, such as Microsoft Project, used to assist the project manager in managing the project.
project plan A comprehensive document comprising several subsidiary plans that communicates the intent and direction of the project.
proposal An exposé on ideas, suggestions, recommendations, and solutions to an opportunity provided by a vendor for a seller. A proposal includes a price for the work and documents how the vendor would provide the service to the buyer.
quality management plan Details the quality improvement, quality controls, and how the project will map to the quality assurance program of the performing organization.
regression analysis A forecasting tool used to measure and predict the link between two variables within a project. This analysis tool and technique examines a series of variables and their results to determine how closely related the relationship among the variables may be.
requirements management plan Defines how project requirements will be identified, prioritized, documented, and managed throughout the project.
requirements traceability matrix A table that identifies all of the project requirements, when the requirements are due, when the requirements are created, and any other pertinent information about the requirements.
resource breakdown structure A chart that identifies the resources utilized in the project in each section of the work breakdown structure.
resource calendar Indicates when people and facilities are available or scheduled to work on the project.
resource requirements A planning document that identifies what resources are needed to complete the project work. This includes people, materials, equipment, facilities, and services.
resources plan Details on how the project team members and other physical resources will be brought onto and released from the project.
reverse shadowing An expert follows someone learning to perform a skill to offer coaching or feedback at the end of the session.
risk An uncertain event or condition that can have a positive or negative effect on the project.
risk management plan Details the identified risks within the project, the risks associated with the constraints and project assumptions, and how the project team will monitor, react to, or avoid risks.
risk register All risks, regardless of their probability or impact, are recorded in the risk register, and their status is kept current in the risk register. Should a risk be identified, the issue log is also updated to reflect the risk event that is now a likely issue in the project.
roles and responsibilities Maps project roles to responsibilities within the project; roles are positions on the project team, and responsibilities are project activities.
schedule management plan 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 plan details the approval and accountability process for changes within the project.
scope management plan Details how the project scope should be developed, maintained, monitored, controlled, and validated.
scoring models A project selection method that assigns categories and corresponding values to measure a project’s worthiness of investment.
source selection criteria A predefined listing of the criteria to determine how a vendor will be selected—for example, cost, experience, certifications, and the like.
stakeholder management plan Defines the level of engagement, the interrelationships among stakeholders, communications requirements, and the timing of stakeholder engagement.
supporting detail for estimates The project manager should document how time and cost estimates were created.
storytelling By telling stories, team members can better understand tacit knowledge and interact with one another.
tacit knowledge Knowledge that’s more difficult to express because it’s about personal beliefs, values, knowledge gained from experience, and know-how when performing a task.
trend analysis Examines recurring problems, threats, and even opportunities so you can react to the situation based on the trends you’ve identified.
work performance data Raw data about the project work. This can include data on activities completed, costs, schedule, and other items measured for analysis.
work performance information Useable information based on the work performance data, which is analyzed and becomes work performance information.
work performance reports The communication devices used to share the work performance information with the appropriate stakeholders as defined in the project’s communications management plan.
work shadowing Following, or shadowing, an expert as they work to learn how to perform certain tasks.
The project charter authorizes the project and names the project manager.
The project charter is not authorized by the project manager, but by a person or party who has the power to grant the project manager the authority over the project resources.
The project charter defines the high-level requirements for the project and the conditions for success.
The project plan is a collection of subsidiary project plans.
The project plan communicates the intent of the project.
Project planning is an iterative process that may require updates to the project plan and other project documents.
The project manager directs and manages the work, while the project team executes the project plan.
The project team executes the project plan in order to create the requirements of the project.
The majority of the project’s time and budget are spent during project execution.
Team development and team management are executing processes.
The procurement requirements are completed during project execution.
New and existing knowledge from the project is documented, catalogued, shared, and archived.
Explicit knowledge is easy to convey through facts and figures.
Tacit knowledge is more difficult to convey because it’s based on personal beliefs, values, and experiences.
Monitoring and controlling processes happen in tandem with the project execution processes.
Earned value management (EVM) is a suite of formulas that can help the project management team monitor the project performance.
Expert judgment comes from someone with more experience, who helps the project manager make the best decisions.
Change requests include scope changes, recommended corrective actions, recommended preventive actions, and defect repairs.
Integrated change control examines the effect of a change on the entire project.
All changes from scope, schedule, costs, and contract must pass through integrated change control to determine whether the changes can be permitted in the project.
Changes approved, declined, or deferred are documented in the project’s change control log.
Closing the project or phase requires that the project manager follow the guidelines of the organization and the project plan.
The project’s contract documentation can help guide the procedures for closing a project or phase when the project is being completed by a vendor for a buyer.
Project documentation should be archived as part of project closure.
1. You are a project manager for your organization. Management has asked you to help determine which projects should be selected for implementation. In a project selection model, which of the following is the most important factor?
A. Business needs
B. Type of constraints
C. Budget
D. Schedule
2. Beth is the project manager of a software development project. She and her project team are done with a phase and Beth needs to make certain the lessons learned register is complete before moving the project onto the next phase. On any project, the lessons learned document is created by which of the following?
A. Customers
B. Project sponsor
C. Project team
D. Stakeholders
3. Your project is moving ahead of schedule. Management elects to incorporate additional quality testing into the project to improve the quality and acceptability of the project deliverable. This is an example of which one of the following?
A. Scope creep
B. Change control
C. Quality assurance
D. Integrated change control
4. You are the project manager of a new web site design project. There are 45 stakeholders with this project, and you are anticipating many change requests in the project. Which of the following is not true about change requests?
A. They happen while the project work is being done.
B. They always require additional funding.
C. They must be documented.
D. They can be requested by a stakeholder.
5. You are the project manager for a pharmaceutical company. You are currently working on a project for a new drug your company is creating. A recent change in a law governing drug testing will change your project scope. Since the project must be completed within two years, what’s the first thing you should do as project manager?
A. Create a documented change request.
B. Proceed as planned, since the project will be grandfathered in and unaffected by the new change in the law.
C. Consult with the project sponsor and the stakeholders.
D. Stop all project work until the issue is resolved.
6. During project execution activities, a project sponsor’s role in a functional organization can best be described as doing which one of the following?
A. Acting as a sounding board for the project stakeholders
B. Helping the project manager and stakeholders resolve any issues ASAP
C. Deflecting change requests for the project manager
D. Showing management the project progress and status reports
7. You are the project manager for the HALO Project. You and your project team are preparing the project plan. Of the following, which one is a project plan development constraint you and your team must consider?
A. The budget as assigned by management
B. Project plans from similar projects
C. Project plans from similar projects that have failed
D. Interviews with subject matter experts (SMEs) who have experience with the project work in your project plan
8. You are the project manager of HYH Project for your company, and you’re working with the project team and several key stakeholders to develop the project management plan. Which of the following is the primary purpose of the project management plan?
A. To define the work to be completed to reach the project end date
B. To define the work needed in each phase of the project life cycle
C. To prevent any changes to the scope
D. To define how the project is executed, monitored, controlled, and then closed
9. John is a new employee and he’s learning how to perform a task in your organization. Mary, a senior network engineer, is working with John to perform the new task. Rather than just show John the procedure, Mary is watching John and coaching him through the task. What is happening in this knowledge management activity?
A. Reverse shadowing
B. Project planning methodology
C. On-the-job training
D. Storytelling
10. You are examining the project management plan and its components with the project team. The team doesn’t understand why so much information is needed for the project. What is the difference between a project baseline and a project plan?
A. Project plans change as needed, while baselines change only at milestones.
B. Project plans and baselines do not change—they are amended.
C. Project plans change as needed, while baselines are snapshots of the project plan.
D. Baselines are control tools, while project plans are execution tools.
11. Which one of the following is not beneficial to the project manager during the project plan development process?
A. Gantt charts
B. PMIS
C. Project management methodology
D. Stakeholder knowledge
12. Yoli is the project manager for her company and she’s reviewing the project budget with management. Management is concerned about the capital expenses in the project, and they’d like more information about when Yoli will actually spend the project budget. Which one of the following represents the vast majority of a project’s budget?
A. Project planning
B. Project plan execution
C. Labor
D. Cost of goods and services
13. The project plan provides a baseline for several things. Which one of the following does the project plan not provide a baseline for?
A. Scope
B. Cost
C. Schedule
D. Control
14. Natasha is the project manager for her organization. She is meeting with her project stakeholders to review the project plan and the different elements she’ll use as part of project execution. Which of the following can best help Natasha during project execution?
A. Stakeholder analysis
B. Change control boards
C. PMIS
D. Scope verification
15. You are the project manager for your organization. When it comes to integrated change control, you must ensure that which one of the following is present?
A. Supporting detail for the change
B. Approval of the change from the project team
C. Approval of the change from an SME
D. Risk assessment for each proposed change
16. Jeff is the project manager of the Bridge Construction Project for his company. This project requires strict change control because of government regulations, the cost of the project deliverables, and the approved scope. The project plan provides what with regard to project changes?
A. A methodology to approve or decline CCB changes
B. A guide to all future project decisions
C. A vision of the project deliverables
D. A fluid document that may be updated as needed based on the CCB
17. You are the project manager for the DGF Project. This project is to design and implement a new application that will connect to a database server. Management of your company has requested that you create a method to document technical direction on the project and to document any changes or enhancements to the technical attributes of the project deliverable. Which one of the following would satisfy management’s request?
A. Configuration management
B. Integrated change control
C. Scope control
D. Change management plan
18. Baseline variances, a documented plan to management variances, and a proven methodology to offer corrective actions to the project plan are all part of which process?
A. Change management
B. Change control system
C. Scope change control
D. Integrated change control
19. One of the requirements of project management in your organization is to describe your project management approach and methodology in the project plan. You can best accomplish this requirement through which one of the following actions?
A. Establishing a project office
B. Establishing a program office
C. Compiling the management plans from each of the knowledge areas
D. Creating a PMIS and documenting its inputs, tools and techniques, and outputs
20. You have just informed your project team that each team member will be contributing to the lessons learned register. Your team does not understand this approach and wants to know what the documentation will be used for. Which one of the following best describes the purpose of the lessons learned documentation?
A. Offers proof of concept for management
B. Offers historical information for current and future projects
C. Offers evidence of project progression as reported by the project team
D. Offers input to team member evaluations at the project conclusion
21. Which one of the following is a formal document to manage and control project execution?
A. WBS
B. Project management plan
C. Organizational management plan
D. Work authorization system
22. Configuration management is a process for applying technical and administrative direction and surveillance of the project implementation. Which activity is not included in configuration management?
A. Controlling changes to the project deliverables
B. Scope verification
C. Automatic change request approvals
D. Identification of the functional and physical attributes of the project deliverables
23. You are preparing to enter into the project execution with your project team. As part of your preparation, you’ll rely on your project management plan and several tools and techniques. Which of the following contains parts of the project plan execution?
A. PMIS, WBS, and EVM
B. General management skills, status review meetings, and EVM
C. Project management methodology and the PMIS
D. General management skills, EVM, status review meetings, and interpersonal skills
24. You are the project manager of the GHQ Project for your company. Management has required that you utilize earned value management as part of your project and their enterprise environmental factors. EVM is used during the _______________.
A. Controlling processes
B. Executing processes
C. Closing processes
D. Entire project
25. You are the project manager for your organization. Management would like you to use a tool that can help you plan, schedule, monitor, and report findings on your project. Which of the following is the correct tool to use?
A. PMIS
B. EVM
C. Status review meetings
D. Project team knowledge and skill set
1. You are a project manager for your organization. Management has asked you to help determine which projects should be selected for implementation. In a project selection model, which of the following is the most important factor?
A. Business needs
B. Type of constraints
C. Budget
D. Schedule
2. Beth is the project manager of a software development project. She and her project team are done with a phase and Beth needs to make certain the lessons learned register is complete before moving the project onto the next phase. On any project, the lessons learned document is created by which of the following?
A. Customers
B. Project sponsor
C. Project team
D. Stakeholders
3. Your project is moving ahead of schedule. Management elects to incorporate additional quality testing into the project to improve the quality and acceptability of the project deliverable. This is an example of which one of the following?
A. Scope creep
B. Change control
C. Quality assurance
D. Integrated change control
4. You are the project manager of a new web site design project. There are 45 stakeholders with this project, and you are anticipating many change requests in the project. Which of the following is not true about change requests?
A. They happen while the project work is being done.
B. They always require additional funding.
C. They must be documented
D. They can be requested by a stakeholder.
5. You are the project manager for a pharmaceutical company. You are currently working on a project for a new drug your company is creating. A recent change in a law governing drug testing will change your project scope. Since the project must be completed within two years, what’s the first thing you should do as project manager?
A. Create a documented change request.
B. Proceed as planned, since the project will be grandfathered in and unaffected by the new change in the law.
C. Consult with the project sponsor and the stakeholders.
D. Stop all project work until the issue is resolved.
6. During project execution activities, a project sponsor’s role in a functional organization can best be described as doing which one of the following?
A. Acting as a sounding board for the project stakeholders
B. Helping the project manager and stakeholders resolve any issues ASAP
C. Deflecting change requests for the project manager
D. Showing management the project progress and status reports
7. You are the project manager for the HALO Project. You and your project team are preparing the project plan. Of the following, which one is a project plan development constraint you and your team must consider?
A. The budget as assigned by management
B. Project plans from similar projects
C. Project plans from similar projects that have failed
D. Interviews with subject matter experts (SMEs) who have experience with the project work in your project plan
8. You are the project manager of HYH Project for your company, and you’re working with the project team and several key stakeholders to develop the project management plan. Which of the following is the primary purpose of the project management plan?
A. To define the work to be completed to reach the project end date
B. To define the work needed in each phase of the project life cycle
C. To prevent any changes to the scope
D. To define how the project is executed, monitored, controlled, and then closed
9. John is a new employee and he’s learning how to perform a task in your organization. Mary, a senior network engineer, is working with John to perform the new task. Rather than just show John the procedure, Mary is watching John and coaching him through the task. What is happening in this knowledge management activity?
A. Reverse shadowing
B. Project planning methodology
C. On-the-job training
D. Storytelling
10. You are examining the project management plan and its components with the project team. The team doesn’t understand why so much information is needed for the project. What is the difference between a project baseline and a project plan?
A. Project plans change as needed, while baselines change only at milestones.
B. Project plans and baselines do not change—they are amended.
C. Project plans change as needed, while baselines are snapshots of the project plan.
D. Baselines are control tools, while project plans are execution tools.
11. Which one of the following is not beneficial to the project manager during the project plan development process?
A. Gantt charts
B. PMIS
C. Project management methodology
D. Stakeholder knowledge
12. Yoli is the project manager for her company and she’s reviewing the project budget with management. Management is concerned about the capital expenses in the project, and they’d like more information about when Yoli will actually spend the project budget. Which one of the following represents the vast majority of a project’s budget?
A. Project planning
B. Project plan execution
C. Labor
D. Cost of goods and services
13. The project plan provides a baseline for several things. Which one of the following does the project plan not provide a baseline for?
A. Scope
B. Cost
C. Schedule
D. Control
14. Natasha is the project manager for her organization. She is meeting with her project stakeholders to review the project plan and the different elements she’ll use as part of project execution. Which of the following can best help Natasha during project execution?
A. Stakeholder analysis
B. Change control boards
C. PMIS
D. Scope verification
15. You are the project manager for your organization. When it comes to integrated change control, you must ensure that which one of the following is present?
A. Supporting detail for the change
B. Approval of the change from the project team
C. Approval of the change from an SME
D. Risk assessment for each proposed change
16. Jeff is the project manager of the Bridge Construction Project for his company. This project requires strict change control because of government regulations, the cost of the project deliverables, and the approved scope. The project plan provides what with regard to project changes?
A. A methodology to approve or decline CCB changes
B. A guide to all future project decisions
C. A vision of the project deliverables
D. A fluid document that may be updated as needed based on the CCB
17. You are the project manager for the DGF Project. This project is to design and implement a new application that will connect to a database server. Management of your company has requested that you create a method to document technical direction on the project and to document any changes or enhancements to the technical attributes of the project deliverable. Which one of the following would satisfy management’s request?
A. Configuration management
B. Integrated change control
C. Scope control
D. Change management plan
18. Baseline variances, a documented plan to manage variances, and a proven methodology to offer corrective actions to the project plan are all part of which process?
A. Change management
B. Change control system
C. Scope change control
D. Integrated change control
19. One of the requirements of project management in your organization is to describe your project management approach and methodology in the project plan. You can best accomplish this requirement through which one of the following actions?
A. Establishing a project office
B. Establishing a program office
C. Compiling the management plans from each of the knowledge areas
D. Creating a PMIS and documenting its inputs, tools and techniques, and outputs
20. You have just informed your project team that each team member will be contributing to the lessons learned register. Your team does not understand this approach and wants to know what the documentation will be used for. Which one of the following best describes the purpose of the lessons learned documentation?
A. Offers proof of concept for management
B. Offers historical information for current and future projects
C. Offers evidence of project progression as reported by the project team
D. Offers input to team member evaluations at the project conclusion
21. Which one of the following is a formal document to manage and control project execution?
A. WBS
B. Project management plan
C. Organizational management plan
D. Work authorization system
22. Configuration management is a process for applying technical and administrative direction and surveillance of the project implementation. Which activity is not included in configuration management?
A. Controlling changes to the project deliverables
B. Scope verification
C. Automatic change request approvals
D. Identification of the functional and physical attributes of the project deliverables
23. You are preparing to enter into the project execution with your project team. As part of your preparation, you’ll rely on your project management plan and several tools and techniques. Which of the following contains parts of the project plan execution?
A. PMIS, WBS, and EVM
B. General management skills, status review meetings, and EVM
C. Project management methodology and the PMIS
D. General management skills, EVM, status review meetings, and interpersonal skills
24. You are the project manager of the GHQ Project for your company. Management has required that you utilize earned value management as part of your project and their enterprise environmental factors. EVM is used during the _______________.
A. Controlling processes
B. Executing processes
C. Closing processes
D. Entire project
25. You are the project manager for your organization. Management would like you to use a tool that can help you plan, schedule, monitor, and report findings on your project. Which of the following is the correct tool to use?
A. PMIS
B. EVM
C. Status review meetings
D. Project team knowledge and skill set