WASTE: CAUSES AND ROOT CAUSES
A case study on the Customer Requirement Specification process of construction projects in the Netherlands
Janiek Baarends
Faculty of Technology, Policy and Management
Delft University of Technology
Delft, the Netherlands
janiek_baarends@hotmail.com
Abstract— The Customer Requirement Specification
(process) is a core part of Systems Engineering and often
burdened with waste, but what are the (root) causes? In
this paper, the results from a case study about the causes
and root causes of waste in the Customer Requirement
Specification process are presented and discussed. During
two preliminary studies these (root) causes have been
identified. A brainstorm session revealed five causes and an
A3 Process method has been applied to identify its
accompanying root causes and a case study was used to
validate these (root) causes. During the case study different
root causes were observed in contrast to the pre-assumed
root causes. Inexperience and the lack of knowledge with
regard to the process contributed to a large extent to the
generation of waste during the project. This difference may
be due to the fact that each project and its context are
unique. This research provides an increased understanding
of (root) causes for waste in the Customer Requirement
Specification process.
Keywords — Systems Engineering, Customer Requirement
Specification, causes, root causes, waste, case study
I. INTRODUCTION
“Systems Engineering is regarded as a technically sound
process for creating complex systems but is often burdened
with waste and inefficiencies” [9, pp.3)]. However, waste is
present in all sorts of projects. It is evident that failed projects
represent the most waste, but even successful projects suffer
from lots of waste [9].
A study in the aerospace industry observed waste in 27
(different) aerospace projects that were executed using the
Systems Engineering approach [11]. Said study [11] shows
that the most contributing category of waste is waiting (is the
time spend waiting), which is striking since the second most
contributing category is over processing. This means that
when one is waiting for some input to continue his/her job,
another is over processing output, revealing that activities are
not always planned properly.
Another study illustrated the amount of waste produced by
people (wasted effort) and waste produced by work packages
(wasted time) [8] showing that 29% of all activities were
required non-value adding (RNVA) activities and 40% non-
1
value adding (NVA) activities. Above that, activity owners
were idle during 62% of the time.
This raises the next question: what are causes and root
causes to such types of waste?
In literature two reasons can be distinguished:
1) Most processes and procedures are not designed at all. In
fact, they just happen [2]. Often, Systems Engineering is not
incorporated into the planning as such; only particular
Systems Engineering activities are planned for, but lack
coherence. Often these ineffective ways-of-working emerge
“as a consequence of uncoordinated incremental change or the
inability to take advantage of new design enablers”. [7,
pp.34)];
2) “[H]ow [Systems Engineering] processes should ideally
work is rarely specified clearly” [3, pp.249)]. When new
processes are designed in general, there is no accessible
documentation for employees in most cases [3].
It is argued that these poorly designed processes result in
inefficiencies such as higher costs, wasted effort, and wasted
time, with an increased potential for errors [3]. All together
may lead to project failure.
The Systems Engineering approach states that a project is a
success if all (relevant) customers’ requirements are met
within socially accepted costs. However, this objective is
constrained by physical boundaries, standards, time, resources,
and budget. From the Systems Engineering’s perspective,
customer is king. Therefore the Customer Requirement
Specification, where customer demand is established by
collecting needs, expectations, and wishes of all stakeholders
with respect to the system to be realized, is a vital part of
Systems Engineering.
Up till now virtually no research has been done with
regard to the Customer Requirement Specification process, but
a large consultancy and engineering firm in the Netherlands
indicated that they experience inefficiencies when they draw
up Customer Requirement Specifications. In their opinion, the
current Customer Requirement Specification process, as
applied to the Dutch Civil Engineering sector and adduced by
Rijkswaterstaat, shows to be inadequate to prevent, reduce, or
eliminate waste [4]. Therefore, an interesting question to pose
here is what causes inefficiencies or waste? Thus, the
objective of this paper is to identify reasons for inefficiencies
and/or waste and to check whether these actually occur in the
Customer Requirement Specification processes
construction projects in the Netherlands. In order to achieve
this objective, two preliminary studies have been performed to
identify causes and root causes, subsequently a case has been
studied to validate these causes and root causes. The results
are reported in this paper.
The structure of this paper is as follows: section two
presents the background of the case that has been studied and
the Customer Requirement Specification process as applied to
the drawbridge to be designed in the case. Section three
describes the research methodology. Section four presents the
results of this study. Section five gives an interpretation of the
results and a discussion. Finally, section six concludes this
paper by providing a conclusion and suggestions for future
research.
II. THE CASE
All results of this research are based on empirical data
from infrastructure projects at a large consultancy and
engineering firm in the Netherlands. The company has over a
thousand employees and offers consultancy and designs for
water, infrastructure, spatial development, environment, and
construction projects [13].
The case that has been analysed during this study was the
renovation of a drawbridge in the Netherlands. This project is
executed using Systems Engineering and uses an adapted
approach as stated by the problem owner. This study focuses
on a specific phase of said approach; the Customer
Requirement Specification process. The Customer
Requirement Specification process as applied to the
renovation project consists of the following activities as
depicted by figure 1: analysing the problem and defining
project objectives (A1), performing a stakeholder analysis
(A2), gathering and assessing customer requirements (A3),
defining a validation strategy for those requirements (A4),
drawing up a Customer Requirement Specification (A5), and
validating this Customer Requirement Specification (A6).
These activities are performed by the project team, which
consists of different people:
• The project leader who leads, checks work done, and
organizes meetings with the problem owner;
• Team members of the CRS who perform all activities
as described in the preceding;
• Designers who design the new drawbridge.
Figure 1: Customer Requirement Specification
process
of In detail, the activities consist of the following steps:
A1. At the beginning of each project, the problem is defined
first. Consequently, a problem definition document is
drafted. When there is a clear understanding of the
problem, project objectives are set, which subsequently
are incorporated into a project plan.
A2. The stakeholder analysis starts with identifying all
stakeholders. Next, their interests, power, and resources
are determined. Finally, a stakeholder overview is
established.
A3. First, the needs, requirements, and constraints are
identified. After drawing up a preliminary list of customer
requirements, these requirements are assessed based on
usefulness (i.e. are the requirements clear and is it
possible to assess them during a granting session?). If
requirements are useful, they are assessed and the
problem owner will be advised accordingly – to either
grant them or not (i.e. decided to incorporate a specific
requirement of a stakeholder into the design). Ultimately,
the problem owner decides whether to grant these
requirements or not.
A4. This activity consists of two steps: making agreements
about how requirements will be validated and specifying
those (agreed) validation steps.
A5. The fifth activity is drafting the actual Customer
Requirement Specification document.
A6. Finally, the requirements from the Customer Requirement
Specification are validated using the validation strategy as
specified in A4. The validated customer requirements and
how it is translated into system requirements are reported
to the relevant stakeholder(s). If the stakeholder does not
agree with the translation, requirements need to be
reformulated and checked with the stakeholder yet again.
III. RESEARCH METHODOLOGY
The research was conducted using a three-phase research
approach. During the first phase, the current situation is
analysed within the company and a set of hypotheses have
been derived that describe the causes for waste when using the
Systems Engineering approach. In the second phase,
hypotheses for root causes are identified for the causes defined
in the previous phase. The third and final phase consists of a
case study. The hypotheses are validated in this case study.
Figure 2: Research methodology
2
A. Phase one – identifying causes for waste
A brainstorm session was used to identify waste in the
Customer Requirement Specification process. Hypotheses are
identified and presented below. This served as an input for
phase three where these will be validated using a case study.
The possible causes that were identified during the brainstorm
session are the following:
1) The process of granting requirements (C1). During the
process of granting requirements multiple people are needed
to assess the requirements, time is lost because of mandatory
steps in the process and accountability, requirements also go
through the process multiple times when they cannot be
assessed due to indecisiveness of the problem owner or the
ambiguity of those requirements.
2) Irrelevant requirements are included in the Customer
Requirement Specification (C2). During the Customer
Requirement Specification process a lot of irrelevant
requirements are included, which are those that are too
detailed for a specific design phase, requirements that are
outside the scope of the project, and those that are unrealistic.
Including these types of requirements asks for a lot of extra
work since they have to go trough the whole Customer
Requirement Specification process as well.
3) Continuous inflow of requirements (C3). At the start of a
project, a large amount of requirements come in, however
during the project (i.e. when the new system is designed) and
at the end of the project, the same amount of requirements
come in. This asks for changes to the initial design (additional
work and rework) and it jeopardises completing the project on
schedule.
4) The Customer Requirements Specification is highly
underestimated (C4). Often project teams delve into the
design stage of a project right away, without considering the
customer’s needs and requirements. Underestimation can
cause a lot of rework when the project team recognizes that
the customer wanted something different.
5) There is a constant aim for SMART requirements (C5).
Very often there is a tension between the design team and the
problem owner with regard to the desired level of
SMARTness of requirements. The problem owner rather does
not have SMART requirements, so he retains room for
negotiation. Designers prefer SMART requirements in the
process since that makes it easier to design a system.
Therefore requirements need to be reformulated over and over
again.
The top 5 causes for waste are based on how many people
recognized it in their daily way-of-working and whether they
thought it was impressionable.
It should be noted that the problem owner does not
necessarily recognize these causes for waste as well. Some
contribute to creating stakeholder support and are therefore
not considered waste by the problem owner.
3
B. Phase two – identifying possible root causes
The A3 Process method was used to reveal root causes of
the previous identified causes for waste. Most companies try to
solve their problems in superficial ways, but do not solve the
root causes. By not addressing these causes, the same problems
will appear again and again. Based on the results from the A3
Process method, the hypothesis is that the five causes have the
following root causes:
1) The process of granting requirements (C1)
a) The company demarcates what should be documented,
but the problem owner wants full accountability (RC1.1)
b) The Customer Requirement Specification team and
area management intermingle without having any agreements
with respect to who will be preforming which tasks (RC1.2)
c) There is a lack of managerial understanding by too
many people (in particular area manager and problem owner)
(RC1.3)
2) Irrelevant requirements are included in the Customer
Requirement Specification (C2)
a) The Customer Requirement Specification team talks
with the wrong interlocutors to retrieve requirements (RC2.1)
b) The Customer Requirement Specification team uses
the wrong framing/ introduction of the problem when they talk
to stakeholders (RC2.2)
c) The strategic behaviour of stakeholders (sometimes
stakeholders use the Customer Requirement Specification
process as a means to accomplish other goals outside the
project scope) (RC2.3)
3) Continuous inflow of requirements (C3)
a) Project control: time and budget (RC3.1)
b) Problem owner with changing insights with regard to
the problem and accompanying requirements (RC3.2)
c) The Customer Requirement Specification is never
complete; changes keep coming (RC3.3)
4) The Customer Requirement Specification is
underestimated (C4)
a) Planning of the Customer Requirements Specification
is imposed by the problem owner (RC4.1)
b) Project team lacks the knowledge with respect to the
Customer Requirement Specification (RC4.2)
c) The focus is too introvert regarding the problem owner
(RC4.3)
5) There is a constant aim for SMART requirements
(C5)
a) Area manager initiates the interview to retrieve
requirements, but does not involve the technical manager,
which results in too little time to match the required level of
SMARTness (RC5.1)
 b) Often the stakeholder’s background is not fathomed
when an interview is prepared (RC5.2)
C. Phase three – testing hypotheses using a case study
Considering the preceding two phases, the causes and root
causes are validated using a case study. During this study
participant observation was applied. In order to keep track of
the requirements and possible waste, a requirement monitor
was developed (see figure 1 and 2). This monitor is able to
identify patterns that indicate waste and categories of
requirements that are wasteful, which can confirm the
identified causes and root causes.
IV. RESULTS
The brainstorm session in phase one revealed that there
could be five main causes for waste in a consultancy and
engineering firm. The A3 Process method identified possible
underlying root causes.
While analysing the results, it was confirmed that 4 out of 5
causes were present. On the other hand, not a single root cause
was confirmed, however some have been confirmed indirectly.
Below the results are elaborated on.
A. Confirmation of assumed causes for waste (C1-C5)
All pre-assumed causes are addressed separately in this
paragraph.
C1: The process of granting requirements. This part of the
Customer Requirement Specification process was new to all
involved, even the project leader. This lack of knowledge
resulted in a process of granting requirements that is not
managed properly. The project leader lacks the knowledge and
is not able to control the process. He suggested assessing the
requirements based on three criteria instead of seven in order
to save time, but problems arise when looking at criteria that
were not considered. Since those are neglected, problems will
become visible when they already started the design and
rework will be unavoidable at that point.
C2: Irrelevant requirements are included in the Customer
Requirement Specification. In the preliminary Customer
Requirement Specification, already eight requirements are
included that are outside the scope of the project. This is
almost 9%, which can be seen in figure 1. Since it takes at
least two hours per requirement from the start of the process
till the end [5], and when the project team does not eliminate
these requirements, theoretically16 hours could be wasted.
C3: Continuous inflow of requirements. This cause could
not be identified during the case study. During the process,
none of the stakeholders filed in their requirements. The team
members of the Customer Requirement Specification had to
retrieve the requirements actively. In fact the opposite of a
continuous inflow of requirements had taken place.
C4: The Customer Requirements Specification is highly
underestimated. First of all the Customer Requirement
Specification process is underestimated by the project leader.
4
His top priority is to stay within budget and therefore he
doesn't want to spend more on the CRS-process even though it
might result in more efficiency and a (more) satisfied problem
owner. In addition, they already started designing the
drawbridge without considering any customer requirements.
This might lead to a frustrated problem owner, who isn’t
satisfied. Rework seems inevitable if they continue without
considering the customer requirements.
C5: There is a constant aim for SMART requirements.
When the team members of the CRS drafted a preliminary
Customer Requirement Specification the project leader wanted
to review the document. The project leader assessed all
requirements and argued that 14 out of the 93 requirements
were not SMART enough, which is 15% (see figure 2). This is
a fairly large amount of rework since these requirements need
to be reformulated and checked with the relevant stakeholder
who brought it in. This observation is a confirmation of this
cause for waste.
B. Root causes to the causes as seen in the case study
In order to provide a deeper understanding of the causes,
employees and team members were asked to describe the
accompanying root causes presented above. Based on these
interviews, the assumed root causes could either be confirmed
or rejected.
Root causes of the process of granting requirements (C1) in
case study:
a) Lack of knowledge at both the problem owner as the
contractor with regard to the process of granting requirements
(RC6.1)
b) Underestimation of added value of the process of
granting requirements (RC6.2)
Root causes of including irrelevant requirements (C2) in case
study:
a) The project team lacks the experience with respect to
retrieving customer requirements and drawing those out
(RC7.1)
b) Scope of the project is unclear [6] (RC7.2)
c) A large amount of the customer requirements is
unclear and ambiguous, which could include irrelevant
requirements [12] (RC7.3)
Root causes of a continuous inflow of requirements (C3) in
case study:
Not applicable since this cause was not confirmed.
Root causes of underestimating the Customer Requirement
Specification process (C4) in case study:
a) The design process is considered more important than
the Customer Requirement Specification process [4] (RC8.1)
b) Fundamental choices in the design are not based on
the customer requirements [10] (RC8.2)
Root causes of aiming for SMART requirements (C5) in case
study:
a) The project leader is a Civil Engineer and prefers to
have SMART requirements that can be easily translated into a
design (RC9.1)
b) Lack of experience of the project team with respect to
retrieving customer requirements and drawing those out
(RC9.2)
V. INTERPRETATION AND DISCUSSION
In this section, the achieved results are interpreted and
discussed. Above that, the limitations of this research are
discussed.
In general, the Customer Requirement Specification
process is considered to be a challenge to the case company.
This research showed that the focus of the process is mainly
from a technological point of view instead of a social point of
view. It seems a challenge to unite the two points of view.
When looking at the causes identified during the brainstorm
session, four out of five causes were confirmed by the case
study. Only the continuous inflow of requirements was not
recognized.
A. Interpretation and comparison of the results
Now, the following question arises whether these causes
have the same root causes as identified during the A3 Process
method.
When comparing the two lists, it can be seen that the root
causes do not completely match for the process of granting
requirements. However, the lack of managerial understanding
may be interpreted as the lack of knowledge regarding the
process. Either way, both result in a project leader who lacks
control.
When considering the root causes to including irrelevant
requirements, it can be concluded that the different root causes
do not match, however RC2.1 and RC2.2 can be a result of the
lack of experience (RC7.1).
Cause 3, the continuous inflow of requirements, was not
recognized, thus no root causes could be compared.
Looking at the root causes for cause 4, underestimation of
the Customer Requirement Specification process, again no
match is found, but the lack of knowledge with respect to the
Customer Requirements Specification (RC4.2) might be the
reason that the design process is considered more important
(RC8.1) and that fundamental choices are not based on
customer requirements (RC8.2). However, this is not
confirmed.
Lastly, the root causes for cause 5 are compared, but no
match was found. Not even an indirect match.
It can be concluded from the above that the identified root
causes for the A3 Process method cannot be confirmed in
practice. This may be due to the fact that the participants of the
A3 Process method experience the waste and its causes in
different ways. In addition, no project is the same and therefore
root causes can differ from project to project.
5
B. Discussion of the limitations
As every research experiences limitations, this research did
as well. These will be addressed in the remainder of this
paragraph.
During this study, a possible cause for unreliability is
related to observer biases. It could happen that results from the
brainstorm session and/or the A3 Process method have been
unconsciously biased by the observer’s knowledge with respect
to the people, processes, and the experienced waste. This treat
to validity was addressed using reviews. During these reviews
the findings were discussed with the project director and other
experts within the company.
Another aspect was the possibility to generalize the results
from the case study. Both internal and external generalizability
should be kept in mind. Sampling participants from different
parts of the company for the pre-studies ensured internal
generalizability. The external validity may be questioned due
to the fact that only one company was involved in the research.
However, one can generalize from one case study [1] and the
main focus of this research is not to provide a full theory on
causes and root causes for waste in the Customer Requirements
Specification process. In addition, it may not even be possible
to replicate the results from this study because no project is the
same. Despite these limitations, this research still contributes to
the understanding of causes and root causes for waste in the
Customer Requirements Specification process.
VI. CONCLUSION AND FUTURE RESEARCH
A. Conclusion
The objective of this paper was to identify reasons for
inefficiencies and/or waste and to check whether these actually
occur in the Customer Requirement Specification processes of
construction projects in the Netherlands.
Therefore, this paper reports on a case study that tries to
understand and validate the causes and root causes for waste in
the Customer Requirements Specification process. The case
study has been preceded by two pre-studies at the case
company: a brainstorm session and an A3 Process method. The
findings from these pre-studies were discussed and validated
during a case study.
The case study confirmed that the process of granting
requirements is wasteful. In addition, one of its assumed root
causes, the lack of managerial understanding, was validated as
well. The case study also confirmed that irrelevant
requirements were included. However, none of its root causes
could be confirmed. During the case study, the Customer
Requirement Specification process was also highly
underestimated by the project team, but the underlying root
causes could not be confirmed. The same goes for the fifth
cause, the constant aim for SMART requirements; the cause
itself was confirmed, but the root causes were not.
The only cause that was not validated by the case study is a
continuous inflow of requirements. Therefore, its root causes
could not be confirmed as well.
During the case study different root causes were observed
in contrast to the pre-assumed root causes. Inexperience and
the lack of knowledge with regard to the process contributed to
a large extent to the generation of waste during the project.
These were the main root causes, but these did not match the
pre-assumed ones. This may be due to the fact that each project
and its context are different and unique.
B. Future research
Of course this is not the end of the research with respect to
the topic, future research is needed. It should be investigated
whether there could be more and/or different causes and root
causes present. In addition, it could be very interesting to
investigate how the different causes are interconnected. The
same goes for the root causes. Future research also includes the
search for methods and tools that could prevent, reduce, or
completely eliminate the causes and root causes for waste in
the Customer Requirements Specification process.
ACKNOWLEDGEMENT
I would like to thank all participants who participated in the
brainstorm session and the A3 Process method for their
contribution to this research. On top of that I would like to
thank the project team for giving me the opportunity to validate
the results from the pre-studies. This paper is part of a bigger
research; a graduation project as part of the Master Systems
Engineering, Policy Analysis and Management at the Delft
University of Technology.
REFERENCES
[1] B. Flyvbjerg, 'Five Misunderstandings About Case-Study
Research', Qualitative Inquiry, vol. 12, no. 2, pp. 219-
245, 2006.
6
[2] M. Hammer, 'Reengineering work: don't automate,
obliterate', Harvard business review, vol. 71, no. 6, pp.
119-131, 1990.
[3] C. Jimmerson, D. Weber and D. Sobek, 'Reducing waste
and errors: piloting lean principles at Intermountain
Healthcare', Joint Commission Journal on Quality and
Patient Safety, vol. 31, no. 5, pp. 249-257, 2005.
[4] L. Kalwij and E. G. Molier, private communication, May
2015
[5] V. Kramer, private communication, May 2015
[6] M. Lagemaat, private communication, May 2015
[7] M. Laguna and J. Marklund, Business Process Modeling,
Simulation and Design, Second Edition. Hoboken: CRC
Press, 2013.
[8] H.L. McManus, Product development value stream
mapping manual, LAI Release Beta, Massachusetts
Institute of Technology, Lean Advancement Initiative,
Cambridge, MA, April 2004.
[9] B. Oppenheim, Lean for systems engineering with lean
enablers for systems engineering. Hoboken, N.J.: Wiley,
2011.
[10] M. Pot, private communication, May 2015
[11] R. Slack, 'Slack, Application of Lean principles to the
military aerospace product development process', M.S.,
Massachusetts Institute of Technology, 1998.
[12] H. de Waardt, private communication, May 2015
[13] Witteveenbos.com, 'Mission and vision -
Ingenieursbureau Witteveen+Bos', 2015. [Online].
Available: http://www.witteveenbos.com/en/mission-and-
vision. [Accessed: 13- May- 2015].
 Figure 3: Requirement Monitor

Figure 4: Clarification waste categories requirement monitor