Module 8
Project Outsources, Monitoring, and Closure
A. Outsourcing Project Work
Contracting project work has long been the norm in the construction industry,
where firms hire general contractors who, in turn, hire and manage cadres of
subcontractors to create new buildings and structures. For example, the Chunnel project,
which created a transportation tunnel between France and England, involved more than
250 organizations. Contracting is not limited to large projects. For example, an insurance
company worked with an outside contractor to develop an answering service that directs
customers to specific departments and employees. The trend for the future suggests that
more and more projects will involve working with people from different organizations.
The term outsourcing has traditionally been applied to the transferring of business
functions or processes (e.g., customer support, IT, accounting) to other, often foreign
companies. For example, when you call your Internet provider to solve a technical
problem you are likely to talk to a technician in Bangalore, India, or Bucharest, Romania.
Outsourcing is now being applied to contracting significant chunks of project work. For
example, Apple and Motorola work closely with manufacturers in China to develop next-
generation smartphones. Toyota and DaimlerChrysler collaborate with suppliers to
develop new automobile platforms.
The shift toward outsourcing is readily apparent in the film industry. During the
golden era of Hollywood, huge, vertically integrated corporations made movies. Studios
such as MGM, Warner Brothers, and 20th Century–Fox owned large movie lots and
employed thousands of full-time specialists—set designers, camera people, film editors,
and directors. Star actors like Humphrey Bogart and Marilyn Monroe were signed to
exclusive studio contracts for a set number of films (e.g., six films over three years).
Today, most movies are made by a collection of individuals and small companies who
come together to make films project-by-project. This structure allows each project to be
staffed with the talent most suited to its demands rather than choosing from only those
people the studio employs.
Many outsourced projects operate in a virtual environment in which people are
linked by computers, faxes, computer-aided design systems, and video teleconferencing.
They rarely, if ever, see one another face-to-face. On other projects, participants from
different organizations work closely together, for example, at a construction site or in
shared office space. In either case, people come and go as services are needed, much as in
a matrix structure, but they are not formal members of one organization, just technical
experts who form a temporary alliance with an organization, fulfill their contractual
obligations, and then move on to the next project.
Not only can work be done more cheaply, but it can also be done faster.
Competitive pricing means more resources for the dollar. For example, you can hire three
Indian software engineers for the price of one American software engineer. Furthermore,
outsourcing can provide access to equipment that can accelerate completion of project
tasks. For example, by contracting a backhoe operater you are able to accomplish in four
hours what it would take a landscaping crew four days to complete.
A high level of expertise and technology can be brought to bear on the project. A
company no longer has to keep up with technological advances. Instead, it can focus on
developing its core competencies and hire firms with the know-how to work on relevant
segments of the project. Organizations are no longer constrained by their own resources
but can pursue a wide range of projects by combining their resources with talents of other
companies. Small companies can instantly go global by working with foreign partners.
Coordination of professionals from different organizations can be challenging,
especially if the project work requires close collaboration and mutual adjustment.
Breakdowns are exacerbated by physical separation with people working in different
buildings, different cities, if not different countries. There is potential loss of control over
the project. The core team depends on other organizations that they have no direct
authority over. While longterm survival of participating organizations depends on
performance, a project may falter when one partner fails to deliver.
Depending on the nature of the project, trade and business secrets may be
revealed. This can be problematic if the contractor also works for your competitor.
Confidentiality is another concern and companies have to be very careful when
outsourcing processes like payroll, medical transcriptions, and insurance information.
Foreign outsourcing of work is perceived as a major cause of underemployment and U.S.
companies are under increased pressure to keep jobs local. Furthermore, companies like
Apple have been criticized for the oppressive labor practices of some of their suppliers in
China.
Once an organization decides to outsource project work, the customer or project
manager is frequently responsible for developing a Request for Proposal (RFP). The
responsible project manager will require input from all stakeholders connected to the
activities covered in the RFP. The RFP will be announced to external contractors/
vendors with adequate experience to implement the project. For example, government
projects frequently advertise with a “request for proposal” to outside contractors for
roads, buildings, airports, military hardware, space vehicles. Similarly, businesses use
RFPs to solicit bids for building a clean room, developing a new manufacturing process,
delivering software for insurance billing, conducting a market survey. In all of these
examples, requirements and features should be in enough detail that contractors have a
clear description of the final deliverable that will meet the customer’s needs.
The background and a simple description of the final project deliverable are given
first. For example, through simulated war games, the U.S. Navy has found their giant
warships of the past are too vulnerable against today’s technology (an example is the
Silkworm antiship missiles). In addition, the Navy’s mission has shifted to supporting
ground forces and peacekeeping missions, which require getting closer to shore. As a
result, the Navy is revamping ships for near-shore duty. The Navy will select three
designs for further refinement from the responses to its RFP. In general, it is expected
that the new ship will be capable of at least 55 knots, measure between 80 and 250 feet in
length, and be fitted with radar absorbing panels to thwart guided missiles.
Failing to spell out the responsibilities for both parties is notorious for leading to
serious problems when the contractor implements the project. For example, who pays for
what? (If the contractor is to be on site, will the contractor be required to pay for office
space?) What are the limits and exclusions for the contractor? (For example, who will
supply test equipment?) What communication plan will be used by the contractor and
owner? If escalation of an issue becomes necessary, what process will be used? How will
progress be evaluated? Well-defined responsibilities will avoid many unforeseen
problems later.
Essentially there are two types of contracts—fixed-price and cost-plus. Fixed-
price contracts agree on a price or lump sum in advance, and it remains as long as there
are no changes to the scope provisions of the agreement. This type is preferred in projects
that are well defined with predictable costs and minimal risks. The contractor must
exercise care estimating cost because any underestimating of costs will cause the
contractor’s profit to be reduced. In cost-plus contracts the contractor is reimbursed for
all or some of the expenses incurred during performance of the contract. This fee is
negotiated in advance and usually involves a percent of total costs. “Time and materials”
plus a profit factor are typical of cost-plus contracts. Both types of contracts can include
incentive clauses for superior performance in time and cost, or in some cases, penalties—
for example, missing the opening date of a new sports stadium. Appendix 12.1 elaborates
further on contract management.
B. Best Practices in Outsourcing Project Work
This section describes some of the best practices we have observed being used by
firms that excel in project management (see Figure 12.4). Although the list is by no
means comprehensive, it reflects strategies used by organizations with extensive
outsourcing experience. These practices reveal an underlying theme in how firms
approach contracted work on projects. Instead of the traditional master–slave relationship
between owner and provider or buyer and seller, all parties work together as partners
sharing the ultimate goal of a successful project.
Convincing people from different professions, organizations, and cultures to work
together is difficult. If expectations and requirements are fuzzy or open to debate, this is
even harder. Successful firms are very careful in selecting the work to be outsourced.
They often choose to contract only work with clearly defined deliverables with
measurable outcomes. For example, contractors hire electric firms to install heating and
air-conditioning systems, electronic firms use design firms to fabricate enclosures for
their products, and software development teams outsource the testing of versions of their
programs. In all of these cases, the technical requirements are spelled out in detail.
Not only do requirements have to be spelled out, but the different firms’ project
management systems need to be integrated. Common procedures and terminology need to
be established so that different parties can work together. This can be problematic when
you have firms with more advanced project management systems working with less
developed organizations. Surprisingly, this often is the case when U.S. firms outsource
software work to India. We have heard reports that Indian providers are shocked at how
unsystematic their U.S. counterparts are in their approach to managing software projects.
Too often managers become preoccupied with the plans and technical challenges
of the project and assume that people issues will work themselves out over time. Smart
firms recognize that people issues are as important, if not more important, than technical
issues. They train their personnel to work effectively with people from other
organizations and countries. This training is pervasive. It is not limited to management
but involves all the people, at all levels, who interact with and are dependent upon
outsourcers. Whether in a general class on negotiation or a specific one on working with
Chinese programmers, team members are provided with a theoretical understanding of
the barriers to collaboration as well as the skills and procedures to be successful.
The length and design of the team-building sessions will depend on the
experience, commitment, and skill level of the participants. For example, one project, in
which the owner and the contractors were relatively inexperienced at working together,
utilized a two-day workshop. The first day was devoted to ice-breaking activities and
establishing the rationale behind partnering. The conceptual foundation was supported by
exercises and minilectures on teamwork, synergy, win/win, and constructive feedback.
The second day began by examining the problems and barriers that prevented
collaboration in the past.
Conflict is inevitable on a project and, as pointed out in the previous chapter,
disagreements handled effectively can elevate performance. Dysfunctional conflict,
however, can catch fire and severely undermine project success. Outsourced projects are
susceptible to conflicts since people are unaccustomed to working together and have
different values and perspectives. Successful firms invest significant time and energy up
front in establishing the “rules of engagement” so that disagreements are handled
constructively. Escalation is the primary control mechanism for dealing with and
resolving problems. The basic principle is that problems should be resolved at the lowest
level within a set time limit (say, 24 hours), or they are “escalated” to the next level of
management. If so, the principals have the same time limit to resolve the problem, or it
gets passed on to the next higher level. No action is not an option. Nor can one
participant force concessions from the other by simply delaying the decision. There is no
shame in pushing significant problems up the hierarchy; at the same time, managers
should be quick to point out to subordinates those problems or questions that they should
have been able to resolve on their own.
Project managers and other key personnel from all involved organizations meet
on a regular basis to review and assess project performance. Collaborating as partners is
considered a legitimate project priority which is assessed along with time, cost, and
performance. Teamwork, communication, and timely problem resolution are evaluated.
This provides a forum for identifying problems not only with the project but also with
working relationships so that they can be resolved quickly and appropriately.
One of the best ways to overcome interorganizational friction is to have people
from each organization working side by side on the project. Smart companies rent or
make available the necessary accommodations so that all key project personnel can work
collectively together. This allows the high degree of face-to-face interaction needed to
coordinate activities, solve difficult problems, and form a common bond. This is
especially relevant for complex projects in which close collaboration from different
parties is required to be successful. For example, the U.S government provides housing
and common office space for all key contractors responsible for developing disaster
response plans.
When negotiating contracts the goal is to reach a fair deal for all involved.
Managers recognize that cohesion and cooperation is undermined if one party feels he or
she is being unfairly treated by others. They also realize that negotiating the best deal in
terms of price can come back to haunt them with shoddy work and change order gouging.
Performance-based contracts, in which significant incentives are established based on
priorities of the project, are becoming increasingly popular. For example, if time is
critical, then contractors accrue payoffs for beating deadlines; if scope is critical, then
bonuses are issued for exceeding performance expectations. At the same time contractors
are held accountable with penalty clauses for failure to perform up to standard, meet
deadlines, and/or control costs. More specific information about different types of
contracts is presented in this chapter’s appendix on contract management.
Many companies recognize that major benefits can be enjoyed when outsourcing
arrangements extend across multiple projects and are long term. For example, Corning
and Toyota are among the many firms that have forged a network of long-term strategic
partnerships with their suppliers. The average large corporation is involved in around 30
alliances today versus fewer than 3 in the early 1990s.
C. The Art of Negotiating
Effective negotiating is critical to successful collaboration. All it takes is one key
problem to explode to convert a sense of “we” into “us versus them.” At the same time,
negotiating is pervasive through all aspects of project management work. Project
managers must negotiate support and funding from top management. They must negotiate
staff and technical input from functional managers. They must coordinate with other
project managers and negotiate project priorities and commitments. They must negotiate
within their project team to determine assignments, deadlines, standards, and priorities.
Project managers must negotiate prices and standards with vendors and suppliers. A firm
understanding of the negotiating process, skills, and tactics is essential to project success.
Project managers accept this noncompetitive view of negotiation and realize that
negotiation is essentially a two-part process: The first part deals with reaching an
agreement; the second part is the implementation of that agreement. It is the
implementation phase, not the agreement itself, that determines the success of
negotiations. All too often, managers reach an agreement with someone only to find out
later that they failed to do what they agreed to do or that their actual response fell far
short of expectations. Experienced project managers recognize that implementation is
based on satisfaction not only with the outcome but also with the process by which the
agreement was reached. If someone feels bullied or tricked into doing something, this
feeling will invariably be reflected by half-hearted performance.
Too often personal relations become entangled with the substantive issues under
consideration. Instead of attacking the problem(s), people attack each other. Once people
feel attacked or threatened their energy naturally goes to defending themselves, and not to
solving the problem. The key, then, is to focus on the problem—not the other person—
during the negotiation. Avoid personalizing the negotiation and framing the negotiation
as a contest. Instead, try to keep the focus on the problem to be resolved. In Fisher and
Ury’s words: Be hard on the problem, soft on the people.
While it is important to separate the people from the problem during actual
negotiations, it is beneficial to have a friendly rapport with the other person prior to
negotiating. Friendly rapport is consistent with the social network tenet introduced in
Chapter 10 of building a relationship before you need it. If, in the past, the relationship
has been marked by healthy give-and-take, in which both parties have demonstrated a
willingness to accommodate the interests of the other, then neither individual is likely to
adopt an immediate win/lose perspective. Furthermore, a positive relationship adds a
common interest beyond the specific points of contention. Not only do both parties want
to reach an agreement that suits their individual interests, but they also want to do so in a
manner that preserves their relationship. Each is therefore more likely to seek solutions
that are mutually beneficial.
While such interchanges are common during preliminary discussions, managers
must prevent this initial posturing from becoming polarized. When such positions are
stated, attacked, and then defended, each party figuratively begins to draw a line he or she
will not cross. This line creates a win/lose scenario in which someone has to lose by
crossing the line in order to reach an agreement. As such, the negotiations can become a
war of wills, with concessions being seen as a loss of face. The key is to focus on the
interests behind your positions (what you are trying to achieve) and separate these goals
from your ego as best you can. Not only should you be driven by your interests, but you
should try to identify the interests of the other party. Ask why it will cost so much or why
it can’t be done by Monday. At the same time, make your own interests come alive.
Don’t just say that it is critical that it be done by Monday; explain what will happen if it
isn’t done by Monday.
When focusing on interests, it is important to practice the communication habit:
Seek first to understand, then to be understood. This involves what Stephen Covey calls
empathetic listening, which allows a person to fully understand another person’s frame of
reference—not only what that person is saying but also how he or she feels. Covey
asserts that people have an inherent need to be understood. He goes on to observe that
satisfied needs do not motivate human behavior, only unsatisfied needs do. People try to
go to sleep when they are tired, not when they are rested. The key point is that until
people believe they are being understood, they will repeat their points and reformulate
their arguments. If, on the other hand, you satisfy this need by seeking first to understand,
then the other party is free to understand your interests and focus directly on the issues at
hand. Seeking to understand requires discipline and compassion. Instead of responding to
the other person by asserting your agenda, respond by summarizing both the facts and
feelings behind what the other person has said and checking the accuracy of
comprehension.
Once the individuals involved have identified their interests, then they can explore
options for mutual gain. This is not easy. Stressful negotiations inhibit creativity and free
exchange. What is required is collaborative brainstorming in which people work together
to solve the problem in a way that will lead to a win/win scenario. The key to
brainstorming is separating the inventing from the deciding. Begin by taking 15 minutes
to generate as many options as possible. No matter how outlandish any option is, it
should not be subject to criticism or immediate rejection. People should feed off the ideas
of others to generate new ideas. When all the possible options are exhausted, then sort
through the ideas that were generated to focus on those with the greatest possibilities.
Whenever possible, you should insist on using external, objective criteria to settle
disagreements. For example, a disagreement arose between a regional airlines firm and
the independent accounting team entrusted with preparing the annual financial statement.
The airline firm had made a significant investment by leasing several used airplanes from
a larger airline. The dispute involved whether this lease should be classified as an
operating or capital lease. This was important to the airline because if the purchase was
classified as an operating lease, then the associated debt would not have to be recorded in
the financial statement. However, if the purchase was classified as a capital lease, then
the debt would be factored into the financial statement and the debt/equity ratio would be
much less attractive to stockholders and would-be investors. The two parties resolved this
dispute by deferring to formulas established by the Financial Accounting Standards
Board. As it turns out the accounting team was correct, but, by deferring to objective
standards, they were able to deflect the disappointment of the airline managers away from
the accounting team and preserve a professional relationship with that firm.
Most people working on projects realize that in the long run it is beneficial to
work toward mutually satisfying solutions. Still, occasionally you encounter someone
who has a dominant win/lose attitude about life and will be difficult to deal with. Fisher
and Ury recommend that you use negotiation jujitsu when dealing with such a person.
That is, when the other person begins to push, don’t push back. As in the martial arts,
avoid pitting your strengths against another’s directly; instead use your skill to step aside
and turn that person’s strength to your ends. When someone adamantly sets forth a
position, neither reject it nor accept it. Treat it as a possible option and then look for the
interests behind it. Instead of defending your ideas, invite criticism and advice. Ask why
it’s a bad idea and discover the other’s underlying interest.
The best defense against unreasonable, win/lose negotiators is having what Fisher
and Ury call a strong BATNA (best alternative to a negotiated agreement). They point
out that people try to reach an agreement to produce something better than the result of
not negotiating with that person. What those results would be is the true benchmark for
determining whether you should accept an agreement. A strong BATNA gives you the
power to walk away and say, “No deal unless we work toward a win/win scenario.” Your
BATNA reflects how dependent you are on the other party. If you are negotiating price
and delivery dates and can choose from a number of reputable suppliers, then you have a
strong BATNA. If on the other hand there is only one vendor who can supply you with
specific, critical material on time, then you have a weak BATNA.
D. A Note on Managing Customer Relations
Customer satisfaction is a complex phenomenon. One simple but useful way of
viewing customer satisfaction is in terms of met expectations. According to this model,
customer satisfaction is a function of the extent to which perceived performance (or
outcome) exceeds expectations. Mathematically, this relationship can be represented as
the ratio between perceived performance and expected performance (see Figure 12.7).
When performance falls short of expectations (ratio < 1), the customer is dissatisfied. If
the performance matches expectations (ratio = 1), the customer is satisfied. If the
performance exceeds expectations (ratio > 1), the customer is very satisfied or even
delighted.
Project managers must be skilled at managing customer expectations and
perceptions. Too often they deal with these expectations after the fact when they try to
alleviate a client’s dissatisfaction by carefully explaining why the project cost more or
took longer than planned. A more proactive approach is to begin to shape the proper
expectations up front and accept that this is an ongoing process throughout the life of a
project. Project managers need to direct their attention both to the customer’s base
expectations, the standard by which perceived performance will be evaluated, and to the
customer’s perceptions of actual performance. The ultimate goal is to educate clients so
that they can make a valid judgment as to project performance.
Once the project is authorized, the project manager and team need to work closely
with the client organization to develop a well-defined project scope statement that clearly
states the objectives, parameters, and limits of the project work. The project scope
statement is essential to establishing customer expectations regarding the project. It is
critical that all parties are in agreement as to what is to be accomplished and that people
are reading as best they can from the same page. It is also important to share significant
risks that might disrupt project execution. Customers do not like surprises, and if they are
aware in advance of potential problems they are much more likely to be accepting of the
consequences.
Project managers need to keep customers informed of project developments so
that customers can make adjustments in their own plans. When circumstances dictate
changing the scope or priorities of the project, project managers need to be quick to spell
out as best they can the implications of these changes to the customers so that they can
make an informed choice. Active customer involvement allows customers to naturally
adjust their expectations in accordance with the decisions and events that transpire on a
project, while at the same time, the customer’s presence keeps the project team focused
on the customer’s objectives for the project.
E. Structure of a Project Monitoring Information System
Data collected are determined by which metrics will be used for project control.
Typical key data collected are actual activity duration times, resource usage and rates,
and actual costs, which are compared against planned times, resources, and budgets.
Since a major portion of the monitoring system focuses on cost/schedule concerns, it is
crucial to provide the project manager and stakeholders with data to answer questions.
With the determination of what data are collected, the next step is to establish
who, when, and how the data will be assembled. Will the data be collected by the project
team, contractor, independent cost engineers, project manager? Or will the data be
derived electronically from some form of surrogate data such as cash flow, machine
hours, labor hours, or materials in place? Should the reporting period be one hour, one
day, one week, or what? Is there a central repository for the data collected and is someone
responsible for its dissemination?
First, who gets the progress reports? We have already suggested that different
stakeholders and levels of management need different kinds of project information.
Senior management’s major interests are usually, “Are we on time and within budget? If
not, what corrective action is taking place?” Likewise, an IT manager working on the
project is concerned primarily about her deliverable and specific work packages. The
reports should be designed for the right audience.
F. The Project Control Process
The baseline plan provides us with the elements for measuring performance. The
baseline is derived from the cost and duration information found in the work breakdown
structure (WBS) database and time-sequence data from the network and resource
scheduling decisions. From the WBS the project resource schedule is used to timephase
all work, resources, and budgets into a baseline plan. Time and budgets are quantitative
measures of performance that readily fit into the integrated information system.
Qualitative measures such as meeting customer technical specifications and product
function are most frequently determined by on-site inspection or actual use. This chapter
is limited to quantitative measures of time and budget. Measurement of time performance
is relatively easy and obvious. That is, is the critical path early, on schedule, or late; is the
slack of near-critical paths decreasing to cause new critical activities? Measuring
performance against budget (e.g., money, units in place, labor hours) is more difficult and
is not simply a case of comparing actual versus budget. Earned value is necessary to
provide a realistic estimate of performance against a time-phased budget. Earned value
(EV) is defined as the budgeted cost of the work performed.
Because plans seldom materialize as expected, it becomes imperative to measure
deviations from plan to determine if action is necessary. Periodic monitoring and
measuring the status of the project allow for comparisons of actual versus expected plans.
It is crucial that the timing of status reports be frequent enough to allow for early
detection of variations from plan and early correction of causes. Usually status reports
should take place every one to four weeks to be useful and allow for proactive correction.
If deviations from plans are significant, corrective action will be needed to bring
the project back in line with the original or revised plan. In some cases, conditions or
scope can change, which, in turn, will require a change in the baseline plan to recognize
new information. The remainder of this chapter describes and illustrates monitoring
systems, tools, and components to support managing and controlling projects. Several of
the tools you developed in the planning and scheduling chapters now serve as input to
your information system for monitoring performance. Monitoring time performance is
discussed first, followed by cost performance.
G. Monitoring Time Performance
A major goal of progress reporting is to catch any negative variances from plan as
early as possible to determine if corrective action is necessary. Fortunately, monitoring
schedule performance is relatively easy. The project network schedule, derived from the
WBS/OBS, serves as the baseline to compare against actual performance. Gantt charts
(bar charts), control charts, and milestone schedules are the typical tools used for
communicating project schedule status. As suggested in Chapter 6, the Gantt chart is the
most favored, used, and understandable. This kind of chart is commonly referred to as a
tracking Gantt chart. Adding actual and revised time estimates to the Gantt chart gives a
quick overview of project status on the report date.
This chart is another tool used to monitor past project schedule performance and
current performance and to estimate future schedule trends. Figure 13.2 depicts a project
control chart. The chart is used to plot the difference between the scheduled time on the
critical path at the report date with the actual point on the critical path. Although Figure
13.2 shows the project was behind early in the project, the plot suggests corrective action
brought the project back on track. If the trend is sustained, the project will come in ahead
of schedule. Because the activity scheduled times represent average durations, four
observations trending in one direction indicate there is a very high probability that there
is an identifiable cause. The cause should be located and action taken if necessary.
Control chart trends are very useful for giving warning of potential problems so
appropriate action can be taken if necessary.
Milestone schedules are often used to keep more distal stakeholders informed on
the progress of a project. Such stakeholders, whether it is senior management, the owner,
or regulatory agencies often neither need or desire a detailed accounting of project
progress. Instead, their interests can be satisfied by reporting progress towards major
project milestones. Remember from Chapter 4, milestones are significant project events
that mark major accomplishments. Below is the milestone schedule used to keep the
president of a university and her cabinet informed on the construction of a new College
of Business building.
H. Development of an Earned Value Cost/Schedule System
Earned value is not new; the original earned value cost/schedule system was
pioneered by the U.S. Department of Defense (DoD) in the 1960s. It is probably safe to
say project managers in every major country are using some form of the system. The
system is being used on internal projects in the manufacturing, pharmaceutical, and high-
tech industries. For example, organizations such as EDS, NCR, Levi Strauss, Tektronics,
and Disney have used earned value systems to track projects. The basic framework of the
earned value system is withstanding the test of time. Most project management software
includes the original framework; many systems have added industry-specific variations to
more precisely track progress and costs. This chapter presents the “generic” core of an
integrated cost/schedule information system.
The earned value system starts with the time-phased costs that provide the project
budget baseline, which is called the planned budgeted value of the work scheduled (PV).
Given this time-phased baseline, comparisons are made with actual and planned schedule
and costs using earned value. The earned value approach provides the missing links not
found in conventional cost-budget systems. At any point in time, a status report can be
developed for the project.
The major reasons for creating a baseline are to monitor and report progress and
to estimate cash flow. Therefore, it is crucial to integrate the baseline with the
performance measurement system. Costs are placed (time-phased) in the baseline exactly
as managers expect them to be “earned.” This approach facilitates tracking costs to their
point of origin. In practice, the integration is accomplished by using the same rules in
assigning costs to the baseline as those used to measure progress using earned value. You
may find several rules in practice, but percent complete is the workhorse most commonly
used. Someone familiar with each task estimates what percent of the task has been
completed or how much of the task remains.
This rule is the heart of any earned value system. The best method for assigning
costs to the baseline under this rule is to establish frequent checkpoints over the duration
of the work package and assign completion percentages in dollar terms. For example,
units completed could be used to assign baseline costs and later to measure progress.
Units might be lines of code, hours, drawings completed, cubic yards of concrete in
place, workdays, prototypes complete, etc. This approach to percent complete adds
“objectivity” to the subjective observation approaches often used. When measuring
percent complete in the monitoring phase of the project, it is common to limit the amount
earned to 80 or 90 percent until the work package is 100 percent complete.
The baseline (PV) is the sum of the cost accounts, and each cost account is the
sum of the work packages in the cost account. Three direct costs are typically included in
baselines—labor, equipment, and materials. The reason: these are direct costs the project
manager can control. Overhead costs and profit are typically added later by accounting
processes. Most work packages should be discrete, of short time span, and have
measurable outputs. If materials and/or equipment are a significant portion of the cost of
work packages, they can be budgeted in separate work packages and cost accounts.
These comparisons can be made at the project level or down to the cost account
level. Project status can be determined for the latest period, all periods to date, and
estimated to the end of the project. Assessing the current status of a project using the
earned value cost/schedule system requires three data elements—planned cost of the
work scheduled (PV), budgeted cost of the work completed (EV), and actual cost of the
work completed (AC). From these data the schedule variance (SV) and cost variance
(CV) are computed each reporting period. A positive variance indicates a desirable
condition, while a negative variance suggests problems or changes that have taken place.
The “today” label marks the report date (time period 25) of where the project has
been and where it is going. Because our system is hierarchical, graphs of the same form
can be developed for different levels of management. In Figure 13.4 the top line
represents the actual costs (AC) incurred for the project work to date. The middle line is
the baseline (PV) and ends at the scheduled project duration (45). The bottom line is the
budgeted value of the work actually completed to date (EV) or the earned value. The
dotted line extending the actual costs from the report date to the new estimated
completion date represents revised estimates of expected actual costs; that is, additional
information suggests the costs at completion of the project will differ from what was
planned. Note that the project duration has been extended and the variance at completion
(VAC) is negative (BAC − EAC).
I. Indexes to Monitor Progress
Practitioners sometimes prefer to use schedule and cost indexes over the absolute
values of SV and CV, because indexes can be considered efficiency ratios. Graphed
indexes over the project life cycle can be very illuminating and useful. The trends are
easily identified for deliverables and the whole project. Indexes are typically used at the
cost account level and above. In practice, the database is also used to develop indexes
that allow the project manager and customer to view progress from several angles. An
index of 1.00 (100 percent) indicates progress is as planned. An index greater than 1.00
shows progress is better than expected. An index less than 1.00 suggests progress is
poorer than planned and deserves attention.
The CPI of .696 shows that $.70 worth of work planned to date has been
completed for each $1.00 actually spent—an unfavorable situation indeed. The CPI is the
most accepted and used index. It has been tested over time and found to be the most
accurate, reliable, and stable. For example, U.S. government studies have shown that the
CPI is stable from the 20 percent completion point regardless of contract type, program,
or service. The CPI can provide an “early warning signal” as to cost overruns so that
adjustments can be made to the budget or scope of a project. The second index is a
measure of scheduling efficiency to date
Two project percent complete indexes are used, depending on your judgment of
which one is most representative of your project. The first index assumes the original
budget of work complete is the most reliable information to measure project percent
complete. The second index assumes the actual costs-to-date and expected cost at
completion are the most reliable for measuring project percent complete. These indexes
compare the to-date progress to the end of the project. The implications underlying use of
these indexes are that conditions will not change, no improvement or action will be taken,
and the information in the database is accurate.
The variety of software packages, with their features and constant updating, is too
extensive for inclusion in this text. Software developers and vendors have done a superb
job of providing software to meet the information needs of most project managers.
Differences among software in the last decade have centered on improving “friendliness”
and output that is clear and easy to understand. Anyone who understands the concepts
and tools presented in Chapters 4, 5, 6, 8, and 13 should have little trouble understanding
the output of any of the popular project management software packages.
Although the percent complete rule is the most-used method of assigning budgets
to baselines and for cost control, there are additional rules that are very useful for
reducing the overhead costs of collecting detailed data on percent complete of individual
work packages. (An additional advantage of these rules, of course, is that they remove the
often subjective judgments of the contractors or estimators as to how much work has
actually been completed.) The first two rules are typically used for short-duration
activities and/or small-cost activities. The third rule uses gates before the total budgeted
value of an activity can be claimed.
J. Forecasting Final Project Cost
There are basically two methods used to revise estimates of future project costs.
In many cases both methods are used on specific segments of the project. The result is
confusion of terms in texts, in software, and among practitioners in the field. We have
chosen to note the differences between the methods. The first method allows experts in
the field to change original baseline durations and costs because new information tells
them the original estimates are not accurate. We have used EACre to represent revisions
made by experts and practitioners associated with the project. The revisions from project
experts are almost always used on smaller projects.
Research data indicate that on large projects that are more than 15 percent
complete, the model performs well with an error of less than 10 percent (Fleming and
Koppleman, 2010; Christensen, 1998). This model can also be used for WBS and OBS
cost accounts that have been used to forecast remaining and total costs. It is important to
note that this model assumes conditions will not change, the cost database is reliable, EV
and AC are cumulative, and past project progress is representative of future progress.
This objective forecast represents a good starting point or benchmark that management
can use to compare other forecasts that include other conditions and subjective
judgments.
K. Other Control Issues
Measuring technical performance is as important as measuring schedule and cost
performance. Although technical performance is often assumed, the opposite can be true.
The ramifications of poor technical performance frequently are more profound—
something works or it doesn’t if technical specifications are not adhered to. Assessing
technical performance of a system, facility, or product is often accomplished by
examining the documents found in the scope statement and/or work package
documentation. These documents should specify criteria and tolerance limits against
which performance can be measured. For example, the technical performance of a
software project suffered because the feature of “drag and drop” was deleted in the final
product. Conversely, the prototype of an experimental car exceeded the miles per gallon
technical specification and, thus, its technical performance. Frequently tests are
conducted on different performance dimensions. These tests become an integral part of
the project schedule.
Large changes in scope are easily identified. It is the “minor refinements” that
eventually build to be major scope changes that can cause problems. These small
refinements are known in the field as scope creep. For example, the customer of a
software developer requested small changes in the development of a custom accounting
software package. After several minor refinements, it became apparent the changes
represented a significant enlargement of the original project scope. The result was an
unhappy customer and a development firm that lost money and reputation. Although
scope changes are usually viewed negatively, there are situations when scope changes
result in positive rewards. Scope changes can represent significant opportunities.3 In
product development environments, adding a small feature to a product can result in a
huge competitive advantage. A small change in the production process may get the
product to market one month early or reduce product cost.
A second defense against scope creep is stating what the project is not, which can
avoid misinterpretations later. (Chapter 7 discusses the process. See Figure 7.9 to review
key variables to document in project changes.) First, the original baseline must be well
defined and agreed upon with the project customer. Before the project begins, it is
imperative that clear procedures be in place for authorizing and documenting scope
changes by the customer or project team. If a scope change is necessary, the impact on
the baseline should be clearly documented—for example, cost, time, dependencies,
specifications, responsibilities, etc. Finally, the scope change must be quickly added to
the original baseline to reflect the change in budget and schedule; these changes and their
impacts need to be communicated to all project stakeholders.
Changes during the life cycle of projects are inevitable and will occur. Some
changes can be very beneficial to project outcomes; changes having a negative impact are
the ones we wish to avoid. Careful project definition can minimize the need for changes.
The price for poor project definition can be changes that result in cost overruns, late
schedules, low morale, and loss of control. Change comes from external sources or from
within. Externally, for example, the customer may request changes that were not included
in the original scope statement and that will require significant changes to the project and
thus to the baseline. Or the government may render requirements that were not a part of
the original plan and that require a revision of the project scope. Internally, stakeholders
may identify unforeseen problems or improvements that change the scope of the project.
In rare cases scope changes can come from several sources. For example, the Denver
International Airport automatic baggage handling system was an afterthought supported
by several project stakeholders that included the Denver city government, consultants,
and at least one airline customer. The additional $2 billion in costs were staggering, and
the airport opening was delayed 16 months. If this automatic baggage scope change had
been in the original plan, costs would have been only a fraction of the overrun costs, and
delays would have been reduced significantly. Any changes in scope or the baseline
should be recorded by the change management system that was set in place during risk
control planning.
Generally, project managers monitor scope changes very carefully. They should
allow scope changes only if it is clear that the project will fail without the change, the
project will be improved significantly with the change, or the customer wants it and will
pay for it. This statement is an exaggeration, but it sets the tone for approaching baseline
changes. The effect of the change on the scope and baseline should be accepted and
signed off by the project customer. Care should be taken to not use baseline changes to
disguise poor performance on past or current work. A common signal of this type of
baseline change is a constantly revised baseline that seems to match results. Practitioners
call this a “rubber baseline” because it stretches to match results. Most changes will not
result in serious scope changes and should be absorbed as positive or negative variances.
Retroactive changes for work already accomplished should not be allowed. Transfer of
money among cost accounts should not be allowed after the work is complete.
Unforeseen changes can be handled through the contingency reserve. The project
manager typically makes this decision. In some large projects, a partnering “change
review team,” made up of members of the project and customer teams, makes all
decisions on project changes.
Similar pseudo-percent complete systems have been used by others. Such pseudo-
percent complete approaches appear to work well in multiproject environments that
include several small and medium-sized projects. Assuming a one-week reporting period,
care needs to be taken to develop work packages with a duration of about one week long
so problems are identified quickly. For large projects, there is no substitute for using a
percent complete system that depends on data collected through observation at clearly
defined monitoring points.
The best information system does not result in good control. Control requires the
project manager to use information to steer the project through rough waters. Control and
Gantt charts are useful vehicles for monitoring time performance. The cost/schedule
system allows the manager to have a positive influence on cost and schedule in a timely
manner. The ability to influence cost decreases with time; therefore, timely reports
identifying adverse cost trends can greatly assist the project manager in getting back on
budget and schedule. The integrated cost/schedule model provides the project manager
and other stakeholders with a snapshot of the current and future status of the project.
L. Types of Project Closure
On some projects the end may not be as clear as would be hoped. Although the
scope statement may define a clear ending for a project, the actual ending may or may not
correspond. Fortunately, a majority of projects are blessed with a well-defined ending.
Regular project reviews will identify projects having endings different from plans. The
most common circumstance for project closure is simply a completed project. For many
development projects, the end involves handing off the final design to production and the
creation of a new product or service line. For other internal IT rojects, such as system
upgrades or creation of new inventory control systems, the end occurs when the output is
incorporated into ongoing operations. Some modifications in scope, cost, and schedule
probably occurred during implementation.
The pressure is on to finish the project and send it to production. Before
succumbing to this form of pressure, the implications and risks associated with this
decision should be carefully reviewed and assessed by senior management and all
stakeholders. Too frequently, the benefits are illusory, dangerous, and carry large risks.
Some projects never seem to end. The major characteristic of this kind of project is
constant “add-ons,” suggesting a poorly conceived project scope. At some point the
review group should recommend methods for bringing final closure to this type of project
or the initiation of another project. For example, adding a new feature to an old project
could replace a segment of a project that appears to be perpetual.
Failed projects are usually easy to identify and easy for a review group to close
down. However, every effort should be made to communicate the technical (or other)
reasons for termination of the project; in any event project participants should not be left
with an embarrassing stigma of working on a project that failed. Many projects will fail
because of circumstances beyond the control of the project team. See Snapshot from
Practice 14.1: The Wake, for a novel response to a canceled project.
Organizations’ priorities often change and strategy shifts directions. For example,
during the 2008–10 financial crisis organizations shifted their focus from money-making
projects to cost savings projects. The oversight group continually revises project selection
priorities to reflect changes in organizational direction. Projects in process may need to
be altered or canceled. Thus, a project may start with a high priority but see its rank erode
or crash during its project life cycle as conditions change. When priorities change,
projects in process may need to be altered or canceled. Different types of project
termination present unique issues. Some adjustments to generic closure processes may be
necessary to accommodate the type of project termination you face.
M. Wrap-up Closure Activities
The major challenges for the project manager and team members are over.
Getting the project manager and project participants to wrap up the odds and ends
necessary to fully complete a project is often difficult. It’s like the party is over—now
who wants to help clean up? Much of the work is mundane and tedious. Motivation can
be the chief challenge. For example, accounting for equipment and completing final
reports are perceived as dull administrative tasks by project professionals who are action-
oriented individuals. The project manager’s challenge is to keep the project team focused
on the remaining project activities and delivery to the customer until the project is
complete. Communicating a closure and review plan and schedule early allows the
project team to (1) accept the psychological fact the project will end and (2) prepare to
move on. The ideal scenario is to have the team member’s next assignment ready when
project completion is announced. Project managers need to be careful to maintain their
enthusiasm for completing the project and hold people accountable to deadlines, which
are prone to slip during the waning stages of the project.
Administering the details of closing out a project can be intimidating. Some
organizations have checklists of over 100 wrap-up tasks! These checklists deal with
closure details such as facilities, teams, staff, customer, vendors, and the project itself. A
partial administrative closure checklist is shown in Table 14.1. Getting delivery
acceptance by the customer is a major and critical closure activity. Delivery of some
projects to the customer is straightforward. Others are more complex and difficult. Ideally
there should be no surprises. This requires a well-defined scope and an effective change
management system with active customer involvement. User involvement is critical to
acceptance.
The conditions for completing and transferring the project should be set before the
project begins. A completed software program is a good example of the need to work out
the details in advance. If the user has problems using the software, will the customer
withhold final payments? Who is responsible for supporting and training the user? If
these conditions are not clearly defined up front, getting delivery acceptance can be
troublesome.
Another delivery tactic (briefly mentioned in Chapter 7) for a project that has
been outsourced is known as build, own, operate, and transfer (BOOT). In this type of
project the contractor builds, owns, and operates the project deliverable for a set period of
time. For example, Haliburton will operate a hydro-electric plant for six months before
turning over operations to their Indian counterparts. During this time all the bugs are
worked out and conditions for delivery are satisfied. Again, note the delivery conditions
need to be carefully set up before the project begins; if not, wrap-up activities can
develop a life of their own.
Releasing the project team typically occurs gradually during the closure phase.
For some people, termination of their responsible activities ends before the project is
delivered to the customer or user. Reassignment for these participants needs to take place
well before the final finish date. For the remaining team members (full or part time),
termination may result in a new project or returning to their functional job. Sometimes,
on product development efforts, team members will be assigned to operations positions
and play an active role in the production of the new product. For contract people it may
mean the end of their assignment to this project; in some cases there may be follow-up
work or user support possibilities. A small number of part-time participants may be
recommended to the user organization to train or operate new equipment or systems.
A final wrap-up activity is some form of celebration. For successful projects, an
upbeat, festive celebration brings closure to the enjoyable experiences everyone has had
and the need to say good-bye. Celebration is an opportunity to recognize the effort
project stakeholders contributed. Even if the project did not reach its objectives,
recognize the effort involved and goals that were achieved. If the project was a success,
invite everyone who in some way contributed to project success. Thank the team and
each one individually. The spirit of the celebration should be one in which the
stakeholders are thanked for a job well done and leave with a good feeling of
accomplishment.
N. Project Audits
Project audits are more than the status reports suggested in Chapter 13, which
report on project performance. Project audits do use performance measures and forecast
data. But project audits are more inclusive. Project audits not only examine project
success but also review why the project was selected. Project audits include a
reassessment of the project’s role in the organization’s priorities. Project audits include a
check on the organizational culture to ensure it facilitates the type of project being
implemented. Project audits assess if the project team is functioning well and is
appropriately staffed. Audits of projects in process should include a check on external
factors that might change where the project is heading or its importance—for example,
technology, government laws, competitive products. Project audits include a review of all
factors relevant to the project and to managing future projects.
Project audits early in projects allow for corrective changes, if they are needed, on
the audited project or others in progress. In-process project audits concentrate on project
progress and performance and check if conditions have changed. For example, have
priorities changed? Is the project mission still relevant? In rare cases, the audit report may
recommend closure of a project that is in process. These audits tend to include more
detail and depth than inprocess project audits. Project audits of completed projects
emphasize improving the management of future projects. These audits are more long-
term oriented than in-process audits. Postproject audits do check on project performance,
but the audit represents a broader view of the project’s role in the organization; for
example, were the strategic benefits claimed actually delivered?
Initiation of the audit process depends primarily on organization size and project
size along with other factors. In small organizations and projects where face-to-face
contact at all levels is prevalent, an audit may be informal and only represent another
staff meeting. But even in these environments the content of a formal project audit should
be examined and covered with notes made of the lessons learned. In medium-sized
organizations with few projects the audit is likely to be conducted by someone from
management with project management experience. In large companies or organizations
with many projects the audit is under the purview of the project office.
A major tenet of the project audit is that the outcome must represent an
independent, outside view of the project. Maintaining independence and an objective
view is difficult, given that audits are frequently viewed as negative by project
stakeholders. Careers and reputations can be tarnished even in organizations that tolerate
mistakes. In less forgiving organizations, mistakes can lead to termination or exile to less
significant regions of an organization. Of course, if the result of an audit is favorable,
careers and reputations can be enhanced. Given that project audits are susceptible to
internal politics, some organizations rely on outside consulting firms to conduct the
audits.
Each organization and project is unique. Therefore, the specific kinds of
information that will be collected will depend upon the industry, project size, newness of
technology, and project experience. These factors can influence the nature of the audit.
However, information and data are gathered to answer questions similar to those
suggested next. The audit group should not be limited to these questions. The audit group
should include other questions related to their organization and project type—e.g.,
research and development, marketing, information systems, construction, facilities. The
generic questions above, although overlapping, represent a good starting point and will
go a long way toward identifying project problem and success patterns.
The major goal of the audit report is to improve the way future projects are
managed. Succinctly, the report attempts to capture needed changes and lessons learned
from a current or finished project. The report serves as a training instrument for project
managers of future projects. Audit reports need to be tailored to the specific project and
organizational environment. Nevertheless, a generic format for all audits facilitates
development of an audit database and a common outline for those who prepare audit
reports and the managers who read and act on their content.
The term retrospective has emerged in recent years to denote specific efforts at
identifying lessons learned on projects. Proponents believe that the traditional audit
process focuses too much on project success and evaluation which interferes with the
surfacing and transferal of important lessons learned. They advocate a separate effort
toward capturing lessons learned. In many ways this effort mirrors the auditing process.
Typically, an independent, trained facilitator acts as a guide who leads the project team
through an analysis of project activities that went well, what needs improvements, and
development of follow-up action plan with goals and accountability. This facilitator may
come from the project office or be an external consultant. Wherever this individual comes
from, it is critical that she or he be perceived as being independent and unbiased.
Armed with the information gleaned from one-on-one sessions and other sources,
the facilitator leads a team retrospective session. The session first reviews the facilitator’s
report and attempts to add key information. So with regard to the information overload
problem, team members not only identify failure to flag critical information, but also a
tendency to “cc” everyone just in case. The facilitator works with the team to develop a
system that not only prioritizes information, but also does it according to who needs to
receive it.
Individual audits or postproject retrospectives can yield valuable lessons and
recommendations that team members can apply to future project work. When done on a
consistent basis, they can lead to significant improvements in the processes and
techniques that organizations use to complete projects. A more encompassing look from
an organizationwide point of view is to use a project maturity model. The purposes of all
maturity models (and there are many available) are to enable organizations to assess their
progress in implementing the best practices in their industry and move to improvement. It
is important to understand that the model does not ensure success; it only serves as a
measuring stick and an indicator of progress.
Why does it take so long? One reason is simply organizational inertia. It is
difficult for complex social organizations to institute significant changes while at the
same time maintaining business efficacy. “How do we find time to change when we are
so busy just keeping our heads above water?” A second significant reason is that one
cannot leapfrog past any one level. Just as a child cannot avoid the trials and tribulations
of being a teenager by adopting all the lessons learned by his or her parents, people
within the organization have to work through the unique challenges and problems of each
level to get to the next level. Learning of this magnitude naturally takes time and cannot
be avoided by using quick fixes or simple remedies. See Snapshot from Practice 14.6:
2015 PMO of the Year: Navy Federal Credit Union for how a PMO improved the
maturity of project management operations at a large credit union.
O. Post-Implementation Evaluation
Evaluation of performance is essential to encourage changes in behavior and to
support individual career development and continuous improvement through
organizational learning. Evaluation implies measurement against specific criteria.
Experience corroborates that before commencement of a project, the stage must be set so
expectations, standards, supportive organizational culture, and constraints are in place; if
not, the effectiveness of the evaluation process will suffer.
Most organizations do not go beyond these measures, although they are important
and critical. Organizations should consider evaluating the team-building process,
effectiveness of group decision and problem-solving processes, group cohesion, trust
among team members, and quality of information exchanged. Measurement of customer
and user satisfaction with project deliverables (i.e., the project results) is often missed
completely. Yet, project success depends significantly on satisfying these two very
important groups. The quality of the deliverables is the responsibility of the team.
In practice, the actual team evaluation process takes many forms—especially
when evaluation goes beyond time, budget, and specifications. The typical mechanism
for evaluation of teams is a survey administered by a consultant, a staff member from the
human resources department, or through computer e-mail. The survey is normally
restricted to team members, but in some cases, other project stakeholders interacting with
the team may be included in the survey.
Organizations vary in the extent to which their project managers are actively
involved in the appraisal process of team members. In organizations where projects are
managed within a functional organization, the team member’s area manager, not the
project manager, is responsible for assessing performance. The area manager may solicit
the project manager’s opinion of the individual’s performance on a specific project; this
will be factored into the individual’s overall performance. In a balanced matrix, the
project manager and the area manager jointly evaluate an individual’s performance. In
project matrix and project organizations in which the lion’s share of the individual’s work
is project related, the project manager is responsible for appraising individual
performance. One process that appears to be gaining wider acceptance is the multirater
appraisal or “360-degree feedback,” which involves soliciting feedback concerning team
members’ performance from all the people their work affects. This would include not
only project and area managers, but also peers, subordinates, and even customers.
Performance appraisals generally fulfill two important functions. The first is
developmental in nature: the focus is on identifying individual strengths and weaknesses
and developing action plans for improving performance. The second is evaluative and
involves assessing how well the person has performed in order to determine salary or
merit adjustments. These two functions are not compatible. Employees, in their eagerness
to find out how much pay they will receive, tend to tune out constructive feedback on
how they can improve their performance. Likewise, managers tend to be more concerned
with justifying their decision than engaging in a meaningful discussion on how the
employee can improve his or her performance. It is difficult to be both a coach and a
judge. As a result, several experts on performance appraisal systems recommend that
organizations separate performance reviews, which focus on individual improvement,
and pay reviews, which allocate the distribution of rewards.
Organizations employ a wide range of methods to review individual performance
on a project. In general, review methods of individual performance center on the
technical and social skills brought to the project and team. Some organizations rely
simply on an informal discussion between the project manager and the project member.
Other organizations require project managers to submit written evaluations that describe
and assess an individual’s performance on a project. Many organizations use rating scales
similar to the team evaluation survey in which the project manager rates the individual
according to a certain scale (i.e., from 1 to 5) on a number of relevant performance
dimensions (i.e., teamwork, customer relations). Some organizations augment these
rating schemes with behaviorally anchored descriptions of what constitutes a 1 rating, a 2
rating, and so forth. Each method has its strengths and weaknesses, and, unfortunately, in
many organizations the appraisal systems were designed to support mainstream
operations and not unique project work. The bottom line is that project managers have to
use as best they can the performance review system mandated by their organization.
Both managers and subordinates may dread a formal performance review. Neither
side feels comfortable with the evaluative nature of the discussion and the potential for
misunderstanding and hurt feelings. Much of this anxiety can be alleviated if the project
manager is doing her job well. Project managers should be constantly giving team
members feedback throughout the project so that individual team members can have a
pretty good idea how well they have performed and how the manager feels before the
formal meeting. Post-project angst can be avoided if pre-project expectations are
discussed before the project and regularly reinforced during project performance.
While in many cases the same process that is applied to reviewing the
performance of team members is applied to evaluating the project manager, many
organizations augment this process, given the importance of the position to their
organization. This is where conducting the 360-degree review is becoming more popular.
In projectdriven organizations, the project office typically will be responsible for
collecting information on a specific project manager from customers, vendors, team
members, peers, and other managers.
