Chapter 2

Process improvement
concepts
2.1 Introduction
Many publications report on the success of management systems such as
lean production and six sigma. Lean production has evolved into a widely
accepted system, or philosophy, for the management and improvement of
production systems (Holweg, 2007). The overlap or relation between lean
production and other systems, such as agile manufacturing (Narasimhan
et al., 2006) and six sigma (Linderman et al., 2003; Sulek et al., 2006) is
also well described. Some authors (for example Shah and Ward, 2003) em-
phasized the individual tools and techniques normally regarded as elements
of lean production. In particular just-in-time/continuous ow production,
lot size reduction, pull systems/kanban and quick changeover techniques are
frequently reported as key elements (Shah and Ward, 2003). Other authors
emphasize that lean production should be seen more as a holistic philosophy,
a set of values, and that many of the tools and techniques are interdependent
(Herron and Braiden, 2006a,b).
In nearly all publications relating to lean production, examples from
high volume industries are used. Indeed, most of the tools and techniques
(continuous ow, lot size reductions, just-in-time/pull/kanban) are mostly
applicable for high volume production. To date, surprisingly little research
is available on the possibilities for implementing lean production and other
systems in engineer-to-order industries.
In principle, the best practices of lean production are so well described
that they can be used by companies as a practical reference. Many companies
and consultants use these descriptions, sometimes described in progressing
stages, in order to aid improvement (Herron and Braiden, 2006a,b). It fol-
17
Process improvement concepts
lows that for companies which are not in the typical high-volume production
industries in which the best practices were developed, alternatives or amend-
ments to the reference frameworks are required. This is the case for the
engineer-to-order industry.
Engineer-to-order companies have an order penetration point that is
situated before the start of the engineering process (Olhager, 2003). Work
activities in this type of rm are often so untypical that the existing tools for
preserving and improving processes do not work very well. Many engineer-to-
order organizations often spend a great deal of eort implementing currently
popular concepts and programs, without obtaining the desired results. The
main contribution of this chapter to the existing literature is twofold: (1) it
provides an overview of the factors that obstruct the eective use of process
management tools in engineer-to-order; and (2) it presents a concept that
could deal with some of these factors- the idea of process maturity as a
roadmap towards a state of continuous measurement and improvement.
An important framework for the stepwise improvement of engineer-
to-order processes is the Capability Maturity Model (CMM), developed by
Carnegie Mellon Universitys Software Engineering Institute in the late 1980s
(e.g. see Humphrey, 1988). Although this framework
1
was originally created
for the software engineering industry, eorts have been made to generalize it
to areas such as new product development (Dooley et al., 2001) and construc-
tion (Sarshar et al., 2000). Although a more generic method was introduced
in 2002 (the Capability Maturity Model Integrated, CMMI), the central idea
of a maturity model as a basis for process capability improvement beyond
software engineering has not been widespread since. In this chapter we will
describe some typical obstacles for engineer-to-order rms in introducing and
eectively using process improvement concepts, and postulate what could be
done to overcome these problems using the concept of process maturity. We
furthermore map CMMI onto typical engineer-to-order processes to identify
the areas in which engineer-to-order rms can apply CMMI readily, and the
areas within CMMI that need extensions.
1
One can argue about whether CMM is truly a model or should be considered a frame-
work. When applying strict denitions of a model as being an abstracted or simplied
version of reality, and a framework as a set of rules and guidelines that can be applied to
reality, CMM is a framework. However, CMM contains several implicit model-like struc-
tures. The distinction, therefore, is rather trivial. For this reason we treat model and
framework as interchangeable terms.
18
2.2 Process management literature
A process can be dened as a time-dependent sequence of events governed
by a process framework (Mackenzie, 2000, p.110). Process management,
then, can be described as follows: process management, based on a view of
an organization as a system of interlinked processes, involves concerted eorts
to map, improve, and adhere to organizational processes (Benner and Tush-
man, 2003, p.238). Process management practices have become core elements
of well-known programs and concepts such as the International Organization
for Standardizations Series 9000 program, total quality management, busi-
ness process reengineering, six sigma (Benner and Tushman, 2003), lean and
agile manufacturing (Narasimhan et al., 2006). Dierences between these
programs and concepts exist, but it is still unclear where these dierences lie
exactly and at what level. In an attempt to conceptualize lean production,
Shah and Ward (2003) distinguished four bundles of practices: just-in-time
manufacturing, total quality management, total productive maintenance and
human resource management. While this study might suggest a hierarchical
structure (in which total quality management is a branch of lean production),
Andersson et al. (2006) placed the concepts at the same level having compa-
rable origins, methodologies, tools and eects. In another study, Narasimhan
et al. (2006) attempted to disentangle lean and agile manufacturing, stating
that the pursuit of agility might presume leanness. One of the best-known
dimensions from which process management concepts and programs can be
compared is the one between stepwise and radical improvement. Whereas
business process reengineering is often positioned on the radical side of the
continuum, the others lie more in the middle and towards the stepwise side.
In summary, we can argue that although these concepts and programs seem
to be benecial to organizations, clear distinctions between them are hard
to make. They can, however, be compared by means of various dimensions
(i.e., use of practices, hierarchical structures, sequence of implementation and
degree of scope change).
Besides comparing these concepts and programs, it is useful to identify
the underlying assumptions. First of all, they all focus upon processes. Sec-
ond, they all serve multiple purposes such as increasing customer value and
reducing cost, waste and cumulative lead time. They all have rationaliza-
tion and the elimination of variance as a common feature and require that
an organization be aware of the state and outcome of the process (Benner
and Tushman, 2003). For such concepts or programs to work, a certain de-
gree of repeatability and stability is required. If ones aim is to measure and
improve a process, one has to be able to predict (that is, at least to a rea-
sonable extent) the behavior and interrelationships of that process. For the
19
Process improvement concepts
engineer-to-order industry, as we will demonstrate, this is a great challenge.
Clear descriptions of engineer-to-order organizations and processes can
be found in Hicks et al. (2000a), Hicks et al. (2000b) and Cameron and
Braiden (2004). Hicks et al. (2000a) focused on capital goods goods rms
that produce on a make-to-order or engineer-to-order basis. They made a dis-
tinction between physical (e.g. manufacturing, assembly, construction), non-
physical (e.g. tendering, engineering, project management) and support pro-
cesses (quality, nance and accouting, human resource management). They
argued that the processes make-to-order and engineer-to-order rms execute
are similar at a high level, but dier at more detailed levels. For example,
engineering in make-to-order settings is mostly done in product development
projects, whereas engineering in engineer-to-order is often done for specic
customer orders. Examples of engineer-to-order companies are manufactur-
ers of gas production plants, oil platforms and lithography systems. In addi-
tion, many construction projects can be labeled engineer-to-order. Common
engineer-to-order company characteristics that can be found in these publi-
cations are:
Output is highly customized to meet individual requirements;
Output is low in volume and consists of a wide range of technologies
that are often very advanced and at the boundary of knowledge;
Processes are highly complex and dynamic;
Organization is often project orientated;
Supply networks are very much integrated and suppliers are powerful.
Today it is clear that existing concepts and programs should be assessed
carefully to understand the usefulness for the various types of rms. Muk-
herjee et al. (1998), for example, challenged the assumption made by many
researchers that process improvement practices are universally valid. Many
publications can be found that underline the poor applicability of the tradi-
tional process management tools for engineer-to-order companies. Shah and
Ward (2003) demonstrated that just-in-time/continuous ow, lot size reduc-
tion, pull systems/kanban and cellular manufacturing are techniques that
most authors see as typical elements of lean production, while, for example,
management of product information across its life cycle is not listed. Other
examples:
Cameron and Braiden (2004) identied several elements that prohibit
companies in the engineer-to-order sector from successfully adopting
business process reengineering. One of these elements is poor control
20
over the supply chain network outside the organization. Since engineer-
to-order work is hardly ever a stand-alone activity, suppliers and part-
ners play important roles. Control over these suppliers and partners,
however, turns out to be often so limited that business process engi-
neering can only be applied to particular processes at the business-unit
level, while a successful business process reengineering project would
require radical change in the entire supply chain;
Wortmann (1995) indicated that although the timing and quantity of
demand in engineer-to-order work may be estimated to some extent,
the precise nature of the product and its routing through the organiza-
tion cannot. For organizations this means that no consensus can exist
on what constitutes the process. Traditional concepts and programs,
however, are modeled after the high volume production control model
of traditional mass industries, such as the automotive industry (Winch,
2003). They all assume a medium to high level of predictability in the
ow and rhythm of the production process, so that processes can be
tightly coupled using coordination mechanisms such as standardization
of output and work. One major alternative proposed is that of Lean
Construction. Lean construction (e.g. see Serpell and Alarcon, 1998;
Koskela and Ballard, 2006; Salem et al., 2006) was developed in the
early 1990s as an alternative to the traditional conversion types of
process views (i.e., relatively simple input-output schemes). Being un-
satised with the ecacy of production control and improvement prin-
ciples (originally designed for mass industries), the lean construction
initiative developed guidelines which described construction projects
as value networks with a ow of activities.
The fact that every engineer-to-order project is relatively unique does
not necessarily imply that learning is impossible. As demonstrated by Brady
and Davies (2004) and Engwall (2003), most projects start o from some
level of experience obtained in comparable projects. Furthermore, a current
trend in engineer-to-order industry is the lifecycle view of processes. In many
cases engineer-to-order processes are considered as part of a lifecycle, with
a high degree of integration between up- and downstream processes such as
design, maintenance and operations. In this view, decisions are made in a
multidisciplinary way, covering all parts of the lifecycle, whereas in the tradi-
tional approach design decisions did not take the latter phases into account.
Learning in engineer-to-order companies thus involves the identication and
application of knowledge and experience obtained in similar settings as well
as learning across process boundaries. In the rst case, project closeouts
could be used as a reference manual for future projects, whereas in the sec-
21
Process improvement concepts
ond case cross-boundary learning is the translation of downstream data and
information into knowledge upstream, or vice-versa. Such learning processes
are found to contribute positively to process capability (Ravichandran and
Rai, 2003). A major trend in engineer-to-order industry is the integration
of design and production work with maintenance activities. Maintenance
data could thus be used to improve designs and the way the product is built.
Today many advanced maintenance techniques such as condition-based main-
tenance provide the organization with this input. Translating this input into
action, however, is still a big challenge for many engineer-to-order companies.
2.3 An example of industrial process management
questions
In order to clarify some of the statements made above we will consider the
case of Stork GLT, an engineer-to-order rm that engineers, constructs and
maintains gas production plants for a major oil and gas production company.
The rst author had the unique opportunity of conducting in-depth case
research at the organization.
Stork GLT is a joint venture with ve partners (engineering, construc-
tion and maintenance, instrumentation, compression and electric motors for
compressors). It has been awarded a long-life contract for the renovation and
maintenance of 22 gas production plants for a large gas eld in the Nether-
lands. The renovation part is executed in batches of two to four production
locations. Activities include basic design, detail design, procurement, con-
struction and subsequently maintenance. After handover of the plant to the
customer, the expected time the plant will be operated is approximately
twenty-ve years. When the gas reservoir is depleted, plants will enter end of
life processes which include the decommissioning of the plant. Early design
decisions will take the operations and end-of-life phases into account.
The largest part of the projects characteristics is typical for engineer-to-
order rms. Output is delivered in very small quantities and every subproject
has some unique and some common properties. Processes are therefore dy-
namic and complex. Stork GLTs project organization is deeply integrated
with the customer. This leads to ecient and eective communication struc-
tures and decision-making processes.
The degree of partnering and subcontracting is very large. The gas plant
is a conguration of many technologically advanced components. Design, ma-
nufacturing and assembly of the advanced automation and instrumentation
technology are done by one of the partners. The 23 megawatt compressor
and the electric motor are also designed, manufactured and assembled by
partners in the joint venture. These technologies can clearly be considered
22
Health, safety, environment
and well-being (HSEW)
Logistics
Configuration & change
Information management
Planning
Finance, costing
Quality assurance & control
Human resources
Engineering
Develop requirements
Design development
& delivery
Requisitioning
Procurement
Supplier selection
Purchasing
Expediting
Construction
Work preparation
Subcontract man.
Construction execution
Pre-commissioning
Commissioning
Comm. preparation
Comm. execution
Post-comm. support
Maintenance
Plant monitoring
Maint. engineering
Work preparation
Maint. execution
PRIMARY PROCESSES
SUPPORT PROCESSES
Sales and Marketing,
Tendering
Stork GLTs scope
management
Operations,
End-of-life processes
Figure 2.1. Case company primary and support processes.
as key-technologies in the renovation project. Production of other package
goods, as these large technologies are called within the project, is also out-
sourced for a large part. Furthermore, long-term relationships with suppliers
are a major aspect of procurement strategy. Much of the construction work
is sub-contracted. For this reason, subcontract-management becomes a vital
coordination activity.
Engineering changes and modications are major sources of process
disturbance during engineering, construction and maintenance/operations
phases. The sources of these changes can arise from: suppliers, customers,
lessons learned from earlier engineering, construction, maintenance and oper-
ations work. Design challenges might also be detected in a later stage, which
then need to be corrected. Due to the repeatability within the project, rou-
tines and formalization are major aspects of the work. Engineering changes
and modications are a major source of variation within nearly every process
within the project organization. They therefore disturb the regular pro-
cess ow within the organization. Company processes are depicted in gure
2.1. The gure includes the parts of the process that are within the project
organizations control, and the parts that are not (operations and decom-
missioning). Marketing & sales and tendering are depicted because these
processes are important in every project. At the case study company these
processes are inactive since the contract covers a long period and no new
sales have to be made.
During the case studies, some process improvement challenges were
identied. These challenges were related to the nature of the engineer-to-
order rm. In particular, the day-to-day measurement of performance and
process improvement opportunities (kaizen) appeared to be dicult. Several
questions arose:
23
Process improvement concepts
How can the core capabilities of the company be measured and im-
proved?
To what extent does lean production apply to this organization?
A lot of data, information and knowledge are available in the organi-
zation. How can we capture this, make it explicit and reintegrate this
into our processes and designs? Should our aim be to standardize our
processes and plants or should we aim to continuously improve them?
2.4 Process maturity
2.4.1 Process maturity models
Inspired by the problems and challenges illustrated above, a research project
is currently being undertaken at the University of Groningen on process man-
agement for engineer-to-order companies. One of the aims within the research
project is to identify (and, if necessary, modify) process improvement models
and frameworks that t the needs and characteristics of engineer-to-order
rms. One of the preliminary outcomes of the research project is the iden-
tication of the concept of process maturity (for example the Capability
Maturity Model Integrated-CMMI (SEI, 2002)) as one of the possible key
elements of engineer-to-order process management. In this section we will
explain what process maturity means and we will discuss CMMI. In the
subsequent sections, we will discuss a particular application of the maturity
concept.
Process maturity is the extent to which a certain process is able to meet
its targeted goals. The best-known framework for the achievement of pro-
cess maturity is CMM. CMM was developed by the Software Engineering
Institute at Carnegie Mellon University in the late 1980s. One of its original
aims was to create a way of evaluating the software capability of U.S. federal
governments. In 2002, the Software Engineering Institute introduced a re-
vised version of CMM, called CMMI. CMMI is the result of the integration
of three models (Ahern et al., 2004): the CMM for software, a framework
for systems engineering, and a maturity framework for integrated product
and process development. The framework has been claimed to be capable of
guiding process improvement for projects other than software engineering. In
the following sections, we will discuss CMMI. The basic structure of CMMI is
as follows. In the framework, twenty-ve process areas can be distinguished.
Each process area is attached to one of the four maturity levels (i.e., level
two to level ve; the rst level contains no process areas). Process areas
are dened as follows: A process area is a cluster of related practices in an
24
area that, when performed collectively, satisfy a set of goals considered im-
portant for making signicant improvement in that area (SEI, 2002, p.17).
Maturity levels are called (in order of maturity): initial, managed, dened,
quantitatively managed and optimizing
2
. Process maturity, therefore, can
be dened as the degree to which a process is explicitly managed, dened,
quantitatively managed and optimized (e.g., see Dooley et al., 2001; Fallah,
1997). Figure 2.2 gives a graphical overview. Short descriptions of maturity
levels are
3
:
1. At level 1, the initial level, the focus is on competent people and hero-
ics, meaning that success within projects is dependent on the eorts
of talented or risk-taking individuals. Processes are dicult to predict,
poorly controlled and reactive;
2. At level 2, the managed level, project management is the most impor-
tant set of process areas that need to be established. Processes are
characterized for projects and are often reactive;
3. At level 3, the dened level, processes are standardized based on several
process management process areas. Advanced engineering process areas
are implemented to ensure high quality output that meets customer
needs. Processes are shared at the organization level and are proactive.
Substantial process improvements can be made;
4. At level 4, the quantitatively managed level, quantitative measures of
processes are available and processes are proactively controlled;
5. At level 5, the optimizing level, substantial process improvements can
be made based on a deep understanding of the behavior of processes.
Two conditions need to be met in order for an organization to be at level 2
or higher. First of all, as discussed earlier, the specic goals attached to each
process area need to be achieved. For example, one of the specic goals of the
level 3 process area requirements development is stakeholder needs, expec-
tations, constraints and interfaces are collected and translated into customer
requirements (SEI, 2002, p.209). Second of all, generic goals are attached
to each maturity level to guide the institutionalization process of a particular
2
The Software Engineering Institute has actually developed two representations. In
the staged representation, the process areas are organized around maturity levels. An
organization moves to a higher maturity level if all of the process areas are meeting its
specic and generic goals. In the continuous representation, an organization is free to
choose what process areas to focus on. In this chapter we focus solely on the staged
version.
3
The following description is based on Ahern et al. (2004)
25
Process improvement concepts
Disciplined
Standard,
consistent
Predictable
Continuously
improving
Optimizing - 5
Org. innovation & deployment
Causal analysis & resolution
Quantitatively managed - 4
Organizational process
performance
Quantitative project management
Defined - 3
Requirements development
Technical solution
Product integration
Verification
Validation
Organization process focus
Organizational process definition
Organizational training
Integrated project management
Risk management
Integrated teaming
Integrated supplier management
Decision analysis & resolution
Org. environment for integration
Managed - 2
Requirements management
Project planning
Project monitoring & control
Supplier agreement management
Measurement & analysis
Process & product quality
assurance
Configuration management
Initial - 1
Figure 2.2. CMMI process maturity framework (partly based on Paulk et al. (1993)).
26
process area from one maturity level to the other
4
. Institutionalization is the
ingrained way of doing business that an organization follows routinely as part
of its corporate culture (Ahern et al., 2004, p.62). For example, the generic
goal of the level 2 process areas is to institutionalize a managed process.
The achievement of generic goals is guided by generic process descriptions or
practices. These practices are organized around the basic components of an
entire implementation process:
Commitment to perform;
Ability to perform;
Directing implementation;
Verifying implementation.
The appendix gives an overview of maturity levels, process areas and specic
practices. For more detailed information, full framework descriptions can be
downloaded from the Software Engineering Institute website
5
.
The mechanisms within the framework and the performance eects can
be explained in dierent ways. The basic idea behind the maturity levels
is that when processes become standardized, they can be controlled because
variation is recognized. The higher the maturity level, the better it is un-
derstood and the more the measurements of process behavior make sense.
Signicant improvement of processes can only be achieved if processes are
measured quantitatively.
The signicant benets of process maturity models have been described
in several publications. Generally, process maturity models lead to increased
quality, shorter development cycles, increased eciency and exibility (e.g.
Dooley et al., 2001; Harter et al., 2000; Jiang et al., 2004; Krishnan et al.,
2000). Several other elds have adopted the maturity approach to guide the
road to improvement, such as in the eld of project management (Grant and
Pennypacker, 2006).
2.4.2 Process maturity models for ETO rms
CMMI is one of the few frameworks that are able to deal well with the specic
nature of engineer-to-order projects. As mentioned above, CMM was able to
guide software engineering rms into a state of continuous improvement, in
which high quality products were delivered at low cost and on time. CMMI
4
As a matter of fact, only levels 2 and 3 contain generic goals and practices. It is
assumed in the framework that institutionalization of levels 4 and 5 process areas is guided
by the specic goals and practices of those process areas.
5
see http://www.sei.cmu.edu
27
Process improvement concepts
usage was promoted several years ago (e.g. see Nambisan and Wilemon,
2000). Aside from some applications of CMMI in new product development
and the use of the maturity concept in construction, however, few applica-
tions outside the software engineering arena are known. A process maturity
framework such as CMMI, however, could be very benecial for engineer-to-
order organizations for a number of reasons:
Maturity frameworks reduce task uncertainty and help manage complex
interactions among actors, tasks and processes. We mentioned that
these complex interactions are a central element in engineer-to-order
work. Through the structuring of functional and cross-functional pro-
cesses, interfaces are known to major actors such as engineers, buyers,
work-package coordinators and construction workers. This eventually
leads to a reduction in defects and rework;
Maturity frameworks provide substantial guidance for the integration
of process and product experience back into design and processes. In
particular the process management process areas oer support for this.
Knowledge reuse is important in this industry and the more explicit
reuse practices of CMMI can complement the softer and more intangible
practice of social-knowledge networks, as is common in the architecture,
engineering and construction industry (Demian and Fruchter, 2006);
Supplier integration can be enhanced by the process areas of supplier
agreement management (level 2) and integrated supplier management
(level 3). These process areas stress formal relationships, yet relation-
ships for the long term based on negotiation and coordination of mutual
concern.
Besides these specic reasons, some generic reasons for using maturity frame-
works could be cited as well. CMMI provides the organization with an au-
ditable process (Fallah, 1997). Furthermore, we believe that these maturity
stages can be viewed as parts of an implementation ladder. The staged
approach therefore facilitates a relatively easy transition from chaos to struc-
ture. It makes sense to dene a process at a project level, then carry it to
the organization level, measure it and improve it accordingly. It also makes
less sense to do it the other way around.
2.4.3 Mapping CMMI to ETO lifecycle processes
Sections 2.4.1 and 2.4.2 clearly describe the potential benets of CMMI for
ETO rms. In this section we describe the details of CMMI to uncover where
engineer-to-order process management can directly benet from CMMI and
28
where CMMI needs enhancement. We do so by means of a gap analysis.
This gap analysis is a detailed mapping of company processes with best prac-
tice reference frameworks. Any reference framework should essentially cover
the whole range of business processes of the rm. For engineer-to-order rms
these consist of the primary processes engineering, procurement, construc-
tion, commissioning and maintenance. Also the support processes health,
safety, environment and well-being (HSEW), planning, logistics, nance, cost
and acquisition control, conguration and change management, quality assur-
ance and control, information management/information technology (IM/IT)
and human resources should be taken into account. More detailed process
descriptions can be found in Veldman and Klingenberg (2006). The pro-
cesses shown in that paper share a great deal of overlap with the framework
presented by Hicks et al. (2000a). Admittedly, the processes given are a fo-
cused on construction and maintenance organizations, in which (for example)
HSEW is of greater importance. We also do not include the primary stages
(marketing and sales, tendering) in the framework. Furthermore the manu-
facturing and assembly undertaken by partners are not included, since they
are not within the scope of the organization. We consider that the frame-
work is universal and can be used outside the construction and maintenance
setting. In order to avoid an exercise that is too theoretical, Stork GLT (see
section 2.3) is used as a reference case. The processes were shown earlier in
gure 2.1.
Mapping principles
The following method was used. First we obtained detailed descriptions
of engineer-to-order processes, and veried these with experts from Stork
GLT. Then we obtained the denitions of the specic goals of CMMI. Each
engineer-to-order process was mapped against the specic goals. We thereby
employed the following scale: (1) no coverage of the process by CMMI, (2)
weak coverage, (3) moderate coverage, (4) good coverage, (5) full coverage.
The amount of coverage is related to the extent to which the typical activi-
ties within a process are supported by a specic goal. Thereby we not only
looked at the degree to which processes and activities are literally mentioned,
but also at whether the specic goals could potentially be supportive to the
engineer-to-order process. Since specic practices are not described as re-
quired materials in the CMMI documentation and for the ease of mapping,
we did not focus on specic practices.
Mapping results
The results of the mapping process are given in table 2.1. We found that the
strongest coverage of CMMI is given for the processes of engineering, procure-
29
Process improvement concepts
ment, planning and quality assurance and control. This is not surprising since
these are the typical processes within software engineering projects. Mod-
erate coverage is provided in the areas of commissioning, nance, cost and
acquisition control and conguration and change management. These pro-
cesses are also very standard in engineering-oriented projects (e.g. product
development), but the dierences between construction projects and other
development projects are more visible. The commissioning process, for ex-
ample, consists of careful testing of a complex facility prior to and after gas
in. These activities contain a high level of plant knowledge, support and ma-
terial ows. The validation process area of CMMI does include testing of the
output in its real-life setting, but the practices given for these activities are
simply too general to support typical engineer-to-order processes. Further
developments in the process areas scored moderate are thus needed. The
CMMI process areas linked to these activities can provide a good starting
point for this development.
30
T
a
b
l
e
2
.
1
.
C
M
M
I
p
r
o
c
e
s
s
a
r
e
a
s
.
E
T
O
p
r
o
c
e
s
s
M
a
i
n
a
c
t
i
v
i
t
i
e
s
w
i
t
h
i
n
p
r
o
c
e
s
s
C
M
M
I
p
r
o
c
e
s
s
a
r
e
a
c
o
v
e
r
a
g
e
o
n
t
h
e
E
T
O
a
c
-
t
i
v
i
t
y
l
e
v
e
l
P
r
o
c
e
s
s
a
r
e
a
s
p
e
-
c
i

c
g
o
a
l
a
S
c
o
r
e
C
o
n
c
l
u
s
i
o
n
(
c
o
v
e
r
a
g
e
)
E
n
g
i
n
e
e
r
i
n
g
D
e
v
e
l
o
p
r
e
q
u
i
r
e
m
e
n
t
s
R
e
q
u
i
r
e
m
e
n
t
s
m
a
n
a
g
e
m
e
n
t
1
5
S
t
r
o
n
g
R
e
q
u
i
r
e
m
e
n
t
s
d
e
v
e
l
o
p
m
e
n
t
1

3
D
e
s
i
g
n
d
e
v
e
l
o
p
m
e
n
t
T
e
c
h
n
i
c
a
l
s
o
l
u
t
i
o
n
1

3
5
a
n
d
d
e
l
i
v
e
r
y
P
r
o
d
u
c
t
i
n
t
e
g
r
a
t
i
o
n
1

2
V
e
r
i

c
a
t
i
o
n
1

3
R
e
q
u
i
s
i
t
i
o
n
i
n
g
R
e
q
u
i
r
e
m
e
n
t
s
d
e
v
e
l
o
p
m
e
n
t
2

3
5
P
r
o
c
u
r
e
m
e
n
t
S
u
p
p
l
i
e
r
s
e
l
e
c
t
i
o
n
S
u
p
p
l
i
e
r
a
g
r
e
e
m
e
n
t
m
a
n
a
g
e
m
e
n
t
1
5
S
t
r
o
n
g
T
e
c
h
n
i
c
a
l
s
o
l
u
t
i
o
n
2
I
n
t
e
g
r
a
t
e
d
s
u
p
p
l
i
e
r
m
a
n
a
g
e
m
e
n
t
1
P
u
r
c
h
a
s
i
n
g
S
u
p
p
l
i
e
r
a
g
r
e
e
m
e
n
t
m
a
n
a
g
e
m
e
n
t
2
5
I
n
t
e
g
r
a
t
e
d
p
r
o
j
e
c
t
m
a
n
a
g
e
m
e
n
t
2
E
x
p
e
d
i
t
i
n
g
P
r
o
j
e
c
t
m
o
n
i
t
o
r
i
n
g
&
c
o
n
t
r
o
l
1

2
5
S
u
p
p
l
i
e
r
a
g
r
e
e
m
e
n
t
m
a
n
a
g
e
m
e
n
t
2
V
e
r
i

c
a
t
i
o
n
1
,
3
C
o
n
s
t
r
u
c
t
i
o
n
W
o
r
k
p
r
e
p
a
r
a
t
i
o
n
P
r
o
j
e
c
t
p
l
a
n
n
i
n
g
1
2
W
e
a
k
S
u
b
-
c
o
n
t
r
a
c
t
P
r
o
j
e
c
t
m
o
n
i
t
o
r
i
n
g
&
c
o
n
t
r
o
l
1
2
m
a
n
a
g
e
m
e
n
t
S
u
p
p
l
i
e
r
a
g
r
e
e
m
e
n
t
m
a
n
a
g
e
m
e
n
t
2
I
n
t
e
g
r
a
t
e
d
s
u
p
p
l
i
e
r
m
a
n
a
g
e
m
e
n
t
2
C
o
n
s
t
r
u
c
t
i
o
n
e
x
e
c
u
t
i
o
n
P
r
o
d
u
c
t
i
n
t
e
g
r
a
t
i
o
n
1

3
1
P
r
e
-
c
o
m
m
i
s
s
i
o
n
i
n
g
P
r
o
d
u
c
t
i
n
t
e
g
r
a
t
i
o
n
3
3
V
e
r
i

c
a
t
i
o
n
1

3
C
o
m
m
i
s
s
i
o
n
i
n
g
C
o
m
m
i
s
s
i
o
n
i
n
g
p
r
e
p
a
r
a
t
i
o
n
V
a
l
i
d
a
t
i
o
n
1
3
M
o
d
e
r
a
t
e
C
o
m
m
i
s
s
i
o
n
i
n
g
e
x
e
c
u
t
i
o
n
V
a
l
i
d
a
t
i
o
n
2
3
P
o
s
t
-
c
o
m
m
i
s
s
i
o
n
i
n
g
s
u
p
p
o
r
t
N
/
A
N
/
A
N
/
A
M
a
i
n
t
e
n
a
n
c
e
P
l
a
n
t
m
o
n
i
t
o
r
i
n
g
M
e
a
s
u
r
e
m
e
n
t
&
a
n
a
l
y
s
i
s
1

2
1
W
e
a
k
M
a
i
n
t
e
n
a
n
c
e
e
n
g
i
n
e
e
r
i
n
g
S
e
e

e
n
g
i
n
e
e
r
i
n
g

5
W
o
r
k
p
r
e
p
a
r
a
t
i
o
n
P
r
o
j
e
c
t
p
l
a
n
n
i
n
g
1
2
M
a
i
n
t
e
n
a
n
c
e
e
x
e
c
u
t
i
o
n
P
r
o
d
u
c
t
i
n
t
e
g
r
a
t
i
o
n
1

3
1
31
Process improvement concepts
T
a
b
l
e
2
.
1
.
C
M
M
I
p
r
o
c
e
s
s
a
r
e
a
s
(
c
o
n
t
i
n
u
e
d
)
.
E
T
O
p
r
o
c
e
s
s
M
a
i
n
a
c
t
i
v
i
t
i
e
s
w
i
t
h
i
n
p
r
o
c
e
s
s
C
M
M
I
p
r
o
c
e
s
s
a
r
e
a
c
o
v
e
r
a
g
e
o
n
t
h
e
E
T
O
a
c
-
t
i
v
i
t
y
l
e
v
e
l
P
r
o
c
e
s
s
a
r
e
a
s
p
e
-
c
i

c
g
o
a
l
a
S
c
o
r
e
C
o
n
c
l
u
s
i
o
n
(
c
o
v
e
r
a
g
e
)
H
S
E
W
H
S
E
W
m
a
n
a
g
e
m
e
n
t
s
y
s
t
e
m
d
e
l
i
v
e
r
y
N
/
A
N
/
A
N
/
A
W
e
a
k
R
i
s
k
&
t
r
e
n
d
a
n
a
l
y
s
e
s
P
r
o
j
e
c
t
p
l
a
n
n
i
n
g
2
2
P
r
o
j
e
c
t
m
o
n
i
t
o
r
i
n
g
&
c
o
n
t
r
o
l
1

2
R
i
s
k
m
a
n
a
g
e
m
e
n
t
1

3
C
a
u
s
a
l
a
n
a
l
y
s
i
s
&
r
e
s
o
l
u
t
i
o
n
1

2
H
S
E
W
s
i
t
e
s
u
p
e
r
v
i
s
i
o
n
N
/
A
N
/
A
N
/
A
P
l
a
n
n
i
n
g
P
l
a
n
n
i
n
g
P
r
o
j
e
c
t
p
l
a
n
n
i
n
g
1

3
5
S
t
r
o
n
g
M
o
n
i
t
o
r
i
n
g
a
n
d
c
o
n
t
r
o
l
P
r
o
j
e
c
t
m
o
n
i
t
o
r
i
n
g
&
c
o
n
t
r
o
l
1

2
5
M
e
a
s
u
r
e
m
e
n
t
&
a
n
a
l
y
s
i
s
1

2
L
o
g
i
s
t
i
c
s
W
a
r
e
h
o
u
s
i
n
g
N
/
A
N
/
A
N
/
A
W
e
a
k
T
r
a
n
s
p
o
r
t
a
t
i
o
n
P
r
o
d
u
c
t
i
n
t
e
g
r
a
t
i
o
n
3
3
S
p
a
r
e
p
a
r
t
s
m
a
n
a
g
e
m
e
n
t
N
/
A
N
/
A
N
/
A
F
i
n
a
n
c
e
,
c
o
s
t
&
a
c
q
u
i
s
i
t
i
o
n
c
o
n
t
r
o
l
F
o
r
e
c
a
s
t
i
n
g
P
r
o
j
e
c
t
p
l
a
n
n
i
n
g
1
,
3
3
M
o
d
e
r
a
t
e
P
r
o
j
e
c
t
m
o
n
i
t
o
r
i
n
g
&
c
o
n
t
r
o
l
1

2
M
e
a
s
u
r
e
m
e
n
t
&
a
n
a
l
y
s
i
s
1

2
B
i
l
l
i
n
g
&
c
l
o
s
e
o
u
t
N
/
A
N
/
A
N
/
A
S
c
o
p
e
c
o
n
t
r
o
l
P
r
o
j
e
c
t
p
l
a
n
n
i
n
g
1

2
3
C
o
n

g
u
r
a
t
i
o
n
&
c
h
a
n
g
e
m
g
m
t
.
E
n
g
i
n
e
e
r
i
n
g
c
h
a
n
g
e
m
a
n
a
g
e
m
e
n
t
R
e
q
u
i
r
e
m
e
n
t
s
m
a
n
a
g
e
m
e
n
t
1
3
M
o
d
e
r
a
t
e
C
o
n

g
u
r
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
2
M
o
d
i

c
a
t
i
o
n
c
o
n
t
r
o
l
R
e
q
u
i
r
e
m
e
n
t
s
m
a
n
a
g
e
m
e
n
t
1
3
C
o
n

g
u
r
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
2
C
o
n

g
u
r
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
C
o
n

g
u
r
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
1

3
3
Q
u
a
l
i
t
y
a
s
s
u
r
a
n
c
e
&
C
o
n
t
r
o
l
Q
u
a
l
i
t
y
a
s
s
u
r
a
n
c
e
M
e
a
s
u
r
e
m
e
n
t
&
a
n
a
l
y
s
i
s
1

2
5
S
t
r
o
n
g
P
r
o
c
e
s
s
&
p
r
o
d
u
c
t
q
u
a
l
i
t
y
a
s
s
u
r
a
n
c
e
1

2
O
r
g
a
n
i
z
a
t
i
o
n
a
l
p
r
o
c
e
s
s
f
o
c
u
s
1

2
O
r
g
a
n
i
z
a
t
i
o
n
a
l
p
r
o
c
e
s
s
d
e

n
i
t
i
o
n
1
O
r
g
a
n
i
z
a
t
i
o
n
a
l
p
r
o
c
e
s
s
p
e
r
f
o
r
m
a
n
c
e
1
O
r
g
a
n
i
z
a
t
i
o
n
a
l
i
n
n
o
v
a
t
i
o
n
&
d
e
p
l
o
y
m
e
n
t
1

2
Q
u
a
l
i
t
y
c
o
n
t
r
o
l
S
u
p
p
l
i
e
r
a
g
r
e
e
m
e
n
t
m
a
n
a
g
e
m
e
n
t
2
4
M
e
a
s
u
r
e
m
e
n
t
&
a
n
a
l
y
s
i
s
1

2
P
r
o
c
e
s
s
&
p
r
o
d
u
c
t
q
u
a
l
i
t
y
a
s
s
u
r
a
n
c
e
1

2
32
T
a
b
l
e
2
.
1
.
C
M
M
I
p
r
o
c
e
s
s
a
r
e
a
s
(
c
o
n
t
i
n
u
e
d
)
.
E
T
O
p
r
o
c
e
s
s
M
a
i
n
a
c
t
i
v
i
t
i
e
s
w
i
t
h
i
n
p
r
o
c
e
s
s
C
M
M
I
p
r
o
c
e
s
s
a
r
e
a
c
o
v
e
r
a
g
e
o
n
t
h
e
E
T
O
a
c
-
t
i
v
i
t
y
l
e
v
e
l
P
r
o
c
e
s
s
a
r
e
a
s
p
e
-
c
i

c
g
o
a
l
a
S
c
o
r
e
C
o
n
c
l
u
s
i
o
n
(
c
o
v
e
r
a
g
e
)
I
M
/
I
T
A
p
p
l
i
c
a
t
i
o
n
&
n
e
t
w
o
r
k
s
u
p
p
o
r
t
N
/
A
N
/
A
N
/
A
W
e
a
k
P
r
o
j
e
c
t
a
d
m
i
n
i
s
t
r
a
t
i
o
n
P
r
o
j
e
c
t
p
l
a
n
n
i
n
g
2
2
P
r
o
j
e
c
t
m
o
n
i
t
o
r
i
n
g
&
c
o
n
t
r
o
l
1
M
e
a
s
u
r
e
m
e
n
t
&
a
n
a
l
y
s
i
s
1

2
H
u
m
a
n
r
e
s
o
u
r
c
e
s
S
e
l
e
c
t
i
o
n
o
f
p
e
r
s
o
n
n
e
l
P
r
o
j
e
c
t
p
l
a
n
n
i
n
g
2
3
M
o
d
e
r
a
t
e
T
r
a
i
n
i
n
g
O
r
g
a
n
i
z
a
t
i
o
n
a
l
t
r
a
i
n
i
n
g
1

2
5
E
m
p
l
o
y
e
e
e
v
a
l
u
a
t
i
o
n
N
/
A
N
/
A
N
/
A
a
M
o
s
t
p
r
o
c
e
s
s
a
r
e
a
s
c
o
n
t
a
i
n
m
o
r
e
t
h
a
n
1
s
p
e
c
i

c
g
o
a
l
.
I
n
t
h
i
s
c
o
l
u
m
n
,
t
h
e
a
p
p
l
i
c
a
b
l
e
s
p
e
c
i

c
g
o
a
l
s
a
r
e
m
e
n
t
i
o
n
e
d
w
i
t
h
a
n
u
m
b
e
r
.
N
o
t
e
v
e
r
y
s
p
e
c
i

c
g
o
a
l
i
s
a
u
t
o
m
a
t
i
c
a
l
l
y
a
p
p
l
i
c
a
b
l
e
.
T
h
e
r
e
f
o
r
e
t
h
e
y
a
r
e
s
p
e
c
i

c
a
l
l
y
m
e
n
t
i
o
n
e
d
.
S
p
e
c
i

c
g
o
a
l
d
e
s
c
r
i
p
t
i
o
n
s
c
a
n
b
e
f
o
u
n
d
i
n
t
h
e
a
p
p
e
n
d
i
x
.
33
Process improvement concepts
The processes of construction, maintenance, logistics, IM/IT and HSEW
are weakly covered by CMMI. No generic goals of the CMMI process found
were found to be fundamentally benecial to these processes. The construc-
tion process, for example, is in the engineer-to-order/oil and gas setting a
complex activity of work package preparation (i.e. obtaining designs, es-
timating work activities, estimate cost, obtain permits, coordinate subcon-
tractor work, quantity surveying), construction and pre-commissioning. This
process also includes the complex activity of sub-contracting and the rela-
tionships with (engineering,) manufacturing and assembly processes, that, in
the case of Stork GLT, are the responsibilities of the joint venture partners.
This is called sub-contract management. These typical activities cannot be
structured according to the CMMI product integration process area, simply
due to the lack of details. The maintenance process, another example of a
weakly covered area, is said to be supported by the framework according to
CMMI advocates (e.g. Chrissis et al., 2003). Careful analysis of the model
lead us to conclude, however, that maintenance is primarily seen as a stake-
holder of the other processes (e.g. for engineering), and not as a process that
is supported by practices specic for maintenance. It is for exactly that rea-
son that maintenance maturity frameworks for software have been developed
(e.g. April et al., 2005).
2.4.4 Final remarks
We end this section with three remarks. First, we should stress that engineer-
to-order organizations can apply CMMI in addition to their existing concepts
and programs, such as lean production and ISO 9000 (Ahern et al., 2004;
Ashra, 2003), although it might be counter-eective to apply too many pro-
cess improvement initiatives at the same time. Second, one must realize that
process capability is not the only capability an organization can or should
be concerned with. Other capabilities requiring dedicated resources and the
balancing of these process capabilities are, for example, innovative capability
or human resource capability (Grant, 1996). Finally, one major part of the
criticism CMMI has received over the years is that it promotes bureaucracy
and that it does not t every organizations culture (Adler, 2005). Accord-
ing to Ngwenyama and Nielsen (2003), many CMM implementations fail due
to the necessity to change underlying cultures. This cultural shift is not
explicitly included in the framework. Therefore, it is advisable that matu-
rity framework implementations should be accompanied by an appropriate
cultural change project.
34
2.5 Conclusions
In this chapter we have shown opportunities for engineer-to-order companies
in managing and improving their processes. Traditionally, engineer-to-order
companies can only to a limited extent benet from best practice descrip-
tions in lean production and related literature. For a large part is this is
due to the specic characteristics of organization, work and output within
these companies: low volume and customized, complexity and dynamicity
of processes, project-based organization of work and high level of integration
within the supply chain. Many process improvement philosophies and frame-
works assume medium to high level of predictability in the rhythm and ow
of processes. Consequently, standard contingency theory proposes the use of
the dierent types of standardization.
In this chapter, it is demonstrated that the Capability Maturity Model
Integrated (CMMI), a best practice reference framework widely used in the
software industry, contains practices which are also applicable in engineer-
to-order companies. CMMI provides a philosophy, as well as a hands-on set
of guidelines and measurable stages for progressing organizations towards
managed, dened, quantitatively managed and optimized processes. CMMI
may provide practical techniques to engineer-to-order companies which other
companies acquire from systems such as lean production and six sigma. For
engineer-to-order companies, CMMI can therefore serve as the much-needed
vehicle for structured process assessment and improvement. As with many
of such reference frameworks, CMMI has its aws. Particularly company
downstream processes -processes which become more and more important in
the shift towards life cycle management we observe- need better coverage than
CMMI provides currently. These areas, which include logistics, construction
and maintenance, need to be extended in order for CMMI to act as an eective
life cycle process management tool.
35
Process improvement concepts
Appendix
Table 2.2. CMMI process areas.
Maturity
level
Category* Process area Specic goal(s)
2 EN Requirements
management
SG1 - manage requirements
PM Project planning SG1 - establish estimates
SG2 - develop a project plan
SG3 - obtain commitment to the
plan
PM Project monitoring
and control
SG 1 - monitor project against
plan
SG 2 - manage corrective action
to closure
PM Supplier agreement
management
SG 1 - establish supplier agree-
ments
SG 2 - satisfy supplier agreements
SUP Measurement and
analysis
SG 1 - align measurement and
analysis activities
SG 2 - provide measurement re-
sults
SUP Process and product
quality assurance
SG 1 - objectively evaluate pro-
cesses and work products
SG 2 - provide objective insight
SUP Conguration SG 1 - establish baselines
management SG 2 - track and control changes
SG 3 - establish integrity
3 EN Requirements
development
SG 1 - develop customer require-
ments
SG 2 - develop product require-
ments
SG 3 - analyze and validate re-
quirements
EN Technical solution SG 1 - select product-component
solutions
SG 2 - develop the design
SG 3 - implement the product de-
sign
EN Product integration SG 1 - prepare for product inte-
gration
SG 2 - ensure interface compati-
bility
SG 3 - assemble product compo-
nents and deliver the product
EN Verication SG 1 - prepare for verication
SG 2 - perform peer reviews
SG 3 - verify selected work prod-
ucts
EN Validation SG 1 - prepare for validation
SG 2 - validate product or product
components
PSM Organizational process
focus
SG 1 - determine process-
improvement opportunities
36
Table 2.2. CMMI process areas (continued).
Maturity
level
Category* Process area Specic goal(s)
SG 2 - plan and implement
process-improvement activities
PSM Organizational process
denition
SG 1 - establish organizational
process assets
PSM Organizational
training
SG 1 - establish an organizational
training capability
SG 2 - provide necessary training
PM Integrated project
management for IPPD
SG 1 - use the projects dened
process
SG 2 - coordinate and collaborate
with relevant stakeholders
SG 3 - use the projects shared vi-
sion for IPPD
SG 4 - organize integrated teams
for IPPD
PM Risk management SG 1 - prepare for risk manage-
ment
SG 2 - identify and analyze risks
SG 3 - mitigate risks
PM Integrated teaming SG 1 - establish team composition
SG 2 - govern team operation
PM Integrated supplier
management
SG 1 - analyze and select sources
of products
SG 2 - coordinate work with sup-
pliers
SUP Decision analysis and
resolution
SG 1 - evaluate alternatives
SUP Organizational
environment for
SG 1 - provide IPPD infrastruc-
ture
integration SG 2 - manage people for integra-
tion
4 PSM Organizational process
performance
SG 1 - establish performance base-
lines and models
PM Quantitative project
management
SG 1 - quantitatively manage the
project
SG 2 - statistically manage sub-
process performance
5 PSM Organizational SG 1 - select improvements
innovation and SG 2 - deploy improvements
deployment
SUP Causal analysis SG 1 - determine causes of defects
resolution SG 2 - address causes of defects
* Process areas can be arranged by categories: EN=engineering, PM=project
management, SUP=support, PSM=process management.
37
38