Pergamon

International Journal of Project Management Vol. 14, No. 3, pp. 163-168, 1996
Copyright 1996 Elsevier Science Ltd and IPMA
Printed in Great Britain. All rights reserved
0263-7863/96 $15.00 + 0.00

0263-7863(95)00068-2

Integrated project development

teams: another f a d . . , or a
permanent change
Quentin W Fleming and Joel M Koppeiman
Primavera Systems, Inc., Bala Cynwyd, Pennsylvania, PA 19004, USA

This paper candidly discusses both the positive and the negative aspects of an increasingly
popular approach towards project management called integrated project development teams.
The concept has been around for years and has gone by other names, most notably concurrent
engineering, but at other times it is simply referred to as project teams. The use of teams has
had wide acceptance in the US in both the private and government sectors. The attraction of
the project teams concept is quite straightforward: the distinct possibility of shortening the cycle
time necessary to take a new product idea from its creator to the ultimate consumer, while
maintaining or improving the quality of the final design. Whereas managements often understand the general nature of employing project teams, not all firms are willing to make the
necessary commitments to make them work successfully. There are also certain drawbacks in
the use of teams which not everyone discusses, or quite possibly understands. Copyright 1996
Elsevier Science Ltd and IPMA.
Keywords: project teams, risk, schedules, scope, teams

Unlike Detroit, there's no caste system here. Our people

don't think about which executives they work for, just
which project they are working on.
Rick Lepley, Senior Vice President
Mitsubishi (USA) ~
There is a mild revolution occurring within the established
businesses o f the world, and most particularly in the US.
Evidence o f such changes appears almost daily in magazine
advertisements, in television commercials, and in numerous
articles appearing in various business journals. Some o f the
mightiest industrial giants have joined in this new crusade,
including such notable firms as: Boeing, Chrysler, Corning,
DuPont, Eastman Kodak, Eli Lilly, General Motors,
Hewlett-Packard, Xerox, and so on.
What would motivate an established company to adopt
new, sometimes unorthodox practices so late in their
organizational existence? The consistent response from all
of these firms is their compelling desire to transform new
product ideas into finished consumer products . . . in the
shortest possible time, and without reducing the quality
o f the final product. Think about it: If a company could
somehow shorten the time needed to go from a conceptual
idea to a tangible new product, it could in effect lengthen
the life-span o f their new product. In addition, all profits
on the new products would probably be higher before competition arrived with their new (substitute) products. The
attraction to any company is thus tremendous. Numerous

books have emerged on the subject, all citing essentially the

same benefits to any firm giving the concept consideration:
Perhaps most obvious but least important is that the product's
sales life is extended. If a product is introduced earlier, it
seldom becomes obsolete any sooner. Consequently, for
each month cut from a product's development cycle a
month is added to its sales life, for an extra month of
revenue and profit ...2
Although the popularity o f this concept has increased
dramatically in recent times, the fundamental idea has been
around for a number o f years and has gone by various other
terms. Concurrent engineering, fast-track engineering,
integrated development teams, multi-functional project
teams, parallel engineering, project teams, simultaneous
engineering, work teams, etc., have been used by firms for
years. Two management consultant gurus have provided
us with a definition of teams in their recent book on the
subject:
A team is a small number of people with complementary
skills who are committed to a common purpose, performance
goals and approach, for which they hold themselves mutually
accountable. 3
Whereas the names for teams may vary, there are important
similarities. All teams include the requirement that multiple
163

Integrated project development teams: Q w Fleming and J M Koppelman

functional disciplines join together to work towards a
common objective, as in the development of a new product.
As shown in Figure 1, there are three approaches towards
new product development: the traditional form at the
top, fast-tracking in the center, and the integrated project
development teams at the bottom.
At the top of Figure 1 is the traditional method of new
product development. A new idea for a product is conceived,
and then the developmental process flows from one function
to the next function in a serial fashion. Traditionally, each
function would perform its individual tasks until it was
completed and then would pass the results on to the next
function which would continue work on the product to its
own satisfaction. This sequential functional approach to
new product development resulted in the emergence of a
highly skilled technical workforce. But the completion
of the overall products took an excessive time, as each
individual function would complete its stage in the process
to its own satisfaction before passing on their output to the
next function in the linear sequence. Most of the products
developed in the last half of this century were probably
developed with a sequential or serial process.
In an attempt to shorten the time required to bring a new
product to the market place, selected firms employed another
technique which was called "fast-tracking" or "parallel
paths", which is presented in Figure 1 at the center. Fasttracking resembled the sequential product development
process in that the various functions continued to perform
their individual tasks, independent of each other. But by
management direction, later functions would start their
respective work prior to the final completion of the preceding function. The overlapping of separate functional
tasks did shorten the developmental cycle by shortening the
time subsequent functions had to wait before they started
their tasks. Fast-tracking did work, but it also added
substantial risks to the project. The reason was that the
assumptions which were used to initiate subsequent functional
tasks often changed, or were incorrectly assumed, which
caused re-design, re-work, the scrapping of good parts,
accompanying schedule delays, and quite often added
major costs to the project. Fast-tracking did save time, but
with the addition of substantial re-work costs and risks to
the project.

Traditional Product Development:

(Sequential tasks--function to function)
[engineering ~*1 procurementt~[ fabrication ~*1 assembly

Fast-tracking: (over-lap separate functions...adds risks)

I engineering I
[procurement]

Integrated Project Development Teams:

(parallel step by step tasks)
engineering

engineering

engineering

procurement

f procurement

fabrication

fabrication

fabrication

assembly

assembly

assembly

procurement

Figure 1 The integrated project development team concept

164

The "project teams" method of new product development

is displayed at the bottom of Figure 1. This approach requires
that members of various multi-functional disciplines be
assigned and physically integrated to form a product development team, with all members working in concert
towards a common goal. Teams proceed through the new
product developmental cycle in unison, with all functional
issues considered as each step in the process is taken.
Empirically, the results obtained with the use of integrated
project development teams has provided companies with
three clear benefits: (a) it has shortened the new product
developmental cycle; (b) reduced overall new product
developmental costs, and (c) resulted in a higher quality
product at first release. No wonder the concept has received
wide acceptance among the corporate community.
Certain rules need to be followed in order to employ the
integrated project development team approach effectively.
These requirements are presented in detail in the following
section.

Fundamental rules for integrated project teams

A century ago new product development centered on the
individual "craftsman" approach. One person did everything needed to produce a new article. It was a simple time
and the products were of the highest quality. People took
personal pride in their work, in what they did.
Then industrial products became more complex. Out of
necessity, new product developments evolved into the
efforts of multiple, highly specialized functions, working
towards a common objective of producing a new item.
However, something unfortunate happened as we made the
transition from the individual craftsman to multi-functional
product developments. Whereas the individual craftsman
constituted the ultimate "integrated" project team--where
one person did everything, today multi-functional specialists
perform very narrow and sequential tasks. But with the
evolution of highly skilled functional specialists came
parochial attitudes, and the formation of individual functional territories. The parochial needs of certain factions
has too often become the paramount concern, sometimes
overshadowing the attainment of project goals.
Each individual function did its work to its own satisfaction, then passed their output on to the next function in
the series. Engineers sent their completed work on to
purchasing to buy the articles, or on to the factory to build
the new item. The factory prototypes would be sent back
to the test engineers for proofing, back to design engineers
for final specifications, and so forth. All this sequential
effort took time, and was not without its problems. Whereas
the ultimate products became more sophisticated than might
otherwise have been possible when done by a single craftsman, serial functional developments simply took more time.
Sometimes companies have ended up with their new product
containing three distinct product definitions based on separate
functional perspectives: as "designed", as "purchased",
as "built".
Boundaries and functional partitions set in and instead of
doing the common work in unison, tasks were now being
done strictly in series, a serial approach, one task would
need to be completed before the next task was started. Each
function did its own specialized work, and sent their completed output on to the next function in a sequential fashion.
The approach resulted in the emergence of a highly skilled

Integrated project development teams: Q W Fleming and J M Koppelman

technical workforce. But the overall process took more

time: excessive, expensive, and irreplaceable time.
The excessive length of time it took to develop new
industrial products did not go unnoticed. Tearing down the
imaginary walls that had been created between the various
functions might well aid projects in dramatically shortening
their developmental cycle. The integrated team or concurrent
engineering concept allowed functions to work in unison,
towards some common project objective.
Interestingly, as the project team concept has begun to
yield positive results, we have observed that company
managements often make dissimilar commitments to support
their teams. Whereas some companies have given a full
commitment to the team process, others have given them
minimal support. Displayed in Figure 2 is a continuum of
management's commitment to the project team process:
from full, to limited, to minimal support.
Any management commitment to project teams may well
start with something as simple as who will be given authority
over the use of project funds. Will budget authority be
given to the teams, or will this critical matter be delegated
to the functions. Budget authority is a critical project management tool. Often teams are publicly announced by a
firm, but budget authority continues to reside with the
functions. This is called business is as usual.
There must be a published charter establishing the project
teams, defining the relationship and roles between the
teams and the permanent functions. Teams cannot be expected to operate outside of a written management commitment. It is difficult for any team to function properly in
an organization when all company policies, procedures,
and forms are silent on the subject of teams and their
authority. Project teams, in order to carry out their mission
effectively, need to operate under some type of formal and
published charter, in concert with the other defined and
formally issued company policies and procedures.
Project teams need to have some say in the matter of who
will work on the project. They may not require absolute
authority on hiring and/or removing team members, but
they need to have some influence in personnel matters
based on individual team member performance. Joint
personnel performance reviews, collectively approved by
both the team leader and the permanent functional manager
are often an effective way to balance the needs of teams vs.
functions.
iSSUeS

Full

Budget:

Teams get
budget with
no conditions

Charters:

Formal
Policies &
Procedures

Personnel:

Teams can
hire or remove
personnel

Func,
on. [+.m.c.o.ct
Influence:
on their own

Limited

~*

Minimal

Budget issued,
4 ~ , but earmarked *--~
for the other

*~

Some written
a u t h o r i t y in ~ *
place

I
J

Functions g e t ]
budget with J
no condltionsJ

Nothing
in
writing
]
No ability /
to
|
select people
E

uno, oos ]

must approve

Figure 2 Managemenrs commitment to project development

teams

Finally, teams need to be empowered by both management and the functions with authority to make their own
technical decisions, independent of direct functional interference. If each and every technical decision must flow
through the permanent functional bosses for approval, then
the effectiveness of project teams will be severely restricted,
and the developmental cycle will not be shortened.
In his recent book, management authority Tom Peters 4
devoted considerable attention to the importance and use of
teams, which he calls "project teams". In a section of the
book in which he cautions corporate management Don't Let
Project Teams Become Committees, he listed 13 fundamental
hurdles, rules he feels are necessary for the successful
formation and employment of project teams. Five of his 13
rules would seem to have particular relevance to the project
management process, and to the necessary commitment
by management in order to employ the team process
successfully:
Rule 1 : "Successful project teams are characterized by a
clear goal . . . "
All project teams should work to clearly defined goals.
Such goals need to be developed by multi-functional teams
for presentation and authorization of senior management.
Once approved, project goals need to be monitored by
management according to an agreed set of metrics until the
successful attainment of these goals.
Rule 2 "'Keep team members' destiny in the hands of the
project leader"
Functional management must be prepared to share the
performance evaluation of team members with the teams,
when assessing the performance of those functional members
assigned to the project teams. At a minimum, individual
team members' performance needs to be assessed jointly
by the team leader and the functional departments they
represent. The responsibility for writing the actual reviews
should be given to the team leader, for concurrence by the
function.
Rule 3

"Aim for full-time assignments to the team"

All new product developments approved by management

must have full time " c o r e " members assigned to the team
for the period needed to conclude the project successfully.
These dedicated project core team members will be
supported as required by part-time functional members
throughout the duration of the project.
Rule 4 "Give project team members authority to commit
their functions"
One of the more critical of all commitments: Functional
management must be prepared to empower their chosen
representatives to project teams by providing them with
sufficient authority to act independently of the functional
departments they represent. Independent functional authority
is a key requirement of the teams, and is essential to
shortening the overall developmental cycle. Senior management needs to make this commitment at an early stage to the
teams.
Rule 5 "Allot space so that team members can 'live'
together"
The " c o r e " project team members must be allowed to be
165

Integrated project development teams: Q w Fleming and J M Koppelman

housed together, physically co-located in the same vicinity,
in order for them to function as a cohesive project team.
This requirement cannot be met by simply placing a second
desk in the team area and allowing team members to retain
an office or desk back in their functional areas.
A less than full commitment to the teams approach would
seem to deny the old business school maxim that authority
given should be approximately equal to the responsibility
accepted. More often than not, however, integrated project
development teams have been given full responsibility for
the final product, but lack commensurate authority over the
process. A simple "litmus test" of any firm's management
commitment to project teams might consist of three basic
issues:
do all project team members work the same hours, as you
would expect of a team, or do respective team members
work the same hours as their individual functions?
who is authorized to sign team member's time sheets,
the team leader or the function?
who can authorize a team member's overtime, the team
leader or the function?
Unless these three simple issues can be decided by the
project teams themselves, it is likely that the company has
made a less than full commitment to the integrated project
development team process.

The advantages of teams

The advantages with the employment of integrated project
development teams are considerable. Probably the single
most important benefit is the shortening of the time it will
take to bring a new product from the initial idea to the
finished final product, available to the public. Shortening
the developmental cycle would give a company an advantage
over its competitors. Also of importance, it would result in
an overall cost savings to develop the new product. But
there are other advantages.
The concept of integrated project teams requires a new
spirit of cooperation among traditional functional adversaries.
This is a novel experience in many businesses, where the
players often find delight in their roles of arms-length
antagonists. In many high-technology projects the resulting
mal-functional designs could not be purchased, or could not
be built, without considerable re-design by the last function
in the process. Multi-functional project teams have minimized such functional differences.
Typically most of the project teams employed in industrial
or high-technology projects select as the initial leader a
technical individual: an engineer, a scientist, a manufacturing
specialist, a quality control person, etc. These technical
individuals will be supported by people specifically trained
in the business disciplines, who may well later assume the
role as team leader in subsequent phases of the project. By
holding accountable the technical person at the start of a
project's life-cycle, the quality of the initially released
design appears to be vastly improved.
With the increasingly larger segments of major projects
being purchased, either by subcontract or by teaming/joint
venture partners, the importance of the technical design
being correct first time has never been more important. Late
changes in a procurement specification can be devastating
166

to any project's cost or schedule position. The use of project

teams has improved this process.

The disadvantages of teams

The proponents of project teams are quick to point out the
benefits of their use. Rarely, if ever, do they mention the
disadvantages. But there are certain disadvantages, which
need to be understood.
Membership on a project team requires cooperation from
each member, and respect for other functions represented
on the team. The intent of the team concept is to consider
and to incorporate the requirements of all perspectives as
the design evolves from the beginning of the process to the
end. Late functional requirements must be considered early
in the design effort, in order to allow for their requirements
to be incorporated early in the design cycle.
However, some individuals lack the capacity to work in
a cooperative team environment. Some individuals are loners
by nature. Therefore, the turnover rates are sometimes high
in the early days of teams, as members learn how to work
together, and how to function in a coherent team manner.
Some people just cannot work productively with others.
The use of technical people to head the project teams during
the early phases of projects makes good sense, and is
normally the practice. Sometimes, however, certain of
these technical team leaders are not prepared for management
assignments. Replacement of team leaders is sometimes
necessary when individuals, primarily skilled in technical
matters, are not ready for management assignments.
Another critical but negative issue with teams is that of
early project funding requirements. Rarely do projects have
unlimited funding. Projects often span many years, but
funds are authorized only for the initial fiscal year. The use
of project teams accelerates functional efforts that would
otherwise occur late in the cycle. The shifting of downstream functional tasks by the use of project teams puts
pressure on early project funding. There may well be
overall savings in project costs with the use of teams, but
the early phases of the project will experience higher initial
costs than in a more traditionally planned project. This is
particularly the case when a new project has been bid under
normal (sequential development) assumptions, and then a
late management decision converts it into a project team
effort.
There is also much to be said in favor of the use of
the more traditional matrixed organization. A matrixed
organization allows for perhaps the most efficient utilization
of limited company resources. But in addition, in a matrixed
arrangement the project manager can focus maximum
attention on the three critical issues of: (a) " w h a t " work
will be done, the project scope; (b) " w h e n " the work will
be done, the schedule; and (c) "with what" will tasks be
accomplished, the budget. Functional managers in turn
support the project by deciding the (d) " w h o " will be
assigned to the project, and (e) " h o w " the defined work
will be done. These are not minimal chores performed for
a project by functions in a matrixed environment.
Project teams closely resemble a project type organizational arrangement. The use of teams often requires that
project managers get involved in work they may have found
distasteful such as personnel recruitment, the coaching of
personnel, employee performance reviews, removing and
replacing team members and an assortment of various other

Integrated project development teams: Q W Fleming and J M Koppelman

personnel activities, typically done for them by the functions.
Project teams, if taken to their extreme, could eliminate
the "home bases" for project members. Projects start, they
phase up, and then they close down. At the point of phase
down if employees do not have a home base to return to
after the project is over, the adverse impact on individual
team member morale can be considerable. Many of the
proponents of the use of project teams have conveniently
ignored the "human relations" issues in project management. The responsibility for providing continuous longterm work for all team members is a factor which must be
considered when deciding on whether or not to employ
project teams.
Finally, project teams, if used over an extended period by
any given company, may well diminish the technical
expertise, the knowledge base of the parent organization.
Functional organizations provide a way for a company to
develop technical competence bases, which keeps them in
business over the longer-term. The over-extended swing to
project teams could well impair the cross-fertilization of
technical competence which comes from having a strong
functional organization.

The project management process will be changed

with the employment of project teams
Whether we like the concept or not, the increased popularity
and use of multi-functional project development teams will
probably result in changes to the project management
process. Whereas many aspects of project management will
be impacted, we will discuss two of the more important:
scope management and time management.
Impact on scope management
One of the most challenging issues confronting any project
manager is the one which deals with scope definition. What
constitutes the work of the project, and conversely, what
work is beyond the project, i.e. out of scope work, is a
critical issue for any project manager.
The integrated project development team concept will
have a positive impact for scope management by providing
the project manager with a work breakdown structure
(WBS) which is more relevant, more palatable to all of the
key project functions.
Three decades ago the WBS emerged as a tool to help the
project manager define the work and tasks to be done.
The WBS is to the project manager essentially what the
organization chart is to the corporate executive: a tool to
describe what project tasks will be done, and who will be
responsible for each part of the work.
However, the issue of work definition did not end with
the emergence and adoption of the WBS. Whereas perhaps
most project managers today use the WBS, not all of the
critical functions have warmly embraced the concept.
The estimating function is a critical one for any project.
But the estimating function's acceptance of WBS has been
less than enthusiastic. There are valid reasons why they
take this position. Most of the historical data used by the
estimators have been stored in formats other than by WBS:
by function, by commodity, or other categories. To regroup completed projects and actual data by WBS would be
a major effort.
Another vital function to project management is that of
scheduling. But the scheduling people also have shown

resistance to preparing their plans and schedules within the

confines of the project WBS. Many schedulers do not feel
that their efforts are improved with the use of the WBS.
Thus two or more of the most critical functions to the
success of projects often operate outside the framework of
the project WBS, which is the vehicle intended to define the
total project, and to integrate multiple functions.
The use of a project team's orientated WBS will not
automatically eliminate this functional dichotomy . . . but it
will help. A project WBS which has its orientation based on
project teams appears to be a more natural subdivision of
the project work. Based on early experience with the
employment of integrated project teams, the organization
of project work around project teams appears to be more
palatable to all traditional functions, including those of both
estimating and scheduling.
The WBS under an integrated project team approach
essentially constitutes a division of the overall project into
sub-projects, representing a natural flow of tasks towards a
common set of objectives. Thus the estimating function's
historical data files are relatable to the WBS. Likewise, the
scheduling specialists are able to develop their networks
into cohesive work units, which in turn roll up to a master
project network.
Impact on time (and risk) management
The use of integrated project development teams and its
resulting pressures on early funding will require the identification of and the management of critical path method
"float". The float position for all tasks will need to be
determined, and then carefully managed by the project
manager in order to minimize the adverse impact on early
project funding.
The employment of project teams has the effect of
moving selected (downstream) project work to the left on
a schedule. This increases risks because the later functional
tasks have traditionally been performed in a sequence only
after the earlier functional tasks have been completed,
reducing the number of unknowns and uncertainties. In
order to relieve some of the pressures for early funding, it
becomes necessary for the project managers to use their
"schedule float" in a manner not normally done on most
projects.
Each of the project tasks must be assessed as to its
criticality, and the inherent risks of performance weighed
against achieving project goals. If a given task has total
float available, and does not carry undue risks in its
performance, then the project manager will have to use the
available float to move such tasks to the extreme right of the
schedule. Most of the low-risk tasks will need to be shifted
to the right towards their late start dates, in order to stay
within the confines of overall project funding.
To stay within funding constraints, the project teams will
need to manage the task float to a greater extent than in a
traditional (sequential) project development cycle. Frankly,
this constitutes a positive step because it forces an assessment of risks, the employment of mitigation strategies and
contingency plans early, before the project begins.

In conclusion
The benefits from the use of project teams are tremendous,
and are illustrated in Figure 3, which displayed the life
cycle of a typical project.
167

Integrated p r o j e c t d e v e l o p m e n t teams: Q W F l e m i n g a n d J M K o p p e l m a n

Life Cycle of a Project

(3) Lower
Project
Costs

Project Dollars
100%

}J

,=," T

80%

(2) Shortened
Cycle Time

60%

40%
m

(1) Early investment

~ ~

20%

0%

A M

M A

M J

Figure 3 Impact of integrated project development teams

When using project teams there will be pressures on
increased early project funding as downstream tasks are
moved to the left. However, the impact can be minimized
by the judicious management of the schedule float. Those
tasks which have a positive float, and are considered to be
low risks to the project will need to be moved to their
extreme right on the master schedule, in order not to exceed
funding limitations. There is no point investing in early
routine tasks when the project faces funding pressures.
With the use of project teams a shortened developmental
cycle is a distinct possibility. The results of companies
using teams have indicated that they not only cut down on
the required time to produce their products, but maximum
product quality is incorporated into the technical design,
the first time through. No wonder the results indicate an
overall reduction in total project costs.
However, in order to reach their full potential, the project
teams must be supported and empowered by management
to act on their own. They must be allowed to make technical
decisions . . . independent of functional management.
In practice, senior company management has been slow
to relinquish management authority to the teams, and the
functions have been even less prepared to give up any of
their influence over technical decision making. Therefore,
all too often we find project teams being formed with full
responsibility for the project, but with something less than
commensurate authority. Hence project teams are frequently
achieving less than their full potential.
Nevertheless, the concept of integrated project development teams is an exciting one and when properly
implemented will deliver real payoffs to the project.

References
1 New York Times (March 3, 1992) in Tom Peters book, Liberation
Management, Alfred A. Knopf Inc., New York (1992) 159
2 Preston G Smith and Donald G Reinertsen Developing Products in
Half the 7~me Van Nostrand Reinhold, New York (1991) 3

168

3 Jon R Katzenbach and Douglas K Smith The Wisdom of Teams

Harvard Business School Press, Boston (1993) 45
4 Tom Peters Liberation Management Alfred A. Knopf Inc., New York
(1992) 208
Quentin w Fleming has had over
three decades o f industrial experience. He was with the Northrop
Corporation from 1968 until his
retirement in 1991 where he held
various domestic and overseas
management assignments. He served
on a CEO directed "earned value"
corporate review team in 1989-90,
and subsequently wrote the corporate
policy directive on scheduling. On a
leave of absence he accepted an
appointment with the US Government.
He and his family moved to Tehran,
Iran, where he was appointed as the
seventh and the last Peace Corps Director in that country. Concurrently, he also directed the Peace Corps programme in Bahrain.
Recently, he developed and instructed a new course for the University
of California, lrvine entitled: "Earned Value Applications", as part
of their new project management certificate programme. He has
instructed the scope, time and cost management modules for the
project management professional examinations for his local Project
Management Institute chapter in Orange County, California. He holds
a bachelors and masters degree in management, and is the author of
six published project management textbooks. In July 1993, he became
senior staff consultant to Primavera Systems Inc.

Joel M Koppelman is co-founder, coowner, and president of Primavera

Systems Inc., the leading developer
of project management software and
the fortieth largest PC-based software company. Mr Koppelman is a
registered professional engineer who
has spent more than a decade in the
planning, managing and controlling
of capital projects in the transportation
industry. He earned a bachelor's
degree in civil engineering from
Drexel University, and an MBA from
the Wharton School of the University
of Pennsylvania. Before forming
Primavera, Mr Koppelman was a vice president at Day and Zimmermann
Inc., the large engineering-construction firm headquartered in
Philadelphia, where he was responsible for financial consulting assignments. One of his assignments was building the initial management
control system for the design and construction of the 18-mile Metro
Rail Project in Los Angeles. Earlier he operated his own consulting
firm where one of his principal engagements involved managing
alternatives analysis, feasibility studies and environmental impact
statements for the $300 million replacement o f the Frankford elevated
transit line in Philadelphia. Before that he was with Booz, Allen and
Hamilton for five years as a senior consultant responsible for projects, .
including the valuation of the nine major railroads that became
Conrail and for the financial restructuring on behalf of the unsecured
creditors o f the ITEL Corporation. Mr Koppelman is a member o f
several professional societies, has delivered papers for AACE, APTA,
ASCE, CMAA, CFMA, PMA, PMI and is a guest lecturer at several
universities.