<<

. 2
( 6)



>>

vulnerabilities.
• Vague role definitions. The reporting structures and responsibilities are unclear, causing conflicts.
Territorial disputes and power struggles occur often.
• No commonality or cohesiveness. The team is an unorganized grouping of people. No one feels a
sense of community or brotherhood. No common ground exists other than to meet periodically to work.
This results in lost synergy.
• Conformity and mind protection. Insecurity permeates people for fear of being different or
ostracized. People do not speak or share information unless it reinforces behavior or thoughts.
• Low tolerance for diversity. The pressure to conform is so intense that anyone different in thinking or
work style is ostracized or not taken seriously. Whistle-blowers and creative types, for instance, may be
viewed with suspicion. Under such circumstances no opportunity is available to capitalize on people™s
strengths and address their weaknesses.
• Insufficient resources. Whether it™s people, equipment, supplies, facilities, time, or money,
insufficient resources make teams ineffective. The situation can also lead to squabbling, dissention,
even revolts. If resources are not distributed in an objective, meaningful manner, then differences can
magnify into severe conflicts. Members of the team can quickly become polarized.
• Lack of management support. If team members perceive”whether justifiably or not”that
management is not supportive of the project, then motivation can plummet. People will feel that the
work is not valuable, at least to the organization.
• Listless team members. The goals are vague or nonexistent. Even if the goals are defined, no
one”including the project manager”seems to focus on them. Instead, everyone is aimless.
• Discontinuity between individual expectations and group expectations. There is a misalignment
between the two, with the latter not valuing the former. A symbiotic relationship between the two just
does not exist.
An ineffective team is conflict ridden, filled with distrust, unfocused, and reeking of negative competition.
These conditions manifest themselves in high turnover and absenteeism, considerable frustration levels, poor
communication, no esprit de corps, and intolerance.
Perry wants, of course, a project team with desirable characteristics:


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Characteristics of Effective Teams
Title

• Acceptance of new ideas and objective evaluation of them
• Sustained common norms, values, and beliefs without excessive conformity
• Synergy through mutual support
-----------
• Loyalty and commitment to the project
• Focus on end results
• A trusting, open attitude
• Ability to gain consensus and resolve conflicts
• High morale and esprit de corps
• Information and resources sharing
Perry knows all too well that a team with these characteristics is difficult to achieve. Yet he also knows that
such characteristics will not arise unless he takes action. There are seven actions that he takes to engender
such characteristics:
1. He sets the example. He not only espouses certain values and beliefs but also exercises them. He
wants people to be trustful and open, so he is trustful and open. He expects people to be committed, so
he is committed. In other words, he “walks the talk.”
2. He encourages communication”oral, written, and electronic. He knows that communication is more
than writing memos, standing in front of a team, or setting up a Web site. It requires sharing
information in an open and trusting manner, holding frequent meetings (status reviews and staff),
publishing a project manual, defining acronyms and jargon, employing technology as a
communications tool, and encouraging task interdependence.
3. He has the team focus on results. They direct all their energies toward achieving the vision. Whether
he or the team makes a decision, it is made in the context of achieving the vision. Perry constantly
communicates the vision and establishes change control and problem-solving processes.
4. He engenders high morale and esprit de corps by developing and maintaining the energy that comes
from teaming. He knows, however, that he must continually nurture that energy to keep it flowing. So
he empowers team members, encourages consensus building and win-win solutions, increases task
interdependence, matches the right person with the right task, and teams people with complementary
work styles.
5. He builds commitment to the vision and the project. Throughout the project cycle, team commitment
can rise or fall. Ideally, Perry wants to achieve the former. Ways to do that include matching people™s
interests with tasks, encouraging participative decision making, empowering people, seeking input and
feedback, assigning people with responsibility for completing deliverables, and keeping the project in
the forefront of everyone™s mind.
6. He lays the groundwork for synergy. A team is more than the sum of its members. But synergy
requires cooperation. Ways to obtain cooperation include providing cross-training so that people
understand each other™s roles and responsibilities, clearly defining roles and responsibilities,
determining each team member™s strengths and weaknesses and making assignments that capitalize on
the former, and having groups within the team be accountable for a complete work unit (e.g.,
subproduct or deliverable).
7. He encourages greater diversity in thinking, work style, and behavior. Always mindful of the danger
of groupthink, Perry encourages different thoughts and perspectives. He is especially aware of the
multicultural environment of the Smythe Project. The project culminates in Italy and, therefore,
requires working with people from another country. The Smythe family also has many friends around
the world who will attend the wedding. To ensure receptivity to diversity, Perry uses cross-training and
job rotation to broaden people™s understanding of each other, encourages experimentation and
brainstorming to develop new ideas and keep an open mind, seeks task interdependence to encourage
communication, and nurtures a continuous learning environment.

Team Diversity
With globalization of the economy in general and the Smythe Project in particular, Perry recognizes that the
challenge of leading a diversified team has never been greater. The team members have a variety of
backgrounds, including race, ethnicity, and religion. Leading a team in such an environment requires
heightened sensitivity to different values, beliefs, norms, and lifestyles.
Perry understands that people vary in their concept of time, ways of doing business, styles of management and
leadership, and views of how the world functions. He also understands that differences exist in the meaning of
words (semantics), interpretation of expressions (body language), perception of priorities, and definition of
team building. Needless to say, all this diversity adds complexity to the planning, coordination, and control of
the project. He knows, however, that he can deal with diversity in several ways.
1. He sets the example by embracing diversity. Through research, background reviews, interviews, and
the like, Perry learns about the diverse backgrounds of the people and encourages everyone to do the
same.
2. He is patient when dealing with people of a different background. He remains conscious of different
values and beliefs, for example, and accounts for them when leading the project.
3. He overcomes the temptation to stereotype. That is, he avoids generalizing about people based on
one characteristic. He also tackles stereotyping by team members. An effective approach is to have
people with different backgrounds work together. He can also have the team, with himself, attend
diversity training to understand and respect differences.
4. He has empathy for other people™s experiences. The word is empathy, not sympathy, since the latter
connotes patronization and condescension. He attempts to appreciate, for example, the difficulties in
reconciling different perceptions of time.
5. He encourages feedback. He is especially mindful to obtain feedback from people whose cultural
background is dramatically different from his own or from the rest of the team. This lessens the
tendency for the team to split into subgroups.


Previous Table of Contents Next
Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Contract Employees and Consultants
Title
Along with downsizing has come a corresponding rise in the use of consultants and contract employees. The
Smythe Project is no different, and its use of such people challenges his efforts to build a cohesive team.
Many contract employees and consultants do not feel they are part of a team. They know that their presence is
-----------
temporary; their participation could end at any time; hence their commitment is questionable. At the same
time, many permanent employees feel slighted by the presence of independent contractors and consultants.
They feel that management is exhibiting lack of confidence in their work, or that management perceives
outside help as better than inside. Team members may also feel that the contractors or consultants are
receiving higher compensation or the best offices or equipment.
These circumstances, real or imagined, challenge any team-building effort. But they are not insurmountable,
even for Perry. He gives preference to permanent employees regarding task assignments, equipment, and
other perks. An exception is made only if the consultant or contractor has unique expertise, and, if so,
preference is only for the duration of the task. Perry also gives employees the first opportunity to participate
in decision making. (More about contractors and outsourcing in Chapter 9.)

Telecommuting and Mobile Computing
In today™s environment, team members may be spread over a wide geographical area, presenting little
opportunity to see each other. (See Chapter 19 for additional information.) Team building can be extremely
difficult, thanks to this dispersion. To foster team building, however, Perry takes three important steps:
1. He tries to have everyone on the team meet periodically. At a minimum, this meeting provides an
opportunity to exchange ideas, share information, and become acquainted.
2. He develops rules of exchange or communications etiquette. For instance, colleagues should respond
to each other within a certain time. Such etiquette enables greater interaction, which in turn increases
bonding or cohesion.
3. He assigns people to tasks that require greater interaction and, if only occasionally, meeting
physically. If meeting is costly or impossible, the task should require at least some electronic
interdependence to generate cohesion.
In general, Perry treats the word TEAMING as an acronym to remind him of how to build a good project
team:
Target Focus on the end result.
Energize Provide the emotional spark that encourages high morale and esprit de corps.
Assemble Bring people together with defined roles and responsibilities.
Move Get people to move efficiently and effectively toward the results.
Inform Have people share knowledge, skills, and expertise, laterally and vertically.
Neutralize Remove biases and preferences in decision making.
Glue Keep the team as a cohesive unit so that synergy is produced.

There is additional information on telecommuting and other technology-based innovations in Chapter 19.

The Project Manager as a Motivator
Leadership plays an important role in the successful execution of a project. However, it is not something that
can be done in a “paint-by-number” fashion. Perry, like all experienced project managers, knows that
leadership must be constantly exercised throughout a project. It requires having a basic understanding of what
motivates people.
A vision statement partly satisfies the motivational needs of a project team. Perry realizes, however, that the
vision is just one aspect of leadership. He must build teams and focus all their efforts on achieving the vision.
The vision plays another role too. It provides the basis for developing a meaningful statement of work.

Questions for Getting Started

1. Can you identify the obstacles for exercising effective leadership inherent in your project?
2. How will you develop a vision for your project? How do you plan to communicate it? What are the
challenges you face in developing and communicating that vision? How do you plan to overcome
them?
3. How will you ensure that your project stays focused on the vision? What challenges will you face?
4. How will you facilitate and expedite performance? What obstacles will you face and how will you
overcome them?
5. In what ways (e.g., job enrichment) do you plan to motivate the people on your team? What
challenges will you face and how do you plan to overcome them?
6. In what ways (e.g., focus on the vision) will you encourage team building? What obstacles will you
face and how will you overcome them?
7. If you have contractors, consultants, or telecommuters, how will they be involved? What impact will
that have on the permanent team members and what will you do about any problems that arise?


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 5
The Statement of Work and the Project
Announcement
-----------

Perry recognizes that a key determinant for success or failure of a project is the adequacy of the definition. As
described in Chapter 1, the project manager defines the project, or determines its vision (as mentioned in
Chapter 4), goals, objectives, scope, responsibilities, and deliverables. He knows that good definition lays the
groundwork for developing reliable plans. It also sets the stage for effective communication throughout the
project cycle.
To define is to determine exactly the purpose and boundaries of the project. In other words,
• What are the goals and objectives?
• Who are the principal participants?
• When must the project be finished?
• Where will the project be executed?
• How will the result be achieved?
• Why is the project being launched?
• What are the constraints/limitations of the project?
By answering such questions Perry can better execute the other functions of project management. However,
getting answers to these and other questions is not easy. It requires considerable effort, largely by
interviewing members of the steering committee, contacting the customer, and reviewing documentation (e.g.,
the contract between the company and the Smythe family).

The Statement of Work
Although a contract has been signed between GWI and the Smythe family, many details remain unaccounted
for. Perry uses a statement of work (SOW) or, more informally, a statement of understanding to obtain and
record answers to any remaining questions.
The SOW is a definitive agreement between the customer and the project™s leadership about what is to be
accomplished. Perry knows, however, that the SOW is more than an agreement between the major
participants. It also sets the groundwork for effective communication, raises and addresses assumptions and
potential conflicts, and gives direction overall.
The SOW, then, is a medium for defining what the project will accomplish and the overall approach to take.
With an SOW Perry will have the answers to five W™s:
1. What is the product or service to be delivered?
2. Who are the primary participants, including the customers?
3. When must the project start and be completed?
4. Where will the project be undertaken?
5. Why is there a project?
More specifically, Perry will capture the following information:
• Constraints or limitations on the work
• Coordination requirements
• Levels of support from participants
• Major assumptions
• Major responsibilities
• Milestone dates
• Quality criteria
• Specific objectives
The onus is on Perry to acquire the data necessary to draft the SOW. It is also on him to draft the document
and obtain final approval. To obtain that data, Perry has several options, which include examining data from
earlier, similar projects; interviewing project sponsor, steering committee, vendors, or customers; reviewing
existing documentation, such as memos or procedures with earlier customers; and reviewing lessons learned,
if applicable, from earlier projects.
After collecting the data, Perry prepares a draft of the SOW, which follows this outline form:
I. Introduction
II. Scope
III. Assumptions
IV. Constraints
V. Performance Criteria
VI. Product/Service description

The Art of Interviewing
You don™t have to be a Barbara Walters or Larry King to conduct effective interviews. You just need to
follow a few principles:
• Determine the objectives of the interview. Is it specific information that you need or general
background information?
• Determine whether you want to do a structured or an unstructured interview.
Structured interviewing is asking a set of questions that help you get specific, often detailed information.
You use it when the subject matter is clear and unambiguous. For example, use a structured interview to
obtain specific information about a line item in a statement of work.
Unstructured interviewing is asking open-ended questions and winging it. The interviewer controls the
interview as it progresses. You use it when the subject matter is vague and greater insight into the subject
matter is necessary. For example, use an unstructured interview to obtain an understanding of the
customer™s expectations for a project.
Follow proper interviewing etiquette by asking permission to record or tape sessions, asking clear and
concise questions, keeping emotional distance from the response, listening actively, and scheduling
interview sessions at the right time. Avoid engaging in a debate and do not introduce bias in your questions.
If you follow these guidelines, interviewing will be a useful tool for acquiring information for your
statement of work.

VII. Major Responsibilities
VIII. References
IX. Amendments
X. Signatures

Exhibit 5-1 shows the draft SOW that Perry has prepared. When reviewing the draft, consider the purpose of
each major section.

Introduction

This section describes the goal of the project. It provides the name of the project, gives reasons for its
existence, names major players, and provides other pertinent information.
The Art of Negotiation
As a project manager, you will have plenty of opportunity to negotiate. You will have to negotiate
resources, schedules, budgets, and quality with customers, team members, and senior management.
Sometimes the negotiation will be formal, other times it will be informal.
When negotiating, keep these principles in mind:
1. Seek a win-win solution. Negotiation is not a victory over someone. Such victories are short-lived
and can cause greater problems later on.
2. Keep the commonalities between you and the person you™re negotiating with in the forefront of
your mind. Commonalities might include values, norms, tools, goals, or visions. By stressing what™s
common, you keep communication open.
3. Be flexible. A rigid stance may leave you with nothing or even a lose-lose result. Be flexible by
knowing what you value most and least.
4. Pick the right time and place to negotiate, one that is comfortable for both parties. Being
comfortable opens the dialogue.
5. Know as much as possible about the person you™re negotiating with.

Scope

This section lists the project™s “boundaries””that is, what is and is not to be done. The scope is important for
planning and also for minimizing changes.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Assumptions
Title

This section lists any unsubstantiated ideas about the project. Assumptions may, for example, relate to levels
of internal support or existing or market conditions. Assumptions are used in planning.
----------- Constraints

Rarely does a project have unlimited resources at its disposal. Money, time, people, equipment, supplies, and
facilities are often limited in quantity and quality. Recognizing such limitations early on enables realistic
planning.
Exhibit 5-1. Statement of work (SOW).
I. Introduction
This project resulted from a request by the Smythe family of 1801 Brotherhood Avenue, Rockford,
Pennsylvania. Although our primary focus is on weddings within the continental United States, this
wedding will occur in Naples, Italy. This is GWI™s first project outside the United States. It is
expected that this project will lead to similar ones in the future, substantially increasing our revenues.
II. Scope
This project will require all our services provided for domestic weddings. These services include:
• Announcements, including to friends, relatives, and newspapers
• Ceremony and reception locations
• Decorations and props
• Entertainment
• Flowers
• Food and beverages
• Hotel accommodations
• Invitations
• Lighting
• Music
• Photography
• Prewedding parties and rehearsals, including bachelor parties and bridal showers
• Sound
• Travel
• Videotaping
• Wedding attire
• Wedding feast and cake
• Wedding transportation

Services required by the Smythes but not available through GWI will be contracted out.
III. Assumptions
The Smythe Project will be managed based on the following assumptions:
• Internal resources will be available to include electronic and staffing.
• Contracted services will perform when required.
• The project will have priority over existing projects.
• No legal problems will occur in holding a wedding outside the United States.
IV. Constraints
The following constraints will be placed on the project:
• Culture differences may impede performance.
• Resources must continue to support other wedding projects.
V. Performance Criteria
The project will comply with all requirements listed in the contract between the Smythe family and
GWI. Any deviations from the contract must be reviewed by the steering committee and require
signatures.
The project must finish on 11 June 2000. The cost for the wedding cannot exceed $1 million (U.S.).
VI. Product/Service Description
GWI will provide a full one-day wedding service on top of Mount Vesuvius on 11 June 2000. The
wedding includes providing lodging for dignitaries, food, tourist attraction events, and entertainment.
GWI will also arrange the wedding ceremony, feast, and itinerary for the honeymoon. Refer to the
contract between the Smythe family and GWI. Also refer to Section II, Scope, for additional
information.
VII. Major Responsibilities
The project manager will:
• Serve as the primary point of contact for the project.
• Develop and execute a comprehensive project plan.
• Keep the steering committee informed regarding progress.
• Use all resources efficiently and effectively.
• Evaluate changes to all baselines.

The steering committee will provide continuous overseeing for the project, which includes:
• Periodic review of progress
• Guidance and direction, when necessary
• Reporting to the internal customer
VIII. References
The primary documents supporting this statement of work are:
• Contract between GWI and the Smythe family
• Existing company policies and procedures
IX. Amendments
This document may be changed only after review and approval of first the steering committee and
then the internal customer.
X. Signatures
• Project manager
• Steering committee members
• Internal customer

Performance Criteria

This section describes the criteria for customer satisfaction. Often, it points to three criteria: cost, schedule,
and quality. The project cannot, for example, cost more than a set amount; specific milestones or red-letter
dates must be met; service or product specifications must be addressed. This information allows for
meaningful planning and ensures that the project will address key concerns.

Product/Service Description

This section has an overall description of the product or service. This description might include the basic
features, characteristics, components, or deliverables to be produced. The content may be a narrative or a
diagram. This information is useful for developing a work breakdown structure.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Major Responsibilities
Title

This section delineates the high-level tasks of major participants. These tasks will be given in finer detail in
the work breakdown structure.
----------- References

This section lists any documentation that governs the content of the SOW. The documents often provide more
details for planning.

Amendments

The SOW is not something etched in stone, contrary to popular belief. It is a living document that probably
will be modified from time to time. This section is for appending any agreed-upon changes that come later.

Signatures

This section contains the approvals of all principal decision makers. At minimum, it should have signatures of
the project manager, executive sponsor, customer, and executive steering committee members. If the ultimate
customer is external to the company, as with the Smythe Project, the “customer” is frequently the liaison with
the external customer. If this is the case, the statement of work usually becomes part of the terms and
conditions of the formal contract.
Exhibit 5-2 shows a flowchart for developing a statement of work.

The Project Announcement
With a completed SOW, Perry has one more task before he can start to plan: publishing a project
announcement.
The project announcement is a widely distributed memo”albeit more than just another memo. It is also a
way to give visibility to the project, communicate to everyone the priority of the project, and acquire the
political muscle to compete with other projects.
Exhibit 5-2. Flowchart for statement of work.
Exhibit 5-3. Project announcement.
Date: 15 January 2000
To: Jones, N., et al.
cc: Rogersby, H., et al.
Subject: Smythe Project
Perry Fitzberg has been designated the project manager for the Smythe Project. He will report directly to the
executive steering committee, consisting of all functional vice-presidents of GWI.
The project must start no later than 30 January and be completed by 11 June 2000. The wedding will occur
in Naples, Italy. Approximately 1,000 people will attend the event.
Amelia
Amelia Rainbow
President, GWI
Extension 3400
Mailstop 01-01

The key question is, Who will prepare and sign the memo? Being a self-starter, Perry prepares the memo
himself and presents it to Amelia for signature. He believes she is the internal customer and sponsor for the
project. In many circumstances, however, there is a distinction between the two. Exhibit 5-3 shows the
announcement.
With publication of the project announcement, Perry can begin planning. The planning function, as described
in Chapter 1, entails many tasks, which are covered in Chapters 6 through 8.

Questions for Getting Started

1. Provide answers to these questions about your project:
• What are the goals and objectives of the project?
• Who are the principal participants?
• When must the project be started and finished?
• Where will the project be executed?
• Why is the project being launched?
• How will the product or service be?
2. If you don™t have the answers to any of the above, how are you going to get them?
• By interview?
• Document research?
• Contact with the customer?
3. Is a statement of work, or understanding, necessary? If so, do you know what is contained in each of
these sections:
• Introduction?
• Assumptions?
• Constraints?
• Performance criteria?
• Product/service description?
• Major responsibilities?
• References?
• Amendments?
• Signatures?
4. Do you need a project announcement? If so, do you know:
• Who will prepare it?
• Who will sign it?
• What the contents should be?


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 6
The Work Breakdown Structure
Perry now has the visibility he needs and the details for building the project. Now he will use the SOW to
-----------
develop a work breakdown structure, or WBS. The WBS is a detailed listing of the deliverables and tasks for
building the product or delivering the service. It is a top-down, broad-to-specific hierarchical outcome of the
work to perform.
There are several benefits to developing a WBS.
1. The WBS forces the project manager, team members, and customers to delineate the steps required
to build and deliver the product or service. The exercise alone encourages a dialogue that will help
clarify ambiguities, bring out assumptions, narrow the scope of the project, and raise critical issues
early on.
2. It lays the groundwork for developing an effective schedule and good budget plans. A well-defined
WBS enables resources to be allocated to specific tasks, helps in generating a meaningful schedule, and
makes calculating a reliable budget easier.
3. The level of detail in a WBS makes it easier to hold people accountable for completing their tasks.
With a defined WBS, people cannot hide under the “cover of broadness.” A well-defined task can be
assigned to a specific individual, who is then responsible for its completion.
4. The process of developing and completing a WBS breeds excitement and commitment. Although
Perry will develop the high-level WBS, he will seek the participation of his core team to flesh out the
WBS. This participation will spark involvement in the project.
Of course, developing a WBS is not easy. For one, it takes time”and plenty of it. A large WBS (one that
identifies several thousand activities) can take several weeks to develop. For another, it requires effort. There
is a knowledge transfer and exercise of brain power. The larger the scope of the project, the larger the WBS
will be. More people must provide input and then approve the portion they are responsible to perform.
Finally, the WBS requires continual refinement. The first iteration is rarely right and as the project changes,
so does the WBS. Still, the advantages outweigh the challenges. A good WBS makes planning and executing
a project easier.
Where WBSs Go Wrong
More often than not, a simple WBS can improve the overall performance of a project. Sometimes, however,
a WBS can do more harm than good. The reasons some WBSs fail are as follows:
1. The WBS does not have sufficient detail. If it is kept to too high a level, estimating, and tracking
the schedule and cost performance become “guesstimation.” Composite or roll-up views lack
meaning because the lower-level content is missing or too general to be reliable.
2. The WBS is the result of one individual and does not include those who will work on the tasks.
When the WBS is published, few team members have a sense of ownership or commitment to the
contents.
3. The WBS does not cover the whole project. It contains only the activities needed to build the
project. It might omit other important activities, such as project administration and training. The result
is that subsequent delivery of the product or service is unsatisfactory.
4. The entire WBS is not used in subsequent planning. The project manager takes an eclectic view of
the WBS, using only selected portions. The result is incomplete planning, lacking a comprehensive
view of the work to be done.
5. There is a failure to put the WBS under configuration management. Once everyone agrees on its
contents, the WBS should not become “frozen” or “baselined,” with all future changes not identified
or evaluated for their impact on the project. Failure to manage changes to the WBS can result in
unanticipated impacts on the scope, schedule, or cost.

As Perry progresses down each leg of the WBS, he gets to a level of detail that provides the ability to track
and monitor progress, make assignments that build accountability, and reliably estimate the hours to perform
tasks. How detailed the WBS gets depends on the level of control the project manager wants. Generally, the
more specific the WBS, the more accurate the planning and the greater the ability to monitor progress. A
common heuristic Perry uses is the 80-hour rule: each of the lowest-level items in the WBS should not exceed
80 hours™ effort. If the job requires more, then he breaks down the task into smaller tasks. Perry recognizes
that he will have to continually refine the WBS as he estimates the time to complete tasks.
To begin developing a WBS, Perry identifies all the requirements for the wedding. First he reviews the SOW,
which provides a guideline since it is representative of a high level and contains all the necessary information.
Other sources of information for building the WBS are documentation, including the WBS, of related
projects; interview notes; legal documentation; and memorandums.
With this information, Perry decides on how to approach the WBS. There are many ways to draw up a
WBS”for example, by responsibility (see Exhibit 6-1); by phase; or by deliverables. He decides on
deliverables for this WBS since that worked best for him in the past. It is also easier to determine progress at a
higher level when reporting to senior management or the customer.




Exhibit 6-1. Work breakdown structure based on responsibility.
The WBS generally consists of two components. The first component is the product breakdown structure
(PBS), which delineates the segments that constitute the final product or service. It may also contain items
deemed important (e.g., training). Each item in the PBS is described with a noun and a unique number.
The other component is the task breakdown structure (TBS), which contains the tasks to build or deliver
something (see Exhibit 6-2). It may also list tasks deemed important to the project. Each task in the TBS is
described with an action verb, a noun, and a unique number.


Previous Table of Contents Next
Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



The lowest level in the WBS is the work package level. These are the tasks or subtasks he will use to assign
Title
responsibilities, construct schedules, and track progress. Consider the WBS as a giant topical outline. Each
level lower is a breakdown of a higher level. The items in the lower level constitute the one in the next higher
level. Sometimes the higher levels of a WBS are managerial levels; the details are “rolled up” to the
managerial level for reporting purposes. Lower levels are called technical levels.
-----------




Exhibit 6-2. Task breakdown structure (TBS).
On very large projects, each task in the work package has an accompanying description, contained in a WBS
dictionary. Each entry in the dictionary describes the expected output of the task. Thus, a WBS dictionary can
help the project manager determine whether a task has been completed.
Perry™s WBS for the Smythe wedding is shown in the Appendix. He used a word processing program to
produce it. But he can also display the WBS graphically, as a tree diagram, by using graphics software.
Another way is to post sticky notes on a wall to display the hierarchical relationship. Either way, the display
will look like Exhibit 6-3.
With his draft of the WBS ready, Perry is now able to solicit input from the key players. He presents it to the
steering committee and obtains their acceptance. Next, he identifies the key skills needed to perform the tasks
and obtains additional input from team members. The PBS gives him an idea of the following needed
expertise:
• Attendants
• Cosmetologist
• Drivers
• Florist
• Hair stylist
Exhibit 6-3. Graphic display of task breakdown structure.
• Jewelers
• Lawyer
• Musicians
• Photographer
• Planners
• Public relations expert
• Receptionists
• Tailor
• Travel agents
• Ushers
• Valet
• Videographer
• Waiters
• Wedding consultants
At the moment, Perry has no idea how many people with the requisite expertise are necessary. But he will
require at least one of each on the core team (the key participants).
To acquire core team members, Perry needs once again to present his case to the steering committee, and
upon receiving its approval, to contact the relevant functional organizations. Perry now has his core team, as
shown in Exhibit 6-4. Perry then solicits input from these core team members regarding the WBS and gets
ready to take on the next step in planning: estimating the time to complete each task.
The work breakdown structure, although time-consuming to prepare, is an excellent foundation for the
remaining project planning functions. Next we consider the work-time estimates; which aid in the preparation
of schedules and costs.

Questions for Getting Started

1. What are the deliverables for your project? Did you display them in the product breakdown structure
(PBS) of the WBS?
Exhibit 6-4. Core team members.
Attendant, Pat Jones Public relations expert, Eva
Brewster
Cosmetologist, Cynthia Fralusinski Receptionist, Wonda Wrangell
Driver, Terry Karla Tailor, Frank Galucci
Florist, David Rockford Travel agent, Larry Eisenberg
Jeweler, Henry Winkless Usher, Michael Cramer
Lawyer, Robin Schister Valet, Danny Smith
Musician, Vy Toon Videographer, Raymond Leazowitz
Photographer, Gina Davies Waiter, Ted Rogers
Planner, Hank Wilson Wedding consultant, Mary Ewing

2. What are the tasks for your project? Did you display them in the task breakdown structure (TBS) of
the WBS?
3. Did you receive input from all relevant parties when building the WBS?
4. Did you perform the following when building the WBS:
• Explode each leg down to the lowest level of detail (e.g., using the 80-hour rule)?
• Give each item a unique number?
• Give each item in the PBS a name consisting of an adjective and a noun?
• Give each item in the TBS a name consisting of an action verb and an object?
5. Did you put the WBS under configuration control in the event that an item is added, removed, or
modified?


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 7
Techniques for Estimating Work Times
With the work breakdown structure complete, Perry can now estimate the time required to complete each task.
-----------
But remember, an estimate is just that, an estimate. The best Perry or any project manager can hope to
develop are reliable estimates ” ones that offer confidence in being achievable.

The Benefits and Challenges of Estimating Work Times
Estimating the work times provides several benefits for the project manager. It gives an idea of the level of
effort required to complete a project. This information then enables the project manager to produce a realistic
plan based upon that effort. Estimating also helps the project manager anticipate the budget for the project.
Allocated funds are largely based on the effort, or labor, to produce the product or deliver the service.
The estimate becomes the basis for developing a schedule. Hours are converted to flow time, which in turn is
used, with the interrelationships among tasks, to calculate start and stop dates. Lastly, doing an estimate
breeds commitment. If the people who will do the work also help make the estimates, they will feel more
committed to their tasks and keep within the allotted time.
While it offers many benefits, estimating is not easy, for two reasons. First, it takes time and effort to develop
reliable estimates. Many people take the path of least resistance and generate either an extremely pessimistic
or an overly optimistic estimate. Good estimating requires extensive calculation and research to avoid
skewing the calculated values. Second, estimating requires dealing with ambiguity. By its very nature,
estimating has both knowns and unknowns. The unknowns can generate fear or cause people to react out of
ignorance. Either way, confidence in the resulting estimate is low.

Types of Estimating Techniques
Perry and his team can use one of four techniques to estimate the time it will take to complete each task:
1. Scientific wildly assumed guess
2. Global efficiency factor
3. Productivity adjustment percent
4. Program evaluation and review, or three-point estimating, technique

Scientific Wildly Assumed Guess (SWAG)
This technique is the most popular, yet the most unreliable. The SWAG is most popular because it is quick.
The estimator determines a single value for time to do the work; no long calculations are necessary. The
estimator provides one figure for each task, quickly. The SWAG is also popular because it requires very little
research. Often, one or two individuals can do the entire estimate. It is rarely based on in-depth analysis to
derive the values.
However, the SWAG is also very unreliable for two reasons. First, it is highly subjective, based on one
person™s estimate of doing a task. It accounts for only a limited number of factors, relying on an hour estimate
that is based on a “feel” for doing the work.
Second, it understates or overinflates the time. If the estimators hold themselves in high regard, then the
estimate will be optimistic; if they lack confidence, then it will be pessimistic. As long as the same people do
the same work, then the estimates may prove reliable. What happens, though, if someone does the work who
had no input to the estimate? What happens if an obstacle arises that the new person cannot handle? Then the
estimate becomes unreliable.
For these two reasons alone, Perry decides not to use the SWAG technique. Now he is thinking about using
the global efficiency factor technique.

Global Efficiency Factor (GEF)
This technique is also easy to use and attempts to incorporate nonproductive time into the estimate. The
estimation assumes that a person is 100 percent productive. Then the estimator accounts for nonproductive
factors that are each assigned a percent relative to each other. The estimator deducts the percents from 100
percent to derive a more realistic estimate, as follows:
Task 10.4 Arrange for food and beverage
Deficiency Percent to Deduct

Unsatisfactory skill level 8

Unfamiliarity with project 10

Unfamiliarity with tools 5

Lack of well-defined requirements 2

Total Deficiency 25

Estimate to perform work 100 hours
Adjusted estimate 125 hours [100 hours + (100 hours — 25%)]

The GEF is not as popular but it does have its adherents. They believe that it accounts for nonproductive time
and eliminates the tendency toward unwarranted optimism.
However, the GEF technique has its drawbacks. The percents to deduct are often subjective themselves,
thereby skewed and subjective. The percent for each deduction will also often vary among people. Perry
decides, therefore, to look at another estimating technique: the productivity adjustment percent.

Productivity Adjustment Percent (PAP)
The PAP technique attempts to do on a more global scale what the GEF does. It applies an overall
productivity factor to the estimate for all tasks. For our example, we assume people are 80 percent productive:
Task 8.2.1 Determine floral requirements
100% - 80% = 20%. We now add this 20% factor to our baseline of 100%, giving us a PAP of 120%, or 1.2.
Estimate to perform work 100 hours
Adjusted estimate 120 hours (100 hours — 1.20)
The PAP has its adherents, for two reasons. First, it is based on historical figures. Work measurement studies
are frequently used to derive the overall percent. Second, it is easy to apply this calculation. There are no
percent deductions on a task-by-task basis nor any burdensome mathematical calculations.
Despite these two benefits, there are some disadvantages. The historical records are not always available to
determine the productivity factor for an organization. Also, the figure is so global that it may not be relevant
to a specific task. Finally, it does not account for the complexity of issues involving individual tasks. For
these three reasons, Perry does not use the PAP technique. That leaves one other option: the PERT.

Program Evaluation and Review Technique (PERT)
The PERT, also known as the three-point estimating technique, uses three estimates of time to complete a
task. The three estimates are the most likely, most pessimistic, and most optimistic. The most likely time is
the effort (usually in hours) to complete a task under normal or reasonable conditions. The most pessimistic
time is the effort to complete a task under the worst conceivable circumstances. The most optimistic is the
effort to complete a task under the best or ideal circumstances. The three variables are then used to calculate
an expected time to complete a task, as shown below:




Task 1.3.2.1 Determine type of entertainment/music




This estimating technique accounts for the level of effort to complete a task after accounting for all the
parameters to do the work. The estimator assumes that a person is 100 percent productive during the time to
complete the task. Realistically, of course, no one is 100 percent productive. Some time is inevitably spent
being nonproductive, so the hour estimates are adjusted to account for this nonproductive time (e.g., telephone
calls, meetings, break times). This time has no direct relationship to the work being done; the results have no
impact on progress on the actual work. Below is an example of how to calculate the revised expected time:
Task 10.3 Coordinate transportation (ground and air)
Estimate to perform work = 500 hours
500 hours — 1.10 (for 10% nonproductive time) = 550 hours
Revised expected time = 550 hours


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



The three-point estimating technique has its problems. For one, it is time consuming; performing the
Title
calculations can take a long time, even when a computer is used, especially for a large project. Also, it is
laborious; performing the calculations requires considerable thinking and searching for reliable information.
Lastly, not too many people understand the reasons for taking this approach; its underpinnings are probability
and bell curve analysis, which can be intimidating and too academic for some people.
-----------
How to Reevaluate an Estimate
Sometimes you might feel uncomfortable with an estimate. Perhaps you suspect it is unrealistic. Perhaps
you think the reasoning behind it is faulty. Perhaps you do not trust the people making the estimate.
Whatever the reason, you can take several actions to validate the estimate.
You can check the historical records of other projects that dealt with similar work. Sometimes, however,
such data are either difficult to obtain or unavailable.
You can seek a second opinion. It might mean going to someone on another project where similar work was
performed. It might mean going to an outside expert or organization for an evaluation.
You can benchmark one or more tasks. It may mean comparing the estimates with similar ongoing or
completed projects, either inside or outside your company.
You can apply the Delphi approach. Simply identify a number of people to provide input on an estimate.
Then make the adjustment and resubmit the estimate to them for further adjustment. The adjustment ends
once you gain concurrence or are comfortable with the result.
Finally, you can conduct peer reviews. Once all the estimates are complete, you can assemble everyone in a
room to discuss the estimate for each task. Assumptions and issues may arise that will call into question the
validity of some estimates. New estimates can then be developed.

The technique, however, does offer four benefits. It forces people to think seriously about the time to
complete a task; the three variables require looking at as many parameters as possible to calculate a realistic
estimate. The estimate is more reliable than other estimating techniques; it accounts for many parameters to
compensate for being too optimistic or pessimistic. It improves communication; discussion over the
parameters that relate to each variable forces people to communicate to come to a conclusion. It identifies
issues and assumptions early. When calculating each variable, people must identify issues and assumptions.
To ignore issues and assumptions adds to the cost of addressing them later in the project cycle.
What Happens When No One Wants to Give the Project Manager an Estimate?
Project managers often lack formal authority over the people on their teams. This is especially the case in a
matrix environment, where people report to a functional manager and may support several projects
simultaneously.
Sometimes project managers just do not get cooperation from team members. The team members may fear
commiting themselves, hate to wrestle with unknowns or ambiguities, or just not like the project manager.
What, then, is a project manager to do?
Project managers have several options:
1. They can document the refusal to cooperate in a memo and address it to the functional manager.
This takes advantage of formal authority to get the estimate.
2. They can hold a team meeting, where everyone can discuss and share their estimates in the
presence of other team members. This takes advantage of peer pressure to get the estimate.
3. They can solicit input from other people. Then they present the estimate to the uncooperative team
member and formally request his or her feedback. This takes advantage of professional pride.
4. They can make the estimate themselves and inform the person in a memo that unless there is
acceptance by a certain date, the accuracy of the estimate will be assumed. This takes advantage of
time pressure.

Of the four estimating techniques, Perry elects the three-point estimating technique. He believes that it will
provide more-reliable estimates and also offer many other benefits. So, using the three-point estimating
technique requires Perry to keep in mind the following points.
1. He must get input estimates from the people who will do the actual work. He appreciates their
knowledge of what is required to complete the work. He also knows that getting their input will
encourage commitment to their assigned tasks. It is one thing to follow someone™s dictate of the hours
to do the work; it is another when he does the estimate himself.
2. He must look at the historical records of other projects. Rather than apply the estimating technique
for all tasks, he may uncover some reliable estimates that can be reused for similar tasks. He is cautious
enough to realize that circumstances are not always exactly the same from one project to another.
Consequently, the reusable estimate may require revision. Also, he reminds himself that it is still a good
idea to get input from people who will do the work.
3. He must identify and document the assumptions and parameters used to derive the estimates. Doing
this is important for two reasons. First, he and others will better understand the rationale behind the
estimates. Second, he can also determine what has changed since making the estimate and make
revisions accordingly.
4. He must maintain consistency in the estimating process. He avoids using the three-point estimate
technique for some tasks and not for others. Otherwise, he will mix “apples with oranges,” with some
estimates being realistic, optimistic, or pessimistic. A lack of discipline in this regard can result in an
unrealistic schedule.
5. He must make the estimates public. After getting feedback, he will publish the estimates. He does
not hide the estimates, as though they were his personal golf scores or bowling averages. By publishing
the estimates, Perry knows that people will feel a subtle pressure to use them.
6. He must understand that the estimates are approximations, not accuracies. Circumstances change
that make estimates irrelevant. That requires reestimating during the project to increase the reliability
and validity of the overall estimate. Ideally, an estimate has the highest confidence level, which
becomes more possible as a project progresses through its cycle.

Factors to Consider in Drawing Up Estimates
Estimators consider many factors when performing their calculations. These include:
• Availability of nonlabor support
• Clarity and definitiveness of scope
• Complexity of the work
• Degree of available information to estimate
• Degree of uncertainty or risk in achieving the outcome
• Experience, knowledge, and expertise of the team members
• Financial constraints on the project
• History of similar work performed
• Legal constraints on the project
• Location of team members working on the task
• Number of people assigned to the task
• Number of potential interruptions
• Priority of the task
• Productivity of team members
• Project size
• Standardization of processes related to the task
• Structure versus unstructured nature of the work to be performed
• Whether the completion date of the task is dictated
When estimating, Perry will consider Parkinson™s law. He knows that too much available time to perform a
task is almost as troublesome as too little. Parkinson™s law, of course, says that work expands to fill the time
available. In other words, if given ten hours to complete a task when it ordinarily takes five hours, people will
take ten hours. So Perry treats Parkinson™s law seriously.
Perry is now ready for the next big planning action: developing a schedule.

Questions for Getting Started
1. Did you identify all the work package items in the work breakdown structure?
2. Did you select the most appropriate estimating technique? What are the reasons for your choice?
3. With at least the core team members, did you get time estimates for the tasks they are responsible
for completing?
4. If you meet resistance, how do you plan to overcome it?
5. If necessary, how will you reevaluate estimates? Review historical records? Apply the Delphi
approach?


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 8
Schedule Development and the Network Diagram
With the statement of work and the work estimates completed, Perry is now ready to do some scheduling. In
-----------
so doing, he will juggle six factors: scope, time, duration, tasks, logic, and resources. The scope is described
in the SOW. Time is the hour estimate to complete each task”in other words, the estimates. Duration is the
hour figure converted to flow time for completing each task and, consequently, the entire project. Tasks are
the entries in the WBS. Logic is the sequence of tasks. And resources are the labor and nonlabor investments
assigned to each task. But all of this will become clearer as we explain more about scheduling.

What Scheduling Is
Scheduling entails making a logical sequence of tasks and then calculating start and stop dates for each task.
The results are displayed as a diagram.
A schedule is only useful if people are willing to commit themselves to maintaining it. Therefore, Perry sits
down with his core team and determines the logical sequence of tasks. He has everyone look at the big
picture, tying together all the tasks. They use this perspective to draw a network diagram, like the one in
Exhibit 8-1. The network diagram displays the logical relationships between the tasks.
Network diagramming may initially seem complex, especially if you™ve not had previous experience drawing
flowcharts. The advantages, however, are great. By constructing the diagram, you focus on the project goal
and discover the appropriate approach. Difficult issues become apparent, so the effort and expense of dealing
with them later is avoided. In addition, the diagram enables easier tracking of performance because it is based
on the work-package level items in the WBS. Finally, making forecasts and “what-if” scenarios is easier.
Warning Signs of Bad Scheduling Practices
Bad scheduling practices can tarnish the credibility of a schedule. Watch for these two common indicators
of bad scheduling:
• Warning Sign Number 1: Sometimes people are unsure of the future, so rather than calculate an end
date for a task, they write “TBD,” or “to be determined.” It not only represents unclear and
incomplete thinking but also opens the opportunity for guesswork and poor oversight of tasks.
• Warning Sign Number 2: Occasionally people will develop schedules that contain too much
negative float (being too tight) or too much positive float (being too loose). Either way, it indicates a
problem with the schedule, especially one of realism. Too much negative float indicates that the
schedule cannot be realistically accomplished; too much positive float indicates that estimates for the
tasks are too low.

Task Dependencies and Date Scheduling
A network diagram will show one or more of the following relationships, or dependencies, between tasks.
Finish-to-Start
An earlier activity, or the predecessor, is completed and the next one, the successor, is begun, as illustrated in
Exhibit 8-2. Sometimes the succeeding task is not begun immediately; there is, in other words, a lapse of time
between the end of the predecessor and the start of the successor. That interval is called lag. A task can have
one or more predecessors or successors.




Exhibit 8-1. Network diagram.




Exhibit 8-2. Finish-to-start relationship.
Start-to-Start
Two activities are begun around the same time, as displayed in Exhibit 8-3. Sometimes one task is begun just
a little later than the other; the gap between the start of one task and the beginning of the other is also called
lag.
Finish-to-Finish
Two activities are finished around the same time, as shown in Exhibit 8-4. Sometimes one task will finish
earlier than the other, yet each must finish before its successor is begun. The time between the finish of one
and the other is also called lag.



Exhibit 8-3. Start-to-start relationship.




Exhibit 8-4. Finish-to-finish relationship.
Having identified all the dependencies between the tasks, Perry can apply the time estimates to each task. But
the raw time estimates must be converted to some meaningful value. For starting purposes only, Perry
converts the hour estimates into workdays. He divides the hours by 8 to derive the number of days needed to
complete the task. He then uses this duration, or flow time, to calculate the start and stop date for each task.
Actually, Perry calculates two sets of start and stop dates: early and late start dates, and early and late finish
dates. The early start and early finish dates are the first pair to calculate. The early start date is the earliest
time a task can be begun. The early finish date is the earliest time a task can be completed. These dates are
determined by comparing the duration of a task with the dates for the preceding and succeeding tasks.
Why Some People Don™t Do Scheduling
Occasionally you run into people who do not like schedules. Sometimes that person is even the project
manager.
There are all sorts of reasons for this reluctance. People might feel the time or effort expended to build the
schedule exceeds the value gained. Or they might not want to commit themselves.
If you are working with someone who is reluctant to schedule, you have several options. You can document
a person™s reluctance in a memo and send it to higher-level management. You can hold a group meeting and
cover the schedule in general, letting peer pressure prompt the person to cooperate. A related tactic is to
apply the Delphi method by encouraging input from everyone, then make changes, recirculate for feedback,
and repeat the cycle until everyone is satisfied with the results.

Some dates may not be logically derived from a network diagram. For example, certain tasks may have to
start no earlier than a specific date or may not finish earlier or later than a specific time. In some cases, tasks
may have to begin or finish on a specified date; these are known as constraint dates. Likewise, the start or
finish date of a task may depend on the start or completion of a task in another project. The output of one
project, for example, may feed another. Under these circumstances, the task has an external dependency that
must be considered when calculating start and finish dates.

Perry™s Scheduling Method
Here™s how Perry calculates the early start and early finish dates for his tasks. First, he assigns activity
numbers to the tasks in the WBS and converts the time estimates into flow times, as shown below:


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Activity Number Task Description Hours Duration (Hours/8)
Title
6.1-1.1 3
Identify limousine service to church 24

6.1.1.2 1
Coordinate limousine service to church 8
-----------
6.1.2.1 3
Determine transportation requirements to church 24

6.1.2.2 2
Coordinate transportation to church 16

6.1.2.5 1
Arrange for valet service for church 8

Next, Perry logically ties all the tasks together in a network diagram. (A network diagram was shown in
Exhibit 8-1.) After determining the durations and sequences, Perry calculates the early start and early finish
dates for each task and then the entire project. He performs the forward pass, by moving from the first task in
the network diagram up through the last.
Now, as shown in Exhibit 8-5, Perry knows that task 6.1.1.1 will begin on 8:00 A.M., April 1. He also knows
that the previous task was completed the day before. He knows, too, that the duration is three days, meaning
the task will be done on April 1, 2, and 3, finishing at 5:00 P.M. on the April 3. Task 6.1.2.1 is the successor
and it will begin on April 4 at 8:00 A.M. It, too, has a duration of three days and is completed at 5:00 P.M. on
April 6.
Two successor tasks follow 6.1.2.1. They both will begin on the day after 6.1.2.1 is completed, April 7. Task
6.1.2.2 has a duration of two days, so it is completed at 5:00 P.M. on April 8. Task 6.1.1.2 has a duration of
one day, so its completion date is April 7.




Exhibit 8-5. Forward pass (where ES is early start, EF is early finish).
Task 6.1.2.5 cannot be begun until its two predecessor tasks are finished. The one that is finished the furthest
out”6.1.2.2”must end before 6.1.2.5 can begin. Hence, 6.1.2.5 will begin on April 9 and, with a duration of
one day, will be completed on April 9.
Perry now calculates the late start and late finish dates for each task. Using the same durations and
dependencies in the network diagram, he moves from right to left, beginning with the very last task and
calculating the late start and late finish dates. This movement from right to left is the backward pass, as
shown in Exhibit 8-6.
Assuming that the finish date to task 6.1.2.5 has been set as April 9, Perry can begin the backward pass. He
knows that 6.1.2.5 has a duration of one day and, consequently, begins on that same day, providing a late start
date of April 9. He realizes that task 6.1.2.5 has two predecessors, 6.1.1.2 and 6.1.2.2. Since they each finish
the day before, their late finish dates are April 8. Task 6.1.2.2 has a duration of two days and, consequently,
has a late start date of April 7. Since task 6.1.1.2 is a concurrent activity, and has a shorter duration, it can
begin as far back as April 7, the same late start date as 6.1.2.2. Since 6.1.2.1 is the predecessor to both 6.1.1.2
and 6.1.2.2, it must have a late finish date of April 6. Since task 6.1.2.1™s duration is three days, its late start
date is April 4. And since task 6.1.1.1 is the predecessor of 6.1.2.1, it must finish the day before, on April 3;
with a duration of three days, it must have a late start on April 1.
Is Work Group Participation the Best Way?
In many environments, project managers develop schedules without input or feedback from the people who
will be doing the work. There are several reasons for this.
One is the time required to obtain this input. Getting people involved adds time, and the more people, the
more time to develop the schedule. Also, the project manager has overall responsibility for the project. The
project manager has the big picture perspective and can ensure that “all the pieces fit together.”
The counterargument is that the work group should have a say in building the schedule. Although
participation adds to the flow time, it does offer some powerful advantages. By obtaining input, the project
manager solicits ownership in and commitment to the schedule, especially for the work each person is
responsible to do. Work group participation also helps to raise issues and question assumptions early to
preclude future misunderstandings and problems.




Exhibit 8-6. Backward pass (where LS is late start, LF is late finish).

Note: this is only a partial description of the network diagram for the wedding. It™s a “snapshot” presented here
to illustrate the basics of network diagramming and calculating dates.


The Float
Perry now has four dates for each task: early start, early finish, late start, and late finish. These dates are
necessary to calculate the float for a task. Float is the time an activity can slide without affecting the project
completion date. For instance, if a task does not have to be begun right away, there may be time to slide. Or if
it does not have to be finished as early as possible, there is time to let the date slide a bit.
Perry uses a simple calculation to determine float: the difference between the early start date and the late
finish date, minus the duration, as shown in Exhibit 8-7.


Previous Table of Contents Next
Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Tasks given a zero float means that they cannot slide; if they do, then the project end date will slide, too. The
Title
one or more paths through the network diagram that have tasks with zero floats are called the critical path, as
shown in Exhibit 8-7.
There are, in reality, two types of float. The float just described is known as total float and affects the project
end date. The other type is the free float, which occurs on noncritical paths. This is the time that an activity
-----------
can slide without impacting the start date of its successor.




Exhibit 8-7. Critical path showing float.

Other Types of Network Diagrams
Perry has used one type of network diagram, but several other types exist. Perry™s choice is the precedence
diagramming method. It is used most often in nonconstruction applications, such as in the information
systems, pharmaceutical, and engineering industries.
For construction applications, the arrow diagramming method is used. It, too, relies on relationships, but they
take a different form. The arrow diagram uses “nodes” to represent events and arrows to describe the task
between those nodes. Also, this technique uses dummy activities that consume no resources, unlike the
precedence diagramming method.
Another diagramming technique is the bar, or Gantt, chart. The fundamental difference between a bar chart
and a network diagram is that the former does not show dependencies. The bar chart displays a list of tasks
and, for each one, a bar shows the flow time or duration. As Exhibit 8-8 shows, a standard bar chart does not
present all four dates for a task.
The bar chart often is useful, for several reasons. It is easy to read, showing only one set of start and finish
dates. The bar itself provides a visual means to check the status of a task. It is also excellent for “rolling up,”
or summarizing the progress of a related group of tasks. Thus, its simplicity, visual orientation, and
summarization capabilities make it an excellent tool for reporting to senior management. It gives senior
management the big picture rather than the details. A bar chart using roll-ups is shown in Exhibit 8-9.




Exhibit 8-8. Basic bar chart.




Exhibit 8-9. Roll-up bar chart.

The milestone chart is a type of bar chart. It has the outlay of a bar chart but also has an icon or symbol to
mark the occurrence of an event. The icon has a duration of zero. This event might be receiving approval or
the completion of a task. Exhibit 8-10 is an example of a milestone chart. Like the basic bar chart, it is best
used when reporting to senior management.
Exhibit 8-10. Milestone chart.
Month
Task Duration Jan Feb Mar Apr May Jun
1.0 Parties Ê
2.0 Stationery Ê
3.0 Photography/ Ê
Videography
4.0 Gifts and favors Ê
5.0 Attire Ê
6.0 Transportation Ê
7.0 Fees Ê
8.0 Flowers Ê
9.0 Honeymoon Ê
10.0 Guests Ê

Perry uses the network diagram to plan the details of the project and manage it from day to day. He uses the
bar chart for reporting to senior management.

The Schedule as a Road Map
Using the work breakdown structure and the time estimates that he developed earlier, Perry builds a realistic
schedule. The schedule provides a road map for him and all team members to follow.
However, he realizes that a schedule can help him to accomplish only so much. He also needs to organize his
project so that he can efficiently and effectively execute his plan.
Questions for Getting Started
1. Did you develop a network diagram or a bar chart? Or both?
2. If you developed a network diagram, did you:
• Assign task numbers to each item in the WBS? Is the numbering scheme meaningful?
• Identify the people who will help you put the logic together?
• Tie all the tasks together to form a complete, logical diagram?
• Convert the hours for each task to flow time or duration?
• Calculate the early and late start and finish dates for each task?
• Consider the constraints, such as imposed dates, when calculating dates?
• Consider relationship types and lag?
• Calculate float to identify the critical path(s)?
• Obtain all core team members™ concurrence?
Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 9
Resource Allocation:
Aligning People and Other Resources With Tasks
-----------

For the Smythe Project to succeed, Perry must have sufficient resources”that is, both people and things”and
use them efficiently and effectively. Resource allocation, a part of the organizing function, allows him to do
that.
As Perry knows, a project manager has a wide variety of resources to employ, including people, supplies,
equipment, and facilities. People, for most projects in general and for the Smythe Project in particular, are the
predominant resource and, consequently, the major focus here to illustrate resource allocation principles.
Resource allocation involves four basic steps:

1. Identify the Tasks Involved
Perry goes directly to the network diagram to identify the tasks involved in his project. These tasks are the
same ones as at the work package level in the work breakdown structure (see Chapter 6).

2. Assign Resources to Those Tasks
Perry starts determining how to best apply his resources. When assigning people resources, he considers
several factors, including:
• Availability
• Available budget
• Education/training
• Equipment to do work
• Expertise
• Individual™s desire or interest
• Knowledge
• Personality
• Teaming
Perry also considers behavioral factors, such as personality. He recognizes that some people may not be
suitable to do certain tasks (e.g., an engineer may well be unsuitable to do the work of a salesman).
Perry also considers the motivational tools at his disposal. He will use job enlargement, for instance, to
challenge certain people to assume more responsibilities. He uses job enrichment to motivate other team
members. And he considers job rotation. Of course, Perry recognizes that there are some risks, mainly the
inability of the person to handle different or greater responsibilities. However, Perry is willing to take the
chance in applying his people resources, since the potential payback in productivity will easily outweigh the
risks.
When allocating resources, Perry applies the following heuristics (or rules of thumb):
• With noncritical tasks, give preference to the task with the least float.
• Give priority to tasks on the critical path.
• If two activities are critical and have the same float, give preference to the more complex task.

3. Build a Resource Profile
The resource profile graphically displays the planned and actual use of one or more resources over the
duration of a task, group of tasks, or entire project. The display is often a histogram, as shown in Exhibit 9-1.
The x-axis shows a time continuum reflecting the early or late start and finish dates. The y-axis shows the
cumulative hours to perform one or more tasks. The continuous vertical bars profile the cumulative hours that
someone will work on one or more concurrent tasks.
The initial histogram often has an irregular shape. The high points are peaks, reflecting greater use of
resources at a specific point in time. The low points are valleys, reflecting lower use of resources at a specific
point in time. Exhibit 9-1 is an example of a histogram with several peaks and valleys.
An irregular shape to the histogram reflects that resources are being employed inefficiently or ineffectively.
The peaks may indicate that the schedule is too tight (i.e., compressed durations), thereby requiring extensive
overtime to complete the work. The schedule may be too loose (i.e.,




Exhibit 9-1. Unleveled histogram.

durations too spread out). The valleys may indicate that too much time is available to complete a task. Either
way, such scenarios can negatively affect motivation, performance, and productivity. Too much duration
communicates a lack of importance or urgency. Too little duration can lead to burnout, negative conflict, and
work owing to oversights or mistakes.
Therefore, Perry attempts to reduce the number of peaks and valleys by smoothing out the histogram as much
as possible, similar to what appears in Exhibit 9-2. The result is called a leveled histogram, and the process of

<<

. 2
( 6)



>>