Technical uncertainty

A project is a unique endeavour (Dvir, Raz, Shenhar, 2003:90), to which a lack of precedence is common. These properties expose project organisations to great amounts of uncertainty that impacts a multitude of aspects in project management; for example, in project planning (Gidado, 1996). It has been accepted in the literature that projects are vehicles to reduce uncertainty (Turner and Müller, 2003; Shirazi et al, 1996).

In a study of 8 major projects, Morris and Hough (1987) related technical uncertainty with the lack of means to technically achieve project objectives (p.211). This may be associated with the use of innovative technology and changes in project objectives forced by the direction in which technical means develop. Williams (1999) categorised project uncertainty as goal or method uncertainty and argued that uncertainty is a dimension of project complexity (p.270). Such kinds of uncertainty cause the project work to become difficult and its outcome unpredictable, hence increasing the overall level of project complexity. Turner and Müller (2003) expanded the concept and included outcome in their conceptualisation of uncertainty (i.e. taking a holistic view of project process).

It is characteristic of project uncertainty to be highest at the project inception and gradually decrease as project details are developed over various phases of the project

(PMI, 2000:12; Adams and Barndt, 1988:214). Essentially, as the project organisation processes more information and learn more about the project requirements, the level of uncertainty decreases as the amount of information accumulates.

In most engineering projects, input is vastly associated with the employer’s requirements.⁵ Comparative to the DBB delivery method, where design and specification are fully developed, DB inputs are more abstract in nature. Interpretation of employer needs, understanding of functional and technical performance requirements, functional inputs from interface contractors, and, clarity of employer’s scope and specification have been found to impact the DB process (Chan et al, 2001:97; Ling et al, 2003; Gidado, 1996:216; Songer and Molenaar, 1997:38).

Uncertainty in the project processes to achieve project goals may be due to results of project elements that are stochastic and lacking in knowledge (Williams, 1999:271).

The effect may compound as indeterminate processes are likely to induce changes as project events unfold, until such a time that the processes become determinant; i.e., a decision is made (Stinchcombe and Heimer, 1985). It is also an attribute of uncertainty that changes in a project will require interfacing elements to make corresponding changes as well (Williams, 1999:271). Such cross-impact may form a feedback loop which increases complexity of the project (ibid). It follows that uncertainty experienced at the input may become elaborated in the project process if left unresolved.⁶

5 The employer in this thesis is viewed in a broad context that includes other contractors employed by the employer. Such contractors may have functional interface with any given project in question and poses additional inputs to the project process.

6 For example, in Kaohsiung Metro (Red and Orange Line), we observed that detailed designs developed by the design-builder are subject to review and approval of the employer before design implementation.

Project progress was partially stalled by divergent, ambiguous or non-concrete design comments from the employer and interfacing contractors (a form of uncertainty). Design-builders were unable to plan its work with inputs having minimal utility. This situation propagated until design was confirmed. The contractor

Uncertainty bears a ripple effect, particularly, on interfacing elements, be it technical, contractual or organisational.

The outcome effect of uncertainty include overrun budget, heavy demand on project schedule, conflicts, poor commercial performance on the part of the contractor, and reduced quality (Morris and Hough, 1987).

Shenhar (2001) associated technical uncertainty in engineering projects with the

“degree of using new versus mature technology within the product or process produced”

(p.397). Based on this conception, four levels of technical uncertainty at project inception have been proposed by Shenhar (see Table 2.2). In his framework, technical uncertainty increases as the amount of new technology embodied in the project increases (corresponding to decrease in use of mature technology). Project processes, such as design cycles and testing, were observed to increase with the level of technology (Shenhar, 1997:141). Management styles (i.e. coordination mechanisms, information flow and intensity, bureaucracy) moved along a continuum of rigidness to flexible adaptation.

Shenhar’s operation of uncertainty using “percentage of new technology” has received some criticism by Williams (1999). Attempts to quantify technology in the engineering discipline may be difficult. Moreover, technical projects often employ a range of technologies within a system, as would units within organisations adopt different operating technologies.

suffered from loss of time and rework.

Table 2.2 – Shenhar’s classification of technological uncertainty

Type Uncertainty level Level description

A Low Technological Uncertainty

(Low-Tech)

All technologies are well known, well established and considered base technology. Typical projects are construction, road, bridges and utility installation. Many such projects are built to print.

B Medium Technological Uncertainty

(Medium-Tech)

Adaptation of familiar technologies, type B project mainly uses mature technology (less than 50% of new technology embodied).

Examples are development of new model in a well-established industry or improvements, modifications or upgrades such as automobiles.

C High Technological Uncertainty

(High-Tech)

Type C projects integrate many new, but existing, technologies and involve more than 50% of new technology. Incorporating new technology for the fist time typically leads to products that do not exist in the past, or even new to the industry. Computers, military systems are examples.

D Super High Technological Uncertainty

(Super High-Tech)

This category of projects require development of new technologies that does not exist at the time of project initiation, some may be emerging. An example of such project would be the Hubble Space Telescope.

Source: Shenhar, A. J., 1998, “From topology to practice: Toward a typology of project-management styles”, IEEE Transactions on Engineering Management, 45(1), 33-48; Shenhar, A. J., 2001, “One size does not fit all projects:

Exploring classical contingency domains”, Management Science, 47(3), 394-414

Table 2.3 – Technological uncertainty, project management style and communication Project Type Project Management Style Communication A – Low Tech. Formal and rigid. Main concern is to

finish the project on time and within budget.

Formal channels.

B – Med. Tech. Moderate firm style. Ready to accept changes. Increased interaction.

Regular meetings of management team and subcontractors with ad hoc meetings and phone discussions.

C – High Tech. Flexible with extensive trade-offs.

Expecting many changes. High interaction.

Intense formal and informal communication. The majority flow of information was oral.

D – Super High Tech.

High levels of flexibility and tolerance for change. High awareness of potential problems. Share immediate information; extensive interaction.

Control changes and risks.

Continuous flow of enormous amount of information and extensive communication.

Adapted from Shenhar, A. J., 1997 “The new taxonomy of systems: Toward an adaptive systems engineering framework”, IEEE Transactions on Systems, Man, and Cybernetic – Part A: Systems and Humans, 27(2), 137-145; Shenhar, A.

J., 2001, “One size does not fit all projects: Exploring classical contingency domains”, Management Science, 47(3), 394-414

Against each project type, we tabulate the project management style and means of

communication in Table 2.3. At lower ends of uncertainty, communication tends to be more bureaucratic (as in projects type A and B). The volume of information flow increased with increasing levels of uncertainty (as in projects type C and D).

A different perspective of project management style with respect to project uncertainty was proposed by De Meyer, Loch and Pich (2002). They identified four levels of uncertainty: variations, foreseen uncertainty, unforeseen uncertainty and chaos.

Parallel to the work of Shenhar (1997, 1998 and 2001), De Meyer et al also observed similar patterns of management styles under varying degrees of uncertainty, featured as an uncertainty profile (see Fig. 2.5). The profile shows that increasing levels of uncertainty is matched by more organic styles of management; low levels of uncertainty are matched by an orientation towards mechanistic styles.

y Planning and anticipation y Learning and response y Exchange of structured information

along defined interfaces

y Exchange of unstructured information along emerging interfaces

y Fulfilment of targets y Flexible use of methods to reap upside rewards

y Tracking progress y Tracking assumptions and unknowns

Fig. 2.5 – Uncertainty profile

Adapted from: De Meyer, A., Loch, C. H., Pich, M. T., 2002, “Managing project uncertainty: From variation to chaos”, MIT Sloan Management Review, 43(2), 60-67

Chaos

We summarise the various perspectives of project uncertainty in Table 2.4, and outline their key concepts. In summary, we observe that technical uncertainty at the project level is process-driven, with coupling effects between input and output related to the technology, or scientific means employed in project execution. The technology itself may be well developed (being a mature science), or innovative (where there is little knowledge about the technology). Shenhar’s (1997, 1998 and 2001) framework of technical uncertainty is sound, but offers little clarity in how “new technology” is quantified (Williams, 1999), despite outlining qualitative attributes. Furthermore, the concept appears to be based on the dominant technology embodied in a project, which according to Robbins (1990) overlooks variations of other technologies employed in the project’s subsystems. Hence, Shenhar’s framework can be taken one step further by focusing on the subsystems in assessing the technology-structure relationship in projects.

Table 2.4 – Perspectives of technical uncertainty

Scholar Key Concept Categories

Morris & Hough

(1987) Lack of technical means to achieve project objectives.

Use of innovative technology.

---

Williams (1999) Uncertainty in goals and methods Goals Methods Tuner & Müller

(2003) Uncertainty at input, process and outcome --- Shenhar (1997,

1998, 2001) Use of new vs. mature technology Low tech.

Medium tech.

High tech.

Super-high tech.

De Meyer, Loch, Pich (2002)

Project management techniques Variations

Foreseen uncertainty Unforeseen uncertainty Chaos

The implication of technical uncertainty on structure is evident from the above discussions. Uncertainty is reduced by making information available to those affected by the lack of information. This indicates that the project needs to have an adequate system of communication in place in order to keep the information flowing. We observe that the level of uncertainty reduces with time, but whether such relationship is linear or curvilinear remains to be tested.