Description

reassessed. Cost-time trade-offs can be considered. In some cases priorities
may be changed. See Snapshot from Practice 8.3: U.S. Forest Service
Resource Shortage.
Resource schedules provide the information needed to prepare timephased work package budgets with dates. Once established, they provide a
quick means for a project manager to gauge the impact of unforeseen events
such as turnover, equipment breakdowns, or transfer of project personnel.
Resource schedules also allow project managers to assess how much
flexibility they have over certain resources. This is useful when they receive
requests from other managers to borrow or share resources. Honoring such
requests creates goodwill and an “IOU” that can be cashed in during a time
of need.

SNAPSHOT FROM PRACTICE 8.3
U.S. Forest Service Resource Shortage
A major segment of work in managing U.S. Forest Service (USFS) forests
is selling mature timber to logging companies that harvest the timber under
contract conditions monitored by the service. The proceeds are returned to
the federal government. The budget allocated to each forest depends on
the two-year plan submitted to the U.S. Department of Agriculture.
Olympic Forest headquarters in Olympia, Washington, was developing a two-year
plan as a basis for funding. All of the districts in the forest submitted their timber sale
projects (numbering more than 50) to headquarters, where they were compiled and
aggregated into a project plan for the whole forest. The first computer run was reviewed
by a small group of senior managers to determine if the plan was reasonable and
“doable.” Management was pleased and relieved to note all projects appeared to be
doable in the two-year time frame until a question was raised concerning the computer
printout. “Why are all the columns in these projects labeled ‘RESOURCE’ blank?” The
response from an engineer was “We don’t use that part of the program.”
The discussion that ensued recognized the importance of resources in completing the
two-year plan and ended with a request to “try the program with resources included.” The
new output was startling. The two-year program turned into a three-and-a-half-year plan
because of the shortage of specific labor skills such as road engineer and environmental
impact specialist. Analysis showed that adding only three skilled people would allow the
two-year plan to be completed on time. In addition, further analysis showed hiring only a
few more skilled people, beyond the three, would allow an extra year of projects to also
be compressed into the two-year plan. This would result in additional revenue of more
than $3 million. The Department of Agriculture quickly approved the requested extra
dollars for additional staff to generate the extra revenue.

Darinburt/Getty Images

page 279

8.8 Assigning Project Work
LO 8-7
Identify general guidelines for assigning people to specific tasks.

When making individual assignments, project managers should match, as
best they can, the demands and requirements of specific work with the
qualifications and experience of available participants. In doing so, there is
a natural tendency to assign the best people the most difficult tasks. Project
managers need to be careful not to overdo this. Over time these people may
grow to resent the fact that they are always given the toughest assignments.
At the same time, less experienced participants may resent the fact that they
are never given the opportunity to expand their skill/knowledge base.
Project managers need to balance task performance with the need to
develop the talents of people assigned to the project.
Project managers need to decide not only who does what but also who
works with whom. A number of factors need to be considered in deciding
who should work together. First, to minimize unnecessary tension,
managers should pick people with compatible work habits and personalities
but who complement each other (i.e., one person’s weakness is the other

person’s strength). For example, one person may be brilliant at solving
complex problems but sloppy at documenting his progress. It would be wise
to pair this person with an individual who is good at paying attention to
details. Experience is another factor. Veterans should be teamed up with
new hires—not only so they can share their experience but also to help
socialize the newcomers to the customs and norms of the organization.
Finally, future needs should be considered. If managers have some people
who have never worked together before but who have to later on in the
project, they may be wise to take advantage of opportunities to have these
people work together early on so that they can become familiar with each
other. Finally, see Snapshot from Practice 8.4: Managing Geeks for some
interesting thoughts from the former CEO of Google on how to put together
teams.

SNAPSHOT FROM PRACTICE 8.4
Managing Geeks*
Eric Schmidt, after a successful career at Sun Microsystems, took over
struggling Novell, Inc., and helped turn it around within two years. Four
years later he became the CEO of Google. One of the keys to his success
is his ability to manage the technical wizards who develop the sophisticated
systems, hardware, and software that are the backbone of electronically driven
companies. He uses the term “geek” (and he can, since he is one, with a Ph.D. in
computer science) to describe this group of technologists who rule the cyberworld.
Schmidt has some interesting ideas about assigning geeks to projects. He believes
that putting geeks together in project teams with other geeks creates productive peer
pressure. Geeks care a great deal about how other geeks perceive them. They are good
at judging the quality of technical work and are quick to praise as well as criticize each
other’s work. Some geeks can be unbearably arrogant, but Schmidt claims that having
them work together on projects is the best way to control them—by letting them control
each other.
At the same time, Schmidt argues that too many geeks spoil the soup. By this he
means that when there are too many geeks on a development team, there is a tendency
for intense technical navel gazing. Members lose sight of deadlines, and delays are
inevitable. To combat this tendency, he recommends using geeks only in small groups.
He urges breaking up large projects into smaller, more manageable projects so that
small teams of geeks can be assigned to them. This keeps the project on time and
makes the teams responsible to each other.

*

Russ Mitchel, “How to Manage Geeks,” Fast Company, May 31, 1999, pp. 175–80.
page 280

8.9 Multiproject Resource Schedules
LO 8-8
Identify common problems with multiproject resource scheduling.

For clarity we have discussed key resource allocation issues within the
context of a single project. In reality resource allocation generally occurs in
a multiproject environment where the demands of one project have to be
reconciled with the needs of other projects. Organizations must develop and
manage systems for efficiently allocating and scheduling resources across
several projects with different priorities, resource requirements, sets of
activities, and risks. The system must be dynamic and capable of
accommodating new projects as well as reallocating resources once project
work is completed. While the same resource issues and principles that apply
to a single project also apply to this multiproject environment, application
and solutions are more complex, given the interdependency among projects.
The following are three of the more common problems encountered in
managing multiproject resource schedules. Note that these are macro
manifestations of single-project problems that are now magnified in a
multiproject environment.
1. Overall schedule slippage. Because projects often share resources,
delays in one project can have a ripple effect and delay other projects.
For example, work on one software development project can grind to a
halt because the coders scheduled for the next critical task are late in
completing their work on another development project.
2. Inefficient resource utilization. Because projects have different
schedules and requirements, there are peaks and valleys in overall
resource demands. For example, a firm may have a staff of 10

electricians to meet peak demands when, under normal conditions, only 5
electricians are required.
3. Resource bottlenecks. Delays and schedules are extended as a result of
shortages of critical resources that are required by multiple projects. For
example, at one Lattice Semiconductor facility, project schedules were
delayed because of competition over access to test the equipment
necessary to debug programs. Likewise, several projects at a U.S. forest
area were extended because there was only one silviculturist on the staff.
To deal with these problems, more and more companies are creating project
offices or departments to oversee the scheduling of resources across
multiple projects. One approach to multiple project resource scheduling is
to use a first come–first served rule. A project queue system is created in
which projects currently under way take precedence over new projects.
New project schedules are based on the projected availability of resources.
This queuing tends to lead to more reliable completion estimates and is
preferred on contracted projects that have stiff penalties for being late. The
disadvantages of this deceptively simple approach are that it does not
optimally utilize resources or take into account the priority of the project.
See Snapshot from Practice 8.5: Multiple Project Resource Scheduling.
Many companies utilize more elaborate processes for scheduling
resources to increase the capacity of the organization to initiate projects.
Most of these methods approach the problem by treating individual projects
as part of one big project and adapting the scheduling heuristics previously
introduced to this “mega project.” Project schedulers monitor resource
usage and provide updated schedules based on progress and resource
availability across all projects. One major improvement in project
management software in recent years is the ability to prioritize resource
allocation to specific projects. Projects can be prioritized in ascending order
(e.g., 1, 2, 3, 4, . . .), and these priorities will override scheduling heuristics
so that resources go to the project highest on the priority list. (Note: This
improvement fits perfectly with organizations that use project priority
models similar to those described in Chapter 2.) Centralized project
scheduling also makes it easier to identify resource bottlenecks that stifle
progress on projects. Once bottlenecks have been identified, their impact
page 281
can be documented and used to justify acquiring additional

Purchase answer to see full
attachment