SciELO - Scientific Electronic Library Online

 
vol.28 issue3 author indexsubject indexarticles search
Home Pagealphabetic serial listing  

Services on Demand

Article

Indicators

Related links

  • On index processCited by Google
  • On index processSimilars in Google

Share


South African Journal of Industrial Engineering

On-line version ISSN 2224-7890
Print version ISSN 1012-277X

S. Afr. J. Ind. Eng. vol.28 n.3 Pretoria  2017

http://dx.doi.org/10.7166/28-3-1838 

GENERAL ARTICLES

 

Application of systems engineering concepts to enhance project lifecycle methodologies

 

 

P.B. Mabelo*; B.P. Sunjka

School of Mechanical, Industrial and Aeronautical Engineering, University of the Witwatersrand, Johannesburg, South Africa

 

 


ABSTRACT

Large Infrastructure Projects (LIPs) drive economic growth through both their construction phase (e.g., job creation) and their successful outcomes (e.g., better services). Numerous and recurrent unsatisfactory outcomes of LIPs indicate that traditional project management has not necessarily kept pace with new developments - especially with the ever-increasing complexity of the projects. Massive costs and schedule overruns on such projects attest to the severity of this problem. Similarly, instances of substantial changes to the initial project scope suggest that modern project management approaches would require enhancements to be applicable and sustainable in the future. Systems engineering, as a discipline and as a way of thinking, is gaining popularity and acceptance in its applications to LIPs. This is due to the benefits emerging from its ability to manage escalating complexity, particularly in large and complex projects such as transportation (e.g. railways, ports), energy, and water infrastructure projects. This article has considered Systems Engineering principles and concepts (e.g., lifecycle, requirements verification and validation) for incorporation by way of enhancements into a holistic project lifecycle model that improves delivery effectiveness.


OPSOMMING

Groot infrastruktuurprojekte is 'n dryfveer vir ekonomiese groei tydens die konstruksiefase (as gevolg van werkskepping) sowel wanneer dit suksesvol voltooi is (as gevolg van verbeterde dienslewering). Vele herhalende onbevredigende uitkomste van groot infrastruktuurprojekte dui dat tradisionele projekbestuur nie tred gehou het met nuwe ontwikkelinge nie, veral met die toenemende kompleksiteit van die projekte. Massiewe koste en skedule oorskrydings getuig van die erns van die probleem. Hiermee saam dui noemenswaardige veranderinge aan die aanvanklike projek omvang daarop dat hedendaagse projek-bestuurbenaderings verbeter moet word om toepaslik en volhoubaar in die toekoms te wees. Stelselingenieurswese, as beide 'n dissipline en 'n denkwyse, kry al hoe meer aanvaarding en erkenning in die toepassing daarvan in groot infrastruktuurprojekte. Dit is as gevolg van die voordele voortspruitend uit stelselingenieurswese se vermoë om die toenemende kompleksiteit geassosieer met groot infrastruktuurprojekte, soos vervoer, energie en water, aan te spreek. Hierdie navorsing oorweeg stelselingenieurswese beginsels en konsepte, soos lewensiklus, vereiste-verifiëring en -validasie, vir insluiting in 'n holistiese projek lewensiklus model wat dienslewering verbeter.


 

 

1 INTRODUCTION

A 2013 KPMG Report [01] suggests that the increase in annual water demand in Sub-Saharan Africa may reach 440 billion m3 by 2030 - a staggering 283 per cent more than in 2005, whereas China or India would only increase demand in volume by ± 60 per cent. It is no wonder that infrastructure expenditure in Sub-Saharan Africa (SSA) is expected to increase by 10 per cent on a year-to-year basis, from US$ 70 billion in 2013 to US$ 180 billion by 2025, with South Africa and Nigeria accounting for the bulk of this expenditure [02]. Rather than being a reason to celebrate, these facts simply mean that Africa will need (to borrow) capital to fund large infrastructure projects (e.g., railway connections, power generation and distribution, telecommunication cables/lines, water and sanitation) to address these challenges.

These large infrastructure projects (LIPs) are critical to, and have an impact on, the macro-economy of the host country in terms of job creation, opportunities for export boost (or reduced imports), and contributions to economic growth [03]. LIPs contribute to the national economy (i.e., GDP growth) both during construction and through their positive outcomes [04]. When well-executed, infrastructure projects bolster economic growth in two ways: "Investments in modern infrastructure lay the foundations for economic development and growth. {1} Building roads, bridges, power transmission lines and making other improvements create jobs. {2} When completed, these projects help a society increase its wealth and its citizens' standard of living" [04].

The planning, development, and execution of such project initiatives present high risks, complex issues, and challenges and disillusionments, judging from the unsatisfactory outcomes common to such projects [05]. "The megaproject market is worth about $9-trillion each year, and globally big builds are in a mess. It is rare to have one completed on time and on budget" [06]. According to the Independent Project Analysts (IPA), "Data from more than 300 global megaprojects shows that 65 percent of industrial projects with budget larger than $ 1 billion in 2010 U.S. dollars failed to meet business objectives. In some industrial sectors the failure rate was as high as 75 percent" [03].

The danger of this high rate of infrastructure project failure (and abandonment) is that it could spell economic disaster for many countries. Project failure (when recurrent) has dire consequences for all involved: first and foremost the project management team themselves, whose job, reputation, and morale could suffer harm; and secondly, the owner or parent organisations could suffer capital loss, negative equity, forfeited business opportunities, commercial liabilities and lawsuits, or reputational damage. Thus a country that has invested in a string of 'white elephant' (i.e., unproductive, economically non-viable albeit politically laudable) or doomed projects will end up in fiscal failure, unable to honour its debt liabilities, with lost opportunities for GDP growth.

The widespread and persistently unsatisfactory outcomes of large infrastructure projects in both private and public sectors may indicate that traditional project management has not necessarily kept pace with new developments, and in particular with the increasing complexity of projects. Wood and Ashton [07] contend: "It is a common statement that the construction industry process is one of the most complex and risky businesses undertaken, however it has also been suggested that the construction industry has developed great difficulty in coping with the increasing complexity of major construction projects".

While project complexity in itself is but one dimension of attaining project success, Baccarini [08] maintains: "The significance of project complexity to project success or otherwise cannot be underestimated, hence the compelling need to allow for a thorough understanding of the inherent complexities in an infrastructure delivery system". Chronic delays and cost overruns on recent multibillion projects, locally and abroad, attest to the high prevalence and severity of the issue [06] [09]. Thus relying on an ineffectual project management methodology that fails to match the complexity of projects to their capital portfolio may prove counterproductive (if not fatal) to companies and governments alike.

Systems engineering (SE), as a discipline and as a way of thinking, is gaining popularity and acceptance in its application to LIPs. This also follows from the benefits emerging from the ability it affords in matching the high level of complexity experienced in transportation projects such as railways, port terminals, and pipelines (among many others) that the industry generally classifies as LIPs [10]. Due to the increasing complexity of their projects, the Dutch civil engineering sector has been using SE for a decade. As a result, the sector is undergoing a transition where the support base for, and the application of, SE have increased in recent years. This is because organisations realise that SE helps them make projects more controllable, and allows them to be set up more efficiently [11].

The judicious application of systems engineering concepts to LIPs should thus provide significant benefits beyond the current boundaries of the established project management body of knowledge (PMBoK).

This paper aims to establish what specific systems engineering principles and concepts could enhance the current project lifecycle methodologies through surveying key industry project management professionals who are involved in LIPs.

 

2 LITERATURE REVIEW

2.1 Project management

A project is commonly defined in the industry's literature as "An endeavour in which human, material and financial resources are organised, in a novel way, to undertake a unique scope of work, of a given specification, within the constraints of cost and time, so as to achieve a beneficial change defined by quantitative and qualitative objectives" [12]. The Project Management Institute (PMI) defines project management as "the application of knowledge, skills, tools, and techniques to project activities in order to meet project requirements" [13]. The key to this definition is the emphasis on 'meeting project requirements'.

This point of emphasis appears to be one of the key challenges affecting traditional project management: modern projects consistently fail to achieve satisfactory outcomes in meeting stakeholders' requirements [05], nor do they fall within the constraints of the agreed budget, schedule, and scope [14]. A recent PricewaterhouseCoopers (PwC) report [15] attributes budget overruns primarily to inadequate project management, with changes in requirements being the fourth highest contributor. As pointed out in Systems engineering for intelligent transportation systems [16], "late changes drive project costs". Changed orders during construction are more expensive to the project. A mistake or missed system feature that is not recognised until after project closeout will be even more expensive to address.

 

 

In numerous attempts to prevent or mitigate project failure, academia and practitioners have proposed cures and remedies [13] [17], including combinations of the following:

a. refining the processes and procedures (e.g., project methodologies);

b. improving the tools and techniques (e.g., PM information systems);

c. developing competencies and culture (e.g., skills and mind-set); and

d. defining reporting and responsibilities (e.g., project structures, roles).

While the implementation of these recommendations to project activities has led to a degree of standardisation of the profession and increased project success, the same cannot be said about the successful delivery of LIPs. In terms of processes, a noticeable step in the right direction was in parting with the "rush to get the substance of the project under way" [17], and the adoption of lifecycle-based project delivery methodologies. The LIP industry has experienced a marked increase in the level of awareness of the benefits and practice of the lifecycle model. These marginal 'overall improvements' would, however, suggest that such interventions, though workable and useful, are not comprehensive enough to prove effective. It has already been argued that something more structural (a more systemic approach) might be needed effectively and substantially to address delivery issues that still lead to project failure.

Traditional project management is based on 'analytical thinking', which is deficient in dealing with complexity in large infrastructure projects. Wood and Ashton [07] contend: "Although a number of systems exists to evaluate construction projects such as risk assessment methods, no system designed specifically to measure and evaluate the complexity of a project at the pre-construction stage exists". They further argue that "being able to measure the complexity at an early stage in a project will lead to a better understanding of the project and therefore could be of great benefit in successfully managing projects and reducing the risks associated with complexity" [07].

This leads to the examination of complexity as a cause of project failure, particularly for construction projects such as LIPs. Since these are large, complex projects, many problems encountered are similar to those that arise in complex systems in general [10]. The inherent complexity of LIPs arises from their emergent behaviour. "A fundamental reason for the difficulties with modern large engineering projects is their inherent complexity. Complexity is generally a characteristic of large engineering projects today. Complexity implies that different parts of the system are interdependent so that changes in one part may have effects on other parts of the system. Complexity may cause unanticipated effects that lead to failures of the system, and in terms of emergent collective behaviours of the system as a whole. Such behaviors are generally difficult to anticipate and understand" [18].

Furthermore, the complexity of a system is usually determined by the number of parts or activities, the degree of differentiation between the parts, and the structure of their connections. Complex systems have multiple interacting components whose collective behaviour cannot be simply inferred from the behaviour of the individual components [19]. Modern 'man-made' systems, and 'system of systems' (SoS) (i.e., independently useful systems incorporated into a larger system that delivers unique capabilities), continually increase in complexity. These systems are developed, and increasingly so, by partnerships involving multiple suppliers and developers and, very often, geographically dispersed teams, involving several key stakeholders with conflicting concerns and interests.

2.2 Systems engineering

Systems engineering (SE) is an interdisciplinary approach and a way to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, on documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, schedule and cost, performance, training and support, test, manufacturing, and disposal [20]. According to the NASA systems engineering handbook [21], systems engineering is "[a] disciplined approach for the definition, implementation, integration and operation of a system (product or service) with the emphasis on the satisfaction of stakeholders functional, physical and operational performance requirements in the intended use environment over its planned life cycle within cost and schedule constraints".

This is a departure from traditional project management, which emphasises the 'construction of a physical asset' as opposed to a 'system' satisfying stakeholders' functional, physical, and operational performance requirements in the intended use-environment. Blanchard [22] comments that these techniques provide fully integrated solutions for the management of complex projects by capturing the functional requirements and effectively managing them through the project lifecycle.

SE is undergoing major developments as part of infrastructure projects. The approach is widely recognised, and project entities are gradually adopting it; yet a comprehensive framework that meaningfully encapsulates project management and systems engineering principles, concepts, and practices is not readily available [11].

The International Council on Systems Engineering (INCOSE) Infrastructure Working Group published a Guide for the application of systems engineering in large infrastructure projects in 2012 [10]. It seeks to reposition the traditional SE practices - it has been successfully developed and applied in the military, aerospace, manufacturing, and telecommunications industries - into the context of the construction industry, and thereby provide professionals engaged in LIPs with convenient and comprehensive access to the relevant parts of the system engineer's toolkit. The application of SE practices throughout the entire lifecycle, to both 'design and development' and 'construction', is in line with the works of the INCOSE Transportation Working Group through the publication of Systems engineering in transportation projects - A library of case studies [23]. The compilation of case studies from systems engineering applications to transportation projects (e.g., LIPs) [24] has confirmed the benefits of using SE principles and practices, among others, in managing project requirements, risks, and stakeholders throughout the entire project lifecycle.

One such SE concept could consist of the application of the soft systems methodology (SSM) to address the seemingly "wicked" problem of eliciting and elucidating the owner's requirements at the earliest stages of the project lifecycle, at a point when both problems and solutions are intrinsically messy, poorly structured, and therefore hard even to formulate. In LIPs, the potential of SSM lies particularly in the early stages of a project to assist stakeholders to achieve a common understanding of the problem situation [25]. Indeed, "construction is ultimately a very complex, multi-disciplinary activity and there is a need to integrate the kind of design and management processes in terms of skill and the knowledge that people bring" [26]. This learning paradigm will help to address unstructured requirements, or conflicts that arise where there are competing claims, needs, and concerns.

Moreover, SE practices such as requirement management, verification and validation (V&V), stakeholder management, and asset lifecycle considerations could be embedded in the project lifecycle methodology. Instead of randomly applying SE principles and concepts to some areas of LIPs delivery, this study considered the application of SE elements to the project lifecycle itself, which represent the "racetrack" of project delivery [27]. This could improve the management of the systems requirements throughout the lifecycle, from concept to operations to eventual disposal.

 

3 RESEARCH METHOD

To address the primary objective of this study - that is, to establish what specific systems engineering principles and concepts could enhance the current project lifecycle methodologies - an on-line survey of key industry project management professionals involved in LIPs was conducted. This study thus needed to target project personnel with knowledge about, or experience in, large infrastructure projects in Southern Africa and/or in systems engineering. The primary data for eliciting enhancement propositions, therefore, needed to be obtained from a very specific group of respondents (e.g., representatives of LIPs industry and subject matter experts). Purposive sampling was thus used, as the results of this type of sampling are usually more representative of the target population than other sampling methods [28]. The researcher relied on available networks (e.g., fellow project managers, colleagues, database entries) in Southern Africa to reach potential respondents for the survey.

In total, 22 respondents - experienced project professionals selected from 19 different entities operating in Southern Africa - participated in the survey. They were drawn from the public sector (41 per cent), the private sector (54.5 per cent), and the non-profit sector (4.5 per cent). It is estimated that together these entities have allocated R 800+ billion (around US $ 50 billion) to capital projects for the next three to five years. In terms of industry classification, almost half (40.9 per cent) the entities surveyed were involved in infrastructure projects, while ICT and related and minerals and mining represented 27.3 per cent and 13.8 per cent respectively. Of the respondents, 63.6 per cent were from an in-house PM team, while 9.1 per cent were from a procurer of PM, 9.1 per cent from a supplier of PM, and 18.2 per cent from a PM contractor. The data collected thus reflected a wide spread of the LIP industry, and could inform the applicability of the recommendations

The survey was structured in five sections as follows:

(1) General information: to classify respondents into groups of project characteristics to analyse the demographics;

(2) Project life cycle methodology: to determine the adequacy of the lifecycle model in use in the project delivery entity;

(3) Principles and concepts of the methodology: to determine the extent of the incorporation of SE principles and concepts in the methodology;

(4) Project delivery process: to determine the extent of the application of SE practices and the resultant overall project performance outcome; and

(5) Readiness to improve project delivery: to establish the readiness and willingness of the organisation to adopt/improve SE applications.

Statistical analysis was applied to the Likert-coded responses of the survey to determine the frequency of a specific question. In some cases, the distribution of 'Strongly Agree' and 'Agree' were combined to indicate the extent of general agreement.

The Conbach's alpha coefficient calculation yielded a value of 0.92425. With this coefficient close to 0.95, the survey questionnaire was deemed valid and the results highly reliable; and so it could be used for data analysis.

A correlation analysis using the Pearson (r) coefficient in Excel was conducted. These correlations reflect how the agents (i.e., the lifecycle elements) in the delivery system interact in apparently random ways. Yet from all such interactions, patterns might emerge that inform the behaviour of the agents within the system and the behaviour of the overall delivery system itself. Therefore, the overall behaviour of the project lifecycle methodology (a system in its own right, according to Eduardo [29]) could be interpreted from sets of mutual relationships among its many elements. These are determined using the coefficient of correlations and mapping that constitutes the correlation map. Such a map could evolve into a standardised tool for measuring the systems-completeness (i.e., the adequacy) of SE-based project lifecycle methodologies.

The correlation map was constructed by drawing connections between critical lifecycle elements (as reflected in the survey questionnaire) that show a strong coefficient of correlation. According to Levine [30], a strong correlation indicates the tendencies present in the data, and does not necessarily indicate a causal relationship. The coefficient of correlation indicates a relationship or association between two numerical variables. Sets of numerical variables arise from Likert-coded responses to the same set of survey questions. Relationships among variables are displayed by cross-tabulation and correlations [31]. When the coefficient of correlation gets closer to +1 or -1, the relationship between the two variables is stronger (i.e., directly or inversely correlated) [30]. Salkind [32] argues that ±0.6 is a strong factor - this study has set a ±0.69 threshold (i.e., above +0.69 and below -0.69 for positive and negative correlations respectively).

 

4 RESULTS

4.1 Survey results

The survey results are summarised in Sections (2) to (5) below, using the following key:

4.1.1 Section (2) - Project lifecycle methodology (Questions Q11 to Q19)

The lifecycle methodology bar chart (Figure 2) indicates that most respondents largely agree with most of the survey statements, particularly the statement, "Your organisation uses a project lifecycle methodology" (Q11). However, there is less agreement about the inclusion of disposal matters (Q15) and full understanding of such methodology (Q19).

4.1.2 Section (3) - Principles and concepts of the methodology (Questions Q20 to Q28)

The principles and concepts of methodology bar chart indicates that most respondents largely agree with most survey statements, and no respondents responded with 'strongly disagree', except to the statement, "Project personnel are exposed to systems thinking" (Q28). However, they also appear to agree less about discussing linkages between projects at the outset (Q21), and testing outcomes of phases against requirements (Q27).

 

Figure 3

 

4.1.3 Section (4) - Project delivery process (Questions Q29 to Q37)

The project delivery process bar chart indicates that respondents largely agree on treating stakeholder management and risk management as core activities (Q30, Q31), and to a lesser extent that the outcome of most of their projects meet business objectives and are completed to specifications (Q34, Q35). Still, they appear to disagree with the remainder of the statements, particularly about completing projects "on time, on budget" (Q36).

 

Figure 4

 

4.1.4 Section (5) - Readiness to improve project delivery (Questions Q38 to Q46)

The readiness to improve project delivery bar chart indicates that most respondents largely agree with most survey statements, particularly with the statements, "Project personnel agree that projects do support strategy" (Q38) and "Management regularly discusses project performance" (Q43). However, they appear to agree less about the remainder of the statements. Statement (Q40) reflects a particularly strong disagreement with a negative assertion - "Project personnel are NOT satisfied with methodology" - which actually indicates an affirmative outcome, a positive stance.

 

Figure 5

 

4.2 Correlation map

A correlation analysis between and among the various participants' responses was conducted to determine to what extent some answers with strong reciprocal correlation could provide insight into any linkages between elements of a generic lifecycle (captured in the various questions). Linkages determine overall behaviours of SoS [33]. A coefficient of correlation table was developed between every two sets of responses to establish their degree of correlation; any sets with strong correlation factors (equal to or above 0.70 in absolute value) were identified as significantly correlated.

The correlation patterns arising from the various lifecycle elements were consolidated into a correlation map (Figure 6) to identify which particular lifecycle elements might reflect significant leverage (i.e., a nodal point). This was based on the realisation that the delivery system (i.e., interacting lifecycle elements) is actually a complex adaptive system (CAS). The project lifecycle infrastructure (containing most of the 22 project lifecycle elements) is considered a complex adaptive system (CAS) because: (i) "As a response to this changing world, the project based organization (PBO) is emerging as a feasible option to companies and organizations in general in order to cope with the complexities and uncertainties of the environment. In this approach, the project as an autonomous agent and the project portfolio as a complex adaptive system (CAS), not the static company or organization, are put at the core of the system" [08]; and (ii) "Complex adaptive systems (CAS) exhibit coherence under change, interacting and exchanging information with the changing environment, not necessarily with a central coordination, having leverage points, where a low quantity of input may lead to significant changes" [29].

The correlation map (Figure 6) reflects two types of 'nodes' (i.e., lifecycle elements) that are colour-coded as a blue node [  ] and a red node [  ]. The blue node represents any ordinary node that connects two or more lifecycle elements, whereas a red node (or precursor element) will embody a specific node from which linkages will originate. These nodes thus constitute starting blocks. It follows that any errors, inadequacies, or flaws in the scope, design, or implementation of any such precursor elements could have a major impact on the overall behaviour of the project lifecycle model (i.e., a complex adaptive system). These leverage-points are to be given strict attention.

4.2.1 Results of correlation map analysis

Precursor nodes (i.e., CAS leverage points) that drive project lifecycle infrastructure deployment, identified via the project lifecycle model correlation map, are as follows:

 

Figure 7

 

Based on the industry survey, many of the entities surveyed do not, or only poorly, practise most of the above-mentioned 'vital' lifecycle elements, as the table below indicates.

 

 

5 DISCUSSION

The survey revealed a number of insights. The respondents answered most 'lifecycle' questions, spread across the whole Likert scale (i.e., from strongly disagree to strongly agree). This reflects the discriminative nature of the parameters conveyed in those questions; otherwise, most respondents would have picked a fail-safe option such as 'cannot tell' to most questions.

Based on Questions Q09 ("Your organisation has clear, documented strategic 'goal's' and most projects are specifically linked to such") and Q38 ("Project personnel agree that projects do support strategy"), it may be inferred that most entities surveyed (77 per cent) have a clear, documented organisational strategy and that projects are specifically linked to their goals. A majority (73 per cent) are also aware that their projects are meant to support strategy implementation. There seem to be many instances (36 per cent), however, where infrastructure projects are managed at 'multiple levels' of the entity (Q03 ("Capital projects are managed at ...")). This may indicate that various spheres within the same organisation are allowed (and perhaps set up) to deliver capital projects.

Capital division or capital department structures that focus on delivery of capital projects manage only 27 per cent and 23 per cent of such infrastructure projects respectively.

Most entities surveyed (86 per cent) use a lifecycle methodology, and since the majority (77 per cent) manage a capital portfolio including 'big and small' projects, there is a need to establish a scalability process or tool (Questions Q07 ("Granularity of projects in portfolio") and Q11 ("Your organisation uses a project lifecycle methodology")). It may seem, thus, that tailoring (e.g., scaling up or down) a lifecycle methodology to suit the profile of any particular project will prevent any detrimental mismatch between lifecycle requirements and the profile of the project under consideration. Also, most entities (64 per cent) using a project lifecycle methodology have adopted a lifecycle model that accommodates distinct stages/phases with gate reviews between each two-study phase, and have implemented a scalability tool. Of the respondents, 63.64 per cent largely agree with assertions in Q11 ("Your organisation uses a project lifecycle methodology"), Q12 ("Such a project methodology has distinct phases/stages"), Q16 ("It allows for gate reviews between each two phases"), and Q17 ("It is scalable to match the level of complexity of projects"). However, 14 per cent of entities surveyed cannot really tell whether the lifecycle methodology is mandatory or not; and nearly half (45 per cent) have personnel who do not fully understand their own project methodology (considering questions Q18 ("The methodology is mandatory for all capital projects") and Q19 ("The project personnel fully understand that methodology")).

Furthermore, 25 per cent of entities surveyed do not consider operational matters during the planning or study phases (Q13 ("Its planning phase(s) also considers operations matters"), Q14 ("Its planning phase(s) also considers maintenance matters"), Q15 ("Its planning phase(s) also considers disposal matters"), and Q44 ("Project personnel are inducted on 'operations' matters")). Moreover, 30 per cent do not consider maintenance matters, and half (50 per cent) do not consider/incorporate disposal requirements. Half of the respondents (50 per cent) admit that their project personnel are not inducted on operational matters. The majority (77 per cent) of respondents formulate project requirements at the outset, and most (80 per cent) seem to consult their stakeholders in formulating project requirements at project outset (Q23 ("Project requirements are clearly formulated at the outset"), Q24 ("Stakeholders are consulted in defining the requirements"), Q25 ("Requirements are reviewed before each phase/stage"), and Q27 ("Outcomes of phases are tested against requirements")). However, a third of the entities surveyed would neither review nor confirm such requirements between each two phases, while half of the entities do not even verify phase outputs/outcomes against agreed requirements to confirm compliance and validity.

While the majority of surveyed entities (76 per cent) encourage a multi-disciplinary approach on projects (Q22 ("A multi-disciplinary approach is encouraged on projects"), Q21 ("Linkages between projects are discussed at the outset"), and Q20 ("Project Scope is generally considered in its totality")), and 73 per cent "consider linkages between various projects at the outset" and "the totality of scope" (i.e., full extent of the problem to be solved in context), 50 per cent do not do so, and some 10 per cent cannot tell whether they do so or not.

Project complexity at the onset is not gauged (e.g. using a standardised tool) by the majority (just below 60 per cent) (Q29 ("Project complexity is gauged at onset with standard tool")), but half of the respondents agree that risk of failure seems to increase with project complexity. This is more pronounced when entities do not consider risk management and stakeholder management as a core project-delivery activity (around 20 per cent of entities surveyed) (Q33 ("Larger and/or highly complex projects are failing the most") and Q32 ("Project failure is clearly defined in a policy/framework")).

They might not even have an official definition of project failure, and would not be able to declare failure even when (i) projects are not meeting their objectives (23 per cent, almost a quarter of respondents, could not tell whether this was pertinent) (Q34 ("Most projects meet their business objectives"); or (ii) projects are producing products or systems that fail to meet agreed specifications - again, 23 per cent of respondents could not determine this (Q35 ("Most projects are completed to specifications")). Only a third (32 per cent) could claim completing their projects on time and on budget, confirming that project management is facing challenges. This is exacerbated by the lack of post-implementation review (PIR) practices in many entities (Q37 ("PostImplementation-Review (PIR) of projects is mandatory")). Less than half (41 per cent) of entities surveyed would agree that PIR is actually taking place, whereas a fifth (18 per cent) could not indicate whether a PIR process/framework is in place or not.

Management theories suggest that people behave according to what they are measured on: "Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way... do not complain about illogical behavior" [34]. This could then explain: (i) why the adopted lifecycle methodology is not being used consistently; (ii) why project personnel are not satisfied with the adopted methodology; and (iii) why lessons learned are not shared, as almost half the respondents indicated in Q45 ("Lessons learned on projects are captured and shared"), where 45 per cent disagreed and a further five per cent did not know.

The surveyed entities had experienced project delivery challenges in terms of the following critical aspects (Q48 to Q52):

i. business case development: difficulties in establishing business rationale for projects or proceeding without such rationale;

ii. technical feasibility and design: although it reflects as the least prevalent, poor technical design or design documentation leading to shortcomings/inadequacies will entail variation orders and/or compensation events for fixes during construction or operations;

iii. execution planning: poorly developed construction methodology, inadequate cost/schedule estimates during planning phase; and

iv. ramp-up to operations: instances of good design or plans, but poor execution and lack of operational readiness by the owner.

It is thus proposed that most organisations seem to struggle less with defining the WHAT (e.g., engineering solution), and more with the WHY (e.g., business case, rationale) and the HOW (e.g., planning of execution) of projects [35].

When the executive management is generally aware of the challenges of the adopted project methodology, they probably support its improvement - e.g., Q41 ("Management are aware of challenges with methodology") and Q43 ("Management regularly discuss project performance"). However, when they do not regularly discuss project performance, as almost a third indicated, there is a risk to the organisation and the capital delivery structure (i.e., project teams) that management will impose unsuitable and ill-advised solutions to such project challenges.

It appears that most commonly adopted methodologies for managing LIPs still follow traditional project management models, and thus are not able to manage the increasing complexity of large infrastructure projects adequately. In order to address these deficiencies in the implementation of current project lifecycle methodologies, the survey data was further analysed to establish the extent to which some answers with strong reciprocal correlation could provide insight into any linkages between elements of a generic lifecycle that were captured in the various questions. The analysis concluded that the first six critical steps towards deploying an effective project lifecycle infrastructure should consist of strategic interventions at organisational level. A systems thinking culture should first be installed at the executive level, as opposed to solely at project level. Many organisations futilely expend effort on rushing to hire reputable project managers, providing them with powerful tools, and expecting them to thrive in delivering capital projects. It must rather start at the organisational level.

 

6 CONCLUSIONS

This paper sought to establish which specific systems engineering principles and concepts could enhance current project lifecycle methodologies through surveying key industry project management professionals involved in LIPs. Many organisations (e.g., mining and utility companies, state-owned enterprises, government agencies) rely on the delivery of large and complex infrastructure projects to realise their strategic plans. The realm of LIPs is characterised by increasing complexity due to their structure, behaviour, and impact. This study has demonstrated that traditional approaches to project management are proving inadequate to managing complexity, thus leading to failure, and has proposed the initial steps in potentially addressing this issue.

Many organisations involved in delivering LIPs and that rely on project methodologies for the successful delivery of their portfolio of projects should consider the adoption of an SE-based project lifecycle model to reap financial benefits (e.g., in the form of savings) from reduced costs and schedule overruns. However, this adoption must start at management level. The six precursor nodes (seen in the correlation map) will need to be in place before any SE-based project lifecycle methodology is successfully implemented in an organisation.

In addition to organisations (whether in the private or public sector) that are actively involved in the delivery of LIPs, the above recommendations should equally apply to most organs of government, development agencies, and development banks that initiate, finance, control, own, or use the product of such projects as part of their mandates.

 

REFERENCES

[1] KPMG Infrastructure. 2013. Infrastructure in China - sustaining quality growth, KPMG Publication number: HK-PI12-0001, KPMG.com/cn. [Accessed: 13 February 2015]        [ Links ]

[2] Author unknown. 2014. The Star, Business Report, South Africa, December 3.         [ Links ]

[3] Merrow, E. 2011. Industrial megaprojects: Concepts, strategies and practices for success, 1st ed. Wiley, Hoboken, New Jersey, United States.         [ Links ]

[4] US DoS. United States Department of State: Bureau of International Information Programs, Embassy of the United States of America. 2012. Better infrastructure brings economic growth. Department of States (DoS), United States.         [ Links ]

[5] Clancy, T. 1995 & 2014. The Standish Group Report. [ONLINE] Available at: https://www.projectsmart.co.uk/white-papers/chaos-report.pdf. [Accessed: 25 June 2016]        [ Links ]

[6] Nevine, T. 2015. South Africa's dirty water crisis. African Business Magazine [Online]. Available at: http://africanbusinessmagazine.com/sectors/infrastructure/south-africas-dirty-water-crisis/. [Accessed: 25 June 2016]        [ Links ]

[7] Wood, H.L. & Ashton, P. 2010. Modelling project complexity. In Modelling project complexity. University of Brighton: UK Association of Researchers in Construction Management, p. 1        [ Links ]

[8] Baccarini, D. 1996. The concept of project complexity: A review. International Journal of Project Management. 14(4), pp. 201-204.         [ Links ]

[9] Flyvbjerg, B., Bruzelius, N. & Rothengatter, W. 2003. Megaprojects and risk: An anatomy of ambition. Cambridge: Cambridge University Press.         [ Links ]

[10] INCOSE . 2012. INCOSE infrastructure group: Guide for the application of systems engineering in large infrastructure projects. # INCOSE-TP-2010-007-01, Version 1, 9-12. San Diego, United States.         [ Links ]

[11] SE for PWW. 2008. Systems engineering guidelines for public works and water management (Department of Public Works and Water Management, Netherlands). Available at: http://www.leidraadse.nl [Accessed: 12 November 2014]        [ Links ]

[12] Kay, R. 2009. An APMP primer, p. 14. Online Edition. [Accessed: 25 June 2016]        [ Links ]

[13] Project Managers Institute. 2013. A guide to the project management body of knowledge (PMBoK guide), 5th ed. Project Management Institute, Newtown Square, Pennsylvania, United States.         [ Links ]

[14] Fox, J. & Miller, D. 2006. Challenges in managing large projects. Defense Acquisition University Press, Fort Belvoir, Virginia        [ Links ]

[15] PwC (Price Waterhouse Coopers). 2014. Capital projects and infrastructure in East Africa, Southern Africa and West Africa. Trends, challenges and future outlook. Available at: https://www.pwc.co.za/en/assets/pdf/capital-projects-and-infrastructure.pdf. [Accessed: 25 June 2016]        [ Links ]

[16] SE for ITS. 2007. Manual on systems engineering for intelligent transportation systems. US Department of Transportation. Available at: http://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf. [Accessed: 25 June 2016]        [ Links ]

[17] Meredith, J.R. & Mantel, S.J. 2009. Project management: A managerial approach, 7th ed. John Wiley & Sons, Hoboken, New Jersey.         [ Links ]

[18] Bar-Yam, Y. 2014. When systems engineering fails: Toward complex systems engineering. International Journal of System of Systems Engineering. New England Complex Systems Institute, Cambridge, MA, United States, p. 2.         [ Links ]

[19] Gould, S.J. 1996 . The mismeasure of man. 2nd ed. New York: W.W. Norton & Company [20] INCOSE.         [ Links ] 2015. INCOSE systems engineering handbook: A guide for system life cycle processes and activities. San Diego, United States.         [ Links ]

[21] NASA. 2007. NASA systems engineering handbook, 1st ed. Washington DC: National Aeronautics and Space Administration.         [ Links ]

[22] Blanchard, B.S. 2012. System engineering management. 4th ed. New Jersey: Wiley and Sons.         [ Links ]

[23] INCOSE Transportation Working Group. 2014. Systems engineering in transportation projects, Issue 7.0. INCOSE. Available at: http://www.incose.org/docs/default-source/TWG-Documents/incose-twg-case-study-library-7_0.pdf?sfvrsn=0. [Accessed: 25 June 2016]        [ Links ]

[24] NEtLiPSE. 2008. Managing large infrastructure projects (research on best practices and lessons learnt in large infrastructure projects in Europe). NETLIPSE Report. Available at: http://netlipse.eu/netlipse. [Accessed 15 September 2014]        [ Links ]

[25] Green, S. 1999. A participative research strategy for propagating soft methodologies in value management practice. Construction Management and Economics. 17(3), pp. 329-340.         [ Links ]

[26] Cushman, M., Venters, W., Cornford, T. & Mitev, N. 2002. Understanding sustainability as knowledge practice. Presented to British Academy of Management Conference: Fast-Tracking Performance through Partnerships, London, UK.         [ Links ]

[27] ISO/IEC 15288 . 2008. Systems and software engineering: System life cycle processes, 2nd ed. IEEE Standards Activities Department, Geneva, p. vii .         [ Links ]

[28] Patton, M. 1990. Qualitative evaluation and research methods. Beverly Hills, CA: Sage.         [ Links ]

[29] Eduardo, C., Sato, Y., Dergint, D. & Hatakeyama, K. 2000. Project-based organizations as complex adaptive systems. Unknown Journal. 2004, pp. 1-12.         [ Links ]

[30] Levine, D.M., Stephan, D.F., Krehbiel, T.C. & Berenson, M.L. 2008. Statistics for managers: Using Microsoft Excel, 5th ed. Pearson Prentice Hall, Upper Saddle River, New Jersey.         [ Links ]

[31] Simon, M.K. 2011. Dissertation and scholarly research: Recipes for success: A practical guide to start and complete your dissertation, thesis, or formal research project, 2nd ed., Kendall Hunt publishing        [ Links ]

[32] Salkind, N.J. 2011. Exploring research, 8th ed. Pearson Prentice Hall, Upper Saddle River, New Jersey.         [ Links ]

[33] SE Guide for SoS. Office of the Deputy Under Secretary of Defense for Acquisition and Technology, Systems and Software Engineering. 2008. Systems engineering guide for systems of systems, Version 1.0. Washington, DC: DUSD(A&T)SSE.         [ Links ]

[34] Goldratt, E.M. 1990. What is this thing called theory of constraints and how should it be implemented? United States: North River Press Publishing Corporation.         [ Links ]

[35] Gate Review Analytics. 2014. Confidential records from an organisation delivering large infrastructure projects, South Africa. (By the author)        [ Links ]

 

 

* Corresponding author consult@e6pc.com

 

 

ANNEXURE A

 


Click to enlarge

Creative Commons License All the contents of this journal, except where otherwise noted, is licensed under a Creative Commons Attribution License