Chapter 2 - Literature Review
2.4 Technology Constructs in Project Management Domain
2.4.3 Technical complexity
The second dimension of a project’s technical system is the complexity of such a system. Early attempts to conceptualise complexity in the project domain began with the dictionary’s interpretation of the word complexity. Baccarini (1996) proposed that project complexity be defined as “consisting of many varied interrelated parts” (p.202).
Baccarini recognised that complexity may occur in various aspects of a project management process, such as organisation, technology, environment and systems. Of particular relevance to this study is technological complexity and organisational complexity. Technological complexity relates to the difficulty of task performance arising from the overlap of design and construction, and interdependence of operations.
Organisational complexity refers to differentiation of the structure in both vertical and horizontal directions. Baccarini further suggested that complexity be operationalised in terms of differentiation (diversity of inputs or outputs, tasks, trade specialties) and interdependence (between tasks, teams, technologies and inputs). Baccarini proposed that differentiation and interdependence be managed by integration (which embodies organisational activities such as coordination, communication and control).
Gidado (1996), another early writer of project complexity, defined complexity as
“the measure of the difficulty of implementing a planned production work flow in relation to any one or a number of quantifiable objectives” (p.215). Gidado collected viewpoints of practitioners in the construction industry and identified two perspectives of complexity.
The managerial perspective involves planning and bringing together various pieces of work to form a work flow. The operative and technological perspective involves the difficulty or technical intricacies of executing work. Gidado further suggested that there are two components of project complexity. One relates to the individual task, the other relates to the process that links the tasks to form work process. Both components are influential on the managerial and technical activities of a project.
In the work of Gidado (1996), the task component of complexity originates from the resources employed and the level of technical knowledge required. This component can be operationalised by task difficulty (Perrow, 1970) and lack of understanding (Mohr, 1971), which Gidado relates to as uncertainty. The process component originates from the sequencing of tasks. Overlapping of tasks and task interdependence increases project complexity. Furthermore, task overlap may alter the structure of interdependence of tasks as dictated by some resource-dependent factors. Direct impact on project time, cost and quality are evident. Gidado argued that project complexity can be reduced by appropriate planning and control.
Based on the work of Baccarini (1996), Williams (1999) further suggested that Baccarini’s definition of complexity in terms of differentiation permits two interpretations.
In the organisation perspective of complexity, differentiation means the number of hierarchical levels, specialisation and functional units in the project organisation7.
7 Robbins (1990) echoes the same argument, and further identified geographic dispersion as a component of organizational complexity.
Whereas in the technological perspective of complexity, differentiation would mean the number of diversity in inputs, outputs, tasks or technical specialties. Collectively, Williams referred the two sets of interpretations as “structural complexity” (p.270) which he considers as building blocks of project structure.
Several factors contributing to complexity has been identified by Williams (1999).
The first being interdependence of subsystems, where the coupling pattern between subsystems may be pooled, sequential or reciprocal (based on Thompson, 1967); in particular, reciprocal interdependency intensifies complexity. Williams suggested that reciprocal interdependence arises from concurrent engineering, where there is a high degree of inter-element connectivity in a project, which are often enforced by tight time schedule. Parallel to the work of Gidado (1996), Williams has also sought to view uncertainty as an underlying dimension of complexity. He argued that uncertainty in goals and methods adds to increased complexity.
Evbuomwan and Anumba (1998) offered a definition of concurrent engineering in the context of the construction industry: “Concurrent engineering attempts to optimize the design of the project and its construction process to achieve reduced lead times, and improved quality and cost by the integration of design, fabrication, construction and erection activities and by maximising concurrency and collaboration in working practices” (p.590).
Concurrent engineering has its roots in the manufacturing industry. It is a practice that generates benefits in terms of product development and quality (Ha and Porteus, 1995; Love et al, 1998). However, the effectiveness of concurrency is dependent on:
(a) the organisation’s ability to resolve uncertainty early in the project process (Terwiesch and Loch, 1999)8,
(b) integration of functional disciplines during various stages of design and information (Evbuomwan and Anumba, 1998),
(c) collaboration of upstream and downstream tasks (Peña-Mora and Li, 2001), (d) suitable information process (Love et al, 1998), and,
(e) the use of multi-disciplinary teams (Anumba and Evbuomwan, 1997).
Fazio et al (1988) argued that coordination (between design and construction, and between work packages) and information are two major challenges in concurrency in the construction industry. Concurrency needs to take account of shortage in resources (Morris and Hough, 1987:217) as some production activities are initiated prior to the completion of full-scale development (ibid p.228). Although concurrency may enable more production decisions to be made, it would not endorse starting production before they are sufficiently designed and tested. Hence Morris and Hough warned that “the essential problem of urgency is to know when haste becomes counterproductive”
(p.229).
In reducing project complexity, classic project management techniques of breaking down projects into small components or subsystems are inadequate in accounting for the holistic systemic effects in complex projects (Williams, 1999). The system dynamic approach is suggested. Eccles (1981), on the other hand, suggested subcontracting as one of the means to reduce complexity.
8 This shows that complexity is dependent on uncertainty. Here, the relationship between complexity and uncertainty is one of dependence where uncertainty is the independent variable.
In more recent work, Shenhar (2001) classified projects in terms of a two-dimensional model. Technical uncertainty has been discussed in the previous subsection (§2.4.2). Here, complexity is viewed from a system perspective by focusing on the scope of the system embodied in a project9. The hierarchical nature of systems and their subsystems characterise project complexity. Such hierarchy is typically addressed through the work breakdown structure (WBS), which is a natural follow on from the practice of engineering discipline in addressing engineering design problems.
Activities and work packages in the WBS are budgeted and duration projected in the overall planning process. Shenhar observed that when system scope increases, this process intensifies, becoming more detailed and formal. Based on this conceptualisation, three levels of complexity are identified in Table 2.5.
Table 2.5 – Shenhar’s classification of project complexity
Type Name Description
Scope 1 An Assembly Project This category deals with a single component or a collection of components and modules assembled into a single unit.
Scope 2 A System Project A system is a collection of interactive elements functioning together within single product. A system consists of many subsystems and is capable of performing a wide range of functions.
Scope 3 An Array Project
(or Program) A disperse collection of systems that function together to achieve a common purpose. Such project can be considered a super-system. For example, a national defence system consisting of radar, control centre, aircrafts and missiles.
Source: Shenhar, A. J., 2001, “One size does not fit all projects: Exploring classical contingency domains”, Management Science, 47(3), 394-414
In an assembly project (scope 1), planning, scheduling and project control are
9 In contrast, Gidado (1996) viewed complexity as work process: input, transformation, output.
relatively simple. Documentation is mainly technical with supplementary managerial documents. Systems projects (scope 2) are complex systems. The systems projects studied by Shenhar (2001) had a main contractor who was responsible for the final product. The entire effort was divided in-house or among several subcontractors where the main contractor was responsible for the final integration to meet performance, quality, schedule and budget goals. Systems projects are typically associated with extensive engineering tasks which require careful technical design, numerous testing and reviews, detailed risk and quality management, and extensive systems engineering activities (ibid). Dividing the work among separate subcontractors and coordinating them required considerable managerial efforts, i.e. defining and analysing employer needs, planning the program resources, negotiating with all subcontractors, and instituting a complicated system of coordination, control, decision-making, and information processing. Management in the level of complexity tended to bureaucratise the project by installing a system of procedures, documents, management tools, meetings, reviews and organisation structure. This level is also characterised by complex project controls, extensive reports, meetings and reviews.
The array projects (scope 3) studied by Shenhar (2001) were large scale programs consisting of a number of subprojects. The project organisation’s main function was to set goals, direct and coordinate the individual efforts of subprojects. Management style was very formal with emphasis on the contractual issues. Technical aspects were left to the managers of subprojects.
In a study of failures of complex systems, Ivory and Alderman (2005) have echoed much of the key elements of complexity identified by earlier writers. Both Ivory and Alderman (2005) and Williams (1999) have pointed to the need of using
multi-disciplinary skills of different engineering disciplines to tackle complexity. In summary, project complexity is associated with (Ivory and Alderman, 2005):
(a) the technological system itself, (b) tight couplings of subsystems,
(c) interdependencies between project elements, and,
(d) complex interactions between elements, both in linear and non-linear manner that results in the lack of equilibrium state10.
Table 2.6 – Perspectives of technical complexity
Scholar Key Concept Dimensions / Taxonomy
Baccarini (1996) Many varied interrelated
parts y Organisation complexity is a result of differentiation (vertical and horizontal) and interdependence.
y Technological complexity arises from diversity of tasks, concurrency and interdependence.
Gidado (1996) Difficulty of implementing planned production work flow in relation to
quantifiable objectives
y Task complexity relates to resource, technology, constraints and
uncertainty.
y Process complexity relates to workflow of tasks, task overlap, interdependence and sequencing.
y Quantifiable objective being time, cost and quality.
Williams (1999) Structural complexity as composed of differentiated organisation functions and technical specialties.
Uncertainty is a dimension of complexity.
y Dimension of structural complexity:
no. of elements and interdependence.
y Dimension of uncertainty: goals and means.
Shenhar (2001) System scope (hierarchy) y Assembly y Systems y Array Ivory & Alderman
(2005) Interaction between
elements y Technology itself
y Tight coupling y Interdependence y Lack of equilibrium state
10 Williams (1999) also characterized technological complexity as non-linearity and lack of equilibrium state.
Different perspectives of complexity in project management are summarised in Table 2.6. From the above review of literature, two levels of complexity can be deduced.
The system-wide level considers large modules, components, subsystems (e.g.
Shenhar, 2001; Ivory & Alderman, 2005) and workflow sequencing (Gidado, 1996). The second level, being a micro view, looks at the tasks or activities in detail and considers the level of technical knowledge required (e.g. Baccarini, 1996; Gidado, 1996). Central to both levels is the differentiation (number of elements, subsystems, tasks, activities) and the interaction or connectivity (type of interdependence, concurrency and task sequence) between them. Based on the preceding review of literature, we outline and summarise the factors that increase and decrease complexity in projects in Table 2.7 and Table 2.8.
Table 2.7 – Factors increasing technical complexity
Factors Scholar
1. Ç Uncertainty Gidado (1996)
Williams (1999) 2. Ç Scope and scale / large number of
elements Shenhar (2001)
Shenhar and Dvir (1996)
Pich, Loch and De Meyer (2002) Ivory and Alderman (2005) Williams (1999)
3. Ç Interdependence / inter-element
connectivity Baccarini (1996)
Gidado (1996) Williams (1999)
Pich, Loch and De Meyer (2002) Ivory and Alderman (2005) 4. Ç Differentiation / diversity in project
parameters / input, output, technical specialty
Baccarini (1996)
Pich, Loch and De Meyer (2002) Williams (1999)
5. Ç Concurrency Baccarini (1996)
Williams (1999)
How does the above relate to design-build projects? A predominant feature of
design-build project is the undertaking of design and construction by a single entity.
Employers of traditional DBB often play a coordinative role between the designer and the builder. To the DB project organisation, what was an external interface between the designer and builder under DBB is now within the scope of work of one entity. This change in relationship between design and construction typically becomes a cross-functional effort with the project organisations facing a broader frame of interface and enlarged scope of project work.
Table 2.8 – Factors decreasing technical complexity
Factors Scholar
1. Planning and control Gidado (1996)
Shenhar and Dvir (1996) Shenhar (2001)
2. Use of multi-disciplinary teams Williams (1999)
Ivory & Alderman (2005)
Anumba and Evbuowman (1997) Love, Gunasekaran and Li (1998)
3. Subcontracting Eccles (1981)
Shenhar and Dvir (1996) 4. Integration (incl. coordination) Baccarini (1996)
Morris (1988)
Evbuowman and Anumba (1998)
Fazio, Moselhi, Théberge and Revay (1988) Peña-Mora and Li (2001)
Williams (1999) Shenhar (1998) 5. Systems engineering techniques Shenhar (2001)
Shenhar and Bonen (1997) 6. Limit system size, clustering, reduce
interdependence
Mihm, Loch and Huchzermeier (2003) Nicolini, Holti, and Smalley (2001) 7. Information process Anumba and Evbuowman (1997)
Love, Gunasekaran and Li (1998)
Fazio, Moselhi, Théberge and Revay (1988) Pich, Loch and De Meyer (2002)
Mihm, Loch and Huchzermeier (2003) Bogus, Molenaar and Diekmann (2005) Shenhar (2001), Shenhar and Dvir (1996) Denker, Steward and Browning (2001)
By viewing the DB project as an operating system consisting of subsystems, one can broadly conceptualise the DB project as being composed of design and construction subsystems. It is widely accepted that an increase in the number of project elements (at technical level), causes the project to be more complex (Gidado, 1996;
Baccarini, 1996; Williams, 1999; Austin, Newton, Steele and Waskett, 2002). This is a direct result of interdependence between subsystems (Thompson, 1967).
In contrast with the traditional DBB delivery method, each project (design and construction) is relatively less complex in terms of its project management scope. DB broadens the scope of tasks that must be performed by a single project and hence its complexity is higher than that of DBB (Shenhar, 2001). Project complexity is further increased by packaging dislike tasks, engineering disciplines and specialist trades together. Under such arrangements, project managers must expand their control to encompass unfamiliar communities of practice, technology and knowledge, while managing this network to deliver results (Ivory and Alderman, 2005:6). From a market perspective, design-build resembles vertical integration (Eccles, 1981). This can be achieved by the designer integrating backward to command more control of the construction activity, or, the builder integrating forward to gain control of design activity.
2.4.4 Brief summary
We have identified from project management literature two dimensions of the technical systems in projects. Technical uncertainty may be related to uncertainty in goals and means (Gidado, 1996), or as newness of technology embodied in the project (Shenhar, 2001). Varying levels of uncertainty maps onto different styles of project management characterised as a continuum ranging from mechanistic to organic styles
(De Meyer et al, 2002). Technical complexity can be broadly conceptualised in terms of differentiation and interdependence (Baccarini, 1996). As project scope increases, interactions between subsystems become more complex. Complexity is further exacerbated by overlapping the execution of project activities which may pose difficulty in sequencing, coordinating and integrating the work packages.
We have reviewed and identified some of the important structural devices used to tackle technical uncertainty and complexity. This includes integration, differentiation and information processes, discussed in the next section.