Make-or-Buy Analysis

The main decision you're trying to get to in make-or-buy analysis is whether it's more cost effective to buy the products and services or more cost effective for the organization to produce the goods and services needed for the project. Costs should include both direct costs (in other words, the actual cost to purchase the product or service) and indirect costs, such as the salary of the manager overseeing the purchase process or ongoing maintenance costs. Costs don't necessarily mean the cost to purchase. In make-or-buy analysis, you might weigh the cost of leasing items against the cost of buying them. For example, perhaps your project requires using a specialized piece of hardware that you know will be outdated by the end of the project. In a case like this, leasing might be a better option so that when the project is ready to be implemented, a newer version of the hardware can be tested and put into production during rollout.

Other considerations in make-or-buy analysis might include elements such as capacity issues, skills, availability, and trade secrets. Strict control might be needed for a certain process, and therefore, the process cannot be outsourced. Perhaps your organization has the skills in-house to complete the project but your current project list is so backlogged that you can't get to the new project for months, so you need to bring in a vendor.

Make-or-buy analysis is considered a general management technique and concludes with the decision to do one or the other.

Market Research

Market research can consist of a variety of methods to assist you or the team in determining vendors and their capabilities, and experience. My first go-to is using my favorite search engine. This can reveal information about experience, market presence, customer reviews, and more. Conferences are my second favorite method of discovering new vendors or new services from vendors I know. I am generally concerned with a few key items when engaging vendor services. First, I need to know their experience levels with my particular project or industry. I also want to know the team members they are proposing for the project and the depth and breadth of knowledge they have in the subject matter. I want to interview them before they start work on the project and learn the financial stability of the company.

Contract Types

A contract is a compulsory agreement between two or more parties and is used to acquire products or services from outside the organization. Typically, money is exchanged for the goods or services. Contracts are enforceable by law and require an offer and an acceptance. Generally speaking, most organizations require a more extensive approval process for contracts than for other types of procurements. For example, contracts may require a signature from someone in the legal department, an executive in the organization, the chief financial officer, the procurement director, and the senior manager from the department that is having the work performed.

There are different types of contracts for different purposes. The PMBOK^® Guide divides contracts into three categories:

• Fixed price
• Cost reimbursable
• Time and materials (T&M)

Within the fixed-price and cost-reimbursable categories are different types of contracts. You'll look at each in the following sections. Keep in mind that several factors will determine the type of contract you should use. The product requirements (or service criteria) might drive the contract type. The market conditions might drive availability and price—remember back in the dot-com era when trying to hire anyone with programming skills was next to impossible? Also, the amount of risk—for the seller, the buyer, and the project itself—will help determine contract type.

Procurement Management Plan

The procurement management plan details how the procurement process will be managed. The procurement management plan is based primarily on the project scope, budget, and schedule and it ensures that the resources you'll need throughout the project are available at the right time. According to the PMBOK^® Guide, it includes the following information:

• The types of contract to use
• The authority of the project team in the procurement process
• How the procurement process will be integrated with other project processes
• Where to find standard procurement documents (provided your organization uses standard documents)
• How many vendors or contractors are involved and how they'll be managed
• How the procurement process will be coordinated with other project processes, such as performance reporting and scheduling
• How the constraints and assumptions might be impacted by purchasing
• How independent estimates and make-or-buy decisions will be used during these processes and in developing activity resource estimates and the project schedule
• Coordinating scheduled dates in the contract with the project schedule
• How multiple vendors or contractors will be managed
• The coordination of purchasing lead times with the development of the project schedule
• The schedule dates that are determined in each contract
• Identification of prequalified sellers (if known)
• Risk management issues
• Procurement metrics for managing contracts and for evaluating sellers

The procurement management plan, like all the other management plans, is a component of the project management plan.

Procurement Statement of Work

A procurement statement of work (SOW) contains the details of the procurement item in clear, concise terms. It includes the following elements:

• The project objectives
• A description of the work of the project and any postproject operational support needed
• Concise specifications of the products or services required
• The project schedule, time period of services, and work location

The procurement SOW might be prepared by either the buyer or the seller. Buyers might prepare the SOW and give it to the sellers, who in turn rewrite it so that they can price the work properly. If the buyer does not know how to prepare an SOW or the seller would be better at creating the SOW because of their expertise about the product or service, the seller might prepare it and then give it to the buyer to review. In either case, the procurement statement of work is developed from the project scope statement and the WBS and WBS dictionary.

The seller uses the SOW to determine whether they are able to produce the goods or services as specified. In addition, it wouldn't hurt to include a copy of the WBS with the SOW. Any information the seller can use to properly price the goods or services helps both sides understand what's needed and how it will be provided.

Projects might require some or all of the work of the project to be provided by a vendor. The Plan Procurement Management process determines whether goods or services should be produced within the organization or procured from outside, and if goods or services are procured from outside, it describes what will be outsourced and what kind of contract to use and then documents the information in the SOW and procurement management plan. The SOW will undergo progressive elaboration as you proceed through the procurement processes. There will likely be several iterations of the SOW before you get to the actual contract award.

Make-or-Buy Decisions

The make-or-buy decision is a document that outlines the decisions made during the process regarding which goods and/or services will be produced by the organization and which will be purchased. This can include any number of items, including services, products, insurance policies, performance, and performance bonds.

Procurement Documents

Procurement documents are used to solicit vendors and suppliers to bid on your procurement needs. You're probably familiar with some of the titles of procurement documents. They might be called request for proposal (RFP), request for information (RFI), invitation for bid (IFB), request for quotation (RFQ), and so on.

Procurement documents should clearly state the description of the work requested, they should include the contract SOW, and they should explain how sellers should format and submit their responses. These documents are prepared by the buyer to ensure as accurate and complete a response as possible from all potential bidders. Any special provisions or contractual needs should be spelled out as well. For example, many organizations have data concerning their marketing policies, new product introductions planned for the next few years, trade secrets, and so on. The vendor will have access to this private information, and to guarantee that they maintain confidentiality, you should require that they sign a nondisclosure agreement.

A few terms that you should understand are used during this process; they are usually used interchangeably even though they have distinct definitions. When your decision is going to be made primarily on price, the terms bid and quotation are used, as in IFB or RFQ. When considerations other than price (such as technology or specific approaches to the project) are the deciding factors, the term proposal is used, as in RFP. These terms are used interchangeably in practice, even though they have specific meanings in the PMBOK^® Guide.

Procurement documents are posted or advertised according to your organizational policies. This might include ads in newspapers and magazines or ads/posts on the Internet.

Source Selection Criteria

The term source selection criteria refers to the method your organization will use to choose a vendor from among the proposals you receive. The criteria might be subjective or objective. In some cases, price might be the only criterion, and that means the vendor that submits the lowest bid will win the contract. You should use purchase price (which should include costs associated with purchase price, such as delivery and setup charges) as the sole criterion only when you have multiple qualified sellers from which to choose.

Other projects might require more extensive criteria than price alone. In this case, you might use scoring models as well as rating models, or you might use purely subjective methods of selection. I described an example weighted-scoring method in Chapter 2, “Creating the Project Charter.” You can use this method to score vendor proposals.

Sometimes, the source selection criteria are made public in the procurement process so that vendors know exactly what you want in a vendor. This approach has pros and cons. If the organization typically makes known the source selection criteria, you'll find that almost all the vendors that bid on the project meet every criterion you've outlined (in writing, that is). When it comes time to perform the contract, however, you might encounter some surprises. The vendor might have done a great job of writing the bid based on your criteria, but in reality they don't know how to put the criteria into practice. On the other hand, having all the criteria publicly known beforehand gives ground to great discussion points and discovery later in the procurement processes.

The following list includes some of the criteria you can consider using for evaluating proposals and bids:

• Comprehension and understanding of the needs of the project as documented in the contract SOW
• Cost, up front as well as total cost of ownership over the life of the product or service
• Technical ability of vendor and its proposed team
• Technical approach
• Risk
• Experience on projects of similar size and scope, including references
• Project management approach
• Management approach
• Business type and size
• Financial stability and capacity
• Production capacity
• Warranty or guarantee
• Reputation, references, and past performance
• Intellectual and proprietary rights

You could include many of these in a weighted scoring model and rate each vendor on how well they responded to these issues.

Change Requests

As you perform the Plan Procurement Management process, the project management plan, including its subsidiary plans, may require changes due to vendor availability, vendor capability, or the vendor's proposed solution, as well as cost and quality considerations. Change requests must be processed through the Perform Integrated Change Control process that we'll discuss in Chapter 10, “Measuring and Controlling Project Performance.”

Project Documents Updates

We've seen this output several times before. Some of the documents that may require updating as a result of the procurement processes are the requirements document, the requirements traceability matrix, the risk register, and others as needed.

Now we'll switch our focus to the human resource needs for the project and discuss the Plan Human Resource Management process next.

Project Management Plan

The project management plan consists of many of the subsidiary plans we have already discussed. During this process, you might want to consider several of them, including the stakeholder management plan and the stakeholder register. These documents describe the communication needs of the stakeholders. Another document to consider is the risk register. It lists the risk owners and their responsibility, so be certain to check this document when outlining roles and responsibilities. The change control and configuration management plans are important to understand as well as the project life cycle processes you'll use in each phase of the project.

Activity Resource Requirements

Human resources are needed to perform and complete the activities outlined in the activity resource requirements output of the Estimate Activity Resources process. During the Plan Human Resource Management process, you'll define those resource needs in further detail.

Key Enterprise Environmental Factors

Enterprise environmental factors play a key role in determining human resource roles and responsibilities. The type of organization you work in, the reporting relationships, and the technical skills needed to complete the project work are a few of the factors you should consider when developing the staffing management plan, which is a subset of the human resource management plan. Here is a list of some of the factors you should consider during this process:

Organizational Factors  Consider what departments or organization units will have a role in the project, the interactions between and among departments, organizational culture, and the level of formality among these working relationships.

Existing Human Resources and Marketplace Conditions  The existing base of human resources that are employed by, or available to, the organization should be considered when developing the human resource management plan. Marketplace conditions will dictate the availability of resources you're acquiring outside the organization and their going rate.

Personnel Policies  Be certain you have an understanding of the personnel policies in the organization regarding hiring, firing, and tasking employees. Other considerations include holiday schedules, leave time policies, and so on.

Technical Factors  Consider the types of specialized skills needed to complete the work of the project (for example, programming languages, engineering skills, knowledge of pharmaceuticals) and any technical considerations during handoff from phase to phase or from project completion to production.

Interpersonal Factors  Interpersonal factors have to do with potential project team members. You should consider their experience, skills, current reporting relationships, cultural considerations, and perceptions regarding their levels of trust and respect for coworkers and superiors.

Location and Logistics  Consider where the project team is physically located and whether they are all located together or at separate facilities (or cities or countries).

Political Factors  Political factors involve your stakeholders. Consider the amount of influence the stakeholders have, their interactions and influence with each other, and the power they can exert over the project.

In addition to these factors, you should consider constraints that pertain to project teams, including the following:

Organizational Structures  Organizational structures can be constraints. For example, a strong matrix organization provides the project manager with much more authority and power than the weak matrix organization does. Functional organizations typically do not empower their project managers with the proper authority to carry out a project. If you work in a functional organization as I do, it's important to be aware that you'll likely face power struggles with other managers and, in some cases, a flat-out lack of cooperation. Don't tell them I said this, but functional managers tend to be territorial and aren't likely to give up control easily. Here's the best advice I have for you in this case:

• Establish open communications early in the project.
• Include all the functional managers with key roles in important decisions.
• Get the support of your project sponsor to empower you (as the project manager) with as much authority as possible. It's important that the sponsor makes it clear to the other managers that their cooperation on project activities is expected.

Collective Bargaining Agreements  Collective bargaining agreements are actually contractual obligations of the organization to the employees. Collective bargaining is typically associated with unions and organized employee associations. Other organized employee associations or groups might require specialized reporting relationships as well—especially if they involve contractual obligations. You will not likely be involved in the negotiations of collective bargaining agreements, but if you have an opportunity to voice opinions regarding employee duties or agreements that would be helpful to your project or future projects, by all means take it.

Economic Conditions  These conditions refer to the availability of funds for the project team to perform training, hire staff, and travel. If funds are severely limited and your project requires frequent trips to other locations, you have an economic constraint on your hands.

Organizational Process Assets

You should consider four primary elements of the organizational process assets input during this process. They are organizational processes and standardized role descriptions, templates and checklists, historical information, and escalation procedures for the team and the organization as a whole.

The term templates, in this case, refers to documentation such as project descriptions, organizational charts, performance appraisals, and the organization's conflict management process. Checklists might include elements such as training requirements, project roles and responsibilities, skills and competency levels, and safety issues.

Organization Charts and Position Descriptions

We've all seen an organization chart. It usually documents your name, your position, your boss, your boss's boss, your boss's boss's boss, and so on. The important point to note about this tool and technique is that this information might be presented in one of three ways:

Hierarchical Charts  Hierarchical charts, like a WBS, are designed in a top-down format. For example, the organization or department head is at the top, the management employees who report to the organization head are next, and so on, descending down the structure. An organization breakdown structure (OBS) is a form of organization chart that shows the departments, work units, or teams within an organization (rather than individuals) and their respective work packages.

A resource breakdown structure (RBS) is another type of hierarchical chart that breaks down the work of the project according to the types of resources needed. (RBS also stands for risk breakdown structure, as you learned in the previous chapter.) For example, you might have programmers, database analysts, and network analysts as resource types on the RBS. However, they won't all necessarily work on the project team. You might have programmers reporting to the project team, the finance department, and the customer service department, for example. An RBS can help track project costs because it ties to the organization's accounting system. Let's suppose you have programming resources in the RBS at the junior, advanced, and senior levels. Each of these levels of programmer has an average hourly salary recorded in the accounting system that makes it easy for you to track project costs. Ten senior programmers, 14 advanced programmers, and 25 junior-level programmers are easy to calculate and track.

Matrix-Based Charts  Matrix-based charts are used to show the type of resources and the responsibility they have on the project. Many times a project manager will use a responsibility assignment matrix (RAM) to graphically display this information. A RAM is usually depicted as a chart with resource names listed in each row (for example, programmers, testers, and trainers) and project phases or WBS elements listed as the columns. (It can also be constructed using team member names.) Indicators in the intersections show where the resources are needed. However, the level of detail is up to you. One RAM might be developed showing only project phases; another RAM might show level-two WBS elements for a complex project, with more RAMs subsequently produced for the additional WBS levels; or a RAM might be constructed with level-three elements only.

Table 7.1 shows a type of RAM called an RACI chart for a software development team. In this example, the RACI chart shows the level of accountability each of the participants has on the project. The letters in the acronym RACI are the designations shown in the chart:

• R = Responsible for performing the work
• A = Accountable, the one who is responsible for producing the deliverable or work package and approves or signs off on the work
• C = Consult, someone who has input to the work or decisions
• I = Inform, someone who must be informed of the decisions or results

In this example, Olga is responsible for design, meaning she creates the software programming design document, but Rae is accountable and is the one who must make sure the work of the project is completed and approved. This is a great tool because it shows at a glance not only where a resource is working but what that resource's responsibility level is on the project.

Keep in mind that this is only one type of RAM chart. You may choose to use other designations in place of R-A-C-I.

Text-Oriented Formats  Text-oriented formats are used when you have a significant amount of detail to record. These are also called position descriptions or role-responsibility-authority forms. These forms detail (as the name implies) the role, responsibility, and authority of the resource, and they make great templates to use for future projects.

Networking

Networking in this process doesn't refer to the technical kind of networking with servers, switches, and fiber. It means human resource networking; that is, you know someone who knows someone and you can share information, learn new techniques, and interact with each other. According to the PMBOK^® Guide, several types of networking activities exist, including proactive communication, lunch meetings (my personal favorite), informal conversations (ah, the information you learn by hanging out at the espresso machine), and trade conferences (another favorite because they get you out of the office). Networking might help when you have a specific resource need on the project but can't seem to locate someone with that set of skills.

Organizational Theory

Organizational theory refers to all the theories that attempt to explain what makes people, teams, and work units perform the way they do. I'll talk more about motivation techniques (which are a type of organizational theory) in Chapter 8, “Developing the Project Team.” Organizational theory improves the probability that planning will be effective and helps shorten the amount of time it takes to produce the Plan Human Resource Management outputs.

Roles and Responsibilities

This output is the list of roles and responsibilities for the project team. It can take the form of the RAM or RACI chart I talked about earlier, or the roles and responsibilities can be recorded in text format. According to the PMBOK^® Guide, the following are the key elements you should include in the roles and responsibilities documentation:

Role  Describes the parts of the project for which the individuals or teams are accountable. This should also include a description of authority levels, responsibilities, and what work is not included as part of the role.

Authority  Describes the amount of authority the resource has to make decisions, dictate direction, and approve the work.

Responsibility  Describes the work the person is required to perform to complete the project activities.

Competency  Describes the skills and ability needed to perform the project activities.

Staffing Management Plan

The staffing management plan is a part of the human resource management plan that documents how and when human resources are introduced to the project and the criteria for releasing them. As with the other management plans I've discussed, the level and amount of detail contained in this plan are up to you. It can be formal or informal, and it can contain lots of detail or only high-level detail.

The staffing management plan should be updated throughout the project. According to the PMBOK^® Guide, you should consider several elements for inclusion in the staffing management plan, including the following:

Staff Acquisition  This describes how team members are acquired (from inside or outside the organization), where they're located, and the costs for specific skills and expertise. I'll talk more about staff acquisition in Chapter 8.

Resource Calendars  This describes the time frames in which the resources will be needed on the project and when the recruitment process should begin. The resources can be described individually, by teams, or by function (programmers, testers, and so on). Many staffing management plans use a resource histogram. This is usually drawn in chart form, with project time along the horizontal axis and hours needed along the vertical axis. Figure 7.1 is an example of a histogram that shows the hours needed for an asphalt crew on a construction project.

Staff Release Plan  Attention should be given to how you'll release project team members at the end of their assignments. You should have reassignment procedures in place to move folks on to other projects or back to assignments they had before the project. This reduces overall project costs because you pay them only for the time they work and then release them. You won't have a tendency to simply keep them busy between assignments or until the end of their scheduled end date if they complete their activities early. Having these procedures in place will also improve morale because everyone will be clear about how reassignment will occur. This should reduce anxiety about their opportunities for employment at the conclusion of the project or their assignments.

Training Needs  This describes any training plans needed for team members who don't have the required skills or abilities to perform project tasks.

Recognition and Rewards  This describes the systems you'll use to reward and reinforce desired behavior. I'll talk more about recognition and rewards in Chapter 8.

Compliance  If your project involves regulations that must be met or contractual obligations (such as union contracts), the staffing management plan should detail these and any human resource policies the organization has in place that deal with compliance issues.

Safety  Any safety policies and procedures that are applicable to the project or industry you work in should be included in the staffing management plan.

In the next section, we'll shift our focus once again but to a completely new topic. We'll look at quality and its effect on the project planning processes.

Standards and Regulations

The project manager should consider any standards, regulations, guidelines, or rules that exist concerning the work of the project when writing the quality plan. A standard is something that's approved by a recognized body and that employs rules, guidelines, or characteristics that should be followed. For example, the Americans with Disabilities Act (ADA) has established standards for web page designers that outline alternative viewing options of web pages for people with disabilities. PMI^® guidelines regarding project management are another example of standards.

Standards aren't legally mandatory, but it's a good idea to follow them. Many organizations (or industries) have standards in place that are proven best practice techniques. Disregarding accepted standards can have significant consequences. For example, if you're creating a new software product that ignores standard protocols, your customers won't be able to use it. Standards can be set by the organization, independent bodies, organizations such as the International Organization for Standardization (ISO), and so on. ISO develops and publishes international standards on various subjects, including mathematics, information technology, railway engineering, construction materials and building, and much more. There are more than 160 countries that have participating members (one member per country) in ISO's national standards institutes. ISO is not a government organization, but it works closely with government and the private sector to establish standards in many disciplines to meet the needs of business and society. You can find out more about ISO at www.iso.org. According to the PMBOK^® Guide, the Project Quality Management Knowledge Area is designed to be in alignment with the ISO.

A regulation is mandatory. Regulations are almost always imposed by governments or institutions such as the American Medical Association. Organizations might have their own self-imposed regulations that you should be aware of as well. Regulations require strict adherence, particularly in the case of government-imposed regulations, or stiff penalties and fines could result—maybe even jail time if the offense is serious enough. Hmm, it might be tough to practice project management from behind bars—not a recommended career move.

If possible, it's a good idea to include information from the quality policy (I'll cover this in the next section) and any standards, regulations, or guidelines that affect the project in the quality management plan. If it's not possible to include this information in the quality management plan, then at least refer to the information and where it can be found. It's the project management team's responsibility to be certain all stakeholders are aware of and understand the policy issues and standards or regulations that might impact the project.

Quality Policy

The quality policy is part of the organizational process assets input. It's a guideline published by executive management that describes what quality policies should be adopted for projects the company undertakes. It's up to the project manager to understand this policy and incorporate any predetermined company guidelines into the quality plan. If a quality policy does not exist, it's up to the project management team to create one for the project.

Cost-Benefit Analysis

You've seen the cost-benefit analysis technique before in the Initiating process group. In the case of quality management, you'll want to consider the trade-offs of the cost of quality. It's cheaper and more efficient to prevent defects in the first place than to spend time and money fixing them later. The benefits of meeting quality requirements are as follows:

• Stakeholder satisfaction is increased.
• Costs are lower.
• Productivity is higher.
• There is less rework.

The primary cost of meeting quality requirements for a project is the expense incurred while performing project quality management activities.

Cost of Quality

The cost of quality (COQ) is the total cost to produce the product or service of the project according to the quality standards and/or the cost to make a product or service that does not meet the quality requirements. These costs include all the work necessary to meet the product requirements whether the work was planned or unplanned. It also includes the costs of work performed due to nonconforming quality requirements, assessing whether the product or service meets requirements, and rework.

Three costs are associated with the cost of quality:

Prevention Costs  Prevention means keeping defects out of the hands of customers. Prevention costs are the costs associated with satisfying customer requirements by creating a product without defects. These costs are manifested early in the process and include aspects such as Plan Quality Management, training, equipment, documenting, and taking the time to do things right.

Appraisal Costs  Appraisal costs are the costs expended to examine the product or process and make certain the requirements are being met. Appraisal costs might include costs associated with aspects such as inspections and testing. Prevention and appraisal costs are often passed on to the acquiring organization because of the limited duration of the project.

Failure Costs  Failure costs are what it costs when things don't go according to plan. Failure costs are also known as cost of poor quality. Two types of failure costs exist:

Internal Failure Costs  These result when customer requirements are not satisfied while the product is still in the control of the organization. Internal failure costs might include corrective action, rework, scrapping, and downtime.

External Failure Costs  External failure costs, unfortunately, are when the customer determines that the requirements have not been met. Costs associated with external failure costs might include inspections at the customer site, warranty work, returns, liabilities, lost business, and additional customer service costs.

There are two categories of costs within COQ, the cost of conformance and the cost of nonconformance. Conformance costs are associated with activities undertaken to avoid failures, whereas nonconformance costs are those undertaken because a failure has occurred. All of the types of costs of quality we just covered fall into one of these categories. Table 7.2 is a quick reference.

Cost of quality is a topic you'll likely encounter on the exam. The following sections will discuss some of the pioneers in this field. To make sure the product or service meets stakeholders’ expectations, quality must be planned into the project and not inspected in after the fact.

Four people in particular are responsible for the rise of the modern quality management movement and the theories behind the cost of quality: Philip B. Crosby, Joseph M. Juran, W. Edwards Deming, and Walter Shewhart. Each of these men developed steps or points that led to commonly accepted quality processes that we use today and either developed or were the foundation for the development of quality theories such as Total Quality Management, Six Sigma, cost of quality, and continuous improvement. I'll also cover a quality technique called the Kaizen approach that originated in Japan and discuss Capability Maturity Model Integration.

Seven Basic Quality Tools

The term Seven Basic Quality Tools refers to seven techniques used to graphically display and diagnose quality issues. According to the PMBOK^® Guide, the Seven Basic Quality Tools are used in conjunction with the Plan-Do-Check-Act cycle we talked about in Chapter 1. The charts and diagrams within this tool you should understand for the exam are as follows:

• Cause-and-effect diagrams
• Flowcharts (also known as stratification charts)
• Checksheets
• Pareto diagrams
• Histograms
• Control charts
• Scatter diagrams

Cause-and-effect diagrams, also known as Ishikawa diagrams or fishbone diagrams, associate the source of the problem back to a root cause. We discussed cause-and-effect diagrams in Chapter 6.

Flowcharts are another tool associated with the Seven Basic Quality Tools that we discussed in Chapter 6. You will recall that a flowchart graphically depicts the relationships between and among steps. They typically show activities, decision points, and the flow or order of steps in a process. Flowcharts may point out possible quality issues and are a great tool for the project team to use when reviewing quality results. They can also be helpful in determining the cost of quality by estimating the expected costs of conformance and nonconformance. According to the PMBOK^® Guide, flowcharts are useful to understand the processes that exist within the Supplier, Input, Process, Output, Customer (SIPOC) model.

Checksheets are similar to checklists and are used during the quality processes to gather or verify data regarding quality problems. They are particularly useful when inspecting quality results.

We talked about histograms earlier in this chapter. I will cover Pareto diagrams, control charts, and scatter diagrams in more depth in Chapter 11, “Controlling Work Results.”

Benchmarking

Benchmarking is a process of comparing previous similar activities to the current project activities to provide a standard to measure performance against. This comparison will also help you derive ideas for quality improvements on the current project. For example, if your current printer can produce 8 pages per minute and you're considering a new printer that produces 14 pages per minute, the benchmark is 8 pages per minute.

Design of Experiments

Design of experiments (DOE) is a statistical technique that identifies the elements—or variables—that will have the greatest effect on overall project outcomes. It is used most often concerning the product of the project but can also be applied to project management processes to examine trade-offs. DOE designs and sets up experiments to determine the ideal solution for a problem using a limited number of sample cases. It analyzes several variables at once, allowing you to change all (or some of) the variables at the same time and determine which combination will produce the best result at a reasonable cost.

Statistical Sampling

Statistical sampling involves taking a sample number of parts from the whole population and inspecting them to determine whether they fall within acceptable variances. We will discuss statistical sampling in more detail in Chapter 11, “Controlling Work Results.”

Additional Quality Planning Tools

The PMBOK^® Guide lists the following tools as part of the additional quality planning tools tool and technique:

• Brainstorming
• Force field analysis
• Nominal Group technique
• Quality management and control tools

We covered brainstorming and the Nominal Group technique in Chapter 6. Let's briefly look at the remaining tools next.

Force field analysis is a method of examining the drivers and resistors of a decision. You could use the old T-square approach and list all the drivers down the left column and all the resistors in the right. Determine which of the elements in the list are barriers and which are enablers to the project. Assign a priority or rank to each, and develop strategies for leveraging the strengths of the high-priority enablers while minimizing the highest-ranked barriers.

Quality management and control tools consists of several tools, including affinity diagrams, process decision program charts, interrelationship digraphs, tree diagrams, prioritization matrices, activity network diagrams, and matrix diagrams. We will cover each of these in Chapter 9.

You should memorize the names of these additional Plan Quality Management tools for the exam, but more important, you should know both the names and concepts of the other tools and techniques I talked about earlier in this chapter, as well as when to use them.

Quality Management Plan

The quality management plan describes how the project management team will carry out the quality policy. It should document the resources needed to carry out the quality management plan, the responsibilities of the project team in implementing quality, and all the processes and procedures the project team and organization should use to satisfy quality requirements, including quality control, quality assurance techniques, and continuous improvement processes. This plan should also address the quality standards for both the project and the products produced by the project. As with other plans, you should consider project scope, risks, and requirements when writing this plan so that quality defects can hopefully be avoided, also allowing you to have better control of the cost of quality.

The project manager, in cooperation with the project staff, writes the quality management plan. You can assign quality actions to the activities listed on the WBS based on the quality plan requirements. Isn't that WBS a handy thing? Later in the Control Quality process, measurements will be taken to determine whether the quality to date is on track with the quality standards outlined in the quality management plan.

Process Improvement Plan

The process improvement plan focuses on finding inefficiencies in a process or activity and eliminating them. The idea here is that if you're doing activities or performing processes that don't add any value, you'll want to either stop doing what you're doing or modify the process so that you are adding value. You should note that the process improvement plan is a subsidiary plan of the project management plan. Some of the elements you should consider when thinking about process improvement are the process boundaries, which describe the purpose for the process and its expected start and end dates; the process configuration so that you know what processes are performed when and how they interact; the process metrics; and any specific elements you want to target for improvement.

Quality Metrics

A quality metric, also known as an operational definition, describes what is being measured and how it will be measured during the Control Quality process. For example, let's say you're managing the opening of a new restaurant in July of next year. Perhaps one of the deliverables is the procurement of flatware for 500 place settings. The operational definition in this case might include the date the flatware must be delivered and a counting or inventory process to ensure that you received the number of place settings you ordered. Measurements of this variable consist of actual values, not “yes” or “no” results. In our example, receiving the flatware is a “yes” or “no” attribute result (you have it or you don't), but the date it was delivered and the number of pieces delivered are actual values. Failure rates are another type of quality metric that is measurable, as are reliability, availability, test coverage, and defect density measurements.

Quality Checklists

If you're like me, you start your day at the office with a big to-do list that has so many items on it you won't be able to finish them all. Nevertheless, you faithfully write the list every day and check off the items that you accomplish throughout the day. Checklists are like this in that they provide a means to determine whether the required steps in a process have been followed. As each step is completed, it's checked off the list. Checklists can be activity specific or industry specific and might be complex or easy to follow. Sometimes, organizations might have standard checklists they use for projects. You might also be able to obtain checklists from professional associations.