How to be a

Successful
Project Manager
by Robert D. Bowenkamp
Senior Scientist and Technical Director,
Hughes Aircraft Company, Fullerton,
California, and
Brian H. Kleiner
Professor of Management, California State
University, Fullerton, California

The Birth of Project Management

The concept of Project Management has evolved only since
the early 1950s. Until then, essentially all operational and
development activities were managed within the traditional
functional management hierarchy with management power
and control centred only at the top. In the early 1950s, the
Federal Government in the US undertook several unique,
high-priority major system developments which were
considered essential for completion in as short a time as
possible to support and achieve national goals. The
management of those projects was removed from normal
on-going operations, and the projects were assigned for
almost total control and accountability to small integrated
organisations drawn from various existing functional
organisations. Those first project management organisations
reported, not through the normal bureaucratic chain, but
only to the highest levels of general management, and then
essentially only for monitoring and assistance and not for
decision making or control[1].
The majority of those early projects were successful and
received high visibility within the Federal Government and
within industry because of their strategic importance. A
bandwagon had been set in motion, and many
organisations, both public and private, jumped on to i t thinking a management panacea was at h a n d .
Unfortunately, what was forgotten was that the early
projects were headed and staffed by very senior and
experienced managers who were capable of using or
modifying existing management and control tools to get the
precise information that they needed to do their jobs in a
minimum amount of time. Many projects which followed
failed to have the same critical success exhibited by the early
projects[2].
Senior managers in industry and in the Government rapidly
came to realise that the tools and techniques for success
in project management were not those that were commonly
known by, or taught to, functional or middle level managers,
i.e. those persons who might be designated as project
managers within organisations. Since about 1960, project

IMDS MARCH/APRIL 1987

management, as a distinct discipline, or rather

interdiscipline, has become a fertile field of study and
practice. There is still no "cook-book" approach that will
guarantee success, but there are many tools and techniques
now available specifically to support the project manager
in the "successful" completion of his project[3].

Traditional vs. Project Management

Traditional management concepts and tools have evolved
primarily since early this century through observation of
"mass-production" operations. Much of the work and most
of the tools have evolved from the "scientific management"
thoughts of F.W. Taylor, who, in 1911, published his famous
book which quantified and organised the management
function in industry. Although many other schools of
management thought have subsequently evolved, Taylor's
concepts of organisation charts, job descriptions, principles
of delegation of authority, etc, have been the core precepts
on which organisations have been operated[4]. These
precepts have served well in the administration of on-going
enterprises in which production operations and sales are
controlling factors and in which product change is generally
evolutionary rather than revolutionary.
If the above statements can be accepted as true, it is
important to highlight the key differences between the
environment of traditional management and the
environment of project management before differences in
management concepts and tools can be addressed[5]:

Traditional management focuses on

continuing
operations, while project management focuses on the
one-time revolutionary development of a new product.

Traditional management focuses on a single product

life-cycle
phaseproduction
w h i l e project
management must focus on sequential multiple lifecycle phasesfeasibility, design, production, turnover and start-up, and project termination.

Traditional management of continuing efforts requires

only minimal active co-ordination of interrelated
organisations since the management hierarchy and
the descriptions of jobs provide functional
organisations with specific continuing charters and
decision-making routes. Project management requires
special efforts to co-ordinate many interrelated
organisations whose relationships may change
continually during the life cycle of the project.

Traditional management focuses on a situation where

the tasks of each organisation are generally repetitive
and where very few " n e w " problems can be
expected. Project management requires the
accomplishment of unique tasks by various
organisations or combinations of organisations during
the limited life of the project.

Project Management Concepts and Tools

Project management concepts and tools have evolved in
response to the differences between on-going operations
and the temporary nature of projects. The concepts and
tools of project management have generally evolved from
the heuristically learned and adapted experimental efforts
of project managers who have been involved in the
management of several different projects over time.

Organisationally, many forms have been used for projects

with varying degrees of success. The matrix organisation
is probably the most common organisational form currently
used in organisations that have many projects in progress
at any one time[5](pp.155-91). Briefly, the matrix organisation
structure is composed of a traditional functional hierarchical
organisation, over which a project organisation is
orthogonally laid. The project organisation provides a
separate management structure, consisting of only those
functional organisation elements necessary to complete the
current project tasks. During different phases of a project,
different functional organisation elements with different
project-oriented hierarchical relationships are placed in, or
removed from, the project organisation. The implementation
of a matrix organisation within an enterprise almost
invariably results in a continuing source of trauma for
workers and managers who must be significantly more
flexible in their thought and actions than within a pure
functional organisation[5](pp. 37-57).

The matrix organisation is

probably the most common
organisational form currently
used in organisations. . .

Detailed planning and scheduling in on-going enterprises

has been limited for the most part to continuing factorytype production efforts. Special tools, such as MRP II, have
evolved to allow for the smooth continuous flow of product
to the end users, based on projections of demand. Thus,
manufacturing managers are the primary users of detailed
planning and scheduling tools. Planning and scheduling in
projects is a continuous and vital element not only for the
project manager and his/her staff, but for every functional
manager whose organisation is a part of the project.
The project, as has been stated, is a one-time complex event
involving many functional organisation elements that must
deliver us an end item within very specific cost and schedule
constraints[3](pp. 265-82). Various tools, many highly
mathematical and sophisticated, have been developed to
allow the project manager and the functional managers to
co-ordinate the dates for input and output of information
or intermediate products necessary to complete the project
on schedule, and to define the nature of the inputs
necessary to produce the required outputs. The Programme
Evaluation and Review Technique (PERT) was one of the
more sophisticated concepts developed to support project
scheduling and monitoring[6]. It has been found that the
technique is amenable to original project definition and for
assessing the impacts of significant changes, but that it is
difficult for use as a daily management tool to monitor
accomplishment to plan. Most projects rely on Gantt charts
that reflect organisational work packages extracted from the
overall network plan of the project to monitor short-term and
intermediate team-work efforts[3](pp. 421-57).
Management information systems capable of tracking costs
and performance to functional organisations are common
in the majority of on-going enterprises. Those systems

provide a hierarchy of reports tailored to support the

hierarchy of management in its goal to achieve overall
profitability for the enterprise. Such systems, however, do
not support the needs of a project manager who is trying
to monitor the costs and performance relative only to his
assigned project, or of the project customer who is also only
interested in the performance of the company relative to
the costs and schedule for the product for which he has
contracted. Special management information systems have
been developed for projects which overlay the traditional
management information systems. These systems are
generally based on the concept, unique to projects, of a
work breakdown structure which defines every cost element
that should be a part of the project costs. The specific
requirement for projects to be able to use such a system
is the requirement to define all of the cost elements which
should be attributed to the project at the outset of the
project[1](pp. 174-8). This degree of management expertise
is generally not present in most functional managers and
in very few general managers. It is a capability that must
be developed within those who are to be assigned project
managers. In general, it also demands that project managers
have some technical background in the area of the project
to be able to know what generic elements must be
considered to prepare the final list of cost elements.

Responsibilities of the Project Manager

There is no way that a comprehensive list of the detailed
responsibilities of a project manager could be prepared. The
project manager is generally the direct representative of the
enterprise's top-level general managers and is made
responsible for performing all functions necessary to make
the project successful. Unfortunately, project managers are
rarely senior managers. Although they are given the
responsibility for success of the project, they do not
generally have the positional authority to direct all actions
that might be necessary to ensure the success of the
project. They must depend on charm, persuasion and
personally developed authority to direct actions leading to
the success of their assigned projects. However, it is possible
to list generic responsibilities of project managers since they
tend to parallel those of general managers. The following
list of responsibilities could be attributed to the manager
of almost any project.

Lead the effort to plan thoroughly all aspects of the

project. Project planning is not solely the project
manager's responsibility. He/she must solicit the
active involvement of all of the functional
organisations involved in order to obtain and maintain
a realistic plan that exemplifies the commitments of
the functional organisations for performance[3](pp.
265-82).

Control the organisation of manpower needed by the

project. As stated previously, the manpower needs
change over the project phases, both in the types and
quantities needed and in the hierarchical project
relationships needed. The project manager must
ensure that he has available the right talent, arranged
in the right hierarchy, at all times. He/she must also
keep looking to the future to ensure that the right
personnel will be available and committed by the
functional organisations when needed[3](pp.
265-82).

IMDS MARCH/APRIL 1987

Control the basic technical definition of the project

output. Functional organisations, particularly those in
engineering, continually try to optimise their own
contribution to the project output. In general, this
attitude can only increase the project costs. The
project manager must ensure that technical vs. cost
trade-offs are accomplished to determine those
specific areas of the project where optimisation is
necessary and where it really makes no improvement
in the ultimate performance of the project. In the
words of the Navy Admiral who was responsible for
the development of the digital sonar systems used
today aboard US Navy submarines: "The project
manager must be sufficiently astute to realize that in
most casesbetter is the worst enemy of good
enough. Optimization of every component and
subsystem generally leads to no measurable
performance gains and invariably leads to increased
development time and costs and higher production
costs".
To make these technical trade-off decisions, the
project manager must generally have had some
technical experience in the area of the project. In
those cases where the project manager has not had
technical experience, he/she should have on his/her
personal staff a project technical director who does
have that experience. The project technical director
should generally have broad systems knowledge and
be able to evaluate objectively elemental technical
details in the context of the overall system
requirements, performance and cost.

Lead the people and organisations assigned to the

project at any given point in time. As has already been
stated, the most common form of project organisation
is the matrix organisation and that organisational form
can as easily lead to confusion as to hierarchical
relationships in the project, and trauma for the
participating functional managers. The project
manager must manage conflicts between
organisations and must facilitate overall project
progress by providing co-ordination between
functional organisations. The project manager must
exercise strong positive leadership in order to keep
the many disparate organisations that comprise the
project team moving in a comon direction in a cooperative manner[5](pp. 103-19).
Monitor performance, costs and efficiency of all
elements of the project, and the project as a whole.
The project manager is generally assigned total
responsibility for the project by the general managers
of the enterprise and must act in their role. Again,
where problems are noted, the project manager must
exercise judgement and leadership to determine the
causes of the problems and to facilitate the solutions
to the problems. A common failing that must be
guarded against is the "fixing" of symptoms without
the "solving" of the underlying problems. The project
manager must have the ability to probe and ask
questions so that he/she really knows what the
problems are before he/she attempts to solve them.
Many projects have faltered and project managers
have failed because they spent all their time applying
"band-aids" to small wounds on a project that was
in reality suffering from a traumatic haemorrhage.

IMDS MARCH/APRIL 1987

Complete the project on schedule and within costs.

This is generally the charter given to the project
manager by the general managers of the enterprise.
It is the overall standard by which the performance
of the project manager is evaluated within the
enterprise, and it is the measure by which the general
managers of the enterprise determine where
resources should be assigned or reassigned within
the organisation[1](pp. 275-312).

Attributes of a Successful Project Manager

Based on the preceding paragraphs, it is not difficult to
develop a list of attributes that would assist a project
manager in the "successful" completion of his/her project.
This section will address two distinct views of project
success. First, there is the view internal to the enterprise
performing the project. This is the view of the general
managers of the enterprise used during the performance
of the project and immediately after its completion. It is the
view used to evaluate the in-process performance of the
project manager within the enterprise. In many cases, this
is also the view used by the customer for the project until
shortly after its completion. Second, there is the view of the
customer and the ultimate users of the project some time
after delivery when the project output is in use. The two
views may be significantly different, as will be shown below.

The project m a n a g e r must exercise

strong positive leadership

During the conduct of the project, the project costs and the
progress toward completion are the principal measures of
the project manager's success. The possible attributes
exhibited by the project manager that support those
measures of success are listed below:

Plan the work and work the plan. The project manager
must make planning/monitoring/re-planning a constant
activity not only for him/herself, but for all functional
managers contributing to the performance of the
project. Every manager involved with the project must
be committed to performance to schedules, must have
the flexibility and foresight to see potential problems
in advance, and to have work-arounds for those
problems available for implementation. Without a valid
plan for the project at all times, it can be completed
on schedule only through blind luck.

Be inquisitive and ask the right questions. The project

manager must often play the role of devil's advocate
in dealing with functional organisations. Rarely do
functional managers want to place themselves on
report for their own failings. The project manager
must be able to listen to what is not said and probe
to find problemsnot to place blame, but to facilitate
their solution and to minimise their impact on the
performance of the project's tasks.

Do not manage by exception. The basic premise of

management by exception is that the manager
devotes his/her time to problems and that until
something has become a problem it is not generally
worthy of his/her attention. In projects working to tight
budget and time constraints, management by
exception can easily result in disaster. Project
managers have to devote much of their time to solving
problems, but they must also devote time to finding
developing trends and must be able to identify the
key spots where trends toward problems must not
even be allowed to develop.
Insist that the work be done right the first time. It is
not uncommon for functional organisations to claim
that the pressures of the schedule do not allow for
proper accomplishment initially, but that they can
come back later to do it right. Any project manager
who accepts such a claim deserves the results he/she
will achievegenerally failure. There is no way that
schedule pressures can be alleviated or costs reduced
when an organisation must do much of the same job
twice.
Involve the manufacturing department early in the
project's design phase. If the factory cannot build the
design produced in the project, there is no way that
the project can be completed without re-doing the
design activities. Early manufacturing involvement
facilitates trade-offs that can significantly reduce
m a n u f a c t u r i n g costs w i t h o u t impacting on
performance capabilities.
Know when to shoot the systems and design
engineers and build hardware! As has been stated
previously, good designers are always interested in
optimising their own contribution to the overall design
of the project. Often, however, they are only adding
cost by their efforts. The project manager must make
a conscious decision regarding what is good enough
and must freeze the baseline and build the output
when that decision is made. After that, the only
changes that should be accepted are those that are
necessary to make the output work, not those that
are necessary to make the output work better.
Establish an honest, trustworthy relationship with the
customer. There must be a bond of trust and honesty
between the project manager and the customer. If
there is no such bond, the project manager will be
devoting a portion of his/her valuable time to hiding
things from the customerthings that will probably
become known anyway if the customer is astute.
Frequently, the customer is a valuable tool in the
solution of technical and programmatic problems.
Often, a performance requirement specified by the
customer which is hard to meet by the producer is
in reality not a requirement. Someone developing the
project performance requirements thought it might
be nice to specify a requirement for a parameter that
really has no effect on total system performance. In
such cases, the customer can easily delete the
requirement or modify it when shown that it has no
impact on ultimate system performance.
The project manager's most important tool is the
ability to communicate. Generally, he/she is charged

with total responsibility, but only limited authority. In

such situations, the project manager must rely on
charm, persuasion, perceptions of his/her authority,
etc, to resolve conflicts between multiple,
organisations. The primary areas of conflict are in
regard to schedules, priorities, manpower allocations
and personalities.
During the course of development of the project,
performance against cost, schedule and technical
requirements are the primary measurement standards of the
project manager's success. Once delivered and in use, a
different perception is applied to measure the success of
the project and of the project manager. Two interesting
phenomena have been noted in regard to completed
projects:
(1) a project completed on time, within budget, and with
all technical specifications met can be considered
a failure and
(2) a project not completed on time and not completed
within budget can be considered a glorious success.
A major study of 650 projects for NASA resulted in the
following definition of project success for completed
projects:
If the project output meets the technical performance
specifications and/or mission to be performed, and if there is
a high level of satisfaction concerning the project outcome
among: key people in the parent organization, key people in
the client organization, key people on the project team and key
users or clientele of the project effort, the project is considered
an overall success[7]
Note that perceptions play a very strong role in the definition
stated above. Also note that schedule and cost performance
are not mentioned in the definition above. The study
produced three lists of project management characteristics.
The first list included those items necessary for perceived
success. The second included those items influencing the
perception of failure. Finally, the third list consisted of those
items whose presence correlated with perceived success
and whose absence correlated with perceived failure. The
lists are presented below.
Project management
success:

characteristics

associated

with

frequent feedback from parent organisation;

frequent feedback from client;

judicious use of network planning techniques;

availability of back-up strategies;

organisation structure suited to the project team;

adequate control
change;

project team participation in planning;

project manager
schedules;

project manager commitment to established budget,

and

project manager c o m m i t m e n t
performance goals.

procedures

for

commitment

dealing

to

to

with

established

technical

IMDS MARCH/APRIL 1987