MGT 323 3rd

page 279

Darinburt/Getty Images

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.

page 280

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

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

page 281

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 can be documented and used to justify acquiring additional

equipment, recruiting critical personnel, or delaying the project.

SNAPSHOT FROM PRACTICE 8.5

Multiple Project Resource Scheduling

The case for a central source to oversee project resource scheduling is well known by practitioners. Here is a synopsis of a conversation with one middle manager.

Interviewer: Congratulations on acceptance of your multiproject scheduling proposal. Everyone tells me you were very convincing.

Middle Manager: Thanks. Gaining acceptance was easy this time. The board quickly recognized we have no choice if we are to keep ahead of competition by placing our resources on the right projects.

Interviewer: Have you presented this to the board before? Middle Manager: Yes, but not this company. I presented the same spiel to the firm I

worked for two years ago. For their annual review meeting I was charged to present a proposal suggesting the need and benefits of central capacity resource planning for managing the projects of the firm.

I tried to build a case for bringing projects under one umbrella to standardize practices and to forecast and assign key people to mission critical projects. I explained how benefits such as resource demands would be aligned with mission critical projects, proactive resource planning, and a tool for catching resource bottlenecks and resolving conflicts.

Almost everyone agreed the idea was a good one. I felt good about the presentation and felt confident something was going to happen. But the idea never really got off the ground; it just faded into the sunset.

With hindsight, managers really did not trust colleagues in other departments, so they only gave half-hearted support to central resource planning. Managers wanted to protect their turf and ensure that they would not have to give up power. The culture there was simply too inflexible for the world we live in today. They are still struggling with constant conflicts among projects.

I’m glad I made the switch to this firm. The culture here is much more team-oriented. Management is committed to improving performance.

Finally, many companies are using outsourcing as a means of dealing with their resource allocation problems. In some cases, a company will reduce the number of projects they have to manage internally to only core projects and outsource noncritical projects to contractors and consulting firms. In other cases, specific segments of projects are outsourced to

page 282

overcome resource deficiencies and scheduling problems. Companies may hire temporary workers to expedite certain activities that are falling behind schedule or contract project work during peak periods when there are insufficient internal resources to meet the demands of all projects. The ability to more efficiently manage the ebbs and flows of project work is one of the major driving forces behind outsourcing today.

8.10 Using the Resource Schedule to Develop a Project Cost Baseline

Once resource assignments have been finalized, you are able to develop a baseline budget schedule for the project. Using your project schedule, you can time-phase work packages and assign them to their respective scheduled activities to develop a budget schedule over the life of your project. Understanding the reason for time-phasing your budget is very important. Without a time-phased budget, a good project schedule and cost control are impossible.

Why a Time-Phased Budget Baseline Is Needed

LO 8-9 Explain why a time-phased budget baseline is needed.

The need for a time-phased budget baseline is demonstrated in the following scenario. The development of a new product is to be completed in 10 weeks at an estimated cost of $400,000 per week, for a total cost of $4 million. Management wants a status report at the end of 5 weeks. The following information has been collected:

Planned costs for the first 5 weeks are $2,000,000. Actual costs for the first 5 weeks are $2,400,000.

How are we doing? It would be easy to draw the conclusion there is a $400,000 cost overrun. But we really have no way of knowing. The