COPYRIGHT and CITATION CONSIDERATIONS for THIS THESIS/ DISSERTATION O Attribution — You Must Give Appropriate Credit, Provide

o Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

o NonCommercial — You may not use the material for commercial purposes.

o ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

How to cite this thesis

Surname, Initial(s). (2012) Title of the thesis or dissertation. PhD. (Chemistry)/ M.Sc. (Physics)/ M.A. (Philosophy)/M.Com. (Finance) etc. [Unpublished]: University of Johannesburg. Retrieved from: https://ujcontent.uj.ac.za/vital/access/manager/Index?site_name=Research%20Output (Accessed: Date).

Evaluating Systems Engineering Capability of the Systems & Automation Department In A Transportation Infrastructure Organization

A Minor Dissertation Submitted in Partial Fulfilment of the Degree of

MAGISTER INGENERIAE / MAGISTER PHILOSOPHIAE

ENGINEERING MANAGEMENT

at the

FACULTY OF ENGINEERING AND THE BUILT ENVIRONMENT

of the

UNIVERSITY of JOHANNESBURG

Asanda Dlamini

Date: 04 May 2018

SUPERVISOR: Louwrence Erasmus

CO – SUPERVISOR: Jan-Harm Pretorius

Acknowledgement

I would like to express my deepest gratitude to the following people:

 Louwrence Erasmus and Jan-Harm Pretorius my supervisors for their supervision.

 Dovhani Makhado from Transnet, the principal project manager from TGC who allowed

me to undertake this study in the department he is responsible for.

 Everyone who was able take time off their busy schedule to participate in the study

 My friends for challenging my point of view during the project

Abstract

The transport and logistics industry is identified as an important component of the South

African economy contributing 12.7 % to the GDP. Transnet with the largest market share and thus a key member of the industry is increasing its infrastructure in anticipation of greater demand. The organization is investing billions of rands by undertaking infrastructure projects through its specialist division, Transnet Group Capital (TGC). The purpose of the study is to evaluate the use of systems engineering in the organization by assessing the capability of its developmental processes, and to compare the model used by the organization with SEMBASE model.The study uses qualitative research methods, data from interviews conducted is analysed by identifying patterns from SE theory. Findings indicate that the department does use systems engineering, but its capability levels need great improvements. These finding show that the company needs to review and continuously develop its departmental processes.

The main recommendation emerging from the study is that the department review their developmental model. This would involve a selection of the critical processes and improvement of their capability levels, and thereafter institutionalising the processes using clear and specific goals.

Contents

Acknowledgement ...... i

Plagiarism Declaration ...... i

Abstract ...... ii

List of Figures ...... vi

List of Tables ...... vii

Abbreviations ...... 1

Chapter 1: Introduction ...... 2

1.1. Introduction ...... 2

1.2. Background ...... 2

1.2.1. Capital/Infrastructure Investment projects ...... 2

1.2.2. Infrastructure Projects in South Africa...... 3

1.2.3. Transnet ...... 5

1.3. Problem Statement ...... 6

1.4. Objectives of the study ...... 7

1.5. Outline of the research ...... 8

Chapter 2: Literature Review ...... 10

2.1. Introduction ...... 10

2.2. Project Management ...... 10

2.3. Systems Engineering ...... 12

2.4. System Life Cycle ...... 15

2.5. Systems Engineering Standards ...... 16

iii

2.5.1. ANSI/EIA 632 – Process for Engineering a System ...... 20

2.5.2. ISO/IEC/IEEE 15288 -System Life Cycle processes ...... 21

2.5.3. IEEE1220 – Application and Management of Systems ...... 22

2.5.4 System Engineering Management Base (SEMBASE) Model ...... 23

2.6. Systems Engineering Research ...... 25

2.7. TGC’s System & Automation department Project development review ...... 27

2.8. Conceptual framework ...... 30

Chapter 3: Research Methods and Methodology ...... 35

3.1. Introduction ...... 35

3.2. Theory ...... 35

3.3. Quantitative Methods ...... 36

3.4. Qualitative Methods ...... 37

3.5. Application ...... 39

3.5.1. Research context ...... 39

3.5.2. Developing the interview questions ...... 40

3.5.3. Sampling ...... 40

3.5.4. Data collection process ...... 42

3.5.5. Interviews ...... 43

Chapter 4: Findings ...... 46

4.1. Introduction ...... 46

4.2. Comparison of SEMBASE and TGC lifecycle stages ...... 46

4.3. TGC documented process reviews...... 48

4.4. Interview Results ...... 49

Process Capability levels ...... 55

Chapter 5: Discussion of Findings ...... 57

5.1. Introduction ...... 57

5.2. Discussion ...... 57

Chapter 6: Conclusion and Recommendations ...... 59

6.1. Introduction ...... 59

6.2. Conclusion ...... 59

6.3. Recommendations: ...... 59

6.4. Limitations of the study ...... 60

6.5. Further research ...... 60

Works Cited ...... 61

Appendix B ...... 64

Appendix C – Analysis ...... 113

List of Figures

Figure 1: Transnet Operating Divisions ...... 5

Figure 2: Project Management as a process (Munns & Bjeirmi, 1996) ...... 11

Figure 3: Systems Engineering Domain ...... 12

Figure 4: Showing how a system is engineered (BKCASE Editorial Board, 2014) ...... 13

Figure 5: Showing a Systems Life Cycle (ISO/IEC/IEEE 15288, 2015) ...... 15

Figure 6: Showing system engineering standard evolution (Juang, Perng, & Chang, 2008) 17

Figure 7: Showing basic system engineering process (Juang, Perng, & Chang, 2008) ...... 18

Figure 8: Showing the history and development of CMM s (Mellon Carnegie University,

2010) ...... 19

Figure 9: Showing ANSI/EIA 632 ...... 20

Figure 10: Showing ...... 21

Figure 11: Showing IEEE 120 ...... 22

Figure 12: Showing system engineering management base model ...... 24

Figure 13: Showing Systems Engineering Research Areas (Erasmus L. , 2013) ...... 25

Figure 14: Transnet Project Lifecycle Process ...... 28

Figure 15: Conceptual framework utilised in the study (Nyareli & Erasmus, 2013; Lemberger

& Erasmus, 2014) ...... 34

Figure 16: Research Process (Muller, 2013)...... 36

Figure 17: The focus of the research (highlighted) within the Organization Transnet ...... 39

Figure 18: A chevron chart of phases in the process from data collection to processing .... 42

Figure 19 : Diagram summarizing responses to processes application ...... 50

List of Tables

Table 1: Showing documents reviewed ...... 27

Table 2: Showing TGC's project categories ...... 29

Table 3: Maturity levels with respective descriptions ...... 31

Table 4: Capability levels and their descriptions ...... 32

Table 5: Differences between Content Analysis and Grounded Theory ...... 38

Table 6: Sampling in different designations ...... 41

Table 7: A comparison between SEMBASE life cycle stages and TGC’s life cycle stages ... 47

Table 8: Capability levels awarded to the selected process areas ...... 56

vii

Abbreviations

RDP Reconstruction and Development Programme

SOE State Owned Enterprise

CMM Capability Maturity Model

CMMI Capability Maturity Model Integrator

GDP Gross Domestic Pro Product

INCOSE International Council on Systems Engineering

NMPP New Multi Product Pipeline

OD Operating Division

ORS Owner Requirement Specification

PLP Project Life Cycle Process

PMBOK Project Management Body of Knowledge

PROM Project Risk and Opportunity Management

PWC Price WaterhouseCoopers

SE System Engineering

SEM System Engineering Management

SEMBASE System Engineering Management Base Theory

SEP System Engineering Process

SOC State Owned Company

TGC Transnet Group Capital

USD United States Dollar

Chapter 1: Introduction

1.1. Introduction

The chapter begins by describing and highlighting the importance of infrastructure in society before focusing on its history and development. It goes on to expand on such projects in South

Africa and thereafter narrows it down to the infrastructure projects of interest, Transportation.

Transnet, the organization which is the focus of this study is introduced by presenting the structure of the organization systematically, together with its history, and the link between the development of its infrastructure and the country’s economic growth. The importance and value of the investigation is highlighted before outlining the objectives of the research.

1.2. Background

1.2.1. Capital/Infrastructure Investment projects

Throughout history mankind has been adding infrastructure to existing infrastructure, from roads to building. This has become very key to the effective operation of a society.

Infrastructure is the prevalence of systems and/or facilities to enhance operation of an area, city or country (Findt, Klaus ;, 2013). Examples of these infrastructure systems are

Transportation, Energy, Water and Sanitation, and Telecommunication systems. As projects, these and other economic projects such as shopping malls and industrial estate are considered large scale projects (Flyvbjerg, Skamris Holm, & Buhl, 2004) .

Urban regeneration and urbanization has increased the number of large infrastructure or Mega projects around the world. These projects require large investments, have long lifecycles and are generally very complex projects with great levels of risk associated with them (Estache &

Garsous, 2012) (Havenga, Simpson, & de Bod, 2014). Despite poor performance with regards to cost overruns, underestimated lengthy timeframes, environmental impact usually experienced after completion, more and much bigger projects are planned (infrastructure,

2014).

Long term economic growth of countries have been directly linked to its infrastructure development. It is therefore necessary to align a nation’s infrastructure to the worlds changing economic requirements. Well established, quality infrastructure reduce costs associated with trade and facilitate effective productivity and human capital, and therefore economic growth

(infrastructure, 2014). That being the case, emphasis is put on development strategies that boost economic growth (Estache & Garsous, 2012) . That is to say building of transport infrastructure between cities involved in economic activities is considered more beneficial growth-wise than merely building structures with no economic activity forecast. The paper also examines different infrastructures that mostly contribute to the economic growth. After energy, transport together with water and sanitation account for the greatest contributors to economic growth (Estache & Garsous, 2012).

1.2.2. Infrastructure Projects in South Africa

South Africa and most African countries in general face a backlog in infrastructure, their developments are faced by long and troubled history. In South Africa some areas are more developed than others largely due to the discriminatory policies and inequalities imposed by the previous government. As with social infrastructure, economic infrastructure was enjoyed by the minority group (Fedderke, Perkins, & Luiz, 2006), (Gwilliam, 2011). The discovery of mines in the mid 1800 had a major influence in the country’s development. These mines needed large quantities of electricity. This presented an opportunity for expansion in the energy sector with large quantities of coal reserves available for cost effective electricity production. Like electricity there was also a need to develop rail and roads for transportation.

Harbors and airports alike had to develop to be able to handle the increasing cargo volumes from import and export ventures (Gwilliam, 2011).

With the changing political landscape of the country, infrastructure investments declined from

1980 to 1995. In 1994 a new government took over, its leaders made it a point to focus on the development of the country. The Reconstruction and Redevelopment Programme (RDP) was

developed to focus on social and economic investments of the country. Like the previous government, infrastructure was largely the responsibility of State owned enterprises

(SOE).SANRAL is responsible for road developments, Eskom for electrification,

Telecommunications through the former SOE Telkom, Transnet for rails, ports and pipelines.

In 2002 the government announced plans to relieve roads by introducing a high speed train from Johannesburg to Pretoria and from Sandton to the airport. The initiative was met by different reactions, there was however agreement of it being a major infrastructure boost for the transportation industry. In May 2004 the country won the rights to be the first African country to host the world cup. The footballing world showed huge trust and gave the country a great responsibility given its infrastructure backlog. This gave rise to investments in a number of large projects, world class stadiums, road expansions and it put urgency into the completion of the Gautrain, although not initially built for the event. These projects too were met with large overruns in scope, time and costs ( Development Bank of Southern Africa

Limited, 2012).

Between 2012 and 2015 the government made further assessment on the development of the country and formulated a national plan to develop infrastructure to boost economic activity via the National infrastructure Plan (NIP). The NIP planned to spend R827 billion in a period of 3 years between 2012 and 2015. Much of the investment went to power supply with the building of Medupi and Kusile power stations. A substantial portion of the money also went to transport infrastructure at Transnet to improve its freight business network.

1.2.3. Transnet

The state-owned organization, Transnet, is the largest logistics organization in South Africa, and a very key organization for growth and sustainability of the country’s economy. The organization transports and delivers thousands of tons of cargo and billions of liters of petroleum products to and from ports, and around the country via rail and pipeline. Structurally the organization comprises of seven Operating Divisions (OD): Transnet Property (TP),

Transnet National Ports Authority (TNPA), Transnet Port Terminals (TPT), Transnet Pipelines

(TPL), Transnet Engineering (TE), Transnet Freight Rail (TFR) and Transnet Group Capital

(TGC) formerly known as Transnet Capital Projects (TCP) (Molefe, 2012). Figure 1 below shows a representation of the organization.

Figure 1: Transnet Operating Divisions

In 2012, Transnet projected an increase in market demand and committed itself to a R300 billion capital expenditure divided amongst the seven OD’s (Molefe, 2012).TGC plays a crucial role in Transnet realizing this market demand strategy (MDS). TGC is entrusted with executing infrastructure development projects on behalf of the entire organization. The OD needs to have sound systems and competent human resources to implement the organizations response to the market demand (Molefe, 2012).

1.3. Problem Statement

A study conducted by Price Waterhouse Coopers (PWC) in 2014 reported a total of 42.2 billion

USD was spent on infrastructure by developing African countries in 2012. The Transportation and Energy sectors had the largest allocation: 36% and 30% respectively (infrastructure,

2014). There were further expectations for expenditure to reach 180 billion USD in 2025. Given

South Africa’s ongoing developmental needs and projected investments, organizations entrusted with the responsibility of undertaking these projects need to curb overruns and delays associated with these type of projects.

Transport and logistics infrastructure spending between the periods of 2010-2011 and 2014-

2015 was a third of the public spending budget in South Africa. The freight logistics industry accounts for 12.7 % of the country’s GDP and is therefore crucial to the economy (Havenga

J. H., Simpson, Fourie, & De Bod, 2011). As noted, Transnet is an integral part of the country’s freight industry.Thus the relatively high cost of the continual development and sustaining of

Transnet’s infrastructure needs to be seen in the context of boosting and sustaining South

Africa’s economy and economic growth.

(Componation, Dorneich, & Hansen, 2015) In a comparative study that examined projects in government and commercial focused industries, a relationship between the application of project management, systems engineering, and project success showed a strong correlation.

Organizations should therefore aim to embrace these project execution principles. The purpose of this study is gain insight into systems engineering methods being used by Transnet

OD responsible for executing capital projects on behalf of the other OD’s.

1.4. Objectives of the study

In this context, and for purposes of the current study, it is important to outline the characteristics and workings of systems. A system is a collection of elements combined intricately to achieve a purposeful function that cannot be achieved by the elements on their own (Sweet, Seymour, Biemer, & Kossiakoff, 2011). (ISO/IEC/IEEE 15288, 2015) Describes the composition of system elements as consisting of hardware, software and/ or human components.

A system itself can be a component or sub-system of a larger system, as is clearly shown by

(Sweet, Seymour, Biemer, & Kossiakoff, 2011). Systems can be classified as natural, social, engineered, or a combination. The infrastructure projects described in the previous section are considered engineered systems.

With the organization set to undertake a number of these engineered system for development, the aim of this research is to evaluate the organizations project developmental models.

Compare the models used in the organizations to reduce project costs overruns and time delays.

The objectives of the study is therefore to:

 To evaluate literature on Systems Engineering (SE) and the developmental models

available.

 To develop a conceptual model based on the literature reviewed to apply to the

research

 Evaluate the application of SE by comparing organizational models with System

Engineering Management Base (SEMBASE) model

 Evaluate the Capability levels of the System & Automation(S&A) department

1.5. Outline of the research

Chapter 1: Introduction

This chapter introduces the research by giving a brief background. Thereafter context from the problem statement together with the purpose and objectives are presented. And finally the layout of the study is presented.

Chapter 2: literature review

Chapter 2 reviews literature in systems engineering. Thereafter the application of systems engineering in system lifecycles. Different standards, models and their applications are reviewed through other research context from previous authors. Lastly based on the literature reviewed a models to be utilized for the study is proposed.

Chapter 3: Research Methods and Methodology

Chapter 3 reviews the different research and research methodology. The chapter explores the reasons and limitations of the research method chosen. Thereafter it shows how the data was collected and analyzed.

Chapter 4: Findings

The chapter presents the findings and results from the data collected and analyzed in the previous chapter. The implicit and explicit existence of systems engineering principles are shown.

Chapter 5: Discussion

This chapter discusses the results and finding from the previous chapter. Possible factors and or reasons that contributed to the type of results is discussed extensively.

Chapter 6: Conclusion and recommendations

Conclusions and recommendations to the research is presented based on the results.

Chapter 2: Literature Review

2.1. Introduction

The chapter presents an overview of project management literature, before reviewing systems engineering and its history, characteristics, its value/application to organisations, and a conceptual framework for conducting research. The chapter begins by defining and exploring the background of the discipline. Thereafter the systems engineering lifecycle and standards available in the literature are reviewed. The chapter ends by exploring the types of research conducted in this field before formulating and providing a rationale for the research framework and methodology for the study.

2.2. Project Management

The endeavour of engineering a new/complex system begins with an exploratory stage of generating concepts to fulfil a need or objective. The enterprise requires a great level of effort by a number of people with diverse skills and usually takes a number of years (Heagney,

2011). The larger and more complex the system, the greater the level of effort and skills required to lead and execute. Project managers are assigned the responsibility of leading the team to execute this enterprise using project management principles (Sweet, Seymour,

Biemer, & Kossiakoff, 2011)

Project management is the application of tools skills and technics to project activity to allow prediction of resources to be utilized, quality of system to be produced and the period within which it will be produced (Project Management Institute, 2015). The common misconception is that project management is merely scheduling (Baguley, 1995), however (Heagney, 2011) points out that scheduling is a major tool used to manage projects. For a long time it was practiced informally, it has however grown in literature and practice since being recorded by

Gantt and other pioneers in the early 20th century. The discipline has evolved to consist of 5 process groups and draws from 10 knowledge areas as outlined in the Project Management

Body of Knowledge (PMBoK). Baguley viewed project management as a conversion process during which the completed project is created from a combination of inputs i.e. information, people and resources (Baguley P. , 1995). The process of project management can be seen from Figure 2 below

Figure 2: Project Management as a process (Munns & Bjeirmi, 1996)

The information pertains to time scales, cost, performance, quality and the client. The people with their skills, needs experience and abilities while resources are of material, money and time.

A carefully detailed planning process, allocation of resources and leadership within the project team is required. When project managers develop a plan, shared understanding of the objectives is needed by all stakeholders. Munns and Bjeirmi mentions how successful project management techniques contribute to achievement of projects, but project management alone cannot stop a project from failing to succeed (Munns & Bjeirmi, 1996).Thus for projects to avoid failure there must be an increase in appreciation of the role and must be placed within the visions of the project along other criteria and long term expectations.

2.3. Systems Engineering

System engineering (SE) is a deep rooted essential domain within project management.

Figure 3 below shows project management as detailed by kossiakoff in principles of system engineering (Sweet, Seymour, Biemer, & Kossiakoff, 2011). SE is an inherent part of project management, it is the domain responsible for the technical effort and development. Apart from the developmental process, duties under SE includes everything needed to support the system like documentation, test equipment, facilities and transportation. The Project planning and controls domain is shown to be responsible for the planning, human resource, financials and contracting.

Figure 3: Systems Engineering Domain

Literature provides various definitions of systems engineering (SE) used in engineering as well as other professions. (Sweet, Seymour, Biemer, & Kossiakoff, 2011) Defines SE: The

leading and management of system activities using scientific knowledge, tools and techniques to ensure complex systems are realised. The International Council on Systems Engineering

(INCOSE) offers a more detailed and comprehensive definition which includes all the elements and role players/stakeholders involved in the process. SE integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. It considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

Figure 4 below demonstrates how a system is engineered, with the respective roles of the development team, systems engineer as well as other stakeholders (BKCASE Editorial Board,

2014).

Figure 4: Showing how a system is engineered (BKCASE Editorial Board, 2014)

While SE literature may appear to be relatively new, or ‘modern’, dating from the 1940’s and

1950’s, (Sweet, Seymour, Biemer, & Kossiakoff, 2011), (BKCASE Editorial Board, 2014) and

(NASA/SP-2007-6105 Rev1, 2007) consider its principles to have been used since the construction of the pyramids, and probably before that. Currently the discipline is advanced in the military, software and aerospace community, especially in the United States of America

(NASA/SP-2007-6105 Rev1, 2007). Its initial literature emerged in greater volume from, the cold war when military requirements of advanced technology, material, and control systems demanded more efficient and reliable systems. Today the increasing demand for SE is due to the increasing complexity of systems as well as the increasing competition in corporates

(Lemberger & Erasmus, 2014; ) (Kossiakoff et al., 2011).

The discipline continues to mature; it has grown to be a very popular choice for product and service development. There are however still sceptics who do not see value in the discipline

(Elm, Developing a Business Case for Systems Engineering , 2012). This scepticism may be the result of what appear on the surface to be the intangible benefits of risks that are mitigated, or the lack of any guarantee of better quality (Lemberger & Erasmus, 2014; Elm, 2012).

Avoiding reworks and poor quality or avoiding undue delays by implementing systems engineering is not quantifiable hence the challenge in convincing the sceptics. To effectively and efficiently develop and implement these complex systems, organizations need systems engineering processes (SEP) (Botha, 2015). Lemberger & Erasmus (2014) argue that many organizations in fact use systems engineering without identifying these as such due to the lack of widely accepted and agreed-upon definition of what comprises SE. This approach acts as a hindrance to the measurement and improvement of SE activities. The following sections review literature on the various aspects of system engineering which relate to the current study.

2.4. System Life Cycle

The System life cycle is a unique model which represents different clearly defined phases in a process of developing a system, from inception to retirement. Progression from one phase to the next is a result of actions performed and managed by people using specific processes while executing them (Kossiakoff et al., 2011; ISO/IEC/IEEE 15288, 2015). The nature, purpose, use and circumstances of a system collectively determine the life cycle. In some cases the complexity of the project, or lack thereof, dictates that some phases may be performed informally (Erasmus et al., 2015). Figure 5 below shows the major periods associated with systems in realizing their product or services. Each phase has a distinct purpose and a whole contribution to the system life cycle.

Figure 5: Showing a Systems Life Cycle (ISO/IEC/IEEE 15288, 2015)

The discipline evolved, and its evolution resulted in a number of different life cycle models being developed and utilized by organisations. The different life cycle models allow a trade- off between developmental speed, production quality, and risks (BKCASE Editorial Board,

2014). The Systems Engineering Body of knowledge identifies the following models and briefly presents descriptions of the advantages, disadvantages, and where they are applied:

Sequential, Vee-Model, Saw tooth, Incremental, and Spiral model.

2.5. Systems Engineering Standards

System engineering standards define the interdisciplinary tasks and activities required throughout the system lifecycle to transform the needs to a solution. Standards, maturity models and methodologies exist as guidelines for organizations to improve the ways in which business is done (Mellon Carnegie University, 2010). In the late 1990s Sheard and Lake reviewed SE models and standards, they made a distinction between SE standards and models. A standard was described as a document that undergoes industry approval processes for acceptance, whereas a model is often developed by organizations with drive and resources

(Sheard & Lake, 1998). Both standards and models only go as far as to indicate or advocate what should be done and not how it should be done. Maturity models further assist organizations in determining how well defined the processes are, and to what extent the organization performs them (Mellon Carnegie University, 2010).

The basis of SE standard began with the US Military standard MIL-STD_499 produced by the department of defence in 1969. It was very influential in defining the SE scope at the time. The standard was frequently improved upon with MIL-STD 499A and MIL-STD 499B (Juang,

Perng, & Chang, 2008). The Department of Defence (DoD) however did not accept the MIL-

STD499B, citing lack in catering for commercial development. A collaboration between

Electronic Industries Alliance (AIA), DoD, National Security Industries Association (NDIA) and

Institute of Electrical and Electronic Engineers (IEEE) and INCOSE was created to account for commercial development by modifying the MIL-STD499B. The modification produced the

ANSI/EIA 632 standard. The evolution of standards can be seen from Figure 6 below

.Thereafter a number of standards emerged from different industry associations catering for

system engineering process at different levels. IEEE 1220 from IEEE (1998), ISO/IEC 15288

(2002). The evolution of standards can be seen in Figure 6 below.

Figure 6: Showing system engineering standard evolution (Juang, Perng, & Chang, 2008)

Similarly with SE process models developed by organizations to describe activities that relate to technical effort required to achieve a certain objective. It represents the sequencing and iterations required within project activities. Models like the waterfall model introduced in the

1970, spiral model in 1988 and the Vee model in 1995. The models are reviewed in the System

Engineering Body of Knowledge showing the different advantages and shortfalls with each type of development to be undertaken. Since then a few models have been developed, either organization specific or for the system engineering community. The Blanchard’s SE model is a good example of this. The basic process typically consists of four activities shown Figure 7 below

Figure 7: Showing basic system engineering process (Juang, Perng, & Chang, 2008)

Maintaining competitiveness, increasing complexity of projects and organizations needing compliance with standard process models, there was a need to evaluate the effectiveness of processes. Capability and maturity models were established to investigate the quality of the processes and ways in which they can be improved upon. They provide appraisal models and road maps to organizations and are sometimes performed by specialists (Mellon Carnegie

University, 2010).

(Mellon Carnegie University, 2010) (Elm, Goldenson, Emam, Donatelli, & Neisa, 2008) And

(Faisandier, 2015)reviewed the history of the CMM family. The first capability model derived was developed in the field of software, the software capability maturity model (SW-CMM) in

1993. Thereafter a model to assess the capability and maturity of the model was created, the

SE CAM. The history and chronological development of the Capability Maturity Models (CMM) can be seen in Figure 8 below. As the literature in the field developed, so CMM incorporated other models and standards to develop a family of models for acquisition, development, and service (Mellon Carnegie University, 2010).

Figure 8: Showing the history and development of CMM s (Mellon Carnegie University, 2010)

Below is a list of systems engineering standards and models used in the development of

Products during the period 2005 – 2015 considered important to this study(IEEE Std 1220,

2005 (R2011)) (Erasmus & Deoben-Henisch, A Theory for System Engineering Management

, 2011) (Mellon Carnegie University, 2010) (ISO/IEC/IEEE 15288, 2015):

 IEEE 1220 – System engineering process

 ISO/IEC/IEEE 15288 – System Life cycle processes

 SEMBASE- Systems Engineering Management Base Theory

 CMMI – Capability Maturity Model Integrator

2.5.1. ANSI/EIA 632 – Process for Engineering a System

Purpose of the standard is to present a combined set of fundamentals to assist the developer in engineering a system. It is made up of 5 process groups, 13 processes directly related to the technical characteristics of engineering a system with 33 requirements to complete the processes (Faisandier, 2015). The model is shown on Figure 9 below. It focuses more on defining the process rather than the method. The method is expected to be developed by the policies and procedures of the enterprise It defines the technical engineering activities less than the IEEE1220 standard.

Figure 9: Showing ANSI/EIA 632

2.5.2. ISO/IEC/IEEE 15288 -System Life Cycle processes

System life cycle processes has a wide scope of application and was designed to be used by organizations, projects within organizations as well as suppliers via the main process groups and can be seen in figure 1 below (Faisandier, 2015). Agreement process group for acquiiring and supplying, Enteprise process group for the organization, project process group for management of the project and the technical process groups. The evolution of the standard from the 2002 version was in an effort to standardize the terminolgy that saw a lot of confusion between the system engineering community and software engineering community. This also gave rise to an update to ISO/IEC 12207 the software engineeirng standard (ISO/IEC/IEEE

15288, 2015) (Faisandier, 2015).

Figure 10: Showing

2.5.3. IEEE1220 – Application and Management of Systems

As stated in the standard, the purpose is to provide a standard for managing a system from initial concept through development , operations and disposal (IEEE Std 1220, 2005 (R2011)).

It contains 14 via the control processes consisting of Data ,Configuration, Inteface, and Risk

Management together with other performance based progress measurements. As noted in the above section of history of standards, it was originally published in 1995. It focuses more on enterprise development then any specific system being built (Faisandier, 2015).While it provides a great level of detail of the processes defined in EIA 632, the scope coverage of the standard is narrow in comparison to the other standards. .It details the technical activities and tasks of systems engineering in a concise manner, the general requirements are within are within the lifecycle stages (IEEE Std 1220, 2005 (R2011))

Figure 11: Showing IEEE 120

2.5.4 System Engineering Management Base (SEMBASE) Model

The SEMBASE model provides a much needed theoretical fundementals of the system engineering process. The model is a construct of a number SEM models that carry out lifecycle integration, development phasing (Erasmus & Deoben-Henisch, A Theory for the Systems

Engineering Process, 2011). The base model is based on a number of industry system engineering standards and is developed to show the interactions of activities in system engineering management. The model is shown in Figure 2 below, one of the key factors in the model is the inclusion of stakeholders (Lemberger & Erasmus, 2014) (Malik, Erasmus, &

Pretorius, 2016)

The engineering of the system requires a large amount of effort. The client begins the process with the required operational capability (ROC) that forms part of the stakeholder documentation in the operations and support phase. The planning in the development phase combines the requirements loop, design loop and development phase activities.During the system life cycle integration the system engineering manager defines the life cycle (Malik,

Erasmus, & Pretorius, 2016) (Erasmus & Deoben-Henisch, A Theory for System Engineering

Management , 2011). The model will enable system engineers to use mathematics to describe management tools, theories and standards (Erasmus & Deoben-Henisch, A Theory for

System Engineering Management , 2011) (Erasmus & Deoben-Henisch, A Theory for the

Systems Engineering Process, 2011).

Figure 12: Showing system engineering management base model

2.6. Systems Engineering Research

The discipline of SE can be thought of as a hard science, as part of management theory and practice (Erasmus & Deoben-Henisch, A Theory for System Engineering Management ,

2011). (Erasmus L. , 2013) Presents a framework of systems engineering research. Figure 13 below illustrates how the research is categorised. It is divided into Systems Engineering

Management, Methods, theoretical fundamentals, and the application of SE in an organisational context.

System Engineering (Field of Specialisation)

Systems Engineering Systems Engineering Systems Engineering Systems Engineering Theoretical Management Methods Application Fundamentals

Figure 13: Showing Systems Engineering Research Areas (Erasmus L. , 2013)

System Engineering Management research is further broken down into three categories:

System Lifecycle Process (SEP), Development phasing, and Life cycle integration (Erasmus,

2013). Some of this literature has been reviewed in this current study. For example Erasmus

(2013) mentions and uses examples of this type of research in his study. Listed below are two examples from his work on SEM:

 Experience in using agile methods for software engineering (Erasmus 2005)

 Semiotic Modelling of a Software Development Company (Erasmus , Doeben-

Henisch, &Muir, 1999)

Systems Engineering Methods research is research done on the methodologies and tools used in the discipline. One example of this type of research is that done on Model Based

System Engineering (MBSE). MBSE is said by researchers and by those in the field to be the future of product engineering. Examples of this type of research can be found on Erasmus

(2013).

Systems Engineering Theoretical fundamental research is a highly conceptual category, and in South Africa not much of this research is being performed. For SE, or any other engineering discipline to be taken seriously, strong theoretical fundamentals need to be established

(Erasmus, 2013). Below are two examples of this type of research:

 A theory for the Systems Engineering Process (Erasmus & Deoben-Henisch, 2011)

 A theory for Systems Engineering Management (Erasmus & Deoben-Henisch, , 2011)

The Systems Engineering Application research category is the most common amongst the four SE categories in South Africa. In this research the author uses standards, processes, or models to compare and evaluate their unit of interest (Erasmus , 2013). The current study follows this research model (highlighted in Figure 13) in evaluating the level of system engineering used in Transnet, the organization of interest. A few studies have been reviewed that have adopted this research approach. The list below shows those which have used the type of approach the author of the current study feels is relevant to, and useful for, the study:

 Application of Systems Engineering : An Acquisition Agent Perspective (Niken &

Erasmus, 2014)

 Systems Engineering process Maturity of South African Manufacturing Organization

(Lemberger & Erasmus, 2014)

 Evaluating Systems Engineering model used by a South African Defence Contractor

:A Case study (Nyareli & Erasmus, 2013)

2.7. TGC’s System & Automation department Project development review

A review of the relevant document relating to the lifecycle process of the Systems &

Automation department at TGC was conducted in order to augment the interviews conducted on personnel. Table 1 below shows the documents reviewed by the author.

Table 1: Showing documents reviewed

1. Project Life Cycle Process Rev1

2. Owner Requirement Spec Guideline

3. Planning and Scope Management plan, work plan for FEL1-4

4. Project Risk and Opportunity Management procedure , Policy and Standards

5. Quality Management policy and procedure

6. Project Documentation Management Strategy , Governance

In order to function effectively, Transnet needed – and continues to need - to continuously and systematically strive towards a high level of consistency in its approach to preparing and managing Capital Investment Projects. The organization developed a standardized and all- inclusive methodology derived from best practices. The Transnet Project Life Cycle Process

(PLP) has continuous project phases, separated and controlled by a series of gate reviews.

These phases address TGC as a developing Engineering, Procurement and Construction

Management (EPCM) organization. Figure 14 below shows the project lifecycle with each phase, a set of activities and outcomes that are to be reviewed by a predetermined specialist committee at the end of each phase (Gate review).

Figure 14: Transnet Project Lifecycle Process

Projects in the organization are initiated at different stages, depending on the size and complexity of the project. Table 2 below shows the project type, category, and descriptions of each category. Since projects of interest are capital investment projects and are usually large requiring intensive front end loading, project type E is considered. Business needs are initially identified and the ORS is developed from the first phase, the after it is improved with planning, quality and integration plans in the following phases until the project comes to completion.

Table 2: Showing TGC's project categories

Project Type Category Description

A Small Consists of either replacing like-with-like, or a straight

forward procurement

B Small (FEL3 There is an option known, and the execution plan is to be

onwards) established for efficient delivery.

C Medium (FEL2 There are identified options, and they are to be reviewed

onwards) to establish a final option for further development

D Large ( FEL1) The business need and the basic options are still to be

established, which entails going through the full lifecycle

E Large (FEL1) The business need and basics are to be established. The

complexity and impact are to be determined and thus the

full PLP shall apply.

2.8. Conceptual framework

Erasmus and Doeben-Henisch (2011) have collaborated to provide much needed theoretical fundamentals of the systems engineering process as well as the development of the

SEMBASE theory. Such studies present a very important aspect of the theory: the inclusion of people in the systems engineering process and the Base theory (Erasmus & Deoben-

Henisch, 2011).

Erasmus (2013) further categorises the research in systems engineering, providing extensive examples as outlined in the previous section (‘Systems Engineering Research’) (Erasmus,

2013). Mgoza and Erasmus (2012) use the application category of research to combine qualitative and quantitative methods to prove that the SEP used by a South African military organization improves overall project delivery. Niken and Erasmus (2014), and Nyareli and

Erasmus (2013), evaluate the application of SE and SEM models in organizations in the military industry. The studies are presented from the perspectives of an Acquisition and a

Contractor organization’s point of view respectively. Nyareli and Erasmus (2013) mention an important point that while organizations need to baseline their development models based on approved models, it is important to tailor the models to best suit the organization of interest.

Malik, Erasmus and Pretorius (2016) conducted research into the readiness of SE in an engineering organization. Their study is based on an organization from a research background. In their article they concur with Lemberger and Erasmus (2014) that many organizations use systems engineering without being aware of doing so. This once again demonstrates the need for standardised terminology in the discipline. Lemberger and

Erasmus (2014) use the CMM model to analyse the state and extent of systems engineering process maturity of South African manufacturing organizations. The investigation is based on the combined management and technical processes as described in the 2010 study conducted by (Mellon Carnegie University and also used by Elm (2012) in his study on developing a

business case for Systems Engineering. The model used in this study was able to effectively measure the levels of process maturity.

According to Mellon Carnegie University CMMI definition, “Maturity levels are used to characterize organizational improvement relative to a set of process areas, and capability levels characterize organizational improvement relative to an individual process area.” (Mellon Carnegie University, 2010). The maturity levels are from 1 to 5 and are represented in Table 3 below with the descriptions of each level. Similarly

Table 4 shows capability levels and their respective descriptions

Table 3: Maturity levels with respective descriptions

Maturity level Description

1 Initial Identified by overcommitting, not sticking to processes in times of

crises, and inability to repeat success

2 Managed Work products are visible to management at certain stages. Relevant

stakeholders commit and revision is done when needed. The work

products and services satisfy their specified process descriptions,

standards, and procedures

3 Defined Organization improves its processes that are related to the maturity

level 2 process areas.

4 Quantitatively Predictions on project performance are accomplished through

Managed qualitative techniques. Processes are controlled using statistical

analysis.

5 Optimizing The organization is concerned with overall organizational

performance using data collected from multiple projects

Table 4: Capability levels and their descriptions

Capability level

0 Incomplete Process that is partly performed or incomplete

1 Performed Process that accomplishes the need work to produce work products

2 Managed Process that is planned and executed in accordance with the

organizations policy

3 Defined Process tailored from the organizations set of standard processes

The theoretical framework utilised in this study is adopted from a combination of that of Nyareli and Erasmus (2013), and that of Lemberger and Erasmus (2014). Figure 15 below shows the plan of development for the study. The first part of the study compares the organizations SEP and is augmented by the formal theory to measure the capability levels of the documented processes. The second part of the study uses SEM theory and the process area specific goals defined by the CMMI for development v1.3 model to measure the level of capability of the

Transnet engineering of systems. Processes selected for analysis were technical and from project management as categorised by CMMI dev 1.3.The processes choses are presented below:

 Requirements Development and Management

 Risk management

 Project planning

 Project Monitoring and control

 Quality assurance and verification

 Product integration

 Configuration management

CMMI for SEP Comparison Development v1.3

TGC System SEMBASE Process Areas of Engineering Model interest Process

Measure Process Capability levels

Figure 15: Conceptual framework utilised in the study (Nyareli & Erasmus, 2013; Lemberger & Erasmus, 2014) 34

Chapter 3: Research Methods and Methodology

3.1. Introduction

This chapter outlines the methods and methodology used in the research study. The chapter begins by giving a theoretical background of the research methods used in management studies to analyse qualitative data. Thereafter it expands on the application through the research context by providing a brief description of the department, the organization and objectives. Lastly the data collection process is described including the development of the structured questions used in the interview and transcription processes, and the identification of codes and themes emerging from the data.

3.2. Theory

Scientific knowledge is only as sound as the research methods used to obtain it. In the pursuit of the knowledge from our perceived problems, there are different applicable methods that offer different perspectives. Critical to the outcome of verifiable and substantial research is the methodology used in the evaluation process. Research processes begin by formulating the situation or phenomenon to be investigated and the perceived challenges involved in this process. The intentions of researchers should be to convert challenges into objectives, thereafter seek ideas or research methods, from existing literature in an attempt to resolve, improve, or gain insights into the situation. From literature well formulated models are formulated to measure validity of the claim. The process thereafter is to observe, measure and collect the data for evaluation. Figure 16 below represents the process used in a master’s research project from an industrial research problem to validated research, on the left a generic approach and on the right a simplified approach (Muller, 2013).

Figure 16: Research Process (Muller, 2013).

The challenge often encountered by researchers is ensuring decoding of the complicated data in telling an all-inclusive story to the intended audience. While a number of research methods are available, this research reviews quantitative and qualitative methods respectively and the best approach for collecting and analysing data for this study.

3.3. Quantitative Methods

Quantitative research is the formal, unbiased systematic collection, processing, analysing, representation and interpretation of quantifiable information about challenges worldwide. The methods are used to describe and or verify claim while considering the cause and effect.

(Hussey & Collis, 2014) In business research design reviews the different type of qualitative methods and reasons for their undertaking. Data is based on large sample sizes of a population using structured collecting instruments namely: (Positivism)

 Surveys- Highly dependent on the structure of the questions being asked. They are

conducted through online platforms, telephone and in person.

 Observations – Observing the number of times an occurrence happens or how many

times certain phases occur during interviews

 Secondary data- Examination of organization account documents

An advantage of this of research method is that it is high reliability and ease of replication. The data is analysed and represented using statistical and mathematical models.

3.4. Qualitative Methods

Qualitative research is an exploratory type of research and seeks to gain insight into the problem and extend or generate new theories. The method is an inductive approach for examining experiences and practices through the use of open-ended questions and examining of participants. Samples used in the study are generally small and not necessarily a representative of the larger population (Hussey & Collis, 2014) (Easterby-Smith, Thorpe, &

Jackson, Management research third edition, 2008). Data collection strategies include focus groups, structured and semi- structured interviews. This method is more flexible then quantitative methods, participants are less restricted and researcher participates in the study.

Some researchers note difficulty in assessing the level of biasness imposed by the researcher on the study (strauss & Corbin, 2008)

Easterby-Smith, Thorpe and Jackson (2008) describe and discuss five different qualitative analysis methods used in management research: narrative, conversational, argument, content, and grounded theory research and data analysis. Narrative, conversational and argument analysis fall under a category known as discourse analysis and include interviews.

The analysis of the data takes into account the social context of the data in which the interviews take place. This category is less concerned with the analysis of transcripts, and is

focused on the surroundings, for example the arrangement of files, why they are arranged in that particular manner, and other arrangements in surroundings.

The researcher considered grounded theory and content analysis methods to be the most appropriate for the current research. These methods enable researchers to investigate data for hypotheses. Table 5 below shows the differences between the two methods. Both methods focus on the content of the data, while content analysis focuses specifically on the ideas/themes and their frequencies. Content analysis was the method selected for this study.

Table 5: Differences between Content Analysis and Grounded Theory

Content analysis Grounded theory

Searching for content Understanding of context and time

Casually linked variables Holistic association

Objective subject Faithful to views of participants

More deductive More inductive

Aims for clarity and unity Preserves ambiguity and contradiction

3.5. Application

3.5.1. Research context

Transnet Group Capital (TGC) is a specialist unit of the state owned enterprise Transnet SOC.

TGC is responsible for determining feasibility and the management in executing Capital

Investment Projects on behalf of the other operating divisions. TGC has undertaken and is in the process of completing mega projects like the multi-purpose pipeline estimated at R14

Billion, the artificial dig out port in Durban and other strategic programs aimed at increasing freight volumes as forecasted. Capital investment is expected to be R300 billion over a seven year period. Figure 17 below shows the System and Automation (S&A) department under the engineering department. The department determines the need for systems to be automated and are responsible for the design, development and management of these systems.

Transnet Group Capital

Support Project Services execution

Safety & Risk, Quality, Project HR security, Engineering Planning Management Environmental

Systems & Specialised OHTE Civil/PerWay Automation Skill

Figure 17: The focus of the research (highlighted) within the Organization Transnet

3.5.2. Developing the interview questions

The questions designed for the interviews were in two folds. The first set of questions was intended to elicit details of the background of each respondent. These questions were developed to elicit information about their technical backgrounds as well as to ensure that the participants were comfortable during the interview process. The second set of questions were designed based on the CMMI process areas chosen from the literature reviewed. The questions were open ended to allow participants to fully express themselves in describing their experiences and in giving their views. Follow up questions were added to ensure the participants gave relevant and full information. Below is an example of how question would be asked and elaborated on to get clarity on the process area. The full questionnaire is provided in Appendix A.

“2.2 How are your project requirements set?

2.2.1 Can you give me an example of how they were set in a project you is working

on?

2.2.2 How do you ensure that the system meets these requirements?”

3.5.3. Sampling

The sampling method used was convenience sampling, the size of the sample was based on the number of employees who availed themselves for the study. While the sampling was based on the number of employees available, the researcher ensured the minimum number

(9) of participants required for saturation and redundancy and saturation for a non- probabilistic approach was met (strauss & Corbin, 2008). Table 6 below shows a breakdown of the participants that were invited. They are categorised according to their designation, thereafter the number that was invited and the type of responses are shown.

Table 6: Sampling in different designations

Designation Invited Accepted Declined/No

Response

HOD/Project Director 2 1 1

System Engineer 8 5 3

Project Manager 7 3 4

Risk Engineer 3 1 2

Quality Engineer 3 0 3

Planner 3 2 1

Total 26 12 14

It should be noted that, while many of the participants had experience of between eight and

16 years, all of them had less than, or equal to, three years in the organization. The participants had all been part of projects, previously or currently, that amounted to investments in excess of R100 Million.

3.5.4. Data collection process

The primary data collection instrument took the form of interviews and structured questions to guide the interviews. .Figure 18 below shows the phases in the process of gathering data and how it was to be analyzed for the findings - for the study.

•Email invitations to respondents explaining the purpose of the research INVITATION •Phone calls followed suit to confirm the appointments S

•Face to face interviews INTERVIEWS

•Transcription of interviews RAW DATA

•Summary of response LEVEL 1 •Notes of Similar responses from participants (Themes/Summaries) SUMMARY

•Representation of findings (Next chapter 4) FINDINGS

Figure 18: A chevron chart of phases in the process from data collection to processing

Once the interviews were transcribed, a summary of the responses was done. Thereafter the similar responses was noted to group such responses. These are presented in the findings

(Chapter 4).

3.5.5. Interviews

3.4.5.1 Ethical considerations

Crucial to the investigation were ethical considerations regarding the participants. Therefore prior to the questions being formulated and the interviews being confirmed, the following were clearly explained to and discussed with the participants:

 The Purpose or intention of the whole study and their participation in it,

 The Integrity of the study: a (disclaimer to assure the participants that the results

from the study would be used for the stated purpose only.

 Confidentiality: a guarantee that the identities and responses of participants would

be kept confidential, data would be stored in an encrypted format and data

collected and presented in the study would not be traceable back to participants.

3.4.5.2. Piloting the interview questions

The questions was presented for testing to Engineers in Training (EITs) who were on the brink of completing their programme in order to:

 Gauge and verify the understand-ability/accessibility and clarity of the questions.

 Obtain a rough estimate of the time needed for each interview in order for the

participant to answer the questions adequately.

Results from the pilot test showed the following:

 Question 1.3,”‘What is the value of the projects you worked on?”’ was unclear. ’Value’

is a vague and loaded term and needed to be qualified/specified. Participants tended

to describe ‘value’ both in terms of their experience and how they thought those

projects benefited the country in general. The purpose of the question was to establish

what participants considered – or gauged - to be the financial value (largest) of those

projects they had been part of.

 The time needed to complete the interview was between 10-15 minutes.

After piloting the interview questions, and taking into account the results from the testing, emails, phone text messages, and personal invitations were extended to the participants. The terms of the pre-interview schedule meeting were agreed upon, and thereafter interviews were scheduled and conducted.

3.4.5.3 Transcriptions

Labelling transcripts

Transcriptions of each interview included the date, the length of the interview, and the location of each interview, followed by verbatim transcriptions of the interview itself. Each interview transcript began on a new page.

Documenting Comments

Comments or questions by the interviewer were labelled Interviewer in the left hand margin, followed by the question or comment indented, similarly, with questions and responses by the participants (see Appendix B).

Example

Interviewer: And how long have you been working in this organization?

S&A_MAN: um 3 years as an executive manager, I started off as an executive manager in

Systems & Automation on the NMPP project. And I went on to technical director at the center of excellence.

Content

The audiotapes’ transcription was verbatim. The researcher attempted to include all relevant non-verbal or background information and this information was typed in parenthesis, for

example (laughter, sighs, and coughs). ‘Filler’ words were also transcribed, such as “uhm” and

“ahh”.

Inaudible and overlapping speech

In cases where a small portion of the tape was inaudible or difficult to decode, “inaudible segment” was used in square brackets. Overlapping speech, where two or more individuals are speaking at the same time, and there was difficulty making out what the other person was saying, cross talk was inserted in brackets and transcription began from the next audible person.

Example

Interviewer: So customer satisfaction is very important….[cross talk]

System_Eng_B: cause you want that person to come back.

Pauses and sensitive information

For brief pauses in the middle of a statement, three ellipses were used. A brief pause is defined as being between 2 and 5 seconds. For longer pauses, long pauses were written in parentheses. Sensitive information was replaced with the interviewer indentation

Example

Interviewer: yes!

System_Eng_B: Oh

SYSTEM_Eng_B Cool (Laughs), alright project success… I define it in a number of ways,

uhm but this is dependent on the project objectives

Various themes were identified from the transcribed data, themes which related to the research question, and each of the themes emerging from the transcribed interviews (see

Chapter 4) was recorded on a separate page.

Chapter 4: Findings

4.1. Introduction

This chapter presents the findings of the research study. The chapter begins by reviewing the documentation relating to the lifecycle process of the Transnet organisation, and comparing it to the Systems Engineering Management (SEMBASE) theory. A brief discussion of the processes of interest from this reviewed documentation follows and lastly findings (including recurring themes) from the interviewed participants are presented before showing the capability levels in graphic form.

4.3. Comparison of SEMBASE and TGC lifecycle stages

A comparison between the System Engineering Management Base (SEMBASE) theory and the organization’s life cycle stages is shown on Table 7. The organization’s systems life cycle is comparable to the SEMBASE. A correlation is indicated by an “X” and where there is no correlation a “-“was used. The documentation showed no separate stages for the preliminary design and the detailed design stages. The specialist unit’s stages end at the commissioning stages. The client or Operating Division (OD) is given the operations and support. The decommissioning stage is carried out either by the OD or the specialist unit, depending on the scope and budget of the project. If the scope, budget and size of the project is big (Type D or larger) they are carried out by the TGC.

Table 7: A comparison between SEMBASE life cycle stages and TGC’s life cycle stages

System Engineering Life-Cycle Stages

SEMBASE Correlation TGC’s PLP

1. Concept Study X FEL 1 – Conceptual Phase

2. System Definition -

3. Preliminary Design X FEL 2 – Pre – Feasibility Phase

4. Detailed Design X FEL 3 – Feasibility

5. Manufacturing , Construction, X FEL 4 – Execution installation and implementation

6. Commissioning X Finalise – Close out

7. Operation & Support -

8. Decommissioning -

4.4. TGC documented process reviews

Requirements Management Process The document reviewing process showed clear input and expected outputs at every stage of the project. The outputs are developed until a clear and sound document is produced before the detailed design phase (FEL 3). Documentation however did not show a process of achieving the expected outputs. There is no clear processes on requirements elicitation, often experience is used rather than the process.

The organization’s project executing plan and planning process do not mention a plan. The project life cycle process states that the ORS is to be developed by the client.

Project Planning Process

The department’s project planning documentation includes plans relating to the delivery of the project. The overall project plan includes all the various plans within a project such as communications plan, a quality plan, a resource plan, a risk plan and a project schedule. The documentation shows well defined and expected inputs and deliverables in the procedures.

Risk Management process

The organization uses a Project Risk and Opportunity Management (PROM) process through the collaboration of the ISO 31000 International Standard, IEC/FDIS 31010 International

Standard and the AS/NZS 4360:2004 Standard. There appear to be similarities throughout the standards as it regards the manner in which risk management process should be conducted. The main steps in this process are planning, identification, analysis, treatment, and control. Within the organizations tailored process clear inputs and outputs are stated.

These include maximising the results for positive events and minimizing consequences for negative events.

Quality Management Process

Project Quality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities that determine the quality policy, objectives, and responsibilities, and implements them by means of quality planning, quality control, quality assurance and quality improvement within the quality system.

Integration Management Process

There appears to be no singled out defined integration management process. The integration plan is embedded in the plans produced in the planning process.

Document Management process

The organization’s document management process ensures that project documents are managed in a manner that ensures traceability, accessibility, transparency, and control throughout the lifespan of the system. The process makes reference such standards as ISO

9000, NEC 3 suite for governance of project documents. Also evident are the key input and output requirements stated in the processes embedded within.

4.5. Interview Results

The transcribed data was coded, and grouped into several specific themes which emerged from the interviews. This was done by highlighting participants’ key thoughts, experiences and views, and comparing them in terms of similarity and frequency of occurrence, for example participants’ experiences and perceptions of a lack of clear process or clear definition of requirements, or integration management processes.

The following section summarises the themes emerging from the participants’ responses to questions in terms of their experiences, perceptions and views of systems being in place, or not, the roles and responsibilities of stakeholders, and the ways in which quality control and risks are managed, or not, within the organization. Figure 19 below shows a diagram representing the findings before a summary of responses from each interview question is shown.

Figure 19 : Diagram summarizing responses to processes application

2.2 How are your project requirements set and managed?

2.2.1 How do you ensure that the system meets these requirements?

One of the themes emerging from the interviews from the project managers who participated in the study was a perceived responsibility that the client should put together the requirements and be managed by TGC through contractors. System engineer participants emphasised that, to avoid setting unclear or incomplete requirements, the client needs to truly understand what they want. This is highlighted by PM1: “So what…what used to happen, especially on the

NMPP is um, the, the operator or the owner of the asset just said they wanted a system that can do one, two, three, four… But then it was left up to TGC to come up with the requirement.

TGC attempted to…to come with the requirements but they didn’t include the owner. That’s what happened initially, to the extent that the system that was specified was, is not what the owner wanted. “

This shows the importance of properly defining roles and responsibilities to avoid unclear, poorly defined, incomplete and impractical requirements. This inevitably results in evolving and therefore cost, time and scope escalating projects. Most of the participants were not part of the team that developed requirements and thus could not draw on experience from TGC.

Those who have been part of the requirements establishments used experience gained in other organization to explain the process they would have followed. Management and system engineering participants stressed that requirements establishment to be the responsibility of all the parties involved, the client, TGC and the engineering consultants.

2.3 How do you do project planning?

2.3.1 Do you have any templates and/or guidelines?

2.3.2 How do you ensure your projects plans are carried out?

One of the emerging topics under this question was the existence of long term planning team responsible for strategic. Project planning is undertaken using different procedures and

guidelines. “I use PMBOK as a guideline to do my project planning…” and “…Use the organizations project life cycle process”. This may be a result of experiences prior to joining the organization. The respondent’s number of years with the organization are mostly less than

3 years. It was further noted that planning became reactive on the NMPP project as it continued, the planning was done on a weekly basis, as explained by PM1 “So it was still planned even though we were doing it on a week by week basis. It was still planned, we didn’t have a sense of, an overall plan”.

Also evident from the data was relying on the contractors to do the planning and incorporating the plan in the master schedule “Some planning was being done by the suppliers, they are the ones with the planning expertise”. This may be as a result of inheriting a project that was already in a crisis, and lack of experience in the particular field. The project was already 4 years past its baseline complete date.

A big concern of the participant was the influence by top management on the project plan.

Crashing methods were often incorrectly applied in an attempt to meet unrealistic timelines set by management. “Top management often insisted on plans being squeezed, reduced or rushed in an attempt to keep the schedule on track without due consideration of the plan in place. This occurred without management understanding the full capability of the resources allocated to the project.”

Top management often insisted on plans being squeezed, reduced or rushed in an attempt to keep the schedule on track without due consideration of the plan in place. This occurred without management understanding the full capability of the resources allocated to the project.

Monitoring and controlling as controls in the form of micro-management was being done through the weekly meeting and through interrogation of the progress vs the scheduled output.

2.4. How do you identify risks to your projects?

2.4.1 How do you manage project risks?

2.4.2 Do you have written procedures or any standards for doing so?

Participants reported that there is a risk department responsible for implementing the risk processes in projects. From the responses it was evident that there is a well-defined and established Risk Management process. “So we have a standard risk methodology for TGC, and that would be every week, no every month, we will sit with risk specialists where we will identify technical risks, thereafter identify the impact of those risks on schedule and costs”

There was consensus amongst participants in terms of the organization’s risk procedure being used. Risks are identified and categorised according to level of impact, likelihood of occurrence, and degree of severity. During risk workshops each discipline comes up with the risks that affect its progress, discussion on how it impacts other discipline time’s lines and thus cost. While risks are managed by the risk department, the whole team come up with mitigation strategies. “Risk management, risk management uhm is the responsibility of everybody on site of course you would have risk manager on both sides, risk management is ultimately the responsibility of everybody else on the site of course there are risk managers on both sides.”

Participants know risk methods, they were not aware of any applicable risk procedure and standards that they were using in the risk management process.

2.5 How is systems integration done in your projects? How do you ensure this is done effectively?

Senior participants (those who have > 8 years’ experience) reported that there was always a well-defined architecture document with the system interfaces and different levels of test to be carried out. This is outlined in one of the systems engineer responses” Then the last step will be integrated system testing. “So it goes per levels so that, that ensure the system is safe to operate. Because if you just integrate a system at a high level without making sure that the lower level are well integrated then that’s going to have problems.” However they were of the view that the problem was, as had been the case with other plans in the projects, the human resources that were responsible for implementation of the plans. The inexperience of the contractor was also seen as an issue that came up frequently in responses to this question.

The system engineers were relying heavily on the plans initially documented. The general response from participants was the testing from components to subsystem and thereafter system.

2.6 How do you ensure your projects comply with the correct quality level?

The participants all spoke about the Quality Management plan (QMP) that had been developed and was being followed. One of the systems engineer mentioned that quality is checked in stages. The initial stage is the quality of the design, to check whether the relevant standards have been applied. As the project management team they were having to ensure that the proper processes were followed as per the applicable specification and standards. An external authorised authority inspector is appointed to ensure the levels of quality TGC signs off are acceptable. The contractor, the client, and the consulting teams are all involved in this process.

2.7 How are the project documents managed?

Participants reported that each and every project has a platform to store their documentation after it has been registered. The participants referred to Aconex (online storage platform) as the main documental portal for the project they were involved in. Formal document communication should have occurred in the portal: every document that is exchanged in the project as per the document management plan should go through the portal with the relevant communication. Participants reported that documentation process was not followed or monitored in most cases. In one case a contractor left the project without handing over documentation. The contractor had to be contacted for the documents long after they had left and asked for the documentation.

Process Capability levels

The awarding of the capability levels of the processes reviewed was based on the participants’ responses. The levels were based on the CMMI (as shown in

Table 4) developed from the literature reviewed. Capability levels go from 0 to 3 and are defined as incomplete, performed, managed, and defined in an ascending order.

Table 8: Capability levels awarded to the selected process areas

Process Area Requirements Management

Project Planning

Risk Management

Quality Assurance

Product Integration Management

Document Management 0 1 2 3 Capability level

Chapter 5: Discussion of Findings

5.1. Introduction

The chapter discusses the findings as set out in the previous chapter. Certain outcomes from the ’Findings’ chapter are connected to and compared with, or against, the literature reviewed.

Thereafter the importance and potential impact of the findings are briefly discussed.

5.2. Discussion

The processes utilised by organizations are the glue that hold everything together; they allow employees to align in the way business is done within the organization as well as with external stakeholders. These processes allow scalability and therefore leverage to resources of the organization (Mellon Carnegie University, 2010). The findings from the study agreed with those of the study done by Elm at el (2008) that produced generalizable results. TGC System and Automation department results indicate that a detailed front end loading (FEL) is done on the projects. This is based on the documentation referred to by the participants. Evidence shows lack of integration of humans called on by the SEMBASE theory on Erasmus & Deoben-

Henisch (2011) Participants referring to the NMPP project experience were not aligned to the documentation developed to execute the project. Reviewing documentation showed no clear pathway for integration in the project development process, the project life cycle process

(PLP). A contributing element to the lack of integration of the participants is that the organization is a rail focused organization. Special skill had to be sourced externally to drive the project. Over and above that, system engineers ended up using experience rather than the defined organization processes. This may be due to the relatively short time with the organization.

Participants inherited a project that was already 4 years overdue, with large scope creeps and more than 2 times over the baseline budget estimate. One of the participants is quoted as saying that, since he had been on the project, it had a new project leader every 6 months.

Improper and/ or inadequate change management was often cited as a possible contributing factor in the inconsistencies experienced in the project as different leadership was often acquired to try and change the project performance.

TGC’s System and Automation department’s findings concur with results of Nyareli and

Erasmus (2013), who highlighted a correlation between a well-defined process and the organization’s increased capability in that process. An example of this would be the risk management process area, there was a well-defined process in the documentation, and the respondents confirm a well-executed process area.

In contrast the lack of consistency with terminology used often resulted in confusion, which is parallel to the study by Elm in (Elm, Goldenson, Emam, Donatelli, & Neisa, 2008) which emphasizes the need for standardised terminology to effectively use SE. Some of the respondents were under the impression that the owner requirement specification (ORS) was a project brief. .

The researcher considers the results of this study to be key to the organization’s market demand strategic investment plans as well as to the development of infrastructure in the transportation industry. The literature review shows (Elm, Developing a Business Case for

Systems Engineering , 2012) & (Elm, Goldenson, Emam, Donatelli, & Neisa, 2008) reporting a lack of quantifiable effective systems engineering in organisations. Consistent application of

SE can help in avoiding adverse effects or increase project performance by minimizing reworks, avoiding risks, and ensuring better products or services. With the organization planning to spend billions over a seven year period, it is important to reinforce and institutionalize the processes utilized in the department.

Chapter 6: Conclusion and Recommendations

6.1. Introduction

This is the final chapter of the study, it makes conclusion and recommendations based on the findings of the previous chapter. The limitations of the study are stated before a suggestion on further research is pointed out.

6.2. Conclusion

The aim of the study was to evaluate the use of systems engineering while measuring the capability levels in the System and Automation department. Based on the research findings, it is evident that the department uses systems engineering, however the capability levels assessed are performed to an “incomplete” level. The main finding indicates TGC System and

Automation department needs to review and continuously develop the SE processes. From the responses of the interviewed participants it was evident that system engineers were using practical experience gained elsewhere to a greater extent than they were using the documented processes and procedures of the organization. The organization needs to continuously ensure its personnel is equipped in its processes.

6.3. Recommendations:

The recommendations emerging from these findings include:

 A review of the developmental model of the organization,

 Initiating a process of selecting critical processes and improving their maturity and

capability levels,

 Arising from the two above recommendations, reinforcing, monitoring, and

institutionalizing the processes using clear and specific goals.

6.4. Limitations of the study

In order to ensure there is no bias towards a specific process area group due to the number of participants from one designation, a homogeneous sample of participants is needed. In addition the research questionnaire needs to be tailored to that specific group.

6.5. Further research

Further research focussing on, and designed specifically for the project management process area groups could be explored. Questionnaires (for quantitative studies), and interview questions tailored to the specific departments need to be developed as shown in the organogram of the organization. An increased population size in each department would provide a clearer and more in depth understanding of the effectiveness of systems engineering.

Works Cited

BKCASE Editorial Board. (2014). Guide to Systems Engineering Body of Knowledge. 1.3, 16.

Botha, B. W. (2015). System Engineering as an integrator between engineering and business. School of Engineering Management (IEEE).

Componation, P. J., Dorneich, M., & Hansen, J. L. (2015). Comparing Systems Engineering and Project Success in Commecial-focused versus Government-focused Projects. Procedia Computer Science, 44, 266-274.

Easterby-Smith, M., Thorpe, R., & Jackson, P. R. (2008). Management Research (3rd ed.). California: SAGE Publications inc.

Easterby-Smith, M., Thorpe, R., & Jackson, P. R. (2008). Management research (third edition). California: SAGE Publications inc.

Elm, J. P. (2012). Developing a Business Case for Systems Engineering . IEEE A & E SYSTEMS MAGAZINE , 13 - 19.

Elm, J. P., Goldenson, D. R., Emam, K. E., Donatelli, N., & Neisa, A. (2008). A Survey of for systems engineering effectiveness (initial results). Carnegie Mellon.

Erasmus, J., Pretorius, J.-H. C., & Wessels, A. (2015). An Integrated Process Framework for Engineering Endevours. International Association for Management of Technology, 225-272.

Erasmus, L. (2013). Framework for Systems Engineering Research. INCOSE SA.

Erasmus, L. D., & Deoben-Henisch, G. (2011). A Theory for System Engineering Management .

Erasmus, L. D., & Deoben-Henisch, G. (2011). A Theory for the Systems Engineering Process.

Findt, K. (2013). Infrastructure and economic development :High potential in East Africa. INSIGHT: The Global Infrastructure Magazine.

Flyvbjerg, B., Skamris Holm, M. K., & Buhl, S. L. (2004). What Causes Cost Overrun in Transport Infrastructure Projects?. Transport Reviews, 24, 3-18.

Havenga, J. H., Simpson, Z. P., & de Bod, A. (2014). South Africa's freight rail reform : A demand-driven perspective. Journal of Transport and Supply Chain Management, 8(153), 1-7.

Havenga, J. H., Simpson, Z., Fourie, P. F., & De Bod, A. (2011). Sustainable Freight transport in South Africa:Domestic Intermodal Solutions. Journal of Transport and Supply Chain Management, 149 - 169.

Hussey, R., & Collis, J. (2014). Business Research : apractical guide for undergraduate and postgraduate students. New York: Palgrave Macmillan.

IEEE Std 1220. (2005 (R2011)). Standard for Application and Managemment of System Engineering Process. IEEE Std 122 26702, ISO/IEC. infrastructure, P. (2014, November). Price waterhouse Coopers. [Online]. Retrieved March 24, 2017, from http://www.pwc.co.za/en/publications/capital-projects-and- infrastructure.html

ISO/IEC/IEEE 15288. (2015). Systems & Software Engineering- System Life Processes. International Standard.

Kassiakoff, A., Sweet, W. N., Seymour, S. J., & Biemer, S. M. (2011). Systems Engineering Principles and Practice. New Jersy: John Wiley & Sons.

Lemberger, I. D., & Erasmus, L. D. (2014). Systems Engineering Management Process Maturity of South African Manufacturing Organizations. PICMET 14 : Infrastructure and Service Integration, 2371-2380.

Malik, H. H., Erasmus, L., & Pretorius, J.-H. C. (2016). The Readiness of Systems Engineering at a South African Engineering Organisation . INCOSE SA.

Mellon Carnegie University. (2010). CMMI for Development Version 1.3 ( CMMI-DEV,1.3). Software Engineering Institute(1.3).

Mgoza, T., & Erasmus, L. (2012). Systems Engineering Benefits for BAE Land Systems OMC Vehicles. INCOSE SA.

Molefe, B. (2012). Market Demand Strategy. Cape Town: Mikateko Media.

Muller, G. (2013). Systems Engineering Research Methods. Conference on Systems Engineering Research, 16, 1092 – 1101.

NASA/SP-2007-6105 Rev1. (2007). Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration.

Niken, A., & Erasmus, L. (2014). Application of Systems Engineering: An Aquisition Agent Perspective. INCOSE SA.

Nyareli, T., & Erasmus, L. (2013). Evalauting th Systems Engineering Management Model used by a South African Defence Contractor : A Case Study. Technology Management for Emerging Technologies, 1828-1836.

Sheard, S. A., & Lake, J. G. (1998). Systems Engineering Standards and Models Compared. Incose International Symposium, 8, 591–598.

Strauss, A., & Corbin, J. (2008). Basics of Qualitative Research: Techniques & procedures for developing grounded theory. Sage Publication inc.

Tschirner, C., Bretz, L., Dumitrescu, R., & Gausemeier, J. (2015). Applying Model-Based System Engineering for Product Engineering Management. Concept of Industrial Application.

Appendix B

Length: 17:05 Min

Date: 25/08/2017

Venue: Carlton Centre

Interview 1

Interviewer: uhm how are you sir?

S&A_MAN: Sharp ojwang (how are you)?

Interviewer: I’m doing a masters project, I’m trying to evaluate the use of systems engineering in the organization.

S&A_MAN: You doing a masters in what? Project management um system

Interviewer: Engineering Management

S&A_MAN: With UP of UJ?

Interviewer: UJ

S&A_MAN: (laughs)

Interviewer: Ja I mean, why have you stopped sponsoring masters project…Transnet.

S&A_MAN: We will only sponsor you after you get your PR Eng. You won’t get any sponsorship without your PR Eng. Yea, what has happened in the past is that other people used to get it and other people don’t get it.

Interviewer: Uhm ok, so…

S&A_MAN: So….they probably waiting for you to get PR Eng.

Interviewer: Um ok, to go on with the interview. The results of, of the study will be for academic purposes only. So the contents of the interview will be confidential. With that said I’d like to get permission to record you.

S&A_MAN: Ok, that’s fine

Interviewer: So what is your background?

S&A_MAN: Which background do you want, technical, and management?

Interviewer: All of it.

S&A_MAN: um mechanical engineer, self-taught electrical engineer. Um PhD in engineering, MBA… (Interrupted)

Interviewer: Is the self-taught certified, self-taught electric… (Cuts in)

S&A_MAN: yeah it’s certified

Interviewer: Oh ok, how long have you been working?

S&A_MAN: Yoh! Since 2000(year), so it’s been like 19 years.

Interviewer: And how long have you been working in this organization?

S&A_MAN: um 3 years as an executive manager, I started off as an executive manager in Systems & Automation on the NMPP project. And I went on to technical director at the center of excellence.

Interviewer: And what’s the value of the projects, financial value of the projects you worked on?

S&A_MAN: you want combined value or the highest value?

Interviewer: let’s do the highest value

S&A_MAN: It would be R1, 5 Billion

Interviewer: Is that within the Nm (interrupts)

S&A_MAN: Ja that would be NMPP, the control & instrumentation part of the NMPP.

Interviewer: Ok and in your experience how would you define a successful project?

S&A_MAN: It’s a project that meets customer expectations and you do it at the agreed costs.

Interviewer: And how are your system requirements, how do you set your system requirements

S&A_MAN: You mean the way…do you want the best way to do it or do you want how we do it at Transnet?

Interviewer: How we’ve been doing it. Well maybe you can tell me the best way or tell me in Transnet and tell me the best way.

S&A_MAN: So what, what used happen, especially on the NMPP is um, the, the operator or the owner of the asset just said they wanted a system that can do one, two, three, four. But then it was left up to TGC to come up with the requirement. TGC attempted to, to come with the requirements but they didn’t include the owner. That’s what happened initially, to the extent that the system that was specified was, is not what the owner wanted. What happened is that the owner ended up going outside, to an external company to develop the system for them while TGC manages the external company. The owner talking directly to the external company to produce whatever they want. That’s the bad way of doing it. Then what happened as well is because the system was not fully specified, they used what they call, um, I’m not sure if you know the project implementation methods. You have your waterfall method, then you’ve got your, your…what do they call this thing? Your rapid development method. So instead of using the waterfall method, they decided not to use the waterfall method because you use the waterfall method once your requirements are fully defined. They ended up using the rapid development, which is basically meeting with your client every week. The client determining, determining what the client wants for that week you have to develop what the client wants. That client comes after a week and checks what you have done compliments what they wanted.

Interviewer: Ok, that’s how it was done.

S&A_MAN: Ja that’s how it was done.

Interviewer: um ok.

S&A_MAN: The best way to do it I reckon is the waterfall. You have to be comfortable to a higher degree of what the client wants/requires before doing the engineering work. But in this case we were doing the engineering work and trying to determine what the client wanted and that resulted in a lot of overruns. Cost overruns and schedule overruns cause a project that was supposed to take what…one year ended up taking six years.

Interviewer: Wow and how do you ensure that these are met? Ok you just told me of how it was done, so how is it(cuts in)

S&A_MAN: So what we do is that for every activity that was given, we will set up the acceptance procedure of the requirement first so that we are in agreement with the client of exactly what we are going to test. If it’s a pass, how a pass should look like. If it’s a fail, how a fail should look like

Interviewer: And how did you do your project planning in the NMPP?

S&A_MAN: Like I said, project planning was very bad. So we ended up doing it on a week by week basis (laughs). So one of the thing that resulted from there was that the project was supposed to be one year, it resulted in it being 5 years. But that’s when we ended having to select the right the right contract for the kind of work. So you can’t come up with um, um what do they call this…project where you know the cost of the project. Ja this was, this was time & material contracts. So then it was open and didn’t have a cap. So which means that the, the external contractor didn’t, didn’t have a cap on the amount of work that they could do for us. That’s one of the, the reasons why the project kept on escalating.

Interviewer: Um so, but …do…in the S&A department did you have a planning procedures or templates that that you followed.

S&A_MAN: Yes, we had a planner, um who planned our activities. So it was still planned even though we were doing it on a week by week basis. It was still planned, we didn’t have a sense of, an overall plan. A master plan because everything was done on a week by week.

Interviewer: Ok, so in that week um plan, how did you ensure what you planned was achieved?

S&A_MAN: So what will happen is we normally have, remember there is 3 people in the picture now. It’s the client who is TPL, its US TGC and then it’s the contractor. TGC is sitting between the client and the contractor. So what we, you would do is that TGC would go have, before you have meetings, 3 of us that’s going to happen that week. Then that week, TGC must manage what happens. TGC will manage that by having 2 meetings in a week, after that the final meeting will be with us and the client and the contractor, Just to check the progress. And then we also, what, what had as well, um TGC also supplied engineers that were seated on site of the contractor to make sure they address the technical issues that arise from the contractor. To make sure that they keep progress of what the contractor is doing on a daily basis so that when we have progress meetings, our meetings are short. They are not long.

Interviewer: Ok alright, so in all this planning, how did you identify and manage risks?

S&A_MAN: So we have a standard risk methodology for TGC, and that would be every week, no every month, we will sit with risk specialists where we will identify technical risks, thereafter identify the impact of those risks on schedule and costs. And then we would rank them from one till whatever and then we will start to identify different mitigation activities for each risk. And then the next meeting we will follow up on mitigation risks and see what has happened. If our mitigations were not good enough we will put on more, additional um risk mitigation issues, um methods.

Interviewer: And how do you ensure or how did you ensure that the quality that was specified was achieved?

S&A_MAN: Um the quality goes back to us providing TGC resources on site, to the contractor, to ensure that the contractor is doing what we want him to do. That monitoring, that everyday monitoring.

Interviewer: Um, and how was system integration done on the project?

S&A_MAN: For this project it was…before the system was designed, an architecture of the system shows how the whole integrated system should operate. From, from there we developed requirements for the interfaces for the different aspects of the system. Um and after specification that’s what the contractor had to do. But as well when we went to site, so we have different levels of commissioning. The first thing we commissioned will be your instruments without the control systems then the second element that we will commission will be the control system without the instruments. The level above that will area commissioning. So you, you commission the system but it’s not yet integrated, you only integrate an area. You check the functional operational operation of that area. Then, then the last step will be integrated system testing. Then the last step will be integrated system testing. So it goes per levels so that, that ensure the system is safe to operate. Because if you just integrate a system at a high level without making sure that the lower level are well integrated then that’s going to have problems, you not going to see where the problems are. It’s going to take a lot of time troubleshooting a lot of the problems.

Interviewer: And how are your projects documents managed?

S&A_MAN: Aconex system, But Aconex system is not just a document management control system. It was just a legacy system that was decided that, the project shall use aconex. I think that the main reason to use aconex was this project comprised of many stakeholders who are graphically situated in different parts of the world. So it was easier to transmit the documents between the stakeholders. But inside ourselves we had a document control team that documented, that kept our documents in order. Before it all started we had, a um document management plan that determined how we going to manage the documents. What kind of naming convention we going to use for the documents. Um what kind of, off um document classification we wanted? Cause for example in systems & automation you’d get different systems. You would get an ICT system, you’ll get a ccv system, a control system. So you would want to classify your documents like that. Aconex is not a repository, it’s just a transitory system. Our self we just had a backup and um a shared folders of where our documents are kept.

Interviewer: Alright this is the end of the interview, thank you very much.

S&A_MAN: Alight, that was short and nice.

END OF INTERVIEW

Length: 34:12 Min

Date: 25/08/2017

Venue: Carlton Centre

Interviewer: The purpose of this study is to evaluate the use of systems engineering in the organization, more so with the NMPP.

System Eng_B: Ok

Interviewer: Uh mm I would therefore like to tell you that the results of this study are for academic purposes only and the content of this interview will be kept confidential and will not be displayed to any other parties.

System Eng_B: Ok

Interviewer: And therefore, with that said I would like to get your permission to record this interview (phone vibrates)

System Eng_B: Ok

Interviewer: In the process thank you for participating, so I would just like to start of lightly, what is your background?

System Eng_B: Mechanical Engineering

Interviewer: Why Mechanical engineering, oh ok, how long have you been working?

System Eng_B: 8 years

Interviewer: Uhm 8 years? And how long have you been working for this particular organization?

System Eng_B: It’s been 2 years now, 2 year and a half

Interviewer: Uhm ok What, What’s the financial value of the projects that you have worked on?

System Eng_B: Here at Transnet?

Interviewer: Let’s start with outside and then will bring it in…

System Eng_B: Uhm my first project that I worked with Anglo. It was an 8 billion contract for construction of kolonda mine, and the second one was for expansion of Sechen, uhm iron ore mine. Expanding the beneficiation plant so that cost about R2 Billion and then I came at Transnet the I worked on the NMPPP, when I got here was NMP, it was already sitting on 24 billion

Interviewer: Ok

System Eng_B: So the final value will be 27 billion

Interviewer: So currently what is it sitting on?

System Eng_B: Currently its sitting on 27 billion, the amount they have approved, they approved on an additional 3 billion so contract will finish on 27 billion.

Interviewer: Provided that nothing…

System Eng_B: Provided that nothing else goes wrong but I mean like TMI it’s pretty much finished. It’s been commissioned, TM2 we should be done perhaps in November, we don’t expect any more delays, costs overruns TMI is without the tank farm. There are no tanks. So that’s a separate contract or under a different warrant.

So they just by passing…?

System Eng_B: Ja they just by passing it ‘’coughs’

Interviewer: Uhm, Uhm In your experience how do you define project success?

Project success? Uhm obviously I mean uhm just like in any project you have your triple constraints, obviously would be your schedule, costs and uhm scope… but without all of that there are other constraints, your quality… there are human resources but I am not sure if we put it as a constraint but in some project we put it as constraints. So any of these … changes to any of these, change the project for us uhm for me personally you know… you can meet your schedule, you can meet your uhm, uhm your cost, but if we go to your scope and we find out that your compromised on quantity that project is not successful.

Interviewer: Uhm ok and uhm… how are your project requirements set?

System Eng_B: Our project requirement?

Interviewer: ja your system, rather system requirements?

System Eng_B: First of all, you … you have uhm uh a business case, right? So the business case can come from your client, and your sponsor. Every project remember it meets a certain strategic thrust, within that strategic thrust, there will be a business case to meet that strategy. So the way you, you and your business case… for example if suddenly Transnet mergers with another organization those strategic or the strategy might change or the business case will probably change so when you set up your requirement it has to meet…

Interviewer: Your strategic…

System Eng_B: … Your strategic thrust

Interviewer: So… How do you ensure your system requirement are met?

System Eng_B: How do you ensure your system requirements are met? That’s a tough one because system, system its uhm it’s an interdependent multidisciplinary you know so uhm so to meet your system requirement…

Interviewer: Say for uhm instance, uhm your NMPP, let’s talk practically the NMPP it had a lot of requirements uhm how did we ensure those requirements were met?

System Eng_B: You see in a project like NMPP there are many different requirements. You might have to be specific as to… are you talking about the ultimate requirements of the project or the requirements of the actual plant system engineering plant or

Interviewer: I would of liked uhm maybe to expand on both but more the functionality of… of NMMP

System Eng_B: How do we make sure that…?

Interviewer: Those requirements are met…

System Eng_B :( sigh) With NMPP it was very tough, remember NMMP was initially designed by uhm uhm is it “Arobe”? Wholly persons and later on “Kentz” (consultants) But… for, for NMMP to …to … to, for them to make sure that NMMP meets the requirements uhm, we uhm. That’s a very tough question because when you look at the engineering itself, when we went to tender, we went to tender with what 14% engineering complete.

Interviewer: Uhm ok… that’s interesting

System Eng_B: Now nowhere in the world do people go well except here in South Africa… you can’t go to tender… you cannot ask someone to build you your house when only designed

14% of what the house looks like, but that’s what we did at NMMP, so (pauses) as time progressed most of the requirement were thrust upon us by the, their contractors maybe for whatever objective they had we knew what we wanted to achieve. It was very simple we needed to ensure the security supply of fuel for Gauteng, that’s, that’s what we needed and the life… the life span uhm of, of the previous system had already well was almost at an end, so demand had grown, life span of the of the … previous system had come to an end, we needed to increase the of the, the capacity

Interviewer: Capacity of the…?

System Eng_B: The capacity uhm you know the uhm to meet current demand… for us to make sure that we meet those uhm the system requirements, it was…it was (pause) how do I put this… uhm I mean. We learned as we went along because I mean you could tell there were a couple of failures in the system for example we had the pipe rapturing about twice there in Durban, then with it rapturing about twice we knew that the capacity we want and what we had designed for is not correct, meaning we had to go back to the drawing board, how do we redesign this thing In such that we don’t have these issues along the way. Remember the pipework is about 600 odd to 50t so kilometers, so it was more of a trial and error, because we did not have the skills, the resources to… to I mean we had the resources, because I mean we did not have the skill, so to meet the.. the system requirement is more trial and error we trial until we, we, we, got things right, but if you don’t use trial and error to meet …any system , for you to meet the system requirement you have what you call modularity between uhm whatever uhm component uhm if if there are mechanical components if there are electrical components, if there are whatever discipline there has to be a certain level of modularity for you to say you met your requirements based on your business case your strategy thrust, but there has to be a decent level of modularity in your design of the system.

Interviewer: So the design was…

System Eng_B: We did not have that, we used trial an error.

Interviewer:Uhm ok uhm when we talking, let’s talk the NMPP, how was the planning done there? Are there guidelines are there uhm templates or what’s the process of planning in the NMPP or what was rather?

System Eng_B: Ok the, the uhm remember we are a state owned enterprise, so we, we yet. of course we have a long term planning department here, but we, we get the uhm instructions from the executives, from the state executives to say the economy is growing at this rate uhm Gauteng is going at this rate, remember Gauteng contributes 65% of the economy of this

country, now at the rate we growing, we knew that we won’t be able to meet demand so that where your planning starts. Now conjunction with Stata SA to use your forecast to say look Gauteng will have so many people uhm acquire this certain of capacity and you start planning from there now Transnet as an organization we process and systems in place we have short long term planning medium, and short term planning, so when the project is uhm initiated like this one there are a couple of phases that in the planning stage that it goes through, your PLP processes that we have here.

Interviewer: Yes... Yes

System Eng_B: So (Coughs) your PLP, your FEL level 1will be your

Interviewer: What is FEL, just to (cuts in)

System Eng_B: FEL will be your front end loading Front End Loading at level one , one dealing with the concept itself you know his pipeline project what is it about what can it … is that the only option that we can go for.. to...to basically we interrogate the actual option that we can go for.

Interviewer: Yeah yeah

System Eng_B: And then we go to FEL2where is now where we begin looking at the engineering, you know what options are there you know within engineering field what options are there to carry out our findings from FEL1. We interrogate those ones. Check do a thorough research… uhm look at international best practice within the engineering and then go to FEL2… I mean 3 sorry. FEL3 we say now can we afford it (pause) whatever option that come up can we, can we now afford the solution that we are trying to provide? To be able to meet we interrogate this… do we have all this you know capacity financially… resources to you know. That does not mean necessary when you are FEL3 you cannot keep going back and interrogate level2, remember within our contracting we have our … what we call continuous monitoring and evaluation… its start right there at FEL1 continuously you monitor because we could be at level 3 and say wait a minute the economy has collapsed and we don’t need that capacity anymore, so we don’t need to make any changes, so now if we can afford it, we pass the stage and we move on to FEL 4… Its where now we going to tender.

Interviewer: Uhm ok so where is, the design made …uhm

System Eng_B: Remember when you have finance, you have gone through when you go to tender, you cannot go to tender without the design. So all that stuff is done here at FEL4, you would have your design, you would go to tender you would come up with a specification

everything else that you need, now what’s gonna and be a require … what does this system require and everything else you would of carried out and you throw it out to tender

Interviewer: Uhm ok, okay but more on the, I don’t know whether I heard… or it went passed me, you, you said there are templates and guidelines… you said there is a planning department that deals will the planning.

System Eng_B: Uhm correct

Interviewer: Uhm how do we or how do you as project managers ensure that those plans are carried out for instance in your construction phase

System Eng_B: The actual execution phase?

Ja…

System Eng_B: How do we ensure that they are?

Interviewer: Those plans are carried out.

When we award the contract to, to, to know the construction companies or you know…as per project management best practice we have a project team from the clients side that managers uhm the contractor. You go to only project that you know Transnet is you know currently carry out we have a team from our side that is currently managing the contractor. You know we have contracts managers we would project managers from our side… right uhm but the project manager would have contracts manager but you know the, the gentlemen who managers contracts the actual contract. We would have a construction manager on our side, we would have uhm basically here I am giving you those that directly billable to the contract itself and we will have uhm ok, the it would be support services, who will be your Qs, Qc’s all that you’re your quality guys. The rest of everybody else but the most important folks would have your project men construction manager, that’s how we ensure the actual contract is executed as you know as agreed.

Interviewer: And how are risks identified when uhm when the project is being taken out…

System Eng_B: Risk management, risk management uhm is the responsibility of everybody on site of course you would have risk manager on both sides, risk management is ultimately the responsibility of everybody else on the site of course there are risk managers on both sides.

Interviewer: And how the… when the risk, the risk have been identified how do we manage them.

System Eng_B: We would have a normal risk reduction with the contractor, came up with solutions and whether do we need to uhm, uhm eliminate them right uhm whether we need to avoid, what we need to do to avoid the risk them, whether we need to. Engineering a solution to overcome the risk uhm whether the risk cannot be avoided we just have to

Interviewer: Accept it.

System Eng_B: Accept the risk… yeah so on an so forth some risks it means you may have to incur additional costs… yeah but our contracts we do have management costs and contingency costs, that for the most part cover the costs risks.

Interviewer: Ok are there standards or… or procedure that assist us in managing the risk…?

System Eng_B: Every, before, remember our project manager during the actual planning in the initiation phase of the project. The project manager comes with what they call a Project Management Plan. This project management plan will cut across all the, the is it the 10 or the 11 project management areas. So for example you asking about risk. Before we even do anything, before we even come and try and execute we have what you call a risk management plan. Every, you know, it’s part of the processes that we have here at Transnet. We have a risk management plan, how to manage risk on this particular, you know, NMPP. NMPP has its own risk management plan that when, in the event of a risk, how do we manage it. Just like with the schedule, we will have a schedule management plan. How do we manage schedule sli pages, how do we manage all the plans in place cutting across all those knowledge areas.

Interviewer And how do we ensure that projects are up to the design quality design?

System Eng_B: That we have always, here with, at the NMPP we have left it to engineering. Remember our quality department is under engineering. Which is not necessarily a good thing. Um it’s, it’s very, it’s been tough because we had a serious quality issue at the NMPP and I think part of the solution was merge quality with engineering. I don’t know how that solution, how they came up with that solution. But they merged quality & engineering. But how do we make sure, you asking how do we make sure we achieve our quality objectives.

Interviewer Yes

System Eng_B: The best way to make sure you meet your quality objectives is to, is to you see when you have processes in place. You have your quality management plan, right. It’s there, in the initial, during your initiation stage. You have your quality management plan, now with the quality management plan you have your assurance, um, quality assurance with NMPP we did that through continuous monitoring and your evaluation. That’s why at some at some point we even had control tower. It was partly the tool to make sure that quality you know is in

place. Control tower for the purpose of your audience will be what you call the War Room. Having all your contractors and subcontractors, all the stakeholders within your project. The execution team being core located in one space sharing ideas you know. Addressing issues together. That kind of engagement helps you manage you know, the quality issues because you have people with different views that come together and, and discuss um what best practices. We have always tried to stick to international best practice with NMPP because I mean it’s a petrochemical industry. The standards are a bit more um, um demanding, they are a bit more exhaustive. So we, we I mean you saw the, the project has so many consultants on site, whether you an engineering consultant or management consultant. It was precisely because we were trying to push for best practice so we can achieve, you know.

Interviewer: So speaking of so many consultants and contractors together. Um maybe from different backgrounds, how do you integrate all those people and their systems?

System Eng_B: Um how do we integrate, remember this here I’m just gonna answer from project management best practices, which was always from applied. You would understand that it, NMPP it had um the main, the main contractor was not very much fair with, with petrochemical construction, construction management. So integrating all the different con, you know contractors and it became a challenge because we did not have a, at the same point we had a meaningful schedule. Um it, it really was a struggle, we had so many contractors that even our configuration was not up um to the right standard. Our, and this was evident in the whenever there are change requests, even significant changes, it did not go through the change management board. In fact at some point we wondered whether did we even have a change management board. Some of the changes were made willy nilly because there was a lot of pressure from stakeholders. Remember it’s very difficult to manage, managing a project that is in a state owned enterprise where the stakeholders is the state and they have political interest, it’s very difficult. So managing these contractors was difficult because some of them were, were in the main, most of them were not um were not competent contractors. But for some reason of, of affirmative action or any of those important policy objectives. I blame more political interest because there were other better contractor that that could of came on site and still we would meet our, our affirmative goals and stuff like that. And we didn’t, we brought those that were not necessarily chosen by the project management team. So integrating them, merging them became an issue because we have issues of competency on their. And of course we do have competency issues on our side but they were more evident on their side in that they were not able to carry out their contractual obligations. So integrating they became an issue and this dynamic with state owned, we see it with Medupi, we see it with kusile, you see it …in most state projects.

Interviewer: Speaking about configuration management, how did you manage project documentation in the NMPP?

System Eng_B: How did we manage with, with um documentation? In fact part of the delays was because of the documentation. Now we have a system called aconex where, all, every, it was our form of communication management tool, aconex. It was there as part of the contract that every contractor that comes in, in fact in our communication management plan. Aconex is stated there as our communication tool, now most contractors when they came in did not use aconex. They stored information, documents, manuals and stuff on their own private system. Some they would be demobed (demobilized from site) and leave site, they would leave site with that documentation without uploading it on aconex. Now this is failure on our side as well because to process payment we were supposed to have asserted that those documents were always uploaded. As a result, some systems long after they were completed, we still didn’t have the documentation form, you know, who signed them off, you know. Who worked on them, we didn’t have. A perfect example is MIP, MIP at TM2 as a sub-contractor to, to our contractor, did what they did. You see when you are constructing, constructing a pipeline we need to know your, your heat maps, we need to know your welding maps. Everything to do with welding, you know. The, the pipe schedule, of course the pipe were free issue but everything related to, even the artisans involved, they, there are there are certificates and there are stamps and everything. We didn’t have that documentation by the time they left. But they were paid. So there was a problem with you know communication, configuration management. We had those issues when it came to documentation now, and we had, needed to close off the project. Cause for us to continue with commissioning we needed the documentation, so we did not have the documentation. We had to go back to the contractor, go through the litigation process, so the court process to even obtain some of the documentation. So, simply because we did not use, we allowed people to get away with predetermined methods of communication, uploading documentation and stuff.

Interviewer: No thank you very much Mr Mphahlele for your participation.

System Eng_B: I hope I was able to help.

Interviewer: Yes you were…

END OF INTERVIEW

Length: 11:40 Min

Date: 25/08/2017

Venue: Carlton Centre

Interviewer: Uhm Mr. S&A_PD, how are you sir?

S&A Project Director: Uhm I am well Sir.

Interviewer: Uhm just before dive into this let me explain that the purpose of the study is to evaluate the use of systems engineering in the organization, uhm the, the result for, are only for academic purposes uhm and the content of this interview will be kept confidential uhm and uhm I would like uhm your permission to record uhm and use this for study.

S&A_PD: Ja, uhm great, permission granted.

Interviewer: Uhm ok, what is your background?

S&A_PD: Uhm, I basically graduated with BSc engineering with electronics from the university of natal yeah it’s a 4 year degree e, uhm I specialized in control system.

Interviewer: Ok and how long have you been working?

S&A_PD: I have been working now since 2001 that makes it around 16 years of experience in the industry. Uhm electrical control and instrumentation.

Interviewer: That’s, that’s a lot, and how long have you been with this particular organization?

S&A_PD: Its almost 2 years now, yeah full 2 years ja.

Interviewer: ok and typically what’s the financial value of the projects that you’ve worked on? Be it outside and coming in into this organization.

S&A_PD: uhm looking at the last 2 projects that I did uhm, uhm the immediate on the NMPP’s components is sitting on R3 billion, uhm the last piece of work I did at Sasol, when we were revamping Sasol to Sasolburg the project was sitting at around R9 billion, so uhm ja the we were working on are mega projects.

Interviewer: Uhm I see and in your experience how would you define a successful project?

S&A_PD: uhm ok uh that’s a nice one (laughs)

Interviewer: Ja

S&A_PD: I think uhm ultimately a successful project is the one that satisfies the client’s requirements.

Interviewer: Uhm ok, so as long as the client are met

S&A_PD: Uhm also, also ja obviously within the triple constraint of the project management of your costs estimates and uhm your time and scope

Interviewer: ok and uhm how are you’re your project or system requirement set in the projects that you work on?

S&A_PD: Ok, uhm ideally your client is supposed to put together your first owner requirement specification. But uhm in my experience throughout the year what we picked up is that clients cannot put these documents together so you end up putting the documents together o behalf of the client, now what happens is that as the project uhm, uhm grows and the client starts to understand uhm the project better. Suddenly requirements evolve because he didn’t actually put the owner’s requirement together. I think that’s a very key challenge with the projects that I am, I have worked on so far

Interviewer: Uhm is that what we, we are using at NMPP?

S&A_PD: Uhm, uhm not sure who put together the owners requirement specification, but usually these are TPL clients requested EPCM companies to put together that spec for them. Which is not ideal. The client itself must know exactly what he wants before he goes to the market, at a high level you should know what I am looking for. You know how to get involved in a sand delivering business, I need a tippler or a truck, something with a beam. At least something on that level you should be able to articulate your requirements.

Interviewer: uhm so at the NMPP how do we ensure are met, the requirements that were set are met?

S&A_PD: uhm, so far if you look at the, the NMPP scope which the project started. Right now the scope has evolved so much that looking at it from a budget point of view. The project kicked off

at about R11 billions of budget, currently we are sitting at uhm, R30 billions. That’s actually a reflection of the scope creep that occurred uhm through the project, and that uhm has something to do with the requirements were not fully uhm were not fully understood. If you look for instance at the security uhm scope within the within our… our S&A scope. You can’t compare it at all with what was initially envisaged. The owner’s requirements were not in place, the owner didn’t know exactly what they wanted.

Interviewer: uhm ok, how is the, how do you know your planning uhm in the NMPP?

S&A_PD: At this stage I mean it’s more or less over, we are more into construction and commissioning phase. And the planning is more now around getting work done to complete the scope so their initial major planning phase is basically now over.

Interviewer: ok so how was it done on the NMPP?

S&A_PD: Ok looking at the documents… ok if you look at planning from project life cycle point of view. Uhm meaning uhm was scope properly defined, uhm, uhm I’ll say no. uhm if you are looking at planning from a normal uhm, project planning in terms of now planning activities to carry out the work. That obviously happened uhm I mean uhm as you can see that every project will have their program run on NEC3 let’s say contract. So any NEC3 contract, I mean basically you can’t run any NEC3 contract without a program. So from that point of view yes there is a level of planning that’s happening on the project, but if you are looking at planning from project life cycle point of view I feel that you know uh scope definition is not properly done, hence you know the scope keeps on growing.

Interviewer: uhm ok, are the any procedure, templates or guidelines that are in place?

S&A_PD: Yes where there is in 2007 Transnet put together at here PLP project where guidelines were put in life uhm what’s in paper is not necessarily what’s executed.

Interviewer: uhm ok and uhm how do you identify and manage risk? How do you identify and manage risk within the NMPP?

S&A_PD: basically every discipline there is risk management department where on a monthly bases we convene a meeting together with uhm the risk management department where we asses risks on an ongoing basis, and uhm to get the mitigations and get that integrated into the

schedules and, and into the time schedules and cost schedules, but ja it’s a bit difficult, since you know the process is uh not really integrated into the main into the main schedules. So it’s the process running on a side.

Interviewer: Ohk, and how do you ensure the level of quality that was initially stated is met in the project?

S&A_PD: ok we do have a QMS process we, do have quality, I mean QA, QC engineers who actually go through uhm documents, for instance, review of documents during procurement phase they do I mean inspection and final approval of uhm fabricated equipment with the vendors and during handover they also sign off on handover documentation.

Interviewer: seeing as it’s a multidisciplinary project, NMPP how did you integrate or how the different disciplines integrated,

S&A_PD: ok uhm … there is regular meetings I mean across discipline uhm on top of that uhm we also have documents, interface documents that defines various interfaces across your disciplines for every scope. For instance if you are putting together a security system that interfaces with… let’s say SAP and, and your fire and gas system. There is an interface document that talks to that.

Interviewer: uhm ok, uhm and how do you, how did you manage documentation?

S&A_PD: we have a document management system called Aconex, so uhm before producing documents we create I mean a document staps uhm following the document uh we call them what documents management you know uhm system. There is a document management system that defines uh how documents are numbers and uhm ja then ok once the document has been produced document control manages the life cycle of the document until it’s as built or the life cycle of the document is reached then handed over to the client, uhm yes, I mean on paper uh it’s all nice and well uhm in reality Aconex and uh also the uses. I wouldn’t say aconex, its more people who are using the system who actually didn’t do the system you know effectively such that we end up having niter data errors such that it’s not easy to retrieve documents that have been slurred in the system, and progressing them.

Interviewer: Uhm No Thank you very much Mr. Makhado this was insightful.

Length: 16:33 Min

Date: 28/08/2017

Venue: Carlton Centre

Interviewer: Um so this is my questionnaire, for formality I have to inform you that the purpose is to evaluate the use of systems engineering um at Transnet. Particularly with the NMPP project. With that said um, the results will be for academic purposes only. The contents of the interview will be kept confidential. With that said I’d like to get your permission to record the interview.

PM_1: Ok

Interviewer: So just to start off, what is your background?

PM_1: um electromechanical design, electronic design BSc, Masters and PHD in electronics. Um what else? And then I was in research for like 8 years, and now yeah I’m in Capital projects.

Interviewer: Ok so how long have you been working in totality?

PM_1: Since 2006, for about 11 years now.

Interviewer: And how long have you been with this organization?

PM_1: 2 ½ years

Interviewer: Oh ok, and what’s the value of the, typically of the projects you’ve worked on?

PM_1: Um I’ve worked on NMPP for a while, I think that’s around R23 Billion. Um it’s now its A100, B 100. I’m not sure of its value but um it’s like a whole port um design and building of ports. Something called lephalale yard which is a train facility. Again it’s quite big, I think it’s about R100 million, it maybe more. What else? And again this berth deepening. So projects are

Interviewer: And Prior to Transnet, how big were your projects?

PM_1: Um they weren’t big at all, less than R5 million.

Interviewer: So in your experience how would you define a successful project?

PM_1: On time, on budget and within scope (laughs)

Interviewer: that’s it? Ok, let’s use NMPP as a reference, how, how did you set your system requirements or your requirements rather?

PM_1: I didn’t do the requirements, so again on these projects I came after they had already started. So we were just taking work and doing things that were required of us. On the berth deepening, I did

do a system requirement for SCADA (Acronym for Supervisory Control and Data Acquisition), no, no, no for a substation.

Interviewer: And how do you typically do these requirements?

PM_1: So first step, you don’t start of from scratch, you find a, other….I mean it’s not the first time we building a substation. We find other specifications that have been done, plot what’s relevant from there, and add what we want. And then we must take into account new technology um, new functionality that people may want. Yeah but you never start from a grounding of zero.

Interviewer: So would that be the same for a….you spoke about the Durban Dig out Port…

PM_1: Yeah for that project…for all these other projects we doing ICT, CCTV and um P.A Scope. And some of them we also doing SCADA...right. So for the ICT stuff it’s mostly the same. The only thing that changes is the number of ICT points, where these points are located. And remember the ICT backbone also has your communication for your CCTV and your security and stuff. So I mean once you do this thing once most of the information is there. You just have to actually communicate with the client. See what they actually want, where they want cameras. Again you never ever start off from a point of zero. You only start off from a point of zero if it’s the first time in doing anything. So after ….The first time….it may take you longer, but every subsequent time when you do a project, it gets quicker.

Interviewer: And how do you make sure these requirements are met?

PM_1: you have to um, so the requirements now, you have to get your requirements stuff from your clients, the owner and the user. And then…how do you actually meet them? I mean these are, are in stone now. Those requirements aren’t met, you haven’t actually delivered on what you are supposed to be doing on the project. Again you make a checklist and ensure that your contractor actually delivers on each one. And it has to be signed up on each of those requirements. And when they do or when your contractor does a task or whatever, he himself must have a checklist that he presents to you on how he actually met the requirements that you have given him. If he hasn’t met, if he hasn’t given you the checklist then you don’t know. I mean you going to have to check them out as well. There, there’s two…it’s going to be multiple levels of checking…of checks and balances. I mean that’s the only way that I can see.

Interviewer: And in the projects that you are involved in, how do you do planning?

PM_1: Again I’m actually working on something for Bessie, um which is a spreadsheet. You can do your planning on Gantt, on Excel, where ever you want. The problem is actually making sure that the plan is actually followed. That is where the issue now comes in.

Interviewer: So how do you ensure that the plan is followed?

PM_1: Eish, Eish you asking me tough questions… (Laughs)

Interviewer: So for instance you were involved in the … (Cuts in)

PM_1: See the thing is if it’s a project that you have total control over, you can make sure things are done in the right time, right. But if you are relying on other people to actually start things off and you require them to actually have hours and staff booked before they can even start working then you have problems. So you got to make sure that on your start day you have all the preliminary stuff ready. You know who is going to be working, what are their capabilities. Can they actually do the work? All those checks and balances have to be done before, prior to your start date. You don’t actually try and find all of those people on your start date. Then you going to have….you will always be on the back foot.

Interviewer: Is that how it’s done or is that how it’s... (Cuts in)

PM_1: That’s how it’s supposed to be done but here it’s not done like that. Over here the project starts and then we start pulling in people. And then um you know the problem with that, um your time line progresses. There is no guarantee that you going to get that person who has the right capability to do the job. Once you bring them in it’s already, you going to be putting them under pressure to actually meet the deadline that you already signed on. It’s like the problem just compounds and snowballs after that.

Interviewer: And then um, during your planning process how do you identify project risks?

PM_1: Project

Interviewer: Risks

PM_1: Risks are everything that can affect your project, right?...affect your projects in any way, right, affect your timeline affect you getting like your materials, affect your human resources, where they are going to sleep, stay um. So you have to look at the project from start to finish and then start digging in each of these deliverables, tasks and then the people um that working, the group. I mean you have to take each on and like start asking questions.

Interviewer: How are they, after you have identified them how are you, how are they managed and, and mitigated if need be?

PM_1: Managed? Now, again it’s on a, now you can’t do a general case here. It’s on a case by case basis here. And again what I would do is I would find, I would do some research and stuff on the net, find out as many of these risks , how they were dealt with on other projects and then bring these ….how it has been handled in other projects. Is it still applicable, if it’s not applicable we start looking

at different ways of handling them. But, um again with (sighs). There is so much, for each of these, they got to do your research… Right.

Interviewer: So…did I disturb you?

PM_1: No, no, no.

Interviewer: Are there any procedures or standards that are in place within this organization?

PM_1: not that I know off, no, risks would have all your registers. Your risk register and then for each risk you have the RACI. You know who is responsible, who is accountable, who needs to be consulted, informed and stuff like that.

Interviewer: Um and in terms of quality how do we ensure that the project meets the right level of quality that was specified initially?

PM_1: Again quality has to be checked as you go. You don’t do…again with all the stuff here. You never ever do anything at the end. It is as you go along and as you see that the quality or the, whatever is deviating from the project plan you make corrections then. So now certain times what we do is we trust the contractor too much. Sometimes we give them a task and then we only come at the end and then we have a look at what’s been done which is completely wrong…right. You know the issues we have with TM1 and those tanks.

Interviewer: what was the issue?

PM_1: Ok I can’t really disclose anything but the problem again is a general problem. You are given …the contractor is given work. They go and do it on their own, we don’t really um, and what do you call it. The problem with us as well is that we don’t have the capability for some of these things. So we don’t really know what best practice is, or whatever. So for any of these things we need at least one consultant or expert in the organization to know these things are done. And as the contractor progresses that expert consults with them. And then the expert tells us:” This is ok, they have progressed, which is supposed to be a project manager and stuff but the project manager doesn’t know everything about everything, right. So for instances, so now you have a tank building project. You have to have a tank building expert within the field within the organization that reports to the project manager. He is the one that goes into the field once every 2 weeks or whatever and then tells the project manager they actually are doing things according to plan. Um and they are using the right practices, and then also you got to have something that can measure other than the person in the field. So for instances on like a tank building exercise you would have like drones fly around and take pictures, scan the layout or something like that, something measureable that you document at this point in time. Say at this time this was, this is how it was done. So if there is a problem you can maybe trace to where it could of happened.

Interviewer: Ok

PM_1: But then again that’s how you supposed to do quality. Quality is never something that you, you take at the end.

Interviewer: So how is it done?

PM_1: As you go, at 25 % is this thing working? It is, it is um. Is it within a set number…for like code and stuff…code is something different now? Again all of this is gonna depend on what you do. So with code, you can check the quality based on how big is your coding. Are they really using stuff or are they putting in stupid functions or whatever. But someone has to actually go and look at what they are doing.

Interviewer: Within your projects how do you ensure systems integration?

PM_1: Ay integration now, ay you know what (sighs). If each system is ideally right. If each system is working independently, they working fine and you, at the beginning you figured out your interfaces and you have done all of that right. Then the best way to actually do that is to stop wasting time or whatever. It’s to do a full system run at the end. Ok, you do your progress as you do your system tests. Right, but at the end now, once you have your whole project just run the whole system. It should um work, you know, as intended if it was designed properly. Depends again on the risk, if you run the whole system and there is a risk of something blowing up then you don’t do it. So um...but the point of this is that if your system is designed properly. At the end of the project the system should be working fine. That is just one test that you do with the entire. And, and that will save you time and whatever and you can see the results.

Interviewer: Ok, so how was it done with the NMPP

PM_1: I don’t know, I mean like I said I wasn’t working on the NMPP. I was working on something else that wasn’t on the NMPP systems.

Interviewer: Oh ok, I thought you were part of the NMPP.

PM_1: Yeah for a little while, I was on the facts and stuff for the control systems. Um we came in at the end. I was like observing what was happening. So from what I observed, I think it was done fairly well but I don’t know. I think it could have been done better.

Interviewer: There is always room for improvement.

PM_1: And um how are documents managed or how were they managed or how are you managing them?

Interviewer: Over here it was done very badly, um it’s something that I have noticed. The guys… can I mention another project that I’m working on. And again the same thing happened. You have

contractors working on this thing and then Transnet ran out of cash and they had to get rid of the contractor. But when the contractor handed over the documents, they handed over it over very badly from my point of view. It was such that like… I don’t think the engineers or the main people who were supposed to be checking what …you know at 5% you doing. Open up the assemblies, the drawing assemblies…open up the drawing assemblies. If everything opens up fine on the first check you know everything is ok. There is no major issues. If the main assembly doesn’t open, it starts popping up errors, then you know from there, there is now no reason for you to check. You tell the contractor to go fix it and you come back. As soon as you pick up an error you tell them you not going to accept this 5%. Go and fix everything don’t waste our time. Then you know they sort of get jerked up and they go and start producing. So you supposed to have, have like 10%, 15% …you know whatever percentage, whatever markers that you have. And you supposed to do it properly right. So what happened now is we got all this stuff from the contractor…and we didn’t have certain natives for certain documents and um we going to have to go and redo all of that work. Um maybe, maybe, maybe not so much because we have pdf’s. Um you just copy and the pdf’s and follow the pdf’s as is. But again it’s, it’s still wasting time, especially if you have like 10 000 drawings and you only have pdf’s and So again if doc control, ICT and all that stuff were doing their jobs properly that wouldn’t of happened.

Interviewer: um ok, we have come to the end of the interview. Thank you very much for your participation, this was insightful.

PM_1: Sure.

Length: 12:13 Min

Date: 28/08/2017

Venue: Carlton Centre

Interviewer: For formality, I have to, I have to read out the first paragraph. Which is the purpose of this study is to evaluate the use of systems engineering in the organization, with that said... (Cuts in)

PM_2: Is it, is it now for your own study or is it part of some job you doing here?

Interviewer: Its part of my own but I’m doing it with Dohvani

PM_2: Oh ok.

Interviewer: He is my internal supervisor

PM_2: Oh ok.

Interviewer: So um with that said, the results of this study are for academic purposes. They will not be used by Transnet or any other organization, and the contents of the interview will be kept confidential. I therefore have to ask your permission to record the interview.

PM_2: Ok

Interviewer: So um what is your background?

PM_2: Um I studied um, I studied BSc Computer Science in Wits.

Interviewer: So how long have you been working?

PM_2: I’ve been working for 13 years now.

Interviewer: 13 years, and how long have you been working for this organization?

PM_2: For Transnet um 2 years. Slightly more than 2 years. So let’s just say 2 years. 2 years & 3 months.

Interviewer: And um what’s the value of the projects that you’ve worked on? Let’s say the biggest project, what was the financial value?

PM_2: Um approximately R25 million

Interviewer: Is that within Transnet?

PM_2: Yes within Transnet, outside of, of Transnet I never got to know how much the project cost because I was a developer. Um ok.

Interviewer: And in your experience how would you define a successful project?

PM_2: Ok, um I would say it’s a project that is within budget, within schedule and it meets the requirements.

Interviewer: And how are your system requirements or project requirements set?

PM_2: um ok, that we will do…ok just the usual um requirements elicitation process whereby you sit with the client, you observe the systems they are working on. Identify gaps and, ja document the requirements.

Interviewer: And how do you ensure the elicited requirements are met?

PM_2: Um, ok um once …remember when we document the requirements now we have to send the documents back to the user for, um, comments for them to verify and validate these requirements. Then once we have agreed, they have signed off on those requirements. Then that would be done through implementation…once whatever system has been implemented, now we first do internal testing against your specification and then the user will come and do their own acceptance testing.

Interviewer: Alright nice, and how do…you do your project planning?

PM_2: Ok, you…myself I use the PMBOK guidelines, project management.

Interviewer: And how do you ensure that the plans are met? You planning is met?

PM_2: The only way, through monitoring. Is there any other way? (Laughs)

Interviewer: No, I mean…it, it all depends on who you are asking.

PM_2: Because now the monitoring now will include the progress status updates. These are done monthly. Ok within the team we have those weekly meetings where we discuss what has been done. And then um the overall project we, we um generate a progress status report monthly to update the client of where we are.

Interviewer: um and how do you identify your…you identify and manage risks within the organization?

PM_2: Ok um the identification um…since I work on systems now, you need to identify what available software is there and then if, if it’s not available then you propose to the client. If the client needs to provide the required hardware and software. If they cannot then you include those into you’re your, your…what can I say. You make provisions for those into your budget.

If the client now says I will provide network, you need to go to site to make that it’s actually there working. And then you also need to now, when it comes to cost, we need to provide, make a contingency…the budget is based on high level um requirements. In in um system development, throughout the years I’ve been working you know the thing needs…tends to expand. The cost um, the cost tends to expand. Hence now you need to make a contingency to accommodate that expansion. And then…ok the management would do…what …that risks meetings monthly. Risk meetings were you initially you have identified the risks…what has been done. What are we going to mitigate it? Some risks you cannot mitigate it, you just accept. But basically monthly meeting take care of that.

Interviewer: And do you have procedures and templates or guidelines that assist with management of the risks.

PM_2: um no, not necessarily. We just use …um ok, still when it comes to the risk I will use the PMBok guidelines. But what we do...we identify the risk, there is a risk team. If there are risks that we cannot um mitigate within our discipline then they are escalated to um ABSCO’s by that risk management team. Ja that team is not part of our department, it’s just their, their, I think it’s a team on their own. I don’t know who they belong to…but … (laughs)

Interviewer: Alright and how do you ensure that the quality is up to um the set specification?..

PM_2: Ok where we have standards we try and follow those standards. It will be up to what the user says when we do the acceptance test. Are they happy with what we have provided or not.

Interviewer: Ok and how is system integration done in your projects?

PM_2: Ok initially we specified the high level interface requirements. So now you um different systems….So you specify for each system the communication that needs, is needed. What data, you need. What is available and then when it comes to detail design now the contractor, remember here we don’t do in house developments. So the contractor would be developing whatever system. Then now it’s the detailed um interface um integration plan yes.

Interviewer: So now there is the plan, how do you ensure um that’s done effectively?

PM_2: That um that plan will be done. We take that plan and check whatever they are doing and check what is the plan. Basically that’s it.

Interviewer: Ok, ja the final question, how are project documents um managed in the organization?

PM_2: Ok, on um on, eish. Within the organization I think we use different management systems. I know um some places, they use um SAP as a document management system. But since I’ve been working with the NMPP for those 2 years we using ACONEX. Ja we use aconex, whatever we need to, we have developed a document we will issue that document via aconex. And now after they have review and they have comments, the document, the comments in the documents and upload again. Same thing with approvals. We issue approvals through aconex.

Thank you very much PM_2. This was insightful and helpful.

END OF INTERVIEW

Length: 19 :31 Min

Date: 25/08/2017

Venue: Carlton Centre

Interviewer: As a formality I have to explain the purpose of the interview, the purpose is to evaluate the use of systems engineering in the organization. I have to tell you that um the contents of the, the contents of this, of this interview will not be, will be kept confidential and not be given to anyone else and the results are for academic purposes only. And I have to ask your permission for recording the interview.

System Eng_A: No its fine.

Interviewer: Its fine? Alright um just to start of lightly what is your background?

System Eng_A: Background?

Interviewer: Yes

System Eng_A: So I have to say this in English heh?

Interviewer: Um that would be helpful (both laugh), its ok, for my audience it would be helpful.

System Eng_A: Um well my background is Automation, ok I started in Automation, like ABB, I mean that’s like the actual real work that I have done. Um then I moved, I was in Systems Engineering for, before I joined here, for the last 5 years before I joined here that’s in systems engineering in defense. At Denel, then systems um Armscor. Um so I know what you talking about and none of that stuff that you need is here.

Interviewer: Um no, we will, we’ll get to that (laughs)

System Eng_A: Just so we clear on that point, just so we clear that point (laughs)

Interviewer: So how long have you been working?

System Eng_A: 16 years now

Interviewer: 16 years? And in this particular organization?

System Eng_A: Um 2 (years), nah it will be 2 years, 2 years end of this month.

Interviewer: So in your experience, ok what’s the value of the projects that you, ok what’s the highest value of projects you’ve worked on?

System Eng_A: I think you need to acknowledge um, as much as we working on NMPP, I can only refer to the scope that I have worked on. Which I joined when it had already started. So the contract that we are trying to close up now, um is about R 235 million that was with Neotel, so we busy trying to close that um. I also worked on the Siemens project, I think the Siemens project portion of the work that I’m working on is about R120 million, about there, ja.

Interviewer: And prior to Transnet?

System Eng_A: Um well prior to Transnet it was, well it was not as much value but um I think I worked on a few projects that were in the region of 50, 30, 50 (million rands). I think the last one was about 57, ja um ja.

Interviewer: Ok, in your experience how would you define a successful project?

System Eng_A: Um a successful project, ok if we go by the book, it’s the 3 constraints of project management. Your time, budget and quality but um I think over and above that is that you need a project that serves its intended purpose. Um which …ja I think let me answer the question, it must serve its intended purpose.

Interviewer: And how do you set your system requirements?

System Eng_A: Ok, um like I said earlier, when we started this project the requirements were already set, but normally what you would look at is you would look your, your user requirements. That is the first cause, what you are trying to achieve here is that you are trying to provide a solution to your, your client. So your user requirements or operational requirements. And then from there you draw your functional designs and then your detail designs and eventually the engineering design that needs to happen. Um ja I think that’s about it. Obviously you can use the V-Model where it’s actually used here cause it’s adapted in the PLP. I don’t know if you understand the PLP.

Interviewer: I understand, so we actually use the V-Model?

System Eng_A: We don’t use the V-Model, but that’s how, that’s how typically…

Interviewer: Ok, in the NMPP what did we use?

System Eng_A: Um looking at how messed up the NMPP is, um I’ll be shocked if any model was used (laughs). No I think um we were, the whole systems were not connected. And the fact that if you look at the NMPP you would be able to find that there was a lot of consultants. And um with that you find that in as much as consultants were used, there were no um people within our structures who would challenge whatever designs they came with cause clearly we got the consultants, who didn’t know the details of the scope, so I think consultants are the

most um. They are the people who come up with a lot of these things. And I think the requirements as well, they were not clearly defined. I think they know what they wanted but they failed to communicate that towards us because at the end we like here now if you look at the URS’s within, I don’t know if you have access to it, to this um aconex. If you look in there you will find that the user requirements that are drafted there were not even drafted by TPL. They were actually drafted by us, so, so that’s a challenge,

Interviewer: And how did you ensure that the requirements, the user requirements that were there. How did we ensure that those requirements were met?

System Eng_A: How did we ensure that those requirements were met? Um ey mostly on the unit monitoring, we ensure that the components, from the component to the unit to the system. System on system, I don’t know if you understand that, um so you look at…fine if you are developing software um you make a small package and um that package that you call a component. Then from there it becomes, it becomes a system, and then it’s a system of another system, and then it makes an overall system. I think that’s how we went about it.

Interviewer: Ok, um and how do you, how did, how did you do your planning?

System Eng_A: You want the truth right?

Interviewer: I would appreciate it

System Eng_A: Ok, here is the truth, the truth is that we don’t do the work ourselves. The people who do the work is the suppliers, the people who um, who we would call subject matter subject matter experts within our structures here is the suppliers. So what would happen is that you would take the overall schedule, say on the overall schedule because we only a subset within S&A, we come right at the end. I think you would understand the specifics, we start with all the hardware and stuff like that. The valve would be installed but it’s not part of the scope, its part of um mechanical. Only then will we be called in to develop the code as per the requirements and provide the servers and PLC’s and what not right at the end. That is S&A but the people who are doing the work is Siemens people. People who are providing for network and the telephone network and ICT is Neotel. So then it would mean because they understand the scope and well they are supposed to understand the scope better and um their limitations. They are the ones who plan, this is how we are doing the work. So we take the plan and try and fit it in the overall plan. The overall plan would be um say to complete say TM2, that’s the overall plan for that. So we try and fit our scope in that and make sure that maybe there is some float in between that to make sure that we are on time. Of course it hasn’t been like that, we have not been on time.

Interviewer: What is, what, what has been the issue between what’s planned and what’s happening?

System Eng_A: Um there is a lot of managers within the NMPP and those managers don’t really, can I say they don’t really know what they are doing (laughs). I think the biggest issue that we’ve got, as much as we got this chunk of work, we are at some point disconnected. So we are disconnected even when, when you communicate that you would with such a scope in, in 3 months or 4 months. You get to a meeting and the project director is sitting there um and then he would tell you no 4 months is awfully a lot. You understand what needs to happen my guy, from start to the end, you understand but they say no you need to squeeze it in and um you are not given a chance to say no that’s not going to work. Over and above that um you get a chance to do the work but um processes stand in the way of what you need to do. Um like if you have to send through someone on site, you have to do a safety file. You do a safety file and then you send it to site and then it takes about 5 days to be reviewed and then you get it back there is findings. You have to send it back again. There is no urgency in this place. You send a PMI, project management is not there in the office just like people who are supposed to sign are not signing because there are 10 people who, who must sign.

Interviewer: Ok, and how did you identify risks

System Eng_A: Ok we had risk meetings, especially on site and risk meeting for say internal within S&A. So we would have meetings to discuss maybe strategic risks um and then you have meetings to discuss technical risks or commercial risk um. Some of those that are in control just so we flag them and then we able to complete them in time, yes mitigate them.

Interviewer: And then in terms of quality, how did you ensure that quality is to the specified level.

System Eng_A: Um ok, for every work, if you go back maybe on the previous question that you’ve asked how you would meet um how you make sure that you got your system requirements. Um with regards of quality, ok we have a quality management um team who does our QA or QC. Um but I think from a technical project management point of view. When you test your systems say stage zero, stage one, two and three. So you’ll have four stages of checking the quality and first before, even before you get to that you need to check the quality of your design documents. um your engineering, your design specification compared to your ORS, um so if those are sorted, or if those are in order it makes it easy for you to go and , and develop your, your commissioning plans, your quality plans because they tie in together like that. So you would look at, looking at quality on the systems or components or quality of subsystems in a hierarchal level and of course um the standards we follow the TPL standards that are obviously guided by the SANS standards ok.

Interviewer: Ok, and then how do you do systems integration in your projects?

System Eng_A: How did we do systems integration? Ok um within, I think S&A it’s those stages that we were talking about, your stage zero just to say that no the camera is there or the server is there. Stage one is when you start seeing can this thing even switch on. Is it done right and what not? Stage 2 you check each system alone (coughs), system alone um, that’s camera works fine. And in stage 3 you have now integrated the systems. If you opening the door, the mat lock will disconnect, the camera will zoom in to the door that just opened. Then when you get inside the building, the PAR needs to activate. On a lower level or a detailed level of projects, of a project like that security system project. But on a bigger scale, like where you find the whole of TM2. Like how do you go and integrate that, um since we come right at the end as S&A we try come in to integrate. You would have done your own test on the component level, subsystem level and system level. And then when you connect to the system as a maybe a cold commissioning, is when you try and check the valves, the opening (inaudible). That’s how you will be looking at your integration, um all of these things are supposed to be done by an engineering manager. I think especially at TM2 we’ve had a lack of such um, I think that might be one of the issues or if they are there they have not been forthcoming, ja.

Interviewer: Um ok, and how are your project documents managed?

System Eng_A: By Percy and Victor (laughs)

Interviewer: Who is Percy and victor (laughs)

System Eng_A: Ok, um ja, we had a plan on that, whenever a system is handed over. You can test it and then it can work perfect, as long as the documents that has to do with that, which were defined right from the start um as post or your maybe design, ja um from the onset. From the user requirement. If all those documents are not there, the system is not handed over. So as part of the test packs that we did for a specific system, we would say for this thing to work we must have operational manuals um, it must show the data sheet of that system. Um it must even, ok the QC itself which includes this. So until all of those documents that were ticked off from the start are ticked off on the register, that system is considered not taken over or handed over at all. So that’s how we managed it.

Interviewer: Thank you very much for your time. That was very insightful

System Eng_A: You are welcome.

Length: 11:07 Min

Date: 25/08/2017

Venue: Carlton Centre

Interviewer: The purpose of the study is to evaluate the use of systems engineering in the organization. Um the results will be used for academic purposes only and the contents of the interview will not be shared with anyone, yabo(you see). So I have to ask “ipermission”, your permission to, to record the interview.

Risk Manager: Ok you can record it yeah.

Interviewer: So what is your background?

Risk Manager: Um what is my background? Academically, it will be chemical engineering and I also have project management, currently doing project risk.

Interviewer: Ok, and how long have you been working?

Risk Manager: Overall work experience, how long have I been working? This is 2017, I’ve been working for 12 years.

Interviewer: Oh that long

Risk Manager: Yes

Interviewer: And how long have you been with this company?

Risk Manager: For 1 year, because I…

Interviewer: And before this company?

Risk Manager: I worked at Eskom, as a systems engineer.

Interviewer: Ok, so you must be familiar with the terms neh?

Risk Manager: With the?

Interviewer: With the terms

Risk Manager: Yes, yes as I said I was a systems engineer, I practiced engineering for some time.

Interviewer: So what’s the value of projects, or the biggest value of the projects you have worked on?

Risk Manager: It would be NMPP, how much is NMPP?

Interviewer: Some say its 27 billion (Rands), some say its 30 billion (Rands)

Risk Manager: It’s 28 billion (Rands)

Interviewer: (Phone rings) um and in your experience how would you define a successful project?

Risk Manager: It would be project management um, what do they call those things. It needs to be within schedule and cost, so that’s what it means to have a successful project.

Interviewer: Ok, and how do you set your project requirements?

Risk Manager: How do I set my project requirements? Um I think it would be the mere fact that understanding what the client wants and then try to check what are the options to resolve that. And then present that, or have a common understanding with clients on everything whether the objective, the outcome and everything that will be concerning the project. And to be transparent enough ukuthi (So That), what are the risks that you foresee, what are the things that you see as hindrance points or constraints within the project.

Interviewer: Ok so are those system or you are just speaking (Cuts in)

Risk Manager: Project, I’m speaking as the overall project. Yes

Interviewer: And how would you ensure that those requirements are fulfilled?

Risk Manager: I think if you have transparency and continuous communication because once you know the needs and then you continuously have a communication ukuthi kahle kahle how are you analyzing things, things and communicate that to the client and have an understanding.

Interviewer: Um ok, and um planning, how was it done in the NMPP?

Risk Manager: Um, ok for sure you know that NMPP is a different project because it started and it wasn’t completed within time and within schedule, so it was one of those failed project management planning values. Yes, the planning side of things, the organizing, the controlling, cost of them, they failed. But managing to pick up what is failed, it’s to review the strategy and how thing were done previously and the lessons learned and try to change the strategy on how you did things and how you planning to do things differently.

Interviewer: You speaking about planning, were there any guidelines or templates that were used on the project?

100

Risk Manager: Yes, there would be templates and guidelines, in terms of like project management asa whole? So then there would be a follow up of, I mean using the PLP. And then each and every discipline would have its own um guidelines of how things are done, how are they supposed to be done.

Interviewer: And then coming to your area of expertise, um risks, how did you identify risks?

Risk Manager: To identify risks in a project firstly you need to understand project objectives. You need to understand project objectives and you need to understand all angles of the project. That means you need to understand all angles of the project. That means you need to understand where we are in terms of um planning side and then cost wise, everything that has to do with that. And then you help the project to, um actually think of anything that can hinder or anything that will be uncertainty to the objectives. So you do that by interrogating, because that’s what we do most of the time. But you can’t interrogate if you don’t have um, you don’t have a basic background or you don’t have information about the project.

Interviewer: And when you have identified those risks, how do you manage them?

Risk Manager: By continuous meetings, continuous follow ups. That’s what you do, you have due dates. If you have um risk, you need to fully identify what is the risk and the causes of that because what you mitigating is the cause. Because you don’t want to repeat like, let’s say again and again. So now you need to follow up, have action items, and have due dates so that you can see your performance.

Interviewer: And um in terms of quality, how did you ensure that the specified quality was met on the project?

Risk Manager: In terms of quality, we think maybe they do ama’audits. Yearly audits , so now that is being done by the external person, so they would pick up with “…” you need to ensure that you work according to the plan, guidelines and the policies because if there are any deviations then they would be picked up during audits.

Interviewer: Um ok, do you know how systems integration was done on the project?

Risk Manager: And when you talk about systems, what are we talking about in a nut shell.

Interviewer: There are different types of systems, you electrical & mechanical but they all have to work together for that particular function.

Risk Manager: Ok, because (Oh fuck) of when I came to the project, it had already started. It was something it was there but um so I wouldn’t know exactly everything else how it was

101

structured, planned or executed but what I know is that they would (phone rings) continuously have um, sorry(pauses and answers phone).

Interviewer: Um we were talking about integration.

Risk Manager: Integration yes, so where we are now, we currently at execution or maybe one system which is tm1. Now in terms of integration there they would have um meetings with the whole team and check what is still outstanding and how far each discipline is with each activities that they were supposed to do

Interviewer: And in terms of documentation, how were they handled on the project?

Risk Manager: Um it’s the same strategy that they were using. What they did is that they identified all the… what do they call this, every discipline that has to submit the documents and then identify what are those documents and then identify what are those documents that need to be part of the handover. And then from there they would track what is being submitted and what is being uploaded on Aconex. And then we would have meetings fortnightly just to check the progress. But the tracker was developed by the client and TGC. So it was an agreement between the two.

Interviewer: To track the documents or to track the work that (cuts in)

Risk Manager: The list of the documents that had to be handed over. And then as well as the tracker on which ones will be the top priority and things like those ukuthi we wouldn’t accept this kind of drawings or these kinds of reports as a handover. So we would have meetings fortnightly or so just to check the progress.

Interviewer: Ahh thank you for your time, we have come to the end of the interview.

END OF INTERVIEW

102

Length: 18:15 Min

Date: 30/08/2017

Venue: Carlton Centre

Interviewer: Mr. Planner_Man, the purpose of this interview is to evaluate the use of systems engineering in the organization. With that said, the, the results from here will be for academic purposes only. And the um contents will be kept confidential. No, no one will know about this, um with that said I’d like to get your permission to record this session.

Planner_Man: No, that’s fine.

Interviewer: Alright, um so just as we start, what is your background?

Planner_Man: My background, I studied electronics, then from there I worked for basically a defense company. Um I worked on the famous Gripen system. I think you are aware of that. Gripen is one of the famous projects, Arms deal. Then from there I did mining and I was working in (inaudible), in an expansion projects. Then I’ve spent the last 3 years with Transnet, 2 of which I was working on oil and gas.

Interviewer: Ok, so you say, how many years have you been working?

Planner_Man: In total, I think close to 18(years)

Interviewer: And with this organization?

Planner_Man: 3(years)

Interviewer: 3 years, ok. And what’s the value, the financial value of the projects that you’ve worked on? Or the highest.

Planner_Man: Um shh, it should be in the ranges of 2 Billion (rands)

Interviewer: Ok, um and how, in your experience, how would you define a successful project?

Planner_Man: A successful project is meeting the clients expectations, that’s one and sometimes going beyond the client’s expectations plus sometimes the client does not know what they really want. So we as the project team, we should actually influence and make sure that, in the sense of what the client wants we surpass his thinking that comes to mind…to add to what I said. What makes a successful project in our environment is injury free and that’s, that cannot be compromised, Safety first. And depending on the project nature sometimes time is more important than cost, sometimes cost is more important than time. So one has to

103

understand where, how those 2 come together. But there is a theory that, I mean theoretically people will say a project is in time, if it’s successful it’s within cost, money, quality. What…I believe you know projects failing. When you building a hospital in a rural area, I think time is of essential because lives are at a cost. So, so you can’t put a, an umbrella definition on what’s a successful project.

Interviewer: So its project specific.

Planner_Man: Ja, because sometimes it’s the quality, quality ranks higher then everything regardless of the cost.

Interviewer: So, how um are your project requirements or system requirements set? Like speaking from this organizations point of view.

Planner_Man: How are our what?

Interviewer: System requirements

Planner_Man: You mean system, this sh…, explain further. So that I don’t put things in my head. Systems in what?

Interviewer: A system is built for a specific function and it has to have certain requirements. The, the reason we do projects is to fulfill a requirement. So…um how are those requirements set?(Long pause)From the NMPP how were they set?

Planner_Man: With the NMPP, it was poorly set because firstly I believe they awarded without, um without the final designs. Two, the project team constantly change, constantly, so you’ll find that every six months you have a new project manager. Um if we use the NMPP, the design engineers were chased, they were not chased, let me rephrase, they left the project. Then you had new design engineers, so obviously there were a lot of gaps which were missed, um group 5, they not an oil and gas….from my experience better oil and gas companies could of finished that job quicker. So the requirements, if you say the system how were they set. Specifically for the NMPP, then they were done poorly. Um although I was not there on the initial setting. I just received the back end and obviously the history, I had to study the history, I had to study the history obviously to understand where we had been to. I hope that answers your question.

Interviewer: It does, it does to some extent but when you were there, there were requirements that were set, how did you ensure that those requirements were met?

Planner_Man: I think um, obviously the first step is meetings or design meetings with the contractors. We had different subject matter experts walking on site inspecting and seeing the

104

implementation um, we had third party coming to verify, to see if the requirements we were setting, we were achieving. So we had an external third party in the form of AIA’s. And once in a while we would get guys coming from Europe to just check if we are building according to specification or according to our own systems as you put it. If we were reaching there, so every three intervals we had specialist, we had outsiders looking besides our own team. Progress meetings and we had um a war room to ensure that everything is done.

Interviewer: Ok um and how was the project planning done in the NMPP?

Planner_Man: Project planning, what we did was basically went back and said, what is left to be installed and we used a thing called weld units. So we knew how many welds a guy should be doing per day. Depending on the radius or the inches of the pipe. So basically we had a tracker where we expected a certain amount of welds to be done within a certain period. So it was very detailed, and in the evenings we had meetings where we would hold the contractor accountable. We had projections of the type of work we should have been … we had look ahead. The type of work that had to be done within a month, 2 months, within the completion, completion period of the project. So it was very detailed, extremely detailed. Um we used obviously primavera, excel spreadsheets um for tracking sheets. So and there was mitigation plans. Where we didn’t meet, the guys worked night, night shifts to catch up. So there was consequences for not meeting the target.

Interviewer: So those would be your project risks?

Planner_Man: Project risks, no, project risks neh, on NMPP (cuts in)

Interviewer: So your mitigation um would be to ensure that your plans are carried out?

Planner_Man: Yes, yes, yes. So you right about risks but we were micro-managing the project. So let’s say you didn’t weld your 14 inches which you were assigned to do. Then you work an extra 2 hours after 4. Or you come in on Sundays to do that. If you were hydro testing and that hydro test didn’t happen and if the temperatures allowed at night. So you are right to say you were managing the risk on schedule. Although there were many dynamics of risk you know. There were risks of like non-payment, people not coming to work. But whatever um, um, we did our share in the sense of managing (phone rings) this huge risk. I think you are right, it’s um (cuts in)

Interviewer: And your other type of risks, how did you identify and manage these?

Planner_Man: If you say that, are you meaning um schedule risks or other risks?

Interviewer: Your other risks.

105

Planner_Man: How did we identify and manage them?

Interviewer: Yes

Planner_Man: I think identification of these was um quite easy but managing! Most of them were based on the board at Eskom. For instance, there was payment disagreements. So that was resolved at our GCE’s level. Because that was the biggest risk, payment. The other risk which was sort…most of the other risks were associated with payment because the other risk was reworks. A lot of reworks, and I think we held up group 5 hostage by saying, you don’t fix your reworks. So there was a lot of negotiations to manage the risk. Um so your top risk was obviously payment, high turnover from the project managers from Transnet side, contractor’s inability to execute work because they are not an oil & gas. They say they are an oil & gas company but they are not really. So we had a risk register which is run by our risk manager. So we listed all the risks weekly, those we could handle we managed. So there were risks which could be managed by the project manager, risks which we had to elevate or escalate to the executives. Risks which executives couldn’t manage, they had to escalate them to the board or Siya (CEO). So that’s how they were managed, those that couldn’t be managed were escalated until it found the right people.

Interviewer: So are there procedures or standards that assist in those risks.

Planner_Man: (Pauses) Yes there is, there is, there is some risks were basically recorded for the sake of recording. I hope I’m not contradicting myself. They were recorded so that when they do happen we highlight that we do expected this to happen. So you had risks that were standards and procedures how you mitigate. Who do you transfer the risk to, such things like that. And there were risks where we knew we would not settle with group 5 payments but we had to write it down until the board took a year or whatever to pay the requirement.

Interviewer: Ok, and how did you ensure that the projects were up to the quality that was initially specified?

Planner_Man: I don’t…, we had a third party specifically for quality, AIA (Authorized Inspection Authority). So what would happen, the contractor would do his own quality inspection, then he called Transnet guys to do their own quality inspections. Then the 3rd partly will look at it. Then the last guy was Transnet pipeline, where they would have a final say if they’ve accepted or not. So you had like a four system, you know, quality checks.

Interviewer: And how was the integration done on the project?

Planner_Man: I think it was carried out in meetings and also site walks, so every evening we would have different disciplines, your mechanical guys, your civil guys, you’ll have your

106

electrical guys and there was a lot of discussions. One, one of the good things, we tried not to do things twice. So you get your painting guys coming in the end, when everyone was finished. But we knew we could only integrate it correctly, there would be a lot of reworks. So there was a lot of reworks, I mean integration.

Interviewer: Then how were your project documentation managed?

Planner_Man: They were managed poorly because mainly as I lauded earlier, there was a lot of change in management. So you get a situation where the last team on site is one which is basically looking for missing documents. Remember when one person resigns, you don’t really have time or his contracts ends, they might not pass on the knowledge of where the documents are. So they are there, I mean we use a brilliant system called aconex but somebody needs to do the work of consolidating, checking if everything was included. So that’s why I was saying they were poorly done was because of constantly changing management and the use of consultants. I mean they can deliberately, for them to extend the contracts, withhold documents. And the way you part is very important cause usually consultants want to hold you hostage until you pay them.

Interviewer: Alright, that brings us to the end of our interview. Thank you very much for your time.

Thanks.

END OF INTERVIEW

107

Length: 16:13 Min

Date: 25/08/2017

Venue: Carlton Centre

Interviewer: Mr. PM_4

PM_4: Yes

Interviewer: Afternoon, how are you sir?

PM_4: Good thanks

Interviewer: Um, let me start by explaining that the purpose of this study is to evaluate the use of systems engineering in the organization. With … particularly with NMPP. Um, id therefore like to state that the results of the study are for academic purposes only. The contents. And further the contents of the interview um will be kept confidential and with that said, I’d like um your permission to record this interview

PM_4: By all means.

Interviewer: Mr. Masingi what is your background?

PM_4: Um mechanical Engineering, I did mechanical engineering.

Interviewer: Um and how long have you been working for this…um how long have you been working in general.

PM_4: Um how long have I been working? Um 3 years.

Interviewer: And how long have you been working for this particular organization?

PM_4: 3 Years

Interviewer: Um ok, what is since…as a project manager what is the financial value of the projects that you’ve been involved in?

PM_4: Financial value? Um looking at now at Transnet like the value it has added at Transnet or?

Interviewer: No, no, no the monetary value, how much. (Cuts in)

PM_4: Oh like they money, the amount of money like projects or should I just give you the estimate total cost of the project. Um ok, one um I was involved in recently um, um, it was R15 million that was the ETC. NMPP was um, um, the last time I checked was R29 Billion. It could

108

change and there is Overvaal which is now. Overvaal I’m actually new, um I recently started the Overvaal project but its R5 billion.

Interviewer: Um ok and in your experience how would you define a successful project?

PM_4: Um a successful project will be one that is executed within um, um the given budget and the given time period and shouldn’t exceed the approved budget. And completion and handover must be done in the timeframe given. I deem that a successful project.

Interviewer: Um how are your system project requirements set?

PM_4: What are you talking about, would it be, are you talking about the FEL phases or…

Interviewer: Um you have…the reason you doing a project is to (Cuts in)

PM_4: Yes, yes a temporary this service or product….

Interviewer: How, how are those requirements set? How do you set them?

PM_4: Um no, I don’t think I am clear on this question.

Interviewer: Ok bona, let’s say for example, for arguments sake there’s a project that a, ok jah…a project to (pauses)… to build a phone, who sets the specification?

PM_4: Ok, how, ok. It will be the client, the client will come to TGC with a full specification that a project that we want you to manage. They will give us the owners Requirement specification. They will give us the scope of work. They will give us the business case, but then it will depend on the amount of work that they want us to do. But in most cases the spec comes from them. We just manage the project. So we have all the specifications from um probably say TFR for arguments sake. They give us all the specs and say this is the project, we want this to be like this and that to be like this. And then from there we do our further investigations. And if we find that the spec that they’ve given us are um in line with our own investigations, then we go ahead with the project but if we find that there are discrepancies we have, we sit down with the um client itself and we give them advise…advise on maybe um, um on how this project should be undertaken as opposed to what they gave us because they just gave us something and said they want us to do it like this. But we do our own investigations and probably if we see that there are any discrepancies we communicate with them to find the best solution.

Interviewer: How do you make sure the requirement set are actually met?

PM_4: Um in many cases there is an evaluation committee that um, the evaluation committee consists of an external, normally consists of an external um person or company. So we would, would, what is the best way to explain this. In most cases in most cases I’ve been involved in um ok. Determining that the specs that have been given meet…you say that they meet what?

109

Interviewer: Um the spec is met.

PM_4: Um the spec is met, let, I’ll talk about mostly execution. Execution will have the specification of the project and the quality manager normally does the verification with regards to the work that was completed. You look at the original spec that was um submitted probably the FEL 2 study. In most cases the specifications are given in FEL 2 study, which is the feasibility study. So we use that study and, um the specification given in FEL 2 study and if there are any amendments and we look at the final spec and compare…checks it with the product itself. Whatever the project…whatever you are checking it against but you must look at the actual product or physical. It must be tangible um in most cases.

Interviewer: And um in, in the projects maybe particularly NMPP, how did you do project planning?

PM_4: Planning of?

Interviewer: Executing the project…

PM_4: Oh executing the project, on the planning is normally um we sit down with the client or the contractor, the people who…cause in most cases we manage the project, we are actually the middle man. So with the planning we sit down with….our planners sit down with the contractor and come up with the schedule that fits the, schedule that both suits the resources, our resources and their resources.

Interviewer: Are there templates/ guidelines for

PM_4: Eish with planning…in terms of planning I’m not sure of the procedures that they follow. I haven’t been involved in much of the planning.

Interviewer: And how do you make sure the plans are carried out?

PM_4: By having weekly meeting and progress meetings with… through progress meetings with and weekly meetings and weekly progress reports.

Interviewer: Ok so that would be all?

PM_4: So you check against your planned targets on a weekly basis to ensure that everything goes according to plan.

Interviewer: Um ok, and how do you identify and manage risks?

PM_4: Um (pauses), um project risks.

Interviewer: Please come closer

110

PM_4: Project risks, how do you manage project risks? Um in most cases we have a, um a risk register um (pauses) um ok, but the ones that I have attended um normally they would have monthly…depends PM on how he wants it to be. But normally we use a risk register um that… So once the information in that risk register is that you have the risk right, you have the impact…I’m trying to think of what’s in the, the risk register. Yes you will have the risk, level of risk and risk impact (pauses). Can we come back to this one?

Interviewer: Um not a problem, not a problem. Um and then how do you ensure the correct levels of quality are attained um within the project?

PM_4: Through quality inspections, um yeah through quality inspections not when the work is completed but when… during the execution of the work. We do, they do normally inspections, quality inspections during the execution of the work and when the work is completed.

Interviewer: Who does these inspections?

PM_4: The quality assurance um the quality assurance team.

Interviewer: Quality assurance team.

PM_4: So in most cases you’ll have a quality guy from the contractor’s side and the quality guy from our side. The quality guy from the contractor’s side is just there to take notes if the quality guy from our side is unhappy with the results of whatever was executed. Then you… (Pauses) in most cases you will refer to that as reworks or defects and now they have to redo until we are satisfied.

Interviewer: and how are the different disciplines integrated, in such projects, I mean it’s a mega project.

PM_4: Um all, all the disciples or just engineering

Interviewer: All the

PM_4: All th…

Interviewer: How do you ensure that they work together effectively to achieve the goal that is required?

PM_4 :( Long pause)….I’m trying to think all the disciplines, engineering, mechanical… (Pauses)

Interviewer: S& A all… how do you put them…? Its ok, let’s move on to the next one. How do you manage the documentation in (Cuts in)

111

PM_4: Documentation portal called aconex. That’s where we share and store our important project documents.

Interviewer: Um so you spoke about going back to… (Cuts in)

PM_4: It’s called document control, we have a document portal that we store and share documents. As long as you have access, irrespective of your location, you can access any document that you want.

Interviewer: Um ok…you said we can come back to the risk management question.

PM_4: What was the risk?

Interviewer: It was how you identify risks or how did you do it during NMPP

PM_4: Um the NMPP project we would have weekly risk meeting with the head of each department. The head of each department, be it planning manager, construction manager. We would have a sit and look at the register and the mitigation plans and where we had any issues. When the head of each department would say or notify the risk manager of any risks within his workspace then come up with mitigation plans on how we can prevent that risk from occurring. Or if it occurs, how do we ensure the consequence is not too much or catastrophic.

Interviewer: Ja Mr. Masingi thank you very much for your valuable time. This is very insightful.

PM_4: It’s a very good questionnaire.

END OF INTERVIEW

112

Appendix C – Analysis

ID Q# Response Code/Summary Man Requirement So what…what used happen, especially on the NMPP Requirements set by is um, the, the operator or the owner of the asset just TGC, an example of said they wanted a system that can do one, two, three, project worked on. Level four. But then it was left up to TGC to come up with of requirements the requirement. TGC attempted to, to come with the elicitation not up to requirements but they didn’t include the owner. That’s standard. Sometimes what happened initially, to the extent that the system requirements are done that was specified was, is not what the owner wanted. by the Engineering What happened is that the owner ended up going Consultants. outside, to an external company to develop the (Engagement between system for them while TGC manages the external owner and EC). company. The owner talking directly to the external Requirements were so company to produce whatever they want. That’s the poorly done that they bad way of doing it. Then what happened as well is have to be done each because the system was not fully specified, they used week and worked upon what they call, um, I’m not sure if you know the project to ensure. implementation methods. You have your waterfall method, then you’ve got your, your…what do they call this thing? Your rapid development method. So instead of using the waterfall method, they decided not to use the waterfall method because you use the waterfall method once your requirements are fully defined. They ended up using the rapid development, which is basically meeting with your client every week. The client determining, determining what the client wants for that week you have to develop what the client wants. That client comes after a week and checks what you have done compliments what they wanted.The best way to do it I reckon is the waterfall.

113

You have to be comfortable to a higher degree of what the client wants/requires before doing the engineering work. But in this case we were doing the engineering work and trying to determine what the client wanted and that resulted in a lot of overruns. Cost overruns and schedule overruns cause a project that was supposed to take what…one year ended up taking six years.

follow up So what we do is that for every activity that was given, Requirements we will set up the acceptance procedure of the acceptance agreements requirement first so that we are in agreement with the are done prior to doing client of exactly what we are going to test. If it’s a pass, the work. how a pass should look like. If it’s a fail, how a fail should look like Planning Like I said, project planning was very bad. So we Project planning was ended up doing it on a week by week basis (laughs). done on a weekly basis. So one of the thing that resulted from there was that Planning department is the project was supposed to be one year, it resulted in available. Incorrect it being 5 years. But that’s when we ended having to contract type in place select the right the right contract for the kind of work. So you can’t come up with um, um what do they call this…project where you know the cost of the project. Ja this was, this was time & material contracts. So then it was open and didn’t have a cap. So which means that the, the external contractor didn’t, didn’t have a cap on the amount of work that they could do

114

for us. That’s one of the, the reasons why the project kept on escalating.

procedures : Yes, we had a planner, um who planned our Yes procedures and & Templets activities. So it was still planned even though we were templates are available doing it on a week by week basis. It was still planned, to assist with the we didn’t have a sense of, an overall plan. A master planning. plan because everything was done on a week by week. planning So what will happen is we normally have, remember regular communication follow up there is 3 people in the picture now. It’s the client who between the is TPL, its US TGC and then it’s the contractor. TGC stakeholders involved is sitting between the client and the contractor. So makes monitoring and what we, you would do is that TGC would go have, managing the plans before you have meetings, 3 of us that’s going to happen that week. Then that week, TGC must manage what happens. TGC will manage that by having 2 meetings in a week, after that the final meeting will be with us and the client and the contractor, Just to check the progress. And then we also, what, what had as well, um TGC also supplied engineers that were seated on site of the contractor to make sure they address the technical issues that arise from the contractor. To make sure that they keep progress of what the contractor is doing on a daily basis so that when we have progress meetings, our meetings are short. They are not long. Risk So we have a standard risk methodology for TGC, and Standard risk that would be every week, no every month, we will sit methodoclogy/procedure with risk specialists where we will identify technical in place. Identify risks, risks, thereafter identify the impact of those risks on potential impact, rank schedule and costs. And then we would rank them according to likelyhood from one till whatever and then we will start to identify of happening. Monitor

115

different mitigation activities for each risk. And then the mitigation plan on the the next meeting we will follow up on mitigation risks risk and see what has happened. If our mitigations were not good enough we will put on more, additional um risk mitigation issues, um methods.

Quality Um the quality goes back to us providing TGC Monitoring the the resources on site, to the contractor, to ensure that the contractor against the contractor is doing what we want him to do. That developed specification monitoring, that everyday monitoring. as indicated in the QMS. Integration For this project it was…before the system was Well documented designed, an architecture of the system shows how architecture of the the whole integrated system should operate. From, system. Well defined from there we developed requirements for the system intefaces. interfaces for the different aspects of the system. Um Different levels of testing and after specification that’s what the contractor had done on the system. to do. But as well when we went to site, so we have Initial tests were on parts different levels of commissioning. The first thing we , components, commissioned will be your instruments without the subsystems and finally control systems then the second element that we will systems. (bottom up commission will be the control system without the approach) instruments. The level above that will area commissioning. So you, you commission the system but it’s not yet integrated, you only integrate an area. You check the functional operational operation of that area. Then, then the last step will be integrated system testing. Then the last step will be integrated system testing. So it goes per levels so that, that ensure the system is safe to operate. Because if you just integrate a system at a high level without making sure that the lower level are well integrated then that’s going to have problems, you not going to see where the problems are. It’s going to take a lot of time troubleshooting a lot of the problems.

116

documents Aconex system, But Aconex system is not just a Platform for documents management document management control system. It was just a to be managed. Aconex, legacy system that was decided that, the project shall store and manage use aconex. I think that the main reason to use aconex documents. Document was this project comprised of many stakeholders who control team to manage are graphically situated in different parts of the world. the documents. So it was easier to transmit the documents between Document management the stakeholders. But inside ourselves we had a plan in place. Naming document control team that documented, that kept our conventions. A backup documents in order. Before it all started we had, a um was in place to document management plan that determined how we going to manage the documents. What kind of naming convention we going to use for the documents. Um what kind of, off um document classification we wanted? Cause for example in systems & automation you’d get different systems. You would get an ICT system, you’ll get a ccv system, a control system. So you would want to classify your documents like that. Aconex is not a repository, it’s just a transitory system. Our self we just had a backup and um a shared folders of where our documents are kept.

117