ARTICLE IN PRESS
Int. J. Production Economics 107 (2007) 179–189
www.elsevier.com/locate/ijpe
A DFX and concurrent engineering model for the establishment
of a new department in a university
Ching-Chow Yanga, Shun-Hsing Chena,b,, Jiun-Yan Shiaua
a
Department of Industrial Engineering, Chung-Yuan University, Taiwan, ROC
Department of Industrial Engineering and Management, Chin-Min Institute of Technology, Taiwan, ROC
b
Received 11 July 2005; accepted 29 August 2006
Available online 1 November 2006
Abstract
The natural focus of concurrent engineering (CE) and design for X (DFX), as commonly used by manufacturing
industry, is on product design or new service development. The present study applies the DFX technique in a CE
environment to the planning and design of a new department in a university, and thus develops a comprehensive model for
such an undertaking. The model identifies two stages in the overall process: the planning stage and the design stage. The
planning stage includes four dimensions, whereas the design stage includes 11 dimensions. The dimensions are
interdependent; indeed, the dimensions cannot be implemented separately and sequentially. The model must be
implemented in a CE environment. A case study is then presented in which a department of leisure management at a
university is established using the model described. The implications of the case study and the final conclusions of the paper
are then presented.
r 2006 Elsevier B.V. All rights reserved.
Keywords: Concurrent engineering (CE); Design for X (DFX); New service development (NSD); University
1. Introduction
The twenty-first century is the era of the
globalized knowledge economy for a wide range of
business activities, including university education.
As the educational market has become liberalized,
Taiwan has recently introduced reforms in educational policy. These reforms have been especially
marked since the entry of Taiwan to the World
Corresponding author. Department of Industrial Engineering
and Management, Chin-Min Institute of Technology, 110 HsuehFu Road, Tou-Fen, Miao-Li 35145, Taiwan, ROC.
Tel.: +886 3 7605723; fax: +886 3 7605724.
E-mail address: k872790@yahoo.com.tw (S.-H. Chen).
Trade Organization (WTO). The rapid growth in
university education has changed the nature of the
Taiwanese educational sector from its original
model of elite education to one of mass education
and, subsequently, to a system of universal education (Ministry of Education Statistical Department,
2004). However, these changes have created imbalances between supply and demand in university
education, leading to a reduction in educational
quality. As international competition in educational
services has become more intense, many countries
have invested enthusiastically in university education in an effort to maintain their international
competitiveness. Taiwan is no exception. To adapt
to the strong competition that has accompanied
0925-5273/$ - see front matter r 2006 Elsevier B.V. All rights reserved.
doi:10.1016/j.ijpe.2006.08.009
ARTICLE IN PRESS
180
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
membership of the WTO, Taiwan must immediately
improve the quality of its university education
(Chen and Ho, 2003).
The provision of education is a service industry
characterized by a high degree of interpersonal
contact (Chase, 1978; Katouzian, 1970); therefore,
any exploration of the management of the education
system must begin with a consideration of its
service-industry attributes. However, despite the
importance of the service sector, empirical research
on new service development (NSD) is still sparse
(Bullinger et al., 2003), and the studies that have
focused on NSD (Alam and Perry, 2002; De
Brentani, 1995) have largely neglected its application in the educational sector. This relative lack of
attention is both surprising and a matter for concern
specially in view of the fact that service design in
education has been identified as a crucial factor
determining educational quality (Oplatka, 2004). In
particular, when planning and designing new
departments in universities, few suitable models
are available for reference in designing integrated
models that are appropriate to practical requirements (Bullinger et al., 2003).
Universities must take care in planning new
departments and satisfying their customers. Kanji
and Tambi (1999) have noted that university
customers include students, staff, parents, businesses, and government. To meet the demands of
these customers in a competitive market, universities must promote themselves as offering highquality education. In pursuit of this objective,
unsatisfactory departments are frequently dissolved
to allow new departments to introduce novel
curricula, advanced technologies, first-class teaching, and improved service quality. This encourages
able students to enroll and enables the university to
provide graduates who meet modern recruitment
criteria. This process of renewal and improvement is
important to universities in the modern competitive
environment. If planning and resources are insufficient, the process will fail to deliver satisfactory
outcomes, thus leading to a lack of student
enrollment and, ultimately, to adverse affects on
the reputation and financial success of the university.
In the services sector in general, many servicedesign methods are available; however, these have
seldom been used in the design and development of
the education sector. Many studies have reported on
the implementation of such methods as quality
function deployment (QFD) and concurrent engi-
neering (CE) in manufacturing industries and in
NSD in general (Han et al., 2004; Stehn and
Bergström, 2002; Kumar and Midha, 2001; Koufteros and Marcoulides, 2006). However, QFD is
more complicated and less convenient than ‘design
for X’ (DFX) (Hsiao, 2002). DFX emphasizes the
consideration of all design goals and related
constraints in the early design stage (Kuo et al.,
2001) and allows the rationalization of services,
associated processes, and systems (Huang and Mak,
1997). Effective utilization of DFX and CE in NSD
can concurrently improve quality, costs, and cycle
times (Dowlatshahi, 2001a, b; Huang and Mak,
1997). Against this background, the present study
applies the DFX technique in a CE environment to
the problem of establishing a new department in a
university.
2. Literature review
2.1. CE
Prasad (1996) defined CE in the following terms:
‘‘concurrent engineering is a systematic approach to
the integrated, concurrent design of products and
their related process, including manufacture and
support’’. In manufacturing, CE is predominantly
used in product design (Dowlatshahi, 1996, 1997),
and product life-cycle (Dowlatshahi, 2001a). The
advantages of the use of CE are (Dowlatshahi, 1992,
1997):
reduction in product development cycle time;
avoidance of costly future redesigns;
reduction in duplication of effort;
better communication and dialogue;
more efficient operations and higher productivity;
overall cost savings;
elimination or reduction of product recalls;
lower maintenance costs;
more reliable products;
better customer satisfaction; and
improved bottom line.
CE impinges on several factors in the establishment of new department in a university including
customers’ demands, competitive advantage, market attractiveness, financial resources, and the
quality of execution of the whole process of
establishing a new department. To consolidate these
dimensions, it is therefore important that a new
ARTICLE IN PRESS
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
department be designed in a CE environment. With
scrupulous planning and design, the new department will not consume valuable resources unnecessarily, and will simultaneously meet the demands of
customers.
181
(Dowlatshahi, 1997, 2000); logistics (Dowlatshahi,
1996, 1999); product life-cycle (Dowlatshahi,
2001a); and product safety and reliability (Dowlatshahi, 2001b). As Dowlatshahi (1992) has demonstrated, all aspects of DFX are integrated and can
proceed simultaneously (see Fig. 1).
2.2. DFX
2.3. New service development (NSD)
DFX was developed in the late 1970s (Kuo et al.,
2001). Since the late 1990s, hundreds of papers have
been published pertaining to the DFX applications
in manufacturing (Rosairo and Knight, 1989; Kuo
et al., 2001) and it is widely used in the development
of new products (Huang and Mak, 1997; Kuo et al.,
2001). DFX is a general term; ‘X’ can represent
assembling, manufacturing, quality, and so on. The
exact nature of the variable ‘X’ in any instance
defines the focus of a DFX tool. ‘X’ has two parts
X ¼ x+bility. The suffix ‘-bility’ corresponds to the
performance matrices (Huang and Mak, 1997). The
‘x’ part represents one or more business processes
corresponding to one or more life cycles in product
development (Huang and Mak, 1997). However,
there have been few studies in the literature on the
application of DFX in the design of a new
department in a university.
DFX emphasizes consideration of all design goals
and related constraints in the early design stage
(Kuo et al., 2001). As such, DFX represents a suite
of contemporary service-development techniques
that can effectively be applied in service development to achieve concurrent improvement in quality,
cost, and time to market. The technique allows the
rationalization of services, associated processes, and
systems (Huang and Mak, 1997). DFX has been
applied in: purchasing (Dowlatshahi, 1992); product design in a designer–buyer–supplier interface
Design for
Marketability
Design for
Procurability
Design for Cost
Design for
Schedulability
The ability of a service organization to remain
competitive in today’s technologically dynamic and
market-driven environment is largely dependent
upon the quality, cost, and timing of new service
offerings (De Brentani, 1995; Dowlatshahi, 1997). A
service organization needs to provide new services
of high quality at low cost at the right time for
customers. Many quality problems are recurrent
and, to a great extent, these result from shortcomings in the development of new services
(Edvardsson, 1992; Juran, 1992). In recent decades,
manufacturing industries have developed many
models, methods, and tools for the development of
quality new products such as the spiral model
(Bullinger et al., 2003), QFD, CE, business process
re-engineering (BPR), and DFX. However, few of
these are used in the design and development of
service organizations (Bullinger et al., 2003), including those in the educational sector (Friel, 2000).
Effective utilization of CE and DFX to new
service design and development will result in
concurrent improvement in production innovation,
quality, costs, and cycle times (Dowlatshahi, 2001a;
Huang and Mak, 1997; Koufteros et al., 2001; Pillai
et al., 2002). The core of the NSD process cycle is
the ‘service concept’—which involves the service
system, technology, people, tools, and the organizational context.
Process Design
Design for
Reliability and
Maintainability
Production
Design
Design for
Manufacturing
planning and
Control
Design for
Safety and
Liability
Design for
Qualit
Design for
Logistic and
Environment
Fig. 1. DFX in the CE environment framework (Source: Dowlatshahi, 1992).
ARTICLE IN PRESS
182
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
3. Model for establishment of a new department in a
university
New service design and development involves the
following steps (Alam and Perry, 2002; Edvardsson,
1997; Johnson et al., 2000; Murdick et al., 1990):
concept creation;
planning and analysis;
design;
testing and pilot run; and
performance measurement.
The present study applies the NSD concept in
developing a model for the establishment of a new
department in a university. The model integrates the
above steps into two stages: planning and design.
These two stages are discussed further below.
3.1. Planning stage
To best meet consumers’ requirements of a
product (service) from a design perspective, the
physical elements of the product (service) requirements being linked to consumers’ perception of the
product (Aitken et al., 2003; Lai et al., 2006.).
Therefore, the planning stage consists of four
dimensions (see Fig. 2):
confirmation of customer requirements;
analysis of competition;
strategic decisions; and
Confirmed customer
requirements
Confirmed new
department vision
and mission
Planning stage
Competition analysis
Strategic decisions
Design of evaluation
system
Design of student
recruitment
Design of
marketability
planning
Design of
administration
support
Design of space
planning
Design of financial
planning
Design stage
Design of teacher
employment
Design of education
quality
Design of physical/
technical facilities
Design of teaching/
service process
Design of
curriculum planning
Fig. 2. Framework of university’ new department with the DFX in the CE environment.
ARTICLE IN PRESS
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
confirmation of new department’s vision and
mission.
Each of these is discussed below.
3.1.1. Confirmation of customer requirements
The most important customers of educational
organizations are students and staff (Kanji and
Tambi, 1999), and this stage ensures that the target
customers are recognized. Customer interviews,
customer surveys, and focus group methods are
used to ascertain and confirm customer demands.
3.1.2. Analysis of competition
As noted above, competition among universities
is becoming increasingly fierce. Strength, weakness,
opportunity, threat (SWOT) analysis is therefore
applied to analyze the university operations. The
analysis reveals resources and competitiveness in
relation to other institutions in terms of demographics, economic environment, political and legal
environment, sociocultural environment, technological environment, and global environment. The
purpose of this analysis is to allow the university to
make use of its strengths, modify any weaknesses,
master the available opportunities, and exclude any
threats (Yang, 2004).
3.1.3. Strategic decisions
The analysis of the competition (above) allows
the university to determine the departments that
should be established to meet customer demand. By
adopting an appropriate strategy, organizations can
avoid potential problems and risks (David, 2001),
and thus achieve competitive advantage. In contrast, incorrect decisions can cause inefficiencies and
cost increases ultimately eroding organizational
competitiveness (De kluyver, 2000; Quinn, 1980).
3.1.4. Confirmation of new department’s vision and
mission
The new department requires an appropriate
mission and vision to promote the reputation of
the university, and to enhance cooperation and
teamwork among staff and students. An organizational mission is a statement of the reason for the
existence of that organization (Kaplan and Norton,
2001; Niven, 2002), whereas a vision provides a
blueprint that points to the future development of
the organization (Kaplan and Norton, 2001; Niven,
2002). Such a vision is usually expected to establish
183
a framework of teamwork, resources, and support
structures.
3.2. Design stage
In investigating the design stage, the present study
used interviews and/or a questionnaire survey
administered to 92 administrative executives or
deans of several universities in Taiwan. The questionnaire used Likert-style scales from 1 to 7 to
measure responses (with 1 representing very unimportant to 7 representing very important). The
original questionnaire developed for the study
included 14 dimensions that received very low
scores (mean value o6). These were eliminated
from the final questionnaire, which contained 11
dimensions. The study then explored the parallel,
and interactive relationships among these dimensions. The objective was to reorganize each practice
in terms of the principles of DFX, and then to
propose an integrated model of a new department in
a CE environment.
As a result of the above empirical evidence and
analysis, the dimensions can be summarized as
follows (see Fig. 2):
design
design
design
design
design
design
design
design
design
design
design
of
of
of
of
of
of
of
of
of
of
of
student recruitment;
financial planning;
marketability planning;
teacher employment;
education quality;
curriculum planning;
teaching/service process;
physical/technical facilities;
space planning;
administration support; and
evaluation system.
Each of these is discussed below.
3.2.1. Design of student recruitment
Students are the key customers of a school (Kanji
and Tambi, 1999), and student tuition fees dominate
the financial income of a university. This aspect of
the design includes entry standards, enrollment
requirements, class sizes, and student numbers.
Class sizes and the number of students in a
department should be approbated by the Ministry
of Education (MOE) of Taiwan, and so must be
planned in advance.
ARTICLE IN PRESS
184
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
3.2.2. Design of financial planning
Universities must have adequate financial resources such that its departments can implement
the institution’s mission and vision. This aspect of
the design includes the cost of libraries and facilities,
staff salaries, and personnel expenses.
3.2.3. Design of marketability planning
This dimension includes the design of marketing
methods, marketing expenses, marketing the implementation unit, and the arrangement of personnel.
3.2.4. Design of teacher employment
This dimension includes the deployment of
teachers, ensuring teaching skills, determining teacher numbers, and deciding teachers’ salaries.
3.2.5. Design of education quality
This dimension includes determining teacher/
student ratios, deciding teaching hours, implementing plans for teaching improvement, and arrangements for education quality assessment.
3.2.6. Design of curriculum planning
This dimension includes curriculum development,
designing overall credits (including compulsory and
optional subjects), and curriculum planning and
evaluation.
3.2.7. Design of teaching/service process
This dimension includes the standardization and
simplification of teaching procedures, the determination of customer requirements and expectations,
establishing the service level and quality standards
specifications, and designing a monitoring-andcontrol system for teaching/service process quality.
3.2.8. Design of physical/technical facilities
This dimension includes the design of a friendly
environment, facility layout, interior decoration,
flow of people, and design of physical surroundings.
3.2.9. Design of space planning
This dimension includes the design of space for
classrooms, learning, libraries, and facilities, and the
allocation of research rooms for use by teachers.
3.2.10. Design of administration support
This dimension includes the design of an administrative framework, the framing of teacher and
student satisfaction surveys, and planning of administration facilities.
3.2.11. Design of evaluation system
This dimension includes the design of performance-measurement systems and performance-measurement indicators.
If these dimensions are carefully planed and
designed, erroneous planning and investment decisions will be avoided.
3.3. Summary of planning and design stages
As shown in Fig. 2, a carefully considered planning
stage supports the design stage. The dimensions of
each are interdependent and cannot be implemented
separately or sequentially. Indeed, if attempts are
made to implement the dimensions separately or
sequentially, a lack of communication will lead to
confusion and wasted effort (Anumba et al., 2002).
In a properly organized CE implementation, each
department offers its suggestions thus providing the
best framework in which to undertake group
decision-making. It is apparent that the model must
be implemented in a CE environment, and that the
DFX and CE aspects must be fully integrated.
4. Case study
Ming-Hsin University of Science and Technology
(MHUST) is a private university situated in northern Taiwan. The university was founded in 1966,
and now has 17 faculty departments, 9 research
centers, 17,000 students, and 588 staff members.
The present paper took MHUST as an empirical
case study to exemplify the successful implementation of the theoretical model described above. The
case study presents the establishment, in 2001, of a
new teaching department in leisure management
within MHUST.
4.1. Implementation of planning stage
It will be recalled (see Section 3.1) that the
planning stage of the model consists of the following
steps:
confirmation of customer requirements;
analysis of competition;
strategic decisions; and
confirmation of new department’s vision and
mission.
ARTICLE IN PRESS
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
The implementation of these steps in the case
study is described below.
4.1.1. Confirmation of customer requirements
Taiwan has beautiful scenery and the Taiwanese
government is promoting tourism. However, many
health clubs and amusement parks lack high-level
managerial talent. Many people are employed in the
leisure industry, but there is a scarcity of universities
offering appropriate education in leisure management. MHUST assessed this situation and decided,
in view of government policy and the demands of
students and enterprises, that a new integrated
teaching department should be established in the
field of leisure management.
4.1.2. Analysis of competition and strategic decisions
In this case study, the second and third steps in
planning competition analysis and strategic decision-making are considered simultaneously.
MHUST undertook an internal and external
environmental analysis and established that only
two Taiwanese universities had departments of
leisure management (DLM). It was therefore felt
that establishing a DLM at MHUST had enormous
potential in terms of attracting students.
Furthermore, it was noted that MHUST is
located near the Hsinchu Science Park. This means
that the region surrounding the university has a
high concentration of well-paid professional employees who work under significant pressure. These
people and their families require suitable leisure
activities, and it was therefore considered worthwhile to support the development of a local leisure
industry by setting up a DLM in the local area.
4.1.3. Confirmation of new department’s vision and
mission
The MHUST defined the mission and vision of
the new department as described below. The
mission of the new department was defined as:
To train polite and well-presented service personnel who: (i) are concerned about society; (ii) have
humanistic attitudes; (iii) possess the ability to think
independently; and (iv) are able to combine the
theory and practice of leisure business.
The vision of the new department was defined as:
To develop a leisure operation
with Taiwanese characteristics
pottery art, tea art) and local
resources (for example, forest
in accordance
(for example,
environmental
and coast) to
185
popularize healthy and meaningful leisure activities.
To promote the ability of students to obtain
employment by establishing multi-dimensional
and diversified leisure operations as the core
curriculum of the new DLM and management
and planning as the supplementary curriculum of
the new DLM.
4.2. Implementation of design stage
It will be recalled (see Section 3.2) that the design
stage of the model consists of the following steps:
design
design
design
design
design
design
design
design
design
design
design
of
of
of
of
of
of
of
of
of
of
of
student recruitment;
financial planning;
marketability planning;
teacher employment;
education quality;
curriculum planning;
teaching/service process;
physical/technical facilities;
space planning;
administration support; and
evaluation system.
The implementation of these steps in the case
study is described below.
4.2.1. Design of student recruiting
The new department decided to recruit students
for five classes every academic year, with each class
containing 50 students. In Taiwan, class sizes and
the number of students in a department must be
approved by the Ministry of Education (MOE) of
Taiwan, and these must therefore be planned in
advance. With respect to entrance requirements, it
was decided that students would apply for admission and then pass an admission examination. It was
also decided that the number of enrollments each
year would be adjusted according to demand for
leisure-operation personnel.
4.2.2. Design of financial planning
Salaries of teachers are determined by MOE
regulations. The following budgetary figures were
determined:
personnel expenses: NT$740,000,000
scholarship funds: NT$49,000,000; and
purchase of instruments and equipment:
NT$7,000,000.
ARTICLE IN PRESS
186
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
4.2.3. Design of marketability planning
Design of marketability planning included:
the drawing-up of a budget (NT$2,000,000) for
marketing (to be carried out by the enrollment
department);
taking part in school admission fairs frequently;
promoting the new department in high schools;
and
marketing using relevant media to enhance the
reputation of the new DLM.
4.2.4. Design of teacher’s employment
It was decided that the department would employ
16 full-time teachers—15 senior staff members with
doctorates and one lecturer without a doctorate. In
addition, the new department would utilize the
services of several part-time teachers with practical
experience in various aspects of leisure management, including:
management of leisure centers;
physical-health activities
management of natural resources;
services provision; and
pottery, tea art, and so on.
4.2.5. Design of education quality
To improve education quality, the staff/student
ratio was set at 1:25. Scholarships were to be
granted to excellent students, and guidance and
assistance were to be provided for weaker students
to encourage all students to work hard. In addition,
an early-warning system of grades was instituted to
avoid students being expelled due to bad grades.
Finally, a system of counseling assistance was to be
provided to monitor students who were facing
psychological difficulties and to provide them with
appropriate advice and spiritual guidance.
4.2.6. Design of curriculum planning
It was decided to base the curriculum planning
design on 131 credit points (88 in the compulsory
curriculum and 43 in the optional curriculum). This
was to include:
leisure agriculture (organic agriculture, leisure
fishery, leisure farming);
leisure art (pottery art, gardening, tea-art culture);
leisure sports (practice of sports, water-leisure
sports, physical-health management);
leisure and natural resources (forest leisure
operations, coastal leisure development, hot
springs management); and
leisure for those with special needs (children,
women, the elderly).
Practical training in enterprises was to be
provided during two summer vacations to ensure
that practical experience was gained before graduation.
4.2.7. Design of teaching/service process
A questionnaire surveying administration and
teaching was to be issued during each semester to
identify the expectations and satisfaction of students. This questionnaire was to be the basis of
assessment of progress in the new department’s
teaching/service process. In addition, the Internet
was to be utilized as an information resource and a
means of network teaching.
Finally, cooperation with leisure enterprises was
deemed to be essential to:
identify demand for graduates;
achieve timely modification of courses and
teaching methods;
identify purchases of appropriate equipment;
meet the demands of all customers; and
estimate overall effectiveness of the new department.
4.2.8. Design of physical/technical facilities
It was decided to provide the following facilities:
a laboratory for physical-health management
(providing equipment for sports testing and
physical fitness);
a video conference room (providing for a
capacity of 150 persons);
multimedia rooms;
a reading room;
a pottery art room;
a tea-art room;
a case-study room;
a rhythmic gymnastics room; and
a teachers’ study room.
4.2.9. Design of space planning
In designing physical and technical facilities, it
was decided that there should be sufficient space for
accommodation and leisure activities for the projected number of students, with allowance for space
ARTICLE IN PRESS
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
for an increased number of students if demand led
to an extension of the department.
4.2.10. Design of administration support
It was decided that all service processes should be
computerized to reduce manpower and to promote
service effectiveness. ISO-9000 standard operations
procedures were to be established to enable teachers
and students to be aware of the complete operational
procedure of the department. In addition, arrangements were made for all instruments and equipment
to be regularly maintained in good order to maintain
the highest standards of teaching and research.
4.2.11. Design of evaluation system
It was decided to establish an effectivenessmeasuring system of the administration and teaching. A questionnaire was designed to survey
teaching quality and satisfaction of students during
each semester. This was to include an assessment of
individual teachers and staff members to ensure
optimal performance.
It was decided to establish the following performance indicators:
customer satisfaction: 90%;
registration rate: 100%;
e-teaching service: 70%; and
performance evaluation of department: top 5.
4.3. Summary of case study
The theoretical model presented in this study
applies the DFX technique while taking account of
every dimension in the CE environment. By
implementing this model in the establishment of
its new department of leisure management,
MHUST achieved the following apparent benefits:
The department registration rate reached 100%
in the three years since the model was first
implemented in 2001.
The performance of the department ranked first
in the university on all measures (including
student satisfaction, overall performance assessment, and so on).
The department’s mission and vision were enunciated and communicated clearly, thus facilitating effective shared efforts among students and
staff in achieving departmental goals.
In accordance with enterprise demand and
government policy, the new department has
187
overcome deficiencies in the training of leisure
managers, and has successfully met the demands
of leisure enterprises.
By emphasizing a combination of theory and
practice, students have acquired relevant theory
from university classes and practical skills
through experience of working in business. (In
this respect, it should be noted that higher
education in Taiwan is notably deficient in
combining theory and practice effectively.)
There are many service design theories and
models are very plenteous, but each method has
its own advantages and disadvantages. In Failure
Mode and Effect Analysis (FMEA), DFX and QFD
are most familiar applications for product design
(Chen and Yang, 2004). FMEA is concerned with
identifying the ways in which a product can fail and
the effects of such failures. It also provides
alternative solutions to prevent failures (Dowlatshahi, 2001b). But, the FMEA method is unsuitable
for using this case study. QFD, a known tool is also
often applied in service design and development, but
statistical analysis, decisions in each service items
correlation and calculation of its weight value are
necessary completed. Therefore, QFD is more
complicated and less convenient than ‘DFX’ (Hsiao,
2002). Traditional product designs or service designs only consider such design factors as cost,
quality, manufacture and reliability (Dowlatshahi,
2001b), however, could allow for the inclusion and
trade-offs among such design factors as: marketability, education quality, space planning and
financial planning. These factors will be adjusted
according to the points of view of the industry or
the organization. Therefore, the case study applies
DFX in a CE environment very cautiously to
consider every key factor. The use of DFX in a
CE environment has ensured success in the planning
and design of the new department. If DFX is
implemented separately from a CE environment,
communication problems invariably arise which
increase costs and decrease the ultimate service
quality. The incorporation of a CE environment in
the overall process ensures simultaneous consideration of service design and process design, thus,
improving service quality and reducing re-design
cost (Yan and Wu, 2001). The use of DFX in a CE
environment, strictly planned and designed, has
ensured that the implementation of the model in the
case study has been complete and efficient. For the
university, the ultimate result is that the institution
ARTICLE IN PRESS
188
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
has attracted excellent teaching staff and outstanding students. The model has thus promoted the
wider reputation of the university in the community
and has ensured its financial health.
5. Conclusion
Competition in the higher education sector is
becoming increasingly fierce. In such an environment, universities must learn from private enterprise
in emphasizing excellent quality, low costs, and high
efficiency. Higher education institutions also need to
apply modern management methods such as total
quality management (TQM), balanced scorecard
(BSC), and Six Sigma. These integrated methods
can promote efficiency and effectiveness, and thus
maintain the growth and financial health of the
institutions concerned. In addition, these methods
also promote the wider reputation of the institution
in the community.
The present study has addressed these matters by
integrating two scientific approaches the DFX
technique and the theory of CE to improve
educational quality and management performance.
The establishment of a new department must take
into account many interdependent dimensions
simultaneously. In presenting a complete model
for the establishment of a new department within a
university, the present study provides university
administrators with a valuable cost-saving and timesaving approach to a crucial and complex challenge
in modern education.
Acknowledgement
The authors acknowledge Dr. Miao-Ling Wang
for providing Ming-Hsin University of Science and
Technology related information. The authors also
appreciate Dr. Zhen-De Fan, for assistance in the
study data investigation and for suggestions.
References
Aitken, J., Childerhouse, P., Towill, D., 2003. The impact of
product life cycle on supply chain strategy. International
Journal of Production Economics 85, 127–140.
Alam, I., Perry, C., 2002. A customer-oriented new service
development process. Journal of Service Marketing 16 (6),
515–534.
Anumba, C.J., Baugh, C., Khalfan, M.MA., 2002. Organisational structures to support concurrent engineering in
construction. Industrial Management & Data Systems 102
(5/6), 260–270.
Bullinger, H.J., Fähnrich, K.P., Meiren, T., 2003. Service
engineering—methodical development of new service products. International Journal of Production Economics 85,
275–287.
Chase, R.B., 1978. Where does the customer fit in a service
operation? Harvard Business Review 56 (6), 137–142.
Chen, P.C., Ho, C.Y., 2003. US university academy reputation
ranking indicators research—example of US News and World
Reports. Education Research Monthly Magazine 116, 77–96.
Chen, S.H., Yang, C.C., 2004. Applications of Web-QFD and EDelphi method in the higher education system. Human
Systems Management 23, 245–256.
David, F.R., 2001. Strategic Management: Concepts and Cases,
eighth ed. Prentice-Hall Inc., Upper Saddle River, NJ.
De Brentani, U., 1995. New industrial service development
scenarios for success and failure. Journal of Business
Research 32, 93–103.
De Kluyver, C.A., 2000. Strategic Thinking: An Executive
Perspective. Prentice-Hall, Upper Saddle River, NJ.
Dowlatshahi, S., 1992. Purchasing’s role in a concurrent
engineering environment. Journal of Supply Chain Management 28 (1), 21–25.
Dowlatshahi, S., 1996. The role of logistics in concurrent
engineering. International Journal of Production Economics
44, 189–199.
Dowlatshahi, S., 1997. The role of product design in designer–buyer–supplier interface. Production Planning & Control 8
(6), 522–532.
Dowlatshahi, S., 1999. A modeling approach to logistics in
concurrent engineering. European Journal of Operation
Research 115, 59–76.
Dowlatshahi, S., 2000. Designer–buyer–supplier interface: theory
versus practice. International Journal of Production Economics 63, 111–130.
Dowlatshahi, S., 2001a. Product life cycle analysis: a goal
programming approach. Journal of the Operational Research
Society 52, 1201–1214.
Dowlatshahi, S., 2001b. The role of product safety and liability in
concurrent engineering. Computer and Industrial Engineering
41, 187–209.
Edvardsson, B., 1992. Service breakdowns: a study of critical
incidents in an airline. International Journal of Service
Industrial Management 3.
Edvardsson, B., 1997. Quality in new service development: key
concepts and a frame of reference. International Journal of
Production Economics 52, 31–46.
Friel, T., 2000. A dramatic method to demonstrate concurrent
engineering in the classroom. Journal of Engineering Education 89 (3), 265–267.
Han, C.H., Kim, J.K., Choi, S.H., 2004. Prioritizing engineering
characteristics in quality function deployment with incomplete information: a linear partial ordering approach. International Journal of Production Economics 91, 235–249.
Hsiao, S.W., 2002. Concurrent design method for developing a
new product. International Journal of Industrial Ergonomics
29, 41–55.
Huang, G.Q., Mak, K.L., 1997. The DFX Shell: a generic
framework for developing design for X tools. Robotics &
Integrated Manufacturing 13 (3), 271–300.
Johnson, S.P., Menor, L.J., Roth, A.V., Chase, R.B., 2000. A
critical evaluation of the new service development process. In:
Fitzsimmons, J., Fitzsimmons, M. (Eds.), New Service
ARTICLE IN PRESS
C.-C. Yang et al. / Int. J. Production Economics 107 (2007) 179–189
Development—Crating Memorable Experiences. Sage Publications, Thousand Oaks, CA, pp. 1–32.
Juran, J.M., 1992. Juran on Quality by Design: The New Steps
for Planning Quality into Goods and Services. Free Press,
New York.
Kanji, G.K., Tambi, A.M.B.A., 1999. Total quality management
in UK higher education institutions. Total Quality Management 10 (1), 129–153.
Kaplan, P.S., Norton, D.P., 2001. The Strategy-Focused
Organization: How Balanced Scorecard Companies Thrive
in the New Business Environment? Harvard Business School
Press, Boston.
Katouzian, M.A., 1970. The Development of the Service Sector:
A New Approach. Oxford Economic Papers. Cambridge
University Press, Cambridge.
Koufteros, X., Marcoulides, G.A., 2006. Product development
practices and performance: a structural equation modelingbased multi-group analysis. International Journal of Production Economics 103 (1), 286–307.
Koufteros, X., Vonderembse, M., Doll, W., 2001. Concurrent
engineering and its consequences. Journal of Operations
Management 19, 97–115.
Kumar, R., Midha, P.S., 2001. A QFD based methodology for
evaluating a company’s PDM requirements for collaborative
product development. Industrial Management & Data
Systems 101 (3/4), 126–131.
Kuo, T.C., Huang, S.H., Zhang, H.C., 2001. Design for manufacture and design for ‘X’: concepts, applications, and
perspectives. Computers & Industrial Engineering 41, 241–260.
Lai, H.H., Lin, Y.C., Yeh, C.H., Wei, C.H., 2006. User-oriented
design for the optimal combination on product design.
International Journal of Production Economics 100 (2),
253–267.
189
Ministry of Education Statistical Department, 2004. from /
http://www.edu.tw/EDU_WEB/Web/STATISTICS/
home.htmS.
Murdick, R.G., Render, B., Russell, R.S., 1990. Services
Operation Management. Allyn and Bacon, Needham Heights,
MA.
Niven, P.R., 2002. Balanced Scorecard Step by Step. Wiley, New
York.
Oplatka, I., 2004. Marketing informal education institutions in
Israel: the centrality of customers’ active development in
service development. The International Journal of Educational Management 18 (6/7), 417–424.
Pillai, A., Sivathann, A., Joshi, K., Srinivasa, R., 2002.
Performance measurement of R&D projects in a multiproject, concurrent engineering environment. International
Journal of Project Management 20, 165–177.
Prasad, B., 1996. Concurrent Engineering Fundamentals—
Integrated Product and Process Organization. Prentice-Hall,
New Jersey.
Quinn, J.B., 1980. Strategies for Change: Logical Instrumentalism. Richard D. Irwin, Homewood, IL.
Rosairo, L.M., Knight, W.A., 1989. Design for assembly
analysis: extraction of features from a CAD system database.
Annals of CIRP 38 (1), 13.
Stehn, L., Bergström, M., 2002. Integrated design and production
of multi-storey timber frame houses—production effects
caused by customer-oriented design. International Journal
of Production Economics 77, 259–269.
Yan, J.H., Wu, C., 2001. Scheduling approach for concurrent
product development process. Computers in Industry 46,
139–147.
Yang, C.C., 2004. Strategy Creates Advantages. Chinese
Productivity Center, Taipei.
CONCURRENT ENGINEERING: Research and Applications
Overcoming the 90% Syndrome: Iteration Management
in Concurrent Development Projects
David N. Ford1,* and John D. Sterman2
1
Department of Civil Engineering, Texas A&M University, College Station, TX 77843-3136, USA
2
Sloan School of Management, Massachusetts Institute of Technology,
50 Memorial Drive, E53-351, Cambridge, MA 02142 USA
Abstract: Successfully implementing concurrent development to reduce cycle time has proven difficult due to unanticipated iterations. We
develop a dynamic project model that explicitly models these interactions to investigate the causes of the ‘‘90% syndrome,’’ a common form of
schedule failure in concurrent development. We find that increasing concurrence and common managerial responses to schedule pressure
aggravate the syndrome and degrade schedule performance and project quality. We show how understanding of and policies to avoid the 90%
syndrome require integration of the technical attributes of the project, the flows of information among participants, and the behavioral decisionmaking heuristics participants use to respond to unanticipated problems and perturbations.
Key Words: concurrent development, concurrent engineering, iteration, rework, cycle time, project management, system dynamics.
1.
Introduction
Developing products faster has become critical to
success in many industries, whether the product is an
office building, software package, or computer chip.
Calls for faster product development have simultaneously taken on the sacred tone of a mantra and the
volume of a brass band [34]. Perhaps with good reason.
Cycle time reduction is considered crucial to success by
many researchers (e.g., [34,41]) and practitioners (e.g.,
[29,33]). Developing products faster than competitors
can increase market share, profit, and long-term
competitive advantage [29,33,41].
In response many firms have shifted from sequential
to concurrent development (aka Integrated Product
Development or Fast Track development). Large
reductions in cycle time can be realized by applying
concurrent development [4,9,31,41,42]. Despite some
successes, implementing concurrent development has
proven difficult for many [30,41]. These failures arise in
part because cycle time reduction through concurrent
development increases process and organizational complexity [8,26,41]. Concurrent methods often increase the
frequency and number of information transfers among
project phases [7,8]. More tasks are begun with
*Author to whom correspondence should be addressed.
E-mail: DavidFord@tamu.edu
incomplete or preliminary information, increasing iteration. Management policies have not generally improved
to address the effects of increased complexity created by
concurrent development.
Many explanations have been suggested for the
concurrent development implementation challenge.
Backhouse and Brookes [4] suggest implementation
fails due to mismatches among a development organization’s people, controls, tools, processes and structure,
and the organization’s need for efficiency, focus,
incremental change, radical innovation, and proficiency.
Other researchers focus on the disaggregation of work
into smaller pieces [35,43] and mismatches between
attributes of the technology and the degree of overlapping employed [25]. Still others focus on activity
sequencing [22,35], coordination caused by overlapping
activities [21], and information transfer [6,25].
In this paper we develop a formal model to explore
how concurrent process structures can cause a particular
form of development project schedule failure, the 90%
syndrome. We show how development processes such as
overlapping of activities, activity durations, and delays
in the discovery of rework requirements can create
unplanned iteration, delays, higher costs, and lower
quality. We explore policies that can help improve
project performance. In the companion paper ([19], this
issue), we use the model to explore the interactions
between the process structure of concurrent projects and
behavioral responses of developers and managers.
Volume 11 Number 3 September 2003
1063-293X/03/03 0177–10 $10.00/0
DOI: 10.1177/106329303038031
ß 2003 Sage Publications
177
178
D. N. FORD
2.
AND
The 90% Syndrome
J. D. STERMAN
inter-phase iterations suggest the importance of the late
discovery of unanticipated rework.
One common concurrent development problem is the
‘‘90% syndrome.’’ The syndrome describes a project
that reaches about 90% completion on schedule but
then stalls, finally finishing after about twice the
originally projected duration. A senior manager in one
company we worked with described their experience as
‘‘The average time to develop a product is 225% of the
projected time, with a standard deviation of 85%. We
can tell you how long it will take, plus or minus a
project’’ [16]. The syndrome is common in many
industries including software, construction, consumer
electronics, and semiconductors [2,12,24]. Consider the
following example from our fieldwork with a leading
semiconductor firm, describing an ASIC (Application
Specific Integrated Circuit) project we call Rattlesnake.
The original schedule called for a 34 week project, with a
smooth, single-pass flow of work through product
definition, design, layout, mask preparation, prototype
fabrication, prototype testing, manufacturing process
design, and production rollout—no iterations were
anticipated. The project appeared to progress smoothly,
though somewhat more slowly than planned, apparently
completing 79% of the project scope by the original
deadline. However, prototype testing revealed major
problems, requiring an unplanned iteration with revisions in the design. Tests of the second prototype found
still more problems, requiring another major iteration.
The project was finally completed in week 81, more than
twice the original schedule (see Figure 1 in [19], this
issue). The slow progress experienced late in the project
is typical of the 90% syndrome, and the unplanned
Product
Definition
3.
The Development Project Model
To investigate the impacts of the interaction of
physical and information processes with managerial
decision-making we built a dynamic project simulation
model that integrates several constraints usually treated
separately:
1. Characteristic Process Durations: Development activities require minimum times to be performed regardless of the resources allocated to the activity.
2. Development Activity Sequencing: Development
activities occur in a specific sequence within phases.
3. Dynamic Information Requirements: Development
phases are constrained by information dependencies
within and among project phases. These dependencies vary with phase progress and management
decisions.
4. Work Release Policies: Work is often not released as
it is completed, but in discrete packets. Policies
governing packet size and release timing strongly
affect the availability of information across project
phases.
5. Coordination: When released work is discovered to
require rework developers in the originating and
discovering phases must coordinate prior to revising
the work.
Our model simulates the performance of a multiplephase development project. Each phase is represented by
Prototype
Testing
Reliability
& Quality
Design
Network Legend
Development Phase
Products of Development Phase
Supplying Phase
Return Errors for Rework
Product
Design Prototype Reliability
Definition
Testing & Quality
Receiving
Phase
Product
Definition
X
X
Design
X
X
X
X
Prototype
Testing
X
X
X
X
X
X
X
Reliability
& Quality
Figure 1. A project phase network and its corresponding Design Structure Matrix.
Iteration Management in Concurrent Development Projects
a generic structure, which is parameterized to reflect a
specific stage of product development such as preparing
construction drawings, writing software, or testing
prototypes. The unit of measure for development work
is the ‘‘task’’ or work package, an atomic piece of work.
Examples include writing a line of code or installing a
steel beam. When tasks within a phase are heterogeneous the unit of work can be defined as the average
amount an experienced person can accomplish in a given
interval (e.g., an hour or day). Information concerning
the quality of completed tasks is generated through
testing or quality assurance efforts. Tasks may require
rework because they were done incorrectly or because
the work or information they were based on was itself
erroneous or has changed.
The model is a system of nonlinear differential
equations. The model is based on existing product
development theories and our field studies of development projects. For example, the development process
structure is based on theories of project constraints
and resources [32] and previous dynamic project
models including [1,10,17]. Because no closedform solutions are known, we simulate the
system’s behavior. The full model is available at
in the Vensim simulation
language (see ).
3.1 Modeling Work and Information Flows
The flow of work and information among phases
defines the network structure of the project. Figure 1
shows a simple but common example. The links shown
in Figure 1 represent several forms of interphase
interaction, including:
. Work progress in which supplying phases provide
development products or other information to
receiving phases. These flows are shown by the
solid arrows.
. Work inherited by receiving phases from supplying
phases may require rework (either mandatory due to
errors or optional for improvement). Inheriting work
containing errors or requiring rework corrupts work
done by the receiving phases. When corrupted work is
discovered it is reported to the phase responsible for
the problem so it can be reworked. These information
flows are shown by the dashed arrows in the project
network.
. Rework requires coordination between the phase that
discovered the change requirement and the phase that
generated and must correct the work. Coordination
must occur prior to the revision of the work.
Coordination is an activity in individual phases
(boxes) generated by the reporting of problems
requiring rework (dashed arrows).
179
The information flows among phases in the model are
bi-directional, as in the Design Structure Matrix (DSM)
approach [13,35,36]. The DSM identifies bi-directional
dependencies between phases in which the activity
initiated first (upstream) receives products from the
activity initiated later (downstream) as well as the more
traditional dependence in the general direction of work
flow. Figure 1 also shows the DSM corresponding to the
project network in the diagram. Several iterative loops
are created by the bi-directional dependencies among
phases. Our model allows any DSM to be represented
by specifying the number of phases and the dependencies among them.
All development processes are constrained by the
physical and information relationships among the
activities and phases within a project. These constraints
include development activity durations and precedence
relationships, information dependencies leading to
iteration [36], the availability of work [17], coordination
mechanisms [22], the characteristics of information
transferred among development phases [25], and the
number, skill, and experience of project staff [2]. These
processes and policies can interact to constrain progress.
Consider the erection of the structural steel skeleton for a
ten story building. Each member (the columns, beams,
and bracing) must be installed, inspected, and corrected
if the installation is found to be defective. These activities
can only occur in a specific order: install, inspect, approve
or discover a problem, rework, and re-inspect; when
no further problems are found the work is approved
and released so other work dependent on that task
can proceed (e.g., installation of floors, walls, etc.).
Management policies such as the number of floors that
must be approved prior to release also affect progress and
information availability downstream. Figure 2 shows the
states of work within a single development phase in the
model and the flows of work among them.
As work is first completed it enters the stock of work
awaiting quality assurance (QA). If it passes QA (either
because it is correct or the need for changes is not
detected), it is approved and enters the stock of
approved work. When sufficient work has been
approved, a package is released, adding to the stock of
work released to other phases or customers. The release
package size is a management decision and is conditioned by characteristics of the phase. For example, in
semiconductor development the vast majority of the
design code must be completed prior to release for a
prototype build since almost all the code is needed to
design the masks. In other development settings
managers have broad discretion in setting release
package sizes.
Work found to require changes must be resolved
through coordination with the phase responsible for
the problem. Classic examples include designers working with marketers to refine ambiguous product
180
D. N. FORD
AND
J. D. STERMAN
Notification and Return
Rate
Coordination rate
Work needing
Coordination
Work known to
need Rework
Discovery of
Needed Rework
Rework
Rate
Work needing
Initial
Completion
Work needing
Quality
Assurance
Approval
Rate
Work
Approved
Release
Rate
Work Finished
and Released
Initial Completion
Rate
Figure 2. Work flows within a single development phase.
specifications and manufacturing engineers meeting
with designers to explain why parts cannot be built as
specified in the drawings. After coordination resolves
disputed issues, these tasks move to the stock of work to
be changed and are subsequently reworked, then
returned to quality assurance for re-inspection. Quality
assurance is imperfect, so some tasks requiring rework
can be missed and are erroneously approved and
released. Such rework requirements may be discovered
later by another phase—if not, they remain embedded in
the product, to be discovered by the customer. When the
phase reports problems, the affected tasks are moved
from the stock of work considered finished to the
coordination backlog, then eventually reworked. For
example, a test phase may discover a short circuit across
two layers in a prototype chip. If the error is traced to
the design, test engineers must work with the designers
to specify the location and characteristics of the short
circuit. The designers then must rework, recheck and
rerelease the design, followed by layout, masking,
prototype fabrication, and retesting of the new chip.
The probability of error detection depends on a
variety of behavioral factors and management decisions. The probability of detecting problems declines
as the information available is less current, complete,
and accurate. High overlap between dependent phases
in concurrent development means many tasks are done
on the basis of specifications and components that
are unavailable or changing. Our fieldwork shows that
activities such as quality assurance, testing, documentation, and validation commonly suffer under concurrent development as development activities are
overlapped. For example, we asked engineers in
a large manufacturing firm how they accommodated
the schedule compression and concurrency created
by the organization’s official product development
process:
‘‘The technology may not be ready before alpha phase.
Sometimes we have no choice, we just have to put
something in’’ — Development Engineer
‘‘We might accept a lower level of maturity [in the
prototype]. Maybe maturity isn’t a good word. We
might accept a lower level of design representativeness
than we would like’’ — Engineering Manager
‘‘Often, we’ll put [early prototype] parts in a [later
prototype] . . . There’s no getting around it as long as we
have to go fast’’ — Program Manager
Schedule compression also biases workers towards
getting their tasks done, even when that means spending
less time on validation and quality assurance. An
engineer in the organization above admitted that ‘‘We
might not be able to finish the part, finish the FMEA’s
[Failure Modes and Effects Analysis], etc. We’ll do the
FMEA’s, but they won’t be as thorough as they would
[be] otherwise.’’ Another commented: ‘‘We haven’t done
the FMEA yet. We’ll probably do it for beta [second
prototype], but not for alpha [first prototype]. We just
don’t have time to do it.’’
These quotes illustrate a phenomenon we find
repeatedly in our fieldwork: The greater the degree of
concurrence, the greater the schedule pressure, and the
greater the gap between resources available and
resources required, the less effort is devoted to quality
assurance and the lower the effectiveness of that effort.
We capture these effects parsimoniously by assuming
the probability of detecting the need for rework declines
as the degree of concurrence increases.
3.2 Modeling the Speed of Development Activities
and Concurrence
The rates at which development activities are performed depend on two types of constraints: resources
and processes. Obviously, progress can be constrained
by inadequate resources—too few workers, insufficient
worker skill and experience, or insufficient supporting
infrastructure (such as CAD/CAM systems). A variety
of models explore how underestimating project scope,
overestimating productivity, delays in the discovery of
errors, or unexpected changes in customer requirements
Iteration Management in Concurrent Development Projects
can cause resource shortages that lead to delays, cost
overruns, and quality problems (e.g., [2,10,37 Ch. 2.3]).
In this paper, however, we seek to show how the
structure of a development process interacts with
managerial decision making to contribute to the 90%
syndrome, even when resources are ample. If so,
throwing more people and money at a project in trouble
will have low leverage; effective policies will require
changes in project structure and management policies.
Even when resources are ample, progress can be
constrained by the interdependencies among phases and
tasks. As an example, consider again the erection of the
steel skeleton for a building. Each steel member must be
installed (base work), and inspected (quality assurance).
If an error is found, the affected supervisors and skilled
trades must work together to devise a plan to remedy it
(coordination) before the error can be corrected
(rework). For any given technology, a certain minimum
amount of time is required for each of these activities
even when resources such as laborers and cranes are
ample. Further, certain tasks cannot be started or
completed until others are done. For example, the steel
members for the upper floors cannot be installed until
the beams and girders for lower floors are in place.
These constraints are captured in our model through
concurrence relationships. The function relating how
much steel for upper floors can be placed to the progress
of lower floors defines an intraphase concurrency
relationship (the constraint arises within the steel
erection phase).
Analogously, interphase concurrence relationships
answer the question ‘‘How much work can we now
complete given the work released by the phases upon
which we depend?’’ For example, the erection of the
steel for an office building depends on the release of
construction drawings by the design phase and the
progress of foundation work (among others). These
constraints require two interphase concurrence relationships: one describing how much of the steel can be
erected based on the release of construction drawings,
and another describing how much steel erection can
proceed based on the state of the foundations. Either of
these interphase relationships might constrain steel
erection. Each interphase concurrence relationship
describes the fraction of a phase’s total scope that can
be done based on the fraction of work released by a
supplying phase. Interphase concurrence relationships
characterize the dependencies among the off-diagonal
terms in the Design Structure Matrix. They are
potentially nonlinear, allowing our model to capture
changes in the degree of dependence among phases as a
project evolves. For example, ASIC designers may be
able to develop certain standard elements of the design
(memory registers, data bus) with early information
about customer requirements, but may be unable to
continue until full specifications for the required
functionality are released.
Concurrence relationships are characteristic features
of a project’s network structure and must be estimated
for each project. We tested our model against the
behavior of a medium-sized chip development project at
a major U.S. semiconductor firm (the Python project)
[18]. Ford and Sterman describe the protocol used to
elicit these concurrence relationships from project
personnel and provide examples. Figure 3 shows four
expert estimates of the interphase concurrence relationship between the product definition and design phases of
the Python project. The product definition phase
develops product architecture and specifications based
on the Python chip’s market and target performance.
The designers use these specifications as the basis for the
detailed design embodied in the software code used to
100
e
epr
ve
tati
sen
gR
etin
Fraction
Available
for
Initial
Completion
by
Design
Phase
(%)
gic
ate
Str
rk
Ma
r
tA
ct
ite
ch
uc
od
Pr
Design
Manager
r
igne
Des
0
0
181
Fraction Released by
Product Definition Phase (%)
100
Figure 3. Four estimates of the interphase concurrence relationship between the product definition and design phases.
182
D. N. FORD
AND
J. D. STERMAN
planned progress 12 weeks after the project began.
However after development began the decision was
made to design the Python chip in two components
instead of one, resulting in two design releases and
therefore two jumps in performance. Like the
Rattlesnake project, Python suffered from the 90%
syndrome. The project remained close to the original
schedule through week 20 and was 73% complete by the
original deadline. Progress then slowed from 1.8% per
week to 0.9% per week, and the project was ultimately
completed 77% late (week 69 vs. 39).
We drew on our fieldwork and prior research (e.g.,
[11]) to estimate the parameters for the Python case.
Ford and Sterman [18] describe the protocol used to
elicit the concurrence relationships and provide examples from the Python project. Figure 5 shows planned
and actual project performance as simulated by our
model. Planned progress simulates management’s plan
for a single design release, their assumption of no
interphase iteration, and overestimation of productivity.
Experienced managers expect iteration but are often
required to use ‘‘stretch objectives’’ in planning because
management believes they keep motivation and pressure
to perform high. Python project developers repeatedly
described the unrealistic optimism used to plan projects,
including the assumption of little or no rework.
The model simulation (Figure 5) closely matches
actual project behavior (Figure 4) and recreates the 90%
syndrome experienced by the Python project.
Differences between our simulation and the project’s
actual behavior are largely due to resource constraints
omitted from the model, specifically staffing problems
created by the unanticipated iterations. The similarity
between Figures 4 and 5 indicates that even projects
staffed by skilled personnel with ample resources can
experience the 90% syndrome, solely as a function of the
informational and physical dependencies created by
concurrency.
lay out individual components on the silicon. Each
estimate in Figure 3 describes the mental model of a
participant concerning the question ‘‘How much design
work can be completed based on the fraction of the
product definition work that has been completed,
approved and released?’’
Interestingly, the two ‘‘upstream’’ people (the marketing representative and the product architect) believed
the ‘‘downstream’’ people (the design manager and
designer) could, and presumably should, begin their
work quite early, when few product specifications have
been released, while those downstream believed their
work could only progress when a majority of the
specifications were available. These differences in mental
models had led to conflict and delay in prior development projects. The explicit description of these mental
models initiated and facilitated discussions for improving the organization’s development processes.
3.3 Model Testing
The model was tested for structural and behavioral
similarity to actual development projects using standard
methods [20,37, Ch. 21]. Model structure was based on
product development project processes and organizations as described in the literature and derived from our
fieldwork. We examined the ability of the model to
replicate the experience of the Python project described
above. Python applied all the major precepts of
concurrent development including overlapping phases
and cross-functional teams. The organization was well
trained in concurrent development practices [15,40].
Figure 4 compares Python’s original schedule and actual
performance, developed from records of the phase
durations and completion dates (e.g., by counting lines
of code in each version of the design code). As is
common in semiconductor development, and verified in
our interviews, the design phase planned to release its
work in a single large package, generating the jump in
100
Cummulative Progress (percent)
90
80
70
60
50
40
30
20
Planned Progress
10
Actual Progress
.
0
0
5
10
15
20
25
30
35
40
45
50
55
60
Time (weeks from project start)
Figure 4. Planned and actual progress of the Python project.
65
70
75
183
Iteration Management in Concurrent Development Projects
100
Cummulative Progress (percent)
90
80
70
60
50
40
30
20
Simulated planned progress
10
Simulated actual progress
0
0
5
10
15
20
25
30
35
40
45
50
55
60
65
70
75
Time (weeks from project start)
Figure 5. Planned and actual progress of the Python project as simulated by the model.
4.
Implementing Concurrent
Development Processes
To examine the impact of concurrence on schedule
performance, we simulated the model with different
levels of concurrence. We vary all inter- and intraphase
concurrence constraints. We preserve start time constraints such as cases where a phase cannot start until at
least some work has been released by a supplying phase.
Figure 6 shows the impact on project duration,
iteration, and quality of varying the degree of concurrence from fully sequential (100% of the base case) to
highly overlapped activities (þ150% of the base case).1
As expected, large reductions in the degree of
concurrence cause sharp increases in duration
(Figure 6). As overlapping decreases some phases
delay the start of their work well after the point at
which the supplying phases have completed theirs.
Increasing concurrency reduces duration, but with
sharply diminishing returns: a 50% increase in overlap
compared to the base case reduces duration by 22%,
while another 50% increase cuts duration only another
6%, and improvement essentially ceases beyond that
point. Figure 6 also shows total work effort relative to
total project scope, defined as the cumulative number of
tasks completed (both initially and through rework),
and is a proxy for project cost.2
1
A stretch factor of þ50% more concurrence means each phase can now do 75%
of its work at the point where it could have done 50% in the base case; a stretch
factor of 50% means the phase could do only 25% of its work at the point
where it could do 50% in the base case. In implementing different levels of
concurrence we preserve constraints, where they exist, that, e.g., phase j cannot
begin its work until phase i has released as least some of its work. Such
constraints mean the ‘‘stretch’’ factor is nonlinear. The web-appendix provides
full documentation.
2
Project cost is actually the sum of the tasks completed by each phase weighted
by the unit cost of tasks in each phase. To preserve confidentiality we report
total work–not cost, implicitly assuming the unit cost of tasks in each phase are
equal.
Note that in the base case, total work effort is 55%
greater than project scope due to the impact of rework
(if all tasks were completed perfectly with no need for
changes work effort would equal project scope).
Interestingly, increasing concurrence decreases total
work effort—a 50% increase in concurrence cuts total
work effort from 1.55 to 1.27 times the project scope.
One might argue that total work effort should rise with
increasing concurrence since more work must be redone
when errors are discovered. This effect does occur, but is
overwhelmed by another, less intuitive impact: increased
concurrence increases the average iteration path length
by delaying the discovery of the need for rework to
phases farther from the generating phase. In an iteration
cycle, rework requirements are passed from the discovering phase to the originating phase. After coordination, changes are made to the flawed work in the
originating phase and to contaminated work in all
affected phases. The reworked tasks are re-inspected,
rereleased and arrive at the location of its discovery
again. For example, a test phase may discover an error
in the chip and trace it to the design. Test engineers
notify and coordinate with the designers to specify the
location and characteristics of the flaw. The designers
then must rework, recheck and rerelease the design,
followed by changes in layout, tape out, masking, and
prototype fabrication. The cycle is completed when
testing of the redesigned prototype begins. High
concurrency means downstream activities carry out a
substantial portion of their work before they (or any
other phase) have a chance to detect and correct errors.
In essence, the downstream phases outrun the discovery
of inherited rework requirements.
From the preceding it appears that increasing
concurrence both speeds the project and cuts project
costs. However, the third graph in Figure 6 shows the
cost of concurrency: project quality drops significantly.
In the base case, the number of uncorrected errors
184
Log (Duration/Base Case)
D. N. FORD
Total Tasks Done/Project Scope
J. D. STERMAN
Project Duration
5.0
3.0
1.0
0.8
-1.0
-0.5
0.0
0.5
1.0
(Concurrence – Base Concurrence)/Base Concurrence
1.5
Work Effort
1.6
1.4
1.2
1.0
-1.0
Errors Remaining/Project Scope
AND
-0.5
0.0
0.5
1.0
(Concurrence – Base Concurrence)/Base Concurrence
1.5
0.08
Errors Remaining at Completion
0.06
0.04
0.02
0.00
-1.0
-0.5
0.0
0.5
1.0
(Concurrence – Base Concurrence)/Base Concurrence
1.5
Figure 6. Impact of varying concurrence (internal and external).
released to the customer is 5% of total project scope.
These uncorrected errors include both outright defects
(where the product does not function as designed) and
instances where the design does not correspond to
customer requirements. In the chip development context
such errors include features the customer wanted that
are not available (e.g., power consumption is too high),
features that do not function as designed (e.g., a certain
combination of inputs gives a fatal error), or design
attributes that cause low manufacturing yield.
Increasing concurrence 50% raises errors remaining
at project completion to 6.7% of project scope—
a 34% increase over the base case. At the same time
that increasing concurrence delays the discovery and
correction of errors, it also increases the likelihood of
releasing tasks requiring rework. As concurrence
increases, the information, technologies, and components of each phase relies upon as the basis for its work
are necessarily less complete, less accurate, and more
ambiguous. The number of tasks requiring rework
grows while at the same time the ability of personnel
in each phase to detect these problems falls, increasing
the number of tasks released with errors and thus the
chance that needed rework will not be discovered and
corrected before the project is completed.
The simulations show a strong tradeoff between
schedule and quality performance. Increased concurrency interacts unfavorably with the delays in the
discovery of rework needs. The greater the overlap,
the more work is completed and released before rework
requirements can be detected, leading to more
unplanned iteration. Greater concurrence increases the
vulnerability of a project to delays in discovering rework
and increases the fraction of work requiring such
changes. The result is lower suitability to customer
requirements and lower product quality.
Iteration Management in Concurrent Development Projects
5.
Conclusions
In this paper we use a dynamic model of development
projects to describe, quantify, and simulate how physical
and information processes interact with managerial
decision making to constrain progress and cause project
overruns. We have shown the critical role of iteration
cycles in explaining the 90% syndrome. Our research
suggests that an effective strategy addresses the managerial behaviors that cause iteration cycles to constrain
progress. Iteration cycles can delay projects by being
more in number, longer in the distance which information must travel, slower in traversing that distance, and
occurring later than possible. Researchers have proposed process designs to manage iteration cycle number,
speed, length, or timing. For example Terwiesch et al.
(1998) recommend ‘‘a fast process of problem detection,
problem solving and engineering change implementation’’ to increase iteration cycle speed. They suggest
‘‘loosening the coupling (dependence) between development activities’’ and improving the accuracy of preliminary information, both of which reduce the number
of cycles. McAllister and Backhouse (1996) suggest
redesigning work flows to reduce the number of
iteration paths in a project network. However increased
concurrence works against all these recommendations.
Our work has several implications for concurrent
development research. The model and simulations
demonstrate that effective modeling of development
processes must include the structure of information
dependencies to explain problematic project behaviors.
More specifically, the role of iteration cycles in
the 90% syndrome demonstrates the need for explicitly
including iteration. Future research can identify and
test metrics that relate iteration to different forms
of project and phase performance and how specific
iteration features constrain progress. Most interesting
and relevant for managers, the model can be used to
study the interaction of the process structure described
in this paper and the behavioral decision rules used
by engineers and managers under pressure to meet
aggressive deadlines (see [19], this issue). In that paper
we show how common behaviors such as concealing
the need for rework from managers and colleagues
interacts with the structure of concurrent development
programs to intensify the 90% syndrome, lower product
quality, and undercut the benefits of increased concurrency. We argue that sustained improvements in
project performance require integration of both the
physical and informational structure of concurrent development processes with the behavioral decision rules of
the engineers and managers who work within them.
185
Acknowledgments
The authors thank the Organizational Learning
Center and the System Dynamics Group at the MIT
Sloan School of Management and the Python organization for financial support. Special thanks to the
members of the Python team for their interest, commitment, and time.
References
1. Abdel-Hamid, T. and Madnick, S. (1991). Software Project
Dynamics, An Integrated Approach, Prentice-Hall, Inc:
Englewood Cliffs, NJ.
2. Abdel-Hamid, T. (1988). Understanding the ‘‘90%
Syndrome’’ in Software Project Management: A
Simulation-Based Case Study, The Journal of Systems
and Software, 8: 319–330.
3. Adler, P.S., Mandelbaum, A., Vien, N. and Schwerer, E.
(1995). From Project to Process Management: An
Empirically-based Framework for Analyzing Product
Development Time, Management Science, 41(3): 458–484.
4. Backhouse, C.J. and Brookes, N.J. (1996). Concurrent
Engineering, What’s Working Where, Gower, Brookfield,
VT: The Design Council.
5. Bohn, R. (July–Aug 2000). Stop Fighting Fires, Harvard
Business Review, 78(4): 83–91.
6. Browning, T. (Oct. 1999). Sources of Schedule Risk in
Complex System Development, Systems Engineering, 2(3):
129–142.
7. Clark, K.B. and Fujimoto, T. (1991). Product Development
Performance, Strategy, Organization, and Management in
the World Auto Industry, Boston, MA: Harvard Business
School Press.
8. Clark, K.B. and Fujimoto, T. (1989). Reducing the Time
to Market: The Case of the World Auto Industry, Design
Management Journal, v. 1(1): 49–57.
9. Componation, P.J., Utley, D.R. and Armacost, R.L.
(1999). Prioritizing Components of Concurrent Engineering Programs to Support New Product Development,
Systems Engineering, Oct 4, 1999, 2(3): 168–176.
10. Cooper, K.G. (1980). Naval Ship Production: A Claim
Settled and a Framework Built, Interfaces, 10(6): 20–36.
11. Cooper, K.G. and Mullen, T.W (1993). Swords and
Plowshares: The Rework Cycle of Defense and
Commercial Software Development Projects, American
Programmer, 6(5).
12. DeMarco, T. (1982). Controlling Software Projects, New
York: Yourdon.
13. Eppinger, S.D., Whitney, D.E., Smith, R.P. and Gebala,
D.A. (1994). A Model-Based Method for Organizing
Tasks in Product Development, Research in Engineering
Design, 6: 1–13.
14. Ettlie, J.E. (1995). Product-Process Development Integration in Manufacturing, Management Science, 41: 1224–1237.
15. Ford, D.N. (1995). The Dynamics of Project Management:
An Investigation of the Impacts of Project Process and
Coordination on Performance, Doctoral Thesis,
Cambridge, MA: Massachusetts Institute of Technology.
16. Ford, D.N., Hou, A. and Seville, D. (1993). An
Exploration of Systems Product Development at Gadget
Inc. Report D-4460, System Dynamics Group, Sloan
186
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
D. N. FORD
AND
School of Management, Cambridge, MA: Massachusetts
Institute of Technology.
Ford, D.N. and Sterman, J.D. (1998a). Dynamic Modeling
of Product Development Processes, System Dynamics
Review, 14(1): 31–68.
Ford, D.N. and Sterman, J.D. (1998b). Expert Knowledge
Elicitation to Improve Formal and Mental Models, System
Dynamics Review, 14(4): 309–340.
Ford, D.N. and Sterman, J.D. (2003). The Liar’s Club:
Concealing Rework in Concurrent Development, Concurrent Engineering: Research and Applications (this issue).
Forrester, J and Senge, P. (1980). Tests for Building
Confidence in System Dynamics Models, TIMS Studies in
the Management Sciences, 14: 209–228.
Haddad, C.J. (1996). Operationalizing the Concept of
Concurrent Engineering: A Case Study from the U.S. Auto
Industry, IEEE Transactions on Engineering Management,
43(2): 124–132.
Hauptman, O. and Hirji, K.K. (1996). The Influence of
Process Concurrency on Project Outcomes in Product
Development: An Empirical Study of Cross-Functional
Teams, IEEE Transactions on Engineering Management,
43(2): 153–178.
Joglekar, N.R., Yassine, A.A., Eppinger, S.D. and
Whitney, D.E. (2001). Performance of Coupled
Development Activities with a Deadline, Management
Science, 47(12): 1605–1620.
Kiewel, B. (January 1998). Measuring Progress in Software
Development, PM Network, Project Management
Institute, 12(1): 29–32.
Krishnan, V. (1996). Managing the Simultaneous
Execution of Coupled Phases in Concurrent Product
Development, IEEE Transactions on Engineering
Management, 43(2): 210–217.
Krishnan, V., Eppinger, S.D. and Whitney, D.E. (1995).
A Model-Based Framework to Overlap Product
Development Activities, Management Science, 43: 437–451.
Loch, C.H. and Terwiesch, C. (1998). Communication and
Uncertainty in Concurrent Engineering, Management
Science, 44(8): 1032–1048.
McAllister, J. and Backhouse, C. (1996). An Evolving
Product Introduction Process in Backhouse, C. and
Brookes, N. (eds.) Concurrent Engineering, What Works
Where. Gower. Brookfield, VT.
Meyer, C. (1993). Fast Cycle Time, How to Align Purpose,
Strategy, and Structure for Speed, New York: The Free
Press.
Moffat, L.K. (1998). Tools and Teams: Competing Models
of Integrated Product Development Project Performance,
Journal of Engineering Technology and Management, 15:
55–85.
Nevins, J.L. and Whitney, D. (1989). Concurrent Design of
Products & Processes, A Strategy for the Next Generation
in Manufacturing, New York: McGraw-Hill.
Noreen, E., Smith, D. and Mackey, J. (1995). The Theory
of Constraints and its Implications for Management
Accounting, Great Barrington, MA: North River Press.
Patterson, M.L. (1993). Accelerating Innovation, Improving
the Process of Product Development, New York: Van
Nostrand Reinhold.
Rosenthal, S.R. (1992). Effective Product Design and
Development, Homewood, IL: Business One Irwin.
Smith, R.P. and Eppinger, S.D. (1997a). A Predictive
Model of Sequential Iteration in Engineering Design,
Management Science, 43(8): 1104–1120.
J. D. STERMAN
36. Smith, R.P. and Eppinger, S.D. (1997b). Identifying
Controlling Features of Engineering Design Iteration,
Management Science, 43(3): 276–293.
37. Sterman, J.S. (2000). Business Dynamics, Systems Thinking
and Modeling for a Complex World, New York: Irwin
McGraw-Hill.
38. Sterman, J.D. (1994). Learning in and about Complex
Systems, System Dynamics Review, 10(2–3): 291–330.
39. Terwiesch, C., Loch, C.H. and De Meyer, A. (2002).
Exchanging Preliminary Information in Concurrent
Engineering:
Alternative
Coordination
Strategies,
Organization Science, 13(4): 402–419.
40. Voyer, J., Gould, J. and Ford, D.N. (1997). Systematic
Creation of Organizational Anxiety: An Empirical Study,
Journal of Applied Behavioral Science, 33(4): 471–489.
41. Wheelwright, S.C. and Clark, K.B. (1992). Revolutionizing
Product Development, Quantum Leaps in Speed, Efficiency,
and Quality, New York: The Free Press.
42. Womack, J.P., Jones, D. and Roos, D. (1990). The
Machine that Changed the World, The Story of Lean
Production, New York: Rawson Associates.
43. Zirger, B.J. and Hartley, J.L. (1996). The Effect of
Acceleration Techniques on Product Development Time,
IEEE Transactions on Engineering Management, 43(2):
143–152.
Biographies
David N. Ford
David N. Ford, PhD, P.E. is
an Assistant Professor in the
Construction Engineering and
Management Program in the
Department of Civil Engineering, Texas A&M University.
He researches development
project strategy, processes,
and resource management.
Dr. Ford earned his PhD
from MIT and Master and
Bachelors degrees from Tulane
University. He has over 14 years of engineering and
project management experience.
John D. Sterman
John D. Sterman is the
Jay W. Forrester Professor of
Management at the MIT Sloan
School of Management and
Director of MIT’s System
Dynamics Group. His most
recent book is Business Dynamics: Systems Thinking and
Modeling for a Complex
World.
International Journal of Project Management 20 (2002) 49±57
www.elsevier.com/locate/ijproman
Managing project risks: a case study from the utilities sector
Paul Elkington, Clive Smallman *
University of Cambridge, Trumpington Street, Cambridge CB2 1AG, UK
Received 20 January 2000; received in revised form 19 June 2000; accepted 13 July 2000
Abstract
We examine the project risk management practices in a British utility, which manages its information systems and business
change projects using the Prince2TM method. This method has greatly increased the success rate of projects run within the company,
but has little in the way of directing Project Managers in handling project risk. We review current project risk management literature. We then explore the current usage of risk management in the utility's projects, and determine the eect of risk management on
project success. We conclude by outlining recommendations for improving projects run in the utility and elsewhere. # 2001 Elsevier
Science Ltd and IPMA. All rights reserved.
Keywords: Project management; Risk management; Utilities; Case study
1. Introduction
In the last decade, British utility (water, power, and
telecommunications) companies have seen an unprecedented change to their businesses, a direct result of their
shift from the public to the private sector. The manner
in which utilities manage such change is increasingly via
change programmes. These are either a large set of
changes to just business processes and computer systems,
or changes to company culture and the attitude of its
sta. The majority are a mix of both. With signi®cant
strategic change being implemented by these programmes,
project and programme management is becoming
increasingly important to the companies' survival, and
much eort and resource are being put into ``professionalising'' the project approach undertaken.
The ``less predictable'' nature of projects makes them
riskier than day to day business activities. Hence, risk
management is an integral part of project management
and most large companies put substantial resources into
the management of business risk. However, there is evidence that a culture of risk management may not ®lter
down into every level of a company [1]. Consequently,
companies do not capitalise upon operational sta's
* Corresponding author. Tel.: +44-1233-766592; fax: +44-1223339701.
E-mail address: c.smallman@jims.cam.ac.uk (C. Smallman).
detailed knowledge of business processes, and it is likely
that many potential risks are not even noticed [2].
We present a study of project risk management practice in a British utility (henceforth `the Utility').
2. Project management practices in the Utility
Until privatisation, the Utility was the monopoly
supplier and distributor of a public good throughout a
large region of Britain. Since ¯otation and the deregulation of their businesses, the Utility has diversi®ed in
an attempt to attract new customers, whilst retaining a
strong presence in its traditional markets.
Immediately after privatisation, engineers, many of
whom had joined at sta level, dominated the Utility's
senior management. This encouraged a culture in which
small multi-skilled teams eected infrastructure maintenance; that is through projects. These ran using the
knowledge and experience of the engineers, rather than
formal methods of project management. Risk (usually
only technical systems risk) was considered, but mainly
on an ad hoc basis. Risk management consisted of overengineering the infrastructure (using high speci®cation
components where lesser ones would have suced) to
eectively build technical risk out, but at massively
increased costs.
The engineering side of the business utilised informal
project management; the rest did not. There were no
0263-7863/01/$20.00 # 2001 Elsevier Science Ltd and IPMA. All rights reserved.
PII: S0263-7863(00)00034-X
50
P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
formal project teams and the deliverables from the work
were not always clear. The direction of process work
was largely ad hoc, as the leader of the work usually had
to continue their other duties alongside the changed
work. Such `Project Managers' rarely had training or a
¯air for directing project work. Not surprisingly, many
`projects' that incorporated business change failed to
deliver the bene®ts that were expected.
2.1. The development of a project ethos
In the early 1990s, the Utility was advised to undertake
large business changes by using speci®c programmes, and
to use projects under that programme structure. This
improved the control and overall direction of the business
changes, and more bene®ts were realised than was previously the case.
However, following the failure of a major business
programme failed in the mid-1990s, senior management
decided that programme management in the Utility
needed to be more `professional'. The aim was to ensure
that future programmes had the best sta available and
that training in Programme Management for senior sta
was provided. As part of this training, it was realised that
the Project Manager level of sta in the programmes
were key to the success of each project and therefore the
programme, and that this level of sta must also receive
formal training and quali®cations in Project Management.
The project management method, Projects in Controlled Environments 2 (Prince2) [3] was chosen, as it was
a generic project management method. Nearly 100 sta
were trained in the method, including members of the
Information Systems Division (ISD) Programme Services
section, which also recruited experienced programme
managers. The section manages some business change
programmes and oers advice to the rest of the company.
risk is acceptable, and if not, what actions can be
undertaken to make the risk acceptable.
The options of which action can be taken to make the
risk acceptable are:
. prevention, where countermeasures are put in
place to stop the threat or problem from arising,
or to prevent it from having any impact on the
project or business;
. reduction, where actions either reduce the likelihood of the risk developing, or limit the impact
to acceptable levels;
. transfer of the risk to a third party, for example by
taking out an insurance policy or a penalty clause;
and
. contingency, where actions are planned and organised to come into force as and when the risk
occurs.
Risk management is the second phase of the Prince2
management of risk framework. Its objective is to integrate the risks identi®ed in the risk analysis stage into
the project management. This is achieved through:
planning the countermeasures identi®ed in the risk analysis stage; identifying and allocating resources to carry
out the risk avoidance work; monitoring against the
plans that the actions are having the desired eect on
the risks; and controlling to ensure that the planned
events actually happen.
Other methods identi®ed also seem to follow the same
broad approach to risk management. Page [4] writes
that risk management should be broken into four
stages, that of comprehensive risk identi®cation of all
sources of risk, objective analysis of their signi®cance,
planning appropriate responses and the management of
those responses.
3. Risk management in projects
3.1. Risk identi®cation
In Prince2, risk is categorised into two types. Project
risk is de®ned as threats directly to the project, such as
supplier issues, organisational issues and resource
issues. Business risks are those that may aect the
delivery of the bene®ts to be gained from the project, for
example the risk that the business case will become
invalid due to changes in the market in which the company operates.
The process of managing risk begins with risk analysis, which is designed to pick up and gain detail on both
business and project risks, and consists of:
Risk identi®cation appears to be the least mentioned of
the risk techniques. It is, however, the most important
stage of risk analysis, as no work can be done on risks
that no one has discovered. Risk identi®cation requires
divergent thinking on the part of the project manager, to
identify potential risks at each stage of the project, but
this investigation is easier if guidelines are set.
Chapman and Ward [5] state that risk identi®cation is
both important and dicult, and that it calls for `some
creativity and imagination'. The identi®cation process
can be made more ecient if the skills and experience of
others can be harnessed. They recommend directed
thinking approaches, such as interviews of individuals
or groups, brainstorming or using checklists. Overall,
they attempt to put more detail into the method of
identifying risks. However, unless it is carefully examined
. risk identi®cation to determine potential risks;
. risk estimation to determine the importance of
each risk, based on its likelihood and impact; and
. risk evaluation, which decides whether the level of
P. Elkington, C. Smallman / International Journal of Project Management 20 (2002) 49±57
51
and broken down as above, it appears complex, and this
is its main failing.
The CCTA's [6] approach is a more detailed version
of that in Prince2. However, the process is, again, very
technical and structured: set the proper context and
perspective for the analysis; gather information on risks;
classify risks based on their causes.
The CCTA [6] approach is procedurally precise, and
answers the question `how do I identify risk?' However, it
does not necessarily oer users the right information or
the whole picture, and does not mention the imagination
or creativity necessary for eective risk identi®cation.
The process directs the project manager to use product
or activity-based planning, and then to look at the risk
of each product. The weakness is that risks may not be
based on products of the project.
Chapman and Ward [5] note that project managers
should also be aware of `positive' risks. Most experienced
project managers focus on the risk of late delivery,
overspend and poor quality in the project products, but
early delivery can also cause signi®cant problems. Even
products that are not on the critical path for the project
can cause problems if they are delivered early.
The CCTA [6] take the process further by recommending that the estimation phase is an iterative one,
and that the estimates should be clari®ed and improved
on an ongoing basis.
Again, Chapman and Ward [5] appear to have
thought through the mechanics of the assessment of the
likelihood of a risk occurring. However, as with risk
identi®cation his process is highly technical. Chapman
and Ward [5] suggest the use of incremental scenario
planning to determine both the likelihood and impact of
a risk. This means determining the maximum and minimum impacts of the risk, and then using incremental
steps to decide the impact of scenarios between the
maximum and minimum impact. The same approach is
then used to assign a probability to each scenario. The
approach also encourages several passes of each stage,
to re®ne the thought process. Chapman and Ward [5]
describe methods of probability assessment that will
improve the estimates made above, these include fractile, relative likelihood and probability distribution
functions.
3.2. Risk estimation
The CCTA [6] take a three-step approach to the evaluation stage of the risk management process:
Risk estimation is the Prince2 term for determining
how important the risk is, (potential impact), and what
the likelihood is of the risk occurring. The CCTA [6]
further de®ne the estimation process to be the likelihood, consequence and timing of the risk.
It appears that writers do not want to approach this part
of risk management. Dembo and Freeman [7] discuss the
philosophy of risks and on how to decide if a risk is worth
taking, but always seems to start by stating a probability
associated with a risk. They have the `luxury' of operating
in the world of ®nancial risk, where vast statistical
databases instruct probability. Project managers operating
outside of ®nance, facing operational risks, constantly try
to decide the chances of an identi®ed risk occurring. Some
use historical project data, and others use unwritten
past experience, but in many cases, the likelihood of a
risk occurring is derived by means of an educated guess.
Prince2 oers no advice to project managers on risk
estimation. However, it appears to recognise the diculty project managers face, as it recommends that the
risk register only has the three bands of high, medium
and low likelihood of occurrence, and does not expect
an accurate appraisal. The area of assessing the impact
of the risk on the project has even less advice, but simply
identi®es that some measure should be made.
The CCTA [6] advise that the project manager should
assess the qualitative likelihood of the risk occurring,
but does not oer up any methods by which to do it.
The `consequences' section does, however, introduce the
notions of time-delimited risks and time-expiring risks.
3.3. Risk evaluation
1. Assess the risks against risk indicators and determine the acceptability of each. This step, unlike
Prince2, suggests that risks may be `grouped' and
have their impact assessed together.
2. Generate alternative paths of action for risks that
do not meet the acceptability criteria. This step is
eectively the ®rst stage of the Prince2 method of
determining what action to take with the risk. This
step also recommends that the project manager
should return to the classify risk and cause step if
necessary for further information.
3. Sort risks into ®nal order of priority and crossreference to the identi®ed risk reduction options.
The ®nal step sets the actions that the project
manager will take to manage the risk.
Chapman and Ward [5] view the evaluation stage as
central in the risk management process. Throughout,
they emphasise that the stages should be used, as
necessary, to improve the information on a risk and its
management. Looping back into other phases of the
analysis will be necessary to clarify and reassess the
risks. This approach is more detailed than the Prince2
or the CCTA [6] methods, and identi®es four speci®c
steps to the evaluation process:
1. Select an appropriate subset of risks. This is where
risks are grouped into subsets that...
Purchase answer to see full
attachment