Developing the Project Plan

Overview

The main focus of this chapter is the creation of the project schedule, which is the next-to-the-last document we'll create in the overall project plan. The creation of the budget is the last task we'll do in the Planning process, and we'll cover that in Chapter 9, "Budgeting 101."

In this chapter we'll look at some methods for determining accurate project scheduling estimates and discover the critical path for the project. We'll then look at some examples of project schedules and ways to balance the resources needed for the activities of the project. In addition to covering scheduling, we'll discuss the quality plan. In this chapter, you will learn:

• Creating the project schedule
• Using the Program Evaluation and Review Technique
• Employing the Critical Path Method
• Displaying and reporting the project schedule
• Resource leveling
• Forming a quality plan

Creating the Project Schedule

The project schedule is a culmination of most of the project planning activities we've undertaken up to this point. Many of the things we've talked about, including the WBS, the task list, network diagrams (these show the activity dependencies), and resource needs, are linked to the project schedule.

Don't make the mistake of thinking that the project schedule is the project plan. The project plan includes the scope statement, the WBS, the communication plan, the risk management plan, and the project schedule. Other documents created along the way such as the resource lists are also part of the project plan.

The project plan is everything we've done up to this point plus the quality plan (we'll cover that later in this chapter) and the budget, which we'll cover in the next chapter. The project schedule is a part of the project plan and should not stand in as substitute for a project plan. The project schedule is an important part of the plan but it does not list project risks, quality requirements, or critical success factors. Substituting the schedule for the entire plan could lead to an unsuccessful outcome because you're only seeing part of the picture.

The budget is derived after the project schedule is completed. Since you don't yet know what the final schedule looks like, it's difficult to come up with a project budget. Say you're contracting resources to complete a particular activity. Until you finish the project schedule, you don't know exactly when the resources are needed, what other activities these resources may be dependent on, or how long you'll need the services of those resources. Most experienced project managers establish the project schedule before working on the budget.

Project Schedule Components

The project schedule details the activities and work of the project in a format that outlines the work from start to finish. The schedule is usually displayed in some type of graph or chart form. We'll look at different ways to display the schedule itself in a later section.

The project schedule is built primarily from the WBS, task list, and network diagram. Each activity is plugged into the project schedule according to the dependencies shown on the network diagram. Start and stop dates are entered for each activity, and resource assignments may be noted on the project schedule as well, depending on the format you're using for the project schedule.

In Chapter 5, "Breaking Down the Project Activities," we talked about estimating activity durations and came up with the number of work periods it takes to complete each activity. We derived these initial estimates by asking team members, subject matter experts, and so on. There is one more technique you can use to derive activity estimates, which we'll talk about in the next section, called the PERT method. (You can also use PERT to calculate total project duration.)

Typically, the project duration is calculated by plotting all the activities on the project schedule. Most project schedule software programs automatically calculate the duration of the project based on the difference between the start date of the first activity and the end date of the last activity. However, don't just simply go through your activity list and add up the number of work periods for each to come up with the total duration. That method would apply only if you were the sole resource on the project, and even then it still might not be accurate.

Some activities can be completed simultaneously, which means that the project schedule is not lengthened by the duration of the lesser activity. For example, if Activity A takes five days and Activity B takes three days, the total duration is five days because Activity B can be completed at the same time Activity A is being worked on. If Activity B were dependent on Activity A to finish before it could start, then the project schedule would be eight days. Let's look at one more method for making activity and project duration estimates.

Program Evaluation and Review Technique

The Program Evaluation and Review Technique (PERT) was developed by the United States Navy to help determine estimates for a complex engineering project called the Polaris Missile Program. The project team needed a way to estimate the project schedule and forecast it with a high degree of reliability. PERT was developed as a result and is widely used today.

Program Evaluation and Review Technique (PERT)

Uses the expected value, or weighted average, of critical path tasks to determine project duration by establishing three estimates: most likely, pessimistic, and optimistic.

We'll look at PERT in its simplest form here. Keep in mind that PERT is typically used for highly complex projects, but I think you'll find that the simplified technique described here can be used for any size project. It's a reliable and accurate technique for determining estimates.

The Big Three

PERT relies on three estimates for activity durations instead of one. The three estimates are used to calculate the weighted average, which then becomes the final activity duration. PERT calls this weighted average value the expected value.

expected value

The weighted average of PERT's three estimates: most likely, pessimistic, and optimistic.

The three estimates you'll use to calculate PERT are the optimistic estimate, the pessimistic estimate, and the most likely estimate. An explanation of each is shown below:

Optimistic estimate The optimistic estimate is the ideal. This is the estimate you're looking for; it assumes that everything goes according to plan, that no risks interfere with the activity, and that everything regarding this activity falls into place almost effortlessly.

Pessimistic estimate The pessimistic estimate is the opposite of the optimistic estimate. It assumes that almost everything that can go wrong will go wrong, that problems will come up, that resources won't cooperate, etc. The pessimistic estimate determines how long it will take to finish the activity assuming that problems will appear on the project.

Most likely estimate This estimate is a balance between the optimistic and pessimistic estimates. It is the most likely duration of the activity.

The PERT Formula

Now that you have those three estimates, what do you do with them? You guessed it—plug them into the formula. As stated earlier, expected value is the weighted average of the three time estimates. The formula to calculate expected value is as follows:

• Expected Value = (Optimistic + Pessimistic + (4 × most likely)) ÷ 6

Now let's look at an example. Suppose you're heading up a project to write a new software program for your company that automates the existing employee leave system. The employees will then be able to enter their leave requests online via a form on the intranet. This system also allows the management team to access leave reports and leave balances through one of the programs available on the system. You interviewed the lead programmer in the engineering department and asked for the three estimates you need to calculate expected value for this programming activity.

The lead programmer has given you these three estimates: optimistic is 45 days, pessimistic is 120 days, and most likely is 90 days. Let's plug them into the formula and see what we get.

• (45 + 120 + (4 × 90))÷ 6 = 87.5

The expected value for the programming activity is 87.5 days. Repeat this process for the remaining activities on your project to determine an expected value for each activity.

To calculate the total project duration, add up the expected value for each activity that has a Finish to Start dependency. The activities that do not have dependencies do not influence the project schedule, as we talked about in a previous section, so don't include them in your sum.

How Confident Are You?

Suppose you're very confident that the programming activity will take 87.5 days. The lead programmer who gave you this estimate is reliable and has consistently given you good estimates in the past. As a result, you might assign this estimate a 95 percent confidence factor, indicating that you (or the person you got the estimates from) are very confident that this activity will be completed in that amount of time. The confidence factor in this case is based on the experience level of the lead programmer who gave you the estimate. In this example, the lead programmer has performed similar activities to this one many times in the past and is confident in the estimates given for this activity.

confidence factor

The level of confidence you have in the estimate that's been calculated.

As you may have suspected, there is a mathematical way to calculate a confidence factor if you don't like using the experience (or seat-of-your-pants) method. This method gives even finer detail to the project estimates. This gets a little complicated and you do not have to go this extreme for small projects, but it's good information to know. Showing that you've calculated the confidence factor for your key project activities will also impress your boss at your next project meeting.

PERT calculations follow a bell curve. This means that most of the time the work will finish within plus or minus three standard deviations of the PERT calculation. Without getting too deep into mathematical and probability analysis, keep the following in mind:

• 99.73 percent of the time the work will finish within plus or minus three standard deviations.
• 95.44 percent of the time the work will finish within plus or minus two standard deviations.
• 68.26 percent of the time the work will finish within plus or minus one standard deviation.

Calculating Standard Deviation

Where does the standard deviation figure come from? I'm glad you asked. We'll calculate the standard deviation for our programming activity to plug into the confidence factors shown above. This will give us a range of days for each of the confidence factors to work from. Remember that in this example we're using days to calculate estimates. If we were using hours, minutes, months, etc. for estimates, the results of the calculation would be in the same increments of time we're using for estimates. The formula for standard deviation is as follows:

• (Pessimistic -Optimistic) ÷ 6
• Let's plug in our estimates:
• (120 -45) ÷ 6 = 12.5

Now we'll calculate the range of date estimates for the 95.44 percent confidence factor for this programming activity. Add two times the standard deviation (12.5 × 2 = 25) to the expected value and then subtract two times the standard deviation from the expected value to determine the estimate ranges. Our expected value is 87.5 days. Here is the formula to determine a 95.44 confidence factor for this activity:

• 87.5 + (2 × 12.5) = 112.5
• 87.5 -(2 × 12.5) = 62.5

Now we can say with 95.44 percent certainty that the programming activity will finish between 62.5 and 112.5 days.

The remaining confidence factors are calculated the same way. Use the number of standard deviations shown in the other confidence factors, adding and subtracting from the expected value to determine the confidence level.

Be aware that the higher the standard deviation for an activity, the higher the risk. The confidence measurement calculates the difference between the pessimistic and optimistic times, so the greater the spread, the higher the number. And of course the opposite is true—the lower the standard deviation, the lower the risk.

Getting to the Estimates

You will have to enlist the help of some other folks to get at the estimates you're going to use for PERT. There's no getting around it; when you work on projects, you're going to be involving people at all levels. None of what we've done or will do throughout the remainder of this book can be accomplished without the assistance and cooperation of a team of folks. Brush off those communication skills and get to know the team members and stakeholders.

Their opinions are valuable, and you're much more likely to gain their cooperation throughout the life of the project when you involve them in important project activities and decisions.

Unfortunately, there are no magic formulas for determining estimates. Many industries do have tools they use to help determine estimates, but these tools are usually based on predetermined criteria. If the project fits those criteria, the estimates are probably reliable. Generally speaking, rely on your subject matter experts to determine the estimates the way they are most comfortable, whether it's with an established tool or based on their own experience.

Calculating the Critical Path

The critical path is the longest full path on the project. This means that when the durations for each of the tasks or activities in one sequence (those that have dependencies) are added up from the beginning to the ending of the project, the path with the longest duration is the critical path. Any task on the critical path is called a critical path task.

critical path

The longest path through the project made up of activities with zero float.

Here we have an example critical path diagram for our software project.

Each task shown in the diagram has the duration of the task in the upper lefthand corner. The topmost path with activity numbers 1-2-3-7 has a duration of 100 days, and path 1-4-5-6-7 has a duration of 144 days. Path 1-4-5-6-7 is the longest full path on the project, so it is the critical path.

Float Time

You may be wondering how to determine which tasks are on the critical path. All tasks with zero float time are considered critical path tasks. Keep in mind that tasks with float time need to be completed in order to consider the project complete. The project wouldn't be considered complete if you finished all the critical path tasks but left the tasks with float time uncompleted. But tasks with float time are flexible. Their starting and ending dates do not influence the other project tasks, so you can schedule them when it's most convenient for the project team.

float time

The amount of time you can delay the early start of a task without delaying the finish date of the project.

Now let's look at how to calculate float time for the project tasks.

Critical Path Method

The Critical Path Method (CPM) is used to calculate the duration of the project. It calculates several dates for each task, including:

• Earliest start date
• Earliest finish date
• Latest start date
• Latest finish date

Critical Path Method (CPM)

Determines a single early and late start date and an early and late finish date for each activity on the project.

Once these dates are known for each task, float time can be calculated by subtracting the earliest start date from the latest start date. If the float time is equal to zero, the task is a critical path task.

Here are the steps we're going to use to complete the CPM calculation for our project, as shown in Table 8.1. Please note that these calculations do not take weekends or holidays into consideration.

1. List the tasks on the worksheet, referencing the task number, or WBS number, and task description.
2. List the dependencies of each task.
3. Record the duration of each task.
4. Calculate the early start date and early finish date for each task. The first task is the "Deliver hardware" task, and it's also where the project starts. The early start date for this task is the first day work can begin on the project. This project is scheduled to begin March 1. The first day is always considered day zero. To calculate the early finish date, take day zero plus the duration of the task (one day) to come up with an early finish date for the first activity, March 1. Since task number two is dependent on task number one, the early start date for task two is the day after task one finishes, or March 2. The early finish date for task two is 24 days after March 2. Counting March 2 as day zero makes the early finish date March 25, and so on for the other tasks. Watch out for task number four because its dependency is task number one, not task number three. That means the "Write programs" task (task number four) can start the day after task one finishes. Keep dependencies in mind when calculating the early start dates because tasks without dependencies can start anytime after the project has started.
5. Calculate the late start and late finish date for each task. To calculate this date start with last task listed. In this example, it's task number seven, acceptance. The early finish date for that task is July 22. Subtract the duration of the acceptance task from the earliest finish date, counting day one as zero, to find the late start date. This is the reverse of what we did to calculate the early dates. Continue in reverse order through the tasks, calculating the late finish and late start dates. Keep dependencies in mind here also since tasks without dependencies can start anytime prior to the end of the project. Task number three is a dependency to task number seven, which means that the latest finish date for task three, "Install hardware," must be one day prior to the latest start date for task seven. Task three is dependent on task two, so task two's latest finish date must occur one day prior to the latest start date for task three.
6. Calculate float for each task by subtracting the early start date from the late start date. If float time equals zero, the activity is on the critical path. Task numbers two and three both have float time, so they are not critical path tasks.
7. Determine the critical path for the project by adding up the duration of every activity with zero float. Do not add the duration times for activities with float since they are not critical path tasks.

The total duration for this project is calculated by adding up the duration for all tasks with zero float. Task numbers 1, 4, 5, 6, and 7 are the critical path tasks and their durations total 144 days. This calculation matches the network diagram constructed previously. Either of these methods can be used to calculate the critical path.

Most computer software programs designed to perform project scheduling calculate the critical path automatically. But it's important for you to understand what makes up the critical path, including the start and finish dates and float times. If you don't understand the basics behind the critical path, you won't be able to make schedule adjustments where needed, and you may not focus the team on the right tasks at the right times.

Working with the Project Schedule

You've calculated the start and finish dates, you know the critical path, and now it's time to assign resources to each of the tasks. At this point you'll put individual names with each task. You could add a column to the above spreadsheet showing the resource name, and you'd have all the information together in one place.

Now you have the perfect schedule for the project. The problem is you don't work in a perfect world. Some resources are not going to be available when the schedule says they're needed. Most folks don't like working through vacations and holidays, so we have to take business schedules and personal schedules into account. Or, the project duration may not be acceptable to management (99 percent of the time they think the project duration is too lengthy).

Let's look at some of the ways we can work with the project schedule to accommodate the situations stated above. First, we'll look at resource issue.

Resources

When creating the project plan, you'll need to know some basic information about the organization and about each of the resources you're planning to assign to the tasks in order to make adjustments to the schedule.

First, you need a calendar or list of all the company holidays. As you calculate the task start and end dates, take the company holidays into consideration by adding the additional days into the start and finish date calculations.

Next, you must determine the normal working hours for the organization. Do most employees work eight hours a day or do most employees work flexible schedules? Are all the resources full-time employees or are some part-time? You'll need the answers to these questions in order to adjust the schedule tasks according to your resource schedules.

Then, you need to determine individual vacation schedules. If one of your key team members is planning a wedding or taking some maternity leave, for instance, you'll need to adjust the schedule to accommodate these times.

If your project calls for the use of certain types of equipment at different times on the project, make certain you and the vendor are aware of the times the equipment is needed so that the schedule can stay on track. Don't forget to consider all the resources that could have a potential impact on the schedule. For example, your project may be dependent on the release of a new version of software or a new product release. You'll have to account for the release dates when building your project schedule.

Contingency Time

One of the things you should consider when constructing the project schedule is adding time to the tasks for unforeseen circumstances. Especially if your project has a lengthy duration, you should consider that employees sometimes get ill, have family emergencies, and so on that will require unscheduled time off from the project. Projects that fall into this category should also have contingency plans in place for key employees who may leave the project.

Even though most of us follow a regular eight-hour workday schedule (I know, many times it's more like 10 or 12 hours, but stay with me on this one), we aren't working the full eight hours on the project. There's e-mail to answer, phone calls to make, the game scores to discuss, and those vacation pictures to share with our teammates. Typically, you can count on people being productive about 80 percent of the time. Given a 40-hour workweek, you'll likely get 32 hours of productive work on the project. Don't forget to account for this time in the project schedule.

Administrative time is another time-killer that many project managers don't think about. For example, you'll require the team members to fill out status reports on a periodic basis, show up at team meetings, meet with users or stakeholders when appropriate, and meet with you one-on-one.

Keep in mind when calculating activity estimates and start and finish dates that personal and administrative time should be accounted for in the schedule. Many project managers add a percentage to the project schedule to account for this kind of time. The percentage used depends on the project manager and the type of project. My area of project management expertise is Information Technology, and I typically add an additional 15 percent of the total project duration to the project schedule to account for administrative activities such as status reports and meetings and unforeseen circumstances.

Adjusting Project Schedules

Remember that you have some flexibility regarding the start and stop dates for the noncritical path tasks. They can be scheduled when it's most convenient. This might be early in the project or late in the project, depending on when you have the resources available.

Critical path tasks can't be changed without impacting the project duration. If you lengthen a critical path task, you'll lengthen the project schedule. Sometimes you'll find that due to resource constraints or resource schedules you have no choice but to lengthen the project duration. This will require approval from the project sponsor and key project stakeholders.

After you've determined an initial schedule, chances are high that you'll have to make adjustments to it. Here are some tips to help you when adjusting the project schedule.

Estimates Stay within the most likely range duration estimates for your tasks. As you gain experience at this, you'll learn when you can use the optimistic estimate and when you should use the pessimistic estimate.

Task estimates and duration Task estimates and duration are not always the same. If you have more than one resource working on the task, the duration of the task is usually shortened So determine the number of resources you have available to perform the task, and adjust the schedule accordingly. For example, the duration for the "Write programs" task is 88 days. The expert who gave you the estimates assumed that only one person would be writing the code. If two people who have equal experience work on this task, the task can be shortened to 44 days.

Another situation to consider is tasks taking much longer to complete than what the estimate says. For example, the "Train users" task has a task estimate of 10 days. However, the users are over a three-state area, and one of your trainers will have to fly to each location to perform the training. That means that the duration of this task is actually longer than the 10 days stated on the schedule.

Shortening the Project Duration

"Is it really going to take that long?" is a question you're going to hear many times throughout your project management career. Sometimes the answer is, "Yes, it's going to take that long." When stakeholders or sponsors insist that the project duration be shortened, you can consider doing several things:

• Adding more resources. This may include hiring consultants, bringing in folks from other areas of the organization, or outsourcing some or all of the project tasks.
• Changing the scope of the project by breaking the deliverables into phases or paring down some of the deliverables.
• Rescheduling the tasks in a different order. Sometimes this will free up resources or better utilize the resources already assigned.
• Bringing in different resources. Perhaps you can find resources who are more qualified, more experienced, or better trained to work on the critical path tasks than the team members from the original plan.
• Asking for more time. This is another example of when you'll need to use those communication skills and negotiating techniques. Sometimes it's a matter of communicating the complexity of the project or explaining the processes the team must use in order to bring the project in according to the quality plan and stakeholder expectations. This option really doesn't shorten the project duration but it might be the only choice you have.
• Start two tasks at the same time that you previously scheduled to start independently. (We'll talk more about this technique in Chapter 11, "Controlling the Project Outcomes.")

Resource Leveling

One more set of adjustments you might need to make to the schedule involves resources. Once you've assigned names to the tasks, you may discover that some resources are used too much and some not enough. Still others may not be available when the schedule calls for them.

Resource leveling is a fancy term for distributing the workload among the team members. You'll smooth out the task assignments so that those folks who are overloaded have some of their work assigned to other members of the team who are underutilized.

resource leveling

Attempts to smooth out the resource assignments so that tasks are completed without overloading individuals and without negatively impacting the project schedule.

Mentoring is good technique to use when you're faced with this situation. I've had lead programmers on many different projects tell me that they are the only one in the whole wide world who can do the particular task you've assigned to them. Don't always fall for that line. You'll find many times that this a great opportunity for a senior programmer to mentor a junior programmer. By assigning the task to the junior team member (with the senior team member acting as mentor), the senior team member still has oversight control so they don't feel as though you've completely cut them off, and the junior member has an opportunity to learn something new. In the process you've successfully leveled the tasks. You can use this technique for partial tasks also. Consider splitting tasks so that the easier portions of the task can be assigned to a junior team member, leaving the more complicated portion for the senior team member. Use your judgment when using this technique, and do consider the validity of the senior team member's comments about the experience level needed to complete the task.

Schedule Display Options

There are several different methods you can use to display your project schedule. You can draw the schedule yourself using software tools or even pen and paper. However, most software scheduling programs give you all the display options we'll talk about here, so get familiar with your project scheduling tool and the different ways to display the schedule. The Gantt chart view and the calendar view were produced using Microsoft Project 2000. Keep in mind that these schedules do not take weekends or holidays into account, and I used the early start dates in the samples you'll see in the coming sections.

Gantt Chart

Gantt charts are easy-to-read charts that display the project schedule in task sequence and by the task start and finish dates. This image shows the tasks from the programming project plotted on a Gantt chart.

The black bar displayed on the first item, Software Project, indicates a milestone on the project. The Duration column for this entry shows 144 days, which is the total duration for the project. All the tasks listed under the milestone entry show their duration, and since these tasks are related to the milestone entry, all of their durations are summed to show the total duration.

It's also possible to add resource names to this view so that the name of the resource assigned to task appears at the end of the bar. That's a good first check you can perform when resource leveling because you can see at a glance whether certain resources are overloaded. Most software programs also have resource reports that will allow you to view, determine, and adjust resource loads.

You have several display options for the Gantt chart, including hours, days, weeks, and so on. Choose the appropriate view depending on the length and complexity of the project. If your project has a lengthy duration and you choose to display the Gantt chart in the week view, for example, you'll end up with pages and pages of printouts for the chart. Try to keep the Gantt chart printout to one or two pages for easy viewing by the stakeholders and sponsor. The project team may want a more detailed view, in which case you could print out all the pages and tape them together on a wall in the project team meeting room.

Calendar View

Calendar views are useful for small projects or as a high-level view for larger projects. Record the task start dates on the calendar, noting the resource assigned to the task and the expected duration. I like to note the finish date on the calendar as well.

You can also use calendar views to manage multiple small projects and to easily track resource usage among the projects or on an individual project. Use different colors to track the projects or resources.

The next image shows a sample portion of a calendar view of our project tasks. You can see that the "Deliver hardware" task begins on March 1 and is the only task on that day. March 2 shows two tasks beginning on that day, "Test hardware" and "Write programs."

Network Diagram

A precedence network diagram like the one shown here is another alternative to displaying the project schedule. This diagram typically shows the task number, the task descriptions, the duration, and the start and stop dates. The dependencies are shown as well.

Milestone Chart

Milestone charts can be used to display the project milestone and due dates. This is a good reporting tool to use in the project status meetings to show stakeholders the progress of the project. If you need a refresher on milestones charts, look at Table 5.2 in Chapter 5.

Quality Management Plan

Quality is another one of the triple constraints. It's important to the success of the project and helps determine whether the stakeholder expectations were met. Quality can be defined by the stakeholders, project team, project sponsor, industry standards, or a combination of these and more. If your project involves manufacturing a new instrument for heart surgeries, for example, there will likely be several quality standards you'll have to meet. The parts should measure a certain size or shape, the instrument must be constructed of a certain material at a certain grade or specification, and so on.

The quality plan concerns detailing the quality standards for the project and the quality criteria that are used to determine whether the deliverable is complete and correct. The next step is creating and documenting a plan to meet those standards. According to the Guide to the PMBOK, things you should consider before documenting the quality standards for your policy include the following:

Quality policy Your organization may have a quality policy guideline already established for projects the company undertakes. The quality policy is usually published by the executive management team, and it contains predetermined guidelines regarding quality standards for projects. Be certain to review your organization's quality policy so that you can incorporate important information from the policy into the project.

Standards Standards are guidelines, rules, or characteristics that should be followed. The organization itself may have quality standards you should know about, and the industry you're working in may also have standards that should be followed. Most industries do have standards, and it's up to the project manager to perform any research necessary to find out what those standards are.

Regulations Regulations are mandatory and usually result from governments, institutions, or organizations with the power to establish regulations within their own industry. Regulations require adherence, and you could face penalties, lawsuits, or fines if you do not comply. Be certain you're aware of any regulations that may impact your project.

Documenting the Plan

After you've determined any organizational standards or regulations that apply, it's time to document the quality criteria. The quality criteria are used to determine whether the deliverable is considered complete and correct according to the documented quality criteria. The example given earlier of manufacturing surgical equipment has several quality criteria, including size, type of material, shape, and weight. If these criteria are met, the deliverable is considered complete and correct.

The last piece of information that should go into your quality plan is the quality assurance process the project team will follow to assure that quality standards and criteria are being met. This includes processes used by the project manager, the project team, or vendors acting in an oversight capacity to assure that quality criteria are met. Our surgical equipment example may require inspection by an outside source to assure that the measurements and other quality factors are correct. We'll talk more about quality control, which works hand-in-hand with quality assurance, in Chapter 11, "Controlling the Project Outcomes."

When writing the quality plan, note any standards or regulations that may impact the project in the quality plan. If the regulations are lengthy or complicated, you could also reference where readers can find a copy of the standards without retyping all of them into the plan itself. You should also make the stakeholders and project team aware of any standards or regulations that impact the project. A sample quality management plan template is shown in Figure 8.1. Depending on the size of the project, you may choose to recap the project overview as shown in the first section or note where this information can be found.

While you don't really need approval of this plan, unless your organization requires it, it's a good idea to make certain that the project sponsor, the key stakeholders, and those responsible for the quality assurance process have reviewed the quality plan and agree to the criteria.

Cost of Quality

There's usually a trade-off where quality is concerned. It's going to cost you something—time or resources—to meet the quality standards for the project. This is known as the cost of quality. But if you don't meet the quality standards, it will cost you as well because the project will be considered unsuccessful.

cost of quality

The cost to produce the product or service of the project according to the quality standards set out in the plan.

Benefits of meeting the cost of quality include:

• Customer and stakeholder satisfaction is increased because the final product or service of the project will meet or exceed their expectations as a result of taking the time to measure and meet quality standards.
• Project teams will experience higher levels of productivity because the quality standards cause them to examine the methods and processes they're using to complete the work of the project for efficiency and effectiveness.
• The costs to produce the product of the project and administer project processes are lowered because of adherence to quality policies and standards.
• The project team will perform less rework because the quality results have been identified ahead of time and are being measured and monitored throughout the remaining project lifecycles.

Determining the Cost of Quality

Cost-benefit analysis is one of the techniques you can use to determine whether the cost of quality is worth the benefits received. The cost of rework alone can sometimes drive the need to adhere to the quality plan. Rework, as we've discussed previously, isn't much fun and is generally a demotivator, not to mention costly in terms of salary, equipment rentals, and so on.

Benchmarking is another technique used to determine the cost of quality. As an example, if the project team was able to write programming code for the print functions in a similar program on a previous project in three days, then three days becomes your benchmark measurement for this project.

benchmarking

Compares previous similar activities to the current project activities to provide a standard against which to measure performance.

There are three costs associated with the cost of quality that you should also be aware of:

Appraisal costs These include costs to examine the product or the process to make certain the requirements are being met. Inspection and testing costs are typical appraisal costs.

Prevention costs These are costs associated with keeping defects out of the final product. These costs are usually seen early on in the process and include such things as quality planning, training, and design review.

Failure costs These are the costs you'll incur when things don't go according to plan. When customer requirements are not satisfied while the product is still in the control of the organization, the expenses incurred are considered internal failure costs. External failure costs occur when the product has reached the customer and they let you know that the requirements have not been met. Internal failure costs aren't ideal, but it's much better to discover quality problems while the product is still in your control. We'll talk more about issues like these in Chapter 11.

You've heard this many times by now, but it's worth repeating. Document the quality plan and file it in a section of the project notebook devoted to the quality plan. The quality plan, as with all the other Planning documents, becomes part of the overall project plan, which we'll cover at the end of the next chapter.

Terms to Know

• benchmarking
• confidence factor
• cost of quality
• critical path
• Critical Path Method (CPM)
• expected value
• float time
• Program Evaluation and Review Technique (PERT)
• resource leveling

Review Questions

Answers