Defining the Nine Knowledge Areas

,

The nine Knowledge Areas are part of the PMBOK and are all present in every project management life cycle. They define the processes within each Process Group and often are part of more than one Process Group. This section covers all nine Knowledge Areas. The names of the Knowledge Areas used here are the same as the names used by PMI.

Integration Management

This Knowledge Area addresses the glue that links all of the deliverables from the Process Groups into a unified whole. This linkage begins with the project description document and extends to the project plan and its execution, including monitoring progress against the project plan and the integration of changes, and finally through to project closure.

Scope Management

The major focus of the Scope Management Knowledge Area is the identification and documentation of client requirements. Many ways exist to approach requirements gathering and documentation. The choice of which approach or approaches to use depends on several factors. Following requirements gathering and documentation, you choose the best-fit project management life cycle and develop the Work Breakdown Structure (WBS) that defines the work to be done to deliver those requirements. That prepares the team and the client with the information they need to estimate time, cost, and resource requirements. The Scope Management Knowledge Area overlaps the Scoping and the Planning Process Groups.

Time Management

Time management includes both a planning component and a control component. The planning component provides time estimates for both the duration of a project task (that is, how long will it take in terms of clock time to complete the task) and the actual effort or labor time required to complete the task. The duration is used to estimate the total time needed to complete the project. The labor time is used to estimate the total labor cost of the project. The control component is part of the Monitoring and Controlling Process Group and involves comparing estimated times to actual times as well as managing the schedule and cost variances.

Cost Management

Cost management includes both a planning component and a control component. The planning component includes building the project budget and mapping those costs into the project schedule. This provides a means of controlling the consumption of budget dollars across time. Variance reports and earned value reports are used in the Monitoring and Controlling Process Group.

Quality Management

Good quality management is probably one of the Knowledge Areas that gets a rather casual treatment by the project manager and the team. A good quality management program contains the following three processes:

• Quality planning process
• Quality assurance process
• Quality control process

The focus on quality is usually on the product or deliverable that is produced. If it meets specific physical and performance characteristics, it will be validated as fit for use and can be released to the client. Validation that a product is fit for use is the result of the product passing certain tests at various points in the product development life cycle. Passing these tests allows the product to pass to the next stage of development. Failure to pass a test leads to reworking the product until it passes or to outright rejection if reworking the product to remove whatever defects were discovered does not make good business sense.

Quality in this context means the product meets the following criteria:

• It's fit for use.
• It meets all client requirements.
• It delivers on time, within budget, and according to specification.

Note that this says nothing about exceeding requirements. Many project managers are ingrained with the idea that they have to “delight the client.” For example, if you promised product delivery on Friday, you try to get the product to the client on Thursday. Or if you estimated that the product would cost $2.00, you try to get the cost down to $1.95. These are all well and good and are part of excellent client service, but they have nothing to do with quality. Quality refers to meeting agreed requirements, not exceeding them. Your quality management program should focus on meeting product and process requirements.

Quality Planning Process

There will be standards that the product and the process will have to meet. These may be external to the organization (federal or agency quality requirements) or internal (company policies and guidelines). In addition, there will be project-specific requirements that must be met. Quality planning must integrate all of these into a cohesive program.

Quality Assurance Process

Quality assurance includes activities that ensure compliance to the plan. The specific tools, templates, and processes that you use to do this are discussed in Chapter 15.

Quality Control Process

This process involves the actual monitoring of the project using the quality tools, templates, and processes discussed in Chapter 15 as well as other project management monitoring and reporting tools.

Human Resource Management

Some would suggest that the job of the project manager is to manage the work of the project. They would add that it is not the job of the project manager to manage the members of the team. Management of the team members is the province of their line manager. In a utopian world, this might be acceptable management practice, but in the contemporary project world, the situation is quite different. More than likely your request for a certain profile of skills and experiences among your team members will not be met by those who are assigned to work on your project. Skill shortages, unavailability of a specifically skilled person, and other factors will result in a less-than-adequate team. What you get is what you get, and you will have to make the best of it. Therefore, I don't think it is that simple, and both the line manager and the project manager share the people management responsibilities. Because the skills and/or competency of the team you have to work with may not be ideal, staff development will be one area where you and the line manager share responsibility. The line manager is responsible for assigning people to projects in accordance with each person's skill and competency profile as well as his or her career and professional development plans. Once a person is assigned to a project, it is then the project manager's responsibility to make assignments in accordance with the person's skill and competency profile and their professional development plans. Obviously this will be a collaborative effort between you and the line manager.

Having motivated team members is in the best interest of the project, the project manager, and the organization. It is my opinion that when you align people's interests and professional development needs to their project assignments, you gain a stronger commitment from the team members. Again, the line manager and the project manager share the responsibility for making this happen.

Not everyone can be motivated. To assume otherwise is risky. In fact, in most cases all that the manager can do is create an environment in which the subordinate might be motivated and then hope that he or she is. It's really like farming. All the farmer can do is pick the crop to plant, the acreage to plant it on, and the fertilizer to use, and then hope that nature supplies the right amounts of rain, wind, and sunshine. The same scenario applies to the project manager. He or she must create a working environment that is conducive to and encourages the development of the team members, leaving it up to them to respond positively.

Fortunately, you do have some information on what professional staffs perceive as motivators and hygiene factors on the job. Motivators are behaviors or situations that have a positive impact on the worker — they motivate the worker to better performance. Hygiene factors, on the other hand, are things that, by their absence, have a negative impact on performance, but don't necessarily motivate the worker if they are present. To put it another way, workers have certain expectations, and to not fulfill them is to demotivate them. These are hygiene factors. For example, workers expect a reasonable vacation policy; to not have one acts as a demotivator. Conversely, having a good vacation policy does not necessarily motivate the worker. The following list of motivators was created as a result of a 1959 survey of professionals by Frederick Herzberg,¹ a professor known for his research in motivational theory. Although the survey was conducted 50 years ago, it has become a classic study and still applies today.

Motivators

Herzberg identified the following motivators:

• Achievement
• Recognition
• Advancement and growth
• Responsibility
• Work itself

Hygiene Factors

Herzberg identified the following hygiene factors:

• Company policy
• Administrative practices
• Working conditions
• Technical supervision
• Interpersonal relations
• Job security
• Salary

Note that motivators are related to the job, specifically to its intrinsic characteristics, whereas hygiene factors are related to the environment in which the job is performed. The good news is that the manager has some amount of control over the motivators relating to the job. The bad news is that the hygiene factors, being environmental, are usually beyond the control of the project manager. As a project manager, you can bring hygiene factors to the attention of your senior management, but you're otherwise powerless to change them.

Motivating Factors

J. Daniel Couger, a professor of Computer Science at the University of Colorado, conducted a similar survey in 1988. Here the respondents were analysts and programmers. The responses were grouped by areas that the respondents considered motivators and areas that they considered demotivators. The following is a combined list of these areas, ordered from highest motivator to lowest motivator:

• The work itself
• Opportunity for achievement
• Opportunity for advancement
• Pay and benefits
• Recognition
• Increased responsibility
• Technical supervision
• Interpersonal relations
• Job security
• Working conditions
• Company policy

The motivators that are high on the list tend to be intrinsic to the job, such as providing opportunities for advancement and recognition, whereas the demotivators, which are lower on the list, tend to be environmental factors such as working conditions (for example, parking areas) and company policy (for example, sick leave and vacation time).

Several of the motivators are directly controlled or influenced by actions and behaviors of the project manager regarding the work that the team member will be asked to do. They are as follows.

Challenge

Professionals respond to a challenge. In general, if you tell a professional that something cannot be done, his or her creative juices begin to flow. Some may even view such a statement as an insult to their intelligence and creativity. The result is a solution. Professionals dread nothing more than practicing skills, long since mastered, over and over again. Boredom sets in quickly and can lead to daydreaming and lack of attention to detail, which results in errors. Challenging the professional does not mean that every moment of every day should be spent solving previously unsolved problems. Usually, an hour or two on a new and challenging task per day is sufficient to keep a professional motivated throughout the day.

Recognition

Professionals want to know that they are progressing toward a professional goal. Publicly and personally recognizing achievements and following with additional challenges tells the professional that his or her contribution is valued. Recognition, therefore, does not necessarily mean dollars, promotions, or titles.

Job Design

Because the job itself is such an important part of motivation, take a look at job design for just a moment. The following five dimensions define a job.

Skill Variety

Jobs that do not offer much task variety or the opportunity to learn and practice new skills become boring for most people. In designing jobs, it is important to consider building in some task variety. This variety, at the very least, can provide a diversion from what otherwise would be a tedious and boring workday. It can also provide a break during which the person can learn a new skill. With a little bit of forethought, the project manager can find opportunities for cross-training by introducing some task variety for new skills development.

Task Identity

People need to know what they are working on. This idea is especially true for contracted team members. The project manager should help them understand their work in relation to the entire project. Knowing that their task is on the critical path will affect their attitude and the quality of their work.

Task Significance

In assessing a task's significance, workers ask themselves questions such as these: Does it make any difference if I am successful? If I am late, will anybody notice? Just how important is my work to the overall success of the project? Am I just doing busywork to pass the time? Team members need to know whether their effort and success make any difference to the success of the project.

Autonomy

Professionals want to know what is expected from them — what are the deliverables? They don't want to hear every detail of how they will accomplish their work. That is blatant micro-management and must be avoided at all costs. It's okay to tell team members what they need to deliver, but not how they should go about delivering it. They want to make that decision themselves. Professionals tend to be rugged individualists. They want to exercise their creativity. They want freedom, independence, and discretion in scheduling their work and determining the procedures they will follow to carry it out.

Feedback

Good, bad, or indifferent, professionals want to know how effective they are in their work. Paying attention to what a team member is doing is motivating in itself. Having something good to say is even better. When a person's performance is below expectations, tell them. If you can convince them that they own the problem, ask them for an action plan to correct their marginal performance. Then help them do it.

Communications Management

At the heart of many of the top ten reasons why projects fail is poor communications. As many as 70 percent of the IS/IT project failures can be traced back to poor communications. It is not difficult to plan an effective communications management process, but it seems to be very difficult to execute that plan. A good communications management process will have provisions in the process that answer the following questions:

• Who are the project stakeholders?
• What do they need to know about the project?
• How should their needs be met?

Who Are the Project Stakeholders?

Any person or group that has a vested interest in the project is a stakeholder. Those who are required to provide some input to the project affect the project and are therefore stakeholders. They may not be willing stakeholders, but they are stakeholders nevertheless. Those who are affected by the project are stakeholders. Often they are the same group requesting the project, in which case they will be willing stakeholders. There will also be unwilling stakeholders who are affected by the project but had little or no say in how the project actually delivered against stated requirements. The project manager needs to be aware of all these stakeholder groups and communicate appropriately to them.

What Do They Need to Know about the Project?

There will be a range of concerns and questions coming from every stakeholder group. Some of the more commonly occurring are as follows:

• What input will I be required to provide the project team?
• How can I make my needs known?
• When will the project be done?
• How will it affect me?
• Will I be replaced?
• How will I learn how to use the deliverables?

Your communications management plan will be effective only if it accounts for each group and their individual needs.

How Should Their Needs Be Met?

This depends on the purpose of the communication. If it's to inform, there will be many alternatives to choose from. If it's to get feedback, you have fewer alternatives from which to choose. Chapter 6 provides all of the details on building an effective communications management plan.

Risk Management

In project management, a risk is some future event that happens with some probability and results in a change, either positive or negative, to the project. For the most part, risk is associated with loss, at least in the traditional sense. But there might be a gain if the event happens. For example, suppose you know that a software vendor is working on a language translator, and if it is available by a certain date, you will be able to use it to save programming time.

More commonly, though, a risk event is associated with a loss of some type. The result might be a cost increase, a schedule slippage, or some other catastrophic change. The cost of loss can be estimated. The estimate is the mathematical product of the probability that the event will occur and the severity of the loss if it does. This estimate will force the project manager to make a choice about what to do, if anything, to mitigate the risk and reduce the loss that will occur.

This estimate is the basis of a series of choices that the project manager has to make. First of all, should any action be taken? If the cost of the action exceeds the estimated loss, no action should be taken. Simply hope that the event doesn't occur. The second choice deals with the action to be taken. If action is called for, what form should it take? Some actions may simply reduce the probability that the event will occur. Other actions will reduce the loss that results from the occurrence of the event. It is usually not possible to reduce either the probability or the loss to zero. Whatever actions are taken will only tend to reduce the loss in the final analysis.

The business decision is to assess how the expected loss compares to the cost of defraying all or some of the loss and then taking the appropriate action. With project management, the risks that need to be managed are those that will hurt the project itself. Although the project may affect the total business, the total business isn't the domain of the project manager.

Risk management is a broad and deep topic, and I am only able to brush the surface in this book. A number of reference books on the topic are available. The bibliography in Appendix C lists some specific titles you can use as a reference. The risk analysis and management process that I briefly describe answers the following questions:

• What are the risks?
• What is the probability of loss that results from them?
• How much are the losses likely to cost?
• What might the losses be if the worst happens?
• What are the alternatives?
• How can the losses be reduced or eliminated?
• Will the alternatives produce other risks?

To answer these questions, the following sections define risk management in four phases: identification of risk, assessment of risk, risk response planning, and monitoring and controlling.

Every project is subject to risks. Some can be identified and plans can be put in place if they occur; others cannot and must be dealt with as they occur. The events that this section focuses on are those that could compromise the successful completion of the project. No one knows when they will occur, but they will occur with some likelihood and cause some damage to the project. For example, the loss of a team member who has a critical or scarce skill is one such event. The longer the project lasts, the more likely this will happen. The history of some organizations might suggest that this is a certainty. Knowing this, what would you do? That is the question answered this section. The answer lies in understanding what the risk management life cycle is and how to construct a risk management plan.

Unfortunately, many project managers view risk as something they pay attention to at the beginning of the project by building some type of risk management plan and then file it away so they can get on with the real work of the project. How shortsighted. Effective project managers treat risk management as a dynamic part of every project. Their plan has the following four parts:

• Risk identification
• Risk assessment
• Risk mitigation
• Risk monitoring

Risk Identification

In order to establish a risk management program for the project, the project manager and project team must go through several processes. The first is risk identification, and it generally occurs as part of project planning activities. In this part of the process, the entire planning team is brought together to discuss and identify the risks that are specific to the current project.

Developing a risk management plan is a significant part of the project planning process. The more complex and uncertain the project, the more important it is to have a dynamic and maintained risk management plan. Some have said that the project manager does nothing more than manage risk on the project. That is too restrictive, but it does speak to the importance of a good risk management plan for every project. Although the experienced project manager will certainly know what general types of risks there are on each project, the professional project manager takes nothing for granted and always engages the project planning team in identifying risks for the project. The list of risks can be cumulatively developed in parallel with other project planning activities. After that list is built, the team can move to the second step in the risk management process.

There are four risk categories. Each category is listed here with its potential risks. Use these as suggestions only. Your specific project will probably suggest these or other risks within each of these categories. The planning team should review each list and modify it as needed.

Technical Risks

These may include the following:

• Quality and performance goals generally relating to the technology of the project
• The suitability, reliability, and quality or performance standards surrounding the technology
• Technology availability and complexity issues

Project Management Risks

These may include the following:

• Poor allocation of the project's resources
• Inadequate project management structure — proper planning processes to define critical deliverables for each project phase
• Inadequate planning, resource inexperience, or poor use of management disciplines
• Cost and schedule risks due to the aforementioned project management risks

Organizational Risks

These may include the following:

• Supportability risks or inadequate prioritization of projects
• Inadequacy of or interrupted funding and/or resource assignments
• Conflicts with other competing projects
• Policies that do not support efficient management and could potentially introduce supportability risks
• Politics and agendas that impede the development of the project's executing objectives

External Risks

These may include the following:

• Shifting legal or regulatory requirements
• Supplier and contractor risks and/or contract issues
• Economic collapse or work stoppages (strikes)
• Programmatic or supportability risks caused by external parties
• Deliverables from teams that are external to your own (IT or client)

Risk Assessment Template

Figure 3-1 shows a template that you can use for defining risks in each of these categories and making a preliminary assessment of how they might impact the scope matrix.

The first step in the Risk Management Process is to identify the risk drivers that may be operative on a given project. These are the conditions or situations that may unfavorably affect project success. As an example, Figure 3-2 shows a candidate list from which the list of risk drivers appropriate for a given project can be chosen.

To establish the risk management for the project, the project manager and project team must go through several processes. The first is identifying risk.

In this part of the process, the entire team is brought together to discuss and identify the risks that are specific to the current project. I recommend that the meeting focus solely on risk. A meeting with such a single focus enables the entire project team to understand the importance of risk management, and it gets everyone thinking about the various risks involved in the project.

Figure 3-1: Risk identification template

Risk Assessment

When the team puts together the risk identification list, nothing should be ruled out at first. Let the team brainstorm risk without being judgmental. Some risks are so small that you will eventually ignore them. For instance, the risk that a meteor will destroy the building in which you work is miniscule. If you're worrying about things like this, you won't be much of a project manager. You need to manage the risks that actually might occur.

There are two major factors in assessing risk. The first one is the probability that the risk event will occur. For instance, when a project involves migrating legacy systems to new systems, the interface points between the two are often where problems occur. The professional project manager will have a good sense of these types of risks and the chances that they will occur.

Figure 3-2: Candidate risk driver template and assessment worksheet (Continues)

The second part of risk assessment is the expected loss the risk will have on the project. If the probability is high and the impact is low, you may be able to ignore the risk. If the probability is low but the impact is high, you might also be able to ignore the risk. The decision is based on the product of the probability of the event happening and the impact it will have. For example, if the probability of losing a critical skill is 0.8 (probability is a number between 0 and 1.0) and the impact is $50,000, the expected loss is $40,000 (0.8 × $50,000). As a further example, suppose the probability of the Bull on Wall Street being stolen is 1 × 10−10 and the impact is $75,000,000; then the expected loss is $750.

You should ignore the risk if the cost of avoiding the risk is greater than the expected loss. In other words, don't solve a $100 problem with a $1,000 solution. In the two examples, you would most likely not ignore the risk of losing the critical skill, but you would ignore the risk of the Bull on Wall Street being stolen.

Static Risk Assessment

If you don't want to get hung up on numeric risk assessments, you might want to try using the risk matrix shown in Figure 3-3. There is nothing magic about using a 3 × 3 matrix. A 5 × 5 matrix works just as well.

Figure 3-3: Risk matrix

For each risk, evaluate the probability that it will occur on a Low, Medium, High scale and the impact on a Low, Medium, High scale. The combination of these two assessments identifies a specific cell in the risk matrix with the recommended action, if any. The situation regarding this risk may change later in the project. So, my advice is to monitor the risk, but don't act unless reason dictates that you do so.

Dynamic Risk Assessment

The preceding risk assessment is basically static. By that I mean an analysis is done during planning, and a risk management plan is put in place for the entire project. It does not change as the project progresses. That is the simplest approach and probably less effective than the dynamic risk assessment discussed in this section. I have used the following dynamic risk assessment approach with great success. In this approach, risk is continuously reassessed at each phase of the project. An example will help explain how this approach is used.

After the risk drivers have been identified, they must be ranked from most likely to have an impact on the project to least likely to have an impact on the project. Label them A (most likely) through J (least likely) and array the data as shown in Figure 3-4. The column entries are 1 = low risk, 2 = medium risk, and 3 = high risk. Actually, any metric can be used as long as the lower numbers are at the low-risk end and the higher numbers are at the high-risk end. Sometimes a “0” might be used to indicate no risk. Other modifications I have seen and used are changing the impact scale to 1–5 or even 1–10.

Figure 3-4: Risk assessment worksheet

The data given in the worksheet is from a hypothetical project. The columns are the top risk drivers that were identified from the candidate list, and the rows are steps in a process. For the sake of an example, I chose steps from a hypothetical systems-development life cycle. Any collection of process steps may be used, so the tool has broad application for a variety of contexts. A score of 1 is given to risk drivers that will not impact the process step if they should occur, 2 is for a medium impact, and 3 is for a strong impact. Actually, any numeric scale may be used. The row and column totals are evaluated relative to one another and to scores from similar projects. These totals tell the story. High column totals suggest a risk driver that is operative across a number of steps in the process. High row totals suggest a process step that is affected by several risk drivers. Finally, the total for the whole worksheet gives you a percentage that can be used to compare this project against similar completed projects. The percentage is relative, but it may suggest a rule that provides an early warning of projects that are high risk overall.

To analyze the resulting scores, first examine column totals that are large relative to other column totals. In the example, you should focus on the risk drivers associated with columns C, D, E, and F. Because their column totals are high, they can potentially affect several process steps. The project team should identify strategies for either reducing the probability of the risk occurring or mitigating its impact, or both, should the event associated with that risk occur. The row totals can be analyzed in the same fashion. In the example, integration has the highest row total (27). This indicates that several risk drivers can impact integration. The project team should pay attention to the work associated with integration and look for ways to improve or better manage it. For example, the team might choose to have more skilled personnel work on integration than they might otherwise choose.

In the example, the risk factor is 71 percent. This value can be interpreted only in comparison to the risk factor of completed projects. There will be a pattern of project failures for projects whose risk factor is above a certain number. If 71 percent is above that number, the example project is a high risk for failure. The decision to do this project will have to be offset by the business value the project expects to contribute.

Risk Mitigation

The next step in risk management is to plan, as much as possible, the responses that will be used if the identified risks occur. For instance, you may want to include a clause in your hardware contract with the vendor that if the servers don't get to you by a certain date, then the vendor will pay a penalty. This penalty gives the vendor an incentive to analyze and mitigate the risks involved in late delivery of key equipment. For all the risks listed in the risk identification that you choose to act upon, you should have some type of action in mind. It's not enough to simply list the risks; you need to plan to do something about the risk events should they occur.

Another example of risk planning is planning for key personnel. What will you do if one of the key developers leaves the company before finishing the coding? This risk will impact the project severely if it occurs. Having someone capture code as it is written and debriefing with the developer each day are two ways of dealing with the risk of key personnel loss. How many others can you come up with? Coming up with contingency plans such as these is risk response planning.

There are five different risk responses. They are briefly defined in the following list:

• Accept — There is nothing that can be done to mitigate the risk. You just have to accept it and hope it does not occur.
• Avoid — The project plan can be modified so as to avoid the situation that creates the risk.
• Contingency Planning — If the risk event occurs, what will you do?
• Mitigate — What will you do to minimize the impact should the risk event occur?
• Transfer — Pass the impact should the risk event occur (that is, buy an insurance policy).

Risk Monitoring

Once you've identified the risk, assessed the probability and impact of the risks, and planned what to do if the risk event occurs, you need to monitor and control the project risks. The process of writing down the risks, assessing them, and posting them in the Team War Room makes everyone on the project team aware of their existence and is a good place to start. Start by creating a risk log. This document lists all risks that you want to manage, identifies who is supposed to manage the risk, and specifies what should be done to manage the risk event. A risk log is a simple template that can be created in a text document or spreadsheet package.

A risk log is a simple template that you can create in Microsoft Word. A typical risk log will contain the following five fields:

• ID number — This always remains the same, even if the risk event has occurred and been managed. If you take the risk off the list and file it elsewhere, don't assign the old number to a new risk. Keep the original number with the discarded risk and never use it again, or there will be a great deal of confusion.
• Risk description — This is a short statement of the risk event.
• Risk owner — This is the person who has the responsibility of monitoring the status of the listed risk.
• Action to be taken — Lists what the risk owner is going to do to deal with the risk event.
• Outcome — Describes what happened as a result of your mitigation strategy.

Use the risk log to keep track of risk in the project, and you'll have control over it. When you go to status meetings, you should always talk about risks and their management by the team. Keep the risks in front of the team so that each member will be aware of what risks are coming up and what is to be done about the risk event. Continuously paying attention to the risks is a good insurance policy against project failure.

Procurement Management

The Procurement Management Knowledge Area consists of processes that span the Planning, Launching, Monitoring and Controlling, and Closing Process Groups. An effective procurement management life cycle consists of the following five phases:

• Vendor solicitation
• Vendor evaluation
• Vendor selection
• Vendor contracting
• Vendor management

As a project manager, you will always have projects for which you must obtain hardware, software, or services from outside sources. This process is known as procurement, and the professional project manager must have a basic understanding of the acquisition procedure so that he or she can ensure that the organization is getting the right materials at the best cost or the best services at the best cost. To manage procurement, you need to go through a few processes, which are summarized in the next few sections.

Vendor Solicitation

After you've done your requirements gathering and have made the decision that you need an outside vendor, you can begin to prepare procurement documents for solicitation. These documents, called Requests for Proposals (RFPs), are what vendors use to determine if and how they should respond to your needs. The clearer the RFP, the better off you and the vendor are, because you will be providing basic information about what you want (don't forget about the earlier discussion of needs versus wants). The more specific you are, the better the chance that the vendor will be able to respond to you quickly and efficiently.

Many organizations have a procurement office. In this case, you need to give them a document with your requirements and let them do their work. If you don't have a procurement office, you need to prepare a document to send to the vendors. You'll want to have a lead writer (preferably not you) and someone from the legal department to ensure that what you've asked for in the document is clear and forms the basis for a contract between you and the vendor.

You have several ways to build a list of potential vendors, as outlined in the following sections.

Publishing a Request for Information

The Request for Information (RFI) is frequently used when you have little knowledge of exactly what is available on the commercial market or you can't identify vendors who have the specific capability you are looking for. The RFI is a broad net designed to find possible vendors who have some product or service to offer that may meet your needs. The RFI is a letter, and the response usually comes in the form of a letter or brochure. Based on the response to your RFI, you will decide the following:

• Who should be invited to respond to your Request for Proposal (RFP)
• Specific content to include in your RFP
• If one of the vendors should be invited to write the RFP

Advertising

Pick any medium that a potential vendor would likely read and advertise your project there. Many vendors will belong to professional associations. If such associations exist, get their mailing lists or advertise in their trade publications.

Renting a Targeted List

Many sources are available for such mailing lists. The reputable ones will have exhaustive profiling capabilities so that you can narrow the list as much as you wish.

Asking Previous Vendors

Vendors who have worked with you in the past may be good sources for your current project, or they may be able to recommend other vendors who can meet the specific needs of this project.

Attending Trade Shows

Attend trade shows where potential vendors are likely to have a booth. This is a non-threatening approach and may even gain you some references to other vendors.

Preparing and Distributing a Request for Proposal

After you've created the RBS, you can begin to prepare procurement documents for solicitation. These documents, called Requests for Proposals (RFPs), are what vendors use to determine how they should respond to your needs. The clearer the RFP, the better off you and the vendor are, because you will be providing basic information about what you want. The more specific you are, the better the chance that the vendor will be able to respond to you quickly and efficiently.

You need to state the time conditions for response, which means that you state how many days you will give people to respond, as well as how long you will need to review the responses before making a choice. By putting a time line on both the vendor and your organization, the process goes faster, and expectations are clear at the beginning of the process.

The RFP is the heart of the procurement process and provides the basis for the contract and the work to be completed. It clearly explains all of the deliverables expected of the vendor.

I recommend that your RFP contain the following:

• Introduction
• Business profile
• Problem or opportunity
• POS (optional)
• RBS (optional)
• Vendor responsibility
• Contract administration
• Instructions to vendors
• Vendor point of contact
• Time and cost estimates
• Pricing
• Evaluation criteria

Managing RFP Questions and Responses

You can expect to receive questions from the vendors who receive your RFP. All potential vendors must be aware of all questions and your responses. That's the law! You need to have some mechanism whereby you can answer questions concerning the RFP.

Responding to Bidder Questions

After the RFP has been distributed, you have to decide how to handle questions that will surely arise from the vendors who have received your RFP. You have three ways to handle these questions:

• Answer questions individually — Receive questions directly from the vendors and distribute your responses electronically to all vendors on the distribution list.
• Hold a bidders' conference — This is a common event. All vendors who wish to respond to the RFP must attend and ask their questions. That way every potential bidder will hear the questions and answers in real time. The bidders' conference can be held at a hotel or conference site convenient to your campus but is usually held on your campus.
• Put your RFP online and respond to questions online — This arrangement gives every vendor who is registered to respond to your RFP a chance to see other organizations' questions and to have a permanent record of your responses to questions posed. This process works only if you have someone constantly monitoring the web site for questions, and someone who is responsible for answering the questions. This process also eliminates the traveling burden on vendors who may be far away geographically. By going online, you level the playing field for all vendors.

The important thing is to make sure all potential bidders have the same information. Otherwise, you are subject to being accused of unfair business practices.

Vendor Evaluation

Before you even start reading the responses to your proposal, set the standards for choosing a given vendor. These criteria may be based on technical expertise, experience, or cost, but whatever criteria you use, it must remain the same for all of the vendors. If you are a public company, every vendor you've turned down will ask for a copy of the winning bid. If they think they have a better bid, all sorts of nasty things may occur (read: legal action). If, however, you have a standards chart, you can point out that everyone was rated with the same criteria and that the winner had the best overall number. By determining your criteria for vendor selection early in the process, it is easier to make a decision and then defend it if need be.

Vendor evaluation consists of creating a rule by which all RFP responses are evaluated on the same scale.

Establishing Vendor Evaluation Criteria

Vendor selection implies that you have specified a set of established criteria that vendors will be evaluated against. The main objective is to ensure that the evaluation of all responses to the RFP is consistent, objective, and comprehensive.

Although many criteria have been developed for vendor evaluation, it is important for you to first decide what the desired vendor relationship will be and define the problem to be solved. You can then develop a specific set of vendor selection criteria that will facilitate the systematic choice of a vendor. This implies that an evaluation team is involved. That team reviews baseline vendor evaluation criteria checklists, debates with the other team members about the relative importance of each criterion, and reaches consensus. This further implies that only the essential criteria are chosen for each vendor, and extraneous criteria that “might” be necessary should be eliminated. Criteria might also be classified as “must have,” “should have,” or “it would be nice to have,” and some type of scoring algorithm should be applied to the criteria in each classification.

Several qualitative factors might also be used. They include the following:

• Corporate experience with similar work
• Financial stability
• Technical approach
• Personnel experience, skills, and competencies
• Risk management processes
• Location
• Applicable tools, templates, and processes
• References for similar work

Some type of weighted scoring algorithm should be employed to assess these qualitative factors.

Several quantitative models exist for evaluating and ranking vendors. Two models that I have used with good success and that are easy to master and administer are Forced Ranking and Paired Comparisons.

Forced Ranking

In the Forced Ranking example shown in Table 3-1, six vendors (numbered 1 through 6) and four consultants (A, B, C, and D) are doing the evaluation. The result of a Forced Ranking is a prioritized list of vendors. Each consultant must rank the six vendors from best to worst in terms of their overall satisfaction of the RFP. (A variation would be to specify the criteria and ask for the ranking based on the criteria.) In this example, Consultant A ranked Vendor 4 as best and Vendor 3 as worst. To determine the overall highest-ranked vendor, add the rankings across the rows. In this case, Vendor 2 is ranked first.

Table 3-1: Forced Ranking

Paired Comparisons

Paired Comparisons is another way to create a single prioritized ranking. Here every vendor is compared against every other vendor. In the example shown in Table 3-2, Vendor 1 is compared against Vendor 2 in the first row. If Vendor 1 is preferred, a 1 is placed in row 1 under the Vendor 2 column and a 0 is placed in the Vendor 2 row under the Vendor 1 column. To determine the overall highest-ranked vendor, sum the values in each row. The highest row total identifies the highest priority vendor.

Table 3-2: Paired Comparisons

Evaluating Responses to the RFP

Vendor RFP response evaluation is a structured method for assessing the vendor's ability to successfully deliver against the requirements stated in the RFP. It should be based on the execution by a team with the best knowledge of the disciplines represented in the RFP. In many cases, this will be an outside team of subject matter experts (SME). The primary deliverable from this unbiased evaluation is a ranked list. Comments are often requested regarding those vendors who meet the minimal requirements as stated in the RFP.

It is not unusual to have more than one evaluation phase. This may be necessary if there are several qualified respondents. The evaluation of vendor responses to the RFP is often used to reduce the number of viable bidders to a more manageable number, usually no more than five. These survivors will then be invited to make an onsite presentation of their proposed solutions. These presentations will often be attended by end users and others who will interact with the solution. They will evaluate each vendor's proposed solution using criteria developed specifically for this onsite presentation. The data collected here will be used to support the final selection of the winning bidder.

In most cases, the short list will contain more than one vendor, so your job of vendor evaluation is not yet done.

Vendor Selection

The result of vendor evaluation usually does not produce a single best choice. There will most likely be several competing vendors for all or parts of the work. So you have another decision to make and that is which vendor or vendors will win your business.

Selecting the vendor is a critical decision. There is no guarantee that even if you diligently follow the evaluation process, you will end up with a vendor that you are comfortable with and whom you can select with confidence. Some selection processes may result in failure. Don't feel obligated to choose one from the remaining list of contenders for your business. It is good practice to let potential bidders know that you may not award the contract after going through the process.

Vendor Contracting

When the software application is to be developed solely by the vendor, the project manager's primary job is contract management. Contract management involves the following:

• The vendor must supply you with deliverable dates so that you can determine whether the project is on time.
• The vendor should also supply a WBS detailing how the vendor breaks down the scope of the project and showing the tasks that make up the completion of a deliverable.
• The project manager should hold regular status meetings to track progress. These meetings should be formal and occur on specified dates. The status meetings should occur at least once a week, although in the early stages of the project, you may choose to have them more often. These status meetings will give you an idea of how the vendor is proceeding in fulfilling the contract, and by having them at weekly intervals, you won't allow the project to get very far off course. At most, you will need to correct only a week's worth of problems — anything longer than that can quickly become unmanageable.

In your contract, state who the contract manager will be for your organization. This is typically the project manager (which will be you if you're managing this project), but in some organizations, contract management functions are handled by a specific department or team. I prefer contract management to be in the hands of the project manager, or at least to have the project manager as part of the contract management team.

Making the actual selection can be very simple and straightforward, depending on the evaluation process. There are several possible scenarios to consider.

No Award

In this scenario, none of the evaluations result in a vendor who satisfactorily meets the requirements; therefore, no award will be made. In this case, you will probably want to rethink the RFP. Could you be asking for more than any vendor can reasonably provide? If so, you should consider revising the project scope.

Single Award

In this scenario, the results of the evaluation are clear, and a single vendor emerges with the highest evaluation across all criteria. In simpler cases, the evaluation criteria are designed to produce a single score, and the highest scoring vendor who meets the minimal requirements will be awarded the business. However, don't think that this is the end and you have a vendor. You still have a contract to negotiate and need vendor acceptance of that contract.

Multiple Awards

When there are multiple criteria, each with its own scoring algorithm, there may not be a clear single vendor who scored high enough across the criteria to be awarded the business. In this case, you may decide to award parts of the business to different vendors. If this possibility exists, you must make it clear in the RFP that the business could be awarded to several vendors who must then work together on the project. The RFP should require information on any similar situations in which the vendor has had experiences. If you have multiple vendors, you will obviously have an added management burden.

Types of Contracts

You might consider several types of contract structures. The four most popular contract types are briefly described in the following sections.

Fixed Price

This form of contract is best used when the requirements are well known and the buyer (that's you) knows that changes will be kept to a minimum. Although many buyers seem to always want a Firm Fixed Price (FFP) contract, it is wise to keep in mind that the supplier (a.k.a. vendor) should have the capability that is described by the Software Engineering Institute (SEI) in the Capability Maturity Model (CMM), Level 3. Only suppliers with organizational processes that are documented, trained, followed, and kept current will have a strong enough organizational measurement repository. These depositories will contain historical data based on many projects to be able to comfortably bid on FFP contracts. Of course all potential suppliers will agree to an FFP, but it is often done to get in the door and hope details can be worked out later with the buyer. It is not done from a base of data.

Time and Materials

Labor rates are established for each of the vendor's position classes that will be assigned to the project. These are stated in the RFP response and agreed to as part of contract negotiations. Time cards are kept by the vendor, and you are invoiced as agreed to in the contract's terms and conditions.

Materials are acquired by the vendor as agreed to in the contract. The necessary documentation is provided as attachments to the invoices.

Retainer

Retainer contracts specify a fixed amount per period to be paid to the vendor, with an agreed number of person days per period provided by the vendor in return for the fee. Retainer contracts are often used when a detailed Statement of Work cannot be provided. In these contracts, it is your responsibility to make periodic assignments with deadlines to the vendor.

Cost Plus

This form of contract is especially useful if you are willing to pay more for higher performance and quality but are not sure how to determine the supplier's true capability. A Cost Plus contract includes direct labor and indirect cost (overhead, actual work performed, and so on) to make up the bill rate, with other direct costs listed separately. Cost Plus puts a major emphasis on contractor performance and quality and can be used as a way to enforce standards and procedures. The award fee is negotiated at the beginning of contract and is directly tied to vendor performance. Vendor performance should be measured in terms of specific quantitative metrics so there is no argument about attainment.

Cost Plus contracts can also include penalties for not meeting acceptance criteria.

Discussion Points for Negotiating the Final Contract

This section of the RFP specifies the areas that will be discussed for the final terms and conditions of the contract following vendor selection. You do not want to present the vendors with any surprises. Some of the areas you will want to discuss in the RFP include the following:

• Work schedule
• Payment schedule
• Fees
• Personnel assigned to the contract
• Rights in data
• Other terms and conditions
• Ownership
• Warranties
• Cancellation terms

Final Contract Negotiation

Establishing and maintaining the vendor agreement provides the vendor with the project needs, expectations, and measures of effectiveness.

The vendor agreement typically includes the following:

• Statement of work for the vendor
• Terms and conditions
• List of deliverables, schedule, and budget
• Defined acceptance process, including acceptance criteria
• Identification of the project and supplier representatives responsible and authorized to agree to changes to the vendor agreement
• Description of the process for handling requirements change requests from either side
• The processes, procedures, guidelines, methods, templates, and so on that will be followed
• Critical dependencies between the project and the vendor
• Descriptions of the form, frequency, and depth of project oversight that the vendor can expect from the project, including the evaluation criteria to be used in monitoring the vendor's performance
• Clear definition of the vendor's responsibilities for ongoing maintenance and support of the acquired products
• Identification of the warranty, ownership, and usage rights for the acquired products

Vendor Management

I have always recommended that you do whatever you can to make the vendor feel like an equal partner in the project. That means including them in every team activity for which it makes sense to have them involved.

Expectation Setting – Getting Started

Starting a contract on the right foot avoids a lot of subsequent frustration for both parties. A good start-up allows the project team and contractor team working relationship to be established early on so that they can function as a unified team throughout the project. Communication needs to be established early among all relevant stakeholders in order to optimize the development environment before the implementation starts.

Conducting meetings and having face-to-face discussions are the easiest and best ways to set clear expectations and gain a mutual understanding of the requirements and expected performance. It is important to remember that the individuals who created and sent the RFP response may not be the same individuals who will actually work on the project. Therefore, it is good practice to hold some type of orientation with the vendor team at the beginning of the project to ensure that both parties share the same understanding of the project goal and objectives.

During this vendor orientation, you should provide answers to the following questions:

• For whom does the vendor work?
• What is expected of the vendor?
• What tools and facilities are available to the vendor?
• What training is available to the vendor? To your team by the vendor?
• What must the vendor deliver?
• When must it be produced?
• Who will receive the deliverables?
• How will the deliverables be evaluated?

However, if the vendor is not onsite, this orientation will pay for itself thousands of times over.

Monitoring Progress and Performance

Monitoring and reporting the progress and performance of one or more vendors takes effort, and you should not expect a vendor to manage their own reporting. The best way to think of the vendor is as a member of the project team. The activities of receiving status reports from the project members and holding project reviews to discuss progress, risks, problems, and ensuing tasks all apply to a vendor as well.

The following discussion of monitoring vendor activities is not intended to be complete or absolute, but rather should be used as a starter kit for subsequent tailoring to ensure proper attention is being devoted to the vendor based on business objectives, constraints, requirements, and operational environment.

Monitoring Requirements Change Requests

One of the most important areas to consider is the requirement change request. These will most likely come from your team and client, but you might also give the vendor the same privileges. After all, they are the experts at what they are doing and may be able to contribute to the betterment and overall success of the project. The bottom line is that requirements management is a collaborative effort of both parties.

Changes to the requirements must be controlled as they evolve over the product life cycle due to changing needs and derived requirements. All appropriate stakeholders on both sides must review and agree on the change requests to the requirements before they are applied. Approved changes to the requirements are tracked and a change history is maintained for each requirement along with the rationale for the change. Applied changes to requirements must be communicated to all stakeholders in a timely manner.

The change process is similar to the process used when no vendor is involved, except for the addition of the vendor's project impact analysis. An impact analysis is conducted on each requirements change request before negotiations take place or a decision to accept or reject the change request is made. The implication will be that a contract or schedule change may be required on the part of the vendor. Even if that is not the case and the vendor's work will not be impacted, it is recommended that you keep the vendor in the approval chain for all change requests. The vendor's approval of all change requests is necessary. Let the vendor decide if their work will be impacted. The vendor's project impact analysis report may conclude that the proposed change will not impact their work in any way, but the vendor needs to officially convey that to the project manager (you).

Monitoring the Performance of Standard Project Activities

The following key metrics need to be provided by the vendor to track actual versus planned contract performance:

• Labor hours
• Cost
• Schedule

Cost and schedule are part of the earned value analysis, which you learn about in Chapter 7.

Other performance metrics that should be tracked by both the vendor and the project manager include the following:

• Frequency of change requests over time
• Incidence of bugs
• Risks
• Issues resolution
• Staffing levels and changes by position type

Transitioning from Vendor to Client

Transitioning from the vendor's environment to your environment for integration and acceptance testing requires thought and up-front planning.

You need to determine what deliverables and/or services you expect to receive in order to successfully transition the product or product component from the vendor to you. The project manager in collaboration with the vendor should develop a high-level summary of the checklist to assist the transitioning of the deliverables:

• What do you expect to be delivered and how will you accept it?
• What environment must you provide in order to accept the vendor's deliverables?
• What support must the vendor provide during acceptance of the deliverables?
• How will problems be resolved?
• What type of maintenance agreement do you expect?
• What about future changes?

It is assumed that acceptance criteria have already been defined and agreed to.

Closing Out a Vendor Contract

Closing out the contract is often an overlooked function of the project manager. It both certifies what has been done and gives all parties a chance to deal with open issues and final payments. The project manager must be aware of all steps to be followed in the procurement process even though he or she may not be the person directly responsible for managing them. This is just another part of being a professional project manager. Consider the following as you bring a contract to a close:

• There should be a clear understanding of when the project is finished. When you write your RFP, state clearly the list of deliverables you expect in order for the project to be considered complete and what the final deliverable is. Failure to do this will almost always lead to cost overruns in the form of maintenance activities under the heading of project work. State what the final product of the project is to be, who is to determine if it has been delivered, and what is to be done with any open issues. Make this information as clear as possible and you will save the company thousands of dollars.
• After the contract is closed, make sure you file all of the materials used during the project. These materials include the original RFP, the project baseline, the scope statement, the WBS, the various plans used to manage the project, and all changes, including those that were requested but turned down. You also need to show all payments and make sure that any subcontractors on the project were paid. Confirming that subcontractors have been paid is done through the vendor, who must show that all payments have been made to the subcontractors.
• Put all this information into a large file and keep it. How long? I have seen instances of disputes coming up years after a project is finished. Keep it as long as the project product is in use. Ideally, keep these records permanently.