Prof C Marnewick - Inaugural Address Page 1 of 18

REBOOTING INFORMATION TECHNOLOGY PROJECT MANAGEMENT

Professorial Inauguration: Prof Carl Marnewick

Introduction

Rebooting your computer or mobile device is a fairly simple activity but for the computer to perform the rebooting task, seven technical steps are involved (Shelly & Vermaat, 2008). The process of closing and starting a computer or its operating system is known as rebooting. This process reloads the operating system and is used to fix many common computer problems, such as slow processing or freezing. There are two types of rebooting, i.e. a cold boot or a warm boot. In the case of a cold boot, the computer starts from a powerless state and performs a power-on self-test (POST). In the case of a warm boot, an all-ready switched-on computer is restarted and it returns the computer to its initial state (Shelly & Vermaat, 2008). There are several reasons why a computer needs to be rebooted. The most obvious one is when there are too many tasks running concurrently and these tasks are blocking the memory from functioning correctly. The only way to clear the memory is to reboot. In other instances, a reboot is necessary to resolve problems temporarily, such as bug fixes or malfunctioning hardware. A reboot is also needed either when new software is installed or updates are required. As is the case with computers, disciplines are also in need of a reboot. Sometimes a discipline is stuck in a rut and is in dire need of a reboot. This reboot entails considering what is currently working but also getting rid of what is not working. A reboot of a discipline is also needed to update or upgrade the discipline with new trends and thoughts. One of the early advocates of rebooting project management is Levitt (2011), who advocates the transition of project management 1.0 to project management 2.0. He highlights various problems or issues with the current way in which projects are managed. A major concern is that the traditional approach as preached by the PMBoK® Guide focuses on a handful of experienced and knowledgeable project managers to produce a detailed project schedule. This detailed schedule is required during the planning phase of a project even though a lot of unknowns are not clarified. Another concern is that this schedule is used as a performance yardstick with regard to cost, time and project team performance. The biggest concern is that “teams are denied the opportunity to use their own creativity to think of ways in which they could impact the higher-level strategic outcomes” (Levitt, 2011, p. 211). Svejvig and Andersen (2015) also agree that project management should undergo a reboot and identify six areas that are in dire need of this: learnability, multiplicity, temporarity, complexity, uncertainty and sociability. Rebooting project management includes rethinking known project management processes and sometimes introducing radical ideas. Some of these ideas include the decentralisation of decision-making and a participative leadership style. In a world of constant change, the scope of projects also cannot be pre-determined and should be flexible. The incorporation of young workers introduces conflict as they rebel against the traditional project management way of doing things. The aim of this article is to determine whether information technology (IT) project management, as part of the larger project management discipline, is in need of a reboot. This is based on historical and current evidence that IT projects are constantly failing and do not deliver value to the organisation. If a reboot is required, what elements or components should be replaced or upgraded? The first section of this paper highlights the current problem that organisations experience with IT projects, with the factors that facilitate IT project failure being identified in the second section. The third and fourth sections deal with what is currently not working within the IT discipline and what is contributing to IT project success. The research methodology is briefly explained in the fifth section, followed by the sixth section which presents a rebooted framework. The seventh section concludes the article, and some future research and ways to adopt the rebooted framework are suggested.

Prof C Marnewick - Inaugural Address Page 2 of 18

Literature Review

THE PROBLEM IT projects are the vehicles that organisational leaders use to implement the IT strategy. The IT strategy per se is derived from the organisational strategies. The logical conclusion is that when IT projects fail or are perceived as not delivering on all the benefits, then the IT strategy is not fully implemented. This then creates an imbalance where the IT strategy does not fully contribute to the organisational strategies. IT project success has been studied over the last couple of decades by academics and practitioners alike (Bannerman, 2008; Belassi & Tukel, 1996; Cooke-Davies, 2002; Hyväri, 2006; Ika, Diallo, & Thuillier, 2012; Pinto & Slevin, 1987; Serrador & Pinto, 2015). The reason for this almost frenetic research is that there is enough evidence indicating that IT projects are still failing at an alarming rate. This was the case two decades ago and it is still the case in the late 2010s. Research is done internationally by the Standish Group which produces the Chaos Chronicles, and in South Africa the research on IT project success rates is called the Prosperus reports (Labuschagne & Marnewick, 2009; Marnewick, 2013b; Sonnekus & Labuschagne, 2003). Figure 1 shows the results from the international research.

Figure 1. International IT project success rates (The Standish Group, 2013, 2014) The results indicate clearly that something is drastically wrong as the rate to successfully implement an IT project is on average 28%. This implies that 70% of IT projects do not add value or add only limited value to organisations. Of even greater concern is the fact that the success rates have stagnated at around 30% for the last decade, implying four things: 1. IT departments and professionals actually do not care about these results, 2. We do not understand the complexity of IT projects, 3. We are measuring the success of IT projects incorrectly or 4. The notion of combining project management and IT is not working and needs to be addressed. IT project success rates within South Africa do not look much better, as indicated in Figure 2.

Prof C Marnewick - Inaugural Address Page 3 of 18

Figure 2. South African IT project success rates (Labuschagne & Marnewick, 2009; Marnewick, 2013b) Although the South African success rates look better than the international ones, South African companies are in the same boat as international companies where on average close to 50% of IT projects are perceived as successful. When these results are translated into monetary value, then a gloomy picture is created as seen in table 1. The results indicate that $17 820 billion dollars are wasted on IT projects that do not deliver or that deliver little value to a company. Table 1. IT Waste – Worldwide (Lovelock, Hale, Hahn, Atwal, Graham, & Gupta, 2017)

Year Spending (Billions of Dollars) Waste (Billions of Dollars)

2014 3 564 2 566

2015 3 395 2 444

2016 3 375 2 430

2017 3 464 2 494

2018 3 553 2 558

2019 3 648 2 627

2020 3 752 2 701

Total 24 751 17 820

The South African perspective is just as bleak, as indicated in Table 2. On average, 57 cents are wasted for every one rand spent on IT. Table 2. IT Waste – South Africa (Lovelock et al., 2017)

Year Spending (Billions of Rands) Waste (Billions of Rands)

2015 56.9 30.2

2016 63 33.4

2017 65 34.5

2018 70 37.1

2019 75 39.8

2020 87.3 46.3

Total 417.2 221.1

The results depicted clearly indicate that companies need to address the success rates of IT projects as a matter of urgency. IT cannot continue to be seen as a black hole into which money disappears and little or no value is created for the company and all the relevant stakeholders.

Prof C Marnewick - Inaugural Address Page 4 of 18

The success rates of IT projects are not close to satisfactory and maybe it is time to really think about and investigate what the underlying issues and concerns are relating to IT projects. IT project management consists of two major components, i.e. information technology and project management. Each of these components in itself creates challenges and has either a positive or negative impact on the success rate of IT projects. Since the current philosophy and practice around IT projects contribute to a 28% success rate, the following questions need to be asked: 1. Are there any facilitating factors that contribute to the low success rate of IT projects? 2. What is currently working that organisations have managed to achieve a 28% success rate? 3. What should be changed or added to improve the current success rates to be more acceptable? The following section highlights some factors that contribute to IT projects being challenging and therefore less successful.

FACILITATING FACTORS IT changes the way we work and is also the catalyst for Industry 4.0 or the so-called 4

th Industrial

Revolution. table 3 shows the top technology trends over the last decade and it is interesting to note that these trends are fluctuating. Table 3. Top 10 strategic technology trends (Gartner, 2017)

# 2008 2012 2013 2015 2018

1 Social Software Media Tablets and Beyond

Mobile Device Battles

Computing Everywhere

AI Foundation

2 Metadata Management

1. Mobile-Centric Applications and Interfaces

1. Mobile Apps 1. Internet of Things Intelligent Apps and Analytics

3 Web Mashup, Cloud Computing and Composite Applications

2. Contextual and Social User Experience

2. Personal Cloud 2. 3D Printing Intelligent Things

4 Web Platform and Web-oriented Architecture (WOA)

3. Internet of Things 3. Enterprise App Stores

3. Advanced, Pervasive and Invisible Analytics

Digital Twin

5 Fabric Computing 4. App Stores and Marketplaces

4. Internet of Things 4. Context-Rich Systems

Cloud to the Edge

6 Real World Web 5. Next-Generation Analytics

5. Hybrid IT & Cloud Computing

5. Smart Machines Conversational Platforms

7 Business Process Modeling

6. Big Data 6. Strategic Big Data 6. Cloud/Client Computing

Immersive Experience

8 Green IT 7. In-Memory Computing

7. Actionable Analytics 7. Software-Defined Applications and Infrastructure

Blockchain

9 Unified Communications

8. Extreme Low-Energy Servers

8. In-Memory Computing

8. Web-Scale IT Event Driven

10 Virtualization Cloud Computing Integrated Ecosystems

Risk-Based Security and Self-Protection

Continuous Adaptive Risk and Trust

These new trends need to be incorporated into IT projects consistently. The challenge with incorporating these new trends is two-fold. Firstly, project teams do not necessarily have the knowledge to implement these trends and secondly, these trends contribute to the complexity of IT projects. A second facilitator is project complexity. Project complexity involves identifying and understanding the various intricacies embedded in a project. Baccarini (1996, p. 201) introduced project complexity within the context of construction projects and argued that project management is “associated with management of complexity”. The research of Baccarini (1996) subsequently resulted in the development of a conceptual model of project complexity. Similarly, Xia and Lee (2004) produced a conceptual model for IT project complexity. Similar literature works have developed models for project

Prof C Marnewick - Inaugural Address Page 5 of 18

complexity to enlighten how projects are understood and perceived. Joseph (2017) developed a comprehensive IT project complexity model consisting of five types of complexities and resulting in 75 individual elements. These 75 elements need to be incorporated into the life cycle of an IT project. The omission or underestimation of any element can cause the IT project to be less successful. The IT project complexity model is illustrated in figure 3.

INFORMATION

TECHNOLOGY PROJECT

COMPLEXITY

Organisational

complexity

Technical

complexity

Environmental

complexityUncertainty

Dynamics

Organisational

structure

Organisational units

Task structure

Project duration

Variety of methods and tools

Capital expenditure

Work hours

Project team

Site area

Number of locations

Project drive

Resource and skills availability

Experience with involved parties

HSSE awareness

Interfaces between different disciplines

Number of financial resources

Contract types

Number of different nationalities

Number of different languages

Joint-venture partners

Overlapping office hours

Trust in project team

Trust in contractor

Organisational risk

Environmental dependencies

Resource sharing

Schedule dependencies

Interconnectivity and feedback loop

Dependencies between actors

Objective dependencies

Process interdependencies

Stakeholder interrelations

Team cooperation & communication

Change

processNumber of goals

Goal alignment

Clarity of goals

Scale of scope

Quality requirements

Number of tasks

Variety of tasks

Conflicting norms and standards

Newness of technology

Experience with technology

Technical risks

Number of

changes

Scope of

changes

Frequency of

changes

Impact of

changes

Change over

time

Number of

stakeholders

Stakeholder’

perspectives

Political

influence

Internal

support

Required local

content

Existing site

interference

Weather

conditions

Remoteness of

location

Experience in

country

Strategic

pressure

Environmental

stability

Level of

competition

Environmental

risks

Uncertainties

in scope

Uncertainties

in cost

Uncertainties

in time

Uncertainty in

methods

Task

uncertainty

Objectives

uncertainty

Technological

maturity

Undisclosed

participantsCompetency

Incomplete

information Figure 3. IT project complexity elements (Joseph, 2017) The complexity type with the most elements is organisational complexity. IT projects are executed by organisations for organisations and these elements are all ‘soft’ elements that are not easy to address or resolve. Organisational complexity is a mixture of tangible and intangible elements. The environmental and technical elements are easier to address as they are more tangible. Uncertainty plays an important role in the complexity of IT projects as the end goal is not as clear as is the case with construction and engineering projects. From the onset of a construction project, such as the construction of a bridge, the end product is already conceptualised as everyone understands and knows what a bridge looks like. The same cannot be said of an IT project as no one within the project team understands what an enterprise resource planning (ERP) system looks like. The project team will have a vague idea but that is all. The changing nature of IT itself and the complexity surrounding IT projects can be perceived as facilitating factors that contribute to these projects failing. Organisations and IT project managers specifically need to be aware of these facilitating factors and consider them during the IT project’s life cycle. The following section covers existing literature to explain what contributes to IT project failure.

WHAT IS NOT WORKING There are various aspects that have a negative impact on the success of IT projects. This section highlights some aspects that need to be either improved upon or totally discarded. 1. The Waterfall method is a very sequential process. It produces some positive results, especially

when the product or service is less complex and straightforward. The majority of IT projects are

Prof C Marnewick - Inaugural Address Page 6 of 18

still being implemented using the Waterfall method. Academic textbooks that are prescribed to students also advocate this method. Figure 4 highlights the success rate when the Waterfall method is used. However, this method of implementing IT projects is not really working. The problem with this approach is that requirements are identified upfront without really knowing what the end-product or service will look like. This relates back to the uncertainty element of the complexity model.

Figure 4. IT project success rates – Agile versus Waterfall methods (Marnewick, Erasmus, & Joseph, 2017; The Standish Group, 2013, 2014)

2. Project management standards were originally developed to implement the organisational strategy (Bredillet, 2003) and to develop the competence of project managers (Crawford, 2005). Over the last decade, standards themselves, the way they are developed and their value have been questioned by practitioners and academics (Grau, 2013; Hällgren, Nilsson, Blomquist, & Söderholm, 2012; Morris, Crawford, Hodgson, Shepherd, & Thomas, 2006). Morris et al. (2006) raise two concerns regarding standards writing. The first is that the standards do not include any vision of the future. Standards are based on how things are currently done. Secondly, the practitioners involved in standards writing might have limited exposure or might even be junior practitioners. They will then not be able to add richness to the standard. In a study focusing on the adherence to project management standards, Marnewick (2017) indicates that IT project managers have a tendency to not adhere to project management standards. The adherence or adoption rates are worrisome. It was found that only three processes were done by more than 50% of IT project managers. The rest of the processes are either negated or not performed at all.

3. Given the fact that IT project managers do not adhere to standards and best practices, it is no

surprise that the maturity levels of organisational project management are not improving. Well-defined, repeatable and predictable project management processes contribute to the maturity of project management capability (Pennypacker & Grant, 2003). The obvious benefit is an improved project success rate for IT projects, but this alone should not be the only motivation to improve the maturity levels. Higher levels of project management maturity levels are associated with better cost and schedule performance (Kwak, 2000). This observation itself should encourage organisations to pursue higher levels of project management maturity. Figure 5 indicates the maturity level of nine knowledge areas within the PMBoK® Guide. The maturity levels are at level 3, implying that processes are standardised and integrated and that IT projects use these approved processes. This underlines the notion that organisations and IT project managers are only doing the bare basics. The concern is that the maturity levels have not improved since 2003 (Labuschagne & Marnewick, 2009; Marnewick, 2013b; Sonnekus & Labuschagne, 2003). The maturity levels are stagnating at level 3.

Prof C Marnewick - Inaugural Address Page 7 of 18

Figure 5. IT project management maturity levels (Marnewick, 2013a)1

Evrard and Nieto-Rodriquez (2004, p. 9) found in their study that “a higher project management maturity level will in most cases deliver superior performance in terms of overall project delivery and business benefits”. Improving project management maturity should therefore improve the success of IT projects. Table 4 provides a correlation between project management maturity and project success. Table 4. Correlation between project management maturity and project success (Marnewick, 2013a)

2003 2007 2011 2013

Pearson correlation 0.094** 0.08 0.211** 0.207**

Sig. (2-tailed) 0.008 0.28 0.00 0.001

**. Correlation is significant at the 0.01 level (2-tailed).

The results in Table 4 indicate that there is a weak relationship between project management maturity and project success. Although these relationships are weak, they are significant since the significance levels are below 0.5. The results do not provide a conclusive answer to whether there is a correlation between project success and the overall maturity levels of the organisation (Marnewick, 2013a).

4. Various project management institutes and associations have instituted certifications. The

purpose of these certifications is to improve the competence levels of project managers. Project managers are provided with the appropriate skills and knowledge required to deliver projects successfully. The assumption is that competent project managers are more likely to implement successful projects. Joseph and Marnewick (2018) have established that certifications do not contribute to project success. This research is in line with Hällgren et al. (2012), who argue that certified IT project managers are not automatically capable of managing a project successfully.

WHAT IS WORKING The previous section highlights aspects that are not conducive to IT project success. Having said that, certain IT projects or parts of IT projects are still successful, as illustrated in figure 1 and figure 2. This section highlights aspects that seem to contribute to IT project success. 1. A relatively new group of approaches, known as Agile approaches, are now considered. These

approaches were initially formulated to manage the development of software development

1 Note that the research focused on nine knowledge areas within the PMBoK® Guide. A tenth knowledge area

(Stakeholder Management) was derived from Project Communications Management and added from the 5th

edition of the PMBoK® Guide.

Prof C Marnewick - Inaugural Address Page 8 of 18

projects, but have been expanded due to their popularity and success in dealing with most types of IT projects. Iterative processes are more of a discovery-based approach. The iterative nature of the processes was the basis on which Agile methods were developed (Leffingwell, 2011). All the various Agile methods share the same underlying basis, which can be described by five elements (Leffingwell, 2011; Sommerville, 2007). The elements are summarised as follows: a. Collaboration: Customers are involved throughout the process. They continuously evaluate

the delivered software and provide feedback. b. Incremental delivery: The software is developed in increments. The customer specifies the

requirements that must be included in each increment. c. People, not process: Individuals are trusted to do their job in their own way without

prescriptive processes. d. Change: The software is changed as the customer dictates instead of following a formal plan. e. Simplicity: There is a focus on simplifying the development of the solution as well as the

process that is being followed.

IT projects using Agile as a method have increased success rates, as illustrated by Marnewick et al. (2017) and the various Chaos Chronicles (The Standish Group, 2013, 2014). As per figure 4, in the case of international IT projects, employing the Agile approach seems to be 300% more effective. The difference is not that extreme in the South African context but the results are also positive.

2. It was stated in the previous section that certification does not necessarily contribute to IT project

success. However, the competence of IT project managers is not necessarily dependent on certifications, but more so on experience and formal qualifications. In a 2016 study, Marnewick, Erasmus, and Joseph (2016) evaluated the competency levels of IT project managers. These levels were based on the Project Management Institute’s Project Manager Competency Development Framework. This framework measures competency levels within two domains. The first domain focuses on the performance competencies. “Performance competencies are what project managers are able to do or accomplish by applying their project management knowledge and skills” (Project Management Institute, 2017b, p. 11). The results in figure 6 highlight that IT project managers are quite competent with regard to performance competencies.

Figure 6. IT project manager performance competency levels (Marnewick et al., 2016)

Personal competencies, on the other hand, determine IT project managers’ “behaviours, attitudes, cultural influences and core personality characteristics that contribute to a person’s ability to

Prof C Marnewick - Inaugural Address Page 9 of 18

manage a project” (Project Management Institute, 2017b, p. 12). Figure 7 highlights IT project managers’ personal competency levels.

Figure 7. IT project manager personal competency levels (Marnewick et al., 2016)

Figure 8 highlights what is currently working and what is definitely not working. It is fairly obvious that the notion of project management as we know it is not working in the IT industry. This does not come as a surprise as project management originated from the engineering and construction industries. The principles of project management were applied as is without adjusting or changing these principles to suit IT implementations.

Figure 8. Weighing the options The research methodology adopted in this study is briefly explained in the next section.

Working Not Working

Prof C Marnewick - Inaugural Address Page 10 of 18

RESEARCH METHODOLOGY A comprehensive literature review was used to develop the concept of the rebooted framework. The results of this review were analysed, providing the foundation for the rebooted framework. According to Mayring (2014), deductive content analysis is a technique used when the concepts are derived based on a literature review. Inductive content analysis, on the other hand, is used when concepts are derived from data. For the purpose of this research, both deductive and inductive content analysis were used to identify the components of the conceptual framework. The categories generated from the content analysis are used as the main components of the conceptual framework. The following process was used: 1. The key concepts were identified. 2. The identified concepts were linked with the problem under investigation in order to validate the

reliability of the concepts. 3. The relationship between the identified concepts was determined. Concept mapping was used to

create relationships between the concepts. 4. The concepts identified from the content analysis were given new names and identified as the

components of the conceptual framework.

REBOOTED FRAMEWORK The previous sections highlighted what is currently working and what is not working in the IT project management discipline. This section highlights new trends as well as new ways of working that should be incorporated into a rebooted framework. The rebooted framework focuses on each of the components of IT project management, i.e. IT + project + management. INFORMATION TECHNOLOGY IT plays a huge role in business, ensuring that the vision and strategies are realised. IT also plays a huge role in the daily lives of normal citizens and this will become more ubiquitous with the Internet of Things and the influence of Industry 4.0. There are two aspects that need to be taken into consideration when an IT initiative is implemented, irrespective of the size of such an initiative. 1. IT initiatives can vary from very simple to extremely complex implementations. The project

manager should take cognisance of the complexity and determine the complexity factor upfront. The complexity factor can be used to determine how the project should be managed.

2. IT is constantly changing as seen in table 3. A potential IT solution might sound like a great idea at the beginning of a four-year endeavour, but might be totally disastrous by the end. IT practitioners must be living IT and understand how IT itself evolves and what the future lasting trends will be.

PROJECT The second component that needs to be rebooted is the notion of what constitutes a project within the IT space. Are IT initiatives projects, programmes or portfolios? The advent of Agile as an approach to implement an IT initiative has made the notion of a project irrelevant. Initiatives are implemented in sprints and teams are self-organising and manage themselves. This implies that project management is no longer required. Empirical data also highlights that the Agile approach is more successful than the Waterfall approach. 1. Organisations should realise that IT initiatives should be implemented using Agile. This is

irrespective of whether it is a hardware implementation or the customisation of software. The Project Management Institute advocates that the decision to choose Agile lies with the organisation (Project Management Institute, 2017a). In the case of IT, the choice is fairly simple as Agile originated from IT. Adopting Agile as an approach negates the notion of a project.

2. One of Agile’s drawbacks is that it was developed for small implementations and not necessarily for the implementation of large ERP solutions. This has led to the introduction of Scaled Agile. Scaled Agile is implemented using programme and portfolio management and does not refer to projects or project management per se. In an Agile environment, a portfolio is a collection of programmes and sprints managed cohesively to achieve strategic objectives (Project Management Institute, 2017c; Scaled Agile Inc., 2018). The focus of a portfolio in Scaled Agile is

Prof C Marnewick - Inaugural Address Page 11 of 18

the flow of value through one or more value streams. The adoption of Scaled Agile depends on people, processes and technology (Gill, 2015). Dikert, Paasivaara, and Lassenius (2016) are of the opinion that for Scaled Agile to succeed, the following needs to be addressed: (i) management support, (ii) choosing and customising the Agile model, (iii) training and coaching, (iv) mindset and (v) alignment. The benefits of Scaled Agile are:

10 – 50% happier, more motivated employees

30 – 75% faster time-to-market

20 – 50% increase in productivity

25 – 75% defect reduction The conclusion is straightforward. The second component that needs to be upgraded after a reboot is the term project. This term is not conducive in the new ways of working and should be replaced by the concept of a portfolio. IT initiatives are implemented through sprints and should be managed as portfolios that deliver value to the organisation at large. The Standard for Portfolio Management (Project Management Institute, 2017c) highlights six knowledge areas that can be used to manage a portfolio optimally. These knowledge areas are:

Portfolio strategic management: IT initiatives are identified at an executive level and the management of these initiatives optimally forms the very fabric of portfolio strategic management.

Portfolio governance: This knowledge area guides the decision-making processes within the portfolio but also within sprints.

Portfolio capacity and capability management: Organisations have limited resource capacities and capabilities. This knowledge area ensures that the various portfolio initiatives are implemented within the resources capacity and capability constraints.

Portfolio stakeholder management: IT initiatives involve various stakeholders. All stakeholders should be identified and their concerns and requirements should be addressed, ensuring the realisation of the strategies.

Portfolio value management: Value streams are the organisational steps IT initiatives should follow to provide a continuous flow of customer value. Organising around value offers substantial benefits to the organisation, including faster learning, shorter time-to-market, higher quality, higher productivity and leaner budgeting mechanisms. It results in value streams that are a better fit for the intended purpose.

Portfolio risk management: Risks associated with IT initiatives should be evaluated, ensuring the best possible success according to the organisation’s strategies.

Managing a Scale Agile portfolio based on these knowledge areas should improve the value that organisations get from their IT initiatives. MANAGEMENT The third component addresses the notion of management but management from a portfolio perspective. Various aspects need to be incorporated as the world is changing. Various demands are placed on organisations regarding the way that they engage with their people but also regarding the way that they engage with the environment. SUSTAINABILITY The first component that should be part of the rebooted framework is sustainability. Silvius (2017, p. 1479) suggests that “sustainability should be considered a new and emerging school of project management”. Sustainability consists of three dimensions, i.e. economic, social and environmental. These dimensions are also sometimes called people, planet and profit. In a South African study, Clinning and Marnewick (2017) measured the extent to which sustainability was incorporated into IT projects. Needless to say, the economic dimension was the dimension that was the best incorporated or addressed, as shown in figure 9. The other two dimensions were addressed but not to the extent that one would hope.

Prof C Marnewick - Inaugural Address Page 12 of 18

Figure 9. Sustainability dimension averages (Clinning & Marnewick, 2017)

Figure 10 provides a more in-depth breakdown of the results. The so-called Sustainability Project Management Maturity Model (SPM3) was developed to assess the integration of sustainability into a project based on four maturity levels (Silvius & Schipper, 2015). In the Clinning and Marnewick (2017) study, 938 projects were assessed and the mean score as well as the coefficient of variation were used. The mean was used to assess the position of each aspect and the spread about the mean was used to determine the variability between projects. The mean for each aspect is indicated in figure 10 as the black line separating the upper and lower bound coefficient of variation (shaded area). The model clearly indicates the poor extent to which sustainability is incorporated into IT initiatives, with the majority of aspects only being addressed at the first level.

Figure 10. SPM3 model with South African IT project data (Clinning & Marnewick, 2017) Incorporating sustainability into the IT portfolio is no longer a luxury, but an imperative. IT portfolio managers cannot continue to ignore this aspect and should be skilled and trained in sustainability and how to incorporate it into IT initiatives. COMPETENCIES

Prof C Marnewick - Inaugural Address Page 13 of 18

The competencies of IT project managers are still extremely important. The competencies as per PMI’s Project Manager Competency Development Framework are still valid and as the results indicate, IT project managers are quite competent in this regard. Competencies that need to be addressed in the rebooted environment are Agile and Scaled Agile competencies as well as portfolio management competencies. Portfolio management competencies focus on three levels (International Project Management Association, 2015): 1. People competencies: These consist of the personal and interpersonal competences required to

participate in or lead a portfolio successfully. 2. Practice competencies: These are the specific methods, tools and techniques used in portfolios

to realise their success. 3. Perspective competencies: Under this heading come the methods, tools and techniques

through which individuals interact with the environment, as well as the rationale that leads people, organisations and societies to start and support portfolios.

IT portfolio managers should also be competent in IT and the new trends as well as Industry 4.0. INDUSTRY 4.0 SKILLS Industry 4.0 is placing huge demands on IT as an enabler. The underlying backbone of Industry 4.0 is IT and how IT connects machine to machine and machine to human. One of the demands is that IT initiatives should be delivered as quickly as possible with an emphasis on quality systems. The quick delivery of new and altered IT systems and/or solutions requires agility and adaptability. This is not possible with the traditional Waterfall approach and the Agile approach is, for the time being, more than appropriate. Current skills and competencies are also not enough. The underlying competencies as highlighted by the Project Manager Competency Development Framework (Project Management Institute, 2017b) and the Individual Competence Baseline for Project, Programme & Portfolio Management (International Project Management Association, 2015) are still relevant, but the focus should be on new skills that are required for Industry 4.0. These future skills are summarised in Table 5. Table 5. Skills required for Industry 4.0

# Skills Reference

1 Sense-making (Davies, Fidler, & Gorbis, 2011)

2 Social intelligence (Davies et al., 2011; Liu & Grusky, 2013)

3 Novel and adaptive thinking (Benešová & Tupa, 2017; Davies et al., 2011)

4 Cross-cultural competency (Benešová & Tupa, 2017; The Economist Intelligence Unit, 2015)

5 Computational thinking (Davies et al., 2011; Pinzone, Fantini, Perini, Garavaglia, Taisch, & Miragliotta, 2017; The Economist Intelligence Unit, 2015)

6 New-media/digital literacy (Davies et al., 2011; The Economist Intelligence Unit, 2015)

7 Transdisciplinary (Davies et al., 2011)

8 Design mindset/creativity (Davies et al., 2011; Liu & Grusky, 2013; The Economist Intelligence Unit, 2015)

9 Cognitive load management (Davies et al., 2011)

10 Virtual collaboration (Davies et al., 2011)

11 Problem solving (Benešová & Tupa, 2017; The Economist Intelligence Unit, 2015)

12 Team working (Benešová & Tupa, 2017; The Economist Intelligence Unit, 2015)

13 Communication (Benešová & Tupa, 2017; The Economist Intelligence Unit, 2015)

14 Critical thinking (Benešová & Tupa, 2017; The Economist Intelligence Unit, 2015)

16 Leadership (Benešová & Tupa, 2017; The Economist Intelligence Unit, 2015)

17 Literacy (The Economist Intelligence Unit, 2015)

18 Emotional intelligence (David, 2017; The Economist Intelligence Unit, 2015)

20 Entrepreneurship (The Economist Intelligence Unit, 2015)

These skills go beyond the traditional portfolio management skills and competencies. Both team members and project managers are required to master these new skills. TEAM Apart from these so-called Industry 4.0 skills, team members should also be specialists in their respective disciplines. This specialisation leads to the formation of guilds which reflect the original

Prof C Marnewick - Inaugural Address Page 14 of 18

guilds formed by various artisans (Frey & Osborne, 2017; James & Charles, 2003). Team members will belong to guilds for training, development and innovation (PWC, 2017), thus introducing a culture of continuous learning. The team members will have high levels of knowledge and experience and will be intrinsically motivated (Levitt, 2011). Team members perform their activities with the minimum supervision or oversight, making the role of the project manager obsolete. Team members are motivated by their level of status and respect in their respective guilds rather than by their salary, formal title or position in the hierarchy (Levitt, 2011). Working in this kind of environment, with very few rules or procedures about how to do things, requires workers to have a high tolerance for ambiguity. There is no right way to do things except the way that they choose to do them (Levitt, 2011). There is also a tendency that team members will become free agents and will not be a permanent member of the project team. Engaging with these free agents creates challenges for the scrum master, portfolio manager and the other team members. Portfolio managers will have to overcome challenges relating to performance and the delivery of artefacts within the predefined constraints, e.g. time and quality. The challenge for team members will revolve largely around trust. Trust is built when team members engage and interact with each other and this becomes difficult when certain team members are not really permanent team members. FINAL FRAMEWORK Figure 11 provides an overview of the rebooted IT Portfolio Management Framework.

Guilds

INFORMATION TECHNOLOGY PORTFOLIO MANAGEMENT

Complexity

Trends

AgileScaled Agile

Competencies

Industry 4.0 Skills

Team

Free Agents

Sustainability

Figure 11. Rebooted IT Portfolio Management Framework A reboot of a computer does not imply that everything is replaced. That is the purpose of a re-install. During a reboot, the majority of the system is kept intact and only the pieces that are not functioning are removed and improvements are installed. The same principle applies when rebooting IT project management. The IT component of the equation need not be changed. However, organisations, scrum masters and portfolio managers must take cognisance of the two facilitating factors. Complexity is part and parcel of any IT initiative and the trends originating within IT contribute to the failure rate of IT initiatives. Embracing these two facilitating factors implies an awareness of where any concerns can be addressed before having a negative impact on the initiative itself. The most drastic change after the reboot is the upgrade of project management to portfolio management. In the new way of working where all IT initiatives are managed in the Agile way, the emphasis is more on portfolio management, ensuring the strategic success of the organisation at large. Embracing the Agile way also has an impact on the way initiatives are managed. Teams are self-reliant and are only dependent on the portfolio manager for strategic direction and the creation of a backlog.

Prof C Marnewick - Inaugural Address Page 15 of 18

Portfolio management implies the management of not just the portfolio, but also of the environment and the people. Four elements need to be incorporated as per the discussion and figure 11. The biggest challenge is to incorporate Industry 4.0 skills into the current skill set and to manage teams accordingly. Teams are more autonomous, self-forming and highly flexible based on the team members, who will be predominately from Generation Z and iGen. In conclusion, the majority of the principles stay in place, i.e. IT and the management part of the equation. The most drastic change is the way that IT initiatives are perceived. IT initiatives can no longer be managed like projects as the notion of projects is fast disappearing. IT initiatives should rather be managed as portfolios that deliver continuous value to the organisation. The biggest challenge is to embrace the Agile approach and the Scaled Agile Framework. Marnewick and Langerman (2018) provide ten enablers. These enablers range from the ability to change the organisational culture to the reduction of management concerns about the loss of control and the lack of upfront planning.

CONCLUSIONS This paper philosophises about the notion that managing IT initiatives as projects per se is no longer relevant and contributes to the low success rates of IT projects. There is overwhelming evidence that IT initiatives managed as projects are not successful and do not deliver the value as intended. This warrants an investigation of how IT initiatives should be managed. There are certain aspects that are definitely not conducive to the management of IT initiatives as projects. The Waterfall approach is definitely not working as there have been no improvements in the success rates for more than two decades. Project management as a discipline is also not working as evidence indicates that practitioners do not really follow the best practices described in the project management standards. The race for a wall full of certifications also seems to be a futile exercise as project management certifications do not necessarily have a positive impact on project success. Research has indicated that the Agile approach has a positive impact on project success. Adopting Agile as an approach does have its challenges, which should be addressed by the organisation at large. Competent project managers also have a positive impact on success rates. Managing IT initiatives using the Agile approach implies by default that Scaled Agile should be adopted as a framework. This in turn then implies that the notion of project management disappears as sprints and programme increments are used to implement these initiatives. Portfolio management should play a more important role in managing IT initiatives, ensuring strategic alignment and value delivery to the organisation. A new approach is needed to manage IT initiatives as project management per se does not meet the changing needs of IT in general and IT initiatives specifically. The research results presented in this article as well as the monologue underline that a new way of working is needed. The two major recommendations are the replacement of the Waterfall approach with an Agile approach and the replacement of project management with portfolio management. There are still various unknowns that need to be addressed. The very first challenge is what will happen to current IT project managers. What will their future role be? Do they need to upskill into portfolio management or cross-skill to become release train engineers or even scrum masters? Another challenge is more of an organisational challenge and it relates to the culture of the organisation. Organisations should embrace the Agile approach as well as Scaled Agile as a way to deliver IT initiatives. There is also a challenge for higher education institutions (HEIs). The curriculum should be adjusted to teach the Agile approach in software engineering courses. Project management courses should also address Agile as an approach to deliver IT initiatives, but also focus on Scaled Agile as a holistic framework to deliver value to the organisation. A major challenge is to prepare students for the new way of working that Industry 4.0 requires. Students cannot graduate with a 3

rd Industrial Revolution

mentality and skill set. They will have to be Industry 4.0 ready, which then also challenges the academia at HEIs to be relevant in their teaching and research.

Prof C Marnewick - Inaugural Address Page 16 of 18

References

Baccarini, D. (1996). The concept of project complexity—a review. International Journal of Project Management, 14(4), 201-204. doi:http://dx.doi.org/10.1016/0263-7863(95)00093-3

Bannerman, P. L. (2008). Defining project success: a multilevel framework. Paper presented at the PMI Research Conference: Defining the future of project management, Warsaw, Poland.

Belassi, W., & Tukel, O. I. (1996). A new framework for determining critical success/failure factors in projects. International Journal of Project Management, 14(3), 141-151. doi:http://dx.doi.org/10.1016/0263-7863(95)00064-X

Benešová, A., & Tupa, J. (2017). Requirements for Education and Qualification of People in Industry 4.0. Procedia Manufacturing, 11, 2195-2202. doi:https://doi.org/10.1016/j.promfg.2017.07.366

Bredillet, C. N. (2003). Genesis and role of standards: theoretical foundations and socio-economical model for the construction and use of standards. International Journal of Project Management, 21(6), 463:470.

Clinning, G., & Marnewick, C. (2017). Incorporating sustainability into IT project management in South Africa. South African Computer Journal, 29(1), 1-26. doi:https://doi.org/10.18489/sacj.v29i1.398

Cooke-Davies, T. (2002). The “real” success factors on projects. International Journal of Project Management, 20(3), 185-190. doi:http://dx.doi.org/10.1016/S0263-7863(01)00067-9

Crawford, L. H. (2005). Senior management perceptions of project management competence. International Journal of Project Management, 23(1), 7:16.

David, B. (2017). Computer technology and probable job destructions in Japan: An evaluation. Journal of the Japanese and International Economies, 43, 77-87. doi:https://doi.org/10.1016/j.jjie.2017.01.001

Davies, A., Fidler, D., & Gorbis, M. (2011). Future Work Skills 2020. Retrieved from Palo Alto, California: http://www.iftf.org/uploads/media/SR-1382A_UPRI_future_work_skills_sm.pdf

Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87-108. doi:https://doi.org/10.1016/j.jss.2016.06.013

Evrard, D., & Nieto-Rodriquez, A. (2004). Boosting Business Performance through Programme and Project Management. Retrieved from http://www.pwc.com/us/en/operations-management/assets/pwc-global-project-management-survey-first-survey-2004.pdf

Frey, C. B., & Osborne, M. A. (2017). The future of employment: How susceptible are jobs to computerisation? Technological Forecasting and Social Change, 114, 254-280. doi:https://doi.org/10.1016/j.techfore.2016.08.019

Gartner. (2017). Gartner Identifies the Top 10 Strategic Technology Trends for 2018. Retrieved from https://www.gartner.com/newsroom/id/3812063

Gill, A. Q. (2015, Sept. 28 2015-Oct. 1 2015). Learning Enterprise Agile Software Engineering: Scaling Agility at the Enterprise Level. Paper presented at the 2015 24th Australasian Software Engineering Conference.

Grau, N. (2013). Standards and Excellence in Project Management – In Who Do We Trust? Procedia - Social and Behavioral Sciences, 74, 10-20. doi:10.1016/j.sbspro.2013.03.005

Hällgren, M., Nilsson, A., Blomquist, T., & Söderholm, A. (2012). Relevance Lost! A Critical Review of Project Management Standardisation. International Journal of Managing Projects in Business, 5(3), 457-485.

Hyväri, I. (2006). Success of projects in different organizational conditions. Project Management Journal, 37(4), 31-41.

Ika, L. A., Diallo, A., & Thuillier, D. (2012). Critical success factors for World Bank projects: An empirical investigation. International Journal of Project Management, 30(1), 105-116. doi:10.1016/j.ijproman.2011.03.005

International Project Management Association. (2015). Individual competence baseline for project, programme & portfolio management (pp. 416). Zurich, Switserland: International Project Management Association.

James, W., & Charles, G. (2003). The future of work: Changing patterns of workforce management and their impact on the workplace. Journal of Facilities Management, 2(2), 142-159. doi:doi:10.1108/14725960410808177

Joseph, N. (2017). Conceptualising a multidimensional model of information communication and technology project complexity. South African Journal of Information Management, 19(1). doi:10.4102/sajim.v19i1.825

Prof C Marnewick - Inaugural Address Page 17 of 18

Joseph, N., & Marnewick, C. (2018). Investing in project management certification: Do organisations get their money’s worth? Information Technology and Management, 19(1), 51-74. doi:10.1007/s10799-017-0275-y

Kwak, Y. H. (2000). Calculating Project Management's Return on Investment. Project Management Journal, 31(2), 38.

Labuschagne, L., & Marnewick, C. (2009). The Prosperus Report 2008: IT Project Management Maturity vs. Project Success in South Africa. Johannesburg: Project Management South Africa.

Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston: Addison-Wesley.

Levitt, R. E. (2011). Towards project management 2.0. Engineering Project Organization Journal, 1(3), 197-210. doi:10.1080/21573727.2011.609558

Liu, Y., & Grusky, D. B. (2013). The Payoff to Skill in the Third Industrial Revolution. American Journal of Sociology, 118(5), 1330-1374. doi:10.1086/669498

Lovelock, J.-D., Hale, K., Hahn, W. L., Atwal, R., Graham, C., & Gupta, N. (2017). Forecast Alert: IT Spending, Worldwide, 4Q16 Update. Retrieved from Stamford: USA: https://www.gartner.com/doc/3567217/forecast-alert-it-spending-worldwide

Marnewick, C. (2013a). To mature or not to mature - the Information Systems conundrum. South African Computer Journal, 51, 10-21.

Marnewick, C. (2017). The reality of adherence to best practices for information system initiatives. International Journal of Managing Projects in Business, 10(1), 167-184. doi:doi:10.1108/IJMPB-05-2016-0045

Marnewick, C. (Ed.) (2013b). Prosperus Report - The African Edition. Johannesburg: Project Management South Africa.

Marnewick, C., Erasmus, W., & Joseph, N. (2016). Information technology project managers’ competencies: An analysis of performance and personal competencies. Cape Town: AOSIS.

Marnewick, C., Erasmus, W., & Joseph, N. (2017). The symbiosis between information system project complexity and information system project success. Cape Town, South Africa: AOSIS (Pty) Ltd.

Marnewick, C., & Langerman, J. (2018). Agile Maturity: The First Step to Information Technology Project Success. In G. Silvius & G. Karayaz (Eds.), Developing Organizational Maturity for Effective Project Management (pp. 233-252). Hershey, PA, USA: IGI Global.

Mayring, P. (2014). Qualitative content analysis: theoretical foundation, basic procedures and software solution. Klagenfurt, Austria: Social Science Open Access Repository (SSOAR).

Morris, P. W. G., Crawford, L., Hodgson, D., Shepherd, M. M., & Thomas, J. (2006). Exploring the role of formal bodies of knowledge in defining a profession – The case of project management. International Journal of Project Management, 24(8), 635:734.

Pennypacker, J. S., & Grant, K. P. (2003). Project Management Maturity: an industry benchmark. Project Management Journal, 34(1), 4-11.

Pinto, J. K., & Slevin, D. P. (1987). Critical factors in successful project implementation. IEEE Transactions on Engineering Management, EM-34(1), 22-27. doi:10.1109/TEM.1987.6498856

Pinzone, M., Fantini, P., Perini, S., Garavaglia, S., Taisch, M., & Miragliotta, G. (2017). Jobs and Skills in Industry 4.0: An Exploratory Research, Cham.

Project Management Institute. (2017a). Agile Practice Guide (pp. 183). Newtown, PA, USA: Project Management Institute.

Project Management Institute. (2017b). Project Manager Competency Development Framework (3 ed.). Newtown, Pennsylvania: USA: Project Management Institute.

Project Management Institute. (2017c). The Standard for Portfolio Management (4 ed.). Newtown Square, Pennsylvania: Project Management Institute.

PWC. (2017). The future of work: A journey to 2022. Retrieved from https://www.pwc.co.uk/assets/pdf/future-of-work-report.pdf

Scaled Agile Inc. (2018). SAFe®. Retrieved from https://www.scaledagileframework.com/ Serrador, P., & Pinto, J. K. (2015). Does Agile work? — A quantitative analysis of agile project

success. International Journal of Project Management, 33(5), 1040-1051. doi:http://dx.doi.org/10.1016/j.ijproman.2015.01.006

Shelly, G. B., & Vermaat, M. E. (2008). Discovering computers 2009 complete. Boston, MA: Cengage Learning.

Silvius, A. J. G., & Schipper, R. (2015). Developing a Maturity Model for Assessing Sustainable Project Management. The Journal of Modern Project Management, 3(1), 17-27.

Prof C Marnewick - Inaugural Address Page 18 of 18

Silvius, G. (2017). Sustainability as a new school of thought in project management. Journal of Cleaner Production, 166, 1479-1493. doi:https://doi.org/10.1016/j.jclepro.2017.08.121

Sommerville, I. (2007). Software engineering: Addison-Wesley. Sonnekus, R., & Labuschagne, L. (2003). The Prosperus Report 2003. Johannesburg: RAU Standard

Bank Academy for Information Technology. Svejvig, P., & Andersen, P. (2015). Rethinking project management: A structured literature review

with a critical look at the brave new world. International Journal of Project Management, 33(2), 278-290. doi:http://dx.doi.org/10.1016/j.ijproman.2014.06.004

The Economist Intelligence Unit. (2015). Driving the skills agenda: Preparing students for the future. Retrieved from https://static.googleusercontent.com/media/edu.google.com/en//pdfs/skills-of-the-future-report.pdf

The Standish Group. (2013). Chaos Manifesto 2013. Retrieved from http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf

The Standish Group. (2014). Chaos Manifesto 2014: The Standish Group International. Xia, W., & Lee, G. (2004). Grasping the complexity of IS development projects. Communications of

the ACM, 47(5), 68-74. doi:10.1145/986213.986215