COPYRIGHT AND CITATION CONSIDERATIONS FOR THIS THESIS/ DISSERTATION

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://ujdigispace.uj.ac.za (Accessed: Date).

Enhancing the throughput of development projects using a model that improves the process of release management

by

Natasha Nicolette Vitó Ferreira

200508700

Dissertation submitted in fulfillment of the requirements for the degree

Magister Scientiae in the subject of in the Faculty of Science at the University of Johannesburg

SUPERVISOR: PROF J.J. LANGERMAN October 2013

Dedicated to

My parents: My mom, Nanda, you have always been the shining star in my life; I completed this for you in an attempt to add half the sparkle to your life that you have added to mine. Thank you for your infinite motivation. My dad, Julio, for always portraying a character of strength; the pride you possess has helped me complete this.

My special sisters: Melanie - as my older sister, you have always had so much faith in me and were always proud of my achievements; thank you for always being there for me when I needed some light in the dark. Carina - my twin, I am truly grateful for the words of encouragement you’ve always shared with me; thank you for cheering me on till the end.

For the rest of the people, friends and family with whom I have been blessed in my life, thank you for being my anchor when the waters were too rough. I thank you for your support and understanding through this venture of mine.

‘Thank you for filling my bucket so high of self-esteem that the rest of the world can’t poke enough holes to drain it dry.’

ACKNOWLEDGEMENTS

Firstly, to my supervisor, Prof. Josef J. Langerman, you have always been the person I have looked up to. Thank you for your patience and motivation throughout this exciting journey in my life. You’ve made me believe that ‘only as high as I reach, can I grow; only as far as I seek, can I go; only as deep as I look, can I see and only as much as I dream, can I be’.

To my family and friends who have shown me immeasurable support and have had so much faith in me during the completion of this chapter in my life. You’ve made the journey worthwhile and assisted me in adding plenty of colour to the pages of my life. ‘When my life flashes before my eyes, at least I know I will have plenty to watch.’

I am honoured to acknowledge the generous financial support from the University of Johannesburg and Standard Bank of South Africa. None of this would have been possible without the support of the Standard Bank Transactional and Product Services (TPS) department in the Corporate and Investment Banking (CIB) division of the bank who assisted me and was always willing to provide me with information.

ABSTRACT

The process that involves creating and altering software systems can be defined as the lifecycle. People often use methodologies and methods in order to develop these systems with success factors such as people, processes and technology. The lifecycle is comprised of the following stages: • Planning • Requirements definition • • Development • Integration and testing • Installation • Acceptance.

The underlying issue in such a lifecycle is that project defects are identified late within the lifecycle and therefore, the process of rectifying these problems becomes costly. Ultimately, an ideal product is one with minimal or zero defects which can be achieved with a software project that prevents or detects defects earlier within the cycle.

Release management can be described as the process involving decision-making regarding the implementation and releasing of a software product. A conceptual framework exists which stipulates the stages involved in the development process of a software application. Several models exist that describe the SDLC in different approaches.

A philosophy is adopted within the RAD model, known as Agile and is beneficial since it minimises future scope creep and scope changes. Development occurs in shorter intervals. Over and above the stages and values in this methodology, the Agile methodology includes incremental changes which are then captured in the scheduled software releases.

The purpose of the research presented in this dissertation is to incorporate findings where large companies with global IT projects can adopt the Agile conceptual framework and to testify whether all types of IT projects will benefit from a frequent release approach to the delivery of the project.

Three different projects across a large South African financial institution that specialises in corporate organisation banking and core-banking functionality will be studied and presented as case studies. Release management will also be studied from an organisational perspective with the following banking institution in context. Data will be retrieved by carrying out interviews and surveys with appropriate stakeholders, and therefore, analysed to generate a valid conclusion.

Key words: Software development lifecycle, release management, frequent releases.

Table of Contents 1. INTRODUCTION ...... 1 1.1 BACKGROUND INFORMATION ...... 1 1.2 PURPOSE AND IMPORTANCE OF STUDY ...... 3 1.2.1 PROBLEM STATEMENT ...... 4 1.2.1.1 RELEASE MANAGEMENT ...... 6 1.3 RESEARCH QUESTIONS ...... 8 1.3.1 QUESTION ONE ...... 8 1.3.2 QUESTION TWO ...... 9 1.3.3 QUESTION THREE ...... 9 1.4 DISSERTATION STRUCTURE ...... 10 2. RESEARCH METHOD ...... 13 2.1 INTRODUCTION ...... 13 2.2 RESEARCH QUESTIONS ...... 15 2.2.1 QUESTION ONE ...... 16 2.2.2 QUESTION TWO ...... 16 2.2.3 QUESTION THREE ...... 17 2.3 RESEARCH APPROACH ...... 17 2.3.1 QUALITATIVE VS. QUANTITATIVE RESEARCH ...... 17 2.3.2 SELECTED RESEARCH APPROACH ...... 20 2.4 RESEARCH METHODOLOGY ...... 21 2.4.1 OVERVIEW OF POSSIBLE RESEARCH METHODOLOGIES ...... 21 2.4.1.1 PARTICIPANT OBSERVATION ...... 21 2.4.1.2 EVALUATIVE RESEARCH ...... 21 2.4.1.3 COMPARATIVE ANALYSIS ...... 22 2.4.1.4 EXPERIMENTS ...... 22 2.4.1.5 CASE STUDIES ...... 22 2.4.1.6 INTERVIEWS ...... 23 2.4.1.7 SURVEYS ...... 24 2.4.2 SELECTION OF THE APPROPRIATE RESEARCH METHODOLOGY ...... 24 2.4.2.1 CASE STUDIES ...... 24 2.4.2.1(A) CASE STUDY PROTOCOL ...... 25 2.4.2.1(B) COLLECTION OF DATA ...... 25 2.4.2.1(C) CASE SELECTION ...... 25 2.4.2.2 LITERATURE SURVEY ...... 25 2.4.3 RESEARCH DATA COLLECTION PROCESS ...... 27 2.4.4 RESEARCH INSTRUMENTS ...... 27 2.4.4.1 CASE STUDIES ...... 28 2.4.4.2 INTERVIEWS AND SURVEYS ...... 32 2.5 ETHICAL CONSIDERATION ...... 33 2.6 RESEARCH DATA ANALYSIS ...... 33 2.7 RESEARCH VALUE ...... 35 2.8 PROPOSED RESEARCH APPROACH ...... 35 2.9 CONCLUSION ...... 36 3. LITERATURE REVIEW ...... 38 3.1 ...... 38 3.1.1 IT PROJECT LIFECYCLE ...... 42 3.2 RELEASE MANAGEMENT ...... 43 3.2.1 RELEASE MANAGEMENT METHODOLOGIES ...... 44 3.2.1.1 AGILE PRINCIPLES ...... 50

3.2.1.2 LEAN METHODOLOGIES ...... 57 3.2.1.3 DEVOPS ...... 57 3.2.1.3(A) VARIATIONS BETWEEN DEVOPS AND OTHER METHODOLOGIES ...... 58 3.2.1.3(AA) DEVOPS VS. AGILE ...... 59 3.2.1.3(BB) DEVOPS VS. ITIL ...... 59 3.2.1.3(B) DEVOPS PRINCIPLES AND PATTERNS ...... 60 3.2.2 DIFFICULTIES WITH RELEASE PLANNING ...... 61 3.2.2.1 ITIL FRAMEWORK ...... 62 3.2.2.2 ISSUES IN IT ENVIRONMENTS ...... 63 3.2.2.3 SERVICE MANAGEMENT ...... 63 3.2.2.4 ITIL FRAMEWORK BENEFITS ...... 66 3.2.2.5 SERVICE TRANSITION STAGE ...... 67 3.2.2.5(A) RELEASE AND DEPLOYMENT MANAGEMENT ...... 68 3.2.2.6 CHALLENGES OF IMPLEMENTING ITIL ...... 71 3.2.2.7 RISKS OF IMPLEMENTING ITIL ...... 72 3.2.2.8 PREFERRED ORGANISATIONAL STRUCTURE IN AN ITIL ENVIRONMENT ...... 73 3.2.2.9 PRODUCTION/OPERATIONS MANAGEMENT ...... 75 3.2.2.10 PRODUCTION MANAGEMENT ...... 75 3.2.2.11 OPERATIONS MANAGEMENT ...... 77 3.3 CONCLUSION ...... 78 4. THROUGHPUT ...... 79 4.1 WHY IS THROUGHPUT IMPORTANT? ...... 79 4.2 REASON FOR MEASURING THROUGHPUT – LEAN THINKING ...... 80 4.3 THEORY OF CONSTRAINTS AND THROUGHPUT ...... 83 4.4 PRINCIPLES OF THE THEORY OF CONSTRAINTS ...... 84 4.5 THROUGHPUT MEASUREMENT ...... 86 4.5.1 USE CASE POINTS (UCP) ...... 86 4.5.2 FUNCTION POINTS ...... 88 4.5.3 SOURCE LINES OF CODE (SLOC) ...... 89 4.5.4 FACTORY POINTS ...... 89 4.5.4.1 THE ESTIMATION MODEL ...... 90 4.6 IMPROVING THROUGHPUT ...... 92 4.6.1 SIX SIGMA ...... 93 4.6.2 CRITICAL CHAIN APPROACH ...... 94 4.7 CONCLUSION ...... 96 5. DISSERTATION LAYOUT ...... 98 5.1 INTRODUCTION ...... 98 5.2 OUTLINING SIGNIFICANT CONCEPTS ...... 98 5.2.1 SYSTEMS DEVELOPMENT LIFECYCLE (SDLC) ...... 98 5.2.2 RELEASE MANAGEMENT ...... 99 5.3 CASE STUDIES ...... 100 5.3.1 CASE STUDY 1 – SMALL PROJECT ...... 100 5.3.1.1 INTERVIEWEES ...... 100 5.3.2 CASE STUDY 2 – MEDIUM TO LARGE PROJECT ...... 101 5.3.2.1 INTERVIEWEES ...... 101 5.3.3 CASE STUDY 3 – LARGER THAN LARGE PROJECT ...... 102 5.3.3.1 INTERVIEWEES ...... 102 5.3.4 CASE STUDY 4 – ORGANISATIONAL RELEASE MANAGEMENT ...... 102 5.3.4.1 INTERVIEWEES ...... 103 5.4 RESEARCH QUESTIONS ...... 103 5.5 STRUCTURAL VIEW ...... 104

5.6 CONCLUSION ...... 104 6. CASE STUDY NUMBER 1 – SMALL PROJECT ...... 106 6.1 PROJECT OVERVIEW ...... 106 6.1.1 PROJECT SIZE ...... 107 6.1.2 PROJECT BUDGET ...... 108 6.1.3 PROJECT BUSINESS CASE ...... 108 6.2 SYSTEMS LANDSCAPE ...... 110 6.3 PROJECT ORGANISATIONAL STRUCTURE ...... 111 6.4 METHODOLOGY ...... 112 6.4.1 SUCCESS AND FAILURES ...... 112 6.5 CASE STUDY FEEDBACK ...... 113 6.5.1 RELEASE FREQUENCY ...... 113 6.5.2 PROJECT DELIVERY RISKS ...... 114 6.5.3 THROUGHPUT ...... 114 6.5.4 OPTIMUM RELEASE STRATEGY ...... 117 6.6 CONCLUSION ...... 118 7. CASE STUDY NUMBER 2 – MEDIUM TO LARGE PROJECT ...... 120 7.1 PROJECT OVERVIEW ...... 120 7.1.1 PROJECT SIZE ...... 121 7.1.2 PROJECT BUDGET ...... 122 7.1.3 PROJECT BUSINESS CASE ...... 122 7.2 SYSTEMS LANDSCAPE ...... 124 7.3 PROJECT ORGANISATIONAL STRUCTURE ...... 126 7.4 METHODOLOGY ...... 127 7.4.1 SUCCESS AND FAILURES ...... 129 7.4.2 IMPLICATIONS OF SCALING SCRUM IN LARGE PROJECTS ...... 131 7.5 CASE STUDY FEEDBACK ...... 133 7.5.1 RELEASE FREQUENCY ...... 133 7.5.2 PROJECT DELIVERY RISKS ...... 135 7.5.3 THROUGHPUT ...... 136 7.5.4 OPTIMUM RELEASE STRATEGY ...... 138 7.6 CONCLUSION ...... 139 8. CASE STUDY NUMBER 3 – LARGER THAN LARGE PROJECT ...... 141 8.1 PROJECT OVERVIEW ...... 141 8.1.1 PROJECT SIZE ...... 142 8.1.2 PROJECT BUDGET ...... 143 8.1.3 PROJECT BUSINESS CASE ...... 143 8.2 SYSTEMS LANDSCAPE ...... 144 8.3 PROJECT ORGANISATIONAL STRUCTURE ...... 148 8.4 METHODOLOGY ...... 149 8.4.1 SUCCESS AND FAILURES ...... 150 8.4.2 RELEASE FREQUENCY ...... 150 8.4.3 PROJECT DELIVERY RISKS ...... 152 8.4.4 THROUGHPUT ...... 153 8.4.5 OPTIMUM RELEASE STRATEGY ...... 154 8.5 CONCLUSION ...... 155 9. CASE STUDY 4 – ORGANISATIONAL RELEASE MANAGEMENT ...... 157 9.1 RELEASE MANAGEMENT FROM A ORGANISATIONAL PERSPECTIVE ...... 157 9.1.1 INTERVIEWEE ...... 157 9.1.2 PROJECT TYPES ...... 158

9.1.3 METHODOLOGY ...... 158 9.1.3.1 METHODOLOGY FREQUENCY ...... 159 9.1.3.2 METHODOLOGY APPLICATION: SUCCESS AND FAILURES ...... 160 9.1.4 PROJECT DELIVERY RISKS ...... 161 9.1.5 THROUGHPUT ...... 161 9.1.6 OPTIMAL RELEASE STRATEGY ...... 162 9.2 RELEASE PROCEDURE FROM A DIVISION PERSPECTIVE ...... 162 9.2.1 INTERVIEWEE ...... 163 9.2.2 METHODOLOGY ...... 165 9.2.2.1 METHODOLOGY FREQUENCY ...... 165 9.2.2.2 METHODOLOGY APPLICATION: SUCCESS AND FAILURES ...... 166 9.2.3 PROJECT DELIVERY RISKS ...... 166 9.2.4 THROUGHPUT ...... 167 9.2.5 OPTIMAL RELEASE STRATEGY ...... 167 9.3 FROM A BUSINESS PERSPECTIVE ...... 168 9.3.1 BUSINESS AS IT’S CUSTOMER ...... 168 9.3.2 INTERVIEWEE ...... 168 9.3.3 METHODOLOGY ...... 168 9.3.3.1 METHODOLOGY FREQUENCY ...... 169 9.3.3.2 METHODOLOGY APPLICATION: SUCCESS AND FAILURES ...... 169 9.3.4 PROJECT DELIVERY RISKS ...... 169 9.3.5 THROUGHPUT ...... 170 9.4 CONCLUSION ...... 170 10. A PROPOSED MODEL FOR RELEASE MANAGEMENT ...... 173 10.1 INTRODUCTION ...... 173 10.2 FACTORS INFLUENCING RELEASE MANAGEMENT ...... 174 10.2.1 PROJECT SIZE ...... 174 10.2.2 OVERHEADS ...... 174 10.2.3 ITERATIONS ...... 175 10.2.4 ENVIRONMENT AVAILABILITY ...... 176 10.2.5 CONSOLIDATED FINDINGS ...... 177 10.3 MODEL ...... 177 10.3.1 PROPOSED RELEASED MANAGEMENT ORGANISATIONAL STRUCTURE ...... 179 10.3.2 CREATING DIFFERENT PATHWAYS TO PRODUCTION ...... 181 10.4 CONCLUSION ...... 182 11. CONCLUSION ...... 184 11.1 INTRODUCTION ...... 184 11.2 OVERVIEW OF CHAPTERS ...... 184 11.3 SUMMARY OF OBJECTIVE ACHIEVEMENTS ...... 186 11.4 SUMMARY OF CONTRIBUTIONS ...... 187 11.5 RECOMMENDATIONS FOR IMPLEMENTATION ...... 189 11.6 RECOMMENDATIONS FOR FUTURE RESEARCH ...... 189 11.7 CONCLUSION ...... 189 APPENDIX A – INTERVIEW QUESTIONS ...... 190 GLOSSARY ...... 192 ACRONYMS ...... 201 LIST OF REFERENCES ...... 204

List of Figures

FIGURE 1 RAD PROTOTYPING MODEL (RUPARELIA, 2010) ...... 2 FIGURE 2 DISSERTATION STRUCTURE ...... 10 FIGURE 3 THE PHASES OF THE RESEARCH APPROACH (OLIVIER, 2008) ...... 15 FIGURE 4 CASE STUDY RESEARCH PROCESS (YIN, 2009) ...... 28 FIGURE 5 TIMELINE OF INTERVIEW QUESTIONS ...... 36 FIGURE 6 THE TRIPLE CONSTRAINT (SCHWALBE, 2010) ...... 39 FIGURE 7 AGILE METHODOLOGY STAGES (IBM, 2009) ...... 51 FIGURE 8 AGILE MANIFESTO VALUES (IBM, 2011) ...... 54 FIGURE 9 DEVOPS INTEGRATION ...... 58 FIGURE 10 SERVICE LIFECYCLE ...... 64 FIGURE 11 ITIL ORGANISATIONAL STRUCTURE (WHEELDON, 2002) ...... 74 FIGURE 12 PRODUCTION MANAGEMENT OBJECTIVES ...... 76 FIGURE 13 ESTIMATION PRINCIPLE (LADEIRA, 2002) ...... 86 FIGURE 14 VARIATION OF THE SDLC (SORIANO, 2013) ...... 99 FIGURE 15 ANNUAL FINANCIAL APPROXIMATES (PARSHOTAM, 2013) ...... 108 FIGURE 16 PROGRAMME BENEFITS ...... 109 FIGURE 17 BUSINESS CONNECT SYSTEMS LANDSCAPE ...... 110 FIGURE 18 BUSINESS CONNECT ORGANISATIONAL STRUCTURE ...... 111 FIGURE 19 BUSINESS CONNECT RELEASE CYCLES (WYNGAARD, 2013) ...... 114 FIGURE 20 DEFECTS GROUPED BY STATUS 2013 (WYNGAARD, 2013) ...... 115 FIGURE 21 DEFECTS GROUPED BY STATUS 2012 (WYNGAARD, 2013) ...... 116 FIGURE 22 NBOL BUSINESS CASE (VERMEULEN, 2013) ...... 123 FIGURE 23 NBOL'S SYSTEM LANDSCAPE (VERMEULEN, 2013) ...... 125 FIGURE 24 NBOL’S ORGANISATIONAL STRUCTURE (VERMEULEN, 2013) ...... 126 FIGURE 25 METHODOLOGY EVOLUTIONS ...... 127 FIGURE 26 PRODUCTION INCIDENTS (VERMEULEN, 2013) ...... 130 FIGURE 27 NBOL RELEASE CYCLES (VERMEULEN, 2013) ...... 135 FIGURE 28 CONTEXT DIAGRAM FOR A PARTICULAR BUSINESS RELEASE WITHIN SAP CORE BANKING PROJECT (BRITS, 2013) ...... 145 FIGURE 29 ARCHITECTURAL COMPONENTS INTEGRATED IN BUSINESS RELEASE 6 (KRUGER, 2013) ...... 147 FIGURE 30 CBT PROGRAMME ORGANISATIONAL STRUCTURE FOR BUSINESS RELEASE 6 (KRUGER, 2013) ...... 149 FIGURE 31 CORE BANKING RELEASE CYCLES (PEARSON, 2013) ...... 152 FIGURE 32 RELEASE MANAGER’S SYSTEM VIEW (THERON, 2013) ...... 158 FIGURE 33 RELEASE GATES (OMAR, 2013) ...... 164 FIGURE 34 ECONOMIC BATCH SIZE (POPPENDIECK, 2010) ...... 175 FIGURE 35 PROPOSED OPERATIONAL STRUCTURES ...... 179 FIGURE 36 CURRENT ENVIRONMENT LANDSCAPE ...... 181 FIGURE 37 RECOMMENDED RELEASE STRATEGY ...... 181

List of Tables

TABLE 1 DISSERTATION CHAPTER BREAKDOWN ...... 11 TABLE 2 QUALITATIVE VS. QUANTITATIVE RESEARCH ...... 19 TABLE 3 METHODOLOGY|RESEARCH QUESTION MATRIX ...... 26 TABLE 4 RELEASE MANAGEMENT METHODOLOGIES AND FRAMEWORKS ...... 45 TABLE 5 EXPLANATION OF AGILE PROJECT STAGES ...... 52 TABLE 6 AGILE METHODOLOGY ADVANTAGES AND DISADVANTAGES ...... 56 TABLE 7 DESIGN OPTIONS ...... 69 TABLE 8 CONSTRAINTS IN THE ESTABLISHMENT AND GROWTH OF AN ORGANISATION ...... 84 TABLE 9 SIZE OF THE NBOL PROJECT (RESOURCE-SPECIFIC) ...... 122 TABLE 10 THROUGHPUT MEASUREMENT EVOLUTIONS ...... 137 TABLE 11 GLOSSARY ...... 192 TABLE 12 ACRONYMS ...... 201

1. Introduction

This chapter is dedicated to introduce the purpose of this research study and to discuss the release management strategies intended for investigation.

1.1 Background information

There is quite a significant unexplored area in the software management field that can be described as the decision process in releasing or implementing a software- developed product. Software functionality has become the most effective way of communicating and transacting with customers, specifically in the financial industry. Software acts as the predominant medium, presently, between organisations and customers who wish to interact effectively with such organisations.

A particular framework that describes the stages involved in developing software application is known as the Software Development Lifecycle. Various models exist and according to the specific relevance of certain software projects these models can therefore be applied. The stages of the traditional software development lifecycle can be listed as follows (Turpin, 1996): • • Design • Implementation • Testing • Delivery.

The different models that exist can be listed as below (Ruparelia, 2010): • The • The • The B-Model • The V-Model

Natasha NV Ferreira 200508700 Page 1 of 213

• The Incremental Model • The Wheel and Spoke Model • The Model • Rapid Application Development (known as RAD).

RAD is a model that uses a prototyping mechanism where test cases are created and unit testing is performed. RAD incorporates a number of techniques for support. The most significant characteristic known among these techniques is rapid development. Approximately five such mentioned techniques exist and can be listed as follows (Ruparelia, 2010): • Agile • • Joint Application Development (JAD) • Lean Development • SCRUM – this technique involves development occurring over a series of short iterations, or sprints, where progress is measured daily.

Figure 1 RAD prototyping model (Ruparelia, 2010)

The five above-mentioned techniques that improve rapid development in the RAD-model have distinctive characteristics. One of the 19 guidelines for creating open source software states that in order to achieve rapid code improvement

Natasha NV Ferreira 200508700 Page 2 of 213

and effect with minimal hassle, your users should be treated as co- developers (Ruparelia, 2010).

Another guideline states the philosophy ‘release early; release often; and listen to your customers’, which is supported by the Bazaar model (Raymond, 2001). This model represents the development of software over the Internet, which is in public view. This particular philosophy is quite similar to the one RAD has adopted as well as one of its supplementary techniques, Agile. By adopting such techniques a number of benefits result from that, namely minimising scope changes and future creep. This is maintained because the project is divided into smaller sub-projects and development occurs in shorter intervals. Incremental changes are also captured by the software releases that are prepared.

1.2 Purpose and importance of study

The key objective of release management is to protect the live environment while enabling enhancements in a coordinated manner to ensure a trouble-free go live. A release management process is necessary to minimise the risk caused by business process interruptions that are associated with the changes implemented in the system, which have been scheduled inadequately (Wartnaby, 2011). This process is significantly important for organisations implementing new functionality that is closely related to existing functionality. The goals of such a process include quality assurance, production readiness and deployment of first-hand or modified software. Many organisations seem to have difficulty within their change management process because the release management process may not exist.

The main challenges some organisations may encounter is the lack of accurate prediction with regard to time, cost and a total breakdown in the business owners’ confidence level and the faith they have in IT’s ability to deliver (Lahtela et al., 2011). With the aid of a release management methodology in place, schedules and

Natasha NV Ferreira 200508700 Page 3 of 213

functionality may be forecast. The view between the integration departments such as business and IT becomes more visible, and also provides for predictability.

Since a variety of programmes may exist within an organisation, similarly a variety of projects may exist within that programme. It is therefore quite necessary that the appropriate release management methodology be applied to the correct type of project for accuracy purposes. We hope that this study will show that not all projects can implement the same release management methodology. Therefore, in order to be effective, each methodology should be applied according to appropriateness.

1.2.1 Problem statement

Release management is a crucial factor in the SDLC. A variety of formal SDLC methodologies exist to assist a project manager in accomplishing software release delivery into production. The methodologies range along a spectrum of Agile to iterative to sequential (Vermeulen, 2012).

Research has shown that the software development cycle can simply be defined as a framework that describes the activities that are performed at each stage within a software development project (Bhattacharjee, n.d.). The phases can be listed as: • Systems Investigation • • Systems Design • Systems Implementation • Systems Maintenance and Review.

Research shows that Agile methodologies have been developed initially to add flexibility to small-scale IT software development projects (Ambler, 2012). This is to ensure improving the project’s ability to respond and adapt to change in an

Natasha NV Ferreira 200508700 Page 4 of 213

environment that is constantly changing, since change is inevitable. By applying such methodology the number of software releases can be increased annually.

On the other hand this does not necessarily translate to the increase in functionality that is delivered to business, nor does it make the ability of process repetition possible in the sense that the process can be repeated over several releases with an equal success rate reproduced in each release. Similarly, this methodology is not beneficial for effective future planning in both the business and IT environment. Specifically on what functionality will be delivered in what timeframe.

The underlying concern that exists in most software development projects is the decision regarding which release management approach should be applied in order to achieve the four primary business requirements. These requirements can be defined as the following (Vermeulen, 2012): • The ability to maximise functionality delivered in the shortest possible timeframe • Knowledge of what requirements will be delivered and when • Catering for a capability for future planning so that commitments with regard to budgets and client expectations can be managed and met • Repetition of the delivery process over a number of releases with consistent results in each release. My research will attempt to show that fewer releases do not always increase throughput but that it depends on many factors.

The outcome will be justified with information, including the advantages the relevant release methodologies portray.

Natasha NV Ferreira 200508700 Page 5 of 213

1.2.1.1 Release management

A significant skill to distributing a software project or product to a customer is known as ‘Software Release Management’ (Rana et al., 2005). Release management is a rapidly growing discipline within . It can be defined as the process by which the planning, building and deploying of hardware and software are initiated as well as the version control and storage of such software.

For the purpose of this research project, emphasis will be placed on the deployment of software products. The planning and building as well as storage of such software will remain out of scope with regard to this research initiative. This process is not just about what goes into a product development environment but also how these go in. The implementation of an accurate release model results in two specific business benefits known as ‘overall cost reduction’ and ‘improvement in customer satisfaction’.

This process uses people, functions, systems and activities to also package the abovementioned into production (Lahtela et al., 2011). As such, each software release by nature as well as definition can be seen as an independent project.

The IT service management discipline benefits significantly from this process, as its aim is to improve the alignment of IT efforts to business requirements and to manage the efficiency in providing IT services with guaranteed quality. Software releases are necessary for two known reasons (Lahtela et al., 2011). Firstly, to implement solutions to incidents and problems as bug fixes. A problem can either be defined as an unknown cause of one or more incidents or similarly, as a human encounter with software that causes difficulty, doubt or perhaps even uncertainty. Secondly, to implement changes – those that add new requirements to system enhancements.

Natasha NV Ferreira 200508700 Page 6 of 213

Two processes that cannot easily be implemented independently are known to be change management and release management.

It is often quite difficult to decide on the most appropriate release date, feature functionality, associated development costs and quality concerns. A release strategy often includes information, as mentioned in the Supporting a Common Project Delivery Framework newsletter, such as: • Producing, testing and documenting the product • Packaging and distribution • Data migration • Software hosting • Provision of end-user training.

Release management approaches are organisation-specific and may vary. Having said that, regardless of the adapted approach according to research (‘Supporting a Common Project Delivery Framework’, 2012), the best practice that should be implied within either approach is comprised of activities that strive to meet the defined process above as well as implementing defects, change requests, market demands and client expectations. As a crucial factor in the software development lifecycle, research has shown that this process feeds directly into the primary business requirements to achieve the following (Vermeulen, 2012): • Ensure the maximum possible functionality delivered in the shortest possible timeframe • Identify and recognise what requirements will be delivered and when • Ensure the capability to do forward planning so that commitments with regard to budgets and client expectations can be managed and met • Repeat the delivery process over a number of releases with the same results in every release.

Natasha NV Ferreira 200508700 Page 7 of 213

Critical success factors for release management that should always be considered are the following (Pieterse, 2001): • A reliable measurement methodology • The ability to repeat deliverables release after release • The ability to predict what business functionality can be delivered and when • The ability to plan a release well in advance to determine go-live dates with a high degree of accuracy.

Release management has proved to be simple for a team adopting Agile principles to their specific projects (Berczuk et al., 2008). Since this particular team would, theoretically speaking, make provision for project releases at regular intervals.

1.3 Research questions

The questions that will be addressed for the purpose of this investigation consist of the following:

1.3.1 Question one

Will a frequent (minimum of one week) release strategy increase project throughput for all types of projects? This question will be evaluated and investigated by using a number of reference projects in order to determine the throughput achieved in the particular projects. The specific release management strategies will be considered.

The frequency of any release varies according to the technical and business aspects in context. In general, however, one release with four to six SDLC iterations would be considered maximum. On the other hand, findings have defined a ’frequent release’ as anything as short as one to two weeks or up to

Natasha NV Ferreira 200508700 Page 8 of 213

four weeks, which is what has been described as common practice (IBM, 2009). This is therefore what is referred to as ‘frequent’ in this particular question.

Frequent releases play a significant role in release management, as they lead to the extension of a product’s sale lifespan, since a day taken out of the development lifecycle is an extra day in the sales environment. Similarly, the availability of resources increases too; resources are able to work on other initiatives. Logically speaking, any product that makes it to the market first, is likely to be the one to preserve market share compared to competitors.

1.3.2 Question two

If the first question results in a negative outcome, i.e. frequent releases are not necessarily applicable to all project types, and then the following reasoning that complements this conclusion would be identified. The second question that will be studied is:

What type of projects will not benefit from a frequent release strategy as seen from a throughput perspective? This question will be devoted to identifying which projects in particular are better managed using a distinctive release management strategy and do not benefit from such methodology.

1.3.3 Question three

How can an optimum release management methodology be determined to add advantage to certain project types?

Natasha NV Ferreira 200508700 Page 9 of 213

Research will then be conducted to determine the most ideal release management strategy for the projects failing to benefit from the frequent release-specific management strategy, as discussed in Question 2.

1.4 Dissertation structure

This dissertation consists of nine chapters. Figure 2 below presents a graphical layout of the structure of the dissertation.

Section(1:(Background ( ( Chapter(2( Chapter(5( Chapter(1( Chapter(3( Chapter(4(( Research( Disserta?on( Introduc?on( Literature(Review( Throughput( Methodology( Layout( ( (

Section(2:(Research(Results,(Evaluation(and(Discussion

( ( ( ( Chapter(9( Chapter(8( Chapter(7( Chapter(6( Examines(Case( Examines(Case( Examines(Case( Examines(Case( Study(4( Study(3( Study(2( Study(1( ( ( ( (

Section(3:(Conclusion

( ( Chapter(10( Chapter(11( Op?mal(Release( Conclusion( Strategy(Proposal( ( (

Submission(

Figure 2 Dissertation Structure

This dissertation is made up of three sections, namely: 1. Background Which provides a background to the problem 2. Research results, evaluation and discussion. This section examines the proposed research questions. The results retrieved are also analysed in this section.

Natasha NV Ferreira 200508700 Page 10 of 213

3. Conclusion This section provides a conclusion to the research topic.

Each section is compromised of either a single chapter or multiple chapters.

Please refer to the table below for details concerning the contents of the chapters subsequent to this one.

Table 1 Dissertation Chapter Breakdown Section Chapter

One Two

This chapter will provide an overview of the research method, an introduction to the literature review and research questions that will be investigated will be made. Four projects will be discussed as well as the measurement metrics that were adopted for such projects. One Three

This chapter will consist of an overview of the literature review. Project management and software engineering methodologies will be defined as well as release management strategies. Similarly, throughput will be defined and how to measure it will be illustrated. Agile methodologies and their characteristics, from a release management perspective, will also be discussed. One Four

This chapter is dedicated to explaining what throughput entails and why it is so important. It also looks at ways to measure throughput and states why measuring throughput is significant.

One Five

This chapter provides an overview of the proceeding chapters specific to the case studies. It describes how the following chapters will be structured and presented.

Natasha NV Ferreira 200508700 Page 11 of 213

Section Chapter

Two Six, Seven, Eight

The sixth, seventh and eighth chapters will be devoted to investigating the three research questions proposed previously in this research paper by examining three case studies and their relevance.

They will be considered in answering these questions. Firstly, whether frequent releases increase throughput with large-scale financial projects and secondly, the evaluation of less frequent release strategies will be carried and a decision made on whether such release methodologies are only applicable to some project types or to all. Goldratt’s critical chain management principles will be used to identify activities within a project. A method will then be identified to overcome such project constraints. Lastly, the final question that will be addressed is how an optimum release management methodology could be determined to add advantage to certain project types.

Two Nine

The ninth chapter will provide a holistic view from three different perspectives and how release management is applied in those environments. Three Ten

This chapter will propose an optimal release strategy to be applied to projects throughout the financial institution.

Three Eleven

Lastly, a detailed conclusion will be presented that can be drawn out of the researched topic.

Natasha NV Ferreira 200508700 Page 12 of 213

2. Research method

This chapter is dedicated to introducing the methodologies that will be applied to this research study, and to discussing the research approach adapted to the research topic in context.

2.1 Introduction

It has been noticed through thorough investigation that research is defined as ‘the systematic and objective analysis and recording of controlled observations that may lead to the development of generalisations, principles or theories, resulting in prediction and possibly ultimate control of events’ (Borland, 2001).

‘Research design’ is a term often interpreted as the structure of the research that combines all the elements of a research project. Time is a significant element in research design (Trochim, 2002). The significance of the structure lies within illustrating how all the key components proceed in addressing the fundamental research questions. This term can often also be seen as the plan in which the researcher intends on carrying out the research project; it serves as an indication of what will be done, in what manner and when, in order to reach a solution to the proposed research question(s) (Draper, 2004). This term is an umbrella term, incorporating the expressions ‘research methodology’ and ‘research methods’ which are often used interchangeably. A research methodology is the overall research approach selected by the researcher while a research method is the practicality around data collection and analysis. The design ensures coherence, since it is the rationality that links the collected data in order to achieve a conclusion (Rowley, 2000). A research design is made up of the following components: • Research questions • Research propositions • Project units of analysis • Logic for linking questions and propositions

Natasha NV Ferreira 200508700 Page 13 of 213

• The criterion of interpreting findings.

This chapter is dedicated to introducing the research questions and the approach followed in the research design process. It takes the necessary methodologies, instruments in the data collection and analysis phases into consideration. This chapter, along with the actual proposed research statement, is a significant factor that adds to the success of a dissertation. This chapter serves the particular purpose of explaining to the audience how the solution to the dissertation statement will be determined.

There are three conditions that exist in assisting on the decision-making of what research methodology should be applied to a certain research project (Yin, 2009). These include: • The proposed research question type • The extent of control the researcher has over the actual behavioural events • The degree of focus on contemporary events over historical ones.

Four best-case projects or initiatives that resemble the particular release management methodology in context of this dissertation will be introduced. These will add to the investigation around whether frequent releases are one of the significant factors leading to project throughput.

A model will be considered, which has been constructed to imply simpler understanding. Some of these problems could be resolved using an argumentative or case study approach. Since an argumentative approach could consider two release management methodologies and argue why an agile methodology, for instance, is the most efficient one. On the other hand, a case study approach will learn from current situations and be used to measure some phenomenon existing in a situation that could have either a qualitative or a quantitative result.

Natasha NV Ferreira 200508700 Page 14 of 213

As illustrated by certain research, a few methods are applicable to information technology research projects. These will be adopted to determine an appropriate conclusion to the research questions proposed for this particular study (Olivier, 2008). It is essential to determine which one of the many research available is the most appropriate for the particular statement proposed. This does not imply that only one research method may be adopted though – the strengths and weaknesses of all the methodologies should be investigated so the appropriate methodology may be adopted.

Explore Propose Prepare Execute Analyze Publish

Figure 3 The phases of the research approach (Olivier, 2008)

2.2 Research questions

The research question, which is often seen as the problem statement, is the basis of any research study. It often presents the idea for examination and is the readers’ signpost (Haber, n.d). Research questions are not necessarily generated from thin air; they should indicate the practical experience and critical appraisal of the scientific literature or interest in a theory not yet tested. These criteria should form the basis of the proposed research questions. A well-developed research question is essential in any research project in order to avoid searching for incorrect, inappropriate or redundant information. A well-developed question should specify

Natasha NV Ferreira 200508700 Page 15 of 213

the considered variables, what is being studied and imply the empirical testable ability.

Two types of questions exist (Draper, 2004): 1. Interrogative Conveyed as a question 2. Declarative Expressed as a statement defining the purpose of the research project.

The research questions mentioned in Section 1.4 above were refined and established with reference to the ambiguity that currently exists within specific IT projects and the delivery methodologies that are being applied in different departments in the financial institution in context.

The questions for investigation are highlighted below. These questions will focus on certain project types, and methodologies specifically.

2.2.1 Question one

Will a frequent (minimum of one week) release strategy increase project throughput for all types of projects?

2.2.2 Question two

What type of projects will not benefit from a frequent release strategy from a throughput perspective?

Natasha NV Ferreira 200508700 Page 16 of 213

2.2.3 Question three

How can an optimum release management methodology be determined to add advantage to certain project types?

A fundamental element within the research process in its entirety consists of two elements previously discussed. These are the research design and research questions, because the quality of the research project could be challenged if an inappropriate design is applied to answer the research questions (Draper, 2004). Research design, in most cases, is driven by research questions.

2.3 Research approach

This section explores distinctive research approaches and distinguishes the most appropriate ones for the purpose of this research project. This is a significant step within the research study since the decisions made here strongly influence what the question definition will be as well as what particular methods will be used.

2.3.1 Qualitative vs. quantitative research

Qualitative and quantitative research can be differentiated, as a qualitative method involves characteristics that are not at all statistical; i.e., they are characteristic of people or events in comparisons (Thomas, 2003). Qualitative researchers examine things in their natural settings; they try to make sense of personal stories while quantitative research focuses more on the measurements or amounts revolving around the characteristics of people or events. These particular researchers use numerals and statistical means of making sense of data. Their role is to perceive and quantify; their objectivity is the ultimate concern.

Natasha NV Ferreira 200508700 Page 17 of 213

While these two research approaches differ in focal points, research has shown each of the results generated may be complementary (Firestone, 1987). Moreover, there are more overlaps than differences between the two types of methods (Brannen, 2005). Similarly, these two approaches may be concerned with people’s actions; the most significant difference between these two types of research approaches is the flexibility of qualitative research methods. The research may apply initiative in implementing an interview that is a qualitative research method. These significances are generally based on this philosophy – can it be quantified and how is it perceived in reality? The decision revolving around which approach to select is purely based on the data type that needs to be collected and analysed, whether it is textual or numerical.

The table below compares the two research approaches (Borland, 2001):

Natasha NV Ferreira 200508700 Page 18 of 213

Table 2 Qualitative vs. quantitative research Qualitative Quantitative Purpose to explain, and gain insight and Purpose to explain, predict and control understanding of phenomena through phenomena through focused collection intensive collection and narrative data. of numerical data. Approach to Inquiry Holistic and process oriented. Focused and outcome oriented. Hypotheses Tentative and study-specific. Specific and stated prior to study. Review of Related Literature Limited and does not affect particular Extensive and affects study. study. Research Setting As-is to the possible degree. Control to the possible degree. Sampling Determined. Random. Measurement Narrative and continuous. Numerical and standardised. Design and Method Flexible and specified in general terms. Structured and specified in detail. Data Collection Strategies Unstructured or informal interviews. Semi-structured and formal interviews. Administration of open-ended Administration of questionnaires. questionnaires. Data Analysis Raw data = words. Raw data = numbers. Data Interpretation Conclusions reviewed on an ongoing Conclusions formulated at end of study basis, generalisations are non-existent. and stated predetermined with a degree of certainty.

Natasha NV Ferreira 200508700 Page 19 of 213

Research states that, even though several differences exist between the two research approaches, success in research is often a result in appropriately applying both approaches in order to create knowledge to support decision- making (Borland, 2001).

2.3.2 Selected research approach

After many deliberations it was decided that a hybrid approach of both qualitative and quantitative would be applied to this research study. The main reason is because a qualitative approach fits cases best where an unknown experience needs to be better understood because it has never been applied in the correct manner perhaps. A detailed answer is required from this research paper. And similarly, an explanation should be derived through focused collection of numerical data, which relates to quantity. These are the elements that led to choosing a hybrid approach.

• This research topic takes manners, outlooks and incidents into consideration. • The necessity of a comprehensive understanding into the problem is based on contributors enlightening their previous practices. • This particular study requires contact with certain stakeholders in their work environment. • Interpretation of reality is necessary to achieve experience explanations.

Natasha NV Ferreira 200508700 Page 20 of 213

2.4 Research methodology

2.4.1 Overview of possible research methodologies

Qualitative data refers to the data collected in terms of words or pictures and not necessarily numbers (Seaman, 1999), since this type of methodology is used to study the complexities, which exist with respect to human behaviour. Within the field of Information Technology, however, it has been said that a combination of both qualitative and quantitative methodologies are recommended in order to ensure that both the technical and the human behavioural aspects are studied. This is to ensure that the one benefits from the strengths of each methodology.

2.4.1.1 Participant observation

This methodology involves interaction between the researcher and informant or many informants (Seaman, 1999). Firsthand behaviour should be captured in order for data to be collected unobtrusively. Data gathering using this approach is usually done in the form of field notes. This approach is often used in conjunction with interviews.

2.4.1.2 Evaluative research

The researcher adapting this type of research is interested in coming to a conclusion about the success level or effect of a particular intervention. An appraisal is drawn up for this methodology in order to evaluate why the conclusion was what it was. Appropriate measurement criteria are required and are challenging to determine (Hofstee, 2006).

Natasha NV Ferreira 200508700 Page 21 of 213

2.4.1.3 Comparative analysis

This type of research involves a researcher investigating two matters in a methodical way (Hofstee, 2006). These items are compared so their differences are understood. This approach needs to be a focused one and is best suited to some problems rather than others – this is one of the risks in applying such a methodology.

2.4.1.4 Experiments

This section will provide an indication of the approach that will be taken to test the proposed research statement in Chapter 1. The following techniques that will be adopted to reach a conclusion to the statement will be listed and on which will be focused. Each of their characteristics, both advantageous and disadvantageous, will be discussed.

A qualitative research methodology can either be conducted in a laboratory or within the field. It is carried out to test a theory or hypothesis (Hofstee, 2006). The relevance of such an approach would be more appropriate in the physical science and psychology fields where certain tests need to be carried out on living things, for example. This type of design can be costly and the ethics side of it could cause some complications.

2.4.1.5 Case studies

A case study is usually applied to test the hypothesis, specifically of a certain case (Hofstee, 2006). The main goal of applying a case study type of methodology is to learn from current situations in real life (Olivier, 2009). The aim of such a research methodology would be to discover some principles, which could possibly be generalised to cases that are similar in nature.

Natasha NV Ferreira 200508700 Page 22 of 213

A particular area of concern regarding this technique would be the risk of losing focus, subjectivity as well as the generalisability of results. For this particular reason this is one of the techniques that is usually used in conjunction with one or a few of the others that are available.

2.4.1.6 Interviews

This common approach is usually used when the researcher has objectives in retrieving historical data from the interviewee’s memory, clarifies data gathered or elicits impressions (Seaman, 1999).

Several types of interviews exist: • Structured interviews o The interviewer possesses the questions while responses rest with the interviewee. • Unstructured interviews o The interviewee is the source of both questions and answers. • Semi-structured interviews o It consists of a combination of open-ended and a set of actual questions with objectives to elicit not only the information seen, but also unexpected types of information.

Similarly, field notes are used to gather the specific data collected during the interview.

Natasha NV Ferreira 200508700 Page 23 of 213

2.4.1.7 Surveys

A survey can be described as an investigation of the opinions, desires or attitudes experienced by a group of people (Hofstee, 2006). This is usually carried out by means of questionnaires or interviews – this research design also tests particular theories and does not necessarily only determine qualitative-specific data (Olivier, 2009).

2.4.2 Selection of the appropriate research methodology

2.4.2.1 Case studies

Research has shown that a central tendency among all case study types is the attempt to illuminate a decision or decision sets, the reasoning behind these decisions being made and how implementation has taken place (Yin, 2009). A case study observes a large number of features of a few cases. It has been said that this particular methodology is applied in scenarios when the researcher requires detailed knowledge in particular cases. For the purpose of this document the cases will be seen as certain projects.

This particular methodology is more often rather qualitative than quantitative in the sense that the achieved results are expressed by means of descriptive statements and not through statistical numerical values.

A number of possible designs exist, specifically for case studies: • A holistic design vs. an embedded design • Single case design vs. multiple case designs o A holistic design refers to a case that is studied in its totality whereas an embedded design simply means that exclusive cases within a major case are studied.

Natasha NV Ferreira 200508700 Page 24 of 213

2.4.2.1(a) Case study protocol

This fragment of the case study sets out what is specifically going to be studied and how exactly it will be studied. The protocol assists in maintaining the focus regarding why the study has been initiated.

2.4.2.1(b) Collection of data

Data may be collected in a qualitative or quantitative manner but in most cases and for this particular research design, qualitative data has more of an accurate representation of the aspects being studied. Data will be collected by means of interviews for this particular research paper.

2.4.2.1(c) Case selection

Cases should not be selected based on the validity they reflect on the theory one intends on testing. They should rather be selected with a relatively arbitrary approach.

2.4.2.2 Literature survey

According to Hofstee, a literature survey is significant because it: • Provides awareness for you of what is happening in the field of study and the researcher’s credentials • Ensures significance of the research piece of work • Ensures that a theory base exists for the proposed piece of work.

Natasha NV Ferreira 200508700 Page 25 of 213

The purpose of the literature survey for this particular study is to become accustomed with the vast amount of knowledge available regarding release management methodologies in IT project management.

Take into consideration: A researcher can never be sure of when the data collected from previous studies is sufficient only until the research study has reached its completion. It can be noted that the more resources from which the articles are retrieved, the better for the research projects knowledge base.

The four above-mentioned research methodologies are used throughout this dissertation. The table below summarises and illustrates clearly which research methodology was used to address the relevant research questions.

Table 3 Methodology|Research question matrix Quantitative Qualitative Research Research Method Method

Surveys Case Studies Interviews Literature Survey Research Question 1. Will a frequent (minimum of one week) release ✓ ✓ ✓ ✓ strategy increase project throughput for all types of projects?

2. What type of projects will not benefit from a ✓ ✓ ✓ frequent release strategy from a throughput perspective?

3. How can an optimum release management ✓ ✓

Natasha NV Ferreira 200508700 Page 26 of 213

methodology be determined to add advantage to certain project types?

2.4.3 Research data collection process

The purpose of this particular subsection is to discuss the detail concerning the application of each particular research design selected to this study. Each case study will then be discussed in the chapters to follow. This will each entail a section discussing the data that has been obtained as far as discussing the strengths and weaknesses of such data. An analysis section that will be used to turn the data retrieved into evidence will follow this section. Any form of analysis should then be applied; whether it’s in a statistical or textual format in order to form a discussion on how the conclusion will be derived, based on the retrieved data.

Another section that may be discussed would be that of limitations. This will entail the other manner in which that the proposed problem statement could have been tackled and why this method was not chosen.

2.4.4 Research instruments

This section reflects how the actual data used to reach a conclusion is collected, and what instruments and procedures are used. Since this research project applies a qualitative research approach, the data will be collected in the form of words from the various methodologies previously mentioned.

Having said that, the primary instruments selected for this research project are the researcher and a generated case study database.

Natasha NV Ferreira 200508700 Page 27 of 213

2.4.4.1 Case studies

Applying this type of research design is a linear yet iterative process, as illustrated in Figure 4 (Yin, 2009).

Figure 4 Case study research process (Yin, 2009)

1. Plan: Research questions are identified and a decision is made to adopt a case study research approach after various other methodologies have been considered; understand the underlying strengths and limitations. 2. Design: The analysis unit is defined at this point as well as the case(s) that will be studied. Theories, propositions and underlying issues are developed thereafter. The case study design is then identified – whether it is single, multiple, holistic or embedded – as well as the procedures to maintain the quality of the case study. i. The unit of analysis is related to the fundamental problem of defining what the definite ‘case’ is. This is related to the way in which the research questions have been defined. ii. A hypothesis or proposition in this context makes provision for what should be examined within the research range. The details regarding linking data to theories and the criteria

Natasha NV Ferreira 200508700 Page 28 of 213

required to interpret findings will be handled in detail in the ‘analyse’ stage of the process. A decision will just have to be made at this stage of how suitable each is to the case in context. iii. Four types of case study designs exist and can be categorised as: o Type (1) Single-case (holistic) o Type (2) Single-case (embedded) o Type (3) Multiple-case (holistic) o Type (4) Multiple-case (embedded). iv. The quality of the design can be analysed by logical tests, four of which can be defined as the: o Construct validity test o Internal validity test o External validity test o Reliability test. Certain strategies are used to be able to generate such tests. 3. Prepare: Specific training is necessary at this stage; since the researcher’s improved skills need to be prepared. Development of the case study protocol as well as a pilot case conduction is then done. If necessary, approval needs to be retrieved for human subject protection. i. A list of common skills exists for a researcher adopting such a methodology. The researcher needs to have the ability to ask good questions and interpret them correctly; to be a good listener; to be adjustable and easy-going; to maintain a firm grasp of study issues in context and to adopt an unbiased attitude towards predetermined concepts. ii. The training involved in order to function as a senior researcher begins with the definition of the research questions to be addressed and the development of the case study design.

Natasha NV Ferreira 200508700 Page 29 of 213

iii. A case study protocol contains instruments and general rules or procedures of how the protocol should be used. Its intention is to guide the researcher in interpreting data. A protocol should contain: o An overview of the case study project o A field procedure that should emphasise major tasks required in data collection o Case study questions o A guide for the report. iv. A pilot case can assist in the refinement of data collection plans and is only a requirement if necessity arises. 4. Collect: At this stage of the process the developed protocol is followed and multiple sources are utilised for evidence. A case study database is then created and the chain of evidence is maintained. i. Six sources of evidence exist: o Documents o Archival records o Interviews o Direct observation o Participant observation o Physical artefacts. ii. Three principles of data collection exist: o Utilise multiple sources of evidence o Create a case study database o Maintain a chain of evidence. 5. Analyse: Theoretical propositions and other strategies are strongly relied upon here, and any five analytical techniques are considered where quantitative or qualitative data, or perhaps both, have been used. Then challenging explanations are explored and data interpretations are displayed.

Natasha NV Ferreira 200508700 Page 30 of 213

i. Relying on defined hypotheses, since these are the foundations of the case studies. If this strategy fails, then perhaps a case description should be developed. ii. Making use of both quantitative and qualitative data is beneficial. iii. Examining rival explanations involves defining and testing these rivals. Two types exist: craft and real-life where sub- types are also defined. iv. The five analytical techniques are defined as: o Pattern matching o Explanation building o Time-series analysis o Logic models o Cross-case synthesis. v. Quality of the analysis must be achieved at all cost. This can be achieved if all evidence is attended to, all major rivals are interpreted, the most significant aspect of the case is addressed and the researcher utilises personal prior expertise. 6. Share: At this stage in the process an audience is defined, while textual and visual materials are then composed. Sufficient amounts of data are provided in order for the reader to draw a conclusion of his own. A review is then carried out and where necessary, re-work is incorporated for perfection to be achieved. i. This stage involves finalising and concluding the results that were uncovered. The appropriate audience needs to be defined. This will reflect what the structure of the case study report should resemble. This then needs to be generated. For the purpose of this project, the report will form part of a larger report with various methods within the dissertation and the audience may be defined as a dissertation

Natasha NV Ferreira 200508700 Page 31 of 213

committee of academics. It will be distributed for a review process. ii. For the particular audience of this research project excelling in the methodology and propositions are fundamental. Four varieties of written formats exist: o Single-narrative case study o Multiple-narrative case study o Multiple or single case study (question and answer format) o Multiple case studies. iii. Six illustrative structures exist and can be applied to either format selected: o Linear-analytical o Comparative o Chronological o Theory-building o Suspense o Un-sequenced.

2.4.4.2 Interviews and surveys

Certain questions will be addressed to key project stakeholders in order to determine the outcome of release methodologies applied to previous and current projects. These answers will form part of the data analysis needed to define the conclusion.

The data will be collected using a semi-structured face-to-face interview with open-ended questions. This will assist in the exploration of the participants’ perceptions. This type of interview yields ‘yes’ or ‘no’ answers, and questions should be defined in advance. It should also follow a conversational manner with smooth topic transitions.

Natasha NV Ferreira 200508700 Page 32 of 213

2.5 Ethical consideration

Research dictates that moral accuracy in all research activities should be considered (Boeije, n.d.). Regarding this study, the basic concept is participant trust. Consent from the participants needs to be received and each participant needs to be informed that their identity will remain anonymous, since this ensures data quality. Confidentiality needs to be maintained, and promises made to interviewees must be kept.

2.6 Research data analysis

This section is dedicated to discussing what the qualitative methods are for analysing the collected data through interviews and case studies in particular.

The steps below describe how qualitative data gathered from interviews can be analysed: Data preparation: This preparation phase includes organising the data for analysis purposes. It forms part of the transcribing stage within the interview process where the data is validated and transformed. Descriptive statistics: As its name suggests, this phase states is a description of the data, and what is illustrated by the data occurs during this phase. Inferential statistics: Lastly, the data is interpreted to determine relevant results. A link between the inferential analysis and the proposed research questions is made.

From a case study perspective, the analysis of the gathered data should follow the process below (Yin, 2009): 1. Rely on the theoretical propositions defined. 2. Apply any of the five analytical techniques for the analysis process of the data. These include: a. Pattern-matching

Natasha NV Ferreira 200508700 Page 33 of 213

This involves the comparison of an empirically based pattern and a predicted one. If these patterns correspond it can be presumed that the case study is internally valid. b. Time series analysis c. Explanation building This analysis involves building an explanation about the case. It is also a direct analogy of the technique used in certain experiments. d. Logic models This technique specifies a complicated chain of events over a lengthy time frame. e. Cross-case synthesis Usually applied to a multiple-case research project. 3. Exploration of rival explanations, a number of rivals exist: a. Craft rivals ! The null hypothesis ! Threats to validity ! Investigator bias. • Real-life rivals o Commingled rival (practice or policy) o Implementation rival o Rival theory o Super rival o Societal rival. 4. Apart from interpretations, data is displayed. o Direct rival (practice or policy).

These are the analytical techniques that will be applied in this research study.

Natasha NV Ferreira 200508700 Page 34 of 213

2.7 Research value

The value of the research undertaken in this dissertation can been perceived from a programme perspective and narrowed down to a project delivery perspective.

The considered program from the financial institution in context is the department associated with Information Technology Transactional Products and Services in the corporate and investment-banking environment.

The various case studies selected from the particular program mentioned above are associated with different project types. The project types vary from technical system integration involvement to functional front-end interface integration as well execution systems producing output, based on a certain input provided. Therefore, the quality success factors in deliverables will vary and they may be affected by the release management methodologies put in place. Project managers and other project stakeholders will now have a better understanding of the project phases and releases.

2.8 Proposed research approach

For the purpose of this research paper a qualitative research approach will be followed. This approach will combine a subset of the methodologies previously discussed, which include: • Case studies o After focusing on all the different case study structures and formats that are available it was determined that the design adopted for this research project would specifically be the third type defined as a holistic-multiple case. • Interviews

Natasha NV Ferreira 200508700 Page 35 of 213

o The approach used to collect the specific data would be by means of interviews; therefore, the researcher has chosen to adopt this specific evidence source. • Literature survey.

Below is a demonstration of the timeline that will be applied to the interviews carried out.

Figure 5 Timeline of interview questions

2.9 Conclusion

This chapter has focused on the research design strategies and the approach that will be adopted in order to determine a solution to each research question. The proposed research questions, as mentioned in the first chapter, are highlighted below: 1. Will a frequent (minimum of one week) release strategy increase project throughput for all types of projects? 2. What type of projects will not benefit from a frequent release strategy from a throughput perspective? 3. How can an optimum release management methodology be determined to add advantage to certain project types?

Natasha NV Ferreira 200508700 Page 36 of 213

As proposed above, this hybrid approach, which takes both qualitative and quantitative methods into consideration, will consider the application of multiple case studies. Current situations can then be reviewed and studied in order to achieve a conclusion for the research questions. The aim is to retrieve a qualitative or quantitative result, structured interviews and a literature survey to be able understand particular concepts used throughout this research paper. The need for surveys to be carried out is not necessary, as the outcome of interviews has been efficient enough for the purpose of this research paper.

The written format of how this research project will be distributed will take the form of a multiple-narrative case study. It will follow a linear analytical illustrative structure to formally inform the audience what the outcome of the research project is.

The next chapter will look into the literature review considered for this research project and define the knowledge base that the researcher has used.

Natasha NV Ferreira 200508700 Page 37 of 213

3. Literature Review

The aim of this chapter is to outline previous studies conducted in the context of this literature. Several project management and software engineering terms that will be utilised throughout this study will also be defined.

3.1 Project management

Before one can understand what the term project management is, the term project needs to be comprehended. A project is defined as an effort that is undertaken on a temporary basis to create a product, provide a service or achieve a result (Schwalbe, 2010). An IT project refers specifically to the information management system of a computer (Liu et al, 2012). This is a project that relates to information technology such as software, hardware and information systems.

A project consists of a number of attributes, which are usually intended for a refined definition of a project. A project: • Has a unique, well-defined purpose • Is temporary with a known start and end date • Is developed using progressive elaboration, which should be developed in increments • Requires a variety of resources such as hardware, software and other assets from several areas • Should have a primary customer or a sponsor who provides the fund and direction of the initiative • Involves uncertainty.

Similarly, an IT project shows the following features: • Urgency IT projects have a deadline with a definite start and conclusion. • Uniqueness

Natasha NV Ferreira 200508700 Page 38 of 213

This refers to the fact that not only is the customer provided with a product, but more importantly with a variety of solutions satisfying his requirements. • Uncertainty Since a project is unique, it is difficult to define its objectives clearly, estimate how long it will take and how much it will cost.

A project is often constrained by three dimensions, known as the ‘triple constraint’. The scope of a project refers to what work has to be completed for the project to reach completion state. Time relates to what the project timeline looks like and the cost is related to what budget is available to go forward with the project. The triple constraint is illustrated in the figure below.

Scope goal Time goal

Target Cost goal

Figure 6 The triple constraint (Schwalbe, 2010)

Research defines project management when knowledge, abilities, tools and practices are applied to certain project activities to satisfy the project requirements (Schwalbe, 2010). Specifically, IT project management is the collective name given to the activities involved in which cost, personnel, progress, quality and risk are analysed, managed and controlled so that the completion of the project may be reached within the stipulated time and budget, and quality (Liu et al., 2012).

As research dictates, the development of a software project involves elements including software development processes and project management views (Callegari & Bastos, 2007). By integrating the principles defined in the Project Management

Natasha NV Ferreira 200508700 Page 39 of 213

Book of Knowledge (PMBOK) and software engineering, the two elements will be addressed respectively. PMBOK describes best practices on project management while RUP defines the best practices that should be implemented during software development.

The majority of uncertainty within software development relates to management issues such as resources, project scope and time. Several models have been defined to assist in overcoming such uncertainties.

Some major obstacles that exist in IT project management can often have a negative impact on the project throughput (Liu et al., 2012). These obstacles are listed below: 1. The lack of IT project management personnel 2. Indefinite requirements from customers 3. Obstacles within IT project teams a. Frequent personnel flow b. Lacking cooperative concept c. Inadequate training d. Lacking mechanisms of perfect motivation. 4. The emphasis on technology rather than management by project management 5. The inadequate support received from top management for IT projects 6. Improper communication 7. Political, legal and market variations.

One of the main concepts in project management stated in the PMBOK guide prepared by the Project Management Institute (2013) is a stakeholder. This refers to any organisation or individual that is related to the project in any way. Stakeholders perform certain tasks defined in a number of knowledge areas, which may be supported either by tools or techniques. These tasks in turn produce deliverables.

Natasha NV Ferreira 200508700 Page 40 of 213

According to the material prepared by the International Institute of Business Analysis (2009), managing projects consists of two dimensions: 1. Investment in projects with a significant worthiness 2. Planning, executing and keeping project activities under control in order to achieve business value in the early stages.

Despite the fact that IT projects are well-defined, certain factors may lead to the failure of a project (Pieterse, 2001). These factors can be described as customer involvement, an optimistic attitude towards the success of the project, adaptable project tools, defined criteria for success, and adhering to schedules and budgets. A list on which one can base the determination of project success is noted below. It: • Achieves the defined business commitment • Benefits the owner in an acceptable manner • Satisfies owners, users, stakeholders, project team and supporters’ needs • Meets the objectives to produce capability. The capability is produced accurately according to what was specified, and within the timeline and budget.

By adhering to methods that may influence the factors leading to project success one may result in a higher possibility if the project is actually succeeding. These factors are listed as: • Recurrent customer feedback • Cautious networking techniques • • Organisational structure appropriate to projects • Adequate control procedures • Cooperation and participation of the project team • Commitment to goals, budget and schedules • The enthusiasm of customers • Adaptable project control tools • Demarcated success measures

Natasha NV Ferreira 200508700 Page 41 of 213

• Satisfactory and suitable resources.

3.1.1 IT project lifecycle

From an IT perspective, research suggests that the fundamental law of IT project development is reflected in the IT project lifecycle (Song et al., 2009). This is exposed from the initial analysis phase, design, implementation and testing straight through to operation and maintenance where the implementation is affected to accomplish success.

The IT project lifecycle is composed of the entire process from the initiation to the completion of an IT project. This particular lifecycle may be divided into three periods, namely: 1. Project preparation – part of the decision-making phase a. This is where requirements are analysed. b. The project is defined. c. Feasibility studies are carried out, reported on and reviewed. 2. Project construction – part of the design and implementation phase a. The project is implemented. b. Project testing and acceptance take place. 3. Project operation – part of the operations and maintenance phase a. Project operation and maintenance b. Post-project evaluation.

The significant stages within the IT project lifecycle have a unique influence on achieving the IT project objective. Therefore, by understanding how each phase affects the lifecycle assists with controlling certain targets set, such as budget and quality for the success of the project. This theory provides the substance for expressing IT industry standards.

Natasha NV Ferreira 200508700 Page 42 of 213

3.2 Release management

Software release management and its significance are often overlooked by many organisations. A software release can be defined as an entirely assembled version of a software product that is ready to be released and used by a specific target audience (Kerkhoff, 2002). The management component of software release describes the techniques required for accumulating the complete release, and having its components defined clearly and exclusively.

Research describes a release as a new version of an evolving product or anything that can usually be related to some sort of intermittent development corresponding to an annual or quarterly timeframe (Günther, n.d.). Release planning is put into practice so that features are assigned to certain releases so that risks, technical, resource and economical restrictions are met. Features may be described as a logical unit of behavior defined by a set of functional requirements. Features are usually categorised according to their priority so that the project benefits are primarily realised.

Release planning is a significant task within any software-specific development project because. Research states that the accuracy of time in releasing software will result in higher market profits and the frequency will minimise cost (Krishnan, 1994).

Upon releasing a software product, the provision of three fragments of information becomes a necessity by the developer, namely (Hoek et al., 1997): 1. Metadata that describes the component 2. The component’s dependencies on other components 3. The component’s source location.

Natasha NV Ferreira 200508700 Page 43 of 213

Release management patterns consist of three key areas known as (Marquardt, 2010): • Purpose of the release o Functional release o Patch release o Service pack o Test release. • Release identification o Technical release identification o Major or minor version number o Marketing name. • Distribution of the release o Pull distribution o Push distribution o Embedded distribution o Version software.

3.2.1 Release management methodologies

Many approaches can be applied to manage releases and each is applicable to a certain IT project. The available methodologies that can be applied are categorised according to the approaches they follow (Sassenburg, 2005).

These approaches are known as: • Traditional, better known as ‘sequential‘ • Iterative.

A traditional approach is referred to when each phase of the project lifecycle is executed and accomplished prior to the next phase commencing while an iterative approach involves prototyping with short iterations.

Natasha NV Ferreira 200508700 Page 44 of 213

The table below illustrates the different types of methodologies, frameworks and standards attainable and how they are categorised according to the above- mentioned categories (Ruparelia, 2010).

Table 4 Release management methodologies and frameworks Sequential Approach Methodology/Framework Description B-Model This is an extension of the operation model that is attached to the Waterfall model (Ruparelia, 2010). Development Path ⇒ Inception ⇒ Define requirements ⇒ Design ⇒ Production ⇒ Acceptance Maintenance Cycle " Production " Design " Analysis " Inception " Operation V-Model The left leg of this model represents the development of user requirements through the process of decomposition and definition (Ruparelia, 2010) while the right leg represents the authentication of system components into levels of accomplishment and association.

Natasha NV Ferreira 200508700 Page 45 of 213

Waterfall This model involves the development of software in stages (Ruparelia, 2010): ⇒ Evaluation ⇒ Requirements ⇒ Analysis ⇒ Design ⇒ Development ⇒ Validation With a feedback loop after each phase. Iterative Approach Methodology/Framework Description Agile Development “Release early; release often; listen to your customers” is a well-known philosophy that should be applied to this methodology (Ruparelia, 2010). Agile development is usually broken up into smaller releases and developed according to priority. This strategy minimises the possibility of scope creep. Rapid Application The mechanism of this methodology involves Development (RAD) prototyping (Ruparelia, 2010) where business stakeholders are actively involved, and test cases are developed and unit tests accomplished. This model is use case-driven (Ruparelia, 2010). The (RUP) seven practices summarised within the model are known as: o Iteration development with risk management o Requirement management o Component-based architecture employment o Visual model utilisation o Continuous quality verification o Change control o Utilisation of customisation.

Natasha NV Ferreira 200508700 Page 46 of 213

Extreme Programming With this development approach, development occurs (XP) on an ad-hoc basis (Ruparelia, 2010). There is no initial design stage; the business stakeholder plays the conduit role and defines user-driven requirements. Dynamic Systems This type of development method has a fixed timeframe Development Method and set of resources assigned to it, and adjusts the (DSDM) amount of functionality accordingly (Moe et al., 2010). Research dictates that not only is the focus of this methodology on team activity, but also on achieving the business solution (Dunlap, 2003). DSDM’s core characteristics include: ⇒ Active user involvement ⇒ An empowered team for decision-making ⇒ Frequent releases ⇒ Iterative development based on customer feedback ⇒ Reversible changes ⇒ Initial high-level definition of requirements ⇒ Meeting the business need as the ultimate goal ⇒ Integrated testing ⇒ Collaboration and cooperation that are essential ⇒ The 20%/80% rule " The assumption that 80% of the solution can be developed in 20% of the time necessary to produce the whole solution SCRUM This involves development in short intervals, defined as ‘sprints’ (Ruparelia, 2010) for regular measurements of progress. This methodology should be applied to smaller projects since it is far less process-driven.

Natasha NV Ferreira 200508700 Page 47 of 213

Feature Driven The primary focus areas of this particular methodology Development (FDD) are the client and architecture (Ambler, 2012). The key deliverables of this methodology are known as ‘features’. These serve as inputs into planning. The phases in this process are listed below. ⇒ Develop overall model ⇒ Build a list of features ⇒ Feature-by-feature planning ⇒ Feature-by-feature designing ⇒ Feature-by-feature building. The following practices are applied for delivery (Feature- driven Development, 2006): " Model domain object " Feature development " Taking ownership of component " Feature teams " Inspections " Configuration management " Regular builds " The ability to have progress visibility as well as of the results.

Natasha NV Ferreira 200508700 Page 48 of 213

Projects in a controlled This project management methodology framework was environment (PRINCE2) developed in England. It is the project management methodology adopted by Europe and encompasses the organisation, management and control of projects. It is a process-based approach that includes eight processes for conducting a successful project (Huijbers et al., 2004). These processes include: " Starting up a project " Initiating a project " Directing a project " Controlling each project stage " Managing stage boundaries " Planning " Managing project delivery " Closing a project. PRINCE2 applies focus to four fundamental concepts known as control, quality, planning and lessons learned. ASAP 7 This methodology known as Accelerated SAP, 7th version, provides an inclusive, demonstrated and repeatable methodology to streamline projects (Musil et al., 2009). It contains all previous steps of the ASAP methodology: • Project preparation • Blueprint • Realisation • Final preparation • Go-live support with the inclusion of a ‘Run’ step in the process, which ranges the value chain in its entirety.

Natasha NV Ferreira 200508700 Page 49 of 213

ITIL The ITIL approach to project management incorporates several good practices, such as Six Sigma, ISO 27000 and COBIT (Arraj, 2010). Its service cycle comprises of procedures such as: • Service strategy • Service design • Service transition • Service operation • Continual service improvement.

3.2.1.1 Agile principles

An Agile methodology can be described as the approach to project management that acts as assistance in responding to the unpredictability of building software through incremental and iterative work paces known as ‘sprints’ or ‘stories’ (Jha, 2012).

In agile development the user story of a project can be defined as a high-level definition of a requirement, which contains sufficient information to ensure an accurate effort estimation to be produced by the developers for implementation purposes (Horvath, 2011).

This methodology was developed to cater for the drawback the Waterfall model has, namely it makes the false assumption that project requirements can be identified before any design or coding can commence. From a software development perspective, the Waterfall model is only applicable to existing software systems that may perhaps need the implementation of change requests due to the amount of uncertainty.

Natasha NV Ferreira 200508700 Page 50 of 213

On the other hand, when developing a brand new software product, the Waterfall model would not be the ideal choice since a significant amount of uncertainty exists regarding requirements and user quality expectation. This methodology assesses project direction throughout the developmental lifecycle. The main stages in an agile project are depicted in the diagram below:

Figure 7 Agile methodology stages (IBM, 2009)

Natasha NV Ferreira 200508700 Page 51 of 213

A brief explanation of each stage illustrated in Figure 2 above is provided in Table 2 below:

Table 5 Explanation of agile project stages Define initial requirements The business will define a list of high-level requirements for the product they require. Prepare high-level use cases The project business analyst will engage with the client to get clarity on each requirement defined and thereafter develop the high-level use case, based on the initial requirements defined. High level planning This is the project manager’s responsibility and usually covers the plan until the first prototype has been completed. Begin iteration This stage is when all the teams involved in the project start their planning and the designing phase. Build and unit test The development team will test build and unit test the prototype in this stage. Enhancements can also take place in this stage of the process if the project is not in its first iteration. System test The testing team then tests the prototype - based on their test cases developed in the initial stages. Regression testing may also form part of this stage to ensure that functionality tested in previous iterations remains unchanged. User evaluation Once the prototype passes the system test it moves into a phase where the client representatives evaluate it to ensure it

Natasha NV Ferreira 200508700 Page 52 of 213

aligns with the defined requirements and completed use cases. Additional requirements may be defined for the project at this point. A decision point – client If the client requires more changes the responsibility project will find itself in another iteration. If the client is satisfied with the project in the user evaluation phase, the product/project may then proceed to a final round of systems testing. Refine use case or requirements Requirements and user cases would have to be refined if the client proposes any changes to the product. The development and testing teams would similarly have to refine their designs and test plans. Final system test Once the client approves the prototype as the final product, a final system integration test may be required to ensure integration of the product and client environment. Product release Once the final system integration test has been completed and approved, the product is ready to be deployed in the client’s environment. Training and user manuals may be required for the wider audience.

The Agile development methods differ from those of plan-based methods in the sense that plan-based methods make the plan itself the central figure, whereas Agile methods primarily focus on the customer (Lehman, 2011). While there is value in the concepts on the right hand side, which portray plan-based software development the concepts on the left hand side should be valued even more. It is all about preferences and not alternatives. The

Natasha NV Ferreira 200508700 Page 53 of 213

Agile Manifesto defines the following four values for Agile software development depicted in the figure below:

Figure 8 Agile manifesto values (IBM, 2011)

The diagram can conclude the following descriptive meanings for ease of understanding of these values: • The individuals involved in the project and the way they communicate are always preferable over tools and/or methodologies. It is teams of people that result in a system being built. These people adapt easily to change and can work together effectively. Tools or processes, on the other hand, cannot adapt to change or advance independently. • Functional software will always be the customer’s preference over particular bureaucracy. Instead of documentation that describes what has been built, the Agile methodology leans more towards producing the actual software rapidly as well as delivering it as an effective product. • Emphasis should be placed on rather servicing customers with

Natasha NV Ferreira 200508700 Page 54 of 213

quality products than continuously debating and defining contracts. The product should be right for the right people. It has to meet the customer’s expectation. Working closely with the customer also results in adapting to change easily. Similarly, a contract is of importance so that responsibilities are understood but it should not substitute communication. • The ability to remain focused and easily adaptive if certain changes are necessary, this is important to the overall functionality of a project. Change is inevitable; the project plan should always be flexible in order for change to be handled effortlessly.

The Agile methodology includes twelve principles, which have been defined below (Ambler, 2011): 1. Customer satisfaction improvement is done by means of rapid, of useful software. 2. Welcome change in requirements regardless of the stage it is in within the development phase. 3. Frequent delivery of working software (weekly) occurs. Some teams push this principle to its full potential, which leads to . It also provides an ability to deliver a product of exceptional quality that is maintained easily. 4. Close daily engagement with business people and developers takes places. 5. Projects are built around motivated individuals who should be trusted. 6. The most efficient form of communication is face-to-face (co- location). 7. The principle measure of progress is working software. 8. Agile processes promote sustainable development.

Natasha NV Ferreira 200508700 Page 55 of 213

9. There is continuous attention to technical excellence and good design. 10. Ensuring the simplicity in any project is definitely a significant factor. 11. Self-organising teams are essential. 12. Within this process there is a regular adaptation to changing circumstances.

The primary control mechanism for Agile methodologies is customer feedback rather than a plan. Research has proven that this methodology is the most efficient if a new software project needs to be developed, as all the above-mentioned characteristics of such a methodology greatly improve the projects direction as well as the customer morale (Horvath, 2011).

Like any other methodology, Agile consists of a number of advantages and disadvantages (Jha, 2012). See Table 3 below.

Table 6 Agile methodology advantages and disadvantages Advantages Disadvantages 1. Only high -level detail required Smaller planning horizon

2. Early benefit to the Lesser design and documentation user/business 3. Face -to-face communication Needs clear customer vision

4. Less time to market Necessity of experienced senior resources 5. Less cost to customer

6. High quality

7. Enables schedule risk management

Agile teams, however, notice falling behind, since they are producing robust code in iteration cycles and this is followed by lengthy debugging sessions

Natasha NV Ferreira 200508700 Page 56 of 213

after each integration cycle. This becomes problematic because many programmers share their code. Continuous integration (CI) is defined as the process that is adapted by such teams and it involves producing a clean build of the system several times per day (Evans, 2012). Agile teams configure CI to incorporate unit test execution, automated compilation as well as source control integration. The principle of CI is to receive feedback as soon as possible because prompt feedback will result in minimised fixing costs (Evans, 2012).

There are criteria to determine whether a project team is taking a disciplined approach to Agile software development and these include (Ambler, 2011): • Whether the team performs development regression testing • Whether stakeholders are active participants within the project • Whether high-quality working software is produced by the team regularly • Whether the team works with an effective governance framework • Whether the team’s approach imporves through the project.

3.2.1.2 Lean methodologies

These methodologies can be categorised under a certain philosophy, whose objective is to eliminate non-essential and non-beneficial activities in order to achieve customer value maximisation of high quality and continuous improvement (Girdler, n.d).

3.2.1.3 DevOps

The term DevOps refers to the evolving effort that promotes the collaborative working relationship between development and IT operations. This increases the reliability of the working environment (Kim, 2013). These two areas define the value stream between business and the customer.

Natasha NV Ferreira 200508700 Page 57 of 213

The concept is to separate teams by functionality and not necessarily activity. That aims to create an overlap of some sort and move away from silo-based behaviour. The diagram below illustrates how DevOps serves as the integration between three significant areas of a project.

Quality

Development Dev Assurance

(Software Ops (QA)

Engineering) Technology

Operations

Figure 9 DevOps Integration

This approach adds value to business in three different ways and can be described as: • Faster time to market – for example, shorter cycle times and higher deployment rates • Increased quality – for example, reduction of the amount of IT waste and ensuring fewer failures • Increased organisational effectiveness – for example, more time spent on value adding functions rather than waste as well as increased quantity of customer value being delivered.

3.2.1.3(a) Variations between DevOps and other methodologies

DevOps aims to recuperate the trust to the IT organisation as a whole; this is achieved by discarding the concept of areas existing in silos.

Natasha NV Ferreira 200508700 Page 58 of 213

3.2.1.3(aa) DevOps vs. Agile

Practicing Agile, results in high development rates within the IT Operations work stream. The IT Operations work stream is then seen as the bottleneck in that area. Two goals evident in DevOps include providing benefit to the customer and ensuring that the code base is ready for production. However, DevOps’ inherent culture change modifies the flow of work, and local measurements of development and IT operations. DevOps’ culture inherits the concepts of continuous prioritisation, task queues and minimisation of work in progress (WIP) (Hochman, n.d).

The development team is held accountable and owns their deliverables. The production environment is the primary focus with DevOps. From an architectural perspective, the system needs to exist as independent stand-alone services and needs to be constructed in such a way that failures can be endured. Specific tools will also be required for reviews, monitoring, testing, logging as well as deployment and communication purposes.

3.2.1.3(bb) DevOps vs. ITIL

In order to accommodate the fast release pace of DevOps, many areas of the Information Technology Infrastructure Library (ITIL) processes require automation, specifically the release processes. DevOps aims to increase the rate of change through a seamless deployment of code. This rate of change is not intended to disrupt any interdependent reams but rather detect and rectify any issues where necessary. It is at this point that the ITIL disciplines including incident and problem management are then adopted.

Natasha NV Ferreira 200508700 Page 59 of 213

3.2.1.3(b) DevOps principles and patterns

The DevOps principles from which each pattern can be originated are known as ‘The Three Ways’. • The first way emphasises the performance of the entire system opposed to the performance of a specific silo in a specific working area. The focus is maintained in all phases within the project. The phases include initiation, requirement gathering, development, deployment and customer delivery. o Outcomes of applying this principle include: o Always seeking to increase flow o Never passing a known defect to downstream systems. • The second way involves creating right to left feedback loops so that the necessary adjustments are constantly made. o Outcomes of applying this principle include: ! Knowledge sharing ! Customer (internal and external) understanding ! Promptly responding to customers. • The third way aims to create a culture that promotes continuous experimentation and the understanding that, practice makes perfect. o Outcomes of applying this principle include: ! Allocation of improvement time for work ! Rewards for team members who have taken the risks.

The DevOps principles can be categorised into four areas known as: • Extend development into production This area involves the extension of the release function into production and also ensures the code is in fact ready to be deployed into a production environment. • Create production feedback into development

Natasha NV Ferreira 200508700 Page 60 of 213

The creation of a complete timeline of events from development to IT operations is necessary in this area to manage occurring incidents. • Embed development into IT operations This area involves moving development into the production work stream, and assigning some resources to production problem management and cross-training in order to minimise production defects. • Embed IT operations and development This involves the definition of general non-functional requirements that can be utilised in other projects as well as the liaison with IT operation resources and development.

3.2.2 Difficulties with release planning

A common problem that becomes apparent when planning for releases is that planning is done based on experience and does not take essential criteria such as size and complexity into consideration. Such problems result in time and budget overruns. These issues may be avoided if intelligent support is provided and if small increments of the software are released more often. In that way, feedback is provided to stakeholders in the early stages of the project. This means misunderstandings can be detected early on.

Two firm disciplines are inherent to release planning: 1. The management and prioritisation of requirements 2. Software project planning and management.

If one recognises the dissimilarities between the above-mentioned disciplines, understanding release planning will be a lot easier.

On the other hand, a factor of uncertainty resides in the process of release planning due to the following: • Misunderstanding and inaccurate specification of features

Natasha NV Ferreira 200508700 Page 61 of 213

• The involvement of specific stakeholders • The change that occurs related to features and requirements • Project size • Project complexity • Data ambiguity • Data availability • Restrictions • Imprecise goals • Efficiency and effectiveness of release planning • The availability of tool support.

3.2.2.1 ITIL framework

One of the main concerns IT projects encounters, is the lack of alignment between IT and business (Esmaili, et al., 2010). Viewing things from only one paradigm proves to be unsuccessful and will have a negative effect on delivery. One approach that is used in practice to strategically align business and IT is the Information Technology Infrastructure Library (ITIL).

The ITIL framework provides best practice guidelines for application in IT service management organisations (Cartlidge, et al., 2007). There is no restriction in terms of organisation size and specific technology that it adopts. The benefit of the framework is adapted easily, as required. Its main focus resides in ensuring that continual quality of IT delivery is maintained and improved throughout organisational processes from both the perspective of business and of the customer.

There are a number of variations of this framework of which Version 3 is the latest. This version was released and published approximately six years ago. It consists of a set of all-inclusive guidelines used to define, design, implement

Natasha NV Ferreira 200508700 Page 62 of 213

and maintain management processes for IT services from both a people’s and a systems perspective.

3.2.2.2 Issues in IT environments

Not only is the alignment of business and IT an existing problem in modern organisations but several other issues are apparent too (Cartlidge et al., 2007). A subset of these issues include: • The implementation of continual improvement • Measuring effectiveness and efficiency of the IT organisation itself • Improving project delivery success • Competitive advantage achievement through IT • Demonstrating appropriate IT governance • Managing continuous change in IT as well as in business.

In summary, the main objective of any IT delivery team is to interact directly with the relevant business team in order to provide valuable IT services.

3.2.2.3 Service management

A service can be defined as a manner of delivering value to customers; this is delivered by expediting results customers aim to accomplish without the ownership of related costs and risks (Cartlidge et al., 2007).

Having defined the above term, one could proceed and extend this definition to define service management. Service management is the enabling factor for a service provider to understand the services he provides. This too is the confirmation that the services add value to the customers. The management discipline can be seen as a set of specialised organisational capabilities to provide value to customers in the form of services.

Natasha NV Ferreira 200508700 Page 63 of 213

Its primary objective is to ensure that the alignment between IT services and business needs exists and that the IT services support these needs (Cartlidge et al., 2007).

The latest version of ITIL is comprised of five core stages of the service lifecycle, as depicted in the diagram below.

Service Strategy

Connual Service Service Design Improvement

Service Service Operaon Transion

Figure 10 Service lifecycle

• Service strategy – initial definition (Cartlidge et al., 2007) This stage involves the exploration of IT management issues (Cervone, 2008). The processes, services and methods are defined that will assist in the success of the organisation in its entirety.

The author of this publication focuses on the following processes (Eikebrokk et al., 2012): ! Financial management ! Service portfolio ! The 7-step improvement process.

Natasha NV Ferreira 200508700 Page 64 of 213

• Service design – the analysis of business requirements (Cartlidge et al., 2007). This stage ensures the most cost-effective services are identified and developed (Cervone, 2008). The focus is on supporting organisational goals and the accuracy of their operation. This volume includes the following management processes (Eikebrokk et al., 2012): ! Service catalogue ! Service level ! Capacity ! Availability ! IT service continuity ! Information security ! Suppliers.

• Service transition – the migration from a testing environment to a live environment (Cartlidge et al., 2007). This stage looks at best practices that make provision for testing, assuring quality, mitigating risks and encouraging responsiveness (Cervone, 2008). The key focus of this publication is managing changes in a ‘business as usual’ environment. The following processes are incorporated in this publication (Eikebrokk et al., 2012): ! Transition planning and support ! Service asset and configuration management ! Change management ! Service validation and testing ! Release and deployment management ! Knowledge management ! Evaluation.

• Service operation – live operation and improvement (Cartlidge et al., 2007).

Natasha NV Ferreira 200508700 Page 65 of 213

This stage entails the details related to supporting and delivering services (Cervone, 2008). This volume incorporates the following processes related to (Eikebrokk et al., 2012): ! Event management ! Incident management ! Problem management ! Access management ! Request fulfillment ! Service desk.

• Continual service improvement - support This stage focuses on encouraging continuous improvement, and making provision for quality and cost measures (Cervone, 2008).

These core publications provide an efficient and professional approach to manage IT services. These enable organisations to deliver appropriate IT services that meet certain business objectives.

3.2.2.4 ITIL framework benefits

There are several benefits of adopting the ITIL framework. These are defined as: • Cost reduction • Productivity improvement • Improved utilisation of skills and experience • Improved delivery and third party service • Improved IT service • Improved customer service.

For the purpose of this research paper, the third publication in the framework will be studied, namely service transition (Arraj, 2010).

Natasha NV Ferreira 200508700 Page 66 of 213

3.2.2.5 Service transition stage

This stage involves the implementation of the service in its entirety. It takes a lot more than just the services application into consideration; it also caters for all possible circumstances of operation (Cartlidge et al., 2007). A function of this stage is to ensure that failure support is available. The functions of this stage are dependent on knowledge and understanding of the following as prerequisites: • Potential business value and target audience • Stakeholder identification • Application and adaption of the previous stage, service design, while making provision for design modifications.

Within this stage a number of key principles need to be adhered to in order for the effective result of new services being implemented. The key principles are: • Knowledge availability of the services, the nature of their outcome and the assurance that the outcome will be delivered • Establishment of a formal policy for implementation of all required changes • Knowledge sharing and process reusability • Adopting a proactive attitude and determining ‘course correction’ requirements • Ensuring involvement of this stage throughout the service lifecycle.

For the purpose of this research paper, the key activity or process within the third service transition stage that will be studied, is the release and deployment management process.

Natasha NV Ferreira 200508700 Page 67 of 213

3.2.2.5(a) Release and deployment management

The purpose of the release and deployment management process is to plan, schedule and control the movement of several releases between a number of test, pre-production and production environments (Banu et al., 2010). This release and deployment management process also establishes an effective use of newly implemented changes (Cartlidge, et al. 2007).

The ITIL framework defines a release as a collection of authorised changes to an IT service (Banu et al., 2010). The contents of a release, whether hardware- or software-related, are managed, tested and deployed as single entities. On the other hand, a release unit is defined as a subset of the service or infrastructure.

Besides the key goal of this process, namely to ensure the integrity of the production environment with the use of change management, the capability of an organisation to develop, compile and reuse will also be enhanced with a minimum effect to business (Banu et al., 2010). In addition to the primary goal, there are several other objectives, namely: • An agreement on defined release policies and deployment plans between customers and stakeholders • To ensure the integrity of constructed release packages (a single release unit or a structured set of release units, including associated users and supporting documentation) and their accurate recordings in the configuration management system • To guarantee that the release packages are tracked, installed and verified accurately or in some cases uninstalled or backed out • To ensure that knowledge-sharing is carried out between the relevant support teams, customers, end users, suppliers and remaining stakeholders • Minimal impact on existing services, customers and operations.

Natasha NV Ferreira 200508700 Page 68 of 213

The release and deployment management process includes benefits, design options and certain activities as defined below:

• The benefits this process offers organisations are that rapid change is delivered with minimum risk and at the most, ideal cost. These changes are then implemented for customer utilisation in support of business ambitions. There are a number of inputs that initiate this process and therefore, necessary for any change to be implemented. A few of the inputs usually required are authorised requests for change, service packages and built models or plans. These inputs produce valuable outputs, such as new modified processes and services, release and deployment plans and a service transition report.

There are a number of factors that need to be considered when deciding on a release approach. These factors include the potential impact of the change; what resources are necessary and what the requirement actually entails. The table below differentiates between the available design options.

Table 7 Design options

Big Bang Approach Phased Approach The change in this approach is The change is first deployed to a deployed to all user areas in one subset of the user base. The same operation. This approach is carried operation is then carried out for the out if consistency is a deciding remaining parts of the user base factor. according to a roll-out plan. Push Approach Pull Approach

Natasha NV Ferreira 200508700 Page 69 of 213

The service component in this This approach is implemented for approach is deployed from the software releases. The software is center and pushed out to target made available at a central location locations. and can be pulled from to the users location at any given time. Automated Manual This approach allows for consistency Monitoring of this approach is vital and repeatability. for impact assessment on manual activities repeating themselves. Such

activities may be error prone and

may be the cause of the release

team slowing down.

• The activities that exist in such process exist because a release policy must be in place before any release units or packages can be deployed or implemented from one environment to another. This formal documentation is the overarching strategy for releases and is considered in one of the earlier stages within the service lifecycle. There are a number of steps that need to be considered, which include: 1. Release planning The plan should include the affected stakeholders, risks, and a scope definition, the responsible teams involved in the release as well as an outline of the communication strategy that will be adopted. 2. Build, test and deployment preparation 3. Build and test 4. Service tests including pilots 5. Deployment planning and preparation 6. Perform transfer - deployment and retirement 7. Deployment verification 8. Early life support

Natasha NV Ferreira 200508700 Page 70 of 213

9. Deployment review and closure

10. Service transition review and closure.

3.2.2.6 Challenges of implementing ITIL

Having mentioned the benefits an organisation inherits from this framework, a number of challenges are also encountered in practice due to the increasing number of services within a supply chain (Bronkhorst et al., n.d.). These challenges are outlined below. • The list of stakeholders impacted by this stage of the ITIL framework is significantly large due to the number of business processes being offered. • Management of many contacts, interfaces, users and programmes becomes significant and overwhelming. • Synchronisation and integration of impacting processes are minimal. • Legacy systems and technology portray inherent differences among each other resulting in unknown dependencies. • The balance between sustaining a stable production environment as well as being responsive to new changes is out of reach. • Similarly, the balance between simplicity and administration is not easy to achieve. • The challenge also lies within creating a standard, simple environment. • Playing the role of business change enabler and the integral component of business change programmes is a challenge within itself. • A leader also needs to be established in order to support the changes. • The necessity of establishing roles and responsibilities at any given timeframe within the process is a significant need. • A culture needs to be developed within the organisation to ensure the collaboration of work.

Natasha NV Ferreira 200508700 Page 71 of 213

• Standard performance measures need to be developed and incorporated. • In order to align business usage, delivery and quality needs to be supported. • Ensuring there is no impact on time and budget, which was defined initially in the service lifecycle is a challenge too. • Another challenge that exists in the understanding of different stakeholder perspectives that emphasise effective risk management. • Similarly, the assessment and understanding of the stability entailed in managing and taking certain risks also proves to be a challenge. • The evaluation of the effectiveness of reporting rather than risk management also proves to be challenging.

3.2.2.7 Risks of implementing ITIL

A baseline assessment should be conducted before any service stage is initiated to assist in identifying the risks that may surface during implementation (Bronkhorst, et al., n.d.). Common risks that become apparent during implementation are: • Fundamental support and operations staff alienation • Additional unplanned costs • Change in accountabilities, responsibilities and practices in existing projects resulting in demotivation • Resistance to change due to perceived establishment • Excessive business costs implied by overly risk-averse plans • Knowledge-sharing with inappropriate stakeholders • Lack of maturity resulting in blame for shortcomings being directed elsewhere • Process isolation caused by poor process integration • Business failure in its entirety due to poor service transition processes.

Natasha NV Ferreira 200508700 Page 72 of 213

Since change is inevitable and business demands are never stable within organisations, the provision for services needs to be aligned closely. The significant objectives of the service transition process are to advance the quality of the service continuously and align this to business specifications that have been outlined in the most cost-effective manner.

3.2.2.8 Preferred organisational structure in an ITIL environment

The structure of an organisation is dependent on the organisational objectives and strategies. It lies within the discretion of the business authorities that the structure is defined and established. This hierarchy depicts different roles and responsibilities within the organisation as well as the various levels of management.

The generic organisational structure view depicted in the figure below should be perceived as scalable, as it was defined for a medium-sized IT organisation in the service support and delivery areas (Wheeldon, 2002). It should be easily adjusted for the specific organisation in context, while also taking the needs of the organisation into consideration.

Certain position labels are used loosely. These should be adapted according to the structure and culture in any specific organisation.

Natasha NV Ferreira 200508700 Page 73 of 213

Problem Manager Technical Support Manager

Service Desk Service Desk Operators/Second Manager Line Support Computer Service Support Operaons Manager Manager Desktop Support Manager Change, Configuraon and IT Service Release Manager Manager Network Support Head of IT Manager Development Manager Test Manager

Service Level Manager

Service Delivery Availability and Manager Capacity Manager

IT Service Connuity Manager

Financial Manager

Figure 11 ITIL organisational structure (Wheeldon, 2002)

In addition to the roles mentioned in the figure above, there are other roles that organisations may choose to incorporate into their structure. These include:

• Strategy manager – This individual reports to the head of IT. His/her main responsibility would be to strategise and ‘think blue sky’. • Account manager/Customer relationship manager – This individual plays the connecting role between business and IT. This role exists in each customer group where large organisations are involved. • IT architect – The IT architect defines and plans the technical infrastructure of the organisation as well as specific standards. • Contracts manager/Procurement manager – This role falls under financial management. This individual serves as the link between procurement and configuration management.

Natasha NV Ferreira 200508700 Page 74 of 213

• Transition to live – This person handles all preparation necessary during the time prior to the go-live date of the application.

For the purpose of this research paper, the organisational structures of the different case studies in context will be studied, analysed and compared in more detail.

3.2.2.9 Production/Operations management

This section serves to define the closely related terms known as production management and operations management, and how they differ from the term project management used throughout this research paper. Stevenson (2012) defines production and operations management as the process whereby the combination and transformation of several resources are performed in order to generate a value-added product/service (Stevenson, 2012). This process is carried out in a controlled manner according to the standards of the organisation.

3.2.2.10 Production management

Independent production management differs from operations management, since it involves the transformation of specific inputs for the generation of a product output. Similar to that of a project, the decision-making process required for the production of these goods is significant to ensure goods are produced accurately according to specifications provided in the correct quantity within the correct schedule and in the most cost-effective manner.

Four objectives of production management can be outlined and are depicted in the diagram below:

Natasha NV Ferreira 200508700 Page 75 of 213

Right Quality Right Time

Right Cost Right Quantity

Figure 12 Production management objectives

1. Right quality The quality of the product is based on whether the product has been produced accurately according to the customer’s needs, and whether its characteristics align with the specified requirements or not. 2. Right quantity This objective is necessary to ensure excess is not produced, since capital will then transform into inventory. On the other hand, a shortage of demand is also not a positive characteristic for the organisation. 3. Right time Effectiveness is derived from the adherence to timelines. Products should be delivered on schedule. 4. Right manufacturing cost The initially defined budget of the product should no be exceeded. The production process should be performed within the cost constraints.

Natasha NV Ferreira 200508700 Page 76 of 213

3.2.2.11 Operations management

Operations within an organisation can be categorised as either manufacturing operations or service operations, as explained previously (Stevenson, 2012). These are categorised, based on its mission within the organisation, the technology with which it engages and the managerial process it involves. Manufacturing operations is the process of ending up with a tangible output such as a product while a service operation is the conversion process yielding in an intangible outcome, such as a performance.

An operation is usually long-term compared to a project, as it involves continuous work (Anglberger et al., 2008). The budget is cyclical, implying the significance of cost management rather than being pre-defined for projects with a permanent allocation of people.

The two objectives that exist in operations management are known as customer service and resource utilisation. • Customer service In operations management the outcome should always meet the customer’s requirements. The outcome should satisfy the customer from a cost and timing perspective too. • Resource utilisation Operating systems need to utilise resources in order to satisfy the customer’s specified requirements successfully. The maximum effect from resources needs to be obtained. The degree of utilisation is measured by the available time being occupied. This management perception incorporates management functions such as planning, organising, controlling, behaviour effectiveness and model utilisation for decision-making processes.

Natasha NV Ferreira 200508700 Page 77 of 213

3.3 Conclusion

Many differences and similarities between different methodologies and frameworks were highlighted and discussed in this chapter.

A release management methodology is applied to a project, which reaches completion once its lifecycle has reached the final phase. Concepts related to project management and software engineering are defined in this chapter in order to put everything discussed in this research paper into perspective.

To highlight the most significant concepts, one should understand that an IT project lifecycle consists of three different periods known as project preparation, project construction and project operation. Release management is the process of assembling the final version of a software product and making it available to the target audience for whom it was developed.

Three sequential methodologies and frameworks are defined as well as ten iterative- type methodologies and frameworks. The most significant iterative methodology discussed above is Agile. Its manifesto can be summarised as: • Individuals and interactions OVER processes and tools • Working software OVER comprehensive documentation • Customer collaboration OVER contract negotiation • Responding to change OVER following a plan.

Even though a number of distinctions exist, it is considered appropriate to point out that many similarities are also visible in terms of the processes or objectives involved. Also, the challenges faced in applying such methodologies are highlighted in this chapter and how these could be overcome. An overall perception of aligning business and IT is also highlighted as a significant challenge in software engineering.

Natasha NV Ferreira 200508700 Page 78 of 213

4. Throughput

The aim of this chapter is to define the concept known as throughput in project management and illustrate why it is significant. Similarly, the methods used in measuring throughput are also discussed in this chapter and the factors involved in improving throughput are also discussed thoroughly. The theory of constraints is also discussed in this chapter as well as its relation it has to throughput.

A global performance measure introduced into project management is throughput, which is defined as “the rate at which the project generates money through sales” (Hirtz et al., 2012). For the purpose of this document, throughput may not necessarily be defined in terms of money but instead delivery of a product or service to a customer. Simply stated, throughput is the amount of material or items passing through a system or process.

4.1 Why is throughput important?

The most significant concept that any business stakeholder of authority should remember when it comes to throughput or productivity is that the measurement thereof is not an end in itself but rather a means to an end (Van Niekerk, 1998). The reason why it is a significant factor in any organisation, large or small, is because it influences the gain of competitive advantage.

Throughput is about the ability of the software application utilising the available resources to the best of its ability in order to produce or serve customer benefit.

There are three components involved in the concept of throughput, namely (Van Niekerk, 1998): • Utilisation • Efficiency • Effectiveness.

Natasha NV Ferreira 200508700 Page 79 of 213

The utilisation factor takes into consideration the extent in which resources are used. The efficiency component is measured in terms of cost and benefit, and the satisfactory relationship thereof while effectiveness, on the other hand, is measured by meeting the customer’s requirements successfully.

There is a relationship between the business models under which the software system is developed as well as the productivity a software methodology can achieve (Malan, 2001). The conclusion is that improved software development productivity will always be the most significant deciding factor in business and development; it has become the main concern for businesses competing globally.

Statistics have illustrated that, in a life sciences industry application, lead times were reduced by an average of 70% reducing delivery time by approximately three weeks. Similarly, throughput increased by 150% with the use of additional resources (Richards et al., 2010).

4.2 Reason for measuring throughput – Lean thinking

Throughput is a significant factor in project management. It is measured because time-to-market is what generates the most revenue and organisational profits. As quoted at a PMI dinner meeting: “Any project worth doing, is worth doing fast and right” (Rodriguez, n.d).

The term lean is an umbrella term for an influential incorporation of methods to amplify customer value while diminishing waste (Rodriguez, n.d.). This leads me to state the goal of lean thinking within a business environment. This management strategy reinforces the effectiveness of project management and creates an unceasing stream delivering customer value, while utilising all resources in the shortest period of time (Bun, n.d.). The goal includes improved quality; reduced surplus, expenditure and lead-time.

Natasha NV Ferreira 200508700 Page 80 of 213

According to Bun, there are several principles in lean project management. These principles are known as eliminating waste; empowerment, respect and integrity; decide later, deliver fast; amplify learning; seeing the whole and managing risk. Eliminating waste requires a shifted mindset – where the required thinking for lean projects is in terms of waste types i.e. waiting, over production, over processing, defects, transport, inventory, material movement and skills. This principle also incorporates a concept known as the baton pass-goal to win the race; this concept involves plan preparation, team building, avoiding rework and practicing to reach perfection. The project should also be perceived as a process or value stream when incorporating this principle. The process should consist of certain activities as inputs in order to achieve specific outputs. The process sets should in turn then be perceived as value streams, where weak links are identified and blockages can then be disregarded. Resulting in robust teams being constructed. With this principle in mind lean project management can be differentiated from other methodologies by the emphasis it has on the opportunity to improve on hand-offs. A strong Work Breakdown Structure should therefore exist.

The second principle; empowerment, respect, integrity includes a responsibility matrix will easily assist keeping track of roles and responsibilities of different stakeholders within the project. This will also aid as a great help for leading of the projects. An important factor in this principle is team building, which Tuckman uses his five-stage model to describe. This model describes the five stages that should be implemented for team development (Schwalbe, 2010). The stages are represented as forming – where not much work is achieved in this initial stage as it purely involves defining the team with introductions held wherever necessary; storming – where the teams have already shared contradictory opinions on the teams operations, this leads to conflict. The third stage in Tuckman’s model is norming – by this stage the team has already reached a steady pace and knows how to work with one another. The team has seen a commonality in working methods where collaboration has overridden the conflict depicted in the storming phase. The next stage is a performing stage where all the team members are now after the same

Natasha NV Ferreira 200508700 Page 81 of 213

goals, a greater sense of loyalty now exists in the team, change is handled in a better way and the more complex tasks are managed better too. The final stage in the team-building model is the adjourning stage which involves breaking the team up at the end of the project that they were all assigned to deliver, once the goals have been achieved successfully the team members move onto other projects – often with other individuals. The second important factor in this principle is giving the team some authority in order for the representation of functional discipline and to produce self directed teams. The implementation of the last principle is also necessary for this principle. This decreases centralised delegating. Plans are produced with a greater sense of detail resulting in more consistent promises being made. Lastly, smaller projects result in smaller impacts with less total disaster and failure costs – continuous improvement is therefore the final important factor in this principle.

The third principle entails pipeline management in order to avoid overloading resources and increasing work in progress. Small commitments are also encouraged to ensure more effective scheduling. The critical chain culture should be incorporated in project management – this lowers the development scheduled considerably. Therefore, decisions should be deferred which will allow for deciding later and faster delivery, leading to the next principle, which promotes amplified learning. Activities should be synchronised; using tools to represent progress reports and to implement knowledge sharing can do this. Team training and the influence of professional development should be promoted.

The fourth principle that encourages seeing the project as a whole includes the need for project chartering – a tool used for stakeholder alignment and allowing everyone involved in the project an understanding of the project. A constant evaluation of the project cycle is required well as portfolio management.

The fifth and final principle is risk management.

Natasha NV Ferreira 200508700 Page 82 of 213

Objectives for lean project management include improved customer satisfaction with shorter throughput times of a maximum of 90 days. It leads to savings in project costs. It also improves continuous organisation, professionalism and quality.

Measurements of throughput should induce parts to do what is good for the system in its entirety. It should also direct management to the specific areas that require their attention (Goldratt, 1997).

Lean’s little law provides the calculation for the lead-time of any process; this

!"# !"#$%& !" !"#$%& !" !"#$%&& is = . This approach to project management is less risky !"# !"#$%&'(") !"#$ and provides simpler coordination of tasks. It also allows for flexibility within project delivery.

4.3 Theory of Constraints and throughput

A constraint is anything that prevents a system from achieving the performance goal a project team has set out to achieve (Groenewald, 2001). Research defines the theory of constraints as a strategy (Goldratt, 1997). It illustrates previously experienced constraints and how these can be managed in some organisations.

Internal and external constraints may exist within organisations. Examples of these are production bottlenecks or a lack of customer orders. Bear in mind that there are managerial constraints as well.

This theory is based on cause-effect logic. It applies an analogy of identifying and managing the weakest link in a chain to ensure overcoming any obstacles in the way of reaching the goal in sight.

There are three factors that usually assist in achieving the defined goal. These are maximising throughput as well as minimising inventory and operating expenses.

Natasha NV Ferreira 200508700 Page 83 of 213

Certain constraints that establish and grow certain organisations can be categorised as general and specific (Groenewald, 2001).

Table 8 Constraints in the establishment and growth of an organisation General Constraints Specific Constraints Insufficient managerial information Management insufficiency and lack of experience Risks not being managed Absence of a business plan Insufficient planning and budget Insufficient knowledge regarding organisation structure

This theory, in the Critical Chain novel (Goldratt, 1997), involves constructing analytical procedures. It is associated with techniques to remove resistance among people (Goldratt, 1997). It is a blend of three differently related discoveries known as a new management philosophy, an introduction of research methods and a broad spectrum of robust applications.

The logical measures, as mentioned above, incorporate cause-effect relationships and determinations based on conflict between necessary conditions. There is no dependency on mathematical algorithms; instead, it has more to do with common sense.

4.4 Principles of the Theory of Constraints

The methodology denoted as the theory of constraint occurs in three distinct parts (Groenewald, 2001), namely problem-solving tools, daily management tools and proven solutions.

The problem-solving tools make up the thinking process of the theory. This part handles significant concepts to consider. These include considerations such as “What change should occur in the organisation?” Such a perception is discussed with stakeholders and needs to be justified accurately (Groenewald, 2001). Secondly,

Natasha NV Ferreira 200508700 Page 84 of 213

“What should be the result or outcome of this change?” is where the perception needs to materialise. Lastly, another question that needs to be considered is “How can change be brought into practice?”

The daily development tools are absorbed from the problem-solving tools discussed above and used for fundamental management skill enhancing (Groenewald, 2001) such as delegation and win-win conflict resolution. The human factor is the most challenging aspect of achieving any goal in a workplace.

The proven solutions part of this theory is derived from applying some of the problem-solving and daily development tools. These have solved a vast range of issues residing in different, yet common business units of any organisation (Groenewald, 2001). Project management happens to be one of the business units it affects.

A concept within the theory of constraints that improves system performance by utilising the system constraint is commonly known as “the five steps of focusing” (Groenewald, 2001). These steps are described as identifying the constraint, which is an obstruction in achieving the goal. Confirming the decision of constraint exploitation is the second step. This step involves making the decision of how to manipulate the constraint in such a way that the system still performs to its best ability. With the decision made in the previous step as the basis, making everything else a subsidiary is the third step. This step involves the alignment of all other significant aspects of the system with the exploited constraint. Promoting the constraint is step 4. Elevating the constraint simply means that something is done in order to increase the competence of the constraint. The last step is to return to step 1 where inactivity is present. This is the step introducing monotony. The initial step is performed again. With the design of satisfaction impediment in mind, self- satisfaction occurs in two forms, namely: the assurance that the problem has been solved before and there is not need to re-visit it and that environmental change is avoidable.

Natasha NV Ferreira 200508700 Page 85 of 213

4.5 Throughput measurement

Software cost is not necessarily referred to monetary value but instead it refers to time and effort required to complete a project (Ladeira, 2002). Software cost is therefore in some way or another related to project throughput. Since the number of initiatives completed in a certain release is a significant value and project stakeholders often aim to increase this value. In certain projects, the concept of estimation is introduced in order to understand how many initiatives for example can be delivered in a particular release. Estimation is often defined by incorporating the size of the project, its complexity and risk factors into consideration as depicted in the diagram below.

Definition Capability

Estimates - Schedule - Effort Project - Costs Project Size Risk Factors Complexity

Figure 13 Estimation principle (Ladeira, 2002)

4.5.1 Use case points (UCP)

This model is a renowned technique for estimating the cost of a project, since use cases provide the functional capacity of a project (Clemmons, 2006). This particular model is categorised into three types of measurements (Ashman, 2004), namely scheduled measurements including cost and resource approximations. Unscheduled measurements encompass any unexpected changes to the project, whether it refers to requirements or scope creep. Time refers to trend and different measurements for comparative purposes.

Natasha NV Ferreira 200508700 Page 86 of 213

Research has shown that the time a project takes for completion is affected by many factors such as the number of steps needed in order to reach completion of use case(s). Similarly, the amount of actors involved to achieve the projects goal is also a deciding factor of the duration of a project. The projects complexity and whether technical requirements – such as security, concurrency and performance, exist within a particular use case. Lastly the environmental factors relating to development teams knowledge and experience also impact delivery time (Clemmons, 2006).

The use case points model estimates the effort in man-hours necessary to complete a use case for a particular initiative. The UCP equation consists of three variables, the first is known as unadjusted use case points (UUCP) which is based on the total number of activities in all the use cases, as well as the combined complexity if the actors in the use cases. Actors in this context specify a role played by a user or another system that interacts with the subject, for example exchanging signals and data. The use cases are weighed according to three categories – simple, average and complex. The second is the technical complexity factor (TCF), which is evaluated by the development team; the team assigns values against a professed scale of complexity. Lastly the environmental complexity factor (ECF) is also evaluated by the development team and is assigned a value based on the alleged impact the team’s knowledge and experience will have on the project.

These variables are calculated against weighted and subjective values as well as constraining constants. The equation represented in hours can be defined as UCP = UUCP * TCF * ECF * productivity factor.

The productivity factor, as defined by Clemmons, takes the quotient of the required development man-hours per use case point.

Natasha NV Ferreira 200508700 Page 87 of 213

The conversion involving use case points and development hours can often lead to inaccuracy. A minor adjustment applied to the environmental complexity factor may impact the overall estimate significantly.

4.5.2 Function points

The Software Development Cost Estimating Guide Book states that this method estimated the total size of a software project instead of how it is developed and implemented. This type of metric is independent on technology and has the ability to estimate, manage projects, gather requirements and quantify quality (Ladeira, 2002). Although it is communicated that this estimation model has its limitations, many use it since measuring effort against functionality instead of physical size will result in a more accurate estimate (Rao et al., 2008). This model analyses the classes or interaction diagrams in UML to provide estimates. The semantic link that may exist between any two diagrams, be it a sequence diagram and a use case, can be typically categorised according to their representations, static or dynamic, namely structural and behavioural.

UML relationships can be categorised in four groups known as association, dependency, generalisation and realisation. This is how the function points can be measured from the points of relationships.

Estimation in software engineering is more of an art than a science (Ladeira, 2002). Research has demonstrated that any organisation applying his particular metric benefits by enhancing project estimation, clarity of the project, maintaining productivity, managing change and collecting user requirements.

Natasha NV Ferreira 200508700 Page 88 of 213

4.5.3 Source lines of code (SLOC)

One of the most popular size estimation methods involves counting of source lines of code. This includes all executable lines of code; for example, deliverable job control language (JCL), data typing and input/output format statements (Ladeira, 2002). The Software Development Cost Estimating Guide Book defines a SLOC as a software statement that is designed, documented and tested. This may include new, modified, deleted or reused code.

This methodology has been designed to make size-prediction in software engineering easy. One must always view software as entropy, as Norman suggests in the Software Development Cost Estimating Guide Book, since it is difficult to grasp, has no weight and always increases which leads to the reasoning behind cost estimations in software engineering as being significant.

4.5.4 Factory points

Adopting similar principles used to derive the cost estimation processes, such as function points (FPs) and source lines of code (SLOC), the case study to which reference is made throughout this research introduced a formal process that will be used to measure functionality necessary for production delivery (Mann, 2012).

In any program, the primary goal or objective would be to increase throughout for production delivery, assuming the functionality delivered has an acceptable degree of quality.

The proposed process to utilise for this purpose is said to provide a reasonable level of accuracy. The target audience of such a process is any stakeholder, i.e. business analysts, testers and even developers seeking to complete some sort of deliverable within the project to acquire a certain level of skill and expertise.

Natasha NV Ferreira 200508700 Page 89 of 213

Initially, size is determined by effort but then the stakeholders are independent resulting in size predicting effort.

4.5.4.1 The estimation model

Taking the SDLC into consideration, this model will be discussed with each of the SDLC stages in context. • Firstly looking at the estimation model from an analysis perspective: The initial stage of the factory points estimation model, as discussed above, has been categorised based on the existence of the use cases and the effort required for altering them. The size is therefore scaled according to the simplicity of the use case and whether it only requires modification or if a new use case has to be created. Nothing in that context exists yet. This particular type of estimation is specific to the business analyst assigned to the particular project. The number of days to complete a specific use case is dependent on whether the use case is already in existence or not as well as the complexity thereof. Based on that, the number of days is calculated and then multiplied by 6 (i.e. effort *6) in order to determine the cost or size of the sub-task. • Secondly, studying the model from a development estimation perspective. o This particular criterion is specific to the development and testing teams assigned to a particular initiative. Similarly, it involves a rating mechanism based on the complexity of the specific deliverables of the two teams. Another set of criteria that is taken into consideration based on this estimation model, are the priority factor and the risk factor. Each factor- specific rating is assigned a certain score that is incorporated in the estimation.

Natasha NV Ferreira 200508700 Page 90 of 213

o After every estimated cost value that is submitted, each value is assigned a particular status, which is also evaluated against certain criteria. o This criteria rating also depends on the stage within the software development lifecycle in which it occurs. For example, is in the stage of high level planning or in production. • Thirdly, the model from the perspective of architecture sizing: o This particular section will be devoted to discussing the model that was designed specifically for the architects assigned to a software project. o The criteria in this particular model are specific to certain stories within a project. Stories are applicable to project that apply the Agile approach to release management, which will be discussed in detail in advancing chapters within this dissertation. o The total architectural effort required is based on the effort required by the business analysis, development and testing teams. The sum thereof will result in the architectural effort. Thereafter the architectural size of the story will be calculated by multiplying the development effort by 6 to provide an equivalent to factory point opportunity cost rating used for project and capacity planning. o The priority and risk factors are then selected, based on demand management or business provision. The priority risk score is the calculated by multiplying both these scores. Based on all this information the respective total effort magnitudes are then displayed. A similar approach may be applied to determine the enablement and defect effort. • Lastly, examining the model from the perspective of functional sizing: o As mentioned in previous sections of this chapter, a sizing model was designed for each significant stage within the software development lifecycle. This particular section will

Natasha NV Ferreira 200508700 Page 91 of 213

devote the discussion to the model used for the business analysts in the analysis phase. o In addition to the criteria referred to in the earlier sections of this chapter, the functional-specific model was customised further. It consists of the following metrics for cost estimation purposes: ! Sizing criteria This considers the number of user interfaces impacted as well as things such as integration points, technicality, impacted entities and the supporting documentation required. Once all the relevant size ratings are captured, a weighted average size score is calculated, based on user selected ratings as well as the respective criteria ratings. Similarly, a suggested complexity value will be determined, based on the weighted average size score. ! Risk rating Similarly, risk criteria are categorised according to the clarity and stability of requirements as well as the skill certain stakeholders who are directly involved in the project acquire. In addition to the expertise, the availability of such experts is also taken into consideration.

4.6 Improving throughput

There are a number of principles and concepts that promote throughput and productivity in information technology (Edgett & Cooper, 2008). Some of these entail building in the voice of the customer, applying a more holistic approach to product innovation, relying on spiral rather than linear development, metric generation,

Natasha NV Ferreira 200508700 Page 92 of 213

team accountability and continuous improvement. Lean methodologies are also adopted to achieve the goal of increased productivity; this is applied in order to remove waste and development more of a flexible, adaptable and scalable process, which is more open to the environment.

4.6.1 Six Sigma

Research suggests that several processes may be applied to certain projects in order to improve performance (Echie & Sheu, 2005). Six Sigma is a methodology that is used to improve business processes by which sigma represents a statistical measure of variability in the process.

The term sigma (σ) means “standard deviation” (Schwalbe, 2010). Standard deviation measures the amount of variation that occurs in a distribution of data. The larger the sigma, the greater the irregularity. This particular methodology involves the attainment of knowledge in order to achieve products that are superior, prompter and inexpensive. Literature has defined Six Sigma as a system inclusive and adaptable enough to accomplish, endure and expand business success (Schwalbe, 2010).

The way this methodology can be carried out is by means of taking the project processes through five transformational phases, a process known as DMAIC (Schwalbe, 2010): 1. Define Start off by understanding what the customer requires. 2. Measure Determine how the performance of the process may be measured. 3. Analyse Determine and understand the variables causing quality dissimilarities. 4. Improve Identify and apply methods to eliminate defect origins.

Natasha NV Ferreira 200508700 Page 93 of 213

5. Control Maintain improvement.

4.6.2 Critical Chain approach

One must remember that there are several paths within a project where, if each starts at its earliest date, the level of management will be quite complex (Goldratt, 1997). The project manager will tend to lose focus and the project will overrun substantially.

Research has shown that organisations have at least one constraint preventing them from accomplishing the goals set by executives. A certain methodology has been developed to recognise and optimise such constraints. This is referred to as the theory of constraints (see discussion at 4.4 above). It is about change and how best to affect change. It introduces three performance measures, namely throughput, inventory and operating expense (Ehie & Sheu, 2005).

The theory of constraints consists of five focusing steps: 1. Identify systems constraint(s). 2. Make a decision based on how constraint(s) may be manipulated. 3. Make everything else subordinate to the above decision. 4. Evaluate the systems constraint(s). 5. If a constraint has been broken, revert to step 1.

A methodology that applies the theory mentioned above is known as the critical chain methodology (Cohen et al., 2004). Its aim revolves around developing a sound schedule to avoid project overruns. By supplying project managers with an experimental framework and guidelines on how to plan, it leaves the bulk of the matter in the hands of the user to complete the details.

Natasha NV Ferreira 200508700 Page 94 of 213

The critical path determines when the project will be completed. It suggests that any delay on this path will result in a delay on the project as a whole (Goldratt, 1997). As Goldratt says: “Concentrating on everything is synonymous with not concentrating at all.”

The following are the steps one can follow when the critical chain methodology is applied to a single project environment: 1. Reduce activity durations. Eliminating safety margins will result in the above step. 2. Identify the critical chain. This is a sequence of activities defining the project duration. 3. Create a project buffer. This buffer is eliminated in step one and moved to the end of the critical chain. It is used to protect the deliverable due date against the variations in the critical chain activities. 4. Create feeding buffers. These are added to the end of a non-critical activity chain; therefore, protecting the critical chain activities. 5. Control. By monitoring the buffers one has a fairly good idea of the project status.

On the other hand, in a multiple project environment the following steps should be followed: 1. Treat each project as a single project. Apply the above steps defined for single projects to each project. 2. Vary projects according to the bottleneck resource. Identify the most constraining resource. Release projects sequentially so there is no idle time. 3. Control.

Research has clearly stipulated that the two concepts mentioned above, namely the theory of constraints and the critical chain methodology, can complement

Natasha NV Ferreira 200508700 Page 95 of 213

each other. The theory of constraints provides statistical tools and procedures to apply changes, while the critical chain methodology could serve as the framework.

4.7 Conclusion

The findings in this chapter are related to a very significant concept that will be applied to this research paper to reach a valid conclusion for the purpose of this study. In order to answer the research questions related to throughput, one must understand what the term means.

Throughput has been defined as the rate at which a project generates value. In this context, an IT project specifically. This concept is quite significant since it promotes competitive advantage. It is important to measure throughput to understand time- to-market because it lead to a positive advantage if an organisation can satisfy its customer’s needs within a short period of time.

Lean thinking should be applied in the elaboration of why throughput should be measured. In summary, lean thinking is the improvement of quality with reduced surplus, expenditure and lead-time. This concept is known for: • Eliminating waste • Empowerment, respect and integrity • Deciding later and delivering fast • Amplifying learning • Seeing the whole • Managing risk.

The theory of constraints is another applied methodology that should be considered to manage any constraints that prevent a software product or system from achieving a set out performance goal. A constraint can be categorised as generic or specific, such as unmanaged risks or no business plan.

Natasha NV Ferreira 200508700 Page 96 of 213

The measurement of throughput is equally important in a study like this one. Many methods that aim to do just that have been discussed in this chapter. The commonality of such methods is that they take the proportion of effort and complexity involved in achieving such results. These attributes have to be known in order to define how long it will take to complete a certain project. Therefore, it will be easy to understand how much can be delivered in a release.

Natasha NV Ferreira 200508700 Page 97 of 213

5. Dissertation layout

5.1 Introduction

The following chapter intends providing some indication of how the proceeding chapters from this point forward will be structured and the specific information one can expect reading this research paper.

The particular approach that will be used to resolve the research questions articulated earlier in this paper has been stipulated as the case study research approach. The specific case studies selected for the purpose of this research paper will be introduced. Adopting the interviewing methodology and applying it to specific stakeholders within the selected case studies will gather the information.

5.2 Outlining significant concepts

Throughout this research paper several IT project management and software engineering theories that refer to release management are addressed. These significant concepts are adopted in one or another or perhaps many of the case studies that have been chosen for the purpose of this research paper.

Two of the concepts are outlined and defined at high-level in the subsections below.

5.2.1 Systems Development Lifecycle (SDLC)

The well-known methodology is often adapted when technological projects are aimed for development (Soriano, 2013). This approach is essentially a succession of phases that all need to be conceded from inception right to the point when the needs of the customer or business are satisfied. The diagram below depicts one of the variations of the lifecycle that is adapted to IT projects.

Natasha NV Ferreira 200508700 Page 98 of 213

Build and System Business Planning Analysis Design Test Implementaon Soluon Needs Stage Stage Stage Setup Stage Stage

Figure 14 Variation of the SDLC (Soriano, 2013)

Something that should always be kept in mind regarding methodologies is that they do not aim to be creeds, which need to be carried out as stipulated, phase by phase. Instead, they should be adopted as guidelines and adhered to where their application is necessary.

5.2.2 Release management

Another concept that is related to software is known as software release management. It dictates what the processes consist of in order to release working software into production in an orderly and enhanced manner (Smith, 2002). It involves software planning, building, testing, deployment and versioning. It considers the “how” of getting software into production.

A release methodology that is put into practice is the Agile methodology. Its highest priority is customer satisfaction through continuous beneficial software (IBM, 2009). Change requirements are welcomed to ensure harnessing for competitive advantage. The primary measure of progress in this methodology is working software.

Natasha NV Ferreira 200508700 Page 99 of 213

5.3 Case studies

A case study can be defined as an instance of something analysed in order to illustrate a principle or thesis; it is a record of research. In this context, it is utilised to answer the defined research questions.

The three projects or programmes that have been selected as the case studies for this research paper are defined and outlined below. The case studies have been categorised according to the size of the projects; i.e., how many resources are contained in the project team as well as the complexity of the relevant project, namely how many integration points the project contains.

5.3.1 Case Study 1 – Small project

Business Connect can be defined as a secure, automated and integrated delivery solution between a customer’s enterprise resource planning (ERP) system and the systems within the Standard Bank Group in South Africa and beyond. This allows the customer to transact directly with Standard Banks banking services (Brochure, 2012).

This team is a fairly small professional one consisting of approximately 17 resources. Thus far in 2013 from January to September, the programme has already delivered an average of 11 initiatives successfully in the programme.

5.3.1.1 Interviewees

The stakeholders interviewed in this programme involved the Solutions Delivery Manager, and the Programme Manager. Their insights into the way in which releases are managed in the project will be analysed and documented.

Natasha NV Ferreira 200508700 Page 100 of 213

A list of the interview questions that have been covered is attached as Appendix A at the end of this research paper. .

5.3.2 Case Study 2 – Medium to large project

A particular project is this case study. It is a system in the Standard Bank corporate and investment banking’s (CIB) Internet banking facility for corporate and specialised clients. Its aim is to have customers in and around Africa perform their corporate banking activities. By the end of 2013 the service will be available in 18 countries. These banking activities involve cross-borders and cross- currencies online and in real-time for multinational corporate entities (Vermeulen, 2012).

With the aid of local and international resources, the project consists of approximately 186 resources. Throughput in this particular project is measured by means of factory points. In 2012 the project delivered 13 708 factory points and in 2013 an estimated 23 445 factory points. This programme delivers an average of 10 to 15 initiatives in one release. These statistics remain true for 2013.

5.3.2.1 Interviewees

The stakeholders interviewed in this programme involved the End-to-End Project Manager, a Project Manager, the Programme Architect, the former Delivery Manager, the Process Improvement and Change Manager, as well as the Programme Technical Lead. Their insights into the way in which releases are managed in the project will be analysed and documented.

A list of the interview questions that have been covered is attached as Appendix A at the end of this research paper.

Natasha NV Ferreira 200508700 Page 101 of 213

5.3.3 Case Study 3 – Larger than large project

The systems, applications and products in data processing (SAP) solution perspective for banking will aim to provide the transactional banking functionality of producing banking products and managing customer interaction (Schlebusch, 2011).

Operations include customer relationship management, customer information, account origination, deposits; loans, leasing, payments engine, collaterals, syndications and master contract management. This project is worth millions and consists of approximately 1 200 resources.

5.3.3.1 Interviewees

The stakeholders interviewed in this programme involved the Release Executive (Head of Business Release) Delivery Manager, Programme Manager, Project Manager and the Project Architect/Technical Lead. Their insights into the way in which releases are managed in the project will be analysed and documented.

A list of the interview questions that have been covered is attached as Appendix A at the end of this research paper.

5.3.4 Case Study 4 – Organisational release management

Release management will be analysed from a business as well as an organisational, high-level perspective. The department in which these programmes reside was studied as an overall case study. Several executive stakeholders were interviewed to retrieve information from their perspective.

Natasha NV Ferreira 200508700 Page 102 of 213

5.3.4.1 Interviewees

The stakeholders interviewed in this programme involved the Programme Release Manager, the Programmer Manager and the Programme Release Manager. Their insights into the way in which releases are managed in the programme will be analysed and documented.

A list of the interview questions that have been covered is attached as Appendix A at the end of this research paper.

5.4 Research questions

The case studies described above were incorporated into this research paper and lead to three specific research questions. These questions aided in defining the conclusion to the proposed research topic. These questions are highlighted below.

Question one: Will a frequent (minimum of one week) release strategy increase project throughput for all types of projects?

Question two: What type of projects will not benefit from a frequent release strategy as seen from a throughput perspective?

Question three: How can an optimum release management methodology be determined to add advantage to certain project types?

Natasha NV Ferreira 200508700 Page 103 of 213

5.5 Structural view

The proceeding chapters will be categorised on a case-by-case basis, starting with case study 1 through to case study 4. Each of these chapters will be structured in a similar manner: • Project overview • Systems landscape • Project organisational structure • Methodology • Case study feedback.

The chapters that follow aim to provide research findings for the research questions.

5.6 Conclusion

This concludes the chapter providing a structural view of the layout applied in presenting the proceeding chapters of this research paper as well as high-level definitions of significant terms incorporated throughout this study.

The software development lifecycle (SDLC) is a significant concept in this research paper. It has been defined above as a succession of phases that need to be concluded from beginning to end in order to achieve satisfaction from a customer’s perspective. Once the SDLC has reached completion, the release management process will be applied in order to release working software into production.

The case studies selected for this study have been introduced and categorised according to project size: • Case study 1: Small project • Case study 2: Medium to large project • Case study 3: Larger than large project

Natasha NV Ferreira 200508700 Page 104 of 213

• Case study 4: Organisational release management.

Each introduction includes information related to the project, such as its name, the project background, number of resources and the corporate positions used for the purpose of this study.

The scheduled chapters will consist of the research results and findings. They will be structured according to the case study that was studied and analysed. The main components that will be discussed in the proceeding chapters from a case study perspective will include a project overview, systems landscape, project organisational structure, applied methodology within the project and feedback received from the respective case study.

Natasha NV Ferreira 200508700 Page 105 of 213

6. Case Study Number 1 – Small project

This aim of this chapter is to describe the context of the first case study in which data was collected. The project overview will be discussed in detail as well as the size and budget of the project, and whether a business case exists for the project or not. The outcome of the interviews will also be analysed in this chapter.

6.1 Project overview

The financial institution in context required a flexible and integrated channel solution to cater for contrasting file formats available via the upload channel compared to the host-to-host channel integration. This was costly and rather complex.

As mentioned above, at high-level this solution provides a secure integration channel between a customer and the financial institution for transactional purposes.

The list of functionality made available to the client is: • Payments and funds transfer in South Africa and the rest of Africa • Collections in South Africa and other supported countries • Statements and balances • Selected reports • Domestic and multi-country processing of transactions.

Certain risks that involve transacting across borders have been alleviated by this project; this is improved by catering for domestic, cross-currency and foreign transactions. By supporting several file formats, global messaging standards and connectivity mechanisms allow Business Connect to be easily adaptable or customisable to any customer’s financial application.

Natasha NV Ferreira 200508700 Page 106 of 213

As explained above, this particular programme can be seen as an integration channel and therefore handles projects that are related to integration. A number of capabilities in relation to transport and network protocols have been developed as well as file handling functionality. The competence of how a transaction file is transported successfully for processing also forms part of the programmes responsibilities.

The main goal and project base of this program was initially driven by clients, in the sense of building the capability for certain products. This is now moving towards a more product - driven perspective and is apparent in the programmes roadmap.

6.1.1 Project size

Business Connect is an independent interface into any financial system at the customer’s site that operates on a 24 x 7 basis. The team has been downsized since the project commenced. The overall programme’s organisational structure consists of a relationship manager, a Business Implementation team, and a project implementation team. This is structured in a similar manner from a customer’s perspective too.

Over and above the team who initiate the project, there exist several smaller teams responsible for delivery. The teams that form part of the delivery aspect of the project include the Product team, the Information Technology team, Technical Integration team, Client Services and Specialised Units.

The technical integration team is currently made up of approximately 17 people who are responsible for delivery.

Natasha NV Ferreira 200508700 Page 107 of 213

6.1.2 Project budget

The projects strategy in 2010 was particularly channel based and the budget allocated in that year was roughly close to R 10 000 000.00 (Parshotam, 2013). In 2011, on the other hand, there was more of a client focus. The objective was based on client achievement footprint in RSA, emerging markets and globally. From a financial perspective, what was allocated to the project in the year 2011 was approximately R 200 000.00 more than the previous year. In 2012, there was a call for an overall refocus of the programme with an appropriate budget of almost double than the previous year. Lastly, in the current year we are in the assigned programme budget is close to R 5,000,000.

2011$and$earlier Budget'Provision' ≤'R10,000,000.00

2012 Budget'Provision' ≤'R24,000,000.00

2013 Budget'Provision' ≤'R5,000,000.00 Figure 15 Annual Financial Approximates (Parshotam, 2013)

6.1.3 Project business case

Last year, there were close to 200 Business Connect opportunities in the pipeline. Recurring Change the Bank (CtB) budgets have been required in both the previous and the current year. This will be business case-based in 2013 and beyond. An additional CtB budget is to increase the programme capacity. The additional and the requested business-as-usual budgets are necessary for delivery and roll-out to the rest of Africa.

Natasha NV Ferreira 200508700 Page 108 of 213

Below is an illustration of what the benefits the programmes aims to achieve, if not achieving them already.

Client attainment and retention focused

Global Acquirement

Africa settlement and solution driven

Malleable Connectivity

Flexible Formats

Reduced client on- Faster and easier on- boarding cost and effort. boarding.

Business Connect

Focused on client acquisition, innovation and functionality across Market portion and geography skeptical Standard Bank Group Divisions.

Figure 16 Programme Benefits

From a client persepctive, it provides flexible connectivity and file formats. The integration, testing and moving into the production process is also simplified, since only configuration is necessary. Adaptibility is streamlined between the channel and the integrated systems. From a programme or project persepctive, the fleixibility of the connectivity implies that any client can be configured wherever the client may be located. The flexiblity of file formats is catererd by means of enabling a partiuclar file format that handles for both payments and collections.

In previous years, when channel was the primary focus it was defined at a very high level. Succeeding appointments with customers forced a strategy review. Moreover, when translating the strategy into detailed deliverables, it became

Natasha NV Ferreira 200508700 Page 109 of 213

evident that we needed a more comprehensive strategy. Thereafter, the focus became more internal and market-driven demand dictated an analysis of the current approach to ensure that the programme would deliver end-to-end globally while in this current year, facilitating the rest of Africa is impossible due to resource constraints.

6.2 Systems landscape

The diagram below illustrates the systems associated with the particular channel integrated system in context.

Standard'Bank

Payment(or(Collection(instruction

Customer'

Response Payment'Execution Payments(or(Collections Responses Information(Services Statements Information(Services

Gateway ERP'System

Information'Source

Other( Services

Statements

Statement' Warehouse

Other'Service

Figure 17 Business Connect Systems Landscape

The channel can transport any messages, whether they are payment or collection instructions or any other service to relevant systems for processing. The channel can

Natasha NV Ferreira 200508700 Page 110 of 213

also receive statements, responses or other services to be sent back to the customer.

6.3 Project organisational structure

Below is a diagrammatic representation of how this programme is structured organisationally.

The stakeholder highlighted in black is the interviewee for the purpose of this research paper.

Business Systems Analyst(s)

Soluons Delivery Porolio Manager Manager Test Analyst(s)

Technical Lead EDi Specialist

Figure 18 Business Connect Organisational Structure

The software delivery manager’s role in the programme is to deliver software packages end-to-end. With the joint nine years of experience in either field the input received has added a lot of value to my research. The agreement of what should be delivered and what not to deliver as well as by when it should be delivered, is handled by the programme manager. This agreement exists between IT and business stakeholders. Ensuring that what has been promised is delivered is also one of the

Natasha NV Ferreira 200508700 Page 111 of 213

roles a programme manager should play and therefore, he or she should manage the team in its entirety.

6.4 Methodology

As highlighted in the interviews held with this programme’s stakeholders, it can be concluded that a formal governance process at project level is adhered to in an accelerated manner. Initially there was no software development lifecycle even being applied, but this changed towards the end of 2012, and the SDLC was then created and adopted (Parshotam, 2013).

However, from a release perspective, a hybrid approach is adopted that has been introduced to the entire department of which this programme forms a part (Wyngaard, 2013). This involves a hybrid approach with aspects from the Waterfall methodology, Agile and PRINCE2 principles. “This results in an iterative and rapid delivery approach,” as stated by the programme manager in her interview.

The programmes solutions delivery manager continues to justify that it was decided on the approach because of the value it adds and the ease of managing control. Due to past experiences, management learnt that consistent delivery was not possible because delivery was implied by projects specifically and not by release.

6.4.1 Success and failures

Research has shown that some of the successes in applying this particular methodology are noted as (Wyngaard, 2013): • Risk identification occurring earlier in the project lifecycle rather than later • Rectifying of defects, which also occurs earlier and therefore improves the overall process

Natasha NV Ferreira 200508700 Page 112 of 213

• The concept of teams no longer working in isolation, which results in the non-existence of isolation failures. Defining the team is less sporadic.

On the other hand, a specific failure also exists. Which is the overrunning of projects within the programme. This failure, however, may not necessarily be attributed directly to the choice of release methodology but just in some way or another.

6.5 Case study feedback

A number of other significant concepts were absorbed from the interview data. These have been categorised accordingly.

6.5.1 Release frequency

The adopted methodology in this programme implies frequent releases if it is to be considered pure project delivery. However, when defining a release as “taking working code into production”, the interdependency among several teams has an impact on delivery. Even though the programme’s release cycle is a month long, the dependent systems may not be directly aligned (Parshotam, 2013).

The monthly cycles effort is represented in the diagram below.

Natasha NV Ferreira 200508700 Page 113 of 213

Business Connect Release Cycles 12 10 8 6 Days 4 2 0 Analysis Development Tesng User Acceptance Tesng (UAT) and Go-Live

Cycle

Figure 19 Business Connect Release Cycles (Wyngaard, 2013)

The effort has been depicted as five days being assigned to analysis work, ten days to development, ten days to testing and the remainder of the month is used for User Acceptance Testing (UAT) and Go-Live. This is obviously project- complexity dependent. The figures below denote our average effort estimates.

6.5.2 Project delivery risks

The respondents in this project strongly believe that the risks involving assumptions being made have been resolved. This was because one of the benefits of implying the methodology mentioned has resulted in the team working a lot closer together (Wyngaard, 2013). The risks involving quality and timing are on the resolution path, because the team members responsible for delivery in the programme still need to succeed in the ability of successfully breaking up a project into smaller logical components for delivery.

6.5.3 Throughput

If throughput is measured as the amount of working code in production, then in this programme, it has improved significantly as well as the quality thereof since

Natasha NV Ferreira 200508700 Page 114 of 213

defects are identified much sooner in the process. This has resulted in the number of defects identified being a lot less this year, compared to last year.

Therefore, in resolving the first research question, namely Will a frequent release strategy increase project throughput for all types of projects? It can be said that frequent releases increase throughput for this particular project.

The graphical representation below in Figure 20 denotes how many defects have been identified, grouped by status and categorised by type. A total of 253 defects were detected in the period starting from January 2013 to July 2013; i.e., within six months of the year 2013. Figure 21 deduced a total of 1 341 defects for the entire period of 12 months. This is more than double those that have been detected in 2013. Therefore, by making a rough estimation, one can confidently state that by the end of the current year the total will still be fewer than last year’s total.

Figure 20 Defects Grouped by Status 2013 (Wyngaard, 2013)

Natasha NV Ferreira 200508700 Page 115 of 213

Figure 21 Defects Grouped by Status 2012 (Wyngaard, 2013)

If one were to attempt identifying what types of projects would benefit from such release methodology that improves throughput as research question 2 states: What type of projects will not benefit from a frequent release strategy from a throughput perspective?, it would have to be a project with unrelated components and instead, an independent project as a whole. This is not the case though with the technology and architecture available nowadays. Projects usually exist as multiple components.

The argument that was prominently projected in the interview is that frequent release benefits are not necessarily inherited by the methodology as such but rather by the project team and the project manager as well as the team’s ability to handle change (Parshotam, 2013).

Similarly, from an initiative perspective, research has shown that throughput did increase. In the year 2012 from the month of January up until the month of September, the programme delivered an average of seven initiatives while a total average of 11 initiatives were successfully delivered in the programme during those nine months in 2013.

Natasha NV Ferreira 200508700 Page 116 of 213

From past experience – research dictates that, by adopting such methodology allowed the team to deliver approximately 500 business requirements in three months for the specific project that is currently assigned. This resulted in two- weekly cycles with multiple scrum teams. The methodology was adopted in all teams.

6.5.4 Optimum release strategy

This section serves to enquire research question number 3: How can an optimum release management methodology be determined to add advantage to certain project types?

The respondents felt the strategy they had adopted was the best optimum release strategy (Wyngaard, 2013). The level of discipline should just be improved and adhered to in order to ensure the creation of the rhythm of the release concept. The process that should ensure the above, involves the approval and acceptance of the entire team. Since some people adapt a much swifter pace naturally while others find it quite difficult to adapt to, the length of the release depends on the system involved, the project, the stakeholders and the team members.

There are just several attributes lacking, which add to the benefit. These include: • The availability of versioning tools to set up the relevant environments correctly o The building environment o The deployment environment o The testing environment. • The availability of a release management (RM) tool • The availability of a backup process.

Natasha NV Ferreira 200508700 Page 117 of 213

If all these functions could be automated, this would be the ideal situation. A shakedown process should ensure the environment is set up correctly.

6.6 Conclusion

This project has a budget of less than R5 million for the year 2013. It consists of quite a small project team of approximately 17 resources. It is an integration team. Some of its members are also integrated into larger teams in the organisation. The project was put in place as an integration channel to cater for the transaction processing of files transferred from a customer’s system that needed to be processed by the bank.

It can be noted that a hybrid approach is commonly used in this type of programme. It seems to be the most optimal manner of delivering working code into production. The SDLC approach to governance was put into place, while from a release perspective, aspects from the Waterfall and Agile methodologies were adopted with the PRINCE2 framework in mind.

This approach was seen as the most optimal, since the controlling and managing aspects behind it all became easier. It added a substantial amount of value to the programme, as risks and defects were identified and remedied much earlier. The team was much closer and well-structured, thus being able to deliver quality opposed to priorities being jumbled up continuously.

The challenge this programme has encountered is the interdependency it has between various distinctive systems. Even though the release in this IT team is approximately a month, the interdependent systems may not be aligned accurately. The quality and timing risks previously identified are on the mend, as the team members are slowly learning how to adapt the methodologies in practice. They will soon be able to break up a project into smaller logical components successfully. This has definitely increased the throughput of the project.

Natasha NV Ferreira 200508700 Page 118 of 213

From a throughput perspective, it can be noted that this has increased by the number of defects raised throughout the years. In 2013 up until July 2013, a total of 253 defects were raised and for the whole 2012, a total of 1 341 defects were raised. This denotes a significant increase in the quality of work delivered. From an initiative perspective, in 2012 the programme delivered an average of seven initiatives in a 9- month period, while a total average of 11 initiatives in a 9-month period was successfully delivered depicting a positive impact in throughput in 2013.

The only other trials with which the programme has struggled are that the discipline within can indeed improve and should. Automation is another important aspect that respondents felt strongly about. If these aspects were present, it would be beneficial. Tools for release management and versioning for environment (build, deployment and testing) have been set up.

Natasha NV Ferreira 200508700 Page 119 of 213

7. Case Study Number 2 – Medium to large project

The aim of this chapter is to describe the context of the second case study in which data was collected. The project overview will be discussed in detail as well as the size and budget of the project, and whether a business case exists for the project or not. The outcome of the interviews will also be analysed in this chapter.

7.1 Project overview

This project is a single online business channel for the financial institution in context. It provides clients with a single view of the relationships the clients have with the institution’s product offerings across a number of countries. This platform is also a payment gateway into Africa in partnership with banks globally. nBOL (new Business Online) started in 2007 and has been running for six years. The first production releases took place in 2009.

The projects the above programme involves are related to the delivery of software applications. They add any new functionality as well as enhancements to the nBOL application as well as support. nBOL delivers work packages to a wider programme. Each release within nBOL is seen as an independent project. It covers all aspects of the software development lifecycle (SDLC). Each project covers the total SDLC cycle (analysis, development and testing) as the key activities within the project (release). nBOL also makes use of several integration channels so that other Standard Bank systems are integrated to ensure process completion. nBOL is the order management system (OMS) that executes payments, collections and delivers statements for CIB.

The project is made up of two data models that have recently been consolidated. Initially, these were defined as a cash management and a channel management data model respectively, of which the details are described below.

Natasha NV Ferreira 200508700 Page 120 of 213

• Cash management model The cash management model incorporates all financial-specific functionality that deals with the exchange of monetary value components. The most significant functionalities involved in this data model include payments, collections, statements, foreign exchange product and transfers (Vermeulen, 2013).

• Channel management model The channel management model incorporates all the foundation functionalities. These components are the fundamentals necessary for any cash management action can occur. The following components are included in this model: bank and department management, customer and user management, account management, customer limits, credit limits, endorsements/authorisation, pay alerts, message alerts, reporting, user permissions (access paths), billing, user roles, calendar management, currency management, notification setup and credential configuration (Vermeulen, 2013). Most of the components include CRUD functionality, i.e. create, read, update and delete along with ability to search.

7.1.1 Project size

From a resource perspective, the project can be categorised as a large project. nBOL is delivering software functionality to 18 countries in Africa (including Mauritius) as well as Britain (London). The next phases are to deliver the software to Namibia and South Africa. Currently 186 people are working on the nBOL project.

Below is a tabular representation of how many resources are currently assigned to this project. The project has resources assigned locally, on-site and off-site as well as internationally. The table below categorises the resources according to location.

Natasha NV Ferreira 200508700 Page 121 of 213

Table 9 Size of the nBOL project (resource-specific)

7.1.2 Project budget

The project budget for 2011, as per interview respondents, totaled R98 872 000 (Vermeulen, 2013). In 2012, the budget increased by approximately 19,3% and reflected a total of R118 million. On the increase again, the budget for 2013 is R260 million.

Please note the amounts are represented in the South African (ZAR) currency.

7.1.3 Project business case

The project was presented on the basis of a business case. The details will be outlined in this sub-chapter.

The existing legacy system currently offered, known as Business Online, supports the financial institution’s core transactional business in both corporate and investment banking as well as in retail. This application is described as an application that reinforces institutional payments franchises, and supports the institutional client relationship model and several revenue streams.

Currently it has no significant ranking in the competitive market. Therefore, the necessity to replace the existing platform with a single online business channel for the Group aims to be the solution for competitiveness. Its alignment with the

Natasha NV Ferreira 200508700 Page 122 of 213

institution’s initiatives will be visible. These initiatives include: • Integration into Africa • Retail Internet banking • Interdependencies with other initiatives such as: o Core banking replacement o Multi-channel architecture o Bankmaster Namibia.

The case proposed for the change is depicted in the diagram below:

Risk Cost Usability- Functionality Transaction- Monitoring Deployment Complexity- EFT-Simplification Manual- Intervention Run-the-Bank Error-Handling Client-SelfDService Service Reporting New-Products Messaging Billing Guarantees FX Liquidity- Management TX-Solutions TPFA Complexity Time-to-Market Cats-Africa Unsuitable- Utilisation Architecture Multiple-LogDIns Long-Testing- Service Cycles Deployment Key-Person-Risk Connectivity

Competitor- Regional- Technology- Landscape Integration Obolescence

Figure 22 nBOL Business Case (Vermeulen, 2013)

Natasha NV Ferreira 200508700 Page 123 of 213

The main goals are as illustrated in the ‘pull’ section in the figure above: • Competitor landscape • Regional integration • Technology undesirability.

In order to achieve these goals, the following inputs and concepts need to be ‘pushed’ into and/or considered regarding the programme before application.

7.2 Systems landscape

The diagram below depicts the system landscape from an nBOL order management systems (OMS) perspective where certain files or messages are received and sent via another integration layer known as MAX through to in-country core banking systems for processing. An input mechanism for nBOL to receive such a file can be via a customer’s ERP system, as illustrated in Figure 17 (Business Connects System Landscape) or perhaps simply from nBOL’s front-end system to which a customer may have access.

Natasha NV Ferreira 200508700 Page 124 of 213

Figure 23 nBOL's System Landscape (Vermeulen, 2013)

Natasha NV Ferreira 200508700 Page 125 of 213

7.3 Project organisational structure

Below is a high-level, diagrammatic representation of how this programme is structured organisationally. The stakeholders highlighted in black font are the interviewees for the purpose of this research paper.

Delivery Project Manager Management

Soluons Architect

Senior Technical Lead (Overall)

End-to-End Release Project Manager Manager Process, Change and Analyst Analyst Lead Manager

Delivery Test Manager

Infrastructure Manager

Figure 24 nBOL’s Organisational Structure (Vermeulen, 2013)

The end-to-end project manager of the programme is responsible for all deliverables related to nBOL within the formal software development lifecycle (SDLC) as well as looking at the dependency systems integrating with nBOL. His vast number of years’ experience in this role proved to be a worthy stakeholder for knowledge-sharing. This role also has the responsibility of managing various teams that deliver software; i.e., the development, testing, analysis and infrastructure teams.

Natasha NV Ferreira 200508700 Page 126 of 213

The process, change and analyst manager has the responsibility of performing root cause analyses to prevent re-occurrence of project disasters. This person also manages the release planning and change control process. With approximately 15 years’ experience, the integrity of release scope is well-coordinated.

The previous delivery manager was also interviewed to provide another viewpoint. He was involved in line management within the programme of a reasonable team of developers as well as some form of project management tasks, tracking of progress, solving problems and removing any hurdles that surfaced.

7.4 Methodology

The diagram below illustrates how methodologies evolved throughout this programme.

Waterfall( Waterfall( PRINCE2(framework( PRINCE2(framework( Agile Agile((Hybrid) Agile((Hybrid) with(SDLC with(SDLC | | | | | 2009 2010 2011 2012 2013

Figure 25 Methodology Evolutions

Natasha NV Ferreira 200508700 Page 127 of 213

In 2009, the team endeavored to adopt a fully-fledged Agile approach (Webber, 2013). However, according to the technical lead of the project and the solutions architect, this was not all that successful.

Reasons for this were summarised by interview respondents as the lack of team skill where the team did not have efficient skills to adopt the methodology and did not understand some of the significant concepts; lack of management, this was a result of the management layer – from a business perspective, managing the project in its entirety was not visible, project managers did not exist. The lack of buy-in also existed because resources within the team, external to the development area specifically, failed to accommodate the change and apply it. Maturity of the application and skills were necessary and yet absent. Lastly, the team size and complexity was challenging due to managing offshore and onshore resources.

In 2010, the team opted to adopt a Waterfall-Agile hybrid approach with a much stronger emphasis on the Waterfall approach rather than on the Agile one (Dormehl, 2013). This was a light, home-grown methodology that was utilised from a release perspective, as defined by the former delivery manager of the project (Dormehl, 2013). Certain technical stakeholders who continued using certain Agile practices, such as daily stand-ups and storyboards, defined this as a home-grown, light-weight methodology. This application continued for two years until the programme confirmed the decision to rather focus on a PRINCE2 project management framework to ensure extensive coverage of all the SDLC cycles.

The decision of adopting this methodology was influenced by factors known as team size; team buy-in who utilised the methodology as well as their comfort level and amount of knowledge (skill) and understanding; probability of higher delivery; the risk of change and continuous influences and evolution that exist in the team (Hawthorne, 2013). In addition to this, management’s previous experience assisted in the decision since delivering three releases a year resulted in a 6-8 month SDLC cycle and since the transformation in Business Requirement Specifications change, it will therefore be easier to adapt to a shorter cycle, resulting in the probability of changing

Natasha NV Ferreira 200508700 Page 128 of 213

requirements being less. Business often requires frequent releases due to the fact that requirements are frequently changing within a given time frame, this minimises the impact of change if we cater for them in smaller chunks.

In addition to the use of release methodologies, certain processes were implemented in the programme to add benefit in other areas. processes entailed a sizing method - to assist in measuring of throughput; i.e., how much could be delivered in a single release. This model was refined and improved over time and forms a fundamental part of release scoping and management. Secondly, scope control process – for Change Control, this process was implemented to provide management with a single view of what was in scope and ensures the functionality coming in and out of scope was controlled. This was put in place for anything attempting to enter or be removed from scope when a release had already been baselined. Lastly, scope baselining process – which was implemented to ensure that business stakeholders agreed that the correct functionality was being delivered within a release scope and the IT department was confident that what was in scope could be successfully delivered by the agreed and stipulated go-live date.

7.4.1 Success and failures

Two major successes were emphasised for this particular programme. In previous years the notable successes in the programme were that the team managed to always deliver, even though there was a great lack of support from business and senior management compared to what was deserved. Delivery was also always maintained, despite the level of change that continuously had to be incorporated.

Currently the notable success, according to research is that the number of incident production defects is very low (Vermeulen, 2013). Please refer to figure 26 below for information on incidents detected between last year and this year.

Natasha NV Ferreira 200508700 Page 129 of 213

Since April 2011, only three major defects have been discovered in production. This is the result of a team as a whole adhering to a formal process, and testing has a recognised the quality assurance role.

Another success would compare to what had occurred previously with the previous three-releases-per-year delivery cycle. When a requirement was pulled from a release (for whatever reason), it took six to eight months before this requirement could be reintroduced into the next release. Now, with the monthly release cycles, it will be possible to reintroduce such a requirement fairly soon, obviously dependent on the severity of the cause for pulling the requirement from a release, this could be as soon as the subsequent month.

The graphical representation below indicates how the number of defects has decreased from last year to this year. There has been a remarkable improvement in the quality of delivery. Defects have been reduced drastically.

Figure 26 Production Incidents (Vermeulen, 2013)

This diagram illustrates the number of critical defects has significantly decreased from 2012 as well as the number of defects in general. Irrespective of the defect’s category - from 2012 to 2013, including only five months of each year into the

Natasha NV Ferreira 200508700 Page 130 of 213

calculation for fairness’ sake, this has resulted in an imprecise 37,5% decrease in defects in total.

On the other hand, the particular failure was also defined in the programme. The inability of the large team (over 170 people distributed over three continents) reacted quickly to urgent requests without interrupting the delivery of an existing (planned) release. In previous releases, urgent requests always had an impact on the current release, most severely felt within the testing team. This limitation is one of the prime drivers for the new revised monthly release process with a 3- month SDLC cycle. The aim is to be able to react quicker to urgent requests.

7.4.2 Implications of scaling SCRUM in large projects

Even though this particular methodology was originally designed for implementation in small and/or medium organisations, the popularity and rewards it reaps has led to large organisations also trying to adopt the methodology where multiple globally distributed teams are involved (Paasivaara, et al., 2012). Introducing such a variation of the methodology, however, implies a number of challenges. These can be described as inter-team coordination, distribution of work without a defined architecture or properly defined requirements as well as the challenges that are inherent to distributed projects, such as deteriorated communication.

The one practice that SCRUM offers for inter-team coordination is Scrum-of- Scrums (SoS). As a result, the way the agenda is altered, compared to the traditional way of implementing Scrum, purely by adding another question for discussion in the stand-up meetings and shuffling up the other questions a bit more, the items for agenda can be defined as: • What did your team do since the previous meeting that is relevant to some other team?

Natasha NV Ferreira 200508700 Page 131 of 213

• What will your team do by the next meeting that is relevant to other teams? • What obstacles does your team have that affect other teams or require help from them? • Are you about to provide an obstacle for another team, making their delivery difficult?

The frequencies of such stand-up meetings vary and are usually dependent on the participants. Some teams prefer to have short daily meetings while others prefer to set slightly longer meetings with one- or two-day intervals between them (Cohn, 2007). This will give participants time to resolve any identified issues in the meeting, as all parties concerned are gathered at the same time. Issues need to be resolved at that point in time since the implications it might have on other teams are greater.

Management in large organisations tend to combine the RUP methodology with SCRUM and adapt these two. The teams are usually stable, long-term teams that are not geographically placed based on functionality. One of the most significant values of applying such a methodology, highly advisable by experts to be practiced as often as possible, is face-to-face communication that is advisable as often as possible (del Nuevo, et al., 2011). This may be challenging in distributed teams due to differing time zones. This should therefore be handled in other ways such as: meetings through documentation, this is usually handled via an easily accessible medium. Secondly by adopting a liaison approach which allows a designated stakeholder to act as a representative in the multiple meetings that need to be scheduled to satisfy all stakeholders. Lastly, alternating meeting times may also resolve the challenges faced with distributed teams. This is when teams need to compromise.

Despite the complications distributed teams cause methods have been designed to make distributed teams perform on projects. Research advises the following methods to be prepared (Fowler, 2006): each respective site should send

Natasha NV Ferreira 200508700 Page 132 of 213

ambassadors to the other sites; this method makes provision for business context to the offshore team. Another method would be to utilise contact visits in order to build trust and also to no underestimate the culture change from a methodologies- perspective. Test scripts should also be used to assist in requirement understanding and regular builds should be used to get feedback on functionality. In addition to this an iteration-planning meeting should be implemented, that is bespoke for inaccessible sites. Lastly, a significant method that aids in assisting with the challenges that distributed teams involve is the demand for more documents should also be expected.

In conclusion, even though distributed teams will lower organisational costs, the results of SCRUM being implemented in these teams can be summarised as challenging in the sense that, when there are too many contributors with conflicting interests and concerns, the result of adopting such a method is poor, yet somewhat possible.

7.5 Case study feedback

A number of other significant concepts have been absorbed from the interview data and categorised accordingly.

7.5.1 Release frequency

With its initiation in 2007 and having run for six years since, the first production release occurred two years after it had started. From that moment on, the programme delivered quarterly releases with a minimum of three releases a year. At least one release would fail in some way. Reasons for these failures include the independent work streams within the programme – evident since the analyst team does not often play a supportive role from project initiation all the way through to project closeout. Instead once their deliverables have been complete the team

Natasha NV Ferreira 200508700 Page 133 of 213

hands it over and then commences analysis on other initiatives without still providing some sort of support or focus on what has moved into the development space. Another reason for the failure of at least one release was the dependency of teams external to the Transactional Products and Services departments necessary for project delivery, since certain initiatives within the programme require time to be assigned to external teams for additional work on their side to be done in order for the project to be a success and be completed accurately. The required stakeholders, therefore, have to be informed of such initiative in due course for it to be prioritised accordingly, to not delay the project in it’s entirety. Constant follow up needs to be done with all systems or teams involved to ensure risks are raised on time. This had not yet been optimally done in the programme.

It was then noticed by certain stakeholders that more frequent releases were required (Dormhel, 2013). The team had the capability to ensure this is done and it resulted in a major release every 2-3 months with monthly minor releases or production fixes.

This year nBOL is in the process of adopting a monthly release strategy (Vermeulen, 2013). However, due to having already worked in the SDLC, there is a transition period until at least August 2013. This needs to be handled carefully to not encounter the same risk that has been faced in previous years. A great amount of frustration was present. Research shows that delivery was slower because people had to adjust to another methodology, which was still in the process of being tailored (Dormhel, 2013). Multiple distinctive processes were also being added for adherence to the programme, which proved to be unnecessary. There was a huge optimal control factor with too many demands from a reporting and process point of view.

Respondents proved that the approach this year is not purely an Agile approach because the large team structure and project scope cause adaptability to be quite challenging; yet, it is an adaptable framework to apply. It was also stated in an interview that it did not matter whether a project adhered to frequent or

Natasha NV Ferreira 200508700 Page 134 of 213

infrequent releases as long as there was a formal process in place that catered for all the cycles within the SDLC (Vermeulen, 2013). An SDLC cycle in this context lasts for three months (one month for analysis, one month for development and one month for testing). Please see the graphical representation of this effort in the figure below.

nBOL Release Cycles 1,5 1

Month 0,5 0

Cycle

Figure 27 nBOL Release Cycles (Vermeulen, 2013)

7.5.2 Project delivery risks

Even though project management is more rigorous now, the known risk revolves around the change in requirements when a project has already gone live (Mann, 2013). Also, the fact that offshore resources are a commonality within this financial institution, it is difficult to apply the Agile methodology. Therefore, a more formal and rigid framework covering all aspects of the SDLC should be applied.

Delivery is affected in the sense that offshore resources have a limited overall view and the quality of the documentation needs to be extremely high. It is also very challenging to have more than 80 developers working on the same code base in a very limited time span. It is even harder to ensure that different teams, located in different continents, do not impact one another’s work negatively.

Natasha NV Ferreira 200508700 Page 135 of 213

A further and quite substantial challenge lies in the ability of the business enablement team (the business team responsible for delivering the deployed software to the CIB clients) to cover 16 countries every month. There is a real possibility that software components will be deployed into production but disabled, as the enablement team cannot cover all countries every month. External team dependency results in a delay, which is out of the IT department’s control.

7.5.3 Throughput

In previous experiences four major releases were delivered using a formal Waterfall methodology. Small maintenance releases were delivered in those months not earmarked for major releases (Dormehl, 2013). Maintenance releases were based on urgent requirements from business and clients, limited to at most two countries being impacted. Throughput was definitely increased but not as much as it could have been, considering the resource quality. The pressure referring to delivery assisted in climbing the throughput ladder. What may have had an adverse effect on the project’s throughput in its entirety could possibly have been the fact that there were too many managers.

In 2012, the second delivered release had a defined size of 5 691 factory points. In the same year, a “maintenance” team was appointed successfully to handle smaller changes delivered via a monthly minor release (Mann, 2013). Fewer than 2 000 factory points were delivered in this manner.

Adopting a formal and rigid project management process and strictly applying SDLC and PRINCE2 rules have led to an average of 25% per annum increase in delivery. However, this 25% increase is not due only to the process being followed – the fact that team members are becoming more familiar and comfortable with the process has also contributed to the increase in deliverables. Team stability has also contributed. Changing from a 3-release-per-year cycle to a monthly release

Natasha NV Ferreira 200508700 Page 136 of 213

cycle will not increase deliverables. There is actually a real risk that delivery might decrease, as resource contention now becomes a big factor (Vermeulen, 2013). The shorter release cycles place a heavier load on the coordination, management and control aspects of the large team. If the management team is not able to cope with this increased demand for coordination and control, then the delivery rate will slow down.

It is important to notice that the shorter release cycles have not increased nor decreased the workload. This is because scope is not necessarily reduced but rather broken up into manageable portions.

This year, 2013, the team will be delivering 11 releases by adopting a hybrid methodology, including aspects of rapid application development, Agile and Waterfall, but sticking to a formal and controlled project management process throughout as well as the PRINCE2 framework while going through all the SDLC cycles in every release (Vermeulen, 2013).

To try and measure the size of what is delivered per release, the “factory point” metric concept, as discussed above, has been introduced. This is similar to the function point principle, which is widely used in the development world. nBOL has steadily increased its delivery over the last few years. The table below reflects this:

Table 10 Throughput Measurement Evolutions Year Throughput Delivered (Measured in Factory Points)

2010 7 503 factory points delivered

2011 9 054 factory points delivered

2012 13 708 factory points delivered

2013 23 445 factory points estimated for delivery

Natasha NV Ferreira 200508700 Page 137 of 213

It is evident that from 2010-2011 there was a 20.67% improvement in throughput due to the increase in the number of factory points. Similarly, the percentage in throughput from 2011-2012 is depicted as 51.40%, as reflected in the table above, for the same reason. Lastly, the increase so far from 2012 to 2013 reflects a 55.99% improvement.

Research has lead us to confidently state that the release strategy applied within the programme has indeed had an impact on the throughput in delivery. Since, the frequent release strategy that nBOL has chosen to apply has increased the project throughput of the project.

The answer to research question 2 remains ambiguous at this point. This question is related to what type of projects will not benefit from a frequent release strategy from a throughput perspective. In general, any software project will benefit from a frequent release cycle. Since there are far more benefits than disadvantages in adopting a frequent release cycle, management must just ensure that the team is mature enough and able to be geared up to meet that and the cycle is not delivering less per cycle than it should.

Another aspect that has been considered is the challenge involved in attempting to adopt this in larger projects. A significant number of team members would not benefit from frequent releases.

7.5.4 Optimum release strategy

While investigating research question 3: How can an optimum release management methodology be determined to add advantage to certain project types?, the respondents provided the following insight as discussed below.

The approach the team is attempting this year is probably as optimum as we could get on this particular project because team size is an issue on this programme.

Natasha NV Ferreira 200508700 Page 138 of 213

nBOL is quite a large team; therefore, things become a little more challenging. Similarly, localisation is a problem because nBOL has a number of outsourced resources distributed globally. The team is still applying an SDLC process but with a monthly release approach.

In summary, an optimum release strategy in the other respondents’ views entails attributes including very rigidly tying down the scope of the release; allowing the team (from analysis to design) to build and focus on the tied down scope; limiting changes within the scope and build this discipline in business, IT executives and senior management and making smaller releases, more frequent, this is necessary in the case of something not being satisfactory from a business point of view – post design – it will therefore have less impact then and will be fixed sooner. This will in essence allow for the core team to transfer the focus in delivery.

On the other hand, it was noted that, in order to increase throughput by 10-20%, the scope control process, quality steps and sizing model implemented would be beneficial. However, to increase throughput by 50%, the paradigm in its entirety will have to change. More processes, such as review checklists, should be introduced so that things are more controlled and repeatable (Mann, 2013).

7.6 Conclusion

Large projects like this one that have a footprint in several countries within Africa and internationally with almost 200 resources and have been in operation for a number of years often have time to attempt several methodologies to understand which is best- suited for the project.

This project has gone through an evolution of methodologies throughout the years. In 2009 Agile was attempted but failed because of the lack of expertise to adapt it to the size and complexity of the team. Thereafter it was decided in 2010 to add a Waterfall emphasis to the methodology but in 2012 the final decision to adopt a PRINCE2

Natasha NV Ferreira 200508700 Page 139 of 213

framework and a Waterfall methodology was more appropriate for the size and expertise of the team.

The programme has not yet mastered the application of the Agile or SCRUM discipline in this large organisation, which has affected the delivery. Nevertheless, the smaller portions of scope make the management perspective a lot easier. Similarly, since the organisational structure of this project involves a scope release manager, it may be beneficial, as the scope will be rigidly tied down, limiting the changes.

In conclusion: A PRINCE2 framework has been adhered to which has lowered production defects and therefore, remained beneficial for the programme.

The Waterfall release management strategy that has been applied to this project has contributed to an increase in throughput and a decrease in the number of critical defects from 2012 to 2013. This is represented graphically above, in Figure 26. It resulted in an approximate 37,5% decrease in defects. From a delivery perspective, in 2010, only 7 503 factory points were delivered, while a total of 13 708 were delivered in 2012. Throughput has, therefore, definitely increased.

Natasha NV Ferreira 200508700 Page 140 of 213

8. Case Study Number 3 – Larger than large project

The aim of this chapter is to describe the context of the third case study in which data was collected. The project overview will be discussed in detail as well as the size and budget of the project, and whether a business case exists for the project or not. The outcome of the interviews will also be analysed in this chapter.

8.1 Project overview

The “Systems, Applications and Products in Data Processing” (SAP) solution perspective for banking will aim to provide the transactional banking functionality of producing banking products and managing customer interaction (Schlebusch, 2011). Operations include customer relationship management; customer information, account origination; deposits; loans; leasing; payments engine; collaterals; syndications; and master contract management.

SAP banking services were implemented and their functionality is enabled as business releases (BRs), predicted to follow two releases per annum, perhaps until and including 2015 (Schlebusch, 2011). Additional SAP products include process integration (PI) and SAP business partner as a customer relationship management system.

The dual banking situation in South Africa will continue until the full decommissioning of the legacy core banking system.

This programme is divided into three phases known as business releases (BRs) which entail the delivery of functionality, a foundation layer which entails the delivery of foundational components, the so-called non-functional requirements; i.e., environments and infrastructure, and thirdly an enterprise design which entails the content of the business release planning (Spies, 2013).

Natasha NV Ferreira 200508700 Page 141 of 213

The enterprise design has three releases running at any given phase of the project. The foundation track implementations are dependencies to the functional releases but there are foundation releases between functional releases too (Brits, 2013).

Functionally, however, this programme involves account management; account origination, separation and transaction processing. It also involves a large quantity of integration aspects with an enormous impact.

The main goal and project base of this program were proposed to replace the branch accounting core banking system that will be decommissioned (Brits, 2013).

8.1.1 Project size

Since this project also overlaps with several departments within the financial institution this is not in fact a project but rather a journey consisting of several programmes and projects within those.

The significant departments in context are known as personal and business banking (PBB) and corporate and investment banking (CIB) respectively. Previously these were estimated to last for five years. The core banking transformation (CBT) programme team consists of about 1 200 allocated persons to a full release, including the delivery (IT) team, the enablement resources and other external resources from interdependent teams.

This journey exists as a programme within the latter departments, which in some way, reflects the initiatives assigned to PBB. It is, however, a lot smaller than PBB.

Natasha NV Ferreira 200508700 Page 142 of 213

8.1.2 Project budget

This programme is worth approximately R140 million a month within the financial institution and therefore one of the most critical ones that needs to reach completion successfully. Currently, R7 million is budgeted for this programme daily. This is a significant amount to waste and therefore, delivery in this programme is of utmost importance.

8.1.3 Project business case

CBT has a business case for each release and tracks benefits against the business case. In many cases CIB does not have a business case except to ensure “business as usual”.

The cost-effectiveness factor is quite significant within the financial institution. This purely relates to the efficiency an organisation has in generating profits.

For the last two or three years this profitability level has encountered some challenges (Schlebusch, 2011). This was due to the impact of several factors, such as legacy systems, system complexity and increased regulatory complexity.

Many challenges were encountered in previous attempts for change. The term “attempts” was used because these transformation programmes were somewhat unsuccessful. It is these changes that are motivating this innovative “case for change”.

A well-defined vision for the financial institution was expressed as the ”2015 Vision” and certain models have therefore been redefined. This is supported by business unit plans with the CBT programme positioned as a significant enabler influencing this. This vision entails that the PBB department of South Africa will be

Natasha NV Ferreira 200508700 Page 143 of 213

more of a customer-centered organisation with amalgamated and proficient processes, reinforced by a contemporary core banking system (Schlebusch, 2011).

Various external and internal environmental trials draw tension to the system. These include external challenges, which bring about economic pressure, and increasing regulatory complexity and opposition. The internal challenges bring with them complexity with regard to systems, products, organisational design and processes.

The following are the factors motivating the case for change and they could result in the following (Schmittknecht, 2012): • Gradual income growth challenges • Increased complication for customers and staff • Incompetent and complex organisation • Slow in effecting changes • High variation in customer experience.

Certain criteria have been specified, which are responsible for proving successful delivery. The criteria are the business and operating model, the business release road map, effort estimation and management benefits.

8.2 Systems landscape

The figure below illustrates a context diagram for one of the business releases scheduled for the SAP core banking project, specifically BR5. However, this should provide a high level of understanding of with which systems each BR will integrate.

Natasha NV Ferreira 200508700 Page 144 of 213

Figure 28 Context Diagram for a particular Business Release within SAP Core Banking Project (Brits, 2013)

Natasha NV Ferreira 200508700 Page 145 of 213

Since the CBT programme overlaps into two specific departments, namely corporate and investment banking (CIB) and personal and business banking (PBB), the key/legend in the diagram is used to differentiate between which systems reside in which department.

The central data group (CDG) system resides in the CIB. It consists of the customer information file (CIF), which refers to a system. These two departments are integrated via a technical component known as an enterprise service bus (ESB). The customer relationship management (CRM) populates the PBB space.

On the next page is a diagram depicting the association of architectural components in business release 6 specifically.

Natasha NV Ferreira 200508700 Page 146 of 213

Legend: Build new Rework Reuse Not applicable

Offering functions

Asset Management Balance Cash Management Cash Services Collateral Correspondence Credit Card Facility Credit Limits Debtors Finance Disbursement Enabler Fleet Management FOREX

Posting / Settlement Franchise Finance Guarantee By Bank Insurance Invoicing Loyalty Management Merchant Services Money Management Notice Notifications Payment Schedule Pricing Re-invest Nominated Account

Safe Custody Standard Executors Related Parties Rental / Leasing Report on Parties Revolve Services Statements Subsidisation Term Tools and Calculators Transactional Limits Value Transactions Services and Trustees (SET) Offering Offering New channels Customer relationship management features

Mobile channel Mobile acquisition and Community retail Queries and Customer needs Single view of Loan centre Advanced analytics Contact management Leads Campaigns (USSD) service channel channel (CReD) complaints analysis / cross sell customer

High volume processes Conduct fraud Respond to / contact Identify customer / Authenticate Create or update BP Perform customer Perform needs Perform customer risk Demonstrate base Prepare quotation for Select non base Create prospect application Request arbitration customer / prospect prospect customer/ prospect record pre-screening analysis assessment score financial offerings customer features assessment

Manage credit Manage pricing Perform financial Provide account Issue documents and Check conditions Perform offering Assess collateral risk Obtain collateral Value collateral Process final contract Produce enablers Set-up authentication concessions concessions needs analysis access enablers notifications completed fulfillment

Initiate time triggered Process payment Execute CRM Amend customer Perform enabler Perform first contact Manage distribution Identify CRM activities Initiate transaction Receive transaction Post payment Record claim request Process policy claims transactions order activities offering feature administration resolution closures

Resolve escalated Set up future payment Resolve operational Obtain customer debt Perform voluntary Resolve escalated Resolve ombudsman Produce customer Process notice Manage queries Qualify complaint Resolve complaint functional area Process closure instruction queries review details debt review complaint complaints documents complaint Plan, calculate and Manage consolidated Perform portfolio Conduct collections Perform statutory debt Validate and classify Monitor account risk Manage limit Execute collections Manage recoveries measure risk Realise collateral Release collateral Monitor account mail ageing activities review fraud trends provisions

Process Detect fraud Conduct fraud case Conduct forensic Perform security Provide fraud legal Calculate fraud and Perform fraud Execute manual data Manage operational Perform transaction Coordinate fraud case Close fraud case Prepare data clean up proactively administration investigation solution services operational loss recoveries clean up customer and BP data matching

Investigate Write off irreconcilable Conduct fraud case Perform channel Plan promotion Execute promotion Develop segmentation Perform segmentation Review outbound unmatched Prepare for settlement Perform GL updates Distribute leads Track leads transactions analysis balancing activities activities analytical models analytics communication transactional items Business capability build / low volume processes Capacity Operational Long term strategy Perform Planning and Channel planning and Create offerings / Business process Business rules Business activity Establish / manage Establish / manage management and Channel migration Offering migration knowledge development budgeting placement offering design management (BPM) management (BRM) management (BAM) external relationships internal relationships forecasting management Workforce Workforce Contact center IPC / RCC Finance and MIS management / onboarding consolidation design consolidation reporting scheduling

Foundational IT components Business functionality IT components

Business rules Business activity Business process Collateral Credit account style Advanced analytics Application monitoring Bulk payments engine SUP upgrade CIF decommissioning Credit (CDDS) CRM migration management management management management rules

Incentives and Common customer Enterprise wide forms EIM development and Enabler linking / de- CIF decommissioning Post payment Data archiving EIM infrastructure CRM 7 CDQ Debtor finance commissions create engine reporting linking management Multi channel Multi channel Multi channel Real time payments SAP technical GTS ! MRI P2P / UVS Reconciliation engine Loyalty management Migration engine applications applications Product deployment Product migration framework engine upgrade (enablement) (migration) Technology Transaction Canonical messaging SAP HANA Branch accounting SAP cross functions / Security processing Environments Retail forex Stabilisation Collections SAP HANA model (POC) decommissioning solutions architecture

Key initiatives and dependencies (outside of CBT programme)

Base24 (routing Full maintenance Regulatory ECM Companies act Quantum Fraud MyUpdates Data warehouse Finance Maven migration EMV Pricing and billing implementation) leasing (PPI and CPA) PIC Channel migration Online programme Telephony programme Mobile programme C360 programme Loyalty programme programme

Figure 29 Architectural Components integrated in Business Release 6 (Kruger, 2013)

Natasha NV Ferreira 200508700 Page 147 of 213

8.3 Project organisational structure

Each programme has a business executive, business release manager, several programme managers and several project managers as well as an integration manager. There are several outsourced resources within this programme. This is cost-effective within the bank.

Four stakeholders from this programme played a significant role in the data collection process for the research. Firstly, the programme manager who has approximately 20 years’ experience in this field is responsible for assembling projects within the programme. Her primary liaison with direct stakeholders is fundamental to ensure alignment and to manage timelines. The programme manager is also responsible for building a delivery team.

Secondly, the team’s project manager was interviewed to share her expertise gained over a period of 16 years. The primary functions of her position entail leading and directing a team of business analysts, systems analysts, architects, designers, developers, and testers. These resources need to be coordinated to deliver a product in the correct environment.

Thirdly, an architect who defines a solution design and determines where the independent solution designs are aligned translates information technology to business. She has approximately 15 years’ experience in the technical field.

Lastly, the programme delivery manager was interviewed. He has 15 years of experience in the IT environment and his responsibility is executing IT deliverables.

Natasha NV Ferreira 200508700 Page 148 of 213

Below is a diagram depicting the typical organisational structure in the particular business release under investigation, namely BR6.

BR6 Board BRDA Business Release 6 Executive Personal Assistant

Business Executive Change BRM Release Support BRM SAP SPoC (Senior Business User) Management Angela Passalacqua Office Migration

Capability Build

Programme Managers Planning & Initiation Phase

Roll Out Quality Manager Analysis and Solutioning Initiation Programme Project Manager Deployment Dependency Manager ANO Manager

Integration Teams

Business and Functional Integration Leads Process Analysis Project Manager and Business Requirements Lead. Leads and Campaigns Retro-fit Campaigns and Leads

Solution & Process Integration Common Offering and Sell Technical Enablement Enablement Technical Product and Pricing Manager Manager Pricing and Product Fumctional Integration Manager Collections Credit Solution Design Project Manager and Credit Credit AMS Manager Payments Payments Credit Credit AO Manager Integration Manager Manager Integration Service Managers Service Ageing Manager Manager Ageing

Business Integration BR6 Integration Leads AMS Lead.

Organizational Design CIB Manager

Technical Leads Manager SAP Prototypes Project Manager and

Architecture Manager Lead. Manager

AMS Manager

GTI Solution Integration

Project Manager and Test Assurance Lead. EIM / EIW Figure 30 CBT programme organisational structure for Business Release 6 (Kruger, 2013)

8.4 Methodology

As the Programme Manager stated in her interview the programme adopts some PRINCE2 principles at a very low level on most of the projects (Pearson, 2013). PRINCE2 is a standard within the financial institution in context. From a methodology perspective, the programme follows a combined team approach (CTA) methodology – incorporating Agile and Waterfall (Brits, 2013). Another methodology that is adopted in the programme for governance purposes in large projects is known as Managing Successful Projects (MSP) (Kruger, 2013).

Natasha NV Ferreira 200508700 Page 149 of 213

This CTA was adopted because not only does it adhere to the nature of project management logically and to the project manager’s expertise but it is also a standard within the financial institution (Brits, 2013). This methodology also speeds up the delivery momentum within the programme (Kruger, 2013). This decision was also made for risk management to ensure minimal potential client impact.

8.4.1 Success and failures

The successes incorporated in the particular methodology being applied can be summarised as clear planning for the department driving this project, cost reduction, resource commitment and changes within the SAP software that are kept to a minimum in order to ensure a viable upgrade path is always available. Module replacement instead of system replacements (i.e. not a big bang approach) is less risky and high in delivery frequency.

Failures, on the other hand, were noticed because of plenty reuse since lessons- learned are applied from previous phases of the programme. Only one environment, which probably only has a 10% accuracy factor is used opposed to the production environment where confidence levels remain low.

8.4.2 Release frequency

Taking the fact into consideration that the CBT programme was foreseen to run from 2010 to 2015 but may now be extended to 2018, two annual releases are therefore as frequent as they could be (Brits, 2013). A reason for this are that interdependency of other systems is involved in this project. Each one of the annual releases, though, culminates into smaller ones to ensure bug fixes are incorporated. There is only one environment currently called dev1. The cost and support involved for making changes to the legacy system in multiple

Natasha NV Ferreira 200508700 Page 150 of 213

environments are part of the proposal being drafted to enable operations in CIB to allow for this. Several environments are required, since two projects are typically in development and/or in test simultaneously.

The programme is currently in the process of adopting the Environment Provision Programme (EPP) and the Work Package Assembly (WPA) programme. These programmes will definitely imply more frequent releases but they depend on the team’s current maturity level and expertise concerning database configuration and traceability. The programmes currently deliver functionality in a period of 100 000 man-days at a time.

The most releases ever delivered in previous experiences by applying this methodology resulted in rather high stress levels (Spies, 2013). These were monthly releases and therefore, 11 were delivered in a year. This taught the researcher that it could be applied successfully in different areas.

Pearson argues that the most number of releases delivered were approximately four; i.e., quarterly, and incorporated one test cycle involving component integration testing, regression testing, defect testing as well as pre-production testing. All these testing cycles involve all products and product interface testing. The diagram below depicts the cycle graphically. All of the activities up until user acceptance testing should be completed almost two weeks before the respective quarter reaches completion; this includes sign-off.

Natasha NV Ferreira 200508700 Page 151 of 213

SAP (Core Banking) Release Cycles 8 7 6 5 4

Week 3 2 1 0

Cycle

Figure 31 Core Banking Release Cycles (Pearson, 2013)

Each release is estimated and there are typically 80 000 man-days in a release. If the estimates turn out to be more than that, they will break it down into sub- releases of about 80 000 man-days each. It is divided into main areas, namely the foundation, which provides all the technical components that the business releases require, e.g. environments, hardware and upgrades. The second area is enterprise design, which in essence looks at the business requirements and business case. The third area entails the business releases (BRs), which deliver the functionality that business has specified and requires.

8.4.3 Project delivery risks

Most respondents felt that risks surfacing in project delivery with this project are not necessarily due to the methodology applied (Pearson, 2013). The risks are rather due to resources and environments. One of the risks that may be worth documenting is when a particular phase needs to be replanned, scoping and analysis occur in parallel purely because of the lightweight Agile aspects being adopted and the budget of the project, which has almost reached completion.

Natasha NV Ferreira 200508700 Page 152 of 213

8.4.4 Throughput

The measurement of throughput is always a tricky one to conquer. A team would not know whether their productivity is on the incline or not without an estimation tool for throughput measurement. As stated in the interview, there is no comparing factor for determination and therefore, a difficult one to respond to on this programme (Brits, 2013).

As mentioned previously, only about two major releases are delivered annually (Spies, 2013). However, hundreds of projects exist in these releases. There are smaller releases in between that cater for change requests, migrations and bug fixes (Kruger, 2013).

Throughput has definitely increased due to time that is removed from the delivery schedule for handover periods (Kruger, 2013). Within the CBT programme the relevant stakeholders required for each phase in the SDLC work closely together from the inception or analysis phase straight through to testing. Previous experiences dictate that throughput has improved. For example, BR2 was made up of 60 000 man-days and delivered within the specified time, budget, with satisfactory quality and minimal impact to existing functionality within the financial institution. Similarly, BR3 enabled functionality worldwide, also on time and within the specified budget where approximately 4.5 million accounts were migrated.

However, one could look at it from a quality viewpoint. The SDLC methodology has made a positive contribution to quality in the sense that prerequisites are ensured before proceeding to the next phase. Therefore, problems can be identified sooner.

The method gave the team traction but there was definitely room for improvement to address the foreseen issues. This approach aims to confirm that

Natasha NV Ferreira 200508700 Page 153 of 213

a frequent release strategy increase project throughput for all types of projects, as research question 1 dictates.

In order to enquire research question 2, namely What type of projects will not benefit from a frequent release strategy from a throughput perspective?, one should remember that “frequent” could have various connotations. It may imply a different quantity from one project to another. On the one hand, for a huge project that requires enhancements two annual releases would be frequent enough. It would not necessarily benefit from more than two releases per year (Brits, 2013).

This is contradictory to what the Agile methodology defines as “frequent” releases though since the big bang approach has its own risks (Pearson, 2013). Module replacement, on the other hand, instead of system replacements, has minimal risk and requires higher frequency of delivery. Spies argues that she does not believe that scenarios which do not mention that the challenge may be slightly greater in applying a methodology to dependent versus interdependent projects do not exist.

Strong project management theories and experience are key in delivering projects within such a large and complex programme. Reliance on resources in the team to ensure common understanding is also absolutely required to achieve success.

8.4.5 Optimum release strategy

While investigating research question 3: How can an optimum release management methodology be determined to add advantage to certain project types?, the interviewees had the following to say: Based on expertise, the current methodology adapted is the most optimum. The only issue they had revolved

Natasha NV Ferreira 200508700 Page 154 of 213

around implementing multiple and well-defined environments as well as additional testing cycles (Pearson, 2013).

The project should be broken up into smaller modules instead of attempting the big bang theory approach. Many reasons exist for this view (Brits, 2013). The sense of accomplishment is lost if a bigger batch size is applied. The people’s morale is impacted. Rewarding delivery cannot be pursued. There is a need for streamlined paper work and process. Change may involve challenges because of the impact it has on people’s mindsets. This may be a costly exercise. The maturity of resources is significant as well as their expertise.

Over and above the suggested ways to optimise the release strategy, Spies adds the fact that documentation necessity needs to be defined and whether this is required for frequent releases or what else frequency involves.

Reliance on resources in the team to ensure common understanding and knowledge-sharing as well as resilient project management theory and experience is utterly required. These are very important within such a large and complex programme to achieve successful project delivery.

8.5 Conclusion

This core banking transformation (CBT) programme is a large project with a team of approximately 1 200 resources, including the IT delivery and enablement teams as well as several other resources from the other integration teams depicted in the organisational structure above. This programme is quite an expensive one, resulting in an approximate weekly budget of R35 million.

We can therefore conclude that utilising an Agile and Waterfall model in conjunction with each other is the most optimal for this kind of project, often adopted with several PRINCE2 principles. It minimises risk impact and reduces costs with its only

Natasha NV Ferreira 200508700 Page 155 of 213

constraint being the limitation of multiple environments, which lowers confidence levels in stakeholders for delivery.

The programme is also in the process of aligning to two governance frameworks known as the Work Package Assembly (WPA) and Environment Provision Programme (EPP) to encourage frequent releases (Kruger, 2013). The WPA approach adopts the principle of breaking large projects up into manageable functional units known as work packages. These will then result in shorter iterations reflecting higher quality. This will be presented in the next chapter as an optimal approach to adopt (please refer to 10.3).

Increased throughput is depicted within the CBT programme since experience dictates that the previous business releases have been delivered in the specified time, budget and with satisfactory quality with minimal impact to existing functionality within the financial institution. Two annual releases are currently delivered in this project and found to be sufficient.

Based on stakeholder expertise and the standard of the financial institution, this is the optimum at which the project will operate. Breaking the project up into modules allows for a sense of accomplishment. Training in adopting a new methodology is vital since the slight change of stakeholders’ outlook may be the main reason for a project to fail.

Projects with minimal integration into other systems may have a lower impact on the application of this methodology compared to projects that are interdependently focused. This methodology is applied to large projects, such as this one, that is composed of several sub-projects spanning over several departments within the financial institution and made up of approximately 1 200 resources.

Natasha NV Ferreira 200508700 Page 156 of 213

9. Case Study 4 – Organisational release management

This chapter investigates release management from an organisational perspective, and how to optimise release management across disparate programmes, projects and portfolios in an organisation.

9.1 Release management from a organisational perspective

9.1.1 Interviewee

The Solution Assembly and Assurance Manager has approximately 17 years’ experience in the IT environment as a configuration manager (Theron, 2013). A configuration manager is responsible for a subset of the functions that are included in the role of the current Solution Assembly and Assurance Manager. The three areas he manages interdependently are known as: • Delivery planning • Systemic impact assessments The figure below denotes a graphical representation of how cross- component detail is analysed in order to perform an impact analysis at a systemic level. The ‘✗’ in the figure signifies the point at which the particular system is needed for integration with the relevant project. • Solution assembly This area involves the assembly of the system once it has been built to ensure it progresses into the environment for testing and deployment thereafter. “This control and management is handled end-to-end from sunrise to sunset” (Theron, 2013).

Natasha NV Ferreira 200508700 Page 157 of 213

Project&Manager's&View& Project(1 Project(2( Project(3 Project(4 System(1 ✗ ✗ System(2 ✗ System(3 ✗ System(4 ✗ ✗ Release&Manager's&View&

Figure 32 Release Manager’s System View (Theron, 2013)

9.1.2 Project types

The respective stakeholder who has been selected for this interview currently manages a total of 243 projects in different areas; not only within PBB but also in CIB Africa, infrastructure, risk and operations. These include any IT related projects whether they be software, hardware or firmware or anything related to the mainframe, middleware or frontend. A variety of different technology stacks are involved and implemented from an application perspective.

9.1.3 Methodology

There are a number of approaches that have been adopted. The typical methodologies that have been adopted are a combined team and work stream approach involving Agile but no SCRUM principles (Theron, 2013). This methodology was unsuccessful, since the attempt to change deep-rooted mentalities is a challenging task. Therefore, standardisation is not easy to incorporate. In Theron’s view, the Agile approach should be used up to a point in the project delivery cycle. Another is ASAP7, a methodology influenced by Accenture and IBM.

Natasha NV Ferreira 200508700 Page 158 of 213

The financial institution in context attempted a release methodology, which could be defined as a hybrid methodology since it incorporated principles and techniques from various methodologies and frameworks, the SDLC being one of them (Theron, 2013). This resulted in multiple concurrent development teams involved in each stream. Nothing can be done without a specific plan to work from or use case in this scenario. The best way to describe a project, even in the IT space, is by using the analogy of building a house. A house cannot be built without a plan. Similarly, a system cannot be built or designed without a plan.

A three-gate sign-off process with several forums has to ensure that no additional requirements creep into the developmental phase.

9.1.3.1 Methodology frequency

The programme is on the correct path in finding the rhythm of monthly releases (Theron, 2013). What is needed for frequent releases to be successful are plans for teams to progress towards accurate achievement (Theron, 2013). Previously, releases were ad-hoc and the environment was chaotic to work in. A direct alignment between impact assessments and the project plan is also needed.

The decision to implement such methodology surfaced from the definition of a committee known as the project execution committee (PEC). This committee is responsible for the delivery of all projects with the exception of SAP.

The process involves a slight mindset change and is rather bespoke. It is based on several factors. The first is requirement prioritisation because each business unit has a perception of being equally important as the other. Another factor is the requirement or project size of which the implementation calculator provides the outcome. This measurement is calculated as potential

Natasha NV Ferreira 200508700 Page 159 of 213

release units and implemented, based on histories or previous experiences, as it still needs some calibration.

The requirement or project has a status assigned to it, depending on the stage it has reached and defined as per certain criteria. These stages are defined below. If the requirement is registered it forms part of the pipeline and then Plan not committed. Thereafter the requirement may be adjusted to a committed project or requirement. If the project is jeopardised, it or the requirement is moved to the replan phase and reverts to plan not committed. Another status is known as reschedule. It is based on executive override. The process is then concluded with close.

The reason for applying this methodology resulted in predictability introducing several monetary and timeline benefits. Confidence levels in delivery have improved with both IT teams and business being directly aligned. This process also assisted in identifying where the bottlenecks were and helped the team progress rapidly.

9.1.3.2 Methodology application: Success and failures

Failures are inevitable in the nature of project management. The distinct failures that have gone unnoticed in this department relate to the way in which certain stakeholders are not directly aligned in all aspects (Theron, 2013). There may be some terminology clashes that make it difficult for people to understand the importance of having software configuration management and the benefit, which that role adds to an organisation.

Secondly, the development houses were in contention with one another but once combined, the lessons learned entailed regression and rework, which implied a cost impact.

Natasha NV Ferreira 200508700 Page 160 of 213

9.1.4 Project delivery risks

Theron confidently states that no project will exist without any risks. All projects have their individual pros and cons regardless of the methodologies adopted. The matter of the risk boils down to the risk appetite of the risk. This depends on the complexity, size and number of systems the project needs for integration.

Therefore, no risk in this department has been severe enough to put the financial institution in jeopardy (Theron, 2013). All the risks experienced in this environment have been managed well because an appropriate mitigating strategy was put in place that managed the risks well.

9.1.5 Throughput

During the investigation of research question: Will a frequent (minimum of one week) release strategy increase project throughput for all types of projects? The answer to this question has resulted in a positive one for this particular department. Predictability is possible and therefore, the ability to know what is going to happen next assists in productivity increase (Theron, 2013).

Secondly, there will be no particular projects that will not benefit from frequent releases. Not only will projects always draw value from predictability but also from modular delivery (Theron, 2013). This was gathered from the interview to relate to the second research question: What type of projects will not benefit from a frequent release strategy from a throughput perspective? Last year specifically, 95% of the 436 committed projects were delivered successfully. These may not necessarily have been projects but they could also have been some sort of task or request, all at an application level but not monetary level. This is the highest rate as which commitments were met in this programme. Research therefore denotes that there has been an improvement in productivity.

Natasha NV Ferreira 200508700 Page 161 of 213

Previous business releases delivered 60 000 man-days worth of functionality in the specified timeframe and within the correct budget, of which quality was also a positive factor.

9.1.6 Optimal release strategy

While enquiring release question 3: How can an optimum release management methodology be determined to add advantage to certain project types?, the following was deduced: Planning is an activity to whose significance is never fully committed. The project planning process should have sufficient time allocated to complete it successfully. Ample time is necessary for accurate project planning (Theron, 2013). Similar to planning, the development phase also requires plenty of time along with accurate prerequisites before development can commence.

Scope creep is a concept from which many projects cannot escape. With signed off specifications, however, the possibility of scope creep will decrease and rework will be minimised (Theron, 2013). When business requests change they must have the ability to absorb a situation where there is no direct impact on the project plan.

Theron proceeds to state that smaller, more frequent releases are always advantageous to any project. Therefore, a strategy that includes the aim of breaking requirement chunks into smaller modules to work with will be easier to manage and control.

9.2 Release procedure from a division perspective

With the transactional products and services (TPS) division in the corporate and investment banking (CIB) department all systems within this division will at some

Natasha NV Ferreira 200508700 Page 162 of 213

point or another integrate with one another. All systems will have to adhere to the release processes in order to reach delivery successfully.

9.2.1 Interviewee

The TPS Release Manager has started and added to her portfolio in this position since 2009. She has experience as a release manger for approximately 5½ years before that. Her portfolio includes two of the case studies mentioned in previous sections of this research paper as well as a legacy system. The portfolio she currently manages consists of three projects. These projects contain an average of approximately 30 initiatives per release in total.

She manages the overall release process. Her responsibilities involve developing detailed release plans, coordinating all the project teams associated with a specific release, liaising with appropriate management, facilitating the team coordination to ensure releases are implemented according to schedule, maintaining the code repository and ensuring entry and exit criteria are met for all stages in the release management process (see Figure 33).

The technical team involves configuration management and building engineers. This team develops and enhances changes and incidents, and consolidates all streams in order for handover to infrastructure for the SIT environment to be successful. This typically involves building release artifacts, merging code into the different test environments and version control.

Natasha NV Ferreira 200508700 Page 163 of 213

CIT SIT UAT PRD Entry&Points:& Entry&Points:& Entry&Points:& Entry&Points:& •! Assyst!Status:! RM&Requirements:& RM&Requirements& RM&Requirements& Create!Change! •! Assyst!Status:!! •Assyst!Status:! •Assyst !Status:! & !!SIT! !!UAT! Implementa8on! Exit&Points&:& •!Release!Notes! •!Implementa8on!plan!! •!Signed!Off! •!Code!Review! •!Build!tags! •!Final!SIT!Build!to!be!used! Implementa8on!Plan!! •!Unit!Tes8ng! •!Approval!From:! •!Sanity!Test!Results! Test&Requirements:& Test&Requirements:& •!PSG! •!PSG!Review!!!!!!!! •!Posi8onal!papers,!FRS,BRS,!used! •!Posi8onal!papers,!FRS,BRS,!used!cases! •!Produc8on!Manager! (!Projects!Only)! cases!signed!off!and!under! signed!off!and!under!version!control! •!Business! ! version!control! •!Test!Analysts!to!receive!walk!through! Representa8ve!(BAS)! •! Assyst!Status:! •!Test!Analysts!to!receive!walk! of!PP,FRS,BRS! •!Test!manager! Build!and!Test! through!of!PP,FRS,BRS! •!Test!Data!available! •!SD!manager! ! •!Test!Data!available! •!Approved!test!cases!available!! •!Infrastructure!Manager! • & •!Approved!test!cases!available!! •!End!to!end!test!environment!available!! !Release!Manager! •!End!to!end!test!environment! •!SIT!Test!Results ! •!CAB!(TPS!and!Central!)! available!! •!CIT!Test!Results!! Exit&Points:& Exit&Points:& •!BAS!Tes8ng!Sign!–!Off! •!Post!Implementa8on! Exit&Points:& •!Date!and!8me!stamp!of!!!when!code! signNoff! •!SIT!SignNOff! was!frozen!! •!Manage!post! •!Known!Issues!report! •!Business!release!notes! implementa8on!issues! •!(Known!issues!to!be!presented! •!Present!Test!report!to!PSG! •Assyst !Status:! at!PSG!and!to!BAS!team)!! •!Walk!through!to!client!services! Post!Implementa8on! •! Assyst!Status:! •! Assyst!Status:! Tes8ng! !!UAT! !!Tes8ng!Completed! ! ! !!Pending!Local!CAB! Pending!Implementa8on! & ! Outcome!! ! & Figure 33 Release gates (Omar, 2013)

Over and above these responsibilities, several other roles related to release management are included. These are firstly, change owner. This is the person responsible for any changes going into production and the communications coordinator. This person sends release updates to the relevant stakeholders. Documentation coordinator and environment coordinator fill the last two roles (Omar, 2013).

A release manager looks after releases from the SIT environment straight through all the way to production. This person hands over to different environments (Omar, 2013). This role also involves aspects of governance and technicality. Activities that imply governance include adhering to release notes and implementation plans as well as presenting and motivating all changes to a change acceptance board (CAB).

Natasha NV Ferreira 200508700 Page 164 of 213

9.2.2 Methodology

Since Business Online (BOL) is a legacy system no formal methodology is necessary because requirements are satisfied quicker if development and implementation are performed dynamically.

One of the programmes that the release manager manages, uses the standard software development lifecycle (SDLC) approach whereby release management plays a role in the initial as well as the final step for environment preparation and production handover to occur respectively.

9.2.2.1 Methodology frequency

Since one of the case studies, nBOL specifically, is still in development. The release manager suggests it is referred to as a project for the purpose of this research paper. It also includes new functionality, enhancements, bug fixes and maintenances (Omar, 2013). This leads to a lengthier duration of delivery and production will also be lengthier.

Previously, nBOL used to be released quarterly and seen as one major release. This year (2013), however, a monthly release approach with new functionality visible to customer but fewer enhancements is attempted. This was decided on purely to reduce the number of defects.

On the other hand, BOL involves enhancements and maintenances with weekly releases in order to keep the customer satisfaction level high. Things in the BOL project are therefore built and not merged. BOL is a legacy system. Release slots in this programme consist of production bug fixes and minor enhancements. The turnaround time on these changes are much quicker than on a release. BOL has more frequent releases because the nature of these changes has minimal risk and impact, and can be delivered sooner.

Natasha NV Ferreira 200508700 Page 165 of 213

9.2.2.2 Methodology application: Success and failures

The main success worth documenting was within the nBOL project. The project implemented a total of 300 changes, resulting in none of the implementations failing. The release manager believes it was the release processes that assisted in the successful implementation.

9.2.3 Project delivery risks

A few risks exist within each of the systems; these may or may not be directly related to the methodology adopted.

The lack of structure of the legacy system could be a risk on its own (Omar, 2013). On the other hand, nBOL is more structured and more successful with the existence of formal environments.

Secondly, the ‘cowboy’ mindset that BOL adopts and which takes no release gates into consideration also allows for additional risks to surface since the governance aspect is nonexistent. There is no documentation or ‘stable’ environment handovers. The challenge this brings with it is changing people’s mentality; this is never an easy task.

Finally the most significant risk known to these systems is the amount of production downtime, which is necessary. This is due to environmental constraints, which are directly related to the implementation freeze. There are only eight development environments, two SIT environments and one UAT environment.

Natasha NV Ferreira 200508700 Page 166 of 213

9.2.4 Throughput

When attempting to investigate research question 1: Will a frequent (minimum of one week) release strategy increase project throughput for all types of projects?, the release manager responded confidently from an nBOL perspective. She claimed that throughput has increased, but she was disappointed to mention that she had no transparency in BOL to add further comments.

However, it is clear that, when referring to research question 2: What type of projects will not benefit from a frequent release strategy from a throughput perspective?, there are no systems that will suffer because of frequent releases. The approach carries more advantages than it does disadvantages.

9.2.5 Optimal release strategy

The current release process, in the release manager’s opinion, should definitely be defined clearly; i.e., add definition to the release gates and adhere to the process to ensure an optimum release management methodology. This would definitely add advantage to projects.

Something else that would add benefit to release management as a whole would be the use of tools for logging changes or any another relevant information for certain stakeholders. The automated approach to certain processes adds the most value to productivity. This could perhaps even include templates for the governance aspect of the process.

Natasha NV Ferreira 200508700 Page 167 of 213

9.3 From a business perspective

9.3.1 Business as IT’s customer

One of the main issues within such organisations is the alignment between business and IT. It is so transparent that it almost does not even exist. IT’s goal is to provide a service and deliver to business. Business is the customer who needs to be satisfied with the service IT provides. If the requirements are not clear enough and alignment between the two teams does not exist, how can IT be confident that they are delivering the requirements correctly?

9.3.2 Interviewee

With more than ten years’ experience as a programme manager, delivering business programmes to business to meet business benefits (Howell, 2013), his responsibility covers the entire division of transactional products and service (TPS), including two of the case studies discussed above, namely nBOL and Business Connect. His role incorporates products, which involves the definition of requirements and user acceptance testing, channels which involve migration and enablement and finally IT.

The programme was formerly known as Tanzanite when he initially joined it in 2011. He remained part of the programme for eight months before returning more or less a year later. He is currently still performing programme manager responsibilities.

9.3.3 Methodology

The Waterfall methodology is the one generally applied to the two programmes in addition to certain principles of PRINCE2 also being adopted (Howell, 2013).

Natasha NV Ferreira 200508700 Page 168 of 213

From a documentation perspective, however, there are no project initiation documents (PIDs) available.

The decision for using the abovementioned methodologies is situation-based since some methods can be applied to certain subsets for certain reasons.

9.3.3.1 Methodology frequency

The main issue mentioned above stating that business and IT are not usually aligned accurately in project delivery – this issue becomes apparent since, frequent releases are a reality from a technical (IT) perspective (Howell, 2013). From a business perspective though, BRs are based on market demand. Therefore, their frequency varies.

9.3.3.2 Methodology application: Success and failures

The minimal failures that project delivery faced were due to the fact that no strategic analysis had been performed on certain projects even though there were a lot of business benefits apparent in the sense of meeting customer needs in respective timelines and upholding quality factors.

9.3.4 Project delivery risks

All projects have their own risks, whether they are methodology-driven or resource-driven, or perhaps even driven by environmental issues. This leads to the assumption that this has instead enhanced the management of any risks or issues (Howell, 2013).

This methodology has proven to be a successful attempt to fight project ‘fires’ from occurring. Risk contempt relates back to culture.

Natasha NV Ferreira 200508700 Page 169 of 213

9.3.5 Throughput

Throughput can be observed from a technical (IT) and a business perspective as well as from the research obtained in the previous sections of this research paper. Only IT aspects were considered and proved to be true. Throughput was increased, based on the methodology applied, as previously discussed. Therefore, the answer to research question 1: Will a frequent (minimum of one week) release strategy increase project throughput for all types of projects? remains the same, as discussed above.

From a business perspective, however, if no return on investment (ROI) is achieved, the reason and justification for implementation remain unanswered.

9.4 Conclusion

The key concept one should take away from this chapter is that methodology preferences are based on management styles. They are not company-decreed but rather individual-specific. Even though methodologies or project management styles may be dissimilar in nature, the outcomes should always strive to deliver a goal of equality.

Successful project management requires the commitment of people or stakeholders, a stable environment and a respective due date. Another analogy is trying to take off in a plane without a flight plan, pilot, fuel or a landing strip. This will prove to be unsuccessful.

Similarly, it is often argued that the fact necessary for improved productivity opposed to being methodology-specific is the necessity of a business case and experienced resources (Howell, 2013). As common as it may seem, the reality is that people play a considerable role in delivery, rather than do methodologies.

Natasha NV Ferreira 200508700 Page 170 of 213

Quite a significant thought to contemplate is: Delivery of code and delivery of benefits are two different things.

Certain organisations and divisions in this financial institution have attempted a number of methodologies that then resulted in a more hybrid method, including aspects of the Waterfall methodology with formal project management principles such as PRINCE2 and SDLC in place.

The releases within these programmes are all monthly. Some other mindsets had to be put in place in order to achieve the ultimate goal successfully. One of these is the importance of prioritisation and adherence thereof. Secondly, the necessity of having a throughput/estimate measuring tool. This improved confidence of stakeholders and the benefits predictably accompany this confidence.

The significance of release management from an organisational perspective becomes evident since all business units have the perception of importance. It is necessary for requirement prioritisation amongst all business units to ensure project prioritisation in all fairness. This will ensure the alignment between business stakeholders and IT, which is equally important in order to deliver value to the customer.

Risks in project management are inevitable. What is important is the appetite of the risk, based on the complexity of the project. This needs to be associated with mitigating processes to have less of a business-related impact. Certain processes adopted also structured the team. The environment constraint has developed into a risk known as downtime.

Therefore, throughput has improved, as predictability is something that should always be present.

Natasha NV Ferreira 200508700 Page 171 of 213

To create the optimum release methodology, a properly defined plan should form the basis to which all stakeholders refer. Certain mechanisms, such as baseline and release processes, should be put in place to minimise scope creep and provide a professional way of moving from one environment to the next.

Natasha NV Ferreira 200508700 Page 172 of 213

10. A proposed model for release management

In this chapter we will present a model to improve release management. Our model is based on the things we have learned from the case studies as well as a literature review, stipulating which particular strategy is the most appropriate and flexible to make adaptation easy in any financial institution.

10.1 Introduction

This chapter will be structured similar to the previous case study chapters have been and more or less the same sub-sections will be analysed. The findings depicted in this research paper regarding release management methodologies and constraints in the software delivery lifecycle will be discussed throughout this chapter.

Everyone strives to pursue the most optimal solution to overcome certain release management difficulties. Optimal can be defined as the most favourable or ideal (Theron, 2013). Applied to this research paper, it would mean the most appropriate release management methodology that would enhance project throughput.

It has been proven that principles from both a Waterfall and Agile approach are the most optimal research methodology for application in the banking industry. Similarly, for the release of working code, multiple environments are required; this is a constraint and should be resolved.

In addition, automation tools are required for measuring throughput, release versioning and prioritisation. Initiatives should be allocated a position in a backlog where priority is assessed and work commences for delivery. In order to achieve this successfully, adequate training needs to be offered to all resources assigned to the project.

Natasha NV Ferreira 200508700 Page 173 of 213

10.2 Factors influencing release management

In this section the researcher will present her findings from the literature study as well as all the case studies.

10.2.1 Project size

The size of the project is used as a deciding factor for methodology selection. What organisation stakeholders do not realise is that this should not be a problem. Any sized project is in some way or another in a position to adopt this hybrid approach.

Small and medium to large organisations, as case study 1 (fewer than 20 people) and 2 (more than 150 people) prove, can be easily adapted to using an Agile/SCRUM type of methodology. This type of methodology can even be applied to larger projects, such as case study 3 (with more than 1 000 people). Widely distributed organisations will inevitably inherit some complications, but there are specific measures in place that assist in overcoming these; measures known as “scrum-of-scrum meetings”, different ways of carrying out meetings as well as applying a most-appropriate-time-for-all approach are necessary.

10.2.2 Overheads

Each case study discussed above denoted similar overheads, which related to team localisation and in some instances, even project or deliverable rework. Another significant overhead was noted as the duration of the test cycles for certain projects.

Natasha NV Ferreira 200508700 Page 174 of 213

10.2.3 Iterations

The idea of smaller batches moving through a development lifecycle will prove to be successful, both from a duration and quality perspective (Poppendieck, 2010). This is due to the prompt feedback received on initial issues before they become too big. The cost of operating without feedback is often hidden and therefore miscalculated.

Another positive effect this rapid feedback has concerns the control over the quality of the project, the minimal chance of slippages and risk development. There are a number of other benefits when working with smaller batches. These include reduced cycle time, increased efficiency, a dramatically improved ability to meet plans and more motivation with a greater sense of urgency.

Releasing development into production is a process on its own and involves various stages such as testing phases, training perhaps or even installation. This is time consuming and quite costly. The disadvantage with respect to the timing issue is that the project may have a competitive shortcoming and then defects go undetected. The cost implications need to be substituted and analysed using the benefits this release frequency entails. The economic batch size calculation is a mechanism one can apply in situations such as these. The graph below indicates how this works.

Total&Cost

Cost&of&Delayed &&Economic &Integration&and& Work& &Defects Package& Size Cost

Release&Overhead& Cost Work&Package&Size Figure 34 Economic Batch Size (Poppendieck, 2010)

Natasha NV Ferreira 200508700 Page 175 of 213

The release overhead costs curve (lighter shade of grey) stipulates the testing stages that need to be performed before code is released (Poppendieck, 2010). These are assumed to be fixed costs, while the curve depicted in the darker shade of grey reflects the cost involving the delay in integration and defects. These costs increase nonlinearly with the size of the batch. The sum of the two costs accrued, where the lowest cost is at the bottom of the curve, is known as the economic batch size. The u-curved line in black depicts this.

The crossover point in this graph is used to calculate how far apart releases can be scheduled. If the overhead costs can be reduced and are therefore not all that fixed, the graph will reflect a slightly different result. Batches will then be a lot smaller and releases will be a lot closer together which will allow for scheduling to take place. That is, if the time for testing and installation or training can be reduced.

Shorter releases are successful in any project and the best approach to practice.

10.2.4 Environment availability

An environment can be defined as a release platform consisting of a certain version of code (Omar, 2013). Testing occurs within this platform to ensure that the particular code base is production-ready.

In the context of this research paper, an example of several environments can be depicted in case study 2 that consists of two CIT testing cycles, three SIT testing cycles and one UAT testing cycle. The CIT test cycle is split between the development and test teams. Defects found during the first CIT test cycle, should be resolved and retested before the close out of the cycle.

The following procedure for the duration on CIT as well as for SIT is followed in a

Natasha NV Ferreira 200508700 Page 176 of 213

similar manner, depending on how many CIT cycles there are and any other testing cycles following these.

Environment availability is a common drawback in each case study presented in this paper. This has resulted in a number of delays in projects. Although the problem is known, the task to fix it is costly and therefore, not recommended at this point of delivery.

Even though case study 1 is a small project, the need for several environments is necessary because of its integration with larger projects. The need for further environments in case study 2 and 3 above also go without saying. This is due to the size of the respective projects.

10.2.5 Consolidated findings

The findings extracted from this research are the following: • Frequent releases are better. This has been depicted in case study 1 and 3 as well as the literature review. • The optimal number of releases per period depends on the project overheads. This has been depicted in all three case studies. • The lack of environments impedes frequent releases because of contention in environments. This has been depicted in case study 3 and 4.

10.3 Model

This chapter serves as the discussion for proposing a specific release management model based on the type of project and its overheads or environment availability. Therefore, based on this, the following model is proposed for a single project or a group of projects, with or without environment contention: • Break the group of projects up into work packages.

Natasha NV Ferreira 200508700 Page 177 of 213

• Refine batch size for the packages within the project. • Define the overheads for a group of projects, such as testing, for example. This is a common operating cost. • If there is severe environmental contention, consider setting up different “runways” or pathways to get to production. See section 10.3.2 below – Figure 36.

To enable the above, one must implement an organisational structure that enables release management across projects and across multiple environments. See section 10.3.2 below – Figure 37.

All of the above will inform the amount of releases that are feasible within a particular period.

Please note: For small projects, a group may be interpreted as a single project and its work package may be the release in its entirety.

Natasha NV Ferreira 200508700 Page 178 of 213

10.3.1 Proposed released management organisational structure

The proposed organisational structure and approach are depicted in the diagram below.

IT#Organisa+onal#Enablement#Work#Stream# Proposed/Opera2onal/Structure/

Department-IT Release Executive Committee Project Board of Executives Executive Committee

Change Approval Board (CAB) Governance structures

Pre- Component System Integration/ Performance/ Project Analysis Design Build Integration Non-functional requirements and Production Planning Testing Regression testing.

Work Project 1 Package Release Cycle X Assembly Project 2 Practice Retro&fitting Project Managers Defect Fixes Release Cycle Y Project to Release Lifecycle

Integrated Component Planning – Release Planning, Release Assurance Release Management Stakeholders Build Package Assembly Team

Build Deployment Team

Environment Management and Support Team

Development and Test Environment Provisioning Team

Figure 35 Proposed operational structures

From a release perspective, the integrated component planning (ICP) function depicted above provides the flight plan control over package/code components across projects and environments. The ICP performs impact analyses. It also guides the projects into testing release cycle windows and specific accessible environment slots, based on the integrated project plan (IPP). The ICP also upkeeps projects in applying the method of breaking projects into smaller, element-based releases, and implies rules of sizing, quality and retrofitting. This is

Natasha NV Ferreira 200508700 Page 179 of 213

a cross-functional team made up of technical specialists and projects managers, each of whom coordinates with business owners.

The build package assembly team assembles and creates a build package, adequate to be deployed into an environment. The build package consists of components of various projects. This team produces the release-driven integrated “build” that will be promoted between the environments along the “pipeline” by assembling “packages” delivered by the project development teams. The build team operates a continuous cycle of builds appropriate to swiftly deploy into environments. This is a dedicated team with an end-to-end system view; these individuals have the proficiency to deliver uninterrupted builds instantaneously.

The build deployment team installs functional changes involving packaged code and associated test data into the technical environments, ensuring the code is ready for its testing phase. The same team also deploys working code into production, reusing the same deployment scripts, tools and meticulousness in work practices. The team is also capable of deploying daily build releases to support release test cycles. Similar to the above, this is an enthusiastic team with an end-to-end system view.

The environments provisioning team is a permanent team responsible for the building and configuring of the non-production environments required for project support. The team upgrades the environments in order to support the environment flight plans; i.e., retrofitting the patches. Upgrading the environment simply means managing the level of versions of the databases, web services and right data – credit card data, file maps etc. It is a single structure and highly technically skilled.

The existing environments management and support team ensures the built configured environments are established, accomplished and appropriate to support testing stages. The team applies ITIL best practices to maintain service

Natasha NV Ferreira 200508700 Page 180 of 213

awareness and ensure that total cost of ownership is minimised. This team comprises highly skilled technical individuals, operating with additional support from the build package assembly team.

10.3.2 Creating different pathways to production

Similarly, the problem with only a few environments resulting in project delays is because a project remains in an environment and therefore holds up the second project wanting to pass through the software development cycle. A solution to this problem involves the introduction of two environments that “pipeline” into production. This is a costly exercise; yet, extremely beneficial.

The following scenario is depicted in the diagram below:

PROJECT 2 DEV SIT PROJECT 1 PROD SIM PROD

Figure 36 Current Environment Landscape

The figure above denotes that Project 1 is in progress but currently stuck in the SIT environment for some or other reason. Therefore, it has a negative impact on the commencement of Project 2.

PROJECT 1 DEV 1 SIT 1

PROD PROD SIM

DEV 2 SIT 2 PROJECT 2

Figure 37 Recommended Release Strategy

The optimal environment, however, is the one represented in the diagram above. It entails two project versions or numbers being in progress simultaneously.

Natasha NV Ferreira 200508700 Page 181 of 213

Version 1 (Project 1) is in the DEV 1 and SIT 1 environments, for example, while Version 2 (Project 2) is in DEV 2 and SIT 2.

Once Version 1 has successfully passed through DEV 1 and SIT 1, it is deployed into DEV 2 and SIT 2 for retesting of defects, perhaps. Once that has been completed successfully that project version can then be moved into the production simulated (PROD SIM) environment and further on into production.

Version 2 (Project 2), which was in progress in DEV 2 and SIT 2, can then also move into DEV 1 and SIT 1 for further testing of any defects. Once that is complete PROD SIM will be vacant as Version 1 (Project 1) would already be in production and therefore has allowed for Version 2 (Project 2) to be deployed into PROD SIM.

Having two or more pipelines to production solves the problem of one project holding up another one as the projects pass from environment to environment.

10.4 Conclusion

As per the case studies analysed above, a hybrid approach should definitely be the type of release methodology adopted. This methodology should cover aspects of both the Agile and the Waterfall methodology, since each has its own pros and cons that should be adopted and in some cases, do not have to be adopted.

The project management framework principles covered in the Waterfall and PRINCE2 methodologies should also play a role in the management and release of the project. These are the most commonly and rewarding frameworks used.

These methodologies will result in a well-structured team working closely together and delivering high quality work. One of the disciplines that Agile ensures, is the disintegrating of projects into smaller portions. This is necessary and beneficial, as it

Natasha NV Ferreira 200508700 Page 182 of 213

minimises the possibility of scope creep that is an inevitable concept in project management.

A well-structured and defined plan is a prerequisite for any project before it is initiated. This too will minimise scope creep within a project.

As illustrated in the proposed manner for the release of working code, multiple environments are required, as this constraint has been the cause of most of the downfalls in the particular projects in the context of this paper.

For any project, irrespective of the project size, the following process should be adhered to: • If a group of projects exists, these should be broken up into work packages. Shorter, more frequent releases/iterations are optimal, since they result in rapid feedback and control over deliverable quality. • The batch size of these packages should then be refined. • The project overheads should be defined with the project in context. The optimal number of releases in a specified period depends on the project overheads. • If environments seem to be a contention, multiple pathways should be configured and set up, since the lack of environments may obstruct frequent release application.

In summary, it can be noted that methodology selection is derived from management and/stakeholder expertise or styles and no other particular reason. Which is why it is very important to acquire the necessary training for practice. Theoretically, each methodology seems simple but the trick is in applying it correctly. The main objective in any project is always a common one: All project stakeholders want to improve throughput and quality in one way or another, regardless of their expertise and how this goal is to be achieved.

Natasha NV Ferreira 200508700 Page 183 of 213

11. Conclusion

11.1 Introduction

The objective of this chapter is to establish whether the research questions proposed in the first two chapters of this research paper have been answered, and accurate solutions have been found for them by using the qualitative research approach discussed in chapter 2.

This chapter also summarises the achievements and contributions of this research study. Recommendations for implementation and future research are also introduced further in this chapter.

This research study demonstrates release methodologies applied in the IT environment holistically. It studies their benefits of application as well as the risks these methodologies have introduced into software engineering. Consideration is given to determine whether any of these methodologies improve the throughput of project delivery in IT.

11.2 Overview of chapters

This section aims to provide a brief overview of the chapter contents contained in this research study.

Chapter one presented an introduction to the research paper and proposed the research questions to which the research study aimed to provide solutions.

Chapter two gave reasons why a qualitative methodology was used to achieve certain objectives and provided a high-level view of four case studies examined for this research paper.

Chapter three presented a literature review synopsis on existing theories and

Natasha NV Ferreira 200508700 Page 184 of 213

concepts referred to throughout the research paper.

Chapter four was dedicated to explaining the concept of throughput and what increasing throughput of a project exactly meant. It also discussed why throughput is important, how it can be measured and the significance of measuring it.

Chapter five explained how the proceeding chapters involving the case study research was structured and positioned.

Chapter six introduced the first case study incorporated in this research paper. A small project in the corporate and investment banking department within the financial institution was used for this chapter.

Chapter seven introduced the second case study incorporated in this research paper. A medium to large project within the corporate and investment banking department within the financial institution was used for this chapter.

Chapter eight introduced the third case study incorporated in this research paper. A super large project within the corporate and investment banking as well as the personal and business banking departments within the financial institution were used for this chapter.

Chapter nine provided an outline on the topic of release management, seen holistically from three different perspectives. These perspectives included a business, departmental and financial division respectively.

Chapter ten served as the proposal chapter, containing all the findings mentioned in the previous chapters to conclude and propose the most optimal approach to release management.

Chapter six, seven, eight and nine all provided outcomes to the proposed research questions proposed initially.

Natasha NV Ferreira 200508700 Page 185 of 213

These questions were introduced as: i. Will a frequent (minimum one week) release strategy increase project throughput for all types of projects? ii. What type of projects will not benefit from a frequent release strategy from a throughput perspective? iii. How can an optimum release management methodology be determined to add advantage to certain project types?

11.3 Summary of objective achievements

The research questions and problem statement will be revisited in this section and the outcomes will be presented. This section assures that the three research questions have been accurately investigated.

The research questions examined were defined above. Their objectives are presented below.

The outcome of question number one resulted in commonality from all respondents of all the case studies. The research showed that even though frequency varied from project to project, all the projects under consideration would like to increase their throughput, but are constrained by a variety of factors. The research also showed that frequent releases do increase throughput in projects unless they are constrained by factors covered in the second research question. This was depicted in case studies 1 and 3 as well as the literature review.

The overall outcome for the second question gathered from the respondents is was that a “frequent release approach” contains more advantages compared to the disadvantages it may have. Projects involving multiple interdependencies among several systems or projects that cannot be broken up into smaller work packages may not benefit from a frequent release strategy.

Natasha NV Ferreira 200508700 Page 186 of 213

The final questions objective resulted in presenting a specific model for optimising the release process.

For single and small projects as well as a group of projects, which do or do not exist with environment constraints, the following should be applied: • Unpack or break the group of projects up into work packages. • Define a suitable batch size for the work packages within the project. • Identify the overheads experienced for a group of projects. • In order to solve the environment contention issue often experienced, different “runways” or pathways should be setup and configured to ensure a seamless, uninterrupted flow into production.

Over and above applying the model below, respondents felt strongly that an automated procedure relating to release management with the use of versioning tools should also be in place to promote an increase in throughput. Similarly, certain governance processes should be defined and adhered to. Specific processes may limit the amount of scope creep that usually finds its way into a project. A significant amount of time should therefore be spent on project planning to ensure rigid scope refinement. Business and IT teams should also be aligned at all times.

The suggested model states that the optimal number of releases per period depends on the project overheads. All case studies examined above reflected this. Similarly, case study 3 and 4 represented the fact that a lack of environments impedes frequent releases because of environment contention.

11.4 Summary of contributions

The research has contributed to the software engineering field in an advisory manner, the benefits of certain release management methodologies and why they should be applied were analysed.

Natasha NV Ferreira 200508700 Page 187 of 213

Many stakeholders confuse the term “release management strategies” with “project management methodologies”.

In this research study, it has been shown how frequent releases have a positive impact on software delivery. The study has defined the most optimal release strategy as the one that breaks single or groups of projects up into logical components with a defined batch size.

Multiple environments should be made available to solve the issue of a particular project delaying another in delivery. This has benefited the programme, since risks and defects have been identified and resolved much earlier – quality was therefore delivered.

It is when multiple project interdependencies are involved that release management becomes quite challenging; not impossible though. It may just need to be adopted in a different manner.

Successful software engineering requires the commitment of people as well as environment stability. The necessity of requirement prioritisation amongst all business units should also be considered. It will result in the alignment between business stakeholders and IT, which is a significant factor for delivering value to the customer.

In this research it has been proven that: • Frequent releases have a positive impact on software engineering. • A model that aids decision-making regarding an appropriate release management strategy has been compiled. • It has been shown that environments are the biggest constraints to a frequent release strategy. • The size of the project team is not necessarily the deciding factor of what release strategy should be applied.

Natasha NV Ferreira 200508700 Page 188 of 213

• A significant overhead experienced in most projects is testing. This should be closely managed.

11.5 Recommendations for implementation

In this research it has been shown that applying the methodologies studied above requires buy-in from management in order to be successful. Over and above management approval, other significant factors include: • A centralised team that ensures the ease of management • Well-defined batch sizes • Multiple environment availability • A knowledgeable team with the relevant skills to apply the methodologies • Process enforcement and the encouragement of streamlined paperwork • Team alignment between business and IT, since delivering code and delivering benefits are two different things • Organisational change management to be implemented to ensure that teams, processes and tools align. A change in mindset is difficult to adopt in such organisations but is possible if managed through a structured process.

11.6 Recommendations for future research

The research is very specific with regard to one large corporate organisation in the finance industry. In future, further research might expand this research to more corporate institutions, perhaps even larger ones in different industries.

11.7 Conclusion

This research has shown that the release strategy concept is a neglected discipline in IT, even though it is crucial and aids the efficiency of throughput.

Natasha NV Ferreira 200508700 Page 189 of 213

Appendix A – Interview Questions

Purpose of the interview

The purpose of carrying out this interview is for academic research. I am currently in the process of completing my MSc in Computer Science. The topic I have chosen to research is related to release management in IT projects to ascertain whether applied release methodologies have an impact on project throughput.

Background information on interview and interviewee

i. Date of interview ii. Name of interviewee iii. What is your job title? iv. What primary functions does your job involve? v. How many years’ experience do you have in this particular position? vi. Duration: ± 45 – 60 minutes

Question 1 In what type of programme are you involved?

Question 2 Please name the different types of project(s) your programme involves.

Question 3 How long have you been involved in this programme?

Question 4 Are you using a formal project methodology regarding project release management? What methodologies are applied to the projects in this programme?

Question 5 Does your release methodology imply frequent releases?

Natasha NV Ferreira 200508700 Page 190 of 213

Question 6 Why have you decided to apply this particular methodology or no methodology at all?

Question 7 Has the abovementioned methodology resulted in any risks in connection with project delivery?

Question 8 Could you describe notable successes and failures as well as lessons learned while using the applied methodology?

Question 9 Does your release strategy increase throughput and why?

Question 10 What type of projects, in your opinion, will not benefit from a frequent release strategy from a throughput perspective? Why?

Question 11 During your experience as a(n) , from a project perspective, what has been the most releases delivered in one year while applying the abovementioned methodology?

Question 12 How will you go about creating an optimum release strategy?

Question 13 Thank you for all the valuable information. Is there anything else you would like to add before we conclude?

MSc student who has carried out the interviews, Natasha NV Ferreira, appreciates your cooperation and willingness to assist in this task.

Natasha NV Ferreira 200508700 Page 191 of 213

Glossary

The table below presents a list of terminology and definitions used throughout this research paper.

Table 11 Glossary

Term Definition Baseline A project’s baseline is the reference point of how performance deviations from the plan can be measured. The performance measurement would only be meaningful if one had an accurate baseline.

Buffer Additional time to complete a task, added to an estimate to account for various factors. A is a protector against impact. Build In the context of this paper, this refers to a version of a particular code base or programme. Business-as-usual (BAU) This term refers to a business process that remains unchanged with any new functionality being implemented into the system.

Change management process A change management process is a formal set of procedures and steps that are defined to manage all changes, updates or modifications to software (systems) within a project.

Natasha NV Ferreira 200508700 Page 192 of 213

Term Definition Change request This is a formal request that needs to follow a particular process in order for approval to include or remove a specific requirement from the confirmed, baselined project scope.

Change the bank (CtB) This team within the financial institution in context is referred to as the CtB, since they are responsible for implementing any new functionality on the current system.

Collection A type of instruction where funds are pulled from one or more accounts into another account. Collection instructions are received from the ordering customer or from an instructing party (on behalf of the ordering customer). The funds are collected from one or more third party accounts into the ordering customer’s account. Each of the third party accounts is debited and the ordering customer’s account is credited with the specified amounts. The ordering customer’s account is held at Standard Bank where the third party accounts can be held with either Standard Bank or any other agent bank.

Natasha NV Ferreira 200508700 Page 193 of 213

Term Definition Component A component is an identifiable part of a larger program. A component provides a particular function or group of related functions. In programming design, a system is divided into components that, in turn, are made up of modules. Component integration testing (CIT) This is the process of testing all related modules that form a component as a group to ensure everyone functions correctly. Constraint This is a bottleneck within the system that determines the ability of the system to be successful. Corporate and investment banking This is one of the many departments within the financial institution in context. This department satisfies corporate clients with transactional functionality. Data model This is the formalisation and documentation of existing processes and events that occur during application and development. These techniques and tools capture and translate complex system designs into easily understood representations of the data flows and processes. Data migration This is the process of transferring data between data storage systems, data formats or computer systems.

Natasha NV Ferreira 200508700 Page 194 of 213

Term Definition Debugging This is the process of locating and correcting or avoiding errors in computer program codes of a particular system. Defect Any instance where a product or service or any specific functionality within a project fails to meet customer requirements.

Deliverable A product or service produced or provided as part of a project; for example: a segment of software code, a technical document or a functional requirement specification.

Deployment This process involves spreading out or arranging strategically. In its IT context, deployment encompasses all the processes involved in getting new software or hardware up and running properly in its environment, including installation, configuration, running, testing and making the necessary changes. The word implementation is sometimes used to mean the same thing. Domestic transactions It is a transaction where the ordering customer’s (issuer’s) account is located in the transaction country. Enhancement In an information technology product, an enhancement is a noteworthy improvement to the product as part of a new version of it.

Natasha NV Ferreira 200508700 Page 195 of 213

Term Definition Environment This term refers to the combination of hardware and software in a system; specifically, the version of data or code and functionality that exist within the system. Estimate An approximation of either the effort required in order to complete the project or the cost required for necessary resources

File format This is a layout of a file in terms of how the data within the file is organised. A program that uses the data in a file must be able to recognise and possibly access data within the file.

Financial institution This is an organisation that provides financial services to its clients or members. Gateway A gateway is a network point that acts as an entrance to another network.

Natasha NV Ferreira 200508700 Page 196 of 213

Term Definition Inception A phase within the RUP. It is an iterative software development process where the primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase, the business case that includes business context, success factors (expected revenue, market recognition, etc.) and financial forecast is established.

Instruction The classification of either a payment or a collection

Integration This generally means combining parts so that they work together or form a whole. During product development this is a process in which separately produced components or subsystems are combined and problems in their interactions are addressed. Iteration This is referred to as a single development cycle measured by one or two weeks. Metadata This is data that describes data. Methodology It describes the manner of how things should be done.

Natasha NV Ferreira 200508700 Page 197 of 213

Term Definition Personal and business banking This is one of the many departments within the financial institution in context. This department satisfies the private individuals, and small and medium enterprises with transactional functionality. PRINCE2 PRojects IN Controlled Environments. A project management methodology developed in the U.K. that defines 45 separate sub-processes and which organises these into eight process groups. Productivity The quality of being effective in achieving specified results Protocol These are the special set of rules that two integrating systems use when they communicate via a telecommunication connection. Protocols specify interactions between the communicating entities. Prototype A developed, working replica of the system or some aspect of the system to help define user requirements Rest of Africa (RoA) This indicates the countries in which the nBOL application is currently supported in Africa. Not South Africa. Regression testing Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes.

Natasha NV Ferreira 200508700 Page 198 of 213

Term Definition Requirement A condition or capability that must be met by a system, product, service, result or component to satisfy a contract, standard, specification or other formal document Robust A robust product can be one that does not break easily. Sometimes it implies that a product or system of products is designed with a full complement of capabilities. Root cause analysis This is a method of problem-solving that attempts to identify the root causes of faults or problems that cause operating events. Scope All the work involved in creating the products of the project and the processes used to create them Software hosting This is the process of installing and accessing software entirely from a remote server or location. Software package A software package is when files and information about those files are assembled. Sprint (SCRUM) A set period of time during which specific work has to be completed and made ready for review.

Natasha NV Ferreira 200508700 Page 199 of 213

Term Definition System integration testing (SIT) This is a testing process that exercises a software system’s coexistence with others. With multiple integrated systems, it assumes that each has already passed system testing. Throughput In computer technology, this term defines the amount of work that a computer can do in a given time period. Transactional products and services Delivering international and domestic banking services that clients need to transact efficiently with their customers, suppliers and counterparties. User interface It consists of a set of operating system commands, graphical display formats and other devices provided by a computer or a program to allow the user to communicate and use the computer or program.

Natasha NV Ferreira 200508700 Page 200 of 213

Acronyms

The table below presents a list of acronyms and their definitions used throughout this research paper.

Table 12 Acronyms

Acronym Definition BOL “Business Online.” This is the legacy order management system within the financial institution in context that processes all transactional data that has been received from a customer and needs to be set back to the customer. CAB “Change Acceptance Board.” An internal committee within the financial institution in context that is responsible for making the decision related to whether or not a proposed change(s) to a software project should be implemented and when the implementation can take place. IT “Information Technology” This term is usually related to computers are any telecommunications equipment that stores, retrieves or transmits data. ITIL “Information Technology Infrastructure Library (ITIL)” A set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of

Natasha NV Ferreira 200508700 Page 201 of 213

Acronym Definition business. JAD “Joint Application Design.” This process is often used in the prototyping life cycle. Which develops information systems for company’s based on certain requirements. nBOL “new Business Online.” This is the upgrade of the legacy order management system within the financial institution in context that processes all transactional data that has been received from a customer and needs to be set back to the customer and more. PID “Project Initiation Document.” The “contract” that binds the project manager and the project board. Including details such as: the aim of the project, its importance, the stakeholders involved and the method applied to achieve the goal. PEC “Project Execution Committee.” An internal committee that was formed in one of the departments within the financial institution in context. This committee is for the delivery of all projects with the exception of SAP. PMBOK “Project Management Book of Knowledge” This book presents a set of standard terminology and guidelines that should

Natasha NV Ferreira 200508700 Page 202 of 213

Acronym Definition be adhered to in project management. RAD “Rapid Application Development.” Software development methodology that uses minimal planning in favor of rapid prototyping. RUP “Rational Unified Process.” This process framework makes provision for industry-specific practices related to the delivery implementation of software and systems effective project management. SAP "Systems Applications and Products." The idea is to make provision for customers to be able to interact with a common corporate database for a comprehensive range of applications.

Natasha NV Ferreira 200508700 Page 203 of 213

List of References

A Guide to the Business Analysis Body of Knowledge. (2006) 1.6 ed. Available at: http://www.theiiba.org.

A Guide to Project Management Body of Knowledge (PMBOK Guide). (2000). Project Management Institute. 5th ed. Available at: http://www.pmi.org.

Ambler, S. (2011). Agile Testing and Quality Strategies: Discipline Over Rhetoric. Available at: http://ambysoft.com.

Ambler, S.W. (2012). Feature-driven Development (FDD) and Agile Modeling. Available at: http://www.agilemodeling.com/essays/fdd.htm.

Anglberger, N. & Frisanco, N. (2013). Operations management vs project management — the operations services universe and its new project manager, paper presented at Management of Innovation and Technology, 2008. ICMIT 2008. 4th IEEE International Conference, Bangkok, 21-24 September 2008. pp. 323 - 326.

Aro, P. (2009) Release Management Approach. Available at: www.sapfinug.fi/Accenture

Arraj, V. (2010) ITIL: The Basics. White Paper. Available at: www.best-management- practice.com

Ashman, R. (2004). Project Estimation: A Simple Use-Case-Based Model. IEEE Transactions on Software Engineering. 6(4): 40 – 44.

Banu, R., Kumar, S. & Rasa, G. (2013). Release and Deployment Management using ITIL. Global Journal of Computer Science and Technology, 10 (15): 2-8.

Bhattacharjee, S. (n.d). Software Development Lifecycle (SDLC). Presented by the College of Agricultural Banking.

Natasha NV Ferreira 200508700 Page 204 of 213

Berczuk, S., Cowham, R., Appleton, B. (2011). An Agile Approach to Release Management. Available at: http://www.cmcrossroads.com.

Boeije, H. (2009). Analysis in Qualitative Research. London: SAGE publishers.

Borland, K. (2001). Qualitative and quantitative research: A complementary balance. New directions for institutional research, (112). Available at: http://onlinelibrary.wiley.com/doi/10.1002/ir.25/abstract.

Brannen, J. (2005). Mixing Methods: The Entry of Qualitative and Quantitative Approaches into the Research Process. International Journal of Social Research Methodology, 8(3): 173-184.

Brennon, K. (2009). A Guide to the Business Analysis Body of Knowledge (BABOK guide). International Institute of Business Analysis. Version 2.0.

Brits, A. (2013). Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Bronkhorst, J., Cannon, D., Case, G., Hanna, A., Iqbal, M., Lloyd, V., Nieves, M., Rance, S., Rudd, C., Spalding, G. & Wheeldon, D. (n.d). ITIL Version 3 Service Transition. Available at: www.best-management-practice.com/itil

Bun, J. (n.d). Lean Project Management. Available at: http://www.slideshare.net

Business Connect (2013) Referencing: The diagram (Brochure). Johannesburg: Standard Bank South Africa.

Callegari, D.A. & Bastos, R.M. (2007). Project Management and Software Development Processes: Integrating RUP and PMBOK. IEEE Transactions on Software Engineering. pp. 1 -8.

Cartlidge, A., Hanna, A., Rudd, C., Macfarlane, I., Windebank, J. & Rance, S. (2007). The IT Infrastructure Library An Introductory Overview of ITIL V3. The UK Chapter of the itSMF. Available through: http://www.best-management-practice.com

Natasha NV Ferreira 200508700 Page 205 of 213

Cervone, F. (2008). Managing digital libraries: The view from 30,000 feet ITIL: a framework for managing digital library services. OCLC Systems & Services, 24 (2):87- 90.

Clemmons, R. (2006). Project estimation with use case points. ACM Digital Library. 19:18 - 22.

Cohen, I., Mandelbaum, A., Shtub, A. (2004). Multi-project scheduling and control: a process-based comparative study of the critical chain methodology and some alternatives. The Project Management Journal. 35(2):39 – 50.

Cohn, M. (2007). Advice on Conducting the Scrum of Scrums Meeting. Available at: http://www.mountaingoatsoftware.com/

Cook, S. (2011). Applying Critical Chain to Improve the Management of Uncertainty in Projects. Available at: http://www.temoa.info/node/64418

Cooper, D. & Edgett, D. (2013). Maximising productivity in product innovation. Research-Technology Management, 51 (2):1-16.

Donalek, J., & Soldwisch, S., (2004). An introduction to qualitative research methods. Urologic nursing, 24(4), pp.354, 356. Available at: http://www.ncbi.nlm.nih.gov/pubmed/21965553.

Dormehl, T. (2013). Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Draper, J., (2004). The relationship between research question and research design. Research into Practice: Essential Skills for Reading and Applying Research in Nursing and Health Care. Edinburgh: Bailliere Tindall, pp. 69–84.

Dunlap, M.C. (2003). What is DSDM? Available at: http://www.codeproject.com.

Natasha NV Ferreira 200508700 Page 206 of 213

Ehie, I. & Sheu, C. (2005). Integrating six sigma and theory of constraints for continuous improvement: a case study. Emerald Group Publishing Limited. 16(5):542 – 553.

Eikebrokk, T. & Iden, J. (2012). “ITIL implementation: The role of ITIL software and project quality”, paper presented at 2012 23rd International Workshop on Database and Expert Systems Applications, Vienna, 3-7 September 2012. Vienna: pp. 60-64.

Esmaili, H., Gardesh, H. & Sikari, D. (2010). “Strategic Alignment: ITIL Perspective”, paper presented at 2nd International Conference on Computer Technology and Development (ICCTD 2010), Cairo, 2-4 November 2010. Cairo: pp. 550-555.

Evans, C. (2012). Continuous Integration. Available at: http://www.versionone.com/Agile101/Continuous_Integration.asp.

Feature Driven Development (FDD). (2006 ). Available at: http://www.skillresource.com/methodology/development-methodology/feature- driven-development.php

Firestone, W. (1987). Meaning in Method: The Rhetoric of Quantitative and Qualitative Research. SAGE Journals. 16(7):16-21.

Fowler, M. (2006). Using an Agile Software Process with Offshore Development. Available at: http://martinfowler.com/articles/agileOffshore.html

Girdler, M. (n.d). Lean Methodologies in Project Management. Available at: http://www.cornerstonedynamics.com/

Goldratt, E. M. (1997). Critical Chain/Eliyahu M. Goldratt. Great Barrington Mass: North River Press.

Groenewald, R. (2001). The application of the theory of constraints in the small business sector. (Master’s Dissertation). Auckland Park, Johannesburg: University of

Natasha NV Ferreira 200508700 Page 207 of 213

Johannesburg. Available from: https://ujdigispace.uj.ac.za/

Hawthorne, M. (2013) Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Haber, J. (n.d). Chapter 2: Research Questions, Hypotheses and Clinical Questions. Available at: http://www.us.elsevierhealth.com

Hirtz, T. & Guernaccini, P. Toward a model of performance measurement of output based on the Theory of Constraints. Emerald Group Publishing Limited, pp.117-137.

Hochman, I. (n.d). Case Study – Continuous Deployment at Outbrain. Available through: http://gotocon.com

Hofstee, E. (2006). Constructing a Good Dissertation: A Practical Guide to Finishing a Master’s MBA or PhD on Schedule. Johannesburg: EPE.

Horvath, D. (2011) Function Point Analysis and Agile Methodology. Available at: http://www.cmcrossroads.com/cm-articles/275-articles/14305-function-point- analysis-and-agile-methodology-part-1.

Howell, R. (2013). Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Huijbers, R., Lemmens, F., Senders, B., Simons, S., Spaan, B., van Tilburg, P. & Vossen, K. (2004) Software Project Management: Methodologies & Techniques. Available at: http://www.projectedu.com

IBM (2009), RP252 ERC 1 Advanced Disciplined Agile Delivery: Student Guide, United States of America.

IEEE Standards Association: The Standards Development Lifecycle. (2013). Available at: http://standards.ieee.org/develop/index.html.

Natasha NV Ferreira 200508700 Page 208 of 213

Jha, N. (2012). Agile Methodology - A Brief Overview. Available at: http://navneetjha.hubpages.com/hub/Agile-Methodology-A-Brief-Overview.

Kerkhoff, W. (2002). Software Release Management. Available at: www.documbase.com.

Kim, G. (2013). Top 11 Things You Need to Know About DevOps. Available through: www.itrevolution.com

Krishnan, M.S. (1994). Software Release Management: A Business Perspective. ACM Digital Library.

Kruger, K. (2013) Release Management. Interviewed by Natasha Ferreira [in person] 45 Commissioner Street, Marshalltown.

Lahtela, A. & Jantti, M. (2011). Challenges and Problems in Release Management Process: A Case Study, IEEE Transactions on Software Engineering, pp. 10.

Lehman, T. & Sharma, A. (2011). Software Development as a Service: Agile Experiences, 2011 Annual SRII Global Conference 2011, IEEE Transactions on Software Engineering, pp. 749-758.

Ladeira, A. (2002). Cost Estimation Methods for Software Engineering. (Master’s Dissertation). Auckland Park, Johannesburg: University of Johannesburg. Available from: https://ujdigispace.uj.ac.za/

Liu, S., Meng, Q., Wu, B. (2012). Critical Affecting Factors of IT Project Management. IEEE Transactions on Software Engineering. Vol. 1, pp. 494 – 497.

Malan, A. (2001.) Towards improved project and product management in a software environment. (Master’s Dissertation). Auckland Park, Johannesburg: University of Johannesburg. Available from: https://ujdigispace.uj.ac.za/

Mann, S. (2013). Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Natasha NV Ferreira 200508700 Page 209 of 213

Mann, S. (2011) Sizing_Model. Internal documentation. Version: 2.4. Published Johannesburg: Standard Bank.

Marquardt, K. (2010). Patterns for Software Release Versioning. ACM Digital Library. Article No. 7.

Moe, N.B., Dingsøyr, T., Doyå, T. (2010). Agile Software Development. Current Research and Future Directions. Springer: London.

Musil, J. & Hoeliner, R. (2009) The new ASAP methodology. Available at www.sdn.sap.com/.

Olivier, M., (2009). Information Technology Research: A Practical Guide for Computer Science and Informatics. Third Edition. Pretoria: Van Schaik Publishers.

Omar, S. (2013). Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Paasivaara, M., Lassenius, C. & Heikkilä, V. (2012). Inter-team Coordination in Large- Scale Globally Distributed Scrum: Do Scrum-of-Scrums Really Work?. ACM: New York. pp. 235-238.

Parshotam, K. (2013). Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Pearson, V. (2013) Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Piattini, M., Pino, F. & Del Nuevo, E. (2011). "Scrum-based Methodology for Distributed Software Development", paper presented at Global Software Engineering (ICGSE), 2011 6th IEEE International Conference, 15 - 18 August 2011. Helsinki: pp. 66-74.

Natasha NV Ferreira 200508700 Page 210 of 213

Pieterse, M. (2001). Critical success factors in Information technology projects. (Master’s Dissertation). Auckland Park, Johannesburg: University of Johannesburg. Available from: https://ujdigispace.uj.ac.za/

Poppendieck, M. & Poppendieck, T. (2010). Chapter 3: Reliable Delivery. In Leading Lean Software Development, Results are not the point. Kindle ed. Madrid: Addison- Wesley.

Rana, A. & Arfi, M. (2005). Software Release Methodology: A Case Study. IEEE Transactions on Software Engineering, pp. 1-10.

Rao, K. K., Srinivasan, N., Ahuja, J. (2008). Measuring the function points from the Points of Relationships of UML. IEEE Transactions on Software Engineering. pp. 748 – 752.

Raymond, E. S. (2001). The Cathedral & The Bazaar: Musings on Linux & Open Source by an Accidental Revolutionary. O’Reilly: California.

Robinson, H. & Richards, R. (2010). "Critical Chain Project Management: Motivation & overview", paper presented at Aerospace Conference, 2010 IEEE, Big Sky, MT, 6-13 March 2010:1-10.

Rodriguez, H. (n.d). Lean Project Management Principles. Available at: http://www.slideshare.net

Rowley, J. (2000). Using Case Studies in Research. Emerald. 25:1:16-27.

Ruparelia, N., (2010). Software Development Lifecycle Models. 35(3):8-13.

Ruthe, G. (n.d). Software Release Planning. Handbook Software Engineering and Knowledge Engineering. Vol. 3. pp. 4 – 21.

Sassenburg, H. (2005). Design of a Methodology to Support Software Release Decisions. Available at: http://www.se-cure.ch/images/ps_thesis.pdf.

Natasha NV Ferreira 200508700 Page 211 of 213

Schlebusch, P. (2011). 2015 Vision Business Case (Iteration 1) Personal and Business Banking. Internal documentation presented in Johannesburg: Standard Bank.

Schmittknecht, D.V. (2012). Standard Bank CIB SAP Ramp Up Knowledge Transfer. Internal documentation presented in Johannesburg: Standard Bank.

Schwalbe, K. (2010). Managing Information Technology Projects. 6th ed. Course Technology, Cengage Learning: Australia.

Seaman, C.B. (1999). Qualitative methods in empirical studies of software engineering. IEEE Transactions on Software Engineering, 25(4):557–572.

Software Development Cost Estimating Guide Book. (2010). Available at: http://www.stsc.hill.af.mil/consulting/sw_estimation/softwareguidebook2010.pdf.

Soriano, J.L. (2012) Maximising benefits from IT project management : from requirements to value delivery. Boca Raton, FL : CRC Press.

Song, X., Jingchun, F., Ming, L. (2009). Research on IT Project Life Cycle. IEEE Transactions on Software Engineering. Vol. 4, pp. 244 - 247.

Spies, A. (2013). Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Stevenson, W. (2012). Operations management. 11th ed. McGraw-Hill Education.

Supporting a Common Project Delivery Framework. (2012). 6(3). Available at: www2.cdc.gov/cdcup

Theron, K. (2013) Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Thomas, R. (2003). Blending Qualitative and Quantitative Research Methods in Theses and dissertations. London: SAGE publishers. pp. 1-23

Natasha NV Ferreira 200508700 Page 212 of 213

Turpin, R. (2002). A progressive software development lifecycle. IEEE Transactions on Software Engineering. pp. 208-211. doi: 10.1109/ICECCS.1996.558414.

Trochim, W. (2002). Research Methods Knowledge Base. Available at: http://trochim.human.cornell.edu/kb/timedim.htm

Van der Hoek, A., Hall, R.S., Heimbigner, D., Wolf, A.L. (1997). Software Release Management. ACM Digital Library. 22(6):159 – 175.

Van Niekerk, G. (1998). Productivity and Quality improvement through the use of an integrated management system. (Master’s Dissertation). Auckland Park, Johannesburg: University of Johannesburg. Available from: https://ujdigispace.uj.ac.za/

Vermeulen, L. (2013) Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Vermeulen, L. and Langerman, J.J. (2012). The effect of Release Management on project throughput. PMSA Conference, 17 – 19 September 2012, Johannesburg, South Africa.

Wartnaby, H. (2011). 10 Key factors for ensuring successful Release Management. Available at: http://www.bluefinsolutions.com.

Webber, S. (2013). Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Wheeldon, D. (2002). ITIL Organisation Structure. Available at: www.itsmf.com

Wyngaard, S. (2013) Release Management. Interviewed by Natasha Ferreira [in person] 2 Rissik Street, Marshalltown.

Yin, R. (2009). Case Study Research Design and Methods. 4th ed. SAGE publications.

Natasha NV Ferreira 200508700 Page 213 of 213