Planning and Acquiring Resources

Overview

We are well on our way to getting this project in motion. We now understand what the project is expected to produce and what the outcomes will look like, and we have an understanding of the logical order of the project work. We have identified resource types, and we have a highlevel idea of how long the project activities will take.

Now it's time to identify and assign the resources we need to complete the work of the project. This process includes identifying people (those folks who will perform the project tasks to satisfy the requirements of the deliverables) as well as equipment and materials. You may have already named some key team members and even involved them in the scope statement and activity definition phase. But it's difficult to identify and assign all the team members on a project team without knowing what the activities and tasks of the project are. Equally, you don't really know what resources are needed until you have a full understanding of what the product or service of the project looks like and what types of deliverables and tasks are needed to produce it.

This chapter discusses identifying and acquiring resource needs, including human resources as well as equipment and materials, and discusses techniques for negotiating or contracting for these resources if necessary. In this chapter, you will learn:

• Planning the project team
• Acquiring materials and supplies
• Contracting for resources

Planning the Project Team

One of your most important jobs as a project manager is building the project team. This is probably the most fun activity of all the project processes. But it doesn't end there; you also have to keep everyone working well together. Sometimes you get lucky, and you have a fabulous team that gels right from the beginning and works well together throughout the entire project. It's rare for this to happen without any intervention on your part, however, so don't think you're off the hook. Usually, great teams come about as a result of careful planning and consideration of skills, personalities, knowledge, and so forth. This chapter discusses finding and matching the skills of team members with project tasks, while Chapter 10, "Executing the Project," will deal with team building and motivational issues.

There are several things to consider when thinking about what resources you need for your project. Organizational policies regarding job descriptions and the transfer of employees from one manager to another are one example. For instance, I work in a government agency that has strict, formal procedures for transferring employees among departments. Job descriptions are also rigid and formal without much room for flexibility. In order to recruit resources from another area for one of my projects, I need to follow the organizational policies and make certain the job description adequately reflects the work of the project.

Recruitment policies are something else to keep in mind, especially when you know you're going to hire some or all of the resources for your project from outside the organization. Some organizations have policies regarding hiring practices that must be adhered to or you'll never get the resources on board that you need. Perhaps your organization uses one or two recruiting agencies to assist in the recruitment process. You'll want to get to know those folks so you can describe for them the skills and knowledge needed for the project. Some organizations have policies against recruiting family members, for instance, or even close friends. Others welcome your friends and family with open arms. Be aware of the recruitment policies and make certain that you're following through with all the necessary paperwork. There's nothing like assuming that your new team members will be raring to go on Monday morning, only to find out that the Human Resources department is still waiting for sign-off from you or your manager on some important document before they can make the offer!

Aside from the organizational and recruiting policies, you should consider several things when planning your project team, including:

• Skills needed for each task or group of tasks
• Ability to learn new things
• Knowledge
• Personality
• Availability
• Experience
• Ability to work well with others

We'll explore each of the areas in depth in the next few sections. Before we jump into them, let's look at a department-wide skills assessment.

Skills Assessment

skills assessment

A document that details the skills each team member possesses and their experience level in those skills.

One of the first places you might want to start planning your team resources is with a skills assessment of your existing staff. If you know that you're going to be using people from your own department or from some of the other functional departments in your company, you should think about putting together a skills inventory like the one shown in Table 6.1 below.

You can use this table as a template to develop your own skills inventory for your department members. This example is the actual form I use to record my team's skills and training. As you can see, the table lists employees' names, skills, degrees and certifications obtained, and experience in years at the listed skill. Once you gather this information initially, I recommend updating it on a yearly basis. Incorporate an update of this inventory as part of your annual performance review process. Ask team members to update you on training and additional experience in their areas of skill, and then plug it into your skills inventory. This way, you'll know at a glance who has what skills, and it will make assigning internal resources to tasks one step easier.

Now down to specifics—who do we need for what tasks?

Deciding Who s Needed

Imagine that you have been appointed the project manager over a new product launch for your company. You work for a software development company that specializes in the insurance industry. With the advent of wireless technology, the field representatives have started asking for a new program that allows them to access account information from their handhelds and laptops when they're at their client's site. You are heading up this project.

Since you've already defined the work of the project through the scope statement, WBS, and task identification processes, it's time to find the right people for the right tasks.

Determining Potential Team Members

We know from our skills inventory in Table 6.1 that Jason has programming skills, Leah can help with the database development, and Aziel can do the technical writing we need for this project. All other potential team member names will be determined from our skills inventory as well (our example skills inventory shows only a few of the names available).

Now we'll use the RAM we developed in Chapter 5, "Breaking Down the Project Activities," and the skills inventory of your existing staff from Table 6.1 to construct a chart like the one in Table 6.2 to help match skills to people. The first column shows the task or work package detail, followed by the type of skills needed to complete this task, the level of experience necessary, and finally the team member assigned to this task.

This is another template that you can use or modify to suit your needs. Remember for all these templates to add the General Information section at the top so that the name of the project, date, and so on are associated with the chart.

You may have more than one person who fits the qualifications for each task. If so, list their names in the Potential Team Member box. At this point, you don't know their availability, so if you're requesting Paul to work on the "Determine platform and languages" task and it turns out that Paul is not available, you know that Ross also meets the qualifications for this task. You don't have to backtrack and figure out who else is available since you've defined all the potential candidates here.

Don't forget to list all the resources you'll need for the project on your skills definition chart. The example in Table 6.2 focuses on one type of resource, but you'll need resources from other areas of the organization such as finance, procurement (to assist with vendors and contract work), training, marketing, human resources, customer service, and so on.

If you're working on a medium-to-large project, you may want to consider adding a column to this chart that indicates the number of resources you need for each task. A project of this size will likely require five or six programmers with similar skills but varying levels of experience.

You may find that you don't have enough resources in your own department to perform all the tasks. That means you'll have to discuss the availability of resources from other departments with the functional managers in those areas, or hire the resources, or contract the resources for the length of the project. After you've identified the potential team member names, it's time to meet with the functional managers and begin negotiating for the resources you need.

Negotiating for Team Members

Unless you work in a projectized environment and have control over all the resources in the company, which few of us do, you'll have to negotiate with other managers for resources. This can include negotiating for folks from the finance department to help determine and track the budget, for programmers, for customer service personnel, and more. The types of people you will negotiate for depend on the skills you identified in the previous section.

The next step is a visit to the functional managers. I'd send ahead a copy of the project charter for them to review before you meet with them. This gives the manager the opportunity to see what the project is all about, informs them that the executive management team is behind the project, and helps them to begin figuring out who from their department might be the best fit for the project.

Meeting with the Functional Managers

Depending on the culture of your organization, you may need to set up a face-to-face meeting with each manager, or you might be able to send e-mail detailing your request for resources. In either case, you'll want to have completed the WBS and identified the tasks that you need the resources to work on. The functional managers will want to know what types of work you have for their employees and how long you'll need them. That's one place where the activity duration estimates come in handy.

Buyer beware! Functional managers may see this as their opportunity to hand off a less-than-ideal employee. You're not interested in inheriting problems; you want folks who are willing and able to do the job. Ask the functional manager specific questions about the people they're recommending for the team, such as the following:

• Does this person have experience at this activity?
• Is their experience in keeping with the level of complexity of this project? Ask for some examples of their past work.
• What kind of training and/or certifications does this employee have?
• What are their personal interests?
• What about personal characteristics?
• Is this person interested in working on this project?
• Has this person worked successfully with a variety of team members in the past without complaints from the other team members?
• Are there any outstanding personnel actions against this employee you should know about?

The answers to these questions will help you determine whether the folks they're recommending are the right people for the job. While you aren't always going to get all the star employees, you surely don't want to be stuck with all those "retired on the job" types either.

Team members who are needed from the beginning of the project should be assigned to the project now. People with specific skills who are needed intermittently on the project, or maybe aren't needed until close to the end of the project, can be assigned as they are needed. However, at this point you don't yet have the project schedule completed (Chapter 8, "Developing the Project Plan," talks about creating the project schedule), so you don't have specific dates and times when the special resources are needed. Tell the functional managers what you do know—tasks, estimated durations, types of resources, and an estimate of when you think you'll need the resources to be available. Let the functional managers know that you'll give them the specific details regarding the need for people with those unique skills when the project schedule is completed. In the meantime, the functional managers should keep those resources available within the estimated time frames you think you're going to need them.

Staffing Assignments

Now you're ready to assign names to the tasks. Like most everything we've done so far, you'll want to document this information. You could simply update Table 6.2 to reflect the actual team member name in the last column or construct a new sheet with the tasks down the left and resource names listed next to them. In the case of those highly specialized folks with unknown availability, you can put their manager's name next to the task temporarily until you have an actual resource identified.

Experience and ability are only part of the picture when making staff assignments. Personal interests and characteristics should be considered when making team assignments as well. Unfortunately, some employees are picky about who they work with. If someone has made mortal enemies out of some of the team members on the last project they worked on, you probably don't want this person on your team. However, you may not have a choice, as this person is the only person available with the specific skills you need. If that's the case, try to manage their time and assignments so that their exposure to other team members is minimal.

Another factor to watch out for is team members who don't want to work on the project. They may be terrific at the job they came from but have little interest in your project; therefore, their performance will be less than stellar. As the project manager, it's up to you to motivate them and rally the team around the project's purpose. We'll talk more about how to motivate, reward, and recognize team members in Chapter 10.

Defining Training Needs

What happens when your resources don't quite measure up to the skills needed and you don't have the money to hire consultants? There are a couple of ways you can deal with this. Encourage the senior project team members to act as mentors to the junior members, allowing the junior members to learn and ask questions of the senior team members. Don't forget to account for additional time on the project activity estimates if this is how your project team is structured.

Outside training is another option, depending on the skill you need the team member to acquire. You'll have to weigh this option to determine whether the investment in training is worth the payoff. For example, if you're working on a small project of a short duration, it would probably make more sense to lengthen the project schedule to give an experienced team member the time to complete that task rather than training someone else to perform the task. In the case of our software project for the field reps' handheld PCs, suppose we have senior-level programmers with lots of experience writing programs for regular desktop PCs but no experience writing software for wireless devices. You could hire a consultant with expertise in this area to come in and work with your senior programmers to show them the ins and outs of wireless communication. Since the senior programmers are seasoned professionals, all they need is a little boost in this one area of expertise, so the benefits of hiring a consultant outweigh the costs.

Creating the Project Team Directory

project team directory

Directory of contact information for everyone involved in the project.

This is a good time to construct a project team directory. The directory lists the names and contact information for all the stakeholders, the project sponsor, all the team members, and any vendor contacts working on the project. I would include the team directory as an appendix in the project notebook.

If most of the folks you're assigning to the project are from your own department, you're probably ready to hold a team kickoff meeting. If you've recruited folks from other departments and they aren't scheduled to start on the project until after the work begins, invite them to the team kickoff meeting so that they have the benefit of hearing the project overview and goals with all the team members present. We'll discuss the project kickoff meeting in more detail in Chapter 10, including what information you should cover with the team in this meeting.

Acquiring Materials, Supplies, and Equipment

Now that you know the tasks required to complete the deliverables for your project, you're ready to fill out your supplies list. As we discussed in the resources section earlier, you can't really know all the materials and supplies you're going to need for the project without having first defined the tasks. If one of your tasks involves calibrating some machinery, for example, how will you know what kind of equipment you'll need to perform the calibrations until you've defined the tasks?

Defining the materials and supplies, along with the human resources we've already outlined, will help you estimate the costs of the project and determine a budget. After defining the materials list, you'll also be able to decide where the resources will come from—will you buy them, lease them, or contract them? First though, there are some questions you should ask.

Questions to Ask

Pull out your copy of the WBS. This is the first place you're going to look to start compiling your materials list. The tasks defined on the WBS dictate the kinds of materials, supplies, and equipment you're going to need for the project. Let's go back to our example project at the beginning of this chapter. You're heading up the development and implementation of a new software program for the field representatives for an insurance company. Some of your WBS tasks include "Define program requirements," "Determine languages and platform," and "Design programming modules."

Starting with these requirements, we can begin to ask some questions: What kind of hardware will we need in order to write the programming code? What kind of hardware will we need in order to test the programs? Should we use the equipment the field reps use? If so, what kind of equipment do they have? Are they, or should they be, upgrading the field equipment prior to implementation of the new programs? What software is needed to assist with design, coding, and testing?

Don't forget to also explore questions regarding facilities, new technologies, and services you might need. Since this particular project involves wireless communications, ask questions such as these: Does the company already subscribe to a wireless satellite communication provider? Do they have the means to supply their own services?

What about facilities? Does the project team work at the same location? If not, do you need a common meeting place to kick off the project and meet on a periodic basis? Should the team work at the same location? If so, what types of resources are needed to make that happen?

Spend some time brainstorming with your team and some of the key stake-holders to determine the resource needs of the project. And as you've probably already guessed, you'll want to document these needs. You can construct a simple document like the example shown below, noting the amount of resources you're going to need, whether the resource is available or must be procured, and so on.

You could consider adding another column to this template that identifies potential vendors or suppliers. In this example, all of the resources listed are going to be procured from a vendor, so listing possible vendors or contractors on this table would make sense. Modify this template to suit your project needs, and file a copy in the project notebook for future reference.

Make or Buy

This question won't always apply to your projects, but it could apply to certain aspects of your project. The question is, should we make or buy the products or services needed for the project?

Make-or-buy decisions involve determining whether it's more cost-effective for the organization to make or buy the products or services of the project. This decision can be made at the individual resource level, or for an entire deliverable, or even for the project itself. Some projects are too cost-prohibitive for the organization to take on internally, and it makes the most economic sense to outsource the project. Make-or-buy decisions regarding the entire project usually happen back at the Initiation phase of the project.

There are several things to consider regarding make-or-buy decisions. Obviously, the biggest factor is cost. You should take into account the costs to produce the product or service—goods, materials, equipment, facilities, employee salaries—as well as the indirect costs. Indirect costs include such things as training costs, management costs, administrative overhead, and ongoing maintenance. Compile all the costs associated with producing the product or service before you compare it to the cost to outsource it or buy it. Ongoing maintenance and change-order costs are costs that are often overlooked in make-or-buy decisions, so be sure to include those in your analysis.

Other things you should consider that aren't necessarily driven by cost alone are issues like capacity—can the organization take on a product of this magnitude? What about the skill level of the folks who'll work on the product or service? Do they require extensive training, or can they produce the product or service without much forethought? Consider things like process controls and trade secrets. If you can't divulge the secret ingredients of the magic formula, you probably can't outsource the production of the magic formula to a vendor. Also consider the availability of your staff and the existing workload. If your staff is buried in a backlog of top-priority projects, it isn't likely that they can take on the production of a new product or service at this time, so buying the products or services needed might be the most beneficial solution.

The goal of this process is to decide whether making or buying the products or services of the project is the most cost-effective and efficient for the organization. Remember, this can involve only one product or deliverable or the entire project. When it is necessary to procure goods and services, you'll want to prepare a procurement plan.

Procurement Plan

Some organizations have departments that handle the procurement process and have long lists of established policies regarding purchasing goods and services. They may have lists of vendors for you to choose from, or they may require an extensive bidding process to take place (depending on what you're buying). And, depending on the amount you're spending, there may be certain procedures in place that require multiple signatures and/or multiple reviews of the requests. Other organizations may have simple guidelines regarding their purchasing policies. These might include signing authority limits that depend on your title or function in the organization.

As the project manager, it's important for you to know and understand the procurement process for your organization. If there are extensive rules to follow and you miss crossing a T somewhere along the way, the holdup could cost you time on the project schedule and potentially money as well.

procurement plan

Describes the resources or services to be purchased from an outside vendor.

No matter what your procurement policies might be, you'll want to create a procurement plan for the items you're purchasing for your project. The procurement plan can be as simple as listing the service or resources needed, the quantity, the price, and the vendor who'll be supplying the services in a spreadsheet format similar to the graphic shown previously. Or, the plan can be very detailed, including deliverables, requirements, dates, and so on.

statement of work (SOW)

A document used in the procurement process to detail the work of the project and used by the vendor to assess whether they should bid for the contract.

The statement of work (SOW) could be prepared in conjunction with the procurement plan or in place of the procurement plan if you're purchasing all your goods and services from one vendor. Remember that the scope statement we talked about in Chapter 4, "Defining the Project Goals," can also be used as the SOW. The scope statement is usually used for the SOW when you're outsourcing the entire project.

Resource Plan

Resources include people, equipment, supplies, and software—anything that's required to complete the work of the project. We've now defined all the resources of the project including the skills assessment, skills definition by task, staff assignments, and physical resources needed for the project.

resource plan

Describes all the resources needed for the project, including human resources and goods and materials.

All of this information collectively is known as the resource plan. As stated, the resource plan covers all the resources you need for the project. You should devote a section of the project notebook to the resource plan. I would include the procurement plan as a subset of the resource plan. You're probably beginning to see how the project notebook is going to help you in the future. When you're assigned to a new project that's similar in scope to a project you've already completed, you'll be able to use the information you filed in the project notebook as a reference for the new project. Why reinvent the wheel? You can use the resource plan from this project to help you document a resource plan for the new project. At the very least, reviewing this information will trigger questions or ideas for the project plans on the new project.

The resource plan might include purchasing some or all of your products or services from an external party, which may require the use of a contract. We'll wrap up this chapter with a discussion of the contracting process.

Contracting for Resources

Project managers often purchase goods or services on contract. Many organizations have departments that handle contract negotiation and fulfillment, but this doesn't mean that you can sit back on your heels and let someone else do the work. As the project manager, you should have an understanding of the contracting process. You're the one who will be communicating with the vendor regarding the work of the project, and you are also the one who will report the status of the work to the procurement department or the contract manager so that payment can be made to the vendor. Many times, contracts are paid incrementally according to the milestones or deliverables listed in the contract. Payment is authorized when the milestones are reached and sign-off is obtained. The project manager is the one who notifies the procurement department when the milestones have been reached.

The contract manager is not the project manager, so they'll be looking to you to make certain the items outlined in the contract are completed satisfactorily. That means you'll monitor the vendor's performance to make sure it measures up to the terms of the contract. When it doesn't, you'll have to work with your procurement department to document the problems, notify the vendor, and then take corrective action or terminate the contract. If you're administering the contract, these duties will fall to you.

As the buyer of the goods or services, you'll want to create the SOW to make certain the requirements are defined accurately and that no important deliverables are missing. The vendor or supplier will use the SOW to determine whether they can fulfill the terms of the contract (they'll do this during the next cycle, which we'll get to in a moment). The WBS is developed at this time as well, cost estimates are determined, and make-or-buy analysis is performed.

contract life cycle

Contracts progress through specific phases similar to a project life cycle. The phases of a contract life cycle include requirement, requisition, solicitation, and award.

Contracts have a life cycle of their own, just as projects do. The four contract life cycles are requirement, requisition, solicitation, and award. We've already covered the things that occur in the requirements cycle. This is where the SOW is created and both parties agree to the requirements and deliverables of the project. If you follow the guidelines for writing the scope statement, you'll end up with a clear and concise SOW that accurately describes the work of the project.

Request for Proposal and More

Requisition is the next contract life cycle. In this process, you'll reconfirm that the project objectives are accurate and make any necessary corrections. The primary purpose of this process is to prepare requests for information regarding your project objectives and deliverables for the vendors who will be bidding on the project work. You'll actually distribute this information to the potential vendors in the next cycle, the solicitation process.

request for proposal (RFP)

Procurement document used to solicit input from vendors when purchasing goods or services or outsourcing project work.

You'll use the project objectives and the SOW to help you prepare requests for information from vendors. These requests are called requests for proposals (RFP), requests for information (RFI), and requests for quotations (RFQ). The idea here is to outline the project objectives in a way that allows the vendors to determine whether they can perform the work accurately and satisfactorily. Again, check your organization's policies regarding RFPs and such. They may require you to use predesigned forms and follow specific steps in order to complete and post the RFP.

Here's another controversy you'll likely find yourself in the midst of during the RFP process. Some project managers believe that the RFP should outline every detail of the project. For example, if you're contracting a new software program, the RFP would dictate the programming language to use, the operating system, the database to use, etc. Other project managers might say that this boxes the vendor in and doesn't give them any flexibility to offer creative solutions. And, the organization doesn't have the chance to approach the project from a new or different perspective because the project specifics have already been dictated.

Still other project managers use both of these approaches depending on the project—I think this is the best approach. If you have a solid idea of the way the project should go, and you do have specific requirements regarding operating systems or other details, then put that in the RFP. If you're not certain how the project should come together and prefer to rely on the vendor for input or want to examine alternative approaches, go heavy on the requirements and objectives of the project and let the vendor detail their alternative solutions in the response to the RFP.

One thing to keep in mind regarding RFPs, particularly for technology-type projects, is that technology changes so quickly in some areas (like telephony, for example) that you might require certain equipment or software in the RFP that is actually outdated by the time the vendor completes the project. Be choosey about the types of requirements that must meet certain specifications, and give the vendor a little room to come up with some interesting alternatives.

Soliciting Bids

This contract life-cycle process is where the vendors respond to the RFP, RFI, and so on. Essentially, vendors are competing for your business in this process and are putting their best foot forward by addressing all the requirements you outlined in the RFP. Most of the work in this process falls on the vendors.

Some organizations require vendors to register with them on a vendor's list before they can participate in the RFP process. The vendor is required to provide information regarding their experience, the services or goods their company offers, prices for standard offerings where appropriate, a list of the officers in the company, and so on. The procurement department then reviews the vendor's qualifications and determines whether to put that vendor's name on the organization's qualified vendors list. These vendors lists are usually updated on a yearly basis, and typically only vendors on the qualified vendors list are allowed to participate in the bidding process.

The RFP is posted or released, and a deadline for responding is announced at the same time. Vendors obtain copies of the RFP, read over your requirements, and set about writing their responses. Before they submit their responses, however, they'll want to ask some clarifying questions.

Sometime after the RFP has been released, you should hold a bidders conference or meeting that allows the vendors to ask questions about the RFP in an open forum. Depending on your organizational policies, you and others on your team might be restricted from speaking with the potential bidders until after the RFP process has been closed. The exception to this is the bidders conference where all participants have a chance to ask questions and hear your responses all at the same time, so no favoritism is shown.

Make certain to use a method of advertising that gives every bidder the opportunity to know about the conference ahead of time. The bidders conference could be announced on your company's website, in professional journals, or in newspapers, depending on your procurement policies. Another alternative is to advertise the bidders conference at the same time you release the RFP. If you don't have the bidders conference scheduled yet, let them know where and when you'll be advertising that information.

Choosing a Supplier

The last life-cycle process is the award cycle. This is where you'll review the responses to the RFPs, choose a vendor, and award a contract.

There are several methods you can use to help you choose among the RFP responses and make a final award. Usually a selection committee is assembled for this purpose, and together the committee reviews and ranks the responses using one of the following methods.

Weighted Systems

weighted scoring models

Used in the procurement process and the project-selection process to weight and rank various criteria and make a final selection.

A weighted scoring model or weighting system is a great tool to use for scoring RFP responses. It's an objective tool and assures that all the selection committee members are using the same criteria to evaluate the responses.

Typically, the project selection committee decides on the criteria they'll use for the scoring model prior to receiving the RFP responses and often this is provided in the RFP itself so the vendors understand what they will be judged on. Suppose our example wireless project is going to be outsourced. In the RFP we've specified certain development environments that the vendor must work within because of compatibility issues with other programs. Because of the importance of the new program's compatibility with existing systems and programs, the selection committee has determined that this should be one of the criteria that's weighed in the decision process. Other criteria are determined based on their importance to the project and the selection committee.

Each of the criteria is assigned a weight, depending on the importance of the criteria to the committee—the higher the importance, the higher the weight. Each vendor's response is then read and scored according to the criteria detailed on the scoring system. Here, individual judgment comes into play as each selection committee member scores the vendor response to each criterion based on their own perception of how well the RFP addressed that particular issue.

Table 6.3 shows a sample portion of a weighted scoring model, with the criteria listed in the left column, the weight for each criterion in the next column, followed by the rating and scores for each vendor.

The rating for each criterion is multiplied by the weight to come up with a score for that criterion. All the scores for a vendor are added together to come up with a total weighted score. The highest scoring vendor receives the award. In the example shown in Table 6.3, Vendor A is the winner of the bid.

Screening Systems

screening systems

Used in the procurement process to outline criteria that must be met in order for a proposal to make it to the next level in the selection process.

Screening systems are used to screen out proposals that don't meet predetermined criteria. For example, our wireless software project requires a specific platform because of compatibility issues with existing hardware and software. The platform requirement could be used as a screening criterion. If Vendor A submits a proposal that outlines a different platform than what we specified in the RFP, they are immediately disqualified from the selection process.

The selection committee determines the screening criteria before the proposals are received. Screening systems are often used in conjunction with weighted scoring systems to make an award. For instance, the screening system criteria must be met before the proposal can proceed to the weighted scoring system process.

Awarding the Contract

The last step in this process is actually awarding the contract. Your procurement department will likely draw up the contract, but you should be a part of this process. Make certain that the requirements listed in the RFP make it into the contract. Review the timelines, deliverables, requirements, etc., and request a copy for your records when it's signed.

You'll use the contract and the SOW to monitor the vendor's performance and assure that the agreed-upon deliverables are met. If they're not, you'll have to document the violations and assist the procurement department with enforcing the terms of the contract or terminating the contract when the vendor is in violation or refuses to correct their errors.

Terms to Know

• contract life cycle
• procurement plan
• project team directory
• request for proposal (RFP)
• resource plan
• screening systems
• skills assessment
• statement of work (SOW)
• weighted scoring models

Review Questions

Answers