ISSN 1744-1986

Technical Report N

2009/ 06

Critical Success Factors for enabling Packaged Software to realise the potential Business Benets
B Bond

26 October, 2009

Department of Computing Faculty of Mathematics, Computing and Technology The Open University Walton Hall, Milton Keynes, MK7 6AA United Kingdom http://computing.open.ac.uk

Critical Success Factors for enabling Packaged Software to realise the potential Business Benefits

A dissertation submitted in partial fulfilment of the requirements for the Open Universitys Master of Science Degree in Computing for Commerce and Industry.

Bryon Bond (W6364392)

9 March 2010
Word Count: 15504

Preface
I wish to thank my employers, Catalent, who have sponsored and supported my studies with the Open University that have led up to this dissertation. The Open University for providing a learning environment that I have found to be truly inspirational. The revision schools with their excellent lectures combined with the infectious enthusiasm of my fellow students have all led the way to writing this dissertation. The support of my supervisor, Dr David Butts, without his encouragement and advice this dissertation may never have been completed. A special thank you goes to my family, my wife Sue, children Jenny and Toby. Without their essential support this would not have been possible to write. Only fellow OU widows and orphans can truly appreciate the sacrifices they had to make. The contributions made by the members of the Delphi panel, I am extremely grateful to them for sharing their knowledge, insight and taking the time out of their busy schedules to complete the questionnaires. To my colleagues Jonathan Porter and Martin Smith for their support and being excellent sounding boards. Finally I would like to thank Mike Furmston, whose long friendship provided the initial spark of inspiration that set me on a path of learning that led me to climb high mountains and write this dissertation.

Table of Contents

Preface .........................................................................................................................i List of Figures............................................................................................................vi List of Tables ...........................................................................................................viii Chapter 1 Introduction..................................................................................................1 1.1 Background to the research..............................................................................1 1.1.1 What is Packaged Software? ....................................................................2 1.1.2 ERP Systems ...............................................................................................4 1.1.3 Critical Success Factors.............................................................................5 1.1.4 Customisation ..............................................................................................6 1.1.5 The Stakeholders ........................................................................................9 1.2 Aims and objectives of the research project ................................................12 1.3 Overview of the dissertation............................................................................13 Chapter 2 Literature Review......................................................................................14 2.1 Why use Packaged Software? .......................................................................14 2.2 The Benefits of Packaged Software ..............................................................16 2.3 The disadvantages of Packaged Software...................................................17 2.4 Critical Success Factors for Software Implementation ..............................18 2.5 Changing the Business Processes instead of Software Customisation. .22

ii

2.6 The Stakeholders..............................................................................................28 2.6.1 The IT Department ....................................................................................29 2.7 Summary............................................................................................................32 Chapter 3 Research Methods ...................................................................................33 3.1 Other Techniques .............................................................................................33 3.1.1 Case Study .................................................................................................33 3.1.2 Questionnaires ...........................................................................................35 3.1.3 Interviews....................................................................................................36 3.2 The Delphi Technique......................................................................................36 3.3 Summary............................................................................................................40 Chapter 4 Data Collection..........................................................................................41 4.1 Data Sources.....................................................................................................41 4.2 Process ..............................................................................................................42 4.2.1 Round One Questionnaire .......................................................................43 4.2.2 Round One Analysis .................................................................................46 4.2.3 Questionnaire Two ....................................................................................48 4.2.4 Round Two Analysis .................................................................................50 4.3 Summary............................................................................................................50 Chapter 5 Results .......................................................................................................51

iii

5.1 Critical Success Factors ..................................................................................51 5.1.1 Consolidated list of Critical Success Factors from round 2. ...............57 5.2 Customisation....................................................................................................64 5.3 Advantages of Packaged Software................................................................66 5.4 Disadvantages of Packaged Software ..........................................................67 5.5 Risks ...................................................................................................................68 5.6 Key Stakeholders..............................................................................................70 5.7 Roles and Responsibilities for the Business Group ....................................74 5.8 Vendor / Consultant Groups Roles and Responsibilities ...........................80 5.9 IT Group Roles and Responsibilities ..........................................................85 5.10 5.11 5.12 5.13 5.14 Project Management...............................................................................89 Application Configuration .......................................................................91 Ownership of the Project Delivery ........................................................97 Resource Estimation.............................................................................101 Analysis...................................................................................................102

Chapter 6 Conclusions .............................................................................................104 6.1 Discussion/Conclusion...................................................................................104 6.2 Future research...............................................................................................109 Glossary ..................................................................................................................111 References..............................................................................................................112 Appendix A Extended Abstract............................................................................115

iv

Appendix B Delphi Questionnaire .......................................................................121 Appendix C Round 1 results from Business grouping of the Delphi panel. .127 Appendix D Round 1 results from Vendor/Supplier grouping of the Delphi panel. ................................................................................................................142 Appendix E Round 1 results from IT grouping of the Delphi panel. ..............154 Appendix F Linking for comparisons between ERP and results for Packaged Software CSFs................................................................................................166 Appendix G Risk Analysis ....................................................................................167 Appendix H IT Roles and Responsibilities.........................................................174

List of Figures
Figure 1 The major groups involved and their areas of knowledge...................10 Figure 2 Traditional Waterfall Software Development process model. ...........15 Figure 3 Traditional Waterfall process model for Packaged Software. ...........15 Figure 4 ERP Critical Success Factors .............................................................20 Figure 5 The Delphi technique adapted from www.mycoted.com ...................37 Figure 6 Round 1 CSFs 1 of 4 ..........................................................................52 Figure 7 Round 1 CSFs 2 of 4 ..........................................................................53 Figure 8 Round 1 CSFs 3 of 4 ..........................................................................54 Figure 9 Round 1 CSFs 4 of 4 ..........................................................................55 Figure 10 Critical Success Factors comparison between ERP and Packaged Software...........................................................................................62 Figure 11 Risks for Packaged Software Implementations.................................69 Figure 12 Business responsibility for ensuring the technical platform...............76 Figure 13 Vendor provision of documentation ..................................................82 Figure 14 IT acting as the liason with the vendor..............................................87 Figure 15 Business role as Project Manager ....................................................89 Figure 16 IT role for Project Management ........................................................90

vi

Figure 17 Business particitpation in the configuration.......................................92 Figure 18 IT Application configuration...............................................................93 Figure 19 Vendor assisting with the Process Design ........................................95 Figure 20 IT Participation in the requirements gathering ..................................97 Figure 21 Vendor ownership for overall project delivery ...................................98 Figure 22 IT ownership of the project delivery ..................................................99 Figure 23 Vendor responsibility for schedule adherence ................................100

vii

List of Tables
Table 1 Critical Success Factors for Packaged Software 1 of 5........................57 Table 2 Critical Success Factors for Packaged Software 2 of 5........................58 Table 3 Critical Success Factors for Packaged Software 3 of 5........................59 Table 4 Critical Success Factors for Packaged Software 4 of 5........................60 Table 5 Critical Success Factors for Packaged Software 5 of 5........................61 Table 6 Advantages of Packaged Software ......................................................66 Table 7 The disadvantages of Packaged Software...........................................67 Table 8 Key Stakeholders for Packaged Software............................................70 Table 9 Business roles and responsibilities ......................................................74 Table 10 Vendor / Consultant roles and responsibilities ...................................80 Table 11 IT Roles and Responsibilities.............................................................85

viii

Abstract

Pre-written Packaged Software that can be configured to meet requirements has become the first choice as a means of satisfying an organisations software application needs. The short history of IT projects is characterised by them being difficult to implement and never realising all of their intended benefits. Software development is one of the hardest of human endeavours, because it attempts to build rule-based models of behaviour based upon an infinitely complex world of humans and their social interactions. The attraction of Packaged Software for Businesses is not only that the development of the software has been removed from the equation having already been written, but more importantly, it has also been fully tested and proven to work.

The move towards the use of Packaged Software started to gain pace in the mid 1990s, and it has been growing in popularity for over ten years. However, despite avoiding the need for organisations to develop their own software, there are still numerous reports in the literature of IT projects failing.

This study sets out to identify if Packaged Software implementations exhibit any special problems and risks when compared to conventional bespoke software projects.

ix

Reports in the literature have concentrated on Enterprise Resource Planning (ERP) Systems. These are the most expensive examples of Packaged Software systems. They are difficult to implement and carry high risks that have even resulted in bankruptcy for the implementing organisation. However ERP systems alone do not completely fulfil all the software application needs that an organisation may have. There are many smaller, more specialised packaged systems that tend to be implemented more frequently.

This study sets out to see if lessons can be learned from the literature on ERP systems and whether they can be generally applied to all types of Packaged Software implementations.

Studies in the literature have typically looked at implementations from a two dimensional viewpoint, that of the Business as a whole and that of the Software Vendor/Consultants. However, a typical Packaged Software domain actually involves three groups: the Business, IT department and the Software Vendor/Consultants. Using the Delphi technique, views from all three groups were gathered to assess the Critical Success Factors and risks associated with Packaged Software. The study also set out to identify the roles and responsibilities implementation. for the main stakeholders for a Packaged Software

This study found that for Packaged Software to be cost effective, it requires an understanding of the Business Processes and a willingness to change their design to fully exploit the systems capabilities. This means that Packaged Software implementation is more about designing Business Processes to align with the best practices embodied within the software. If this is not recognised, it can lead to expensive software customisations or inefficient Business Processes being put in place to support the software. This inevitably brings about more change within the Business and therefore requiring more change management.

xi

Chapter 1 Introduction

1.1 Background to the research As an alternative to developing Software in-house, many IT departments now prefer to buy in software to satisfy their organisations IT needs (Janson and Subramania, 1996), (Whiting, 1998). This type of purchased software is

generally referred to as Packaged Software, which can then be configured to suit the customers requirements.

The main reasons why Packaged Software implementations are preferred is the promise of reduced costs and shorter implementation times, providing a quicker return on the investment (Butler 1999). Costs are reduced because those associated with development and maintenance can be spread over all the software developers customers and implementation times are shorter because the software has already been written (Tayntor, 2006).

Software development projects are seen by Business Managers as high risk because they are notorious for being over budget and late on delivery. Purchasing software that has a proven track record helps to reduce the risks as the majority of the development has been completed (Tayntor, 2006). Also the purchased software will have generally been written by suppliers specialising in niche market sectors, leading to richer functionality that would not have been cost effective if developed in-house.

1.1.1 What is Packaged Software?

Within the literature, the term Packaged Software has been used to describe a variety of different software types. Also the term COTS, which stands for Commercial Off The Shelf Software, has been used in the same context. Both of these terms have been used interchangeably to describe the following commercially available pre-written software types: Software that can be installed and used as is. Examples of this type are Word Processors and Spreadsheets etc. The term Shrink Wrapped has also been applied to this type of software.

The introduction of Object Orientated design concepts with its emphasis on modular design and the reuse of existing components have given rise to components being developed commercially that provide specific niche functionality. These components are then combined into bespoke applications. This type is more commonly referred to as COTS.

Finally, there are pre-written software systems that can be configured to change its behaviour in order to satisfy the requirements for the system. The configuration settings are read in by the system at start up and used to determine its operational behaviour.

The latter will be the subject of this research.

The vast majority of the research in the academic literature in the area of Packaged Software has been devoted to one particular type of system known as ERP, which stands for Enterprise Resource Planning. This is because this type of system is generally very expensive to purchase and implement. ERP system implementations impact on most areas of the business and can lead to a great deal of complexity trying to satisfy many conflicting inter-department and business requirements. Examples of ERP systems are SAP, JD Edwards and Oracle. Whilst ERP vendors are continuing to strive to continually add functionality to their products, they are unlikely to be able to completely fulfil an organisations software needs. There are a large number of other types of Packaged Software vendors that provide niche solutions such as: Laboratory Information Systems (LIMS). These are systems designed to assist in all aspects of running laboratories. Examples of these are SQL*LIMS, LabTrack, LabWare LIMS and STARLIMS.

Time and Attendance These are systems used for monitoring employee timekeeping. Typical examples of this type of system are Kronos and Isys.

Planning Software These are systems used for finite scheduling for planning hour by hour manufacturing operations. A typical example of this system is Preactor.

There has been very little attention paid to the implementation of these types of Packaged Software systems in the academic literature and this is where this research aims to make a contribution to the existing body of knowledge.

1.1.2 ERP Systems

Difficulties with ERP implementations have been widely cited in the literature (Fui-Hoon Nah et al. 2001). So, is a Packaged Software implementation likely to be any more successful than a bespoke software implementation?

Packaged software is already written, but it still needs to be configured to meet the particular requirements of the business. This is typically done by setting variables within the systems database. These variables are read from the database at system start-up and they can be used to change its behaviour. The configuration process can range between a week and several months to complete. For example, SAP has over 8000 different switches that can be set to affect the system's behaviour (Bingi et al. 1999). Configuring these types of system often requires a great deal of specialist knowledge, combining a deep understanding of both the system and the business processes the system will support.

1.1.3 Critical Success Factors

Critical Success Factors (CSFs) have been used as a way to identify and rectify areas of poor performance on software implementation projects (Akkermans and Helden 2002). So, theoretically, if CSFs can be used to give an indication of problematical areas for projects, they can also be used to make comparisons between two different software implementation strategies. Critical Success Factors (CSFs) reported in the literature were examined and used to make comparisons between Bespoke and Packaged software implementations. The aim was to see if the comparison revealed any differences between the two methods and provide an indication if Packaged Software does indeed pose any special kinds of problems or risks when compared to traditional bespoke software projects. For bespoke software, the comparison used Ewusi-Mensah paper which cited seven critical factors that led to bespoke software development projects being abandoned (Ewusi-Mensah, 1997).

For packaged software, the only examples of studies into CSFs reported in the literature were for ERP systems. This is understandable as these types of projects are very expensive to implement and carry a high risk to the business implementing the system. It has even been known for poorly implemented systems to bankrupt the implementing organisation (Ward et al. 2005).

Six common CSFs were identified by all three papers. These were: 1. Team work and Team Composition. 2. Top Management support. 3. Project Management. 4. Project Champion. 5. Change Management Culture. 6. Business process reengineering in preference to software customisation (Fui-Hoon Nah et al. 2001), (Somers and Nelson 2001),(Nagi et al. 2007). Three of these factors aligned those identified by Ewusi-Mensah. These were: Senior Management Involvement, Project Team Composition and Project Management (Ewusi-Mensah, 1997). This suggests that there is some overlap between traditional software development and a Packaged Software

implementation project.

The remaining issues left identified by Ewusi-Mensah are more related towards the technical aspects of software development, whereas the remaining ERP factors are related to Business Processes and change management.

1.1.4 Customisation

Fui-Hoon Nah recommends that Business Process Reengineering in preference to customisation to avoid introducing additional costs and risks associated with software development (Fui-Hoon Nah et al, 2001). This basically means that it

is better to change the processes used by the organisation to produce its goods and services, so that they align with the software design. This approach is preferable to adapting the Packaged Software with specifically designed custom code to achieve the desired functions that could not be possible with system configuration alone.

Customisation also makes it harder to take advantage of newer versions and releases (Fui-Hoon Nah et al, 2001). While this approach is a cheaper option, it does impose changes to the Business Processes. This can cause resentment because the drive for change is dictated by the needs of the system. This is one of the human factors that Diamond identifies with the term Expert Authority. This is where end users perceive that change process is not a collaborative undertaking and that their work practices are being dictated by experts who understand how the new system works (Diamond, 1996). System knowledge is therefore the key to understanding how the Business Processes should be adapted to in order to fully exploit the capabilities of the system. The experts in this case would naturally be the Vendor/Consultants and their knowledge and expertise would be a prime factor for engaging their services. With Bespoke in-house systems developed by the IT group, it is this group that are often seen as the expert authority as they are the ones exerting change upon the Business. With this case the IT group is still part of the same organisation. However, with Packaged Software there is the danger that the notion expert authority is further amplified because it is coming from outside the organisation.

Not having to customise the software makes the implementation easier for the Vendor/Consultant as it eliminates the additional responsibility of having to develop bespoke software modules within the timeframes of the project. This was observed in a case study by Howcroft and Light where the consultant clearly did not want to adapt the software to fit the business (Howcroft and Light, 2006). So, expert advice may not always act in the interests of the Business, adding inefficiencies and costs by forcing them to change their processes to ones that may not be appropriate. This can also work the other way. Light has cited inappropriate expert advice being the reason for unnecessary customisations (Light, Feb 2005). This is why it is essential that the procured expert advice from the Vendor/Consultant has the necessary depth of knowledge and expertise. One of the advantages cited for Packaged Software is that they embody industry best practice (Howcroft and Light, 2006). Providing that the current processes do not give the organisation a unique competitive advantage, why wouldnt organisations want to change their processes to conform to the best practices. It would remove inefficiencies and costs from its processes and therefore increase their profitability.

To minimise customisation, there needs to be a good fit between the Packaged Software system and the business processes that the system has to support. So conventional requirements gathering needs to be supplemented with business process knowledge for Packaged Software systems because unlike 8

bespoke software, the functionality has already been defined in the Packaged Software. This requires a different skill set to match the requirements to the functionality of the Packaged Software (Butler, 1999).

The work of Edmundson and Jefferys highlights the importance of requirements analysis in the purchase of the system, but it also suggests that there is little evidence of increased user satisfaction relating to the quality of the user requirements (Edmundson and Jeffery 1984).

1.1.5 The Stakeholders

For bespoke software Mensah identified the composition of the project team as a major factor leading to projects that have failed (Mensah, 1997). All three of the papers for ERP CSFs highlighted ERP Teamwork and Composition as an important factor. Having Business Analysts/Consultants with both technical and business knowledge was identified as another major CSF (Somers and Nelson 2004).

For a Packaged Software project, the project team is typically comprised of members from the Vendor or Consultants, in-house IT and representatives from the Business. The knowledge of the content of the business processes and IT activities resides in different constituencies (Ward and Elvin. 1999). First there is the IT knowledge domain covering the experience of

implementing other IT systems. Second there is the Business knowledge that covers the area impacted by the system. The third area is that of the system supplier or the consultants that have the detailed knowledge of how the system operates and how to apply the technology. The domain model shown in figure 1 was developed by the author to use as a vehicle to illustrate and explore the issues and relationships between the three groups.

Figure 1 The major groups involved and their areas of knowledge.

Both IT and the Business have little or no knowledge of the system at the start of the project. One of the key differences between bespoke and packaged software is the removal of the traditional role performed by the IT department of

10

developing the actual software. With the development of the software having been effectively outsourced, what is the role of the IT department? This has created some uncertainty as to what the role of IT should be. Ward and Peppard observed, IT directors are unsure amongst themselves whether the role of the IT organisation is primarily to be engaged in a process that brings about business change, or to be the implementer of the consequences of change or merely to facilitate the activities of others (Ward and Peppard, 1996). Another important factor is that there are many reports in the literature suggesting that the relationship between the Business and IT departments in the context of the organisation has been characterised as highly divisive (Ward and Peppard, 1996) and (Coughlan et al. 2005).

11

1.2 Aims and objectives of the research project The aim of this study is to identify if Packaged Software implementations exhibit any special problems and risks when compared to conventional bespoke software projects. The objectives were: Identify the differences between the critical success factors (CSFs) for Bespoke, ERP and Packaged Software implementation projects, so that it may reveal unique factors for Packaged Software. To support this, the objective is to create a list of CSFs for Packaged Software, for comparison against existing CSFs lists for Bespoke and ERP Software found within the literature. Identify the advantages that Implementing Packaged Software has over writing bespoke software. Identify the disadvantages that Implementing Packaged Software exhibits when compared against bespoke software. Identify the main risk factors for a project implementing Packaged Software. Identify the best means of estimating the resources required for a Packaged Software implementation. Identify the key stakeholders for Packaged Software with the objective of devising recommendations for what their roles and responsibilities should be.

12

1.3 Overview of the dissertation The rest of this dissertation is structured as follows. Chapter 2 is a review of the existing literature on the implementation of Packaged Software. Chapter 3 describes the methods that were considered for the study and the reasons why the Delphi technique was chosen. Chapter 4 describes how the Delphi technique was applied for this study. It then describes the rationale behind the questions posed for the rounds of the Delphi study, so that they achieved the projects aims and objectives. The results and analysis are presented in Chapter 5 and Chapter 6 contains the studies conclusions.

13

Chapter 2 Literature Review

2.1 Why use Packaged Software? As an alternative to developing Software in-house, many IT departments now prefer to buy in Packaged Software that can be configured to meet their organisations IT and Business needs (Janson and Subramania, 1996). The reason for this is that Packaged Software promises reduced costs and the ability to deliver complex systems in a relatively short period of time (Butler, 1999). Using software with a proven track record helps to reduce the risks for an implementation project because the majority of the development work has been completed (Tayntor, 2006). Also, purchased software will have generally been written by suppliers who specialise in niche market sectors, leading to richer functionality that would not have been cost effective if it was developed in-house. Although the risk of developing the system is removed from the equation, these types of systems are usually highly configurable and still require careful elicitation of requirements and business processes to ensure that the system is configured correctly to fit the business environment that it is to operate in.

To understand how these cost savings are achieved, a brief examination of the software development process is needed. The Waterfall process model is the most common one followed. See Figure 2.

14

Figure 2 Traditional Waterfall Software Development process model.

Figure 3 Traditional Waterfall process model for Packaged Software.

15

2.2 The Benefits of Packaged Software

Reduced development costs when compared to the costs of inhouse developed systems because the costs of development are spread across more than one organisation (Tayntor, 2006).

Reduced maintenance costs because they are spread across the suppliers customer base (Tayntor, 2006). This also effectively outsources software maintenance so the organisation does not have to employ expensive, specialised skilled IT staff to maintain it (Sherer, 1993).

Compliance with new regulatory and legal requirements becomes the responsibility of the Software vendor (Butler, 1999). The framing of regulations and law often leaves them open to different interpretations. So it can be advantageous for everyone involved in the auditing process if everyone in the industry sector also uses the same systems and interpretations of the regulations.

The risks associated with developing software are removed because the software has already been developed (Tayntor, 2006).

16

Because the software has already been developed it means that it can be implemented faster than if developed from scratch.

Improved quality and reliability. In-house developed software, by its very nature, tends to be only used by one organisation. Packaged Software is used more widely, therefore increasing the likelihood of defects being identified and therefore rectified.

2.3 The disadvantages of Packaged Software

The configuration of some Packaged Software systems can be just as complicated as a bespoke software development. For example SAP has over 8000 switches that can be used to configure it (Bingi et al. 1999).

Packages may overcome problems with existing software at the expense of control over the systems development process (Light, May 2005).

Now that it is a common strategy to use standard Packaged Software there is an argument that this limits an organisations ability to innovate (Peppard and Ward 2004).

17

2.4 Critical Success Factors for Software Implementation Critical Success Factors (CSFs) have been used as a way to identify and rectify areas of poor performance during software implementation projects (Akkermans and Helden 2002). So theoretically, if CSFs can be used to give an indication of problematical areas for projects, they can also be used to make comparisons between different software implementation strategies. The CSFs reported in the literature were examined and used to make comparisons between Bespoke and Packaged software

implementations. If the comparison revealed any differences between the two methods it would provide an indication if Packaged Software posed any special kinds of problems or risks when compared to traditional bespoke software projects. For traditional software development projects, (Ewusi-Mensah, 1997) cited seven critical issues that led to projects being abandoned. These were:1. Project Goals. 2. Project Team Composition. 3. Project Management and Control. 4. Technical know-how. 5. Technology base or infrastructure. 6. Senior management involvement. 7. Escalating project cost and time of completion.

18

For Packaged Software, the only examples of studies into CSFs reported in the literature were for ERP systems. This is understandable as these types of projects are very expensive to implement and carry a high risk to the business implementing the system. It has even been known for poorly implemented systems to bankrupt the implementing organisation (Ward et al. 2005). Their popularity and the high stakes involved make it understandable that ERP systems have been the main focus of academic studies.

Three papers were chosen to represent the CSFs for ERP systems. The papers by Fui-Hoon Nah et al. and Somers and Nelson were chosen because they were widely cited in the literature. (Fui-Hoon Nah et al, 2001), (Somers & Nelson, 2001). The third paper by Nagi et al. was chosen because it was latest study found at the time of writing. (Nagi et al, 2007).

Three papers were examined and the results are shown in figure 4.

19

Figure 4 ERP Critical Success Factors

20

There was a general consensus on 6 main themes which were:-

1. Top Management support. 2. Project Management. 3. Project Champion. 4. ERP Team work and Team Composition. 5. Change Management Culture. 6. Changing the Business Process to fit in with the software should be preferred over customisation of the software.

Three of these ERP factors aligned those identified by Ewusi-Mensah. These were Senior Management Involvement, Project Team Composition and Project Management (Ewusi-Mensah, 1997). This suggests that there is some overlap between traditional software development and a Packaged Software implementation project.

The remaining issues left identified by Ewusi-Mensah are more related towards the technical aspects of software development, whereas the remaining ERP factors are related to Business Processes and change management.

21

The three top ERP CSFs not identified by Ewusi-Mensah were: ERP Team work and Team Composition Change Management Culture Changing the Business Processes to fit in with the software.

These factors focus on having cross-functional teams, change management and Business Processes.

2.5 Changing the Business Processes instead of Software Customisation. One of the main critical success factors identified was Change the Business Process instead of customisation. What does this mean? Going back to first principles, the purpose of the system being implemented is to support some purposeful activity. (Checkland and Holwell, 1998). In this case the purposeful activity to be supported is the delivery of goods or services provided by an individual or an organisation which is generally referred to as a Business. Business Process Modelling is the term used to describe the various techniques defining tasks and their sequencing to achieve the manufacture of the good or provide services. So the CSF statement is saying that when there is a mismatch between the

22

requirements needed to support the business process and the capabilities of the software the preferred resolution is to modify the business process and not the software.

One of the main reasons for implementing Packaged Software is reduced costs, because the supplier can spread the costs of developing the software across all their customers. Implementation time is also reduced because the software is prewritten and tested. However, prewritten software also causes one of the major problems associated with implementing Packaged Software. This is because of the incompatibility of the softwares features with the organisations information needs and business processes (Janson and Subramania 1995).

Where there is an incompatibility between the Software and the organisations business processes, a choice has to be made between modifying the software to fit the business and modifying the business processes to fit the software. Modifying the business process is often referred to as Business Process Reengineering (BPR).

One of the findings from their study into selection and implementation policies for Packaged Software systems found that a good fit between software and organisation had a positive impact on the implementations success. This should not be too surprising as it suggests that the software 23

met the organisations requirements. The work of Edmundson and Jefferys also highlights the importance of requirements analysis in the purchase of the system. However it also suggests that there is little evidence of increased user satisfaction relating to the quality of the user requirements (Edmundson and Jeffery, 1984).

In order to minimise customisation, there needs to be a good fit between the Packaged Software system and the business processes that the system has to support. So requirements gathering and understanding the business processes is more important when implementing a Packaged Software system than it is when developing software because the Packaged Software functionality has already been defined. This requires a different skill set to match the requirements to the functionality of the Packaged Software (Butler, 1999).

By introducing customisation of the software into the equation, all the risks associated with software development are now reintroduced into the project. To quote Butler, it is just as difficult for a software supplier to develop software as it is for an in-house organisation. (Butler, 1999).

Another reason for trying to avoid customisation cited by Butler and FuiHoon Nah is that the customisation makes it more difficult to upgrade the system in the future to a newer version (Butler (1999), (Fui-Hoon Nah et 24

al, 2001). Application support can also be hindered as the vendor may not be able to fully replicate the symptoms of the problem as they need to have a system available with the customers specific customisations (Kyte, 2009.)

However there can be valid reasons for customisation (Light, Feb 2005). He observed the following valid reasons for customisation: The system does not have the functionality to support critical business activities. The simplification of inappropriate user screens. System testing had indicated that if user screens had not been modified, extra operating expenses would have been incurred due to errors made by the systems users. The organisation felt that the system did not embody Best Practice. If the standard functionality of the system were to be used there would be a significant business risk. The system was customised to support ways of working that were perceived to add value and a competitive advantage in the market place.

25

(Light,

Feb

2005)

subsequently

suggested

other

reasons

for

customisation: To correct defects in the system. If the vendor is unable to respond to maintenance or product development needs of the customer. If the system vendor feels that the features required by the customer are of limited value to the rest of their customers, then the customer would have to develop the functionality themselves. To reduce exorbitant maintenance fees. Vendor is no longer in the market. The purchasers of the software did not fully understand their organisations requirements and how they fitted with the system they purchased. Expert advice to customise the system may not have been so Expert and the customisations they recommended were not necessary.

Some of the reasons Light cites for customisation counter some of the reasons for choosing a Packaged Software solution. An example of this is customising the system to correct defects. One of the main reasons for choosing a Packaged Software solution is that it is of a higher quality and less likely to have defects. To quote Butler again: it is just as difficult for a software supplier to develop software as it is for an in-house organisation (Butler, 1999). Because the Vendors are in the business of developing

26

software, they are more likely to be continually improving their development process because, unlike in-house development teams, their core business depends on the development of good software. Also the broader user base of commercial software increases the chances of defects being found. Problems with Packaged Software are most likely to occur when using the less popular features of the software.

Fui-Hoon Nah makes the point that Business Process Reengineering should be preferred over customisation in order to avoid the introduction of the risks associated with software development (Fui-Hoon Nah, 2001). This suggests that successful Packaged Software implementation requires some degree of Business Reengineering as these packages try to appeal to a broad market base in order to be commercially viable. One of the advantages cited for Packaged Software is that they embody industry best practice across the industry sector that it is aimed for (Howcroft and Light, 2006). So, unless it was to accommodate a unique feature essential to the business or it gives an advantage, it makes sense to adopt best business practice and change the Business Processes to fit the software.

Choosing to modify the business process to fit the software can invoke more change in the business than bespoke software. Unlike Packaged, Bespoke software can be explicitly designed to fit the existing business processes and therefore reducing the amount of change required in the business. 27

2.6 The Stakeholders For bespoke software, Mensah identified the composition of the project team as a major factor contributing to project failure (Mensah, 1997). All three of the papers for ERP CSFs highlighted ERP Teamwork and Composition as an important factor. Having Business

Analysts/Consultants with both technical and business knowledge was identified as another major CSF (Somers and Nelson, 2004).

For a Packaged Software project, the project team is typically comprised of members from the vendor or consultants, in-house IT and representatives from the business. The knowledge of the content of the business processes and IT activities resides in different constituencies (Ward and Elvin, 1999). First, there is the IT knowledge domain covering the experience of implementing other IT systems. Second, there is the Business knowledge which covers the area impacted by the system. The third area is that of the system supplier or the consultants that have the detailed knowledge of how the system operates and how to apply the technology.

28

2.6.1 The IT Department

Both IT and the Business have little or no knowledge of the system at the start of the project. One of the key differences between Bespoke and Packaged Software is the removal of the traditional role performed by the IT department of developing the actual software. With the development of the software having been effectively outsourced, what is the role of the IT department? This question has created some uncertainty as to what ITs role should be. Ward and Peppard observed that, IT directors are unsure amongst themselves whether the role of the IT organisation is primarily to be engaged in a process that brings about business change, or to be the

29

implementer of the consequences of change or merely to facilitate the activities of others (Ward, Peppard 1996).

Another important factor is that there are multiple reports in the literature suggesting that the relationship between the business and IT departments in the context of the organisation has been characterised as highly divisive. (Ward and Peppard 1996) and (Coughlan et al. (2005)

The most common approach for software projects starts with the Business having a set of requirements which are then handed over to the IT department who then go away and build the system. The system is tested to ensure that it delivers the requested requirements before handing it over to the business. This view of the software development process follows the Traditionalist change agent role described by Markus and Benjamin (Markus and Benjamin 1996). The view is that the technology can be relied on to make the change and IT don't have to "do" anything other than build systems or install technology (Markus and Benjamin, 1996). They then go onto suggest that IT sees their role as

being purely to deliver the technology and that this will enable the Business to achieve the benefits that they were seeking.

There are numerous accounts of IT systems failing to deliver still appearing in the literature, possibly suggesting that Packaged Software is 30

not without its problems. A lot of the blame for failure in the past has focused on the process of software development. By using Packaged Software, the risks of developing the software have now been transferred from the Business to the software vendor. Yet there is still a considerable risk for the organisation implementing the software. Markus and Benjamin put forward two roles for IT, those of facilitator and advocator (Markus and Benjamin, 1996). In the role of facilitator, the IT function is to provide the Business with information and advice about their options for satisfying their system requirements. For the Implementation of Packaged systems, this could be an effective role for IT to play as observed by Mockler and Chao (Mockler and Chao, 2006). Butler also states that there is a need for a special skill set which has the ability to be able to match requirements against system capabilities (Butler 1999). The Advocate role that Markus & Benjamin put forward, suggests that the IT department takes responsibility for both system delivery and all the necessary Business Process changes (Markus and Benjamin, 1996).

It is questionable if IT have the skills to implement Business Process change or if the changes would be fully adopted. Changes to the Business Process can cause resentment because the need for change has been brought about by the implementation of the system. This is one of the human factors that Diamond identifies with the term Expert Authority (Diamond, 1996). Here the IT Department would be seen as the Expert Authority as well as not being directly impacted by any of the

31

consequences of the changes.

Markus & Benjamin conclude from their

analysis of the literature that IT specialists alone cannot achieve IT implementation success (Markus & Benjamin, 1996).

2.7 Summary Packaged Software is a popular choice for implementing new software systems into an organisation as it has many compelling advantages. However, with the exception of ERP systems, little research appears in the literature on this subject.

Critical Success Factors (CSFs) have been used as a way to identify and rectify areas of poor performance during software implementation projects. There have been numerous studies to develop CSFs for ERP systems and for Bespoke Software developments, but none specifically aimed at Packaged Software.

There are many reports in the literature referring to organisations having troubled relations between their IT departments and the rest of the organisation. Because Packaged Software is pre-written it has removed one of the traditional software development roles performed by the IT department. Also it has introduced a third party into the equation. That is the software vendor or implementation consultant. This has created some uncertainty as to what the roles and responsibilities of all three parties involved should be. 32

Chapter 3 Research Methods

This chapter discusses the research methods that were considered to achieve the main objectives of the project. The primary aim of this study was to identify if Packaged Software implementations exhibited any special problems and risks when compared to conventional bespoke software. The chosen method also had to be capable of identifying who the main stakeholders were and what the roles and responsibilities should be for the three groups: Business, Vendor/Consultant and IT. Reports in the literature have indicated that the relationship between the Business and IT groups has been a difficult one. Packaged Software also removes the need to develop the software, a traditional role performed by the IT group. With these issues in mind, it was important that the adopted research method encompassed the views and opinions from all three groups. The following sections discuss the methods considered before finally going onto discuss the Delphi method and why it was chosen.

3.1 Other Techniques 3.1.1 Case Study

The review of the current literature has shown that most of the research on Packaged Software has been confined to researching the implementation of Enterprise Resource Planning (ERP) systems. The use of case studies has been a popular and effective method for investigating the issues surrounding ERP system implementations.

33

Case studies have been used to identify critical success factors for ERP systems such as the study conducted by Sumner (Sumner, 1999). They have also been used to study other aspects of ERP implementations such as Lights investigation into the customisation of ERP systems (Light, Feb 2005).

A case study was initially given strong consideration. An ideal candidate for the study was the implementation of a Packaged System for monitoring employees time and attendance. The system had been implemented with varying degrees of success on three different sites within the same organisation. The key point of interest was that the system was implemented by different teams led by the Business and IT groups, with the constant factor being the system itself. Like ERP systems, its

implementation impacted on a diverse population of end users comprising of scientists, engineers, managers, office, production, warehouse and casual workers. The aim would have been to show if it is better to implement a Packaged Software as a Business or IT project. This is because the technical aspects of the system could be discounted.

The main difficulty of using case studies to formulate conclusions and theory is because they are limited to a single set of events and the unique dynamics particular to the implementation being studied. In order to be more useful, case study theory and conclusions are usually made up from a number of individual studies. For example, Sumner used seven case 34

studies for different organisations implementation of ERP to devise her list of CSFs (Sumner, 1999). It was felt that it would be beyond the resources available to find enough suitable cases to study to make this approach effective.

The case study approach under consideration would have only looked at projects that had been executed within one organisation and, like previous studies into ERP systems; it is restricted to only one type of system. This would have made the study of limited interest to a wider audience outside the organisation. More importantly, a study into Packaged Software should ideally cover more than one type of Packaged Software system. The final reason for discarding the proposed case study was the risk of introducing bias into the study. This was because of the authors close involvement in one of the implementations.

3.1.2 Questionnaires

Somers & Nelson successfully used a questionnaire methodology for their investigation into ERP that resulted in a list of twenty two CSFs (Somer and Nelson, 2001). Using the Fortune 500 and a directory of top computer executives, they targeted 700 companies for their questionnaire. Due to their popularity, there was a high probability that most of the companies targeted would have implemented an ERP system. Yet only 86 of the questionnaires returned were actually usable in their study. It was considered doubtful that a similar list of companies could be put together 35

that would yield enough useful results for other types of Packaged Software systems. This is because Packaged Software tends to provide specialist niche solutions that are not generally applicable to every organisation. It was also felt that the analysis process would have taken longer than the time available for the project.

3.1.3 Interviews

Interviews were considered and could have been a viable alternative to the method that was finally selected. However, it was rejected because it was felt that it would be too difficult to ensure the repeatability and to collate the answers. The other deciding factor was the diverse geographic locations of the intended participants, making it difficult to arrange mutually convenient times to conduct the interviews. There was also a potential for introducing bias into the interview because of the authors role within the IT group and that the intended participants were all known to the author.

3.2 The Delphi Technique The issues surrounding the subject matter of the project are complex, requiring IT and business knowledge as well as an understanding of the principles of change management. It was for this reason the Delphi technique was the chosen method for conducting the primary research for this project based on the work of Okoli and Pawlowski. (Okoli and Pawlowski, 2003). The Delphi technique was developed in the 1950s by

36

the RAND Corporation as a tool for harnessing the views of experts. Figure 5 briefly shows how the Delphi technique works.

Figure 5 The Delphi technique

adapted from www.mycoted.com

According to Okoli and Pawlowski, Delphi is a popular choice for IT research and analysis of their study indicated that it would be a good choice of tool for this project (Okoli and Pawlowski, 2003). There are three main groups of expertise within the problem domain and these are: IT, Business and the Packaged Software supplier. By adopting one of the

37

principles of Soft Systems Methodology, it is important to consider different world views of the problem area (Checkland and Holwell, 1998). The expert panel in this case was made up of practitioners from the three main groups that are typically involved in a Packed Software system implementation and these are: -

Business Managers who requested the system, or systems owners and end users.

IT Managers responsible for implementing Packaged Software systems on behalf of their businesses.

Representation

from

the

vendor/consultants

supplying

the

Packaged Software.

The main reasons for deciding to use the Delphi technique were: 1. The design is very flexible in that it can be adapted as the research proceeds. It can also be followed up with interviews if required. This was an attractive feature as it offered the possibility of correcting mistakes or implementing new learning as the project progressed.

38

2. The anonymity given to individual panel members. A key feature of the research is to gain an insight into views from the different groups that would be involved in a typical Packaged Software implementation. The anonymity would allow panel members to answer more freely without fear of compromising the client customer business relationship.

3. The anonymity of the panel members would also allow any issues between the groups to be explored within a non-confrontational environment.

4. The literature recommends 10-18 experts on a Delphi panel and this was considered practical to implement (Okoli and Pawlowski, 2003).

5. The Delphi technique does not require the panel to meet physically, making it easier to consider the use of experts from a range of organisations and geographic locations.

39

3.3 Summary This chapter discussed the methods that were considered for this study and the justification for choosing the Delphi technique. The main reasons for choosing the Delphi technique were: 1. Its flexible design. 2. The anonymity of the panel members. 3. It is a non-confrontational environment in which to explore difficult issues. 4. Only 10-18 expert panel members are required. 5. The panel do not need to meet up. 6. It has the promise of being able to explore the issues from the viewpoints of the three groups.

40

Chapter 4 Data Collection

4.1 Data Sources All the primary data for this research project was obtained from an Expert panel using the Delphi technique. The panel consisted of twelve people, and this followed the literature recommendation of having 10-18 experts on the panel (Okoli and Pawlowski, 2003). All twelve panel members were known to the author and they evenly represented the three main groups, The Business, IT, and Vendor/Consultant. The panel was made up as follows: -

Business Group: - Three members of this group came from different Business units within the Catalent organisation. Each Business unit operates within different sectors of the pharmaceutical industry, and have their own organisational culture and processes. A factor in the choice was concern about making this study relevant to a wider audience outside of Catalent. Therefore, relevant experience from previous roles held outside of Catalent was considered important as well as experience in implementing Packaged Software. The fourth member of this group came from a Property Management consultancy firm and had experience of implementing Business automation software solutions for clients.

41

IT Group: - This was made up with two practising IT Project Managers and two IT Business Partners. The IT Business Partner is an advisory/interface role that acts as an interface between IT and the Business. The experience within this group covers IT consulting, IT Management, application development as well as the implementation of numerous types of Packaged Software including ERP systems.

Vendor/Consultant Group: - This group is made up from three software vendors and a third party implementation consultancy.

4.2 Process Prior agreement was sought from all the panel members prior to distribution of the first questionnaire. Overall, the Delphi study consisted of two rounds of questionnaires that were completed by all twelve members of the panel.

42

4.2.1 Round One Questionnaire

The first round questionnaire closely followed the Delphi technique by asking the panel open-ended questions to elicit their views and opinions about the issues surrounding Packaged Software. The questions were arranged under four headings: Critical Success Factors and Risks. Project Resource Estimation. Project Stakeholders. Software Customisation.

Critical Success Factors and Risks

This section aimed to satisfy the research aim of creating a list of CSFs specifically for Packaged Software implementations. The panel members were asked to consider what their top six Critical Success Factors would be for a Packaged Software implementation. The number of CSFs was deliberately restricted to six to avoid similar variations on the same theme, which can be a problem with using the Delphi method (Okoli and Pawlowski, 2003). This had been one of the difficulties of doing the analysis for the ERP CSFs, which had over twenty different CSFs with an element of duplication between them.

43

This section also asked the panel about the Advantages, Disadvantages and the Risks that they associated with Packaged Software projects.

Project Resource Estimation

The purpose of this section was to gain an understanding from the panel members about the issues surrounding estimating resources requirements for these types of projects. The aim was to elicit different techniques. For example, one such technique is Function Point Analysis. It involves decomposing the User Requirements into the functions that will eventually form the building blocks of the final system. Each function is then

assigned a weighting factor based on its complexity and these figures are used to calculate the final estimation for the time and resources required to build the system.

Stakeholders

The aim of this section was to establish who the panel thought the key stakeholders were, before identifying roles and responsibilities for the Business, Vendor/Consultant and IT groups.

44

Customisation

One of the critical success factors for ERP systems that featured highly in the literature is the issue of customisation. Where there is a gap between the functionality of the software and the User Requirements, it is recommended, wherever possible, that the Business Processes should be changed to fit in with the software. The final part of the questionnaire was aimed at verifying this with the panel members. Whilst this may apply for ERP systems, the panel had experience of other types of Packaged System implementations. So the aim was to see if the strategy of always preferring to change the Business Process would also be the same for other Packaged Software applications.

The other objective for this last section was to see if the panel used any methods for evaluating the Business Benefits against the costs of customising the software to fit in with existing Business Process.

Appendix B shows the full questionnaire that was sent out to the panel.

Research

Research was carried out into how to construct the questionnaire. Bell and P Murray were used to provide information on how to go about this task

45

(Bell, 2005), (Murray, 1999). The Flesch Reading Ease Score was used in conjunction with the word count features in MS Word as a further guide to the wording of the questionnaire. This was considered to be important because English was not the first language of some of the participants.

Pilot

Before submitting the questionnaire to the panel, it was piloted with colleagues with a view to sense check the questions and the type of responses that they elicited. It also provided a useful rough guide for questionnaire completion times. The literature on questionnaire design suggested that if it took too long to complete, then there was a real danger that it may not get completed. Given that the Delphi panel was only made up of 12 members, only a small number of panel members failing to complete would have a big impact, and quite possibly put the whole project at risk.

4.2.2 Round One Analysis

The Delphi method with its open-ended questions generates a large amount of qualitative data. The consolidation of the data is subjective and open to different interpretations and ambiguously worded answers. It was also noted that it was difficult to match the CSFs identified by Holland & Light for ERP against the summary of CSFs found in the literature review that was carried out by Somers & Nelson (Holland & Light, 1999), (Somers

46

& Nelson, 2001). This was due to the different wordings used in Somers & Nelsons review.

In order to provide full traceability of the results back to the primary data gathered, and ensure no original responses had been missed from the summarised results, the following methodology was adopted:1. The results from round one were compiled into a table, as shown in appendix c, d and e, with each response being a separate row on the table. 2. Where the responses had been combined into a single paragraph; they were split into separate lines by looking for keywords and the individual points made.

47

4.2.3 Questionnaire Two

Questions for this round were grouped as follows:1. Business groups roles and responsibilities. 2. Vendor/Consultant groups roles and responsibilities. 3. IT groups roles and responsibilities. 4. Key Stakeholders for Packaged Software. 5. Risks for Packaged Software.

For the first four sets of question groups, the panel were asked to select from a list if they Strongly Agreed, Agreed, Disagreed or Strongly Disagreed with the statements that were presented to them.

For the risks identified in round one, the panel was asked to consider the probability of the risk occurring, and if it did occur, what was the likely impact. Again the panel were asked to select their answers from a list of values ranging from Low, Medium and High. All of these questions followed the Delphi technique, requiring the panel to deliberate and refine the answers gathered in round one.

48

Lastly, the panel were presented with the consolidated list of Advantages, Disadvantages, and the Critical Success Factors for Packaged Software identified from round one. Following the Delphi method the consolidated list could have been presented back to the panel in round two, asking them further questions such as ranking the CSFs in order of importance or further refining the list by voting for their inclusion. In this case the aim was to create a list of CSFs that could be compared against the CSFs identified in the literature for ERP and Bespoke systems. Although it would have been interesting to have a ranked list of CSFs, it was felt that it would consume too much time with very little gain. This deviated from the Delphi technique as the consolidated list was submitted to the panel in round two for the purpose of validating the consolidated results obtained from round one. Obtaining verification from the panel is recommended in the literature and this was considered particularly important as this section deviated from the Delphi technique (Okoli and Pawlowski, 2003) The questions in round one for estimation, customisation and the difference in the stakeholder roles did not yield suitable data that could be subsequently used in round two. Although they did reveal some interesting information, the questions turned out not to be suitable for a Delphi study as they did not reveal a variation of opinions that could be evaluated in later rounds.

49

4.2.4 Round Two Analysis

The data returned is based upon simple Likert scales that are only an indication of the respondents strength of feeling towards the question being asked. This, combined with the small sample population of the Delphi panel, make the data unsuitable for any purposeful statistical analysis. The analysis for this round has concentrated on response frequencies and how the responses compared between the groups. For the Stakeholder and the Roles and Responsibilities, the answers were compiled into tables with the responses arranged under the three groupings of Business, Vendor/Consultant and IT. Colour coding was used to highlight and contrast the strengths of feelings both within and between the groups. The results for the Risks were handled in a similar way and are described in detail in appendix G. The results were compiled into a graph showing the risks by probability of occurrence and their impact it they did occur.

4.3 Summary The primary data for this study was obtained from an Expert panel using the Delphi technique. The panel consisted of twelve members and they evenly represented the three groups, Business, Vendor/Consultant and IT.

50

Chapter 5 Results
In this chapter, the studys results and analysis are presented. The study set out to identify whether Packaged Software implementations exhibited any special problems and risks when compared to conventional bespoke software projects.

5.1 Critical Success Factors The identification of CSFs specifically for Packaged Software was one of the objectives of this study. The intention was to compare them with the CSFs identified from the literature for ERP and Bespoke software implementations. The following tables show what the panel considered to be their top six critical success factors for a Packaged Software implementation.

51

Figure 6 Round 1 CSFs 1 of 4

52

Figure 7 Round 1 CSFs 2 of 4 53

Figure 8 Round 1 CSFs 3 of 4

54

Figure 9 Round 1 CSFs 4 of 4

55

The

results

have

been

consolidated

and

grouped

into

Business,

Vendor/Consultant and IT to contrast differences in factors based upon the differing viewpoints.

The System/Vendor section was one of the more notable sections for highlighting the different concerns between the groups and the influence that they appear to have had on their chosen CSFs. For example, Parallel Operation that could enable a smooth transfer between the old and new systems is a CSF for the Business Group. This is because it offers the promise of being able to maintain business continuity. This compares with the Vendor/Consultants who cited CSFs that dealt with the quality of the Packaged Software system and the services that they provided. They place importance on factors that impact on Customer Satisfaction, which in turn ultimately impact on the Vendors/Consultants reputation, their ability to win future orders and thus secure the long-term viability of their business. Lastly, there is the IT group who had CSFs concerning the working relationship between the Vendor/Consultants, and contractual issues designed to ensure that the organisation retained some financial leverage to ensure that the software is fully implemented to their satisfaction. Both the IT and Vendor/Consultant groups recognised that the long-term financial health of the Vendor was a CSF.

56

5.1.1 Consolidated list of Critical Success Factors from round 2.

The following tables show the Critical Success Factors for a Packaged Software implementation that were identified by this study.

Table 1 Critical Success Factors for Packaged Software 1 of 5

57

Table 2 Critical Success Factors for Packaged Software 2 of 5

58

Table 3 Critical Success Factors for Packaged Software 3 of 5

59

Table 4 Critical Success Factors for Packaged Software 4 of 5

60

Table 5 Critical Success Factors for Packaged Software 5 of 5

Studies specifically aimed at investigating the Critical Success Factors for Packaged Software were found not to be widely reported or discussed within the literature. The results of this study have produced a set of CSFs that are specifically for Packaged Software and should be a useful addition to the existing body of knowledge for Packaged Software. However, the primary purpose for investigating and compiling CSFs for Packaged Software was to make comparisons between the CSFs for ERP and Bespoke software.

61

Figure 10 Critical Success Factors comparison between ERP and Packaged Software 62

The aim of the comparison was to see if it revealed any unique factors for Packaged Software. Figure 10 shows how the CSFs found for Packaged Software compared with those found within the literature for ERP systems. Figure 10 shows that two thirds of the CSFs listed from the literature for ERP systems do have a direct correspondence with the CSFs found in this study for Packaged Software. The CSFs highlighted in yellow in figure 10 were not identified as CSFs for Packaged Software and therefore could be considered to be more likely to be specific to an ERP system. However, occasionally they may be appropriate, but may not have made the list because the panel were specifically asked to list their top six CSFs. The CSFs identified in the study for Packaged Software matched two thirds of those identified in the literature for ERP systems, whilst those that did not match were mostly ERP-system-specific. All the CSFs found for Packaged Software could be matched to one or more CSFs identified in the literature for ERP systems. So the conclusion is that CSFs found in the literature for ERP systems can also be applicable to Packaged Software.

Despite this being a limited study, representing the views of only twelve experts, it is felt that further study into CSFs for Packaged Software would not yield anything significantly new that has not already been discovered by previous studies reported in the literature for the CSFs for ERP systems.

63

5.2 Customisation One of the CSFs identified in the literature for ERP systems was change the Business Process instead of customising the software package. This is a key factor that is different between ERP and Bespoke software implementations. The questions in round one set out to see if this CSF for ERP systems also applied to all Packaged Software implementations.

On the whole, the panel agreed that this CSF did apply to Packaged Software, but it was dependent upon the circumstances. In the question about CSFs, it was also identified specifically by the panel as a CSF for Packaged Software.

The main reasons that the panel had for changing the Business Process in favour of customisation were to align the processes with industry best practice embodied within the software and the avoidance of the additional costs of the customisation.

The majority of the panel qualified their agreement for changing the Business Processes in preference to customisation as being dependent on the circumstances of the implementation. This means that there needs to be a clear understanding of the Business benefits that the system will bring along with its aims, objectives and requirements. Having accurate and complete business requirements prior to assessing the software package was another

64

CSF identified by the panel. Also one of the Vendor/consultant panel members recommended that the intended Business Processes should be explored before starting on the selection process and this was also a practice recommended by Tayntor (Tayntor, 2006).

In response to the question, when would it be appropriate to customise the software in preference to changing the Business process, the panel responded with the following reasons: -

When a critical objective cannot be achieved by Business processes alone. When customisation is needed to ensure regulatory compliance. When process is not an industry standard or it is ahead of the software in terms of industry best practice. Reports where data is only read from the system. Where the vendor provides a supported interface that enables other software to link into it and extend its functionality. When the customisation provides a clearly measurable Business benefit that justifies the cost of the customisation.

To summarise, when gaps are identified between the requirements and the functions offered by the Packaged Software, the panels qualified opinion was that changing the Business Processes should be undertaken in preference to customising the software. This was in line with the same CSFs identified in the literature for ERP (Fui-Hoon Nah et al, 2001), (Somers & Nelson, 2001), (Nagi et al, 2007). 65

5.3 Advantages of Packaged Software

Table 6 Advantages of Packaged Software

66

5.4 Disadvantages of Packaged Software

Table 7 The disadvantages of Packaged Software 67

5.5 Risks The Packaged Software risks identified by the panel are displayed in a graph plotting both probability and impact for each risk. See figure 11. A high impact risk can be devastating even though it has low probability of occurrence. For example, the risk having the highest impact, The inability of the vendor to provide timely and skilled support scored a low probability of occurrence.

68

Risks for Packaged Software Implementations

Figure 11 Risks for Packaged Software Implementations

69

5.6 Key Stakeholders

Table 8 Key Stakeholders for Packaged Software

Table 8 shows the results from the second rounds questionnaire, which asked the panel to verify the full list of key stakeholders for Packaged Software implementation identified in round one. There was broad agreement within the panel about all of the stakeholders that were identified. However it was only the Business Sponsor stakeholder that stood out with a Strongly Agreed result. 70

In round one the Project Manager (PM) was cited as a key stakeholder by both Vendor and IT groups, but did not feature in any of the returns from the Business group. Two distinct PM stakeholders were also identified. One was from the Vendor and the other from the organisation having the software implemented. Both have roles of co-ordinating the activities within their respective organisations and typically work together to ensure that the overall project objectives are met. In round one, the panel were asked if any of the key stakeholders identified for a Packaged Software implementation would not be involved in a bespoke implementation. Apart from the Vendor, the only other stakeholder identified as not being involved was Senior Management, which was cited by two members of the panel representing the Vendor group. Their reason was that typically Bespoke Software development is conducted using internal resources and is not subject to capital expenditure requests that go before the Senior Management for approvals.

The panel were also asked if the stakeholders identified for a Packaged Software implementation would have to perform different tasks or roles if the decision had been to implement Bespoke Software instead. Here there were marked contrasts in the responses from the three groupings within the panel. The IT group did not view Packaged Software as being very different to a bespoke implementation. The Business group did see a need for more

71

involvement of the IT group, especially around specifying requirements and design for a Bespoke Software project. The Vendor group viewed Bespoke developments having the same stakeholders, but they would be tied up for longer because of the extra time required to design, build and test the software. They also suggested that the role of the Project Manager would be more demanding due to the constant pressure to control the scope of the project.

The following were identified by this study as key stakeholders for a Packaged Software implementation: Senior Management. Benefactors: - Those who are to gain most from a successful implementation and have the ability to see ROI benefits. Customers: - Those who use the process both internally and externally. Implementation team. Quality/Validation. IT sponsor. Business Sponsor. Vendor/Implementation partner. Finance. 72

Program Manager - Senior member from the project Management group.

IT: - For technical infrastructure. Business Lead - Process owner. Business users / Primary users / End user representatives. Vendor Project Manager. Support staff. Business Project Manager - Managing the whole project on behalf of the business.

There was, however, a range of views expressed about Project Managers. This will be discussed further later in this chapter when the results for the roles and responsibilities for the groups are discussed.

73

5.7 Roles and Responsibilities for the Business Group

Table 9 Business roles and responsibilities

Of the three groups, it was the Business group that had the most agreement amongst the panel about what their roles and responsibilities should be. An explanation for this could be because there is very little difference in the roles performed by the Business group for either a Bespoke or Packaged Software 74

implementation. This was confirmed by the answers to the question in round one asking if any of the stakeholder roles would be different for a Bespoke Software project. The panel did not identify any significant change for the Business group. The main changes identified being the development activities performed by the IT group. Obviously, the roles for Vendor/Consultant group would disappear. One of the main areas of disagreement within the panel was the responsibility for ensuring that the technical platform was in place. The IT group members of the panel were unanimous in their disagreement that this should not be a role for the Business, as shown in figure 12. The coloured bar in the middle of the chart is used to indicate the strength of feeling for each of the three groups and the radar graph in the middle shows the panels overall opinion. The conclusion that can be drawn from this is that it is principally the role of the IT group to provide the technical infrastructure needed to support the software. This is supported by the panels unanimous view that this is an IT role. See table 11, IT roles

75

Figure 12 Business responsibility for ensuring the technical platform

This role for the Business group was suggested by one of the Vendor representatives on the panel in round one. From the Vendors perspective the Business is the Customer and they need to ensure that the infrastructure is in place. As far as the Vendor is concerned they do not care if the Business undertakes the task themselves, contracts it out or gets their IT department to undertake it. So this responsibility is for the Business to ensure that it gets done, but the details about how this is achieved are the responsibility of the IT group. For organisations that are not large enough to support an IT 76

department, it remains the responsibility of the Business and not the software Vendor to supply the technical infrastructure.

The panel broadly agreed that the Undertaking of data preparation and the quality of the data is the Businesss responsibility. However there was one dissenting view coming from one of the Business representatives on the panel. This activity is also closely linked to the IT role for Data Conversion. This is where data needs to be transformed so that it fits the format required by the new system and this could account for some of the ambiguity around this role for the Business. This has to be a role for the Business because they are the ones who interpret the data into meaningful information and assess its usefulness for supporting their purposeful activities. Both the IT and Vendor/Consultants are capable of understanding and interpreting the data as information. However, they will always lack a deeper understanding of the data and its quality because, unlike the Business group, they do not use it to support any purposeful activities. It is for this reason that this has to be a role and responsibility for the Business group. The following Roles and Responsibilities were identified for the Business group when implementing Packaged Software: Undertaking change management and business readiness tasks. Ensuring that the end users of the system are trained.

77

Preparation and execution of User acceptance test scripts (UAT). Definition of user requirements for the system. Participation in the design & design approval process. Resource provision and allowing that resource to dedicate time to the project.

Supporting the implementation team. Making decisions in a timely manner. Championing the system. Process re-engineering: - adapting/defining new processes so that they are aligned with the software, enabling the business needs and the operational management of the business deliverables.

Ensuring technical platform readiness in advance of the software implementation.

The creation of end-user operating instructions. (SOPs). Undertaking data preparation and quality assurance activities. Ownership of the final solution. Identification of key business benefits and objectives.

78

Project Management and the participation in the configuration of the system were the two other roles for the Business group where opinion was divided. These will be discussed later in this chapter as there is some overlap here with other roles for both the IT and Vendor/Consultant groups.

79

5.8 Vendor / Consultant Groups Roles and Responsibilities When compared to the Business group, there were more differences of opinion between the panel members about the Roles and Responsibilities identified for the Vendor/Consultant group in round one. This is shown in table 10 below.

Table 10 Vendor / Consultant roles and responsibilities

80

The panel broadly agreed that having a clear vision of the automation required should be the Vendor/Consultants responsibility as shown in table 10. However half of the panel members from the IT group disagreed with this being a role for the Vendor/Consultant. An explanation for this could be that it encroaches on the IT role of evaluating the strategic fit of the new software package within the organisations existing IT systems. This is one of the purposes behind the role participating in the initial review that was identified by the panel for the IT group. The scope of the Vendors role here is for evaluation of the automation that lies solely within the domain of the software package being implemented.

A role identified for the Vendor/Consultant group was to provide user documentation. The results are shown in figure 13, which shows that the panel were broadly in agreement with this assertion. However two of the panel members representing the Business group did disagree with this as a role for the Vendor/Consultant.

81

Figure 13 Vendor provision of documentation The question for this role would have been better if it had been split in two so that a distinction could have been made between User and System documentation. Had this been the case, it is more likely that the Vendor/Consultants role to provide system documentation would have been a unanimous decision.

This would still leave the provision of the user documentation, which is not so clear-cut, and could have probably been the cause of the disagreement for 82

this role. The Vendor can only realistically provide generic documentation on how to use the software as economies of scale dictate that they would want to be able to leverage it for more than one client. Specific documentation that instructs the users on exactly how they should use the system is the responsibility of the Business. This is because the documentation not only needs to instruct the user on the system, but also on the associated business processes and how the system is used within that context. The panel unanimously agreed that it was the responsibility of the Business to create the end user operating instructions, see table 9. The following Roles and Responsibilities were identified for the

Vendor/Consultant group when implementing Packaged Software: Provision of a clear vision of the automation requirements necessary to produce the desired functional result. Facilitation of requirements gathering sessions. Provision of skilled and knowledgeable resources. Assisting the business to ensure regulatory compliance is maintained. Assisting the business with Business Process re-design. Managing expectations in line with what had been promised. Provision of product support. Provision of technical expertise and product. Provision of user and system documentation. 83

Provision of system design guidance, utilising industry best practices and own expertise based on other implementations and product knowledge.

Completion of unit and integration testing. Completion of application configuration and provide any customisation work if required.

Delivery and deployment of a working product. Provision of software training.

The responsibilities of ensuring the end-to-end delivery of the project and ensuring schedule adherence will be discussed later in this chapter.

84

5.9 IT Group Roles and Responsibilities Overall, the panel was even more divided in their opinions for the roles and responsibilities for this group than the Business and Vendor groups. Out of the fifteen roles and responsibilities that were identified in round one for this group, only five were unanimously agreed to by all of the panel members.

Table 11 IT Roles and Responsibilities

85

One of the answers returned from the first round suggested that the IT groups role should be limited only to the provision of the technical infrastructure needed to support the system. In other words, projects implementing Packaged Software should be seen as a Business project and not an IT project. Gibson et al also made similar observations for the implementation of ERP systems (Gibson et al, 1999). One of the questions posed in the second round set out to specifically seek the panels views about this. Apart from the panel member who originally raised the question, the panel unanimously disagreed with this view. Clearly the panel see the IT groups role as being more than managing the technical aspects of the project. One of the IT roles that was identified by the IT group was to act as the liaison between the Business and the Vendor. The results are shown in figure 14. It shows that the majority of both the Business and the Vendor/Consultant groups were in disagreement with only the IT group unanimously in agreement. This shows that the IT group are out of step with both the Business and Vendor/Consultant groups. No longer is the IT group in the traditional role of software provider for the Business.

86

Figure 14 IT acting as the liason with the vendor Many of the roles identified for the IT group could be classified as classical Project Management roles. These originated mainly from the panel members representing the IT group. Most of the disagreement about these roles came from the Business. This shows that there is still uncertainty around the IT groups role and what the Business is expecting them to provide. The difficulties in the relationship between IT and the Business that were observed by Peppard and Ward back in the 1996 still have not been fully resolved nearly fourteen years later (Peppard and Ward, 1996) The details of these

87

project management roles can be found in appendix H. There will be further discussion on the topic of project management later.

The following Roles and Responsibilities were identified for the IT group when implementing Packaged Software: Technical Aspects: - Provision of the technical infrastructure to facilitate software and technical change management. Provision of post go live support / Data safety / Disaster Recovery and system performance monitoring. Ownership of the project delivery / End to end delivery. System testing (Unit/System/Integration/Performance testing) Interface design and development. Application configuration. Data conversion. Provision of user-management and system security. Participation in an initial project overview to highlight where additional internal paperwork is required. Elevation of user-rights during a project is a good example of this.

88

5.10 Project Management The results from the second round show that there is a split around which group should be responsible for the management of the project. The interesting thing about this split is that there is an opinion within the Business group that this should not be a role for the IT group, and there is a similar strength of opinion within the IT group that it should not be a Business role. See figures 15 and 16.

Figure 15 Business role as Project Manager

89

Figure 16 IT role for Project Management In round one, none of the Business panel members identified Project Management as being one of their top six critical success factors (CSFs). However, it did feature highly as a CSF by both the IT and Vendor/Consultant groups. This may be because the work in both these groups tends to be project-based, whereas the Business groups expertise is predominately centred on processes and the delivery of goods and services.

90

5.11 Application Configuration Business group participation in system configuration had the unanimous agreement amongst the Business group on the panel, but it was met with significant disagreement from both the IT and Vendor groups as shown in figure 17. These groups would be typically involved in the configuration of the software and have the knowledge and experience of the task. Therefore it could be considered that these views on the panel carry more weight.

91

Figure 17 Business particitpation in the configuration However, it is more likely to depend on factors such as the technical complexity of the configuration process. Also if the requirements gathering process had achieved enough detail for configuration to take place without further recourse to the subject matter experts within the Business group. The role of application configuration was also suggested for the IT group and the results are shown in figure 18. Here all the disagreement came from the Vendor/Consultant group on the panel.

92

Figure 18 IT Application configuration There was however 100% agreement amongst the panel that it should be a role for the Vendor/Consultants group. How much IT involvement would be dependent on the resources available within the IT group and the future support envisaged for the system. Did the Business require the IT group to have the capabilities of performing changes to the configuration or would they rely on always going back to the Vendor/Consultants? Having in-house capabilities to adapt the configuration of the system gives the Business the agility to respond quickly to changing market conditions by being able to modify processes and the system. If there were no system configuration 93

capabilities in-house then all changes, however minor, would need to be performed by the Vendor/Consultants who may not always be in a position to respond. This agility has the price of maintaining the configuration skills inhouse and must be weighed up against the Business benefits of being able to respond to market changes quickly.

The configuration process also has a relationship with the Business process design. How the system is configured will have an impact on the design of the Business processes, as will the design of the Business process have an impact on the configuration of the software. This is a good reason for the Business group to be involved in the system configuration as they are responsible for the design of the Business Processes.

One of the roles identified for the Vendor/Consultant was to assist with the process design and the results for this are shown in figure 19.

94

Figure 19 Vendor assisting with the Process Design The two members of the panel that disagreed with this role for the Vendor/Consultants came from panel members representing the two groups within the organisation having the software system implemented. It should be recognised that in this role the Vendor is seen as the expert authority that Diamond was referring to (Diamond, 1996). The answers show that there maybe a difficulty accepting outside advice on business process design when it is something that is clearly a role for the Business and these are shown in the results table 9. However one of the advantages identified for Packaged

95

Software by this study was that it implemented industry best practices. This implies that the Vendor/Consultants must also have the knowledge and understanding to enable them to offer advice on the design of the processes that can fully exploit their system. It is therefore difficult to understand why you would not want to have the Vendor/Consultants assisting with the process design.

The complexity of the configuration issue is beyond the scope and resources available for this project. However Mousavidin and Silva are conducting an ongoing research into the subject of the configuration of Packaged Software (Mousavidin and Silva, 2009).

96

Figure 20 IT Participation in the requirements gathering

5.12 Ownership of the Project Delivery This was a role that was identified for both the Vendor/Consultant and IT groups. Figure 21 shows the results for the Vendor/Consultant group and it shows that the Vendor/Consultants unanimously agreed with the role but differing opinions were expressed within the Business and IT groups.

97

Figure 21 Vendor ownership for overall project delivery When the panel were asked should the IT group be responsible for the overall delivery of the project? Their opinions were even more divided, with the overall opinion being against this. This is shown in figure 22. This role was suggested in round one by one of the IT group members on the panel. Most of the disagreement came from the Business and Vendor/Consultants members of the panel. So there are still some of the uncertainties around the roles of the IT group that were observed by Ward and Peppard, where the IT group

98

are trying to fulfil roles that are not required by the Business (Ward & Peppard, 1996).

Figure 22 IT ownership of the project delivery Based on the evidence from this study, the results are inconclusive as to where the responsibility should lie for the ownership of the project delivery. Ideally the panel should have been asked if the Business group should be responsible for the overall delivery of the project. This was not done because it was not one of the roles that were identified for the Business in round one.

99

Ensuring project schedule adherence and giving assistance was another role that was identified for the Vendor/Consultant group. The results for this are shown in figure 23 and this compares with the level of disagreement around the Vendor/Consultants responsibility for the ownership of the delivery of the entire project.

Figure 23 Vendor responsibility for schedule adherence The risk identified in this study as having the highest impact was the Inability of the Vendor to provide timely and skilled support. This role had the panels unanimous agreement, and would be an obvious source of additional 100

resources that could be drawn upon to maintain the projects schedule. The cost implications of this, along with the loss of control, could be the reason for the disagreements about this role. The Vendor/Consultant group also have a responsibility for ensuring that their parts of the project adhere to schedule. So this should be a vital role for the Vendor/Consultant even if they do not have the responsibility for the overall project delivery.

5.13 Resource Estimation Having the right resources allocated to the project is a CSF for ERP systems. For this to happen, it is crucial to ensure that the estimation of resources is as accurate as possible as this can represent a significant project cost. One of the questions in round one aimed to find out how the estimation of resources was carried out within the three groups. The results returned were disappointing. Of the results returned for the estimation question, none of the Business group reported using any tools or techniques. The Vendor/Consultant group did report the use of spreadsheet tools for estimating their own resource requirements. The IT group tended to rely on past experience with other systems and rely on advice from the Vendors. Both IT and Vendor/Consultant groups reported reasonable success with the estimation methods they used. With experience of past projects playing such a major role in the estimation of resources, it does suggest that organisations need to maintain some core knowledge and expertise for implementing Packaged Software.

101

For both the Business and the IT groups, there was a reliance on past experience when estimating resources and timelines for a project. This implies that IT would be better placed to do this because they are typically involved in the implementation of more projects. The Business, however, would not do this very often, even if they were responsible for the delivery of this type of software project. Because the Business rarely implements software projects, they would have little experience to draw upon in order to make their estimations for the next project. While they can turn to the vendor for help with the estimations, it does present an additional risk of incorrectly estimating the resources and time needed, which could in turn put the entire project at risk of not achieving its objective.

So, because IT work is project based and the need to retain a centre of excellence within an organisation, the role of Project Management should reside within the IT group.

5.14 Analysis This study successfully identified CSFs that were specifically for Packaged Software and they were able to be compared with the CSFs identified from the literature for ERP systems. It also fulfilled its objective of compiling lists for the advantages and disadvantages of Packaged Software when compared to Bespoke Software projects.

102

The Delphi technique proved a highly effective method for not only identifying the risks for Packaged Software, but also ranking them by probability and impact of occurrence. The study did not achieve its aim of identifying the best means of estimating the resources required for Packaged Software implementations. Responses from the first round did not yield suitable data to enable the Delphi technique to be followed. The panel size may have been a limiting factor or it could be that there are few estimating techniques available. This would warrant further study, but using the Delphi technique is not recommended. The study had partial success identifying the roles and responsibilities for the Business, Vendor/Consultant and IT groups involved in Packaged Software implementations. Differences of opinions were expressed between the Business and IT groups. These differences of opinion about roles have been observed in other studies found in the literature (Ward and Peppard, 1996). Had time permitted a third round, then a resolution for the undecided roles may have been achieved. The Delphi technique was found to be a highly effective method for determining the roles and responsibilities of the groups. The makeup of the panel is a key factor key factor when using the technique to ensure that different views are effectively represented in order to give real meaning to any consensus reached.

103

Chapter 6 Conclusions

6.1 Discussion/Conclusion

This study set out to identify if Packaged Software exhibited any special problems and risks when compared to Bespoke Software projects.

Reports in the literature showed that Critical Success Factors (CSFs) could be used to identify key areas that projects need to address for a successful outcome. An examination of the CSFs for both Packaged and Bespoke Software was carried out to see if any differences were revealed. For Packaged Software, the only CSFs found in the literature were those for Enterprise Resource Planning (ERP) systems. To support the comparison of the CSFs an objective of the primary research was to identify CSFs specific to Packaged Software. The CSFs identified for Packaged Software were found to be comparable with those of ERP systems indicating that ERP CSFs could be applied in most cases to Packaged Software implementations.

The comparison between ERP and Bespoke Software CSFs revealed a key distinction between the two approaches. A CSF identified for Packaged Software that is not required for Bespoke Software concerns the approach taken when gaps are identified between requirements and system functions. It stated that, changing the business process should be done in preference to 104

customising the software to fit the business process. It is this principle that is the key difference between Packaged and Bespoke Software

implementations. This needs to be done to achieve the advantages identified for Packaged Software which are:-

Low costs because the development costs are spread across the Vendors customer base.

The risks associated with developing Bespoke Software are removed because it is already written, tested and has a proven track record.

Faster implementation because the time to develop the software is no longer required. This means that the anticipated benefits for the system will be realised earlier.

The functions provided within Packaged Software strive to embody industry best practice.

It is the need to design the Business Processes so that they align with the softwares existing functions that is a key factor that differentiates Packaged from Bespoke Software. With Bespoke software it is possible to design the software to fit existing Business Processes. For processes that give organisations a unique competitive advantage there is a case for customisation or considering developing Bespoke Software. This is because 105

the required functions are unlikely to be found in a Packaged Software application as they have to appeal to a wide customer base in order for it to be commercially viable.

As well as understanding the requirements of what the system has to do, it is also essential to understand the current business processes, and what they should ideally be after the software implementation. This should take place prior to software selection so that the gap analysis between Vendor offerings can be evaluated not only on requirements but also the degree of change required to the business processes to achieve those requirements. One of the risks identified by the study was that the high initial costs of the software can lock an organisation into the software. This can mean having to make difficult choices later on between expensive customisations or inefficient Business processes to support the software.

If the Business Process cannot or will not be changed then the Packaged Software may have to be customised in order to meet the requirements for the system. This means that the software has to be customised. This increases the costs because the code for the customisation has to be developed, and tested, which is re-introducing all the risks associated with Bespoke Software. It is this area that introduces the main risk of cost overruns as they may not have been foreseen during the planning and budgeting for the project.

106

For Packaged Software to be cost effective, it requires an understanding of the Business Processes and a willingness to change their design to fully exploit the systems capabilities. Because of the preference to change the process instead of customising the software, it will inevitably bring about more change within the Business and therefore requiring more change management. The conclusion to be drawn from this is that Packaged Software requires more involvement from the Business because of the process design and the resulting change management activities.

Because the software is already developed, and the emphasis on designing processes to fit the software, there is a strong case that Packaged Software implementations should be seen a Business project and not an IT project. If it is to be an IT project then IT needs to gain an understanding of the business they serve and its associated processes. Their Business analytical skills need to extend well beyond the domain of the system to include the design of Business Processes that the system is there to support. If IT cannot provide this kind of support to the Business then the Business can buy this support in from the Vendor or engage consultants. At this point it becomes a Business project and the IT role is limited to ensuring the technical infrastructure is in place to support the system. If it were to be a Business project then the Business needs to have the understanding of implementing IT systems, knowledge of their current IT systems and have the project management skills for managing IT/Technical change management projects. 107

Information Technology is a highly specialist area and requires a great deal of experience to fully exploit. Howcroft & Light have shown that someone needs to understand the capabilities of the software and the context in which it will be applied and the benefits being aimed for (Howcroft & Light, 2006). This suggests that there is a role that needs to be fulfilled within organisations. The question is does it sit within the Business or IT group?

Schedule adherence and the responsibility for overall project delivery must to lie with the Business group. The results of this study have suggested that it is the Business groups responsibility for: Identification of the objectives and derived benefits of the system. Resource provision. Process re-engineering. Ownership of the final solution.

These four responsibilities combined make it a necessity that the Business group is responsible for the overall project delivery.

Having adequate resource provision with the knowledge of the process areas covered by the system was cited by the panel as a CSF. Both the IT and Vendor groups are unable to deliver the solution without these knowledgeable resources from the Business. They have to come from the Business as only

108

they will have the appreciation of the objectives and benefits that the system is aiming to achieve.

The Business group should be involved in the design and alignment of the Business processes so that they fully exploit the functionality of the software. The results from the Delphi study indicated that there was full agreement that this should be one of the responsibilities of the Business. Additionally, there is also evidence from the literature suggesting that both the IT and Vendor groups would have difficulty getting changes to the process being adopted by the end users. This is because both groups would be seen as the expert authority identified by Diamond and would be a cause of resentment and resistance to the changes being brought about. Another factor is that some changes to the Business process may be inappropriate due to the decision makers not having sufficient depth of knowledge about the Business domain and therefore making incorrect assumptions.

Because IT work is more commonly project based, and the need to retain a centre of excellence within an organisation, the role of Project Management should reside within the IT group.

6.2 Future research The use of Packaged Software is a popular and in some cases the only choice available when implementing software systems. Despite its popularity, relatively little research on this topic has appeared in the literature 109

(Mousavidin and Silva, 2009). This study has made a small contribution to the existing body of knowledge for Packaged Systems but there is still much research needed to be done in this important field.

One of the most contentious areas of Packaged Software implementation is around Business Process versus Customisation. There is clearly a dependency between the Configuration of the system and the design of the Business processes that interface with the system. The process dictates how the system needs to be configured, but also it is the configuration of the system itself that dictates the design of the process. There is an ongoing study by Mousavidin and Silva which is looking at the configuration of these types of systems but this does not appear to include the Business process design (Mousavidin and Silva, 2009). Failure to find the optimum balance between configuration and process will often result either in expensive customisation or in an inefficient Business process resulting in an ongoing cost burden for the organisation implementing the software. This is why it is such an important issue that warrants further research.

110

Glossary
COTS BP BPR ERP ROI SOP Commercial Off The Shelf software Business Process Business Process Reengineering Enterprise Resource Planning System Return on Investment Standard Operating Procedure. This is term used in the Pharmaceutical industry for employee working instruction documents. User Acceptance Test. User Requirements Specification.

UAT URS

111

References
H Akkermans, K van Helden (2002), Vicious and virtuous cycles in ERP implementation: a case study of interrelations between critical success factors, European Journal of Information Systems, 11, 3546 Judith Bell (2005), Doing Your Research Project, 4th Edition, Open University Press Prasad Bingi, Maneesh K.Sharma, Jayanth K.Godla (1999), Critical Issues Affecting an ERP Implementation, Information Systems Management; Summer99, Vol. 16 Issue 3, p7,8p Janet Butler (1999), Risk Management Skills Needed in a Packaged Software Environment, Information Systems Management; Summer 99, Vol. 16 Issue 3, p15, 6p. Peter Checkland, Sue Holwell (1998), Information, Systems and Information Systems, Wiley. Jane Coughlan, Mark Lycett, Robert D. Macredie (2005), Understanding the businessIT relationship, International Journal of Information Management 25 (2005) 303319 M A Diamond (1996), Innovation and Diffusion of Technology A Human Process. R.H. Edmundson and D.R. Jeffery (1984), The Impact of Requirements Analysis upon User Satisfaction with Packaged Software, Information & Management 7 (1984) 83-90 Fiona Fui-Hoon Nah and Janet Lee-Shang Lau (2001), Critical factors for successful implementation of enterprise systems, Business Process Management Journal, Vol. 7 No. 3, 2001, pp. 285-296. # MCB University Press, 1463-7154 Nicola Gibson, Christopher P. Holland and Ben Light (1999), Enterprise Resource Planning: A Business Approach to Systems Development, Proceedings of the 32nd Hawaii International Conference on System Sciences 1999 Christopher P. Holland and Ben Light (1999), A Critical Success Factors Model For ERP Implementation, IEEE Software May/ June 1999 Debra Howcroft & Ben Light (2006), Reflections on issues of power in packaged software selection, Info Systems J(2006)16, 215235 Ben Light. (Feb 2005), Going beyond misfit as a reason for ERP package customisation, Computers in Industry 56 (2005) 606619 112

Ben Light. (May 2005), Potential Pitfalls in Packaged Software Adoption, COMMUNICATIONS OF THE ACM May 2005/Vol. 48, No. 5 Andy Kyte (2009), Customization: The Cost That Keeps on Costing, Gartner Research, ID Number: G00165372, www.Gartner.com accessed July 2009. Marius A. Janson and Ashok Subramania (1996), PACKAGED SOFTWARE SELECTION AND IMPLEMENTATION POLICIES, INFOR vol. 34, no. 2, May 1996 M. Lynne Markus and Robert I. Benjamin (1996), Change Agentry the Next IS Frontier, MIS Quarterly/December 1996. Robert J. Mockler and Chang-nan Chao (2006), Packaged software in China: a managers support roles during implementation. P. Murray (1999), Fundamental issues in questionnaire design, Accident & Emergency Nursing (1999) 7. Elham Mousavidin, Leiser Silva (2009), Packaged Software Configuration through the Lens of Social Construction of Technology, Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009. E.W.T. Nagi, C.C.H. Law, F.K.T. Wat (2007), Examining the critical success factors in the adoption of enterprise resource planning. Computers in Industry 59 (2008) 548564 Chitu Okoli, Suzanne Pawlowski. (2003), The Delphi method as a research tool: an example, design considerations and applications, Information & Management 42 (2004) 15-29. Joe Peppard, John Ward (2004), Beyond strategic information systems: towards an IS capability, Journal of Strategic Information Systems 13 (2004) 167194. Susan Sherer (1993), Purchasing software systems managing the risk, Information & Management 24 (1993) 257-266 T Somers, K Nelson. (2001), The Impact of Critical Success Factors across the Stages of Enterprise Resource Planning Implementations, Proceedings of the 34th Hawaii International Conference on System Sciences - 2001 T Somers, K Nelson. (2004), A taxonomy of players and activities across the ERP project life cycle. Mary Sumner. (1999), Critical Success Factors in Enterprise Wide Information Management Systems Projects, SIGCPR 99 New Orleans LA USA Christine B. Tayntor (2006), Successful Packaged Software Implementation, Auerbach Publications.

113

Kweku Ewusi-Mensah (1997), Critical Issues in Abandoned Information Systems. J Ward and R Elvin. (1999), A new framework for managing IT-Enabled business change. John Ward, Christopher Hemingwaya, Elizabeth Daniel (2005), A framework for addressing the organisational issues of enterprise systems implementation, Journal of Strategic Information Systems 14 (2005) 97119. John Ward, Joe Peppard (1996), Reconciling the IT/business relationship: a troubled marriage in need of guidance, Journal of Strategic Information Systems, 5(1), 3765. Rick Whiting (1998), Don't be a licensing lightweight!, Software Magazine 18.n1 (Jan 1998): pp20(6).

114

Appendix A Extended Abstract

115

Critical Success Factors for enabling Packaged Software to realise the potential Business Benefits
Bryon Bond WS6364392
Extended Abstract of Open University MSc Dissertation Submitted 9 March 2010

Introduction The use of pre-written Packaged Software that has a proven track record of working has been the popular and often the only choice for implementing computer systems into an organisation. Examples of these types of systems are Enterprise Resource Planning (ERP) systems such as SAP, JD Edwards, Oracle and PeopleSoft. However there are also a large number of Packaged Software Vendors that provide niche business solutions such as: -

Laboratory Information Systems (LIMS) which are systems designed to assist in all aspects of running laboratories. Examples of these are SQL*LIMS, LabTrack, LabWare LIMS and STARLIMS. Time and Attendance For monitoring employee hours with examples of this type of system being Kronos and Isys. Planning Software Finite scheduling for planning hour hour manufacturing operations and an example of this type of system is Preactor.

These types of systems have pre-written functions that can have their behaviour modified by changing the configuration settings which gives these advantages: Low costs because the development costs are spread across the Vendors customer base. The risks associated with developing Bespoke Software are removed because it is already written, tested and has a proven track record. Faster implementation is achievable because there is no software development time. This means that the anticipated benefits for the system will be realised earlier. The functions provided within Packaged Software strive to embody industry best practice.

Despite being an increasingly popular choice for implementing software, there are still a significant number of reports of software projects failing to deliver their promised Business benefits. This study set out to identify if Packaged Software exhibits any special problems and risks when compared to conventional Bespoke Software projects. In addition, it also set out to establish who are the key stakeholders and recommend what their roles and responsibilities should be. Critical Success Factors (CSFs) have been used to identify key areas that projects need to address for a successful outcome. A comparison of the CSFs for Packaged, Enterprise Resource Planning (ERP) and Bespoke Software was carried out to see if it revealed any differences. The CSFs identified specifically for Packaged Software were found to be comparable with existing CSFs identified for Enterprise Resource Planning (ERP) systems. So the more extensively researched ERP CSFs are applicable to all Packaged Software. The comparison between ERP and Bespoke Software CSFs revealed a key distinction between the two approaches. For Bespoke, the software is designed to fit the User Requirements. But for Packaged Software, it is already written and its functions are already defined. A key CSF for Packaged Software is that the Business processes should be changed to fit the software in preference to customising the software to fit the Business processes. This means that the design work for this type of project revolves around the alignment of the systems configuration and the Business processes. The CSFs identified in the study for Packaged Software are set out in the following three tables. To some extent the factors that are critical to the success of a project are all about mitigating risks. The study also identified the risks for Packaged Software and these have also been linked to the relevant CSF in the following tables. Understanding who the key stakeholders are and their roles and responsibilities are critical to any projects success. Because Packaged Software is already written it has removed the traditional role of the IT department of supplying the Business with its software. Packaged Software also introduces a third group into the IT and Business relationship. The relationship between Businesses and their IT departments has always been difficult with both sides continually failing to meet the others expectations. In most human relationships adding a third party tends to complicate relations further. The roles and responsibilities identified for the Business, Vendor/Consultant and IT groups have also been linked to the CSFs and risks in the following tables. To conclude, Packaged Software is more about designing Business Processes to align with best practices embodied within the software. This has to be coupled with the configuration of the software so that it aligns with existing/desired Business processes. If this is not recognised, it can lead to expensive software customisations or inefficient Business processes being put in place to support the software.

End of Appendix A

Appendix B Delphi Questionnaire

121

122

123

124

125

126

Appendix C Round 1 results from Business grouping of the Delphi panel.

Responses from the Business Group
1BU 2BU 3BU 4BU What do you consider to be your top six most critical success factors for implementing a Packaged Software solution and very briefly state why? 1. A robust Change Management Plan (Communication, why and how the project is needed, its benefits to the business and the users 2. Implementation Team Composition balance between internal and external team, cross functional teams with robust business knowledge together with external consultants with the software knowledge 3. Clear Business Plan and Visions this links in with the change management as explains why the system is key as part of moving the company towards its future business state. It is important that the implementation is part of the future state Clear strategy or way of decision in regard to implement standard processes of software or to adapt the software to current processes Knowledge of the own processes 1. Senior management commitment 1. Business critical functionality. The business will have identified its core requirements and the softwares ability to deliver on these will impact on the business case viability. 2. System integration. As above the ability of the software to operate seamlessly with associated applications without corruption or interruption is essential.

2. Objectives/benefits clearly defined and understood

Team with people ready to re-design current processes and able to consider impacts on other processes, fast learning

3. Scope management

3. Parallel operation. The current application(s) must continue to deliver while the new software mobilisation process is implemented, tested with user acceptance so new software must pull required data without impacting on the current provision

127

Responses from the Business Group

1BU 4. Business Processes I think it is better to change the manual processes to fit with the system than change the system to fit with the process (where possible). Keeping system changes to a minimum reduces implementation time, system integrity risk and make future upgrades easier and less risky (a upgrade might impact changes made during implementation which is not was not part of the original system) 5. Top Management support it is critical that the senior management support the system implementation and make it imperative that the system is a priority (especially during ERP Implementation) e.g. An example of this relates to reporting, individual sites currently using different systems will have difference reports, it is not practical for the new system to simply replace the existing reports, it will standardise reporting meaning some users will have to change, these changes need to support of senior managers, otherwise the implementation team will be developing reports rather than implementing a robust system 2BU Depending of the overall size of software implementation: consultants with whole overview and interfaces between modules 3BU 4. Change management 4BU 4. Support. The technical support program must include (and deliver) to all eventualities even to associated applications, not just the software in question.

Resources for project (staff and budget)

5. Testing

5. Timeliness. A realistic program must be agreed upon and kept to

128

Responses from the Business Group

1BU 6. Robust Model (global model) prior to actual implementation good due diligence as to what the system needs to be able to do (with the involvement of the key stakeholders) prior to implementing will result in a more standardised system with minimal localisation as the system is rolled out. One of the key advantages, especially with ERP systems, is that everyone is on the same platform, with the same processes and procedures and reporting. The only differences should be due to local laws or key practices 2BU Training: the team members need to have a feeling of the processes in the software to take decisions and fill their role 3BU 6. Documentation and training 4BU 6. Cost. Deliverables should be clearly defined and costed. Out of scope is an indication of output and input specification failure.

If the project were to be bespoke software implementation, would any of the critical success factors that you identified not have made it into your top six and if not, what success factor would you replace it with?
You might be able to remove the business processes and develop the system in line with the current business processes, however you will still need to standardise the processes across the business to fit to one standard Not in: Clear strategy or way of decision in regard to implement standard processes of software or to adapt the software to current processes Team with people ready to re-design current processes and able to consider impacts on other processes, fast learning Depending of the overall size of software implementation: consultants with whole overview and interfaces between modules Training: the team members need to No change The critical success factors would be the same. The numbers around the cost might be different!

129

Responses from the Business Group

1BU 2BU have a feeling of the processes in the software to take decisions and fill their role Instead: Clear User requirement specification Prototyping 3BU 4BU

What do you consider to be the main advantages for using Packaged Software?
They normally use best practices Standard processes Less risk 1. Tried and tested, developed and visible.

Should be more robust/stable You will get system support

Software support Time for implementation

better support upgrade path wider functionality encourages standardised processes

2. Resilient support 3. Trade references 4. System development available over time 5. Integration to like/associated applications seamless

Upgrades are provided (in line with best practice or legal changes

130

Responses from the Business Group

1BU 2BU cheaper. 3BU 6. Lower cost 4BU

What do you consider to be the main disadvantages for using Packaged Software?
Maybe less flexible in terms of functionality, more chance of having to change processes to meet the off the shelf functionality Complexity of software to fit any possible process (implementation much harder and danger to make everything possible) Process redesign The core software functionality is what it is. One inevitably has to change business process to use the software effectively possibly to the detriment of the business. The core business strategy should be paramount, software applications are there to support this. Tail wagging the dog syndrome!

change management not invented here issues

training

What do you consider to be the main risk factors for a project implementing a Packaged Software solution?

131

Responses from the Business Group

1BU Trying to change the business too much to meet the systems functionality 2BU Budget Team Consultants 3BU Scope creep, poor documentation, customisations restricting upgrades, testing, objectives not clearly defined 4BU 1. Business interruption. Industry is littered with case studies of packaged software implementation where critical functions have been obscured. W S Atkins (Ftse 250 global engineering contractor) implemented their new accountancy package and couldnt send out an invoice for 7 months! 2. Post implementation bespoke requirements fail to address the functional gaps 3. Cost over run

What techniques do you use for estimating staff resourcing requirements for a Packaged Software implementation and what degree of accuracy have you achieved with them?
I have never done this for major, however I underestimate the resources needed for Kronos No specific techniques used so far. Decision taken on demand by consultant and in respect to available resources. Establish critical path tasks to go live date. Estimate hours per task for all tasks. Identify skill sets by task, calculate overall hours required by skill set and translate into heads allowing for sickness, leave, supervision and review plus 20% risk factor. We require the seller to estimate and then substantiate the quote with quantified resource and business drivers. We then benchmark these against industry standards and demand explanations for the discrepancies. Additionally we locate existing sites where the software has been installed and undertake some detailed research into what worked and what didnt! Results have been mixed. Those software packages that have needed little bespoke design or module changes have inevitably worked out better than those where the core application is far removed from the

132

Responses from the Business Group

1BU 2BU 3BU output spec. 4BU

When implementing Packaged Software, have resource issues within one of the external groups involved impacted on the project and, if so, what were the consequences?
Yes, trying to run the day to operations V the project work, the implementation suffers in terms of quality and time In case of internal resource gaps, external consultants were take, which created knowledge outside the company but not within This always impacts on the project, management are reluctant to release key resources to the project which is why senior management commitment and backfilling roles is so important. In the context of external groups being the business end user then Yes. The alterations and disruption to BAU should have been identified as part of the output spec and catered to within/by the input spec by the project owner(s). Frequently this doesn't happen (see 'identifying stakeholders'). The end users are normally inward facing ie 'I'm looking for the functionality not having to provide additional resource to deliver YOUR project'. So issues where the customer has to participate in resolution frequently crop up.

Do you take any precautions to mitigate the risk of resource issues in any of the external groups involved and, if so, what are they?

133

Responses from the Business Group

1BU Not experienced enough to answer this Q 2BU External consultants with multiple competences to cover modules in case of resource issues 3BU The benefits of the project must be sold and the resource requirements made clear in order to achieve senior management buy in. If this is not forthcoming then the project will not meet its timeline or budget. 4BU See above. Each case has to be dealt within the context of the project itself. The Risk Analysis will identify how critical the package and the function its there to deliver has on the business. If its critical then a detailed analysis of the resource is essential mitigation.

Who do you consider to be the key stakeholders for a Packaged Software implementation?
Management (information users) Business, end user Process owners Identifying and then qualifying key stakeholders is one of the most important ingredients to a projects success. The process we undertake as business consultants starts with an end user analysis. This enables us to drill UP through a clients organisation to ensure that the steering group(s) have the right mix of operational, technical, financial and managerial input to ensure success. Operational input - is essential as these are the people who are probably customer facing and have a good grasp of the day to day requirements of the actual business (not the perceived business at board level). Technical input - as only the techies know the ins and outs of the existing platforms, data structures, interface applications etc. and can identify technical show stoppers. Financial input - as the

134

Responses from the Business Group

1BU 2BU 3BU 4BU business case has got to add up to get the required approvals. Managerial as you need someone who can say yes or at least have ear or reporting line to those who can say yes.

User Support team (post implementation) Maybe external customers if the system is customer facing Implementation team

customers of the process

Are there any stakeholders in a Packaged Software implementation who would not normally be involved in a bespoke software development?
In my opinion no No No Most unlikely if they are I would question the qualifying process for their selection

135

Responses from the Business Group

1BU 2BU 3BU 4BU

Would the tasks/roles undertaken by the Packaged Software stakeholders differ if the project had been a bespoke software implementation?
In terms of business process standardisation and implementation no difference, but clearly the task in terms of building the system from scratch is different from configuring a off the shelf package If the software is afterwards maintained by own IT the IT department would have more the lead. Yes, more about design than selection of package The technical input would invariably alter to reflect the changed approach. I would expect the stakeholders number to increase also as the level of input during the development and implementation period would be much more.

What do you see as the roles and responsibilities for the Business during a Packaged Software implementation?
Providing the resource and allowing the resource to dedicate time (must be the right resource, not the people who are available or not critical to the business) Process definition Release the required resources As the customer, the business will have bought into the program. The disruption and changes to the business process will strain the understanding nature of the recipient team. This needs careful management. As packaged, the software will not deliver to the business requirements and the changes to the business process will normally exceed expectation. The key roles will be technical alignment of the software output to the business needs and the operational management of the business deliverables.

Providing clear objectives of the systems Change management and business readiness tasks (communications as to why, when, whom)

Validation Testing

be clear on objectives participate in testing and training

136

Responses from the Business Group

1BU Supporting the implementation team Making decisions quickly and timely Process Re-engineering 2BU Data preparation 3BU adapt to new processes 4BU

What do you see as the roles and responsibilities for the Software Supplier/Implementer during a Packaged Software implementation?
Training to implementation team Consulting (transfer of processes) Configuration Managing customer expectations in line with what had been promised Ensuring the project implementation remains on schedule Provision of technical expertise with knowledge from the source codes up to address software interface hitches Ensuring the correct degree of flexibility during user acceptance testing

Advice as to best practice Providing project management support (if the business does not have it, however I think it is always a good idea to have a PM group with both) Provide train the trainer support

Programming Training

training explaining benefits

assisting with process re-design

What do you see as the roles and responsibilities for the IT department during a Packaged Software implementation?

137

Responses from the Business Group

1BU Support technical areas (development platform, networking I guess the architecture of the business to implement the software) 2BU Hardware 3BU Technical considerations 4BU Overall project management.

Supporting the business staff involved in the system on technical issues between the provider and the business

System availability

architecture

The critical interface issues will fall to the IT dept to address.

Backup

system capacity

Having available the necessary resource and expertise to maintain "Business as Usual" (BAU).

User management Data safety

Security Post go live support Upgrades contesting customisations

When a gap exists between the functions of the Packaged Software and the User Requirements, studies have shown that for an ERP system, changing the Business Processes is the best course of action. Do you feel that this also applies to all Packaged Software implementations?
I agree with this most of the time and it should always be the aim to change the process and minimise the system changes, however this cannot always be possible, any system changes need to be fully thought through, fully understood and most importantly fully documented Depends on complexity and other factors Yes Yes. There clearly as to be flexibility from the business as the drivers that support the packaged option will have shown that a compromise is necessary otherwise a bespoke package would have been chosen. However it is essential that the key requirements of the business are identified and adhered to, otherwise

138

Responses from the Business Group

1BU 2BU 3BU 4BU the tail wags the dog.

In what circumstances would you consider customisation to be appropriate?

When the process changes alone will not meet the business needs If standard process does not fit regulatory needs, has high business risk or the customisation has a good cost benefit ratio Reports, which do not touch table structure. Where existing key controls are inadequate. Customisation or bespoke? The compromise has to address the Q above. The business process can change but only as far as this supports the required business outputs. Otherwise the software must be customised to meet requirements. The trick to ensure you dont end up customising the product to the extent it becomes bespoke in which case thats the route that should have been taken in the first place.

If you were considering customising the Packaged Software, would you perform any cost benefit analysis? If so how would this be undertaken?

139

Responses from the Business Group

1BU Yes, but it can be difficult in some circumstances. If the customisation automates a process, I would assess the cost of programming and time V the savings of the automation. The saving of the automation would look at the number of people required to complete manually V the number of people needed for the same task using the customisation It really depends on the change but the overriding approach is to assess the cost base not doing something V the cost base of doing the change (difference being the saving over a period of time) and competing this to the cost of doing and supporting the change 2BU Costs benefit would be undertaken No defined technique for cost benefit analysis was used 3BU Labour cost saved less IT time spent on documenting and maintaining customisations. 4BU Yes. The procurement phase should clearly identify and quantify the customisation requirements and thoroughly test the proposed result. Again the alignment exercise should be clear and unambiguous.

In what circumstances would it not be appropriate to change the business process in order to fit with the Packaged Software?

140

Responses from the Business Group

1BU When the process is customer facing and gives the business a competitive advantage or distinct capability. If the process is core to the business then it should not be changes. The other could be for legal reasons (for example a US developed system may not have the functionality to deal with Japanese tax systems or processes, therefore the system will have to be customised or the process will need to be done outside of the system. I would say however even if there are legal needs because it is back office I would suggest that a cost benefit analysis is performed as it might be better to complete the process outside of the system? 2BU Regulatory need, too high impact on existing processes. Sometimes the overall project size cannot be expanded to the change of a complex business process. 3BU Loss of key controls 4BU Where the business process alters to the extent where the primary requirements are compromised. This would normally be around efficiency, end user applications and ultimately the business case.

141

Appendix D Round 1 results from Vendor/Supplier grouping of the Delphi panel.

Responses from the Vendor/Supplier Group
1S 2S 3S 4S What do you consider to be your top six most critical success factors for implementing a Packaged Software solution and very briefly state why? 1. Validation of the business case If business case not validated then likely to not become a long term engagement benefiting both vendor and customer 2. Project delivered to budget Essential spend be understood throughout project and overages be agreed/negotiated 1. Product has to meet a very high level of functional requirements by standard out-of-the-box functionality to ensure cost effective approach. 2. Clear focus and strong expertise in the regulated industry is key to cope with industry specific requirements, such as validation. 1. A project goal: - Without a fixed point to aim at the project has no real end and therefore will never be finished. 2. A good understanding of the areas covered by the project: - The departments covered by the solution must be understood, so that fundamentals thought to be the basics arent missed by the implementers. 3. A very good understanding of the software solution: - The implementer then has to know the software inside out in order to advise the business on how to get the most from the solution. 4. Measurable mile stones (data validation, testing, etc) Skilled Technical and Project Management team

Proven Project Management structure & well communicated plan

3. Stakeholder buy in on delivery Management must buy in to the solution or it will inevitably lead to a troubled relationship 4. System Performance System must be robust and stable on release. Otherwise recovery of belief in the sytem take that much longer

3. Team spirit in project team / open communication ensures smooth proceedings.

Correct Technical Infrastructure

4. Offering a leading edge product in terms of features and technology enables low operational cost.

Executive Sponsorship

142

Responses from the Vendor/Supplier Group

1S 5. Usability, Ease of use depends on industry but many times software must play to the lowest common denominator in an organisation, and hence if they dont understand exactly what they are doing will lead to mismatched business processes in working on the software. 2S 5. Supplier organization has to support the typical life cycle of a system (10 to 15 years) by having a dedicated maintenance & support team. 3S 5. Project support within the business: - The project must be supported by the business or the implementation will carry no weight and therefore it will never be prioritised. 4S Operational Buy in

6. References / track record in the industry as a source of experience and guidance.

6. Knowledge of the process must be known by the individuals the business has assigned to the project. The individuals running the project must have the knowledge of the areas covered or fundamentals are over looked.

Documentation of areas of configuration or customisation

If the project were to be bespoke software implementation, would any of the critical success factors that you identified not have made it into your top six and if not, what success factor would you replace it with?

143

Responses from the Vendor/Supplier Group

1S Delivered to budget Would not set an expectation on bespoke development being on budget. Bespoke tends to lend itself to massive scope creep 2S 1. Flexible tool box approach instead of standard out-of-the-box approach (replace 1.) 2. Team has to be open for different strategies, architectures and solutions, often resulting in flexible but longer lasting iterative design processes (replace 2.) 3. Project team would also take care of maintenance & support as knowledge is highly specialised (replace 4.) 3S 3. A very good understanding of the software solution Replaced by: A very good and up to date knowledge of the language being used to develop the system. As depending on techniques used the bespoke could well be slower that needs be and be written in to a corner preventing any future updates. 4S n/a

What do you consider to be the main advantages for using Packaged Software?
Focuses the business on the business case, bespoke changes to packaged applications tend to be excessively expensive and forces the organisation to wrap appropriate business process around the solution instead of seeking an IT nirvana 1. Process harmonization and quality improvement based on industry best practices The customer has complete control over table structure and therefore data structure. So the functionality of the system can be tailored to fit the precise requirements of the company. Consistant high level Support

2. Lower cost of ownership

3. Easy delivery and installation of systems (even on a global scale)

Ongoing investment into R&D to align the upgrades with changing business trends Reduced internal infrastructure and resources to support further development this avoids technical stagnation

144

Responses from the Vendor/Supplier Group

1S 2S 3S 4. Easy to manage the lifecycle of solution / future upgrades 4S New functionality available to drive change within the business rather than a technical catch up scenario

What do you consider to be the main disadvantages for using Packaged Software?
It can only do what it can do. Many companies expectations are that everything the software will deal with will now be effectively automated when in fact if you hit 80-90% automation it should be considered a success. Knowledge is required to make the system fit before any data can be entered. So therefore an unassisted evaluation of the software can lead to people getting the wrong answer from the system and rejecting a system that could give them the precise answer they are looking for. 2. Integration into homemade/ non standardized IT 1. Deployment in industries without agreed best practices (no standardization possible) Initial investment can be seen to be higher and off-putting

3. Lower flexibility, if product does not meet requirements to a high extend while still providing enough flexibility in terms of process design

Future technology upgrades to the s/w may require changes to technical infrastructure of a company User can feel a lack of input into development of the product Reduced flexibility in the product Low priority from IT team as not seen as an interesting or challenging application

What do you consider to be the main risk factors for a project implementing a Packaged Software solution? 145

Responses from the Vendor/Supplier Group

1S Without a doubt the ability of the business to accept the changes in business processes! 2S 1. No support from top-level management 2. No early involvement key process & system owners 3. No buy-in of all stakeholders 4. URS & FS not based on business process needs 5. No willingness to discuss process changes 3S Lack of direction for the implementation. With no defined mile stones or project goals and because of the ability to customise the system. The software has the ability to meander in to nothing. 4S Lack of a clear direction for areas of customisation. Where the company is not clear on the result needed from the functionality in the software this can lead to breakdown in the implementation process

What techniques do you use for estimating staff resourcing requirements for a Packaged Software implementation and what degree of accuracy have you achieved with them?
Look at complexity from the start, if after the design phase the complexity and scope has exceeded then needs to be managed with the customer in terms of recovering costs, de-scoping, or rationalising the business to the software We also use historical references comparing similar scale and type of projects would suggest an accuracy of within 10% to be the norm 1. Experience with projects in the past 2. Standard project management methods such as PM Book of Knowledge 3. Precision level typically is +/- 10% in early stages of the URS phase aiming for a fixed price after approval of functional specification I always feel that at the start of a project the ratio will be 4:1 (this is split system implementer:company staff). Then as the project progresses then the ratio is adjusted 1:1 as more data testing is required. Then the project eventually goes fully circle with the ratio moving to 1:4. The only difference being that this ratio continues to move out until the system goes live. A spreadsheet is used to calculate resource then adjusted taking into account complexity of the configuration involved and the level of skills at the implementation site

When implementing Packaged Software, have resource issues within one of the external groups involved impacted on the project and, if so, what were the consequences?

146

Responses from the Vendor/Supplier Group

1S Of course, many times a company does not understand or accept the level of commitment it will need to resource the project. We have his issues which can lead to delays but often weve proceeded without specific interfaces as they can still realise business value in moving forward in the interim without that component 2S Project team consistency on customer and vendor side is always preferable. However, team changes can be dealt with if qualification requirements are clearly documented and alternative personnel is available. In addition clear project documentation is key for managing team changes. 3S Any resource issues internal or external have a big impact on a project. Depending on the point during the project and from which side the issue is from, you are able to use the ratio measures to work out the impact on the overall duration of the project. 4S Change of personnel can impact an implementation temporarily. This can frustrate the company where the software is implemented due to investment in the relationship. However is the project has been correctly documented it should not have any noticeable inpact.

Do you take any precautions to mitigate the risk of resource issues in any of the external groups involved and, if so, what are they?
Often out of remit but would advise customer of impact and consequences hopefully getting them to action the remedial stuff with the other vendor. Ultimately its the customers relationship with both parties that can help when this occurs In our case it is a clear management strategy to offer a one-stop-shop to our customers. This includes product & people and results in an absolute minimum involvement of 3rd parties in the implementation. Thus the above risk can be mitigated. We always have more than one individual involved on any project, even if this is only behind the scenes as a fall back. All work on a project is then relayed to the individual to keep them up to speed. Where customers have had prior experience of such an impact they can be invited to choose their own project teams.

Who do you consider to be the key stakeholders for a Packaged Software implementation?

147

Responses from the Vendor/Supplier Group

1S Senior management sponsor focus on business case 2S Executive management 3S The people in the business who are to gain most from a successful implementation and have the ability to see ROI benefits. 4S Board of executives

Operational team(s) affected and impacts to them and their processes IT but less significant

process owner quality manufacturing validation IT

Project Manager IT team Key Users

Are there any stakeholders in a Packaged Software implementation who would not normally be involved in a bespoke software development?
Cant think of any instances Executive Management (for packaged software it is recommended to align the program goals with the top level People who have nothing to gain from success or failure of a project. The Board of executives are not always aware of the development of bespoke software as the personnel

148

Responses from the Vendor/Supplier Group

1S 2S management goals). 3S 4S resource is salaried with no CAPEX required.

Would the tasks/roles undertaken by the Packaged Software stakeholders differ if the project had been a bespoke software implementation?
Packaged software tends to be more guidance on the business requirements and adjustments to processes Bespoke tends to be a battle about scope constantly Higher responsibilities for project managers and subject matter experts during a bespoke software implementation If a bespoke project is written in house and there is no inter departmental charging structure in place. Then a project has very little ROI measurement and can therefore have a tendency to run for a far longer time scale. So in a packaged solution the stakeholders tend to keep a tighter grip on the entire project. A business analyst may be used to produce the functional specification and then passed on to the internal development team.

What do you see as the roles and responsibilities for the Business during a Packaged Software implementation?
Managing the business change Management objectives have to be focused on tightly monitoring, controlling, and balancing the projects To manage the internal resource and maintain the expected ratio. Their role is to provide specifications to the implementation team and to ensure the technical platform is there for the software to be received and also ensure the full testing cycle is followed and training rolled out.

1. Scope (or Product) 2. Budget 3. and Schedule 4. Provide guidance on customer specific practices 5. Put in place effective management means further detailing requirements during workshops developing test plans and testing the software robustly

149

Responses from the Vendor/Supplier Group

1S working with vendor on managing the requirements gap 2S 3S 4S

What do you see as the roles and responsibilities for the Software Supplier/Implementer during a Packaged Software implementation?
Managing expectations and budget, reporting to senior level on progress, guiding the business team on short / Medium / long term activities and where they play a part. Assisting in the business compliance. Management objectives have to be focused on tightly monitoring, controlling, and balancing the projects 1. Scope (or Product) 2. Budget 3. and Schedule 4. Provide guidance on industry best practices (explore how to leverage advantage) 5. Put in place effective management means The role of the implementer is to keep the project moving at the agreed pace and give assistance to the business to help them maintain project momentum. The supplier is responsible to gain a clear vision of the automation necessary to produce the desired functional result. They then drive the project, configure and implement the software, provide any customisation work, work with the client to test the software and ensure the client is fully trained to use the solution.

What do you see as the roles and responsibilities for the IT department during a Packaged Software implementation?

150

Responses from the Vendor/Supplier Group

1S Hardware and infrastructure 2S Often being in-between the business and the vendor, the IT department facilitates the implementation of packaged software by means of appropriate project management, internal organization & provision of IT infrastructure. 3S To assist both the internal and external project teams. To be involved in an initial project overview to highlight where additional internal paper work is required. Elevation of user rights during a project is a good example of this. 4S Provide technical infrastructure for the software, communicate to the users the purpose of the project, manage the project internally, give implementation updates and gain internal input in testing the system once implemented.

connectivity then stay out of the way! Monitoring system performance during release

When a gap exists between the functions of the Packaged Software and the User Requirements, studies have shown that for an ERP system, changing the Business Processes is the best course of action. Do you feel that this also applies to all Packaged Software implementations?
Absolutely so long as it doesnt invalidate the business case Yes, adherence to industry best practices improves quality and performance. In addition it has a direct impact on both, implementation and operational cost (life cycle). No. Sometimes the software requirement is because of the fact the business processes are not always the same as a Standard method to achieve a business process. On the whole yes.

151

Responses from the Vendor/Supplier Group

1S 2S 3S 4S

In what circumstances would you consider customisation to be appropriate?

The business wont function without that requirement being met, however I would have expected this to be explored in depth prior to engaging with an implementation. So as a vendor I would be having some heated discussions with our Sales and Pre Sales teams If a crucial customer requirement cannot be met by the standard product and also not by business process change or a suitable workaround. Where the business process differ to the standard. Only where the business demand is ahead of the software and does not compromise the data that is received.

If you were considering customising the Packaged Software, would you perform any cost benefit analysis? If so how would this be undertaken?
Would certainly get an estimate of the cost for the customer but the benefits would have to be considered by the customer. Likely both covered in a meeting to make sure both are on the same page Yes, the cost for customization has to be justified by the achievable savings or quality improvement. Interfaces are a good example. Transactions occurring only once per day in most cases to not justify a customized interface. I would highlight the pros and cons of using the system without customisation and with. This would then be able to be discussed and an agreement made with the businesses point of view being taken into consideration. Only on large custom efforts by calculating hard savings (time/money) and soft benefits (morale, acceptance, security, health and safety issues etc..)

In what circumstances would it not be appropriate to change the business process in order to fit with the Packaged Software?

152

Responses from the Vendor/Supplier Group

1S If it breaks the business case, otherwise this should always be the first option 2S 1. High cost/investments for process changes 2. Crucial within the production or supply chain 3. The existing business process provides a unique and unrivaled value proposition that cannot be achieved by alternative methods. 3S Where other processes have already been put in place and are working well and the new software package is being implemented as a complementary product. 4S Where this would create drift from internal compliance issues.

153

Appendix E Round 1 results from IT grouping of the Delphi panel.

Responses from the IT Group
1IT 2IT 3IT 4IT What do you consider to be your top six most critical success factors for implementing a Packaged Software solution and very briefly state why? 1. Accurate and complete business requirements prior to assessing software package. This ensures that critical requirements are assessed against the softwares capabilities. 2. Objective review of the software package options with selection of the best fit. 1. Clearly defined business requirements Without clearly defined requirements the project will not have focus 2. Commitment from senior leadership Project resources look to senior leadership for their direction and work effort, if the senior leadership does not buy in to the project it will have a tendency to fail 3. Adequate resource commitments Without the proper number of resources committed to the implementation it will be difficult to complete on time and on budget 4. A dedicated Project Manager A Project Manager is necessary to track the overall project and act as a central point of communication and management 1. Sponsor participation the more actively involved (with out going too far) the sponsor the greater chance of success 2. Scope control the scope should be defined with a rigorous method of changing it. 1. Conducting a thorough assessment of the packaged software to ensure that it will provide satisfactory fulfilment of the business requirements 2. Willingness of the Business Sponsor to engineer their business processes around the inherent workflow/functionality of the Packaged software solution 3. Structuring of vendor payment terms to ensure the vendor stays committed to the successful implementation of the product

3. Involvement during requirements, design, development, and deployment phases of business users. This ensures the solution developed meets the business needs. 4. Identification of requirements gaps and agreement from business on how to handle. This is critical as it may require changes to business processes or early communication to the end user community preparing them for the change.

3. Timeframe the project must not be longer than 1 year, however it needs to be long enough to ensure the implementation is not rushed.

4. Impacted community support predominately the responsibility of the sponsor, but either way if the end users dont understand or want the system it will fail.

4. Commitment and governance structure to NOT customize the software

154

Responses from the IT Group

1IT 5. Prototype with hands-on testing for end users. Ensures design decisions meet business requirements before final design is implemented. 2IT 5. Training It is critical that end users and people involved with the software are adequately informed and trained on the use of the software 3IT 5. Communication both how, what, why, where, etc. as well as decisions made, and progress through out the project. 4IT 5. Financial heath/long-term presence of the vendor in order to ensure that the vendor will retain a presence in the future

6. Well defined changed management plan. Any new application will impact the business. Users should be prepared in advance for the new system. This includes system training as well as communication of new processes.

6. Highly skilled resources The project resources must be skilled in regards to their assigned role, unskilled resources will hinder the success of the implementation

6. More program management than project so the factor is good program management made up of o On-going support/ maintenance and additional features program the project is not an end but the beginning and will need a defined program for the coming years o Supplier relationship need a good supplier with the right people and responsiveness however this is not a success factor for the individual project more the complete program

6. Internalization of product knowledge in order to optimize longterm support of the application

If the project were to be bespoke software implementation, would any of the critical success factors that you identified not have made it into your top six and if not, what success factor would you replace it with?

155

Responses from the IT Group

1IT No. 2IT No I believe the success factors would be the same 3IT The general rules are the same just PM effort is put in different areas .. supplier relationship becomes programming resource relationship. 4IT All 6 of my prior responses were tailored towards Packaged implementations. Critical success factors for bespoke software would include: o Clearly defined sourcing strategy for technical skills that will be required to provide long-term support of the application o Thorough definition of user and functional requirements o Formal change control program to govern desired changes to the application o Deployment strategy that delivers additive functionality every 90 days or so o Exhaustive testing approach unit, system, performance, etc.

What do you consider to be the main advantages for using Packaged Software?
1. Costs related to development, implementation, and support. 1. Less development time Quick start o Faster realization of business value (i.e., faster implementation lead time)

2. Reduced risk associated with using a software package that has been used and tested successfully in other businesses.

2. Typically has a proven track record

Leveraging industry practices and processes

o Often more cost effective

156

Responses from the IT Group

1IT 2IT 3. Has been tested thoroughly 3IT Can be used as a mechanism for driving change or process. 4IT o Outsourcing of product upgrades and keeping current with technology innovations o Lower long-term support costs o Facilitates customer adoption of implied best practices

4. Supportability typically vendor can provide expertise and support resources

What do you consider to be the main disadvantages for using Packaged Software?
1. The need to make compromises in functionality or business processes. Rarely does software fit perfectly into a business. Typically concessions must be made around missing functionality or changes to business processes. 1. Can have high initial costs to purchase licenses Can be difficult to fit the exact processes in place with out major change. o Packaged software will never meet 100% of organizational requirements

2. May not meet your specific business requirements 3. Could include numerous features that you do not need 4. Does not allow for customization

You are one voice in many for enhancements Support can be difficult or expensive

o Increased change management considerations as user community is forced to change business processes o Packaged software reporting is often insufficient to the needs of most organizations o Annual maintenance fees are costly o Package software shelf life is limited as vendors will incent customers to constantly upgrade

157

Responses from the IT Group

1IT 2IT 3IT 4IT

What do you consider to be the main risk factors for a project implementing a Packaged Software solution?
1. Discovering late in the project that software does not satisfy critical requirements or was configured incorrectly. The cost of reconfiguring or abandoning software can be too high requiring the business to modify processes to accommodate the software. 1. Vendor stability 2. The ability of the vendor to provide timely and skilled support 3. The ability of the packaged software to meet the business requirements 4. The high initial costs somewhat lock you in with the vendor Change management Functionality Reliability Supplier delivery o User community will always be not 100% satisfied as Packaged software will never satisfy all of their requirements and the users are reluctant to change their business processes o Ability of the IT staff to internalize long-term product support

What techniques do you use for estimating staff resourcing requirements for a Packaged Software implementation and what degree of accuracy have you achieved with them?
1. Rely on past experiences to develop estimates. No formal process is used. Estimates are moderately accurate. 1. Typically utilize the vendors past experiences and recommendations in regards to staffing requirements 2. Utilize past internal projects as a basis for initial staffing requirements 3. Asking the resources how much time they need to complete identified tasks I feel that the resource accuracy is typically off anywhere from 10% to 15 % of estimates. It not typically just under or over the estimate but a combination of both depending on the project. Experience based around metrics. Scope and impact dependent o Packaged Software vendors/implementation partners are experienced with other implementations and can provide guidance on resourcing requirements o Typically, we have achieved accuracy of 90+%

When implementing Packaged Software, have resource issues within one of the external groups involved impacted on the project and, if so, what were the consequences?

158

Responses from the IT Group

1IT Yes. Typically lack of commitment of involvement of business resources has lead to missed deadlines or incorrectly implemented solutions. The latter is the biggest issue. Lack of involvement from the business forces decisions to be made by the implementation team, who typically do not have the hand-on business experience that is required to make the proper decisions. 2IT I am assuming external groups is everything outside of the project management group Yes, there are times where the vendor does not have a resource available for a certain period of time due to working on another customer etc.. . There are also times where the business does not provide a subject matter expert for the appropriate amount of time. These issues typically result in the project taking longer than estimated and requires modification of the project plan 3IT Yes late delivery of software changes, causing major delay and ultimately cancellation of project 4IT o Resource issues, whether internal or external, arise when resources are not fully 100% committed to a project. Such issues often impact project schedules as conflicts arise between project plans and resource availability.

Do you take any precautions to mitigate the risk of resource issues in any of the external groups involved and, if so, what are they?
Communication to project stakeholders is critical. Typically done in a weekly or bi-weekly meeting with stakeholders. This should be raised as an issue with impacts and risks explained clearly if the situation is not corrected. During the kickoff meeting we identify the roles and responsibilities of the resources involved with the project, we also use a resource spreadsheet which identifies the amount of hours needed and when those resources are required Communication, communication and more communication . Building a good rapport with the supplier and fostering a blameless culture so that issues get raised early and can be managed o Long-term detailed project planning is always the best solution to mitigate potential resource issues. A good project manager will be able to effectively monitor project progress and forecast potential issues so that such risks can be effectively mitigated.

Who do you consider to be the key stakeholders for a Packaged Software implementation?

159

Responses from the IT Group

1IT 1. Business users 2IT 1. Project Sponsor Senior member from the business 3IT Sponsor 4IT o Business sponsor

2. Support staff 3. Project sponsor

2. Program Manager Senior member Target audience management team from the project Management group 3. Project manager PM for the IT End user representatives group 4. Vendor Project Manager PM for the vendor 5. Business Lead A business user that acts as a project lead

o IT sponsor o Primary users o Vendor/Implementation partner

Are there any stakeholders in a Packaged Software implementation who would not normally be involved in a bespoke software development?

160

Responses from the IT Group

1IT No 2IT 1. Vendor Project manager 3IT --------4IT o Vendor

Would the tasks/roles undertaken by the Packaged Software stakeholders differ if the project had been a bespoke software implementation?
No Typically not. There may be a little more focus around development activities though. Slightly .. they need to own and defend the decisions made about change of process, especially if this is driven by the package. Tasks would not change necessarily, but the effort and complexity of the tasks would be more complex.

What do you see as the roles and responsibilities for the Business during a Packaged Software implementation?
1. Define requirements 1. User acceptance testing Process workshops o User requirements definition

2. Participate in and approve design 3. Participate in system configuration 4. Complete UAT 5. Train end-users

2. Responsible for any Business Process changes or training 3. Identification of key business requirements

Owning the solution Change management Acceptance testing (preparation and doing)

o Business process design o SOP documentation o Data quality o User acceptance testing

161

Responses from the IT Group

1IT 6. Champion system 2IT 3IT 4IT o User acceptance testing

What do you see as the roles and responsibilities for the Software Supplier/Implementer during a Packaged Software implementation?
1. Facilitate requirements session identifying key requirements that impact configuration 1. Provide expertise around product knowledge Delivery of a working product o Project management

2. Guide system design with best practices in mind 3. Communicate potential issues and implications with design/configuration decisions 4. Complete configuration 5. Complete unit testing 6. Complete integration testing 7. Provide training to group of users 8. Deploy application to business

2. Provide industry expertise based on other implementations 3. Provide skilled and knowledgeable resources

Support Documentation

o Application configuration o Unit testing

Potentially workshops for training and administration

What do you see as the roles and responsibilities for the IT department during a Packaged Software implementation?
1. Participate in and facilitate, with vendor, requirements sessions 1. Act as the liaison between the business and the vendor Architecture o Project management

162

Responses from the IT Group

1IT 2IT 3IT 4IT

2. Participate in and facilitate, with vendor, design sessions

3. Coordinate internal resources to ensure activities are completed in time for vendor and business 4. Serve as point person for vendor for issues, concerns, question, etc. 5. Monitor and report progress of implementation activities

2. Ensure that the business requirements are being met by the packaged software 3. Organize internal It resources as needed

Strategic fit

o Infrastructural design and preparation o Interface design and development

End to end delivery

Technical Change Management Technical Project Management

o Application configuration o Unit/System/Integration/Performance testing o Data conversion o Post go-live operation and support

6. Own project delivery 7. Communicate status, issues, decisions to key stakeholders

When a gap exists between the functions of the Packaged Software and the User Requirements, studies have shown that for an ERP system, changing the Business Processes is the best course of action. Do you feel that this also applies to all Packaged Software implementations?
No. Depending on the level of change required by the business, it may be better to modify the system rather than the process. Yes, I believe in most cases business processes should be changed Depends entirely on the solution Yes

163

Responses from the IT Group

1IT 2IT 3IT 4IT

In what circumstances would you consider customisation to be appropriate?

1. Processes that have proven efficient and effective over time, where modifying them would reduce effectiveness or require the business to significantly change the organization 2. An inability to satisfy a critical requirement where the softwares effectiveness to the business is greatly reduced Customization would be appropriate if there was a very large gap in the package software and only after a cost benefit justification has been performed. The cost benefit justification for the customization should take into consideration the ongoing maintenance of the custom program as well as the other intangibles related to having a custom piece of programming. Where APIs are provided and legacy support promise is given. The customisation should be able to work separately to the application if required. o Regulatory compliance o Localization requirements o Customizations that yield measurable business justification

If you were considering customising the Packaged Software, would you perform any cost benefit analysis? If so how would this be undertaken?
Yes. Measure the cost impacts of the change against the benefits (e.g. lower transaction times, improved throughput). Yes, the cost benefit analysis would be undertaken. It would be necessary to get input from the various teams and the analysis would have to consider all of the intangible pros and cons with developing customization. The payback period would be an important consideration as well. Yes. Depends on the process you are proposing, try to avoid the cost of not doing something type analysis (cost avoidance). Yes requestor of customization should provide documented measurable benefit

In what circumstances would it not be appropriate to change the business process in order to fit with the Packaged Software? 164

Responses from the IT Group

1IT 1. Cost or schedule impacts of software changes are too great to justify maintaining the process. 2. Changes required in software would nullify support contract or create major support issues going forward. 2IT One key circumstance would be if the new business process impacted customer satisfaction or regulatory compliance issues. These impacts have large negative impacts to the business and should be taken into consideration during the cost benefit analysis. 3IT Highly specialised and definitive to the business. One that is seen as being "competitively advantageous" 4IT o Processes that provide differentiating advantages to the marketplace may not be candidates for process changes

165

Appendix F Linking for comparisons between ERP and results for Packaged Software CSFs.

166

Appendix G Risk Analysis

In round one the panel were asked what they considered to be the risks associated with implementing Packaged Software. The returned answers were consolidated into a single list containing all the risks that had been identified. The list was then presented back to the panel in round two. This time the panel were asked to asses each risk listed, the probability of the risk occurring, and if it did occur, what would the impact be? To enable the responses to be quantified a simple Likert scale with values of low, medium and high was used.

The results have been presented in three different ways:-

By Probability. This ranks the risk in the order that the panel feel are the risks most likely to occur, so that they can be prioritised accordingly.

By Impact. The risks are ordered by the risks having the most impact on the project. A risk that has a high impact and a low probability needs to be factored into a project plan as it could have potentially disastrous consequences.

By Overall Score. This ranked the risks by combining both probability and impact scores.

167

The ranking for both the Probability and Impact lists were calculated the same way. A value was given to each interval of the Likert scale in order to give a weighting to the answers chosen.

Low = 1

Medium = 2

High = 3

The ranking score was then calculated as follows with n being the number of occurrences of the answer for each individual risk:-

Score = (n * LowVal ) + (n * MediumVal ) + (n * HighVal )

The overall ranking score for each risk was calculated by adding both the impact and probability scores together.

168

169

170

171

172

Appendix G End

173

Appendix H IT Roles and Responsibilities

A lot of the roles that were identified for the IT group could be classified as Project Management type of roles. These originated mainly from the IT group members of the panel as shown in the following table:-

IT roles and responsibilities identified by IT members of the panel.

The following consolidated list of these Project Management type roles that was presented to the panel in round two:-

Ownership of the project delivery / End to end delivery. Technical Project Management / Project management. Implementation progress monitoring & reporting.

Internal organisation of resources.

174

Communication: - purpose of the project to users, and status, issues, decisions to key stakeholders.

Act as the liaison between the business and the vendor. Participation and facilitation with the vendor of the requirements/design sessions to ensure that the business requirements are met by the packaged software.

Most of the disagreement about these roles came from the Business and this is shown in the following tables.

175

176

177

Appendix H End

178