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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
This is a starting point. Based on the specifics of your project, you can add other areas to this list.
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.
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.
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.
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.
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 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 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.
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:
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 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.
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:
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:
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 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:
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.
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:
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 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:
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:
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.
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.
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.
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:
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
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.
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:
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:
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.
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.
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:
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.
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.
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).
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.
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:
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.
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.
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:
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:
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.
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.
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.
Before you take the exam, be certain you are familiar with the following terms:
quality management plan
cost of quality
cost reimbursable contract
fixed price contracts
risk response planning
human resources planning
make or buy analysis
staff acquisition process
staffing management plan
statement of work (SOW)
time and materials contract
IT Project+ Study Guide
Answers to Assessment Test