CLIENT PROJECT TIME SCHEDULE CONTROLS — AN EMPIRICALLY-BASED SYSTEM DYNAMICS CONCEPTUAL MODEL

Different project participants often have different objectives and expectations, and implement different controls aimed at advancing their interests. This article investigates project controls taken by the client during the project design stage to improve project time schedule performance. Dynamic hypotheses and a System Dynamics conceptual model of client controls and their ripple effects are formulated in this article from a combination of the existing literature, mental models of project managers gathered through an embedded multiple-case study, and Systems Thinking. The results suggest that client controls that are aimed at improving project time schedule performance generate ripple effects that worsen the performance.


INTRODUCTION
The execution of engineering projects generally entails design and construction, as is evident from Parvan [1].Project execution is the most challenging phase to manage in a project life cycle.Yet it is the most crucial, as its final output needs to be handed over to the client as a complete system, ready for the effective and efficient realisation of the intended project benefits.It also involves numerous interactions and interdependencies among a number of project stakeholders.Those project stakeholders who are actively involved in the execution of the project are, in this article, referred to as 'project participants', in line with Shen, Song, Hao and Tam [2].According to Ngacho and Das [3] and Toor and Ogunlana [4], key participants during project execution include the client, the engineering consultant, and the contractor.This article focuses only on the design stage, where the key project participants are the client and the engineering consultant.
Different project participants have different objectives [5] and competing expectations [6] during project execution.They therefore tend to take different control actions to try to influence project execution so that it is in line with their interests, as highlighted by Lyneis and Ford [7], and Sutterfield, Friday-Stroud and Shivers-Blackwell [8].However, the well-intentioned decisions and control actions ('project controls') of the project participants often generate some undesirable and unintended consequences (ripple and knock-on effects) that militate against the intended effects, as highlighted by Lyneis and Ford [7].For instance, in a bid to try to bring a project that is behind schedule back on track, a project manager may decide to apply pressure on the workforce to work faster; however, this may increase errors ('haste makes waste'), leading to work having to be repeated, which increases project time schedule delay, according to Lyneis and Ford [7].
Thus project control (in particular, project time schedule control) is inherently characterised by dynamic complexities, as is evident in the research of Ford, Lyneis and Taylor [9], Nasirzadeh and Nojedehi [10], and Rodrigues and Williams [11].For instance, there tend to be delays between the controls (decisions and actions) of one project participant, their effects (some of which are unintended and counterintuitive), and the responses (balancing or reinforcing feedbacks) of the other project participants; and there are often differences between short-run and long-run results; all of which are key characteristics of dynamic complexity, according to Sterman [12].
Solving system problems that involve dynamic complexity, such as project time schedule control, is not possible with the human mind alone; computer modelling and simulation (such as System Dynamics) is needed to support human decision-making and management policies, as highlighted by Forrester [13] and Sterman [12].System Dynamics is thus used in this study to model the control actions taken by the client in an effort to protect project time schedule performance during the design part of project execution.
A review of the existing literature, highlighted in the next section, shows that many studies investigated and modelled (using System Dynamics) project time schedule controls taken by the engineering consultant or construction contractor.However, as is evident from the literature reviewed, project time schedule controls (and the System Dynamics modelling thereof) taken by the client, and their impact on project performance, remain largely under-researched.Accordingly, the objectives of this article are to investigate, from the existing literature and empirically, the controls taken by the client in a bid to protect project time schedule performance; any primary unintended consequences (ripple effects) of such controls; and how the client project time schedule controls and their ripple effects may be conceptually modelled using System Dynamics.
To achieve these objectives, this article proceeds with a critical but relevant review of the extant project performance, project controls, and System Dynamics literature.An account of the research methodology followed in this study ensues, followed by a presentation of the key empirical findings.Next, the empirical findings are discussed, with comparisons with the appropriate extant literature; and dynamic hypotheses and a System Dynamics conceptual model of the client project time schedule controls and associated ripple effects are formulated.Subsequently, conclusions are drawn, and some recommendations for further research are made.

Project performance measures
During project execution, the client is particularly interested in project performance and its associated measures, and sets targets and priorities accordingly.A review of some relevant extant project management literature shows different ways of measuring project performance.The number of key indicators used to measure project performance, in the literature reviewed, varies from two to nine.For instance, the Earned Value Method measures project performance using time schedule and cost, as highlighted by Anbari [14].Other researchers who also measured project performance using only time schedule and cost include Nasirzadeh and Nojedehi [10], Parvan [1], and Parvan, Rahmandad and Haghani [15].Some scholars, such as Rahmandad and Hu [16], used three key indicators (time schedule, cost and quality), the so-called 'Iron Triangle'.Ngacho and Das [3] found six key performance indicators for project performance: time; cost; quality; safety; site disputes; and environmental impact.
At the far end of the scale, Toor and Ogunlana [4] identified nine key indicators for project performance: on time; on cost budget; according to specifications; safety; efficiency; doing the right thing (effectiveness); free from defects; conformance to stakeholders' expectations; and minimised construction aggravation, disputes and conflicts.Table 1 summarises the different measures used or identified for project performance by the different scholars in the reviewed literature.

Project controls and System Dynamics
Different project participants have different objectives [5] and competing expectations [6] during project execution.They therefore naturally tend to take different control actions to try to influence the project execution so that it is in line with their objectives and expectations, as indicated by Lyneis and Ford [7], and Sutterfield et al. [8].Key project stakeholders during the design part of project execution include the client and the engineering consultant.Generally, both the client and the engineering consultant are interested in seeing the project perform well.As discussed in the preceding section, there are many key indicators that may be used to measure project performance; for instance, Rahmandad and Hu [16] used time schedule, cost budget, and quality.This article considers only project time schedule.
The existing project management literature is replete with discussions of control actions taken by the engineering consultant or construction contractor during project execution to ensure that a project is delivered within the planned time schedule.For instance, according to Ford et al. [9], a project manager may: add more people to the project workforce; make the project workforce work overtime; or make the project workforce work faster by applying pressure on them.Lyneis and Ford [7] discuss another System Dynamics project model with similar project time schedule controls.However, both the models of Ford et al. [9] and Lyneis and Ford [7] have one notable short-coming: only the management controls taken by the project manager (belonging to only one project participant) are included.It is not clearly stated to which project participant (client, engineering consultant, or contractor) this project manager belongs.However, considering that the client does not normally have direct control over the project workforce, it can be argued (and thus assumed in this article) that the project manager in the models of Ford et al. [9] and Lyneis and Ford [7] is that of the engineering consultant or construction contractor.Thus the models of Ford et al. [9] and Lyneis and Ford [7] exclude the client project time schedule controls (and associated ripple and knock-on effects); yet, arguably, they are key to project dynamics and project performance.
A more recent study by Nasirzadeh and Nojedehi [10] developed a System Dynamics simulation model of labour productivity in a construction project.Labour productivity was shown, through their model, to influence the work done and the subsequent total project cost and time duration [10].
Their model included two project control actions taken by the contractor's project manager: adding/reducing the workforce; and making the workforce work overtime [10].However, their model does not include the management control actions (and associated ripple and knock-on effects) taken by other project participants, such as the client.
When a project is behind time schedule, the client basically has three options to take: extend the project time schedule deadline; take some control actions that aim to bring the project back on track; or both [11].Consistent with previous studies, such as those of Lyneis and Ford [7] and Ford et al. [9], the current study is aimed at advancing project management effectiveness, and thus focuses on investigating the client control actions aimed at bringing a poorly-performing project back on time schedule.
Von Branconi and Loch [18] highlighted that when a project is delayed, the client may institute a 'liquidated damages penalty' against the construction contractor.However, they warn that the contractor often makes a trade-off analysis between the delay damages and the cost of accelerating the project, and may even decide to stop executing the project if the acceleration costs exceed the delay damages [18].In System Dynamics terminology, this effectively suggests a primary undesirable and unintended effect (ripple effect) of the delay damages penalty.The study of Von Branconi and Loch [18], however, did not include any System Dynamics modelling and simulation to demonstrate the impact of schedule delay damages penalty (as a project time schedule control) on project completion, and a ripple effect on contractor productivity.
Earlier, Rodrigues and Williams [11] developed a System Dynamics model that indicated that poor project time schedule performance results in the client losing trust in the contractor and, subsequently, taking two control actions in a bid to try to bring the project back on time schedule: demanding more progress reports from the contractor; and not tolerating any delays in attaining project milestones.Their model further showed that such client controls (negative feedbacks) tend to generate some ripple effects; for instance, an increase in progress reports results in a decrease in productivity, and consequently a decrease in the project work completion rate and an increase in the project time schedule delay [11].However, their study was not specific enough about how the intolerance in project milestone delays is manifested.
Zhu and Mostafavi [19] highlight that project complexity has two key dimensions: detail complexity (time-independent and arising from a large number of project variables); and dynamic complexity (time-dependent and arising from cause and effect relationships between the variables, which may be unclear and change with time).They emphasise the importance of understanding project dynamic complexity as key to enhancing project performance.Human behaviour is one of the key factors influencing project dynamic complexity, according to Lyneis and Ford [7], Martinez-Moyano and Richardson [20], Sterman [12], and Zhu and Mostafavi [19].
Project control, which essentially involves human behaviour, is thus inherently characterised by dynamic complexity, as is evident in the works of Ford et al. [9], Nasirzadeh and Nojedehi [10], and Rodrigues and Williams [11].For instance, there tend to be delays between the controls (decisions and actions) of one project participant, their effects (some unintended and counterintuitive), and the responses of the other project participants; and there are often differences between short-run and long-run results; all of which are key characteristics of dynamic complexity, according to Sterman [12].
Solving system problems (such as project time schedule control) involving dynamic complexity is not possible with the human mind alone; computer modelling and simulation (such as System Dynamics) is needed to support human decision-making and management policies, as highlighted by Forrester [13] and Sterman [12].Thus, System Dynamics is used in this study to model client project time schedule controls.
Lyneis and Ford [7] indicate that the main objective of applying System Dynamics to project management is to improve project performance.For this, one needs to compare the actual project performance against the targeted project performance, and then take appropriate management decisions and control actions (project controls) aimed at closing the gap between the targeted and the actual project performance [7].As highlighted by Ford et al. [9] and Lyneis and Ford [7], adverse project dynamics that result in poor project performance largely emanate from four key structures: the rework cycle (discovery of errors in previously completed work, prompting repetition of the work); controlling feedbacks (project controls taken by management in a bid to try and bring a poorly-performing project back on track); ripple effects (primary undesirable and unintended consequences of the management project controls); and knock-on effects (secondary and tertiary undesirable and unintended consequences of the management controls).This study focuses on project controls and ripple effects and, in particular, on client project time schedule controls and ripple effects, and their System Dynamics modelling.
The rework cycle is the main cause of many detrimental project dynamics, as highlighted by Ford et al. [9], Lyneis and Ford [7], and Rahmandad and Hu [16].Ford et al. [9] also make the point that ripple and knock-on effects tend to increase project work errors or reduce project workforce productivity.An increase in errors leads to more rework, which in turn leads to more errors: a recursive cycling of tasks around the rework cycle that results in a greater workload, longer project duration, and more resources than initially planned, as illuminated by Ford et al. [9], and Rahmandad and Hu [16].Thus, as Lyneis and Ford [7] highlight, minimising the rework cycle and the ripple and knock-on effects of management control actions can significantly reduce project dynamics, thereby enhancing project performance.
System Dynamics has been extensively applied to project controls, particularly with regard to project time schedule controls taken by engineering consultants or construction contractors, as the preceding literature review highlights.However, project time schedule controls taken by the client and their System Dynamics modelling were sparingly covered in the literature reviewed.Hence, as indicated in Section 1, the objectives of this article are focused on client project time schedule controls.
The next section outlines the research methodology followed in this study.

RESEARCH METHODOLOGY
As indicated in Section 1, this research study is aimed at formulating dynamic hypotheses and a System Dynamics conceptual model of the project controls (and their associated ripple effects) usually taken by the client, during the design part of project execution, to protect the project time schedule performance.Effectively, this means covering the first two stages (problem identification and definition, and system conceptualisation) of the six-stage System Dynamics modelling process recommended by Martinez-Moyano and Richardson [20].The research design for this study is an exploratory, embedded multiple-case study, in line with Cooper and Schindler [21], Parvan et al. [15] and Yin [22].Furthermore, the research design is exploratory and qualitative because the purpose here is to capture current practices and experiences [21] from contemporary client project managers during the design part of project execution.Put differently, the intention includes capturing mental models of contemporary client project managers, in line with Luna-Reyes and Andersen [23], Martinez-Moyano and Richardson [20], and Sterman [12].
For a qualitative study, only non-probability sampling (e.g., accidental, purposive, snowball, or convenience) is applicable, as the intent is not to obtain a sample that is representative of the population (randomly selected and adequate size for quantitative analyses), but to obtain information from appropriate and insightful sources [21] that are purposefully selected [24].This is also in line with the System Dynamics emphasis on capturing mental models of system actors, as highlighted above.Accordingly, this research study used a purposefully-selected key engineering consulting firm with many infrastructure projects (the focus of this article) in South Africa.Nonproject-specific qualitative data was collected using individual face-to-face semi-structured interviews, similar to Mikulskiene and Pitrenaite-Zileniene [25], Nasirzadeh and Nojedehi [10], and Parvan et al. [15]; non-participant casual observation during the interviews [22]; and document analysis, similar to Nasirzadeh and Nojedehi [10].The use of different sources of qualitative empirical evidence enables the production of research findings that are supported by multiple sources of evidence (triangulation), thereby enhancing the construct validity of the case study, as recommended by Yin [22].The specific focus on infrastructure projects was inspired by the fact that infrastructure development is essential for the economic development of any country; yet there are many cases of poor project performance, according to Ansar, Flyvbjerg, Budzier and Lunn [26].
The research participants included five client project managers (from five different organisations (clients), sharing the same engineering consultant); and six project managers from the engineering consulting firm in question.The number of research participants used in this study is comparable to some previous studies, such as Mikulskiene and Pitrenaite-Zileniene [25] and Parvan et al. [15].The data gathered were non-project specific, and were not necessarily limited to the engineering consultant in question.
The non-project-specific qualitative empirical data gathered in this research study were analysed using a three-streamed, iterative, qualitative data analysis process recommended by Miles, Huberman and Saldana [27].ATLAS.ti, a computer-assisted qualitative data analysis software [28], was used in this research study to aid the qualitative data analysis.According to Miles et al. [27], the first stream of qualitative data analysis is 'data condensation', which involves sorting, clustering, selecting portions of, coding, and summarising the gathered qualitative empirical data.
In this study, data condensation was conducted using ATLAS.tisoftware after the gathered qualitative empirical data (interview write-ups, non-participant casual observation notes, and nonproject-specific organisational documents) were imported into ATLAS.tiand grouped according to their type.
The second stream of qualitative data analysis, according to Miles et al. [27], is called 'data display', which involves presenting information from the empirical data in an organised, compact form (such as with tables, matrices, causal network diagrams, or graphs) that simplifies the drawing of conclusions.Ackermann and Alexander [29] highlighted the value of causal maps/networks (in particular, systemic view and improved understanding of project dynamics), and subsequently called for more project management research using causal maps.Accordingly, in this research study, data display was done using the Network View tool of ATLAS.tisoftware, yielding causal networks, as shown in the next section.
The last stream of qualitative data analysis, as recommended by Miles et al. [27], is called 'conclusion drawing and verification', and entails documenting and verifying the research findings (meanings, explanations, causal relationships, themes, or patterns).In this research study, research conclusions were also done in ATLAS.ti using memos.Empirical data from multiple sources of evidence (interview write-ups, non-participant casual observation notes, and non-project-specific organisational documents) were used to verify and support the conclusions, thereby enhancing the construct validity of the case study, in line with Yin [22].
The results of the qualitative empirical data analysis were discussed and compared with appropriate extant literature.Subsequently, a System Dynamics conceptual model of the client project time schedule controls (and associated ripple effects), taken during the design part of the project execution, was formulated by integrating the results of the qualitative empirical data analysis with the extant literature using System Dynamics' Systems Thinking tools (causal loop diagrams).This is in line with Martinez-Moyano and Richardson [20], and Sterman [12].Using a combination of existing literature, mental models of contemporary clients' and engineering consultant's project managers, and System Dynamics' Systems Thinking tools in the formulation of the dynamic hypotheses and System Dynamics conceptual model helps to strengthen their validity, as recommended by Barlas [30], Luna-Reyes and Andersen [23], Martinez-Moyano and Richardson [20], Sterman [12], and Oosthuizen [31].
The next section presents key findings from the embedded multiple-case study.

EMPIRICAL RESEARCH STUDY FINDINGS
Key findings emanating from the analysis of the qualitative empirical data gathered in this study are highlighted in the next two sub-sections.

Client project time schedule controls
In this research study, it was found that when a project is (or is forecast to be) behind time schedule during the design stage of project execution, the client's trust in the engineering consultant diminishes: the higher the project time schedule delay, the less the client's trust.One of the client project managers interviewed quipped: "… the more the project is behind time schedule, the less I trust the engineering consultant.You just cannot trust a non-performer!" [Client Project Manager, Questionnaire Reference Number: C01].
Further analysis of this study's empirical data showed that, as the client's trust in the engineering consultant decreases due to poor time schedule performance, the client takes corrective control actions.Table 2 summarises the time schedule controls usually taken by the interviewed client project managers.Figure 1 is a causal network display (generated using ATLAS.ti), in line with Miles et al. [27], of the five client project time schedule controls presented in Table 2.

Figure 1: Client project time schedule controls during the design stage
As shown in Figure 1, the client project managers interviewed in this study indicated that the abovementioned time schedule controls are aimed at putting pressure on the engineering consultant to speed up project work completion.One of the interviewees highlighted this as follows: "I take these control actions not as punitive measures, but to try and apply some pressure on the engineering consultant to work faster."[Client Project Manager, Questionnaire Reference Number: C03].
In an ATLAS.tinetwork view (such as Figure 1), the relationship between two codes (variables, constructs, or concepts) is indicated by an arrow (showing the direction of the relationship) and a name in the middle of the arrow indicating the type of the relationship [28].ATLAS.ti has standard relations, such as 'isa' (is a) and 'is cause of' (one variable causes another variable), and also allows the creation of user-defined relations [28].The 'is negative cause of' (one variable negatively causes another variable) was specifically created for this study.In Figure 1, the 'is cause of' (causes) and the 'is negative cause of' (negatively causes) relations indicate the type of relationship between the associated two variables, as identified from the gathered empirical data during data analysis in ATLAS.ti. Figure 1 is read as follows, using the top route for illustration: 'project schedule delay' negatively causes 'client trust in engineering consultant', which in turn negatively causes 'progress reports'; 'progress reports' causes 'pressure to work faster', which in turn causes 'work completion rate'; 'work completion rate' negatively causes 'project schedule delay'.

Ripple effects of client project time schedule controls
Further analysis of the empirical data gathered in this study revealed that the client project time schedule controls, described in the preceding section, generate some undesirable and unintended consequences (ripple effects).Table 3 summarises the ripple effects of the client project time schedule controls, as evident from the responses of the interviewed client and engineering consultant project managers.Firstly, it was found, as shown in Table 3, that producing more project progress reports, holding more progress meetings, and conducting more progress inspections consumes a significant amount of time, resulting in less time being available for the engineering consultant to carry out real project work (e.g., producing design calculations, specifications, and drawings), thus reducing the engineering consultant's productivity, which in turn decreases project work completion.
Secondly, also as shown in Table 3, it was found that instituting delay-damages penalties or delaying approval and payment of the engineering consultant's invoices sometimes leads to insufficient project operating cash flow for the engineering consultant.This makes it difficult for the engineering consultant to resource the project fully, thus putting more strain on the engineering consultant's work completion rate.
Figure 2 shows the two ripple effects of the client project schedule controls in the form of a causal network, in line with Miles et al. [27], generated using ATLAS.ti.

Figure 2: Ripple effects of client project time schedule controls during the design stage
Figure 2 is read in a similar way to that described for Figure 1 in the preceding section.
The next section discusses these research findings, and formulates a System Dynamics conceptual model for the client project time schedule controls and associated ripple effects.

Client project time schedule controls
In this study, a client's trust in the engineering consultant was found to decrease with increasing project time schedule delay; this corroborates the findings of Manu, Ankrah, Chinyio Proverbs [32], and Rodrigues and Williams [11].It was further found in this study that, as the client's trust in the engineering consultant diminishes due to poor project time schedule performance, the client implements one or more controls (i.e., demanding more project progress reports; conducting more progress meetings; conducting more progress inspections; delaying approval and payment of engineering consultant's invoices; and applying delay-damages penalties) aimed at putting pressure on the engineering consultant to work faster and increase project work completion.Some of these client project time schedule controls corroborate the works of previous scholars.For instance, demanding more project reports is in line with Rodrigues and Williams [11], who also focused on the design stage.Similarly, applying delay-damages penalties is in line with Von Branconi and Loch [18], who covered both design and construction stages.For client delays in payment of the engineering consultant's invoices, Manu et al. [32] found a similar tendency, with the main contractors often delaying making payments to their subcontractors during construction.
The 'is cause of' and 'is negative cause of' relations used in ATLAS.ti, as shown in Figures 1 and 2, effectively express what System Dynamics theory calls 'dynamic hypotheses', and are represented on causal loop diagrams using arrows with (+/-) signs [12].Indeed, causal networks (such as those shown in Figures 1 and 2) are used to illuminate causal relationships between variables/constructs, according to Miles et al. [27].This means that the causal network displays shown in Figures 1 and 2 can easily be converted into a causal loop diagram, a useful Systems Thinking tool used in System Dynamics, according to Sterman [12] and Martinez-Moyano and Richardson [20].
Evident in the models of Ford et al. [9], Lyneis and Ford [7], and Nasirzadeh and Nojedehi [10] is that a higher project work completion rate leads to a lower expected project time duration.Combining this dynamic hypothesis with Figure 1 effectively forms a negative (balancing) feedback loop around 'project time schedule delay', 'client trust in engineering consultant', 'client time schedule control actions', engineering consultant's 'pressure to work faster', 'project work completion', and 'expected project time duration'.Ford et al. [9], and Lyneis and Ford [7] refer to the engineering consultant's 'pressure to work faster' as 'work intensity'.The resulting negative feedback loop formed by integrating the findings of this study with previous research is shown as a System Dynamics causal loop diagram in Figure 3. Source: Adapted from this study (Figure 1), Ford et al. [9], and Rodrigues and Williams [11] According to Sterman [12], every negative feedback loop must aim at closing the gap between the target and the current/forecast state.In the negative feedback loop in Figure 3, the target is the project time schedule deadline, and the gap (expected project time schedule delay) to be closed is the difference between the expected project time duration and the project time schedule deadline.
Sterman [12] highlights that, in System Dynamics causal loop diagrams (e.g., Figure 3), arrows and their polarity (+/-) indicate causal relationships (positive or negative influences); and the short circular arrows with polarity (+/-) at the centres show the direction (clockwise/anticlockwise) and polarity (positive/reinforcing or negative/balancing) of the causal loop.Each set consisting of two variables linked by an arrow with a positive or negative sign, on a System Dynamics model, represents a dynamic hypothesis.Dynamic hypotheses are read following the direction of the arrows and loops.For example, in Figure 3 the higher the 'expected project schedule delay', the lower the 'client trust in engineering consultant'.

Ripple effects of client project time schedule controls
Two key ripple effects of client project time schedule controls were found in this study.Firstly, demanding more progress reports was found to lead to less time spent by the engineering consultant on carrying out real project work (e.g., producing design drawings), effectively decreasing the project workforce productivity and the project work completion rate.This finding corroborates the work of Rodrigues and Williams [11].It was also revealed in this study that conducting more progress meetings and/or inspections yields a similar ripple effect.This ripple effect forms a positive (reinforcing) loop [12], 'less time spent on real work', which opposes the well-intentioned client project time schedule control.Figure 4 shows the controlling (negative) feedback loop and its associated ripple effect (positive loop) for one of the client project time schedule controls (conducting more progress meetings).Two other project time schedule controls by the client (demand for progress reports from the engineering consultant, and conducting more progress inspections with the engineering consultant) yield loops similar to those shown in Figure 4.
The second ripple effect of client project time schedule controls found in this study is that instituting a delay-damages penalty or delaying approval and payment of the engineering consultant's invoices sometimes leads to insufficient project operating cash flow for the engineering consultant.This makes it difficult for the engineering consultant to resource the project fully, thus degrading the engineering consultant's work completion rate.Figure 5 shows the controlling (negative) loop and its associated ripple effect (positive loop) for client delay in approving and paying the engineering consultant's invoices.Source: Adapted from this research study (Figures 1 and 2), Ford et al. [9], and Rodrigues and Williams [11].Applying a delay-damages penalty yields loops similar to those shown in Figure 5.Other researchers, such as Ford et al. [9], Lyneis and Ford [7], and Nasirzadeh and Nojedehi [10], also highlighted that the lower the workforce productivity, the less the work completion rate, and the higher the project schedule delay.

The overall System Dynamics conceptual model
Applying pressure on project workforce to work faster (work intensity) yields a ripple effect of increasing errors on project deliverables (lowering quality of deliverables), thereby decreasing the project work completion rate, according to Ford et al. [9], and Lyneis and Ford [7].Integrating this with Figures 4 and 5, and including all five client project time schedule controls found in this study, yields the overall System Dynamics conceptual model shown in Figure 6.
In Figure 6, the five negative feedback loops represent the five client project time schedule controls found in this research study (some of which corroborated the extant literature, as discussed in the preceding sub-sections).The positive feedback loops represent the ripple effects of the client project time schedule controls.Effectively, as shown in Figure 6, the positive/reinforcing feedback loops militate against the intended negative/balancing feedback loops, further degrading project time schedule performance.Put differently, the client's control actions, which are aimed at increasing the project work completion rate and reducing/eliminating the project time schedule delay, tend to generate some primary unintended and counteractive consequences (ripple effects) that reduce the project work completion rate and increase the project time schedule delay.This key finding is effectively the main dynamic hypothesis presented in Figure 6.
As is evident throughout this article, the System Dynamics conceptual model of client project time schedule controls and their associated ripple effects, shown in Figure 6, was formulated from a combination of the extant literature; the key findings from an empirical research study that captured the mental models of the client's and the engineering consultant's project managers; and one of System Dynamics' Systems Thinking tools (the causal loop diagram).This helps to strengthen the validity of the dynamic hypotheses and model presented in Figure 6, as recommended by Barlas [30], Luna-Reyes and Andersen [23], Martinez-Moyano and Richardson [20], and Sterman [12].

CONCLUSION AND RECOMMENDATIONS
This article aimed to investigate the project controls (and associated ripple effects) usually implemented by a client during the design part of project execution, to bring a project that is (or is forecast to be) behind time schedule back on schedule.An embedded multiple-case study was conducted, supported by a critical literature review foundation.Analysis of the gathered qualitative empirical data was done using ATLAS.ti,and the key findings were grouped into two main categories.The first category of the key findings concerned the client project time schedule controls.These findings suggest that the client's trust in the engineering consultant decreases with increasing project time schedule delay.It was also found in this study that, as the client's trust in the engineering consultant diminishes due to poor project time schedule performance, the client implements one or more of the following controls: demanding more project progress reports; conducting more progress meetings; conducting more progress inspections; delaying approval and payment of the engineering consultant's invoices; and applying delay-damages penalties.These controls were found to be aimed at putting pressure on the engineering consultant to work faster and increase project work completion.
The second group of the empirical study's findings concerns the ripple effects of the client project time schedule controls.Two key ripple effects were found.Firstly, demanding more project reports, conducting more progress meetings, and conducting more progress inspections were found to decrease the engineering consultant's workforce productivity, resulting in a decrease in the project work completion rate.Secondly, instituting a delay-damages penalty or delaying approval and payment of the engineering consultant's invoices were found, potentially, to lead to insufficient project operating cash flow for the engineering consultant, leading to a decrease in the engineering consultant's project workforce, and consequently decreasing project work completion.Some of these findings from the empirical study were found to corroborate the works of previous scholars.

Figure 3 :
Figure 3: Client project time schedule controlling feedback during the design stage