Other PlanningProcesses

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE

• 1.9 Given a proposed scope definition and based on the scope components , assess the feasibility of the project and the viability of a given project component against a predetermined list of constraints.
• 2.4 Given a team-building scenario, including a scope definition and work breakdown structure (WBS), identify selection criteria for particular team members . Demonstrate the ability to ask interview questions that will assist the team selection process.
• 2.19 Demonstrate the ability to identify project team organization roles and responsibilities required for the execution of the project.
• 2.22 Demonstrate an understanding of the components of a project quality management plan (e.g., measured quality checkpoints, assignments for architectural control, systems test, and unit tests, user sign-off, etc.).
• 2.23 Demonstrate the skills to develop a quality plan.
• 2.24 Demonstrate the ability to perform risk assessment and mitigation (given a scenario including the appropriate project documentation).
• 2.25 Demonstrate the ability to create a project communications plan that clearly indicates what needs to be communicated during a project, to whom, when, and how (using formal and informal approaches).
• 2.31 Be able to secure staffing commitments and resolve staffing issues.
• 3.21 Recognize the relevance of the organization s quality policy to project quality.

It might appear that we should be done with planning and ready to move into project execution. We have planned our scope, cost, and schedule. What more could there be?

Although scope, schedule, and cost are the foundation of project planning, several other components of project management need to be addressed in the planning process. For instance, human resources planning means deciding how to staff your project ”acquiring the people you need to complete the project. Quality planning involves setting the project quality standards. It includes determining what quality variables you will measure and how you will measure them. Risk planning identifies possible risks to your project, quantifies the magnitude and probability of these risks, and defines how to respond if the risk occurs. Communications planning is necessary to identify what people or groups will need information about your project and how you will provide information. Finally, procurement planning becomes necessary if you will be purchasing goods or services for your project from outside vendors . It covers defining a statement of work and vendor selection criteria, as well as the various types of contracts. We ll discuss all of these planning methods in this chapter.

Human Resources Planning

In Chapter 5 we covered resource planning as a process to identify the costs of your project. At that point, we identified human resources primarily by job title; we did not have actual people matched to each deliverable . Before work can actually begin on the project, you need to replace the generic job title requirements you identified with the names of real people. You also need to address how you will organize and manage your team through the completion of the project.

Human resources planning includes defining team member roles and responsibilities, establishing an appropriate structure for team reporting, securing the right team members , and bringing them on the project as needed for the appropriate length of time. Human resources planning results are achieved through the development of an organization plan coupled with the acquisition of the staff necessary to complete the project.

Organizational Planning

Managing a group of people to complete a unique product within a limited time frame can be very challenging. Each team member needs to have a clear picture of their role on the team and what they are accountable for.

Real World Scenario ”Building a Rocket Using a Geographically Dispersed Team

Recently one of us took a college class in organizing technical projects. The instructor for that class had as his day job a position as a senior systems analyst for a large aerospace contracting firm. Let s call this instructor Jim, so we have a common reference name .

Jim s entire premise for the class was that it s very difficult to put together a group of people ” especially highly specialized aerospace engineers ”some of whom live in California, others overseas, still others in Colorado, and so forth to design, build, assemble, and deploy a rocket. Basically, his points were limited but salient:

• You have to really understand the project thoroughly. All team members have to be clear about what it is you re building. There can be no question about vision.
• With big projects you use the eat an elephant one bite at a time principle, breaking the project into manageable chunks and grouping the team members together that pertain to the chunk you re interested in talking about today.
• There is a center point to all projects. You can t, for example, design the fuselage first, then design an engine to fit around it. All components of a rocket project center on the engine itself. Thus, the engine is a well-known, well- understood quantity ”the rest of the parts are designed around it. We believe this is probably true for the vast majority of IT projects.
• In the case of geographically dispersed teams , you simply don t have the funding to fly everyone around the country so they can get together to work on the project (though this happened for Jim s teams at very critical junctures in a project s stage). Jim and his teams rely heavily on online collaboration, using software, audio equipment, and cameras to bring people together over the Internet in order to discuss drawings, design characteristics, and other components of the project. So important to Jim was this topic that the majority of our class time, he talked about the miracle that is online collaboration.
• You don t necessarily need to be afraid of geographic boundaries when assembling people whose skills you need . A little thinking outside the box might lead to a well- formed albeit nonlocal team. That being said, you, the project manager, are the final arbiter of what will and what will not work for a given project.

  Moreover, the primary takeaway from the class was that projects ”IT or otherwise ”of massive proportions are being worked on every day. The power of the Internet has greatly impacted the speed with which team members can communicate and bring their projects to fruition.

Additionally, team members and the other project stakeholders need to understand how the team will be organized. If you have a small 8-person colocated IT team, the team reporting structure will look very different than if you have a team of 150 that is spread across six different organizations in four cities.

Other potential constraints may impact your project staffing. These include labor union agreements, organizational policies, team preferences, and team member knowledge.

Organizational planning is the process of addressing interfaces that may impact how you manage your project team, defining roles and responsibilities for project team members, identifying how your project team will be organized, and documenting your staffing management plan.

Project Interfaces

You need to consider various interfaces as part of your organizational planning, as they may impact both the selection of project team members and how the team is managed.

Organizational interfaces Organizational interfaces are the relationships that must be managed when a project spans multiple departments. The way you structure your team meetings, how you provide feedback to team members, and how you communicate status are a few of the areas that may be managed differently if you are managing a cross-functional project.

Technical interfaces Technical interfaces drive how the technical work of the project gets done. The people developing a new software application that interfaces with existing systems must understand application interfaces as well as the operating platform on which the new application will reside.

Interpersonal interfaces Interpersonal interfaces are the reporting relationships between the people working on the project. In an ideal world, everyone gets along with no conflicts or disputes; in the real world, a project manager needs to be prepared to deal with differences between team members. Knowledge of previous conflicts may even impact the team member selection process.

A key input to organizational planning is the documentation produced from defining your resource requirements during the resource planning process you went through as part of cost estimating that was discussed in Chapter 5. The Resource Assignment Matrix (RAM) or other documentation from resource planning can be used to start your documentation of roles and responsibilities.

Integrated Systems: The We Can t Figure Out Why It Didn t Work Project

The above reference regarding technical interfaces is associated with implicit and subtle nuances . It s easy for company executives to say something like this: You know, we currently have this XYZ system and, while we think it s wonderful ”it does all of our company s billing ” it really needs to be augmented with a newer , friendlier look for the intranet as well as the Internet. Surely the technology you bring to this project can hook to the current system to do this!?!

Well, the answer is yes, sort -of, probably, maybe, and no. When we begin to talk about applying new technology to an existing system, or bringing two or more totally different systems together, we re talking about integrated systems.

Our experience has been that it s remarkably easy for companies such as Microsoft to advertise a snappy new way to interface with an existing system in order to extract information from it for a totally new form of processing. However, the proof s in the pudding, as they say, and putting an integrated system together is much more difficult in practice than in theory.

Consider a mainframe system running Adabas and Natural (a well-known mainframe database and programming interface, respectively). The system has run successfully for 25+ years and though it s efficient, it has run its technological course. Users are tired of the green screen look of the mainframe, and mainframe programmers have run out of ways to make it do what needs to be done for today s billing environment ( specifically Internet queries). You re now charged with a project to bring about an application server interface that allows you to extract the data from this system, render it in XML pages, and thrust it out to the intranet for your customer service folks, your Interactive Voice Response (IVR) system for customers who call in, and the Internet for your more progressive customers seeking assistance via the Web.

Where to start? All of your techies say the words application server simultaneously as though it s clear this is the magic box that s required. But is anyone aware of the complexity involved here? Is anyone in the company prepared for such an undertaking? Microsoft BizTalk, BEA WebLogic, JBoss, and other such application server software (not to mention Internet interfaces for the mainframe such as IBM WebSphere) could potentially bring about the magic required ”but does anyone possess the wand? These application packages are something that a project manager shouldn t just willy-nilly bring into play without first understanding what s required to maintain such a deployment and assessing how much of a corporately internal intellectual grasp there is of such software. After all, you don t want to deploy a project for your company that s going to have to be staffed full-time by expensive contractors. And though it may be acceptable to ask for full-time employees (FTE) trained to handle the care and feeding of such an animal, chances are the first time you say FTE in front of the sponsor you might find your project killed . (It s almost like an allergic reaction with some executives.)

Our point here isn t that you should never venture into integrated systems land, but that you should go there with your eyes open . Do not imagine (or let vendors tell you) that it will be easy to connect two disparate applications. It won t be. You ll run into issues that you hadn t counted on ”running the gamut from simple things like workstation connectivity to ghostly apparitions taking on the form of mysterious disconnections between the two systems. Not to mention the whole issue of representing the system out on the Demilitarized Zone (DMZ “that area between the Internet and the private internal network where IT shops often put their Web and other servers) to Internet users and all of the assorted security concerns that go along with that idea.

As a wise project manager you ll doubtless interview those who ve gone before you in an attempt to figure out what the pitfalls are for the proposed deployment.

Roles and Responsibilities

A roles and responsibilities document lists each group or individual team member on the project and their responsibilities. You have a portion of what you need to document roles and responsibilities if you assigned resources to each task in the schedule or created a RAM to match the activities to the resource doing the work.

But roles and responsibilities of project team members are more than just the assigned tasks. There are standards and methodologies to be adhered to, documentation to be completed, and time reporting responsibilities, to name a few. So in addition to assigning people to tasks , it is a good idea to develop a template to document roles and responsibilities beyond just the task assignment. The more clarity around who is responsible for what, the better.

Roles and Responsibilities Example

Every team member should have clearly documented roles and responsibilities. That includes the project manager; so let s take a look at how you might define the roles and responsibilities for the project manager on the voice-activated dialing project.

Title: Project Manager

Role: Lead the project management activities associated with the launch of voiceactivated dialing.

Primary Responsibilities: The project manager may perform some or all of the following:

• Identify any departmental project management standards.
• Lead team in all aspects of project planning.
• Manage the project team in the execution of the project work.
• Develop schedule and maintain updates on a weekly basis.
• Run weekly project team status meeting.
• Track, assign, and report progress on any project issues.
• Track implementation of contingency or mitigation plans.
• Provide a weekly status of critical issues to project sponsor and key stakeholders.
• Prepare and present a formal monthly project status for the stakeholders.

  Similar documentation should be developed for each project team member. This document not only clarifies for each team member what he or she will be held accountable for, but can also be used to communicate team member accountabilities with the sponsor, functional managers, or other stakeholders.

Many teams often include the project sponsor in the roles and responsibilities documentation. This can be a good way of confirming joint understanding between the sponsor and the project manager as to when and how the sponsor will be involved in the project work.

Roles and responsibilities can be documented in a variety of ways ”bulleted lists, tables, or paragraph format, to name a few. Check for any templates available in your organization or use the format that seems most appropriate for your team.

Tip

Whatever format you choose, the intent is to be as clear and precise as possible in defining the key areas of accountability for each team member.

Tip

Roles and responsibilities may change over the course of the project, so be sure to update this document as needed.

The development of project roles and responsibilities is a good time to clarify the project manager s authority with the project sponsor, especially if the project charter was vague or did not include this information. The project manager s authority can be formally documented in the roles and responsibilities, or it may be an informal agreement where the sponsor delegates some of his or her authority to the project manager. Any authority surrounding hiring and firing decisions or the spending of the project budget should be documented.

Project Organization Chart

It is always a good idea to develop a project organization chart; not only does it provide a snapshot of who is working on the project, it also shows the reporting structure. Depending on the complexity of your project and the number of people involved, there may be multiple reporting levels.

In a small centrally located project team, all team members may report directly to the project manager. However, for an 85-person team working on a large application development project spanning multiple organizations, the structure will typically have many team members report to someone other than the project manager. Large, complex projects often establish project team lead positions . The project team lead is accountable for either the people assigned to a particular phase such as development or testing or for the team members from a specific department such as sales, training, IT, or network. A sample project organization chart using the team lead concept is shown in Figure 6.1.

Figure 6.1: Project Organization Chart

Staffing Management Plan

The staffing management plan is a document where you pull all of your staffing data together. The staffing management plan documents when and how human resources will be added to and released from the project team and what they will be working on while they are part of the team. Adding and releasing resources may be an informal or a formal process, depending on your organization. Make sure you are familiar with any corporate human resources policies that may impact how you release team members from the project. This is particularly important if any of your team members are covered by a collective bargaining agreement (union). Very specific rules regarding both advance notification and the specific process may be used to move these people on and off a project.

If your project involves complex interfaces, be they organizational, technical, or interpersonal, document how you plan to manage these interfaces. If all software development testing must be assigned to a specific work group, this requirement should be identified. If your team spans multiple cities or crosses multiple departments, you need to document plans to manage these circumstances.

The team member roles and responsibilities and the project organization chart also become a part of the staffing management plan to make this a cohesive, comprehensive document covering all aspects of managing your team.

Staffing management plans can be high level or very detailed, so it is a good idea to see if your organization has any project staffing management standards or templates.

Tip

You need to be comfortable that your staffing management plan provides you the blueprint you need to manage the human resources assigned to your project.

Now that you have a plan for managing the staff, it is time to staff your project.

Staff Acquisition

In the staff acquisition process you finally get people assigned to the project. During this process you will put to use some of the general management skills we discussed in Chapter 1.

How the project manager actually goes about obtaining project team members and the amount of project manager involvement in the decision making process for staff assignments varies across organizations. In the best case scenario, the project manager interviews candidates for project team positions and has full authority to select the team members; however, in many organizations, project managers must negotiate with the functional managers providing the resources.

Interviewing Potential Team Members

The control a project manager has over the selection of project team members varies with the type of organization structure and the policies associated with project staffing. If you are in a strong matrix or projectized organization there is more opportunity to impact the decision of who will be included on the team. If you will be interviewing candidates for any of the positions on your team, you need to be prepared with the questions you will ask and the factors that you will use to make your decision. When preparing for an interview, you should make sure to cover several areas.

Skill level:

• Does the person have the training and experience to complete the tasks?
• Does the experience level of the candidate match what is required to complete the tasks?

Project experience:

• Does the person have previous experience working on a project team?
• What types of projects has the candidate worked on?
• What were the candidate s previous project responsibilities?

Interpersonal skills:

• Does the person demonstrate the ability to be a team player?
• Does the candidate have strong written and oral communication skills?
• What are the candidate s strengths and weaknesses?

This is a starting point. Based on the specifics of your project, you can add other areas to this list.

Note

You may find yourself on a project where at least part of the staff is preassigned, if the staff has been defined in the project charter.

Tip

The purpose of an interview is to determine the best person for the job. Preparation is the key to conducting a successful interview. Have a list of written questions that you want to ask each candidate and take notes as you conduct each interview. There are laws governing the personal information that can be requested from job applicants . If you do not have experience interviewing job candidates, you should find a mentor to assist you or obtain a template or checklist from your human resources department.

Negotiating with Functional Managers

In a more traditional organization structure, you will need to negotiate with functional managers to obtain your project staff. You may or may not have an opportunity to interview potential candidates, depending on how staffing is handled within your organization. But even if you interview candidates, you will need to work through the functional manager to finalize project staffing decisions.

Not a Big Field to Choose From

Suppose that you re a project manager in the middle of staffing a new software development project. You don t have a large field of developers from which to choose. The senior-level developers are engaged and are using the juniors from time to time for coding assistance. You re going to have to pick from a field of one or two junior-level developers who you ve been told are available for your project.

Picking a junior-level developer isn t necessarily a bad thing, it s just that you will need to augment the development time required to compensate for the junior-ness of your programmer. He or she can probably do the job, just not as quickly as the senior who has been there, done that. Skill level and experience will drive task durations out and hence affect the bottom line of the project s due date.

If the project has a hard due date ” that is, the sponsor says it must be done by such and such a date ”then you re faced with working your junior overtime, or telling the sponsor that you need to free up senior-level resources to meet the deadline or you employ the techniques of crashing and fast-tracking.

The functional manager will determine whether resources are available on a full-time or a part-time basis. If you are acquiring people who are assigned to additional projects or other staff work, you must establish a clear understanding as to the numbers of hours each person is dedicated to your project.

In a matrix organization, where the project team members will have multiple bosses (the functional manager and at least one project manager), it is essential to clarify and obtain agreement on the team member accountability. A team member should only be accountable to one person for a given result.

Performance assessment is another topic to be discussed at the time resources are obtained. Your organization may have a formal policy that includes input from the project manager as part of the process, or you may need to reach an agreement with each functional manager as to how you will provide feedback into the performance appraisal process.

As the project manager, you should initiate a meeting with each impacted functional manager to discuss your staffing needs and come to agreement on who will be assigned to your project. Functional managers often have very large teams and are constantly fielding requests to provide staffing resources to project teams. You need to come into the meeting prepared to identify your needs and have a game plan to negotiate with the functional manager. Here are some suggestions to help make this process smoother:

Schedule a separate meeting with each functional manager. Unless your organization has a formal staff allocation process involving all project managers and all impacted functional managers, meet individually with each functional manager so that you can focus on the project needs from that specific area and make the best use of the functional manager s time. When scheduling a meeting, be clear on the purpose, allow adequate time to work through any issues, and hold the meeting in a workroom or private office. Do not try to complete the staff negotiation process in the hall or on the elevator.

Identify who would be part of your dream team. Do your homework and become familiar with the people who report to each functional manager. Use your staffing management plan, your roles and responsibilities matrix, any documented information regarding the experience and qualification of available resources, and previous work experience with potential team members to pencil out a list of who you would bring to the team if the decision were in your hands.

Plan who you will request from each functional manager. If you want specific people on your team or you require people with a specific experience level, explain to the functional manager who you want and the reason behind your request. Let s face it; every project manager wants the best people, so you will need to make your case. Be prepared to provide a brief overview of your project, its strategic importance, and the importance of the resource(s) coming from this functional area.

Have a backup plan if you cannot obtain the resources you want, and be prepared to negotiate.

Request your most critical resources first. It is very unlikely that you will get everyone you ask for. Certain people may already be committed to other projects or the timing of your request may conflict with critical functional activities. You need to prioritize your staffing needs. Understand which activities are the most complex, are on the critical path , and have the highest risk potential. These activities are the areas where you want to make sure you have the best people. Work through getting these areas assigned first. You have more flexibility to agree to a different resource or accept the person assigned by the functional manager for activities that are less complex or have float time.

Following these steps may not always get you the team members you want, but it will help establish your credibility with the functional managers if you handle your requests in a professional manner. Whatever the outcome of a particular meeting, maintain a good business relationship with the functional managers; you will be back to see them again for future projects.

Other Staffing Scenarios

In some situations you may not be able to negotiate for staff. Only one person may be available with the skill set required. The project sponsor may assign some of the project team members, or the client or other executive stakeholder may request certain team members. Assignments made without your input may be good choices or bad choices. If you choose to challenge one of these assignments, make sure you are doing so based on hard facts such as the lack of the required technical skills. Unless the person simply is not qualified to do the work, you will probably have to live with this decision and make the best of it.

One last staffing scenario involves procuring resources from an outside supplier. Contract workers may be brought in if no internal resources are available for a time-critical project or if internal resources do not have the required skill set. Procurement planning is discussed later in this chapter.

Quality Planning

When we do a project assessment, one of the items we ask to see is the quality plan. In our experience, the quality plan is one of the most frequently ignored areas in the overall project plan. People sometimes just assume that since the team wants to produce a high-quality product, it will happen. But if you just assume that the quality is there, you may be in for some unpleasant surprises . Not everyone defines quality in the same fashion. If you have not defined your approach to quality up front, how can you determine the level of quality in your finished product? Quality planning is the process of identifying quality standards that are applicable to your project and deciding how your project will meet these standards.

Numerous articles and books have been written on the subject of quality. You may be familiar-with the work of one of the quality movement gurus: Crosby, Juran, or Deming. Although each of these men defined a specific approach to quality, one common thread in their philosophies is that quality must be planned.

Note

Quality management reaches very esoteric heights. Quality management programs such as total quality management (TQM) and Six Sigma strive for consistent quality modifications that result in nearly 100 percent throughput, in terms of high quality. Do an Internet search for TQM, Six Sigma, and ISO 9000 and you ll get plenty of hits for more thorough reading on this subject.

A key component of quality planning is the corporate quality policy. You need to determine if such a document exists in your organization, and if so, review the quality standards or direction on how to approach your project. If you are referencing a corporate quality policy, review that policy with your project team and the stakeholders to make sure everyone is familiar with the standards. You should also reference the quality policy in your quality management plan.

It would be impractical to quality check every single task on the project plan. Several tools and techniques are available to assist you in determining what to measure and how to measure. These decisions regarding quality measurement are documented in the quality plan.

Quality Planning Tools and Techniques

At this point you may be asking yourself How do I go about determining what quality activities I should include in my project? What you need is a way to determine those areas of your project most likely to have quality issues that impact the success of the project.

Your corporate quality plan may include useful tools and techniques to determine where to focus your quality efforts. It may include standard tools that each project is expected to use.

Another area the project manager needs to consider is industry standards or government regulations. In particular, if you are producing a product that is regulated , you must be certain that it meets the criteria defined in the regulations. Failure to meet the provisions of a regulation could result in fines or jail terms. Regulations may also be in place for safety reason to protect workers and/or consumers.

Even if you do not have a corporate quality process and are working on a project with no predefined standards or regulations, you can use several techniques to determine what quality aspects of your project to measure. We will look at four of the most commonly used: cost-benefit analysis, benchmarking, flowcharting , and cost of quality.

Cost-Benefit Analysis

Cost-benefit analysis was discussed earlier in this book in Chapter 2, when we covered project selection. This technique is also useful in planning quality management. You need to identify those quality activities that will provide the most benefit at the least cost.

The benefits of quality are things like client satisfaction, less rework , and lower overall costs. IT projects often have test plans. Cost-benefit analysis can be used to help identify each point in the development phase where test scenarios should be run, as well as the type and number of test scenarios.

Benchmarking

Benchmarking is a technique that uses similar activities as a means of comparison. It is a very useful technique if you are changing or upgrading the way you currently do business. If you are changing the work environment, you want results equal to if not better than the current environment.

For IT projects benchmarking could include such items as a comparison of a new system response time with a similar application or the speed of report generation with the speed of the current system. Benchmarking is only applicable if there is valid data on the capabilities of the original system, and there are enough similarities that the comparison is meaningful.

Flowcharting and Process Diagrams

The notions between a flowchart and DFD are similar ”you re trying to map a process flow ” but with a DFD you are breaking things down into discreet chunks from which you can begin to develop your code.

Flowcharting uses diagrams that depict the relationship of various elements in the project. Developing a flowchart or a series of Data Flow Diagrams (DFDs) can help you anticipate where and when a problem may occur. You can build in checkpoints to assess the quality of a particular activity before the next step is started. To use a simple example from a home improvement project, you could build in a quality checkpoint to make sure the paint on the walls has dried before you hang your family photo collection.

Figure 6.2 shows a flowchart and a DFD for the process of a customer interacting with a company through a customer service website.

Figure 6.2: A Comparison between a Flowchart and a DFD

At first glance the flowchart looks considerably more difficult to interpret than the series of DFDs. However, you should note that the flowchart describes the flow from start to finish. DFDs start with what s called a context zero diagram (note the 0 in the upper center of the starting box) and drill down into diagram levels 1, 2, and so on. The idea is that as you drill down, you get more and more information about a specific context. At some point, you ve finally fleshed out the context so much that you have a solid place from which to begin coding. Some Computer Aided Software Engineering (CASE) tools have the capability of letting you create the DFDs within the CASE tool, then, with the push of a button, create the majority of the code associated with a given context.

Cost of Quality

Quality involves added work to the project, and it comes at a cost. Cost of quality is the cost of all of the work required to assure the project meets the quality standards. You can have costs associated with both the work you do to assure quality and with the ramifications of a poorquality product. The three types of costs associated with quality are prevention, appraisal, and failure.

Prevention Prevention costs cover the activities performed to avoid quality problems. These costs include quality planning, training, and any product or process testing.

Prevention costs are incurred by planning in activities like testing code at various phases: individual unit tests, integration testing that combines several modules, and in some cases a systems test that tests end to end. The purpose of these tests is to catch any potential problems early on as the work is being done.

Appraisal Appraisal costs cover the activities that keep the product defects from reaching the client. Appraisal costs include inspection, testing, and formal quality audits .

User acceptance testing is an appraisal cost. A small, controlled group of users runs scenarios to test the functionality of a new system before it is deployed.

Failure Failure costs cover the activities generated if the product fails. Failure costs include downtime, more user support, rework to correct critical problems, and possible scrapping of the project. Failure costs on a new customer support application could include additional user training or the need for extended on-site support.

Further failure costs are incurred if the product has left the organization and reached an external customer. These costs include recalls, warranty work, customer site visits , and the damage to the company s reputation.

As we mentioned in Chapter 2, quality is one of the constraints that all project managers must deal with. It really is a balancing act among the budget you have for the project, the time you re given to accomplish the project s goals, and the overall quality of the product. Quality is not free and it takes time; as project manager you need to plan for the appropriate quality steps and be prepared to explain the consequences of shortchanging quality in terms of failure costs.

The specific quality activities that you identify are documented in the quality management plan.

Quality Management Plan

The quality management plan documents the output from the quality planning tools and techniques by listing the quality activities that will be performed, the procedures used to complete the quality activities, and the resources required. This plan will be the basis for doing quality control when you are in project execution.

The procedures section of the plan includes more detailed information regarding the expected results from quality activities and the steps used to determine whether the quality standards are being met. The quality standards and the method used to measure these standards need to be clearly defined. Methods used to measure whether quality standards have been met include metrics, checklists, and exit criteria.

Metrics A metric is a standard of measurement that specifically defines how something will be measured. You can define metrics for any area of the project. Let s use a web sales application as an example. If you are going to measure quality of the checkout process, your metric might state that when the customer implements the checkout process, the system will multiply the price of each item by the quantity of items ordered and compute the applicable sales tax and shipping charges 100 percent of the time. This metric would be part of the test scenarios run against both code in the calculation unit and as part of the user acceptance test.

Checklists A checklist is a tool to list a series of steps that must be taken to complete an activity. As each step is completed it is marked off the list. This provides documentation that the steps were done and can also be used to track when the step was taken and who performed the work.

A quality checklist for user acceptance testing might contain the following items:

• Schedule 10 users to complete test scenarios.
• Develop 20 test scenarios.
• Review scenarios and obtain client approval.
• Make copies of scenarios for each user.
• Train the 10 users on how to run the scenarios and document their results.
• Review user results.
• Document defects.

  Note

  You can hire contractors who specialize in testing processes. Also note that companies specialize in validation of a specific development process. These specialists are called Independent Validation and Verification (IV & V) companies and can be an invaluable aid in large software development and deployment projects. They perform the function of keeping everyone on their toes with eyes fixed straight ahead on the project. (See NASA s IV&V site http://www.ivv.nasa.gov/business/ivv/index.shtml for more in-depth information on this intriguing and substantial subject.)

Exit Criteria We discussed exit criteria briefly in Chapter 4 when we talked about milestones. To refresh your memory, a milestone marks a key event in the project life cycle. If your project life cycle methodology uses milestones to mark the end of one project phase and the beginning of the next phase, the milestones between phases may include quality exit criteria. In this case your quality plan should document the criteria that must be met at each phase to consider that phase complete. Software development projects frequently use a series of tests to confirm the quality of the major deliverables for each phase. These tests can be established as exit or entrance criteria. For example, a unit test can be used as a criterion to signify the completion of code development.

The quality management plan should also address how the results of the quality activities will be reviewed with the project sponsor and other stakeholders. Identification of any activities requiring formal sign-off is also documented. A user acceptance test may not be considered complete until the client or a designated representative approves the results.

Risk Planning

Risk is something that we deal with in our everyday lives. Some people seek out jobs or leisure activities that are considered high risk. They may get a thrill or a feeling of great accomplishment derived from taking on the challenge of skydiving or mountain climbing or working as a lineman on high-voltage electrical lines.

However, if you mention the word risk in association with a project, the majority of people will immediately think of something negative. Risks are not always negative. A project risk is simply an element of uncertainty that can have either negative or positive consequences. Remember when we discussed fast tracking as a means to reduce the schedule duration by doing tasks in parallel that would normally be done in sequence? There are definitely risks involved in overlapping tasks , but in this case it is a self-imposed risk that may have a positive outcome of completing the project sooner and meeting the client s needs.

That said, a lot of project risks probably have negative consequences. The best way to handle risk is to acknowledge it and deal with it. In order to more clearly illustrate this, think back a moment about the definition of a project. One of the key factors in defining a project is that it produces a unique result. If you remember that you are not dealing with an operations procedure that has been in place for months or years with fairly predictable results, you ll immediately see the implications of risk. Even if your project is similar to previous projects, it will still produce its own unique result; you do not have a crystal ball to tell you exactly what will happen during the course of the project. You need to plan up front for events that may take your project off course. Risk planning deals with how you manage the areas of uncertainty in your project.

Risk planning has three major components : identifying the potential risks to your project, analyzing the potential impact of each risk, and developing an appropriate response for each risk.

Risk Identification

All projects have risks. Project team members can identify a component of their current project that they are not comfortable with. It could be an aggressive schedule with complex task dependencies, team member experience, or lack of confidence in a vendor. Unfortunately, many project managers do not take the time to work with the project team and other stakeholders to formally document where the project is at risk. Risk identification is the process of determining and documenting the areas in your project with the potential to take the project off track.

Risks can be viewed from both the global level, looking at the project as a whole, and by analyzing the tasks in the project schedule. Global risks can include such items as the level of funding committed to the project, the overall experience level of the core project team, the use of project management practices, or the strategic significance of the project. Typically, the project manager, the project sponsor, and the client deal with identifying the global risks.

Risks are also identified by the project team from the perspective of the schedule and the tasks required to achieve the project objectives within the committed time and budget. There may be risks associated with particular phases of the project or with certain key tasks. The assessment of risks in the project schedule includes participation from all core project team members and any appropriate subject matter experts.

A series of questions can be developed to pose to the project team for each phase or task. Examples of risk identification questions include:

• Is the task on the critical path ?
• Is this a complex task?
• Does the task involve a new or unfamiliar technology?
• Does the task have multiple dependencies?
• Have we had problems with similar tasks in previous projects?
• Is this task controlled by outside influences ( permits , county hearings, etc.)?
• Are there inexperienced resources assigned to this task?
• Are there adequate resources assigned to the task?
• Does this task involve an integrated system?
• Are we unfamiliar with the hardware or software we re going to use for the tasks?

For those tasks with yes answers to any of the above questions, move on to questions regarding the potential problems that may be associated with this phase:

• What issues or problems might occur?
• What problems occurred with similar tasks in the past?
• What could cause this problem?

Once you have walked through the process of identifying all the possible risks to your project, you need to use risk analysis to take a closer look at each identified risk to see what the impact really is.

What Could Possibly Go Wrong?

It s also good to have a pre-project brainstorming session with the finalized project team in which you simply use sticky notes and answer this question: What could go wrong?

By letting people free think and blurt out all the possibilities that occur to them, you might get some input that proves to be really valuable in the risk identification step.

Risk Analysis

Risk analysis is the process used to identify and focus on those risks that are the most critical to the success of your project

There is a lot of information out there about risk analysis and the various techniques that can be used. Risk analysis can be approached from a qualitative or quantitative perspective. Qualitative risk analysis looks at the likelihood that a risk will actually occur and the impact to the project if it does occur. Quantitative risk analysis uses a more complex mathematical approach to numerically analyze the probability that a risk will occur, the effect on the project goals, and the consequences to the overall project. A detailed discussion of quantitative risk analysis methodologies is beyond the scope of this book, but you should be aware of some of the terms you may see. The more advanced techniques for computing quantitative risk analysis include sensitivity analysis, decision tree analysis, simulation using the Monte Carlo technique, and interviewing. Organizations that use these techniques as part of risk management typically have in house experts to complete the assessment or assist project teams . More information on quantitative risk analysis can be found in the Guide to the PMBOK .

What we are going to focus on in this section is a simplified approach to qualitative risk analysis that a project manager can lead without the need for special tools or training. If your organization relies on these more sophisticated tools, that is great, but do not think you cannot do risk analysis without them. By using a template and a simple set of criteria, the project can focus the team on the risks that really need attention.

When you are finished with risk identification, you may find that you have several pages of documentation. Numerous tasks on the project schedule are likely to have some degree of risk associated with them, and the thought of all this risk may seem overwhelming. You need to keep in mind that all risks are not equal. Risk identification is a brainstorming session to make sure as many potential risks as possible have been captured. But not all risks will become a reality. Therefore, it is important to quantify the potential risks, so that attention can be focused on those risks whose impacts on the project success are the greatest.

Risk Severity For each of the items that have been listed on the template, the team identifies the impact to the project if the potential problem does occur. A simple rating can be used:

• High impact
• Medium impact
• Low impact

Some problems have impacts that are very narrow in scope and do not impact the overall success of the project, while others could delay the project completion or cause a significant budget overrun . By relying on the expert knowledge and judgment of the team members and any historical data, your team can rate the severity of the each risk.

Risk Probability The other key element of risk quantification is the probability of the potential problem actually occurring. Some risks are almost a certainty , while others are an extremely remote possibility. The knowledge of the project team and any historical data is used to rate the probability of risk occurrence. The same high, medium, or low scale can be used.

The risk analysis process can be completed using a simple template as shown in Table 6.1. The tasks with potential risks can then be prioritized, with those having both a critical severity rating and a high probability of occurrence listed first. For those tasks that have the greatest potential impact on the project, a plan should be developed for an appropriate course of action.

Table 6.1: Table 6.1 Risk Analysis Template

Risk	Severity	Probability
Risk A	H	H
Risk B	M	M
Risk C	L	H
Risk D	H	L

Risk Response

Risk analysis provides you with a prioritization for all the risks the team has identified. Risk response planning is the process of reviewing each item on the prioritized list of potential project risks to determine what, if any, action should be taken.

The Guide to the PMBOK lists four techniques for risk response planning:

• Avoidance ”changing the project plan to eliminate the activity that created the risk.
• Transference ”moving the liability for the risk to a third party.
• Mitigation ”reducing the impact and/or the probability of the risk.
• Acceptance ”choosing to accept the consequences of the risk or being unable to identify another response strategy.

Transference is a specific technique involving tools such as insurance premiums, performance bonds , or fixed price contracts to limit financial risk. The other techniques can be grouped together as two types of action can be taken when responding to risk: preventative action and contingency action.

Preventative Action

Preventative action involves the review of potential risks to determine if any steps can be taken to prevent the problem from occurring or reduce the probability that the problem will occur. Preventative action combines the techniques of avoidance and mitigation. The costs of these actions are weighed against the impact of the risk. You determine whether resources are available with the skill set to implement the preventative action. Tasks are added to the project schedule to track preventative actions. Questions to ask the project team as you work to identify preventative actions include:

• What can be done to prevent the problem from occurring (address the causes)?
• What can be done to decrease the likelihood of the problem occurring?
• Are these actions cost-effective ?
• Are there resources available to implement these actions?

Contingency Action

Acceptance includes not only those risks you choose to accept, but also those risks you cannot prevent. If the problem is something totally outside the control of the project team (such as pending legislation or a possible work stoppage), a contingency plan is developed to identify the most likely impacts to the project and a strategy to deal with the impacts. You want to be able to answer the following:

• If the problem cannot be prevented, what are the most likely impacts to the project?
• What can be done to minimize these impacts?

Your risk management plan can be documented using a simple template as shown in Figure 6.3.

Figure 6.3: Risk Management Template

This plan is used to communicate project risks and action plans to other stakeholders. It can be converted into a risk tracking log, which we will discuss further during project control in Chapter 9.

Communications Planning

Good communication is one of the keys to project success. If you ask project managers to tell you how they spend their time, most will state that they spend anywhere from 50 to 80 percent of their time on project communication. You may have noticed in this book, we continually end a planning section with the need to communicate this information to team members or other stakeholders. A need for good communication starts from the day the project charter is issued and you are formally named project manager (perhaps even earlier if you have been filling the project manager role informally). The project charter is the first of many project documents that needs to be reviewed with your stakeholders. Unfortunately, even though project managers usually recognize how much time they spend communicating, this does not always translate into taking the time to develop a good communications plan.

Overcommunicating Is Not Necessarily Good Communicating!

Once, one of us was a team lead on a project where the project manager created distribution lists for both email and paper documents and sent everything she received that even remotely involved the project to everyone on the lists. She thought she was doing an excellent job of communicating with the team, but the team was going crazy. We were buried with data, and much of it was not relevant to our role on the project. It got to the point where most of the team members were so overwhelmed we stopped reading everything. That, of course, led us to missing information we did need. The project manager did not understand why there was so much confusion on the team. She had not put any planning into her communications process.

Good communication involves far more than just setting up distribution lists. You need a plan to determine what gets communicated to whom. Communications planning is the process of identifying what people or groups need to receive information regarding your project, what information each group needs, and how the information will be distributed. The communication system should monitor the project status and satisfy the diverse communication needs of the project s stakeholders.

We are going to review general principles of project communications strategy and then focus on some specific areas of concern for communicating with project team members and communicating with other stakeholder groups.

Communications Strategy

Communication is a part of our daily lives, both business and personal. Because people communicate all the time, they give little thought to organizing or planning communication.

Regardless whether you are communicating with your sponsor, team members, or your client, some simple steps will make your communication more effective.

• Decide WHAT you wish to communicate.
• Decide TO WHOM you wish to communicate.
• Think about the BIASES of the receivers/listeners.
• Decide HOW you should communicate.
• COMPOSE and TRANSMIT the message.

It is not necessary to document these steps every time you communicate, but taking even 5 minutes to think through them will have the outcome of improving the focus and clarity of project communications. The importance of planning your communications before you speak or write is even more critical if your message is sensitive or controversial . Life is much easier if you send the right message to begin with, rather than apologizing or retracting at a later time.

Documenting an overall communications plan can be accomplished by:

• Defining who needs information on your project.
• Listing communication objectives for this person or group.
• Identifying the communications vehicle(s).
• Assigning accountability to deliver the communication.
• Determining when the communications will happen.

Figure 6.4 shows an example of a communications plan using this approach. Although the template from this example can be used to create an overall communications plan for all stakeholder groups, there are some additional considerations when it comes to communicating with your project team.

Figure 6.4: Communications Plan Example

Communicating with Project Team Members

One of your most important jobs as project manager will be communicating with your project team members. It is your responsibility to make sure all the team members understand the project goals and objectives and how their contribution fits into the big picture. Unfortunately, this is an area that is frequently overlooked in communications planning.

Your interactions with your project team will involve both formal and informal communications. Formal communications include project kickoff meetings, team status meetings, written status reports , team building sessions, or other planned sessions that you hold with the team. Informal communications include phone calls and emails to and from your team members, conversations in the hallway, and impromptu meetings.

The challenge that project managers face is to match their communication style with that of each team member. Getting input from your team members will help you better communicate with them. If you are scheduling a kickoff meeting or other team building session, ask for suggestions on agenda items or areas for team discussion. Team members may have suggestions for the structure and frequency of the team meetings or format for status reporting, based on their previous project experience. The project manager may not be able to accommodate all suggestions, but taking the time to consider input and reviewing the final format will go a long way toward building a cohesive team.

Everyone has a communications method they are most comfortable with; some of your team members may prefer to primarily use email, while other rely on phone calls or voicemail. For these informal one-on-one communications, where possible, work to accommodate what is most comfortable for each team member.

You may note that some of the other stakeholders may not understand how they are involved with the project. Extra steps are required to properly engage these people.

Engaging Stakeholders

Before you can develop a communications plan for the other stakeholders on your project, you need to identify who they are. In Chapter 2 we identified some of the typical project stakeholders: project sponsor, functional managers, customers, and end users. Remember that a stakeholder is anyone who will be positively or negatively affected by the outcome of a project.

On large projects that cross multiple functional areas, you may identify stakeholders who are not participating in the project or do not fully understand their role. This commonly occurs with large systems applications or new products that are deployed across geographic regions such as multistate customer operations areas or multicampus sites. If the customer operations director does not understand how his team is involved or what will be the total impact on his group, you need to get him connected to what s going on. But he may be busy and not paying attention to your project. So, if you can only get 5 minutes of time with an uninvolved stakeholder, it s vital that you spend your time wisely.

To accomplish your mission, it can be useful to develop an engagement plan that describes the key points you need to get across:

• Identify which aspects of the project plan to communicate.
• List any known or probable benefits or concerns from the stakeholder.
• Determine key message(s) to convey to each stakeholder.

An example of a stakeholder engagement plan using the customer operations scenario for a new product deployment is shown in Figure 6.5.

Figure 6.5: Stakeholder Engagement Plan

This particular example uses three scenarios based on the amount of time you are spending with the stakeholder. This approach has two key benefits:

• You have carefully thought out what you need to say if your time is limited.
• You are ready for the next meeting or to extend your current meeting if the stakeholder wants more detail immediately.

Your communications plan is a document you need to review with your sponsor. If your project requires communication to executive team members, the sponsor can help develop the communications plan by identifying what information the group needs, and how and when communication will take place. In addition to the communications distribution structure, your communications plan may include information on how you will gather and store information, how to obtain information between communications, and how to update the communications plan.

Procurement Planning

Many projects are completed using external resources for part of the project deliverables. For a variety of reasons, another company may complete pieces of the project work or on occasion even the entire project. You may have been part of a project team that included contractors to complete certain tasks . IT projects often use outside resources on large projects rather than hire more employees who may not have any work when the project is done. If your project includes outside resources, you need to be familiar with the procurement process. Procurement planning is the process of identifying the goods and services required for your project that will be purchased from an outside organization. If your project is completely internal, you do not need a procurement plan, unless internal departments bid on the work and sign a contract.

As a project manager, you are the buyer of goods and services for your project, so because of that we will cover the procurement process from the buyer s perspective.

The organization selling the goods or services is referred to as a vendor, a supplier, a consultant, or a contractor.

The procurement process is very complex and often involves the legal department or in the case of larger companies a separate procurement department that manages the process across the organization. This book will not make you an expert in procurement, but we will cover many of the basic concepts.

Procurement planning starts with the decision to procure goods or services outside the organization. Once that decision has been made, you need to determine what type of contract would be best. A statement of work (SOW) is developed to define exactly what work the vendor is being asked to deliver. The SOW is incorporated in a document distributed to the vendors who will be bidding on the work. Vendor evaluation criteria are developed to use in evaluating the bids or proposals that are received.

Let s start by looking at some of the circumstances that might cause you to procure outside resources.

Make or Buy Analysis

Before you can define a procurement plan, you need to determine whether you need to procure anything. The general management technique known as make or buy analysis is often used to make that determination. What it involves is looking at the trade-offs between doing something in-house versus procuring it outside the organization. Here are some of the more common areas to consider:

Equipment

For some of your project resources, this may be fairly simple. If you are developing a new application that requires new hardware, you will need to obtain the hardware from outside your company. But you still have a decision point of purchasing the hardware outright or leasing it. You need to look at the life expectancy of the application as well as such things as whether other applications could run on the hardware and share some of the cost.

Staff Augmentation

The use of outside human resources can range from paying a vendor to run the entire project to contracting for specific resources to perform certain tasks.

Using a vendor can be driven by a lack of organizational expertise. If none of your programmers are skilled in the programming language required for your new application, you could hire people who have this expertise, but there may not be a need for all of those people once the development work is complete. Contracting for programmers with the required skill set to complete the project work may be a better plan. If the new system will be maintained internally after the project is completed, you need to determine how you will train existing employees or add to the current maintenance staff.

Time-critical projects may also require more resources than are currently available. Contract resources can fill this gap.

Other Goods or Services

Projects may have specific deliverables that are appropriate to have completed by a vendor. If you are installing a new commercial software application, you can schedule resources to develop training or you can purchase the training. If you do not have a dedicated in-house training development and delivery team, it may be more effective to contract these services. There may even be existing training developed that you can purchase either with or without resources to do the training.

IV&V and testing services are an ideal candidate for this kind of outsourcing as well. Unless you ve got a formal testing department with an established set of procedures, you ll get much better results from outsourcing the testing to a group of professionals.

Once you determine which aspects of the project to procure from outside the organization, you need to have a basic understanding of the types of contracts you can use to authorize this work.

Types of Contracts

A contract is a legal document that covers the work that will be done, how the work will be compensated, and any penalties for noncompliance . Entire law school courses are devoted to contract management, so this book is not going to make you a contract expert, but you should be able to understand differences between the types of contracts. Most contracts fall into one of the following categories: fixed price contracts, cost reimbursable contracts, and time and materials contracts. Let s take a more detailed look at each of these.

Fixed price contracts Fixed price contracts have a fixed fee for the work that the vendor will provide. This type of contract works best when the product is very well defined and there is good historical information. Using a fixed price contract on a product or service that is not well defined or has never been done before is risky for both the buyer and the seller.

Cost reimbursable contract A cost reimbursable contract provides a seller with payment of all costs he or she incurs to deliver the product and includes a fee to cover the seller s profit. This type of contract has the most risk for the buyer, as you do not know what the total cost will be. Although this may not be the most desirable contract from a buyer perspective, it may be your only option if you do not have a well-defined product or if you are asking the vendor to provide something that has never been done before.

Time and materials contract A time and materials contract is a cross between a fixed price and cost reimbursable contract. The buyer and the seller agree on a unit rate, such as the hourly rate for a programmer, but the total cost is unknown and will depend on the amount of time spent to produce the product. This type of contract is often used for staff augmentation, where contract workers are brought on to perform specific tasks on the project.

Keep in mind the types of contracts as you define the work you want completed in the statement of work (SOW).

Statement of Work

If you are going to have outside vendors involved in the project, it is critical that they know exactly what you are asking them to do. The statement of work (SOW) details the goods or services you wish to procure. In many respects it is similar to the project scope statement; it contains the project description, major deliverables, success criteria, and any assumptions or constraints. It will also generally include information about any warranties the vendor is supplying and will detail payment expectations. The portion of your project scope statement pertaining to the work you are putting out for bid is a good starting point for the SOW.

Even if the SOW is actually created by another department, the project manager should be involved in the process to ensure accuracy of the project requirements. Vendors use the SOW to determine if they are both capable and interested in bidding on your project work. It must be very clear and precise. Anything in the SOW that is ambiguous could lead to a less than satisfactory deliverable .

Many companies have templates for creating a SOW; this ensures that all required items are covered and provides consistent information to vendors.

Completion of the SOW means you are ready to start vendor solicitation.

Vendor Solicitation

Once you have decided that some of the project work will be completed outside the organization and have developed a SOW defining what you want done, you need to notify vendors. Solicitation is the process of obtaining responses from vendors to complete your project work as documented in the SOW.

Typically a procurement document is prepared to notify prospective sellers of work. There are several terms associated with these documents. Three of the more common terms are:

• Request For Proposal (RFP)
• Request For Quotation (RFQ)
• Invitation For Bid (IFB)

These terms are often used interchangeably and may have different meanings in different organizations. Regardless of what these documents are called, they should include your SOW, information regarding how responses are to be formatted and delivered, and a date by which responses must be received. Potential vendors may be required to make a formal presentation or they may just be asked to submit a bid. Depending on the industry you are in, these procurement documents may be extremely detailed.

Before providing a copy of your procurement document to any potential seller, always determine if your company has an approved vendor list. Many companies have a formal process that vendors must comply with before they can do business with the company. If your company has such a policy, you should only be soliciting bids from those approved vendors. If no such list exists, the project team or the procurement department will need to research potential vendors through trade association, Internet, or other available sources of information.

At the time the procurement documents are distributed (or earlier), you need to develop the criteria to be used to evaluate the bids, quotes, or proposals you receive.

Vendor Selection Criteria

The amount of time that the project manager spends on vendor selection is driven by whether the company has a separate procurement department. If your company has a specialized group that handles vendor contracts, they will advise you what information you need to provide and a member of their team will work on your project to manage the vendor selection process and the contract.

If you are responsible for vendor selection, then you will need to develop criteria to use when evaluating vendor bids or proposals. It helps to decide up front with the sponsor and other key stakeholders who will be involved in the review and selection of vendor proposals. This group should develop the selection criteria as a team and reach agreement ahead of time as to any weighting of the criteria.

Sole-Source Documentation

For those of you who work in government, your procurement job is even harder! Governments typically not only create an approved vendor list ”you must buy from the vendors on the list unless you can prove that they can t supply it, never mind whether another manufacturer makes a superior product or not!

The only way you can get around this problem is to provide what is called sole-source documentation stating that the vendor you re buying from is the only one that carries the thing that you need along with the reasons why you need that specific thing. If you don t carefully document the exact reasons why you need the thing you need and you don t make a convincing case of it, you re likely to be forced to go with someone else s product and make it work.

The vendor evaluation criteria you develop will be used to rank the various proposals. The criteria may be both objective and subjective . An example of criteria you might use includes:

• Overall cost of the vendor proposal.
• Vendor understanding of the business need.
• Qualifications of the vendor staff ”both managerial and technical.
• Vendor experience with similar products.
• Cultural fit with your organization.
• Vendor financial status.

Case Study: Chaptal Wineries Email and Intranet Systems ”Formulating the Final Plans in the Project Planning Process

You re very close to finally being able to begin the Chaptal project plan. However, you need to focus on some final planning elements that will help bring about a solidly deployed project. You ll develop a roles and responsibilities worksheet, communications plan, quality plan, and you ll perform risk assessment and team member designations and procurement planning in this section.

Roles and Responsibilities and Team Member Designations

Title: Yourself ”project manager and IT Director for Chaptal

Role: Project planner, initiator, and coordinator

Primary responsibilities: Acquisition of project hardware and software, also WAN telecommunications connections Vendor contracts and maintenance agreements Managing contractors and other winery employees in bringing about the deliverables Work with day-to-day IT duties as required

Title: Guillaume Fourche, Metor Sanchez, Jason Jay ”project team members

Role: Assist with WAN connectivity issues, testing, and server deployment at the various winery sites

Title: Intranet contractor

Role: Develop all intranet pages for use by the Chaptal winery group

Title: Telecommunications contractors

Role: Provide T1/E1 connectivity from the winery site to the telecommunications cloud.

Communications Plan Kim Cox ”your boss, also the project sponsor. You ve decided she ll need daily updates on your progress. Since you don t have email yet, you ll either give her a quick heads-up in person, or over the phone. She says she doesn t expect a blow-by-blow synopsis, just any standout issues or problems that you ve run into. She d also like a quick update on any significant project progress.

Guillaume Fourche, Metor Sanchez, and Jason Jay need to hear from you at a minimum of once a week, even if you have nothing to share. Since they will be working with you to get things done for their particular areas of the world, you ll also need to get any news, updates, or issues while you re talking with them.

All of the telecommunications companies will require direct dialog as needed. When your intranet contractor begins work, he or she will dialog with you on a daily basis, giving you status updates, showing you the work to date, and working with you on testing procedures.

Quality Plan Your quality plan consists of three elements:

• Server hardware and software testing and validation ”You will be responsible for verifying that all server software has been correctly installed, that all service packs and necessary security patches have been applied and that all hardware is functional and operating correctly with the software.
• The telecommunications contractors will be responsible for testing and validating that the telecommunications circuits (T1 and E1) are operational, fully functional, and error-free. Telecommunications companies will provide a warranty of error-free operation and an Operational Level Agreement (OLA) that specifies how they will perform if any problems occur.
• There will be significant unit, system, and UAT testing on the intranet pages. There will be UAT with regard to the email system.

  Risk Assessment After performing a risk assessment analysis with Kim Cox and others from the Chaptal management team, the following subjects were determined to have some element of risk associated with them:

  T1/E1 WAN Circuits ”There is a marginal (20 percent) probability that the minimal speed of the circuit (1.44 Mb/s) could introduce bottlenecking at peak information load times. Risk mitigation involves either waiting out the peak, or purchasing a higher-load circuit (such as a double T1). Chaptal management thinks that the best approach is to monitor the circuits for load at deployment time and to probably live with any minor bottlenecks that might occur. Load testing will be able to show if there are more significant load factors than anticipated as of this writing.

  Hardware failure ”There is a 2 percent probability that the hardware will fail upon initial power-up and short- term operation, or that it will be delivered in a nonfunctional state. The vendor contract calls for a next -day air shipment on all defective parts that cannot be replaced by in-the-field warranty personnel. Otherwise, there is a 3- hour turnaround time on warranty work for hardware. Thus, mitigation will be to utilize vendor warranty services.

  Software failure ”It is anticipated that there is less than a 1 percent chance of the software incorrectly working, provided it is configured correctly. Risk protection involves developing a configuration burn document ahead of time and validating it through the software company to make sure that all correct steps are followed and all service packs and security patches are applied in the correct order. Mitigation means that a re-burn would have to happen after it was determined what went wrong in the first place.

  Internetworking gear failure ”Mean time between failure (MTBF) history shows a less than 0.2 percent chance of a failure on all new router and switchgear that s deployed in the field ”regardless of international location. Mitigation involves warranty replacement (3-hour window) by contract field personnel.

  Programming errors ”The vendor has provided documentation on several other intranet sites he has created and he stipulates that there is less than a 1 percent chance of anything going wrong because he s going to follow the same development characteristics on the same platforms as he s worked with before. However, he has put a warranty stipulation in his SOW that details he will thoroughly test and validate that all systems are working as advertised before he receives his last 50 percent payout .

  Procurement Plan Server Gear: Bids and SOWs received will determine the winning server hardware vendor. Terms: Net 30. Order will include Windows Server 2003 and 25-client license pack as well as comprehensive customer service plan. Vendor has complied with the hardware you specified with no substitutions. Servers shipped to respective locales to avoid additional delivery charges.

  Telecommunications Gear: Provided by respective telecommunications providers upon signing of provision agreement contract (Kim Cox).

  Internetworking Gear: Bids and SOWs received will determine the winning internetworking hardware vendor. Terms: Net 30. Order will include routers, switches, software, network cabling and electrical cabling appropriate for the country the gear will reside in. Internetworking gear shipped to respective locales to avoid additional delivery charges. Internetworking contractors for each country obtained through a reference obtained from the winning internetworking company. Intranet contractor: Ads in San Francisco Chronicle and Napa News soliciting bids for contracting work. Sealed bids will be received after a show-n-tell session held at Chaptal headquarters describing the nature of the work.

Summary

Human resource planning identifies the specific resources that will be assigned to your project as well as how and when they will join the project team and be returned to their functional department. Quality planning determines the quality standards that the project will be measured on and defines how that will be accomplished. Risk planning covers the identification of risks to your project, the quantification of those risks, and a response plan. Communications planning names the people or groups requiring information on the project, the specific information required by each group , and how that information will be provided. Procurement planning is completed if any goods or services for the project will be provided outside the organization. Procurement planning involves a make or buy analysis, a SOW, vendor bid solicitation, and vendor selection criteria.

If you think about the above paragraph, the sum total describes how youre going to work with the people who will bring about the project. You identify the team members who will participate. You determine how people will ascertain the quality levels and how they will keep those levels to customer expectations. Risk identification and mitigation strategies show that people have put some effort into thinking about the problems a project could encounter and have come up with ways to avoid those problems. Your communications plan illustrates how youre going to make sure everyone is in the know regarding the project. And your Procurement plan describes how youre going to interface with people to obtain the goods and services you need to start the project and keep it going. So, if you take the tack that your planning process focuses on people, and you think about the needs those people will have relative to your project, youll be successful.

Exam Essentials

Be able to name the two major components of human resources planning. The human resources planning processes are organizational planning and staff acquisition.

Know the four techniques used to determine what quality aspects to measure. The four most commonly used techniques are cost-benefit analysis, benchmarking, flowcharting , and cost of quality.

Be able to name the types of cost of quality. The types of costs are prevention costs, appraisal costs, and failure costs.

Explain the three processes used to develop a risk management plan. Risk identification is the process of identifying and documenting the potential danger areas in your project. Risk analysis evaluates the severity of the impact to the project and the probability that the risk will actually occur. Risk response planning is the process of reviewing each item on the prioritized list of potential risks impacting the project to determine what, if any, action should be taken.

Know and understand the information to include in a communications management plan. A communications plan identifies the audience, objective, medium, responsibility, and frequency.

Be able to name the types of contracts. Contracts can be fixed price, cost reimbursable , or time and materials.

Key Terms

Before you take the exam, be certain you are familiar with the following terms:

appraisal costs	prevention costs
benchmarking	procurement planning
communications planning	quality management plan
contract	quality planning
cost of quality	risk
cost reimbursable contract	risk analysis
failure costs	risk identification
fixed price contracts	risk planning
formal communications	risk response planning
human resources planning	sole source
informal communications	solicitation
make or buy analysis	staff acquisition process
metric	staffing management plan
organizational planning	statement of work (SOW)
planning	time and materials contract
preventative action

Review Questions

1. What are the processes that you use for human resources planning?
   1. Staff acquisition
   2. Contract administration
   3. Organizational planning
   4. Performance reporting
2. You have been assigned as project manager for a major software development project. Andy is the functional manager who will be providing the resources for your development team. Andy is being asked to supply resources to several projects concurrently. You have a list of the people you want assigned to your team, but you fear other project managers may want these same people. How should you approach Andy regarding the assignment of his people to the project? Choose the best answer.
   1. Schedule a meeting with Andy to discuss resources. Explain your project deliverables and the skill sets you need. Negotiate for your most critical resources first. Negotiate with Andy.
   2. Send Andy a memo listing the resources you need and the start date for each resource.
   3. Catch up with Andy just before a meeting both of you need to attend so that he will not have time to think up reasons to turn down part of your request.
   4. Meet with Andys boss to let her know that your project is critical and provide her with the list of resources you need from Andy.
3. A quality technique that analyzes similar activities as a means of comparison is:
   1. Cost-benefit analysis
   2. Corporate quality policy
   3. Flowcharting
   4. Benchmarking
4. The total cost of all the work required to assure the project conforms to quality standards is referred to as the cost of quality. Which of the following are types of costs associated with quality?
   1. Failure costs
   2. Prevention costs
   3. Appraisal costs
   4. All of the above
5. Risk identification is the process of:
   1. Quantifying the impact to the project of a potential problem
   2. Determining and documenting potential danger areas in your project
   3. Assigning a probability that a particular problem will occur
   4. Defining the action to take in response to a potential risk
6. What types of activities are documented in a risk response plan?
   1. Risk probabilities
   2. Preventative actions
   3. Contingency actions
   4. B and C
7. Communications planning is the process of:
   1. Scheduling a regular meeting for the project team.
   2. Developing a distribution list for the stakeholders
   3. Identifying the people or groups who need information on your project
   4. Creating a template to report project status
8. You are the project manager for a new software application that will provide online help to sales consultants regarding the features of the products they sell. One of your stakeholders is the VP of sales, who has committed to a 5 percent increase in product revenue based on this tool to assist his sales team. You have an opportunity to present an overview of this project to the VP. Based on the why, what, how, and when categories in the stakeholder engagement template, which of the following would be appropriate messages in the presentation?
   1. A summary of the detailed technical design.
   2. A demonstration of how the help function is accessed and the type of product in formation that is displayed.
   3. An overview of the programming language used to develop the code.
   4. A review of the plans to involve a small group of sales consultants in a pilot of the application to identify any concerns before the system is deployed to 4,000 users.
9. The technique of looking at the trade-offs between doing something internally and procuring it from outside the organization is referred to as:
   1. Cost estimating
   2. Vendor selection criteria
   3. Staff augmentation
   4. Make or buy analysis
10. You are a project manager for a telecommunications company assigned to a project to deploy a new wireless network using a technology that does not have a proven track record. You have requested vendor bids for portions of the development that will include researching various scenarios. What type of contract is the most likely in this situation? Choose the best answer.
    1. Fixed price contract
    2. Time and materials contract
    3. Cost reimbursable contract
    4. None of the above
11. Youre stuck with a hard project end date and your budget is fixed. If you dont manage the project extremely well, which component is most likely to suffer?
    1. Project plan
    2. Quality
    3. Documentation
    4. Project book
12. Who is responsible for identifying and mitigating risk in the project?
    1. Sponsors
    2. Stakeholders
    3. Project manager
    4. Corporate management
13. Youre well under way with a major project when one of your development engineers alerts you to an unforeseen problema delay in the procurement of a specific piece of hardwarethat is going to require a significant addition of time to the deadline of the project. What should you do? Please select the best answer(s).
    1. Adjust the timeline of the project and notify the stakeholders.
    2. Consult your risk assessment and mitigation strategies for this risk.
    3. Adjust the timeline of the project and notify the sponsors.
    4. Adjust the timeline of the project and obtain sign-off from the sponsors.
    5. Tell the engineer that he must complete the project on time.
    6. Add developers to the project.
14. Who is responsible for accepting or not accepting the risks associated with a project?
    1. Project sponsors
    2. Project stakeholders
    3. Project client
    4. Project manager
15. You are the project manager for a large, complex project that is in the middle of an 18-month estimated timeline. Some important vendors are now entering into the delivery of key project parts (servers, cabling, etc.). What crucial part of project planning will now play out as you take delivery of the components ? Select all that apply.
    1. Procurement planning
    2. Human resources planning
    3. Communications planning
    4. Risk planning
16. Why do you spend time developing a solid communications plan? Select all that apply.
    1. To set and meet stakeholder expectations.
    2. To set aside time for your own needs.
    3. To make sure vendors are in the loop.
    4. To understand where the blame lies when something goes wrong.
    5. To keep company executives updated on your progress.
17. When developing projects, your company has determined that quality is the most important of the three elements that affect any project (time, money, quality). What corporate strategy would assist with such a mandate ?
    1. Project management plan
    2. Corporate quality officer
    3. Corporate quality policy
    4. Project manager bonuses
18. Your project involves a complicated system that enables communication among several disparate systems. What component of the project planning may require additional (perhaps substantial) communications work on your part with team members and stakeholders in order to clearly elucidate the complexity of the project?
    1. Deliverables
    2. Project end date
    3. Budget and additional resources
    4. Risk assessment
19. Youre the project manager for a project in which youre following a specific software development methodology. Some of the developers went to a presentation by a well-known company that manufactures software development software. They saw a new coding technique that could improve the speed with which the code will be developed and ready. They come back energized and ready to shift everything over to the new coding paradigm. How should you handle this recommendation?
    1. Since theres a cost/time-savings benefit, go with the recommendation.
    2. Obtain project sponsor approval to implement the new methodology.
    3. Run the recommendation through the change-management process.
    4. Development methodologies arent something that the project manager needs to be concerned with.
    5. Assess the risks of adopting the new development methodology. If acceptable, go forward.
    6. Nix the idea and save for the next project.
20. In your risk assessment activities, why would it be more important for you to evaluate potential risks for steps in the critical path than for those steps that are not? (Choose the best answer.)
    1. Steps in the critical path directly affect the projects duration.
    2. Steps in the critical path are the most critical to the projects successful outcome.
    3. Steps in the critical path are those that are the most time- intensive .
    4. Steps in the critical path are those that are the most complicated.

Answers to Review Questions

1. A,C. Organizational planning is the process used to define roles and responsibilities for project team members and a plan to manage the project team. Staff acquisition is the actual assignment of people to the project team.
2. A. Obtaining the right resources for your project requires good planning and skillful negotiation. An individual meeting with each functional manager who will be providing resources is the best approach. Although you identify all the ideal resources you need, do not expect that you will get everyone you want. Negotiate for your most critical resources first and be willing to compromise. An assumption that the functional manager just needs your list or an attempt to obtain resources by circumventing the functional manager provides a perception that you do not value the functional manager and can create a poor working relationship.
3. D. Benchmarking is a technique that uses similar activities as a means of comparison. It is a good quality tool for projects designed to improve the current business operation. Cost-benefit analysis is another quality tool that looks at proposed quality activities to determine which one will provide the most benefit to the project at the least cost. Flowcharting uses diagrams that depict the way work flows. The corporate quality policy is an existing document that can provide information on existing corporate quality standards.
4. D. All of these are components of the cost of quality. Prevention costs cover activities that keep quality problems from occurring. Appraisal costs keep any product defects from reaching the customer. Failure costs include any work associated with the failure of the product.
5. B. Risk identification is the process of determining and documenting the potential danger areas in your project. Quantifying the impact to the project of a potential problem is risk severity. Risk probability deals with the likelihood that a particular problem will occur. Risk response defines the action to take in response to a potential risk.
6. D. A risk response plan contains preventative actions and contingency actions. A preventative action is an activity designed to prevent a risk from occurring. A contingency action is an activity designed to deal with the impacts of a risk that is out of your control. Risk probability is part of risk analysis. You must determine how likely it is that the potential problem will occur in order to prioritize your risks. Risk analysis is done prior to the risk response plan.
7. C. Communications planning is the process of identifying who needs to receive information on the project, what information they need, and how they will get that information. Scheduling project team meeting, developing distribution lists, and creating a project status template are all activities that might be a result of the communications plan.
8. B, D. The VP of sales is accountable for the increased revenue resulting from this application. He is concerned that the functionality the application will provide is easy to use and contains the data users need to close sales. He would also be interested in any processes that will ensure the system is ready for mass deployment. A review of the technical design and programmer language is more appropriate for functional manager stakeholders in the IT organization who are providing the people who will be doing the design and code work.
9. D. Make or buy analysis is the technique of determining the benefits of procuring goods or services outside the organization. Staff augmentation is the term used for contract labor that is added either for a fixed amount of time or to complete specific tasks . Vendor selection criteria are the items you use to evaluate and select a vendor.
10. C. A cost reimbursable contract is often the only option if you do not have a well-defined product or if the vendor is being asked to provide something that has not been done before. A fixed price contract would not be feasible for the vendor or the buyer, as there is not any historical information to use as a basis for the fee. A time and materials contract would also be problematic , as the vendor may not have enough data to know what type of resources will be applied to the contract.
11. B. If your budget and project end date are fixed, then the thing thats going to represent the point of variance will be the quality. Managing quality in such an environment can be very difficult.
12. C. It is the responsibility of the project manager to identify those risks associated with the project.
13. B, C. Youve encountered a risk to the project that you (hopefully) identified in your risk assessment process. The mitigation strategy shows that when the scope of the project has changed, which it has in this case due to the pushing out of the targeted completion date, you must obtain sign-off from the project sponsor. Adding developers wont help in this situation because the problems been determined and a solution proposed but there is a time requirement.
14. B. The stakeholders of the project (which includes the sponsor and the clients ) are the ones wholl have to live with any associated risks and need to be the ones who decide whether the risks are acceptable. On the other hand, it is up to the project manager to make sure he or she has assessed the risk situation and has come up with ways to avoid any pitfalls, as well as mitigation strategies to deal with risks that arise. Stakeholders should be made aware of the risks that were discovered at risk assessment time.
15. A, C, D. When you develop a procurement plan, you put out a request for bids and perform an analysis of the subsequent bids for the work. You should pay attention to the way that the vendor describes how the gear will be shipped, how it will be warranted, and how its safe arrival will be guaranteed . Thus procurement planning is critical to making sure that the long-term delivery initiatives pointed out above (18 months) will be met. Additionally, risk planning will help define those areas where problems may arise. While not necessary, you could certainly add communications planning details on how you'll interact with vendors .
16. A, C, E. While a nice advantage to a good communications plan is that you are able to carve out some time for yourself, it is not the reason you develop such a plan. Similarly, with a good communications plan, youll be updating the sponsor who, in turn , will update the executives, but your communications plan may not directly update them.
17. C. A corporate quality officer is probably a good idea, but how will she enforce quality if theres not a quality policy in place to start with? A project management plan should be in place for adhering to a corporate quality policy and the project manager might be lucky enough to work for a company that gives bonuses for superior project management quality.
18. D. When faced with an integrated system deployment, its wise to understand that the complexities can frequently be more plentiful than your team may at first be willing to admit. In an integrated systems project, it would be prudent to spend extra time on risk assessment as well as allocating extra testing time when connecting systems.
19. F. A methodology change involves in a change in the projects scope, which, in turn, involves sponsor sign-off and a brand new risk assessment. While it may be attractive to go forward with something that has the promise of saving you time, youve already settled on a given methodology that has sign-off and you should not experiment at this point in time with new techniques as youre not sure whether youd have a positive outcome.
20. A. The critical path is the series of consecutive activities that represent the longest dependent path through the project. Since a risk to a step in the critical path could potentially increase the time it takes to get the step done, it can directly affect the projects completion date. While its important that you strive to uncover as many risks as possible prior to the project getting under way, its very important that you pay special attention in terms of risk assessment to tasks on the critical path.