. 1
( 5)



>>

Project Management
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search



Acknowledgments

Chapter 1”Introduction to Project Management
Title
A Science and an Art
Characteristics of Work Using Project Management
Overview
-----------


Chapter 2”Initiating a Project
Criteria for Initiating a Project
The Project Client
What Are Your Overall Objectives?
Defining Project Requirements
Conducting Focused Interviews With the Project Client
Preparing the Project Initiation Documentation


Chapter 3”Building the Project Team
Assembling the Project Team
Defining and Documenting Team Member Commitment
Building a Strong Project Team
Managing the Team During the Project


Chapter 4”A Model for Project Planninig
The Integrated Project Plan
The Five-Step Planning Model
Strategic Planning
Saving Time and Funds With Historical Files
Facilitating the Project Planning Process
Effective Planning


Chapter 5”Project Planning Techniques: Schedule, Cost, and Resource
Utilization
Work Breakdown Structure
Project Network
Estimating Techniques
Critical Path Analysis
Scheduling
Resource Loading
Key Business Applications


Chapter 6”Managing Project Change
Scope Changes
Baseline Changes


Chapter 7”A Model for Project Control
Transition From Planning to Controlling
Formal and Informal Control
A Five-Step Model for Project Control
Project Team Members™ Role in the Controlling Process


Chapter 8”Project Control Techniques: Status Reports and Reviews
Designing and Producing Status Report Documents
Preparing and Conducting Status Review Meetings


Chapter 9”A Model for Earned Value: Achievement-Accomplishment
Monitoring
The Role of Milestones
Achievement Monitoring
Analysis of Accomplishment Data
Calculations Using Accomplishment Data


Chapter 10”Supporting Project Management: Software, Training, and
Administration
Software Support
Training Support
Political Aspects of Support
Index



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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Acknowledgments
First and foremost, the authors would like to thank Dr. Linda Henderson for taking the thoughts of two crusty
old project managers and turning them into communicable project management English. Also, we want to
----------- thank Muriel Rogers for the computer graphics support. Last but not least, we want to acknowledge the
AMACOM staff, Myles Thompson for his role as Project Client, Jackie Laks Gorman for her developmental
assistance, and Richard Gatjens and Beverly H. Miller (through Beehive Production Services) for the copy
editing. We couldn't have completed this work without all of you.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 1
Introduction to Project Management
If you were asked to define the term project, what words would come to mind? Time? Resources (or lack of)?
-----------
One-of-a-kind effort? Deliverables or products? Complex? No authority over other groups? Budget?
A project is a unique effort to introduce or produce a new product or service conforming to certain
specifications and applicable standards. This effort is completed within the project parameters including fixed
time, cost, human resources, and asset limits. Projects are said to be similar to the mating of two elephants:
They start at a very high level with lots of noise and activity, but it takes forever for anything to materialize!
A more serious definition is that a project is a well-organized development of an end product that had a
discrete beginning, a discrete end, and a discrete deliverable. Our goal is to help you become more organized
as you work toward this objective.
Project management is the discipline that relates all of those words that you thought of that apply to project.
This discipline cultivates the expertise to plan, monitor, track, and manage the people, the time, the budget,
and the quality of the work on projects. Project management fulfills two purposes: (1) It provides the
technical and business documentation to communicate the plan and, subsequently, the status that facilitates
comparison of the plan against actual performance, and (2) it supports the development of the managerial
skills to facilitate better management of the people and their project(s). Project management is a proactive
style of management. Negotiation techniques and good communication and analytical skills are integral parts
of this approach. Another key ingredient is the evaluation of performance against those objectives. Central to
this management style is the application of high standards of quality to the project work.
Project management is a means by which to fit the many complex pieces of the project puzzle together. This
is accomplished by dealing with both human and technical elements of the discipline of project management.
Here is our definition of project management:
Definition of Project Management
Project management is a set of principles, methods, tools, and techniques for the effective management of
objective-oriented work in the context of a specific and unique organizational environment.
The project management process encompasses these tasks:
• Assembling a project team with the expertise necessary to execute the project
• Establishing the technical objectives
• Planning the project
• Managing changes to the scope
• Controlling the undertaking so that it is completed on schedule and within budget
Project management is an evolving discipline that integrates the processes of producing the end product with
the processes of planning, change management, control, and initiating preventive and corrective action. It
begins when a decision is made to devote resources to an effort and ends when the desired result has been
accomplished.
Project management is not designed for the management and control of nonproject, day-to-day activities
within the organization. Responsibility for the day-to-day planning, operations, and control of the staff
remains with the functional managers and is accomplished with existing tools and techniques. Responsibility
for the technical direction of the work also remains with the functional managers. Functional management
supports the project management approach rather than being a part of it. The manual and computer-based
techniques used to plan and control work within functional areas can and should be used in conjunction with
project management techniques. Necessarily, planning and control efforts associated with functional work
will have to encompass the portions of projects to which the function must contribute and should be done in a
manner that supports the project management information requirements.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



A Science and an Art
Title

Project management is both a science and an art. It is perceived as a science because it is supported by charts,
graphs, mathematical calculations, and other technical tools. Producing these charts requires the hard skills to
manage a project. But project management is also driven by political, interpersonal, and organizational
-----------
factors”thus the “art” of project management. Communication, negotiation, and conflict resolution are only a
few of the soft skills used in the art of project management.
Each topic explored in this book provides you with both the hard and the soft skills you will need to manage
your projects efficiently and effectively. This book provides you with the technical tools of project
management to address the scientific side of the discipline, as well as the human behavioral techniques.

Characteristics of Work Using Project Management
The word project is a buzzword. The tendency is to use it very loosely.
People refer to the jobs they have been assigned to perform as projects. The secretary refers to cleaning out a
file cabinet and disposing of old, outdated material as a project. The youth refers to cleaning up his or her
room as a project. A spouse refers to wallpapering the bedroom as a project. These assignments,
however”and others like them”lack the characteristics that lend themselves to the application of the
discipline of project management. Project management can be used with work that has three major
characteristics: desired technical objectives, a deadline, and a budget (see Figure 1-1).
1. A discrete technical objective: If knowledge of the end product or service does not exist, it is
extremely difficult to produce a plan. In this circumstance, some type of planning may be possible, but
project planning it is not! If the definition of the technical objective is part of the project, the effective
application of project management requires that the project be broken into several smaller projects, the
first of which will have the technical objective as its end product. In addition, the end product should be
capable of being examined in some objective manner to determine whether it possesses the attributes
and quality desired by the individual(s) for whom the project is being accomplished. If the product will
be assessed on the basis of subjective criteria, it is much more difficult to plan and to manage the effort.
Figure 1-1 Characteristics of project management.
2. A deadline: The deadline can be established prior to the development of the project plan, or it can be
the result of negotiation between the project manager and the client after the plan has been conceived.
In either case, the project team ultimately works toward a designated end date, with some consequence
associated with any delay in completion of the effort.
3. A budget: The budget can be in the form of dollars and/or staffing required; it can be established
prior to the development of the project plan, or it can be the result of negotiations between the project
manager and the client based on the plan.
In addition, the project manager and the other personnel with the requisite subject matter expertise must be
able to divide or partition the work into small, discrete segments whose completion can be measured. This
partitioning or decomposition of the work results in the development of a task (or to-do) list. If the task list is
hierarchical and has a logical structure, it is called a work breakdown structure (WBS).
There should be an established sequence in which to perform the segments of the project. If the segments are
to be performed in a random sequence, the effort still may be planned, but much of the discipline of project
management does not apply. There should be a method for estimating the effort required to accomplish each
component of the assignment. If significant phases of the effort cannot be estimated, the methodology of
project management will not yield the desired results.
Project work obviously involves a client”the person for whom the project is being undertaken. This person
or persons can be referred to as the client, the customer, the user, or the project sponsor. The client is the
person who must be satisfied if the project is to be a success. In most instances, the client controls the purse
strings and approves change requests made during the course of the project.

Overview
In this book, we focus on several key project management processes and models. Chapter 2 thoroughly
discusses the key questions that project managers must answer in order to initiate and define a project. A
critical part of initiating and defining a project is building the project team. Chapter 3 describes the typical
process used for assembling a project team and explores in detail the ways to build a strong and successful
team.
The foundation of all projects is the plan. Chapters 4 and 5 provide extensive coverage of project planning.
Chapter 4 addresses in depth the process for planning a project, which encompasses a five-step integrated
planning model. The specific techniques of project planning are covered in Chapter 5, which describes in
detail how to work through the five-step model through the use of charts, graphs, mathematical calculations,
and validation techniques.
The project management environment is dynamic and constantly in flux. Chapter 6 analyzes the typical
changes that take place in project baseline schedules, resource allocations, and budgets. Our analysis also
includes a close look at the various sources of change to the technical objectives of the project&146;s end
product.
The effective and successful management of change requires the efficient use of project control methods.
Chapter 7 thus describes a five-step model for controlling a project: updating the status, analyzing the impact,
acting on variances, publishing the revisions, and informing management. Chapter 8 addresses the role of
reports and reviews for controlling and reporting project status.
Determining the value of work completed on a project is the subject of Chapter 9, which addresses the major
component for measuring the completion of work: assessments of the state of the project based on milestone
completions. Finally, in Chapter 10, we look at ways to use software, training, and administrative support to
increase the effectiveness of project management.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 2
Initiating a Project
A story about Gertrude Stein underscores the need for 1effectively initiating a project. As Stein was lying on
-----------
her deathbed, surrounded by friends and followers, she was approached by a good friend, who whispered in
her ear, “Gertrude, what is the ANSWER?” There was a long pause. Then Stein slowly sat upright, looked her
questioner in the eye, and replied, “What is the QUESTION?”
“What is the question?” provides the overall direction for this chapter. If you don™t understand the question,
you cannot possibly be expected to find the solution. Nor can you plan or manage the project. Therefore, in
this chapter we discuss how to initiate a project.

Criteria for Initiating a Project
There are four criteria for initiating a project:
B-A-N-C Criteria
Budget
Authority
Need
Cycle

These criteria highlight the key questions that should be asked and, ultimately, answered in any project. You
may interpret these questions differently depending on your industry, its prevailing economic trends, or your
organization™s competitive position within the marketplace. Regardless of how strong you think your
company or division is in the external/internal marketplace, misjudging business opportunities or submitting a
less than high-quality proposal can lose business that is needed to grow or survive.
Let™s take a close look at the key questions that need to be addressed in each of the B-A-N-C areas. First, does
the client have the budget (funding) to pay for the job? If not, when will the funding be available? If the
answer is “not in the near future,” this still might be a good future project opportunity. In this case, don™t put a
lot of time and effort into writing a lengthy proposal, but don™t lose touch with the prospect.
Second, does your contact have the authority to approve the project? If not, has he or she been delegated the
authority? If not, how far up the line does your prospect have to go to obtain approval? If your contact is not a
decision maker and does not have formal or informal power to fund the project or direct access to a decision
maker, this project opportunity may not be worthy of a lot of effort now (although maybe it will later).
Third, is there an identified need that everyone agrees on? If not, can you help define the need? Will you
and/or your client contact be able to sell the need once it is substantiated? And then, can your organization
satisfy the need with your current expertise or products? If not, how much risk is there in acquiring the skills
or products to fulfill the assignment without exceeding the schedule and budget? If the answers to these
questions are no”indicating an unfavorable risk and reward on this venture”pass up this opportunity, but
keep track of it. Once the need is truly defined and once the risk is acceptable, you want to be there to offer
your services.
Fourth, regarding the cycle, when will the client act? Is there money left in the budget for your project? Is the
money allocated for your type of project, or will it be next quarter or maybe next year until monies are made
available? The further away the cycle is, the less time you want to spend now; however, when that cycle
draws near, be ready to ride the wave.

The Project Client
Do you remember the television game show “To Tell the Truth”? There were three contestants, each making
the same claim (to have the same job or to have achieved the same goal, for example). A panel of celebrities
posed a series of questions to the contestants and then identified the contestant they believed was telling the
truth. The dramatic moment in the show came when the moderator asked the person who was telling the truth
to stand up. Usually there were several false moves on the part of the contestants before the genuine one stood
up, to thunderous applause.
We are often reminded of this show when we ask project managers, “Who is your client?” There are several
scenarios that may occur in a project management environment when asking, “Will the real client please stand
up?” Here are three of them and some advice on how to handle each one.

Scenario 1: An Entire Department Is the Client
Our favorite example of this scenario came from a project manager who told us that the manufacturing
division of his organization was his client. Even in the face of repeated probing, he refused to alter his answer.
It was definitely the manufacturing division. The manufacturing division of his company employs
approximately 600 people, including three who work the graveyard shift cleaning up the tool crib.
Would it be necessary to interview each of the 600 people in order to determine the project requirements?
Who would approve the project plan and be an integral part of the project™s day-to-day management? Who
would evaluate changes of project scope? Who would be held accountable for the success or failure of the
project?
Obviously a department cannot be the client of a project. Our recommendation is to have one person or a
small group be the client, accountable for the project.

Scenario 2: There Are Multiple Clients
Sometimes several people stand up and declare themselves all as the project client. This scenario has good
news and bad news. The good news is that there is interest and enthusiasm for the project since more than one
person considers it advantageous to be seen as the client. The bad news is the problems posed. Who will be
the arbitrator or the mediator if there is disagreement among the clients? More important, who will ultimately
be accountable for the success or failure of the project? Our recommendation is to have one person or a small
group led by one person be the project client, accountable for the project.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Scenario 3: Nobody Wants to Be the Project Client
Title

In this scenario, when the question, “Will the real project client please stand up?” is asked, no one stands up.
Everyone looks at each other, waiting for someone else to accept accountability for the project. Perhaps the
project is not worth doing at all. Maybe the support is not there to justify proceeding with the idea. However,
----------- if the project is required, then some of the powers that be within the organization must designate an individual
or a small group to be the project client. Unless this role is clearly defined, the project client may be reluctant
to allow his or her name to be put on the project paperwork or may have no intention of putting any time into
the project. In order to begin to set expectations in this situation, develop a job description that goes along
with this assignment. This description should clearly define the degree of involvement and the specific role
that this person will play in the project from initiation to completion. Once again, our recommendation is to
have one person or a small group led by one person be the project client, accountable for the project.
Where should this one person or small group come from? There are several answers (or a combination of
answers) to this question, such as:
Sources for Project Clients
• The person representing the area that has the greatest vested interest in the outcome of the project
• The person from whose budget the project is being funded
• The person who has a success record of on-time, on-budget project completions
• The person who has the political pull to get all the areas in the company to work together on the
project
• The highest-level decision maker who has the clout to make things happen
• The person who wants it bad enough to put the energy into the project and make it successful
• All of the above

Keep in mind these two rules of thumb when selecting a project client or having one selected for you: (1) have
one person or a small group led by one person be the project client and be accountable for the project, and (2)
have that person be strong enough and dedicated enough to invest the time and energy to fulfill the role
successfully.
What Are Your Overall Objectives?
The client, once determined, must work with the project manager to establish the objectives for the project.
Project objectives are variously, and loosely, defined as the scope, technical objectives, statement of work,
and/or specifications. This set of terms is often misunderstood and in need of explication and clarification.
Consensus on the meaning of these terms will probably never be achieved. However, some framework for
their use is helpful.

Project Objectives
Project objectives is the broadest and most inclusive of the terms; all project targets are part of the project
objectives. Thus, the objectives are the characteristics of the deliverable(s), the target costs at completion, the
target completion date, and the target resource and asset utilization at completion. Without the first three
characteristics, the project objectives are incomplete; the last two are optional. The target cost at completion
and the target completion date can be negotiated after preparation of the plan, or they can be provided to the
project manager as constraints to the planning process.

Technical Objectives
Technical objectives refers to the subset of the project objectives that addresses the characteristics of the
deliverable(s). Many people use the term scope to refer to the technical objectives. The technical objectives
contain two parts: specifications, which describe the characteristics of the product or service that is being
developed in the project, and standards, which enumerate the governmental, institutional, and organizational
norms that the project or service is expected to meet. We might also include the assumptions made to cover
gaps in available information during planning as part of the technical objectives. These assumptions must be
considered part of the project objectives and may be considered part of the technical objectives.

Statement of Work
A statement of work is usually synonymous with the technical objectives of a project, but the term is applied
differently by different organizations. Regardless of the terminology utilized, if the work effort is to be
considered a project, the following three parameters must be met:
Parameters of a Project
1. A statement describing the end-of-work item to be produced as a result of completing the project
2. A stated period of performance
3. A budget

Let™s discuss the first parameter, which describes the end-of-work item to be produced.

Defining Project Requirements
Defining requirements forces the project manager to define clearly and concisely the scope of the work and
place parameters, or a fence, around the project before the plans are developed. When the subject of technical
objectives is raised, references to the requirements of the end product or to the deliverable are often made.
The requirements are the components of the specifications of a deliverable defined by the project manager and
the project client. The definition of the requirements occurs after the goal of the project has been given to the
project manager but before the detailed plan for the project is created. The requirements describe the desired
features or performance characteristics of the product in quantifiable terms, necessary so that the results can
be measured. One of the problems with requirements is that they tend to overlap, and there is always some
question as to where one begins and another leaves off. Nevertheless, overlapping should not be regarded as a
disadvantage, because it tends to ensure comprehensive coverage of the desired attributes of the end product.
There are a number of possible requirements for describing and measuring a deliverable:
Requirements for Describing and Measuring a Deliverable
• Quality, performance, and quantity
• Reliability and maintainability
• Capability to survive
• Operability
• Manufacturability
• Flexibility
• Regulatory compliance
• Materials use
• Community relations and corporate image



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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Quality, Performance, and Quantity
Title

Quality is a broad and complex requirement. It can be described as excellence, robustness, or a level of
perfection in the product. Performance is usually more specific and may also be composed of additional
considerations. Performance may be measurable in terms of miles per hour or tensile strength, for example, or
----------- it can be discussed in nonmeasurable terms, such as the end users™ level of satisfaction with the way a product
functions. The requirement of quantity raises the question, When does the project end? Clearly if the objective
of the project is to produce seven identical items, project management may be utilized to manage the entire
effort until the seventh item has been delivered. But what if the quantity is 25,000 items to be produced over a
period of several years? Should project management be used to control the production effort? Probably not.
Nevertheless, a definition of completion of the project is required in order to plan for the transition from
project management to production management. This definition might be the completion of a pilot
manufacturing run or the point at which the bill of materials for the product is initiated in the computer. The
point is to have a tangible definition.

Reliability and Maintainability
Reliability is defined as mean time between failures or mean time to replacement of a component, part,
subsystem, or system. It can also refer to the useful life of the product. In both cases, the desired level of
reliability should be part of the definition of the objectives of the project. Maintainability is the mean time to
repair or replace a component, part, subsystem, or system. The end product must be designed to support the
level of maintainability that the end user desires. There is often an interplay between reliability and
maintainability; one drives the other. Many companies trade on the reliability or maintainability of their
products (e.g., the loneliness of the Maytag repairman).

Capability to Survive
This function relates to the capability of the end-of-work product to endure in its environment. Issues like the
range of temperatures and relative humidity in which the product can operate are considered to be part of
survivability. In addition, the ability to transport a computer, handle it roughly, and have it operate well can
be a survivability criterion.

Operability
Is the user able to operate the product? The size of the work crew required to operate the product is part of this
issue, as is the amount of training required for its successful operation. Operability refers to many of the
issues of system or product design that are commonly known as human engineering issues. Operability is one
of the areas of the project technical objectives that tend to be overlooked and can have serious implications
once the product has been delivered to the end user or client.

Manufacturability
Can the project team or the recipient of the design manufacture the product? Manufacturability has an image
of smokestack industries and the fabrication of complex industrial equipment, but it is an issue in other
industries as well. For example, in the area of software development, programmers need to be able to create
the necessary code from the product design. In the construction industry, manufacturability is replaced by
structurability. Regardless of industry type, manufacturability can and should be defined and specified.

Flexibility
Flexibility generally refers to an attempt to produce an end-of-work item that has multiple applications or can
be put to use in a number of areas. Modularity is related to flexibility. Building the end-of-work item from
standard modules or designing it as a complex of standard modules can enable the modules to be used for
other applications in the future, thereby increasing the return on investment for the project.

Regulatory Compliance
Regulatory compliance refers to the international, national, state, and local or municipal regulations with
which the project may have to comply. In addition, project standards may be determined by private
organizations such as Underwriters Laboratories, Inc., and/or the organization performing the project. Even
within an organization, corporate, divisional, and/or departmental standards may exist. All of these sources
comprise the body of regulations with which the project may have to comply.

Materials Use
A project team can often find itself constrained by the organization™s preference for certain types of material.
The Brick and Masonry Institute, for instance, probably would not favor a headquarters facility constructed
with aluminum siding. Related requirements are packaging and product appearance.

Community Relations and Corporate Image
Community relations is particularly important in construction project management, where concern with
disruptions in the neighborhood of the construction is part of the project team™s mandate. Community
relations often becomes an issue in other types of projects as well, such as the installation of communications
equipment that might interfere with television reception or the installation of high-voltage power lines that
could cause environmental damage. Corporate image, a more global concern, can affect the packaging of
products, serve as the basis for the approval or killing of certain projects, or affect materials use.
Project requirements serve as the basis upon which the plan is built. Part of the challenge to project teams is to
make sure that all of the requirements have been identified prior to submitting a project plan. The result will
be a better plan, with fewer errors of omission during the course of the project. The requirements should be
quantified in order to measure the project team™s performance. Let™s take a look at two examples and decide
what is wrong with the way the project requirement is stated:
1. “The new system must be better than anything we have used in the past.” What does better mean?
What is the standard-of-performance criterion that will equate itself to “better” after the project is
complete? Do we have a standard-of-performance criterion for current productivity against which we
can compare future productivity after the system is installed?
2. “You have to understand that this will be the greatest thing since sliced white bread, and our
company cannot survive without it.” This explains the why, not the what. Although it is essential that
the project client and manager understand the why, the what must be defined.
Documenting the answers to these questions in the form of a proposal or business case sets the stage for the
remainder of the project. It requires a concentrated, sustained effort. However, the return on investment for
the time and effort spent will be significant.
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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Conducting Focused Interviews With the Project Client
Title

In order to understand and to document the project requirements and objectives, you as project manager need
to interview the project client to determine what belongs within the scope of the project, what work needs to
be done, when the end product is needed, who needs to be involved, and any additional considerations. Here
-----------
are some questions to ask the project client:
Determining the Client™s Objectives
• What do you really want?
• Is there a specific time when you need it? What circumstances have mandated this time frame?
• What are the exclusions, if any (for example, the new product will not be sold outside the United
States)? What specifications do not have to be included in this project?
• By what standard will you measure the end product?
• How do you see the end product performing?
• What will be the use(s) for the end product?

Creating a Context for the Project
• Why do you want the project done?
• Why now?
• What have you tried before, and what were the results?
• What are the risks?
• What do you foresee as the impact that this product will have in your organization and in the
marketplace?
• Are there any future implications that should be considered in addition to the short-term benefits?
• What will it cost?
• What are the tangible and intangible benefits to be realized?
Preparing the Project Initiation Documentation
Among the topics that may be addressed in the documentation for initiating a project, some are mandatory,
and others are optional. Depending on the size of the project, its visibility, and the requirements of
management or the client, select the segments that provide the best return for the effort expended.
• Problem/opportunity statement (mandatory): What is the problem or opportunity that this project
addresses? This section should provide background on the factors that led to this project and, where
appropriate, some history of what has been attempted in the past.
• Scope definition (mandatory): What are the quantifiable characteristics or end results to be achieved?
The scope definition should respond to the problem or to the opportunity. The end product might be a
specified product, process, or service.
• Completion criteria (mandatory): What needs to be done? How will it be measured in the most
objective terms? How will we know when we™re finished? The completion criteria should indicate
whether it is the design, the prototype, or a complete working product, system, or process that is the
goal. Consequently, this completion criterion or standard of performance needs to be quantifiable. The
objective is to eliminate subjective analysis after the completion of the project.
• Assumptions (optional): What has been assumed? Is everyone aware of these assumptions?
Remember that what you, the project manager, assume will form the basis upon which to build the
project plans. If the other people on the team, particularly the client, have not made the same
assumptions, there will be a major variance in expectations.
• Impact statement and interfaces (optional): Upon whom or what will this project have an impact or
an interface? Most projects do not exist in a vacuum. The creation of their end products may have a
ripple effect within the organization, outside the organization, or both. These impacts may have either a
beneficial or detrimental effect, so they should be documented and evaluated.
• Risk (optional): What are the risks of doing or not doing this project? One variation of risk analysis
can be a detailed mathematical presentation with which to project the financial and other ramifications.
Another variation is to provide a business analysis of the major risks and rewards that provide the basis
for deciding whether it is prudent to proceed with the project.
• Resource requirements (optional): What resources will be required? This section should alert
particular areas of the organization that their staff members will be required to support this project. You
may also want to announce whether you will need any special or unusual resources for the project. Do
not make definitive specifications at this point since you do not have enough information to plan.
Rather, include a generic statement of skill mixes that will be eventually requested.
• Constraints (optional): Are there any special constraints imposed upon the project? These could be
environmental factors such as terrain, weather conditions, or Environmental Protection Agency
requirements. There may be constraints imposed by equipment, technology, or chronological
limitations to be considered. Get them out on the table at the beginning of the project so that you will
have the opportunity to reevaluate and pursue alternative solutions.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 3
Building the Project Team
Building the project team is your primary and most critical task. Your success is based on choosing the right
-----------
team members and obtaining their commitment to the project. In this chapter we describe the typical process
for assembling a project team, explore in detail the ways to build a strong and successful project team, and
discuss the factors that affect a team™s performance during the course of the project.

Assembling the Project Team
Typically, you should begin assembling a project team while developing the work breakdown structure
(WBS) for the project because that is when the skills required to execute the project become apparent. Assess
the ability of your permanently assigned staff to fill the project requirements. If there are required skills that
they do not have, identify other sources of personnel possessing these skills.
Once you have identified these sources, begin your negotiations to assemble the project team. Approach each
supervisor of personnel with the required skills and explain the nature of the project and the assignment. If
you can™t obtain a commitment from the supervisor to support the project, investigate alternative sources or
raise the problem with senior management in order to get assistance in obtaining the required commitment.
Even after the individual in question has been assigned to your team, you may need to conduct subsequent
negotiations with the person™s supervisor. For example, the project might call for the participation of multiple
members of the skill group on the project, or it might require a long-term commitment of a key member of the
group.
The organization™s structure and distribution of authority will affect the nature of these negotiations. In some
cases, you may find it necessary to alter the project™s schedule and budget to accommodate the availability of
the staff you need. In other situations, the skill group manager may find it necessary to alter other priorities to
accommodate the demands of the project. In either case, after the negotiations are completed, the head of the
skill group will be asked to assign specific staff members to accommodate the project plan. Nevertheless, if
you are still unable to obtain specific assignments to the plan from the supervisor, you may have to investigate
alternative sources of the required skill or go to senior management for a decision on the relative priority of
the project versus other components of the skill group™s workload.
There are a variety of objective or technical criteria to use in choosing the team members: perceived technical
ability, estimating proficiency, project management skills, experience as a task leader on other projects, and
attitude toward this project and toward projects in general. Often it is the subjective or personal attributes that
are critical ” for example, prior experience with the subject matter, information from fellow project
managers, or an opinion based on casual contact with the individual offered as a team member. For these and
similar reasons, we suggest that you talk to potential team members before negotiating to have them join the
project. In order to determine the potential effectiveness of prospective team members, you need answers to
the following key questions:
What to Look for in Prospective Team Members
1. Would I want this individual working for me?
2. Would I want this individual as one of my peers?
3. Would I want to work for this individual?

Defining and Documenting Team Member Commitment
In order to obtain commitment from team members, it is important to define and document their contributions
to the team. Two tools can help you here: the skills inventory matrix and the responsibility matrix.

Skills Inventory Matrix
Every project requires a variety of skills that will need to be matched to the appropriate tasks. In the beginning
of the project, it is important that you appropriately match people, skills, and tasks. As the project progresses,
it may be necessary to split assignments, add staff to existing assignments, or trade assignments. In order to
have this flexibility, you need to know which people on the project team possess which skills. In many cases,
you will already have this information.
If you want to codify an inventory of the skills available from your project team, we suggest using or adapting
the skills inventory matrix shown in Figure 3-1. Set up a simple matrix form with the skills or areas of
expertise depicted along the x-axis and the resources (people) along the y-axis. Then place a checkmark in the
box indicating which skill(s) each team member possesses. In this way, you create a useful overview of team
members and skills from which to assign tasks.




Figure 3-1 Skills inventory matrix by area of expertise.

Responsibility Matrix
Now consider who on the project team is most qualified to perform each task. In order to do this, develop a
responsibility matrix (Figure 3-2). This matrix is the documentation of a performance contract among the
project manager, the project team members, and their supervisors. It is an important mechanism for obtaining
individual commitment, or buy-in, and for graphically depicting that responsibility.
To develop the matrix, list the tasks on the left axis and the names or job titles of the project team members
along the top. Then match the tasks to the members by indicating the person with prime responsibility (P) and
those having support responsibility (S). Each task requires one and only one prime; several supporting team
members may be assigned. The team member with prime responsibility is accountable for ensuring that the
task comes in on time, within budget, and at the expected level of quality. Those in a support capacity are
chosen because they have skills needed on that task. Follow these five rules of thumb when preparing a
responsibility matrix:
Preparing a Responsibility Matrix
1. Assign staff because they have the correct skills, not because they have time available.
2. Do not assign too many people to one task.
3. Obtain buy-in from team members: “ask,” don™t “tell.”
4. Consider who is good at what, who wants to do what, who can or cannot work together, and who
likes to create versus maintain.
5. From the perspective of the project, consider what skills are needed, what skills are available, and,
if someone left a task, whether his or her work could be redistributed.

Ideally, as the project manager, you have some exposure to these areas of responsibility. This background ”
coupled with intuition, a bit of psychology, and a bit of luck ” can make the task of assigning responsibility
both challenging and rewarding.




Figure 3-2 Responsibility matrix.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Building a Strong Project Team
Title

A strong team is the nucleus of and can ensure the success of a project. The team members are asked to deal
with specified constraints of time and dollars, sometimes under great stress. As project manager, you need to
give them your technical guidance, your management expertise, plus a significant intangible ” your
-----------
enthusiasm and support. In this section we consider the techniques for developing a strong project team, the
importance of building a team communication plan, and your responsibility to, accountability for, and
authority over the project team.

Techniques for Team Development
We recommend that you consider using five techniques to build a solid foundation for coordinating your
project team™s work efforts.
1. Build a broad-based team. Choose the best people available to play on your team. By best, we don™t
just mean people who bring a diverse set of skills, experience, and personalities to your project; we
mean people who are known to get the job done and are team players. Familiarize yourself with their
strengths and weaknesses, both technical and emotional, by observing and listening and by asking their
boss, other project managers who have worked with them, and others with whom they have worked in
the past about their abilities. Evaluate each person™s comments, but make your own judgment. (Of
course, sometimes we are not given the choice but are told who will be assigned to our projects.)
2. Establish a formal leader. Note the adjectives before the word leader: a and formal. A means
singular. Project team members cannot divide their loyalty and responsibility among different captains.
As project manager, you must be the only person running the project. Formal means that you have been
officially delegated the job of captain with the responsibility and authority that comes with it. Make
sure that everyone on the team understands your role, who assigned you this role, why it is necessary to
have a single point of control, and how you plan to exercise your authority.
3. Build and maintain team spirit. If you become apathetic, your team will become apathetic too. You
don™t have to share negative developments with the team. If it does not affect a team member™s ability
to perform the job successfully, keep the downside to yourself. That is part of your leadership role.
Also, if you are not a rah-rah leader, don™t pretend. You can still impart a sense of professionalism and
urgency without it. However, you might want to find someone on the team to be the cheerleader for you
” the person who sets up the milestone party or the Friday beer bust. Well-timed and -deserved thanks
can go a long way.
4. Elicit management support. In many organizations, project managers are dependent upon personnel
who are not members of their staff for the performance of project tasks. Usually these team members
have been assigned by their managers or supervisors to the project for the duration of it or for the time
required to perform a specific task or group of tasks.
The assignment of these persons to the project presents you with a unique challenge: to obtain a
commitment to the project from the assigned team members, to motivate them to achieve the project
goals in a timely and cost-effective manner, and to influence them to identify with the team and its
objective. To meet this challenge, you need to be skilled in persuasion, motivational techniques,
leadership techniques, and the use of influence in the absence of line authority. Even these skills will
not ensure your success, however. The team member, for example, may be a reluctant participant in the
project, viewing it as an interruption of his or her normal duties.
One means of increasing the probability of success for the project is to convince each team member that
the project is an essential part of his or her job. This convincing must be done by the team members™
supervisor or manager, however, not by you. It is easier to convince the team member of the
importance of the assignment if the person™s supervisor agrees that you will have something to say in
the person™s performance appraisal.
5. Keep team members informed. Nothing is more frustrating to project team members than changing
the game plan without their knowledge. As project manager, you need the respect of the team. You can
build this respect in part by establishing communication channels so that you and the team members
can exchange information in a timely and accurate way.

Building a Team Communication Plan
Some team members need to be aware of the project status more frequently than others; some may need to
provide functional input on a regular basis; and some will have varying needs for information by virtue of
their role on tasks (whether prime or support). As project manager, you need to define your goals for team
communication during the early stage of the team™s formation and determine the forms of communication you
will use with each person on the team: meetings (group and/or individual), telephone calls, written status
reports, electronic mail, or some combination of these.
If you plan to use written communication, define the content, level of detail, and format for the reports. Keep
in mind that your written communication will be most effective if you report to the needs of each audience.
Work this out in advance so you™re sure that you will hit the mark.
If you plan to use meetings, devise a strategy that identifies who will attend, how often meetings will be held
and where, when they will be scheduled, and who will be responsible for agendas, minutes, and other
logistics. Your team meeting plan should be part of your project plan so that everyone involved will know
how and when meetings will take place.
Whether you plan formal or informal communication with your team, consider how often you will be in
touch. Some members will need or request more frequent communication than others. In addition to regularly
scheduled communication, you may plan meetings or reports around key project milestones or other
checkpoints. In general, the following guidelines are useful to your communication plan:
Guidelines for Developing Effective Team Communication
• Involve key members of your project team in developing a communication plan.
• Work with each team member to define how and when your communication will take place and
how you™ll work together to solve problems that might arise on the project.
• Devise a strategy with each team member to help ensure that information does not fall through a
crack and to prevent ruffled feathers that often occur when messages are miscommunicated or
omitted.
• Begin developing your communication plan as soon as you take on a new project, and update it as
needed. Players often change in the project universe. Develop new communication strategies when
this happens. Newcomers or replacement project team members are often left out in the cold and
cannot fully contribute unless you take time to involve them.



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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



There is one key communication skill that you as project manager need to develop and use: listening. The
Title
power of this communication tool cannot be overestimated for it leads to several important outcomes for the
project: increased productivity and quality of work, improved job satisfaction, and a clearer sense of roles and
expectations. Let™s look at the key verbal and nonverbal behaviors for active listening.
Verbal Listening Behaviors
-----------
• Ask questions to clarify or to gather information on the topic. Make your questions more than just
closed-ended ones that require only a yes or no response. Make them probing and constructive. Don™t
be too embarrassed to say, “I didn™t understand you. Would you please say that in another way so that I
can understand.”
• Paraphrase what the speaker has said. In some situations, you and the speaker come from different
parts of the organization and may be using different terminologies. If something is said to you in
unfamiliar jargon, paraphrase the information in words that are meaningful to you.
• Summarize at certain intervals what the speaker has said. Periodically confirm that you have
understood and are on the same wavelength with the speaker by restating (concisely, please) what you
have heard up to this point.
• Ask the speaker for examples. If the statement is not clear, an example or a visual impression of the
subject can help clarify the information. Asking for an analogy (some description similar to the topic at
hand) might lead to shared understanding.
• Ascertain the speaker™s feelings and acknowledge them (for example, “You sound pretty frustrated
by the whole thing”). There are times within the conversation when the speaker just needs to get
something off his or her chest. Regard this discussion as important to the speaker. If it has relevance to
your relationship with the speaker or to the project, deal with it. If the speaker™s feelings are irrelevant
to the topic or to the welfare of the project, explain that you recognize the importance of what is being
said, but the speaker should readdress the issue with a more appropriate listener.
Nonverbal Listening Behaviors
• Make eye contact with the speaker. To some people, eye contact indicates honesty,
straightforwardness, and openness. If you are unwilling to look someone straight in the eye when
talking, you are not creating the attention, connection, or personal bond that is necessary and
meaningful for good communication.
• Be expressive. An alert, interested expression motivates the speaker to be open. If you only appear to
be interested, the speaker will probably sense your lack of enthusiasm.
• Move close to the speaker. The intimacy allows you to establish a more friendly, constructive
communication. We once watched a fine negotiator interact with people whom he knew quite well.
Each time someone made a comment that lended to our friend™s position, he physically shifted his chair
closer to that person™s chair. If someone said something contrary to his position, he shifted his chair
away from the speaker. It soon became a game to see how much someone could say that reflected this
man™s thinking and therefore how close he would move his chair to those in agreement. Later, several
of the people got into the game and started moving their chairs in the same manner.
• Listen for the intent of what the speaker is trying to communicate. The message is not only what the
person is saying but how it is being said. Remember “read between the lines”? We must be willing to
listen between the words.
You get out of listening only what you put into it. Project team members may be telling you something
important. They may be indicating that the project will come in six months late or that the budget is
going to be overrun by 190 percent. In some cases, the message is not obvious. Perhaps they are
expressing frustration in getting part of the job completed, which may be indicative of a global
problem. Your team members need your help.
Listening is probably the best communication skill. Pay attention, don™t interrupt, don™t change the
subject, and don™t take over. Make every person with whom you interact feel that what he or she is
saying is the most important thing in your life at that moment and that it will influence the outcome of
the project. Remember that each communication may have a significant impact on some aspect of your
project. Don™t miss that vital message.
A project team communication plan has many benefits: you™ll have fewer forgotten tasks if you
remember to involve the right people early enough in the project to guide your planning efforts, and
you™re likely to reduce the number of wrenches thrown at the project midstream. Perhaps the strongest
benefits are on the human side of the equation: You™re likely to achieve greater buy-in to the project,
and you may even reduce the impact of difficult people as well.

The Project Manager™s Authority
One of the biggest concerns of most project managers is their high degree of responsibility ” for managing
the project management process and delivering a high-quality end product or service ” coupled with a
limited authority to manage team members and other resources. As a project manager, how can you acquire
authority? Let™s explore the possible answers to this question by distinguishing between informal and formal
authority.
Informal authority flows from any of the following sources:
• Experience/knowledge authority: This refers to knowing more about a specific subject than anyone
else. This authority is tenuous, however; a new contender can be coming up to take this venerable
position.
• Authority by association: This is the power of who you know. But it lasts only as long as the “who
you know” status is intact and the association with this person is perceived as strong.
• Personality-based authority: Well-placed prior favors or accommodations may be returned when
they provide the most results. Team members don™t forget that time when you were flexible on a
deadline or when you made other concessions they needed. Some people call this “calling-in markers.”
We call it the golden rule of doing good business.
• Credibility authority: This type of authority differs from experience, knowledge, and technical
qualifications. It is gained by the manner in which you conduct yourself: being honest, fair, and
responsible to the organization, to the team, and to yourself.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Formal authority comes from any of the following sources:
Title
• Direct line authority: You are the person to whom the people on the team report directly. You may
have hired them and may have the ability to fire, and in all cases you determine their raises, their
promotions, and their future growth within the organization. Most project managers, however, do not
have line authority over their project team members.
-----------
• Job title or position within the organizational hierarchy: Job title and/or position do not in and of
themselves guarantee authority, but they certainly do position one to command the attention of others.
• Pecuniary authority: This is power over the purse strings ” probably the most effective control that
a project manager can have. If you have control over the budget, then you have control over the project.
This is particularly true if you have the option to employ internal staff, recruit new staff, or use outside
contractors. You may also be given the authority to provide financial incentives to your most
productive team members.
• Mandated authority: A senior executive mandates that everyone will cooperate with the project
manager. This delegated power, however, is only as strong as the executive who issues the mandate. It
is also only as strong as the consistent backing that this sponsor provides to the project manager. The
sponsor may give the greatest kick-off speech in the world, but without his or her continued support,
this power erodes very quickly.
• Performance appraisal review authority: With this type of authority, you have input into team
members™ performance appraisals. This power is only as effective as the degree of influence that this
information has on team members™ raises and promotions.
Let™s look more closely at this last type of authority: input to a team member™s performance appraisal review.
Some organizations have an organizational policy that governs the manner in which the project manager
provides performance information to the team member™s manager or supervisor. Some of the essential
elements of this process follow:
How to Provide Performance Feedback
• Project team members should know from the start of an assignment that their manager or supervisor
will obtain and use performance appraisal information from you.
• The assignment must be for a sufficient number of person-hours to warrant invoking the process.
• Your input should be obtained when the performance of the team member is fresh in your mind
rather than at the end of the appraisal period.
• Anything critical you have to say about the performance of the team member should be reviewed
with him or her before the end of the appraisal period.
• The team member™s manager or supervisor should use this information as part of the team
member™s overall performance review.

Attaining and Using Power
Authority, formal and informal, is rarely permanent. It must be constantly earned and re-earned. Rather than
think about the formal authority that you do not have, plan to acquire the power that you need to achieve your
goals.
The word power has two important meanings to you in your role as project manager. First is the rational
meaning: the ability to get things done. In an organization, this usually means the ability to get other people to
do work, especially in service of the organization™s goals. Second is the nonrational meaning: people™s
feelings and emotional needs that relate to being in control. Many people have strong emotional needs to be in
control of others or to avoid being controlled by others. Most of us have strong needs to be recognized,
acknowledged, and respected by others.
Emotional needs are easily stirred up when one person is trying to get another to do something. It is easy for
individuals to start out trying to accomplish a project goal through others and then to get confused between
the organization™s needs and their own emotional need for control or recognition. It™s also easy for the other
person to get confused over the same issues. When this happens, we often refer to the interaction as politics, a
power struggle, or a personality conflict.
One of the reasons it is so easy to get into this sort of struggle is that human needs for control and recognition
are often unconscious, and consequently reactions are unplanned. We don™t need to become amateur
psychologists to be good project managers, but it can be very useful to take a few minutes to identify some
key power needs we are likely to have to deal with as project managers. This can help us later to avoid getting
confused and will also give us bargaining power when we need it. We can gain power through the use of
several strategies.

Influencing
Influencing uses a strategy of shared power. It assumes that both parties have equal power in their own areas
and that no bargaining or pressuring needs to take place. Instead, influencing relies on interpersonal skills to
get others to cooperate for common goals. Influencing others can be accomplished by following two
guidelines:
Requirements for Influencing
1. Build and maintain reliability by being consistent in what you ask for and what you do, following
through on commitments, and being clear abut how a decision will be made.
2. Use a flexible interpersonal style in which you adjust to the person you™re with, especially your
voice tone and nonverbal behaviors.

In the long run, influencing is the most practical strategy for project managers to use. It is low cost and
effective regardless of one™s formal level of authority, and it™s good politics. Sometimes you may feel your
influencing skills aren™t quite up to the task, or perhaps you have used them but the other party isn™t following
through. Then you may wish to move on to the next strategy.

Negotiating
Negotiating uses a strategy of trading for power. It assumes that each person has something the other wants,
and neither will yield it unless compensated. Before negotiating, you have to do some analysis. First,
determine what the other person wants, either through asking outright or possibly doing some shrewd
guesswork. Second, identify what you have (or can get) that others want. Finally, identify your own needs in
the situation. What specifically do you want? What is it worth to you? Do your own personal needs and wants
conflict with the other party™s? Once you have finished analyzing the situation, you™re ready to negotiate with
the other person. The following skills will serve you well in this process:
Key Skills and Behaviors for Negotiating Successfully
• Differentiate between wants and needs ” both theirs and yours.
• Ask high, and offer low ” but don™t be ridiculous.
• When you make a concession, act as if you are yielding something of value; don™t just give in.
• Always make sure both parties feel as if they have won. This is win-win negotiating. Never let the
other party leave feeling as if he or she has been taken.



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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Negotiating is a useful fallback strategy when you™re dealing with a tough customer and feel there™s a high
Title
risk of not getting what you need. Some people make an entire life-style of negotiating and become very good
at it.
If you feel you are facing a situation that is too critical to risk negotiating or if you have negotiated and the
other party isn™t honoring his or her side of the bargain, you may decide to move on to the next strategy.
-----------

Using Coercion
Coercion uses a strategy of power imposition. It assumes that the other person has something you want but
will yield it only under force. It turns to formal organizational lines of authority to issue orders and get
compliance and requires that you know (or find out) answers to the following questions:
• Who “owns” the project? Usually it is the client. If the original client is no longer there and no owner
is apparent, who is answerable to the organization for business results that this project supports?
• Is there anyone else at a high enough level who is championing the project or has become visibly
connected with it? This person™s authority is the lever you will use to get compliance.
• Who has formal authority over the person whose compliance you need?
Your job is easiest if the person whose compliance you need is under the client™s lines of authority. If not, the
client will have to solve the same set of problems you have just been trying to solve: how to get his peer to
exert authority over the person whose compliance you need. It is worth noting that the client will have the
same set of strategies to choose from: influencing, negotiating, and using coercion. An important political
consideration is how far up the owner™s line of authority you want to go to make your request. A general rule
is to go to the lowest level you can and still be reasonably sure of success.
Once you have identified the lever of authority, you still need to persuade him or her to act. In some cases, a
word may be enough, but generally you will need negotiating skills. It is also wise to have standard project
status report documentation, showing where the project is now and the likely consequences if no action is
taken.
Using coercion is generally the least practical and most politically expensive strategy to use. Sometimes it is
necessary to use, but it should be your last resort, not your first move.
Each of the three strategies has been presented in a pure form in order to give a clear explanation. In reality,
they are mixed together according to your personal style and the needs of the situation. The more flexible you
are in using and mixing the strategies, the more powerful you are likely to be in motivating others.

Managing the Team During the Project
As work progresses on a project, several external factors will undoubtedly have an effect on the team™s
performance. In this section, we will discuss four of these factors: poor performers, turnover, adding
resources, and overtime.

Poor Performers
All projects are not blessed with superstars. In fact, many projects are not even blessed with average
performers. Not only are poor performers nonproductive, but they also distract and drag down good
performers around them. How can you get rid of poor performance?
First, find out if the poor performers are competent. Perhaps these people are wrong for the project tasks
assigned; they may perform more effectively if assigned to another task. Then determine whether these people
are aware that they are perceived as poor performers. If they are not, performance feedback and/or counseling
may help them improve their performance. If neither reassignment nor counseling helps, you must remove
poor performers from the project if possible. If that is not politically feasible, then isolate these people so they
cause a minimal amount of negative influence on the rest of the team.

Turnover
Turnover during the project can cause a negative impact on the team. If the project loses a team member and
introduces a replacement, time and effort are necessary to orient that new team member. The effect on the
productivity of the team depends on the point at which the turnover occurred and the role of the person who
has left the team. Turnover that occurs late in the project will have the greatest negative impact. Other team
members are too engrossed at this point to have the time to work with the new team members, who have a
great deal to absorb in order to be productive. In addition, studies indicate that loss of the project manager or
the client will have the greatest effect on the capability of the project team to bring the project in on time and
within budget. Worthy of note is that the secretary or administrative assistant has the greatest impact on the
team after the project manager and the client.
Functional managers or supervisors should be required (other than in emergencies) to give advance notice to
you of their intent to replace a team member so you have the opportunity to evaluate the impact in advance of
the actual transfer. If you take exception to the transfer, raise the issue with the manager or supervisor. If
agreement cannot be reached, you have the option of escalating the issue to an arbitrator or mediator who,
after examining priorities and impacts, will determine the appropriate course of action. This must be done
prior to the transfer; reversal of an implemented decision is often difficult and sometimes impossible.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Not all decisions will favor you. Additionally, the longer and larger the project is, the more likely it is that
Title
transfers will compromise your team™s ability to meet the project targets. You can deal with these roadblocks
by requesting a contingency, set aside to deal with the added cost and lost time of assimilating new team
members throughout the project.
The key issue here is not the relative expertise of the original team member and the replacement; it is the
-----------
commitment, motivation, and the sense of ownership of the plan. Thus, you may take exception to transfers
even when you realize they are more experienced and productive employees than the original team member.
Three guidelines will help you deal with turnover:
1. If you can orchestrate turnover, accomplish it early in the project.
2. If the person being moved is the project manager or client, expect a significant impact.
3. If there is turnover, immediately reevaluate and renegotiate the time and budget required to
complete the project.

Adding Human Resources
Adding people to the team will have an impact on the productivity of the team as a whole. There is a law of
diminishing returns when adding personnel onto the project team: adding one more person may reduce the
time, adding another person may further reduce the time, but somewhere in the progression of adding
additional resources, the time will increase. Frederick Brooks, in his book The Mythical Man-Month, suggests
that this phenomenon occurs because the addition of new personnel requires additional communication
channels that must be established and maintained.1 Brooks puts forth this formula:
1The Mythical Man-Month: Essays on Software Engineering (Reading, Mass.: Addison-Wesley Pub. Co., 1982).




where I is the number of interfaces or communication channels that must be established and E is the number
of elements or people on the project team. For example, if there are ten elements or people on the project
team, forty-five communication channels must be established (Figure 3-3). If you add one more person to the
team, there will now be eleven people on the team and fifty-five required communication channels.
Obviously there is a point beyond which the introduction of additional resources to the project is
nonproductive rather than productive. The number of interactions is significant, and it can have a profound
impact on the total number of person-hours necessary to perform the task. When you plan tasks that have
more than one person assigned to them, take into account the number of potential interactions.

Effect of Overtime
There are two major philosophies concerning overtime: (1) overtime is ineffective, and (2) overtime is
effective only when it is required for short intervals. This latter philosophy suggests that project team
members are willing to rise to the occasion and accept overtime under two conditions: they see the end of the
overtime, and they understand why it is necessary. When overtime becomes a way of life, it is no longer
effective or productive. Here™s an interesting example.
In his book Advanced Project Management, F L Harrison suggests that a person who works 6 days at 12
hours per day (72 person-hours) is approximately 88 percent productive.2 In effect, he would give the project
72 — 88 percent = 63.4 effective effort hours. If, however, this person works 7 days at 12 hours per day (84
person-hours), he would be only 77 percent productive and provide the project with 64.7 effective effort hours
(84 — 77 percent = 64.7). By working an extra 12-hour day, he would provide the project with only an
additional 1.3 hours of effective effort. Whether you agree with these percentages of productivity or not, we
believe that you will agree with the premise: people who work too much consecutive overtime show
diminished productivity.
2Advanced Project Management, 2nd ed. (New York: John Wiley & Sons, 1985).




Figure 3-3 Adding resources to a project.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 4
A Model for Project Planninig
This is the first of two chapters that deal with the development of the project plan. In this chapter, we focus on
-----------
the process of planning and address the general procedures for planning project schedules, resources, dollars,
and work accomplishment. In Chapter 5, we explain in detail the specific tools and techniques necessary for
using these procedures.

The Integrated Project Plan
An integrated project plan is the primary tool for effective coordination of project work. It consists of separate
schedule, cost, human resource, capital asset, and achievement subplans. These subplans are integrated
through the use of a common work breakdown structure. The objectives of the project plan are to:
• Determine and portray the scope of effort required in order to fulfill the project objectives.
• Identify all personnel responsible for performance of work on the project.
• Schedule the required work (tasks) and establish a timetable.
• Indicate the human resources and capital assets necessary for each task.
• Determine the budget for each component of the work task or group of tasks.
This integrated project plan facilitates communication among senior management, the project manager, the
functional managers, the project team, and any contractor(s). The plan is designed to facilitate project
coordination, communication, planning, and control rather than to provide technical direction to the
participants. There are eight key considerations for developing integrated project plans.
How to Develop Integrated Project Plans
1. Involve personnel assigned to the team in planning at the earliest possible moment.
2. Involve team members continuously until the plan is completed and approved.
3. Avoid being too optimistic or too pessimistic in estimating. The desired estimate has a high
probability of realization. Ideally, there should be a 50 percent probability of either being over or
under the estimate.
4. Negotiate work commitments from project team members who work for functional managers
outside your authority.
5. Obtain commitments for all effort (human resources, equipment, and assets required to perform
the work) in the work breakdown structure.
6. Obtain a written commitment to project plans from all parties.
7. Remember that an integrated project plan is a step-by-step process. Each step builds on what has
been accomplished in previous steps. Avoid alterations to the planning sequence since they may
reduce participant commitment to the plan.
8. Understand that the effort required to develop the integrated project plan depends on the project™s
clarity, realism, objectives, size, scope, and complexity; the team™s experience, cooperation, and
enthusiasm; and continuous, visible, and strong support by management for the project management
process.

The act of listing tasks in a schedule or collecting costs in a cost report does not constitute project planning.
Project planning is a disciplined process supporting the coordination and direction of resources such as time,
people, and dollars to achieve product and project parameters established by management. It emphasizes the
process of planning the work required to produce the project™s end product rather than focusing on the
technical aspects necessary to produce the product. You must answer these five essential questions during
project planning:
Essential Questions to Ask During Project Planning
What (technical objectives): The question of what is to be accomplished is addressed through the review of
the technical objectives by the project manager and the team.
How (work breakdown structure): The technical objectives are achieved by developing a work breakdown
structure, which is a checklist of tasks that must be performed.
Who (resource commitment and utilization plan): The issue of who will perform the work is addressed, and
the organizational units responsible for components of the work are incorporated into the work breakdown
structure at the appropriate level of detail.
When (schedule): Further into the planning process, the questions of how long each element of work will
take, when it will be performed, and what resources and assets will be used in its performance are
addressed.
How much (budget): How much will it cost to perform the project?

An integrated project plan contains the data that support the what, how, who, when, and how much of a
project. Several benefits are realized from this integration:
1. Effective communication is encouraged within the team and to the project client and management.
2. A final check is provided for ensuring that the project objectives are attainable with the time and
resources available.
3. An integrated plan establishes the scope and a level of responsibility and authority for all team
members and their respective work efforts.
4. The plan serves as the basis for analyzing, negotiating, and recording scope changes and
commitments of time, personnel, and dollars to the project. In this way, a baseline is formed for
measuring progress, calculating variances, and determining preventive or corrective actions.
5. The plan minimizes the need for narrative reporting. Comparisons of the plan against actual
performance in the form of lists or graphics make reporting more efficient and effective. In this way, it
can provide an audit trail and a documentation of changes that can remind team members and the client
why changes were made during the evolution of the project.
6. It records, in a standard format, critical project data that can be used in planning future projects.
The Five-Step Planning Model
An integrated project plan maximizes the probability of achieving the project objectives through five major
work steps:
The Five-Step Planning Model
1. Define the project.
2. Model the project.
3. Estimate and schedule the project.
4. Balance the plan.
5. Approve and publish the plan.

Step 1: Define the Project
As discussed in Chapter 2, once you have reviewed the objectives and accepted the assignment, you must
follow a sequence of planning steps to ensure that an adequate plan will result. There is some overlap between
the start of planning and the process of developing and approving the project objectives. Early in the planning
process, the project objectives will have been thoroughly reviewed and approved by management. Then a
decision to proceed with plan development will be made.


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
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Acceptance of the assignment by the project manager is generally assumed. Sometimes, however, you may
Title
determine that it is in the best interests of the organization for you to refuse the assignment. You may doubt
that the technical objectives are attainable or believe that the project cannot be accomplished within the
budget and schedule. You should bring these concerns to the attention of management. A project manager™s
refusal to take the assignment commonly causes renegotiation of the objectives rather than rejection of the
----------- project. There may be an alteration of the technical objectives of the assignment, the schedule, or the cost
objectives. If you do not believe that you possess the requisite technical expertise to manage the undertaking,
refusing the assignment is also acceptable. In this case, a more technically strong individual may be assigned
to assist you.
You are well advised to perform a personal review of the adequacy of the specifications and list of applicable
standards for the end product or service. Evaluate whether there have been any external influences or
regulatory changes during the period between the formulation of the objectives and the start of the project that
might necessitate a change in the objectives. As a result of this personal assessment, you can indicate that
there is a satisfactory basis for developing the plan or initiate a process of clarification and modification of the
project objectives. At the conclusion of this effort, the objectives are either modified to address your concerns
or the project is terminated prior to plan development.
As project manager, you will serve as the integrative force throughout the project, and it is your responsibility
to establish and maintain project files that all team members will use during the project. The files should
include all original and revised project plans, all milestone products, relevant studies or research results, the
statement of objectives, status reports, and project correspondence. Upon completion of a project, the files
(often referred to as the project notebook) should be reviewed. After selective disposal of papers that are no
longer relevant, the files should be archived for future project managers to refer to. It is important not to
discard work breakdown structures and networks from old projects since the next assignment might repeat
significant portions.

Step 2: Model the Project
Modeling focuses on developing a simulation of the effort required to achieve the project objectives. The

. 1
( 5)



>>