Increasing the Value of Research: A Comparison of the Literature on Critical Success Factors for Projects, IT Projects and Enterprise Resource Planning Projects

Abstract

Since the beginning of modern project management in the 1960s, academic researchers have sought to identify a definitive list of Critical Success Factors (CSFs), the key things that project managers must get right in order to deliver a successful product. With the advent of Information Technology (IT) projects and, more recently, projects to deliver Enterprise Resource Planning (ERP) systems, attention has turned to identifying definitive lists of CSFs for these more specific project types. The purpose of this paper is to take stock of this research effort by examining how thinking about each type of project has evolved over time, before producing a consolidated list of CSFs for each as a basis for comparison. This process reveals a high degree of similarity, leading to the conclusion that the goal of identifying a generic list of CSFs for project management has been achieved. Therefore, rather than continuing to describe lists of CSFs, researchers could increase the value of their contribution by taking a step forward and focusing on why, despite this apparent knowledge of how to ensure their success, ERP projects continue to fail.

1. Introduction

Over time, Enterprise Resource Planning (ERP) systems have evolved into suites of packaged software solutions that support organisational and inter-organisational information needs and activities. Vendors promise their customers reduced cost of inventory, production, shipping, labour and Information Technology (IT) maintenance, arguing that this will lead to increased effectiveness and, potentially, that elusive competitive edge [1,2,3]. However, this promise is too often broken, evidenced by the fact that the analyst firm, Gartner, estimated recently that 55%–75% of ERP projects fail to deliver their objectives [4]. This is an intriguingly high figure for a packaged software solution, particularly one without the inherent risks of complex bespoke development, and reliant on project management for implementation, a tried and tested activity in the modern day organisation.

The management of projects was formalised as a discipline in the middle of the last century [5] and project managers are now supported by a plethora of advice, guidance, standardised tools, techniques and methods. At the same time, academic researchers have worked hard to identify a definitive list of Critical Success Factors (CSFs) for project managers, those key things that they must get right in order to deliver a successful product. Over time, attention has turned from CSFs for traditional projects to those for more specialised types of project. For example, from the 1980s onwards, as IT invaded the workplace more pervasively, researchers began work on the identification of a relevant list of CSFs for IT project managers. More recently, ERP projects have received the same attention. The identification of CSFs for project management is, therefore, a mature and active area of research.

The overarching purpose of this paper is to take stock of the literature across these three bodies of work: CSFs for traditional projects, for IT projects and for ERP projects. This is a comparison that has not been undertaken previously and it provides a unique insight into the similarities between these three domains. There have been decades of effort to identify these lists of CSFs and to create a body of research, raising a series of questions. Firstly, is it possible to identify a single list of CSFs that can be used to guide the management of all projects, whatever their type, or is there a need for lists that are tailored to the requirements of different types of project? Secondly, how do the lists for traditional projects, IT projects and ERP projects compare and are there CSFs that are specific to either IT or ERP projects? The third and final question stems from Grabski et al.’s assertion that a definitive list of CSFs for ERP projects has now been identified [6]. The comparative study undertaken here is used as a basis for asking whether this is so. Has a definitive list that is relevant to all projects been identified and, if so, to what extent does this provide practical value? This leads to consideration of potential areas of research that might have greater impact on the future practice of project management.

The discussion begins by considering whether IT and ERP projects are different from other types of project and, if so, what this means in terms of their CSFs. It then compares the evolution of the three bodies of literature, looking at traditional project management, then IT and, finally, ERP projects. At the end of each discussion, a consolidated list of CSFs is identified. A study of traditional project management, which has benefitted from a longer period of research, was undertaken in 2006 to identify the various lists of CSFs and to synthesise them into a single list. This provides a snapshot of thinking at that point in time. For IT project management, a similar snapshot is taken at 2010, while for ERP project management, six literature reviews were examined and synthesised to determine a consolidated list as of 2016. Thus, this paper presents a longitudinal rather than a cross-sectional study, with the three types of project being compared at three different points in time. Ultimately, this process demonstrates that these areas of study are all very similar but, despite this, there is remarkably little cross-citing of research across the three domains. In addition, this study clearly demonstrates that the identification of a definitive, core list of CSFs has been achieved and that there are, therefore, diminishing returns from the continued research effort. However, there is still much that needs to be understood with regard to CSFs. Much greater value could be delivered to the practitioner, the project manager, if researchers were to switch their efforts to determining why, despite this knowledge of how to ensure success, ERP projects continue to fail. It is questionable whether this research has had any impact on practice, whether CSFs are understood and used by project managers and, if they are, whether they have the positive influence on the success of the project that they promise.

2. Methodology

For the review of the literature on traditional and IT project management, articles from five leading electronic business and management databases (ABI-Inform, Ebsco Business Source Complete, Emerald, Springerlink, and Taylor and Francis Informaworld) were sourced through a systematic review of publications from 1990 to date, giving extensive coverage of the relevant literature. The advanced search option was selected and the terms ‘project and failure’ and then ‘project and success’ were searched, firstly in the article title field and then in the keyword field. The search was limited to peer-reviewed English language journals, which were then further assessed for relevance. The citation details of the selected papers were categorised according to project type and then stored in chronological order in a spreadsheet. The identified CSFs from each article were extracted and the relationships between the studies were identified and analysed. The references in the selected papers were then used to source other relevant literature, enabling the review to move through a variety of sources and to ensure the fullest possible coverage, as advocated by Bates [7].

In terms of the ERP project management literature, the same process was used as a means of understanding the evolution of thinking. Very specific articles, such as those looking at a particular country or considering CSFs from the stakeholder perspective, were excluded. In order to then produce a definitive list, a search was undertaken for those articles that had reviewed the literature in order to produce a consolidated list of CSFs identified over time. To do this, the search terms ‘enterprise resource planning’ and ‘critical success factors’ and ‘literature review’ were entered into the databases, restricted to peer reviewed and English language journals from the 1990s onwards. The same process of analysis was undertaken.

To answer the questions posed by this paper, only selected and specific aspects of this analysis are considered and not the entirety of the identified literature. Despite these exclusions, the aim is to give as complete an overview as possible of the work that has been undertaken in order to demonstrate how thinking has progressed over time in relation to each of the three areas of research.

3. The Same Difference?

The first question posed in the introduction to this paper asked whether there is a need to consider different types of projects or whether all projects require the same project management skills and, therefore, the same CSFs. The academic tendency to characterise all projects as similar was highlighted by Pinto and Covin in the late 1980s [8] with Pinto and Mantel then arguing that every project is unique [9]. Later, the IT project management literature picked up on this point, also talking about specific types of project within specific contexts. For example, in 2001, Lyneis et al. argued that if projects are unique then learning across projects is difficult [10]. By 2010, Howell et al. were suggesting that, as every project operates in a different context, it should be managed accordingly [11]. This line of thought brings the whole basis of a definitive list of generally applicable CSFs into question, whilst also raising questions about the ongoing endeavour to identify such a list. This strand of thinking suggests that projects cannot be classified, that there is no appropriate typology and that, therefore, the continued endeavour to identify a definitive list is in vain.

Despite these arguments that every project and its context is unique, there have been attempts to categorise and differentiate IT and ERP projects from other types of project. In the mid 1980s, Spector and Gifford concluded that IT projects are different to other projects, describing IT design as one of the least classical of the engineering disciplines with products that are often poorly understood, unmanageably complex and unreliable [12]. Pinto and Covin then speculated further on this difference, highlighting that IT projects experience greater risks, that their requirements and processes are unique, and that they have unpredictable outcomes, along with scheduling difficulties [8]. In the mid 1990s, Morris consolidated this thinking, stating that,

“IT projects do indeed pose a particular class of management difficulty. The essence of this difficulty is the way that information technology is so intimately bound into its organisational context. As a result, issues of organisational effectiveness and user involvement are both more complex and more prominent in IT projects than they are in most other project industries. This puts much greater emphasis on the tasks of project definition and user involvement in IT than in other project situations”.

([13], p. 323)

According to Fitzgerald and Russo in 2005, the high rate of IT project failure is largely due to these organisational and social factors rather than to the technological challenges [14]. Kappelman et al. took this thought further, asserting that “IT projects never fail because of technical causes, despite the fact that people and process problems may manifest technically” ([15], p. 32). There is evidently a strong line of argument that IT projects are different due to the nature of the product, the greater risks that they bring and, critically, their implementation being so closely bound with their organisational context. This means that the IT project manager needs to be fully aware of the organisational ‘fit’, how well the system matches the organisation in terms of its people, process and technology. What then of ERP projects? Is it sufficient to classify them as IT projects or are there stark differences?

According to Markus and Tanis, ERP systems are more broadly concerned with their technological, operational, managerial, strategic and organisational components than IT systems which, in their view, tend to focus on the functions within an organisation [16]. Milford and Stewart are more categorical, stating that ERP projects differ because they impact on the whole organisation, potentially requiring employees to learn new business processes in addition to new software, and resulting in the implementation often being business-led rather than IT-led [17]. Wallace and Kremzar argue that ERP systems are primarily people systems that are enabled through technology [18]. However, the same point is made by Davis et al. in relation to IT projects, arguing that success is dependent on the interaction between the information system and the social system in which it operates [19]. Somers and Nelson make another attempt to pinpoint the difference by considering the scale, scope, complexity, organisational change and project costs of an ERP project, along with the required business process reengineering [20]. Dezdar and Sulaiman argue that ERP projects are not simply about IT but rather the delivery of integrated applications that impact the entire organisation [21]. This, they consider, makes them strategic and, therefore, they must be approached as such in terms of their project management. Grabski et al. state that ERP projects are inextricably linked with the organisation’s operational structure and business processes, requiring joint activities in terms of operation and process reengineering, as well as in terms of ERP configuration [6]. They note that IT projects minimise business process reengineering because software is written to match current business processes, whilst ERP projects minimise software modifications but result in significant process and organisational change [22].

It is evident from these arguments that an ERP project is a complex and challenging task with many associated factors that are likely to impact on the level of success that an organisation can expect to achieve as a result of its implementation. For these reasons, it is unlike a typical functionally-oriented IT project [6]. However, there are different scales of IT project and an IT mega-project, of the type typically tackled by governments, would be equally large-scale, expensive and complex with an inevitable impact on communities, environment and budgets [23]. However, an ERP project is differentiated by its intrinsic link with the firm’s operational structure and business processes, requiring joint activities in operations and process re-engineering, as well as ERP configuration. Therefore, IT projects are subtly different from other types of project due to their close relationship with the organisational context and their users, while ERP projects are embedded within that organisational context. Despite this subtle difference, it is evident that these projects share many of the same characteristics as well as having certain highly specific requirements.

The first question asked whether a single list of CSFs can be used to guide the management of all projects, whatever their type, or whether there is a need for different lists that are more suited to the requirements of different types of project. Given this discussion, it is apparent that the type of project needs to be considered and its different characteristics taken into account as they are likely to result in different CSFs. Having said this, the above discussion also indicates that some of the same project management skills are likely to be required across all projects, whatever their type. This suggests that there is, therefore, a core list of CSFs that is applicable across all projects, along with other CSFs that are relevant to particular types of project. Given the nature of IT projects, the expectation of this study is that a number of these more specific CSFs will relate to organisational and social issues. With regard to CSFs for ERP projects, there is likely to be a greater emphasis on those factors that relate to the organisation, the management of significant organisational and business change, and the management of end-to-end business processes. The second question tests this thinking, asking how the lists of CSFs compare across these three bodies of research and whether they include CSFs that are specific to each project type. The next section, therefore, begins with an overview of the evolution of thinking about CSFs for traditional projects.

4. CSFs: The Route to Project Success

It was Daniel in the 1960s who introduced success factors to the management literature, ushering in a new organisational approach to the achievement of performance goals and competitiveness [24]. A decade later, it was Rockart who defined them as:

“…the limited number of areas in which results, if they are satisfactory, will ensure successful competitive performance for the organisation…

…the few key areas where ‘things must go right’ for the business to flourish…

…areas of activity that should receive constant and careful attention from management...

…the areas in which good performance is necessary to ensure attainment of (organisational) goals”.

([25], p. 85)

These words show a clear correlation between the achievement of satisfactory results in identified but limited areas of project management activity and the delivery of a successful project. CSFs appeared to provide a mechanism to aid the planning, managing, monitoring and achievement of organisational goals through projects and, as such, the concept generated considerable interest in industry [26]. Therefore, the identification of CSFs is not only of academic interest, but is also relevant to practitioners, given its potential influence on project success [27]. Therefore, the idea of CSFs gained wider acceptance in terms of traditional project management before being explored further in relation to other types of projects, such as IT projects and, more recently, ERP projects [28].

Early academic effort to identify those ‘limited number of areas’ tended to concentrate on the three classical measures of project management, the so-called ‘iron triangle’: the management of resource consumption (cost); the setting of specifications, requirements or quality (scope); and delivery to a finite timescale (time) [29]. Atkinson describes these as “two best guesses and a phenomenon”, meaning that they can only be estimated at the planning phase, a time of great uncertainty and incomplete data [30]. This means that these forecasts are highly likely to change during the course of the project lifecycle [31]. In addition, they measure only the project management phase and so reflect the specific concerns of the project team rather than the broader aspirations of the stakeholders [31]. Despite these concerns, the iron triangle persists and is defended as a means of keeping project management on track [32]. Arguably, it provides a clear assessment of the efficiency and effectiveness of the project management, as well as a check on the potential business value of the outcome [31]. However, for many researchers, it is simply a measure of the success of the project management and not of the ultimate success of the project.

Along with the iron triangle, the research effort has been focused on producing lists of CSFs and, as such, it has diverted across a number of avenues, including: differentiating the success of the project management from the success of the product of that project; the move to more complex, multi-dimensional and integrated CSF frameworks that incorporate the organisational and managerial variables that exist outside of the immediate project; identification of the need for strategic project management; and the championing of a more contingency-based approach. The mechanism for describing CSFs has evolved from the production of lists to the drawing of frameworks, an evolution that is illustrated by tracking the seminal work of Pinto, who has undertaken a number of studies over time along with a number of his colleagues. This programme of research began in the mid 1980s with the identification of ten CSFs, as shown at

Table 1. From Lists to Frameworks.

Critical Success Factors	Slevin and Pinto (1986)	Schultz, Slevin and Pinto (1987)	Pinto and Slevin (1989)
Project Mission	X		X
Top Management Support	X	Z	X
Schedule/Plans	X	Z	X
Client Consultation	X	Y	X
Personnel	X	Y	X
Technical Tasks	X		X
Client Acceptance	X	Y	X
Monitoring and Feedback	X	Y	X
Communication	X	Y	X
Troubleshooting	X	Y	X
Clearly Defined Goals		Z
Sufficient Resources		Z
Characteristics of the Project Team Leader			X
Power and Politics			X
Environmental Events			X
Urgency			X
Key:
X = CSF Identified
Y = CSF Important During Project Phase (Tactics)
Z = CSF Important During Planning Phase (Strategy)
Pinto and Slevin’s Framework for ‘True’ Project Implementation Success [36]

. Having determined an initial list, it was then categorised according to whether the CSFs were considered to be ‘strategic’ (important during the planning phase) or ‘tactical’ (important during the project phase) [33]. This categorisation relates to de Wit’s differentiation of ‘project management success’ from ‘project success’ [34]. He defined ‘project success’ as the performance of the product of the project, while ‘project management success’ is concerned with the inputs to the project itself (i.e., the iron triangle), which may lead directly or indirectly to product success. Following a similar train of thought, Pinto and Covin noted that CSFs vary throughout the lifecycle of a project with some important in the early stages whilst others become critical later [8]. The CSFs in the early stages are ‘internal’ or project-related, while ‘external factors’, such as customer needs and satisfaction, are product-related, becoming increasingly important as the project progresses. In other words, there are certain CSFs that relate to the planning and development stages, while others are important during implementation and, ultimately, throughout the long-term operation of the product. This point is emphasised here because there is still considerable overlap and confusion in the literature, making it difficult to disentangle the idea of project success from project management success. Arguably, there may be an inherent danger in separating the two, given that overlooking the CSFs for the product during the project management phase could ultimately lead to failure. The next evolution was the identification of four additional CSFs, which are also shown at Table 1 [35]. The first ten CSFs (project mission, top management support, schedule/plans, client consultation, personnel, technical tasks, client acceptance, monitoring and feedback, communication and troubleshooting) are considered to be within the control of the project team, but the additional four may not be. They are:

• Characteristics of the project team leader;
• Power and politics (the degree of political activity within the organisation and the perception that the project may further the self-interests of specific individuals);
• Environment (the likelihood of external factors affecting the operations of the project team, either positively or negatively); and
• Urgency (the perceived importance of the project or the need to implement it as soon as possible).

Following this, the CSFs that had been identified, validated and categorised by Pinto and his colleagues were drawn into a framework, depicting the overlap between Technical Validity (budget and schedule), Organisational Validity (client satisfaction in terms of product use and benefits to end users through increased efficiency or employee effectiveness) and Organisational Effectiveness (value in terms of positive impact, merit and improved efficiency), with ‘true’ project implementation success at its core [36]. This clearly demonstrates that the factors leading to project success are not singular and isolated but multi-dimensional and interlinked.

Despite this early move to more sophisticated thinking, the mid 1990s saw Belassi and Tukel berating the continued prevalence of lists of CSFs that, in their view, were either too general or too specific [37]. They picked up on Pinto and Slevin’s earlier argument that it is not individual CSFs that cause project management to succeed or fail but a combination of multiple factors that vary in importance as the project progresses through its lifecycle [36]. Their resulting framework consists of four categories of CSFs that relate to the project; the project manager and the project team; the organisation; and the external environment. This thinking both confirmed and extended Pinto’s work, firmly associating the project with organisational and environmental factors. In addition, Belassi and Tukel clearly identify the implications of these factors not being addressed, as well as showing the relationships between individual factors and different groups of factors. As they observe, lists of CSFs provide no mechanism for taking these interrelationships into account [37].

By the 2000s, Lyneis et al. were articulating their frustration at the tendency to take a partial and narrow view of project management, focusing either on ‘soft’ or ‘hard’ CSFs when there is a need to attend to both, given that they are simultaneously important [10]. They also call into question the entire basis of a generic list of CSFs, arguing that every project is unique, making learning across projects difficult, if not impossible. In their view, project managers need to think strategically at numerous points, including the design phase; the identification of indicators to measure, monitor and control; the risk management process; any mid-course corrections; and when attempting to incorporate past learning from previous projects [10]. Thinking along similar lines, Shenhar argued for strategic project leadership, most particularly for those projects that are designed to deliver competitive advantage (such as an IT or ERP project) [38]. He agrees that projects are unique and argues that this means that each one requires a different type of leadership.

Following on from this, Dvir et al. defined four CSFs: an essential and urgent operational need; a cohesive development team; exactly defined operational and technical requirements; and learning mechanisms [32]. Of these, they emphasise the first, the operational need, arguing that if end-users consider a project to be important, then it has a better chance of succeeding. However, in contrast to Lyneis et al., they believe that learning from other projects can substantially improve this chance. Milosevic and Srivannaboon then took the strategic project management argument one step further, aligning project management with business strategy and considering their mutual influence [39]. Cooke-Davies et al. then explored the influence of business strategy on both the nature of the projects undertaken and the appropriateness of the project management processes [40]. Both the degree of fit between an organisation’s strategic drivers and the configuration of its project management system influence the value that it obtains from its project management. Project success is, therefore, related to the right management approach, which is, in turn, related to the characteristics of the specific project. This further demonstrates the need to understand the type of project being tackled and the need to differentiate IT and ERP projects.

At the same time as the merits of strategic project management were being considered, Shenhar was making the link between project management and contingency theory, arguing that the effectiveness of the organisation depends on how it responds to a range of external conditions, termed contingency factors, in order to maintain its fit with the environment [41]. Expanding on this idea, Pich et al. observe that the project management discipline is ‘instructivist’ by nature, relying on pre-determined signals to trigger pre-specified actions [42]. However, in order to decide what best to do, the project manager needs to have pre-requisite knowledge and skills rather than simply acting according to pre-specified instructions, thereby placing the emphasis on ‘constructivism’ rather than instructivism. Lauras et al. then questioned whether it is possible for a project manager to control numerous CSFs in a very complex project environment, particularly if that project is unique and highly subject to its context [43]. Almost in response, Howell et al. propose their Project Contingency Theory, arguing that as every project operates in a different context, it should be managed accordingly [11]. The ‘one size fits all’ approach is sub-optimal; a project’s structure and management practices should be tailored to suit its context. However, despite these persuasive and compelling arguments, the application of contingency theory to project management remains rare [11].

Having begun this discussion by considering types of project, it might be expected that the focus of the traditional project management literature would be on the process of managing a project. However, this overview suggests that there is a great deal of reference to the organisational and social factors, along with consideration of the unique nature of projects, rather than treating them as standard and regularised operations. While thinking about CSFs for projects has evolved over time, the production of lists persists as a popular activity. For example, in 2011, Mishra et al. published a paper that investigated project-based organisations to find 49 CSFs which they categorised according to the project manager’s capabilities, the project team, the organisation, the environment, and tools and techniques [44], while in 2015, Besteiro et al. published a list of 19 CSFs that, amongst other variables, were involved in successful project management [45]. This is despite the fact that, in 2006, Fortune and White undertook extensive work to consolidate and synthesise the lists that had been identified previously in 63 publications, producing a single definitive list of 27 CSFs, as shown at

Table 2. Categorised Critical Success Factors (CSFs) for Project Management.

27 CSFs
63 Publications
Listed in Order of Importance (Based on Numbers of Citations)	Categorisation of Factors
	Organisational (O)/Process (P)/Social (S)/Technological (T)
Support from senior management (39)	O
Clear realistic objectives (31)	P
Strong detailed plan kept up-to-date (29)	P
Good communication/feedback (27)	S
User/client involvement (24)	S
Skilled/suitably qualified/sufficient staff/team (20)	S
Effective change management (19)	O
Competent project manager (19)	P
Strong business case/sound basis for project (16)	O
Sufficient/well allocated resources (16)	P
Good leadership (15)	S
Proven/familiar technology (14)	T
Realistic schedule (14)	P
Risks addressed/assessed/managed (13)	P
Project sponsor/champion (12)	S
Effective monitoring/control (12)	P
Adequate budget (10)	P
Organisational adaptation/culture, structure (10)	O
Good performance by suppliers/contractors/consultants (10)	S
Planned close down/review/acceptance of possible failure (9)	P
Training provision (7)	S
Political stability (6)	O
Correct choice/past experiences of project management methodology/tools (6)	P
Environmental influences (6)	O
Past experience (learning from) (5)	S
Project size (large)/level of complexity (high)/number of people involved (too many)/duration (over three years) (4)	P
Different viewpoints (appreciating) (3)	S

[46]. The most frequently cited CSFs, which they considered to be the most important, are listed first, although it is not clear that simply counting citations is a solid indicator. The top three CSFs were ‘Support from senior management’, ‘Clear realistic objectives’ and a ‘Strong detailed plan kept up-to-date’. However, it should be noted that, of the reviewed articles, only 17% included all three of these, although at least one of the three appeared in 81% of the papers. Given the discussion about how the emphasis of the CSFs might change according to the type of project, particularly in relation to IT and ERP projects, each CSF has been categorised according to whether its focus is on the Process of project management, the Social or Organisational aspects or on the Technology being implemented. This aids comparison and shows that the focus of the list is split between the Process issues (11) and the Social issues (9), with more limited reference to Organisational issues (6) and little reference to the Technological issues (1). Of the top three CSFs, two are concerned with Process issues and one with Organisational while, of the top ten, three are concerned with Social, while only three focus on the Process of project management, demonstrating that social and organisational issues are critical to the successful delivery of traditional projects.

Fortune and White’s much-cited paper is now a decade old and, as such, provides a snap-shot of the research at a single point in time. The factors that it identifies are relatively generic and are still being identified today, as evidenced by the two papers cited above by Mishra et al. [44] and Besteiro et al. [45], for example. Therefore, it provides a basis for comparison with the two other bodies of literature on IT and ERP project management, a means of determining whether any significant differences have emerged as this form of study has moved on in time and to different types of project. The above discussion shows that there is much within traditional project management to inform anyone embarking on either an IT project or an ERP project. The next stage is, therefore, to consider and compare the evolution of the scholarly debate by considering the CSFs for IT project management.

5. CSFs for IT Projects

From the 1980s, IT began its takeover of the workplace and, at the same time, the search for those CSFs that are specific to IT projects began. More lists were produced but, from the very start, they showed a greater level of concern with the complex and cultural issues of organisations. There was also a much earlier realisation of the need for organisational fit than is evident in the traditional project management literature and recognition that it is frameworks not lists that enhance understanding of the interrelationships between CSFs. For example, Markus and Robey’s idea of ‘organisational validity’, the fit between the organisational context and the IT system [47], appeared five years before Pinto and Slevin’s framework (Technical Validity/Organisational Validity/Organisational Effectiveness), shown at Table 1 above [36]. Markus and Robey’s model contains four levels of analysis: User-System Level, Structure-System, Power-System and Environment-System Level [47]. Pliskin et al. later added a fifth level, Culture-System, concerned with “the fit between the organisational culture presumed in the design of the system and the actual organisational culture in the implementing organisation” ([48], p. 146). However, Markus and Robey carefully cautioned against assuming that validity leads to effective use or invalidity to ineffective use [47]. Again, five years before de Wit made his argument in relation to traditional projects [34], they had recognised that successful IT project management does not ensure the success of the product. This depends on the extent to which the delivered product, the IT system, matches the organisational thinking and behaviour. However, even if it is organisationally valid, a system is unlikely to deliver significant benefits if it merely automates inefficient ways of working; alternatively, while users might resist the use of an invalid system it could still yield major improvements in terms of organisational effectiveness.

Davis et al. went further, creating a framework based on two premises: “an information system is a social system that uses information technology” and IS success or failure cannot be explained in terms of either the IT alone or the social system alone ([19], p. 294). His framework, therefore, includes the social system (reactions to the technical system, indicators of performance, development processes and theories in use) and technical aspects (technology, user interfaces, information requirements and organisational fit), giving 16 areas or factors that indicate potential reasons for failure. However, Lyytinen and Hirschheim considered this too narrow, suggesting that the macro-social and historical factors should also be investigated, along with the multi-causal relationships that are more immediately involved in failure [49]. They raise the spectre of the wider environment and its impact on the project, acknowledged earlier by Markus and Robey [47], while their thinking corresponds with Belassi and Tukel’s view of the importance of interrelationships in projects in general [37].

Sauer also highlights the importance of interrelationships with his Triangle of Dependence Approach, arguing that the IT system relies on the project organisation to maintain it, the project organisation relies on supporters for resources, and the supporters expect benefits from the system [50]. Flaws in any of these relationships are likely to have a negative impact on the IT project, leading to failure or termination. This again recognises the need for organisational fit. Linking back to the work of Markus and Robey [47] and adding to Pliskin et al.’s thoughts [48], Heeks et al. argue that a successful IT system matches the technical, social and organisational factors in its specific context, as well as the perceptions of its key stakeholders [51]. However, the purpose of a newly implemented IT system is to support and generate organisational change and a system that exactly matches its organisational context is unlikely to change it. Heeks et al. conclude that success is more likely when change is limited, because the level of risk is then reduced. This means that the initiator of the IT project has to make a trade-off between change and risk: reducing the size of change may increase the chance of success but decrease the organisational benefits; increasing the size of change may reduce the chance of success but increase the benefits. This highlights the role of change in the success or failure of an IT system and the need to match that system to its highly specific and unique context. In terms of CSFs, this is less about lists and much more about carefully considering the system’s interaction with the organisation to highlight where the critical issues lie.

In 2005, Fortune and Peters captured this broader thinking, including addressing the IT project’s relationship with its wider environment, in their Formal Systems Model (FSM) for IT projects [52]. They describe this as “a model of a robust system capable of purposeful activity without failure” ([52], p. 97). The FSM not only identifies the possible points of failure in a project and all possible CSFs but also considers how they might be managed, offering an important move forward in thinking. The model consists of the system (the project) sitting within a wider system (the organisation), both of which sit within an environment. The wider system defines the purpose and sets the objectives of the system, providing resources, influencing the decision makers and monitoring the performance of the system as a whole. The environment disturbs the system both directly and indirectly through the wider system and vice versa. The Formal System has a decision-making sub-system, a performance monitoring sub-system and a set of sub-systems that carry out the tasks. This model also picks up on subjective issues, like expectations management, as well as noting the need for decision-making processes and the requirement for the project to fit the organisation and beyond. It also very clearly shows the interrelationships between single CSFs and groups of factors, bringing together much of the thinking demonstrated in both the traditional and IT project management literature over the years.

Chua notes that the research on CSFs for IT project management tends to split into two threads [53]. The first is concerned with ‘specific factors’, the CSF lists, while the second thread looks at the systemic nature of IT project management, the specific organisational context and the emergent properties that cause its overall success or failure. This latter approach produces a series of issues and actions, rather than a single set of static factors. The above review deliberately focuses on the second in order to clearly highlight the earlier move to a broader definition of IT project management than is apparent in the traditional project management literature, showing concern with the organisation and structure of the project, along with its context and its environment. This demonstrates that more attention has been given to synthesising factors into interrelating groups in the IT project management literature. However, for the pragmatic purposes of ease of comparison, the 25 CSFs that were derived from this review of 58 publications are presented as a list, which is shown at

Table 3. CSFs for IT Project Management [54].

25 CSFs
58 publications
Listed in Order of Importance (Based on Numbers of Citations)	Categorisation of Factors
	Organisational (O)/Process (P)/Social (S)/Technological (T)
User/client involvement (33)	S
Clear realistic objectives (28)	P
Support from senior management (26)	O
Skilled/suitably qualified/sufficient staff/team (25)	S
Proven/familiar technology (22)	T
Organisational adaptation/culture/structure (19)	O
Realistic schedule (15)	P
Project size (large)/level of complexity (high)/number of people involved (too many)/duration (over three years) (14)	P
Sufficient/well allocated resources (13)	P
Good performance by suppliers/contractors/consultants (12)	S
Strong detailed plan kept up-to-date (11)	P
Correct choice/past experience of project management methodology/tools (10)	P
Differing viewpoints (appreciating) (10)	S
Competent project manager (9)	S
Effective monitoring/control (9)	P
Environmental influences (9)	O
Good communication/feedback (9)	S
Training provision (9)	S
Adequate budget (8)	P
Good leadership (6)	S
Strong business case/sound basis for project (6)	P
Effective change management (5)	O
Political stability (4)	O
Past experience (learning from) (2)	S
Risks addressed/assessed/managed (1)	P
Not included for IT Projects (2 CSFs)
Planned close down/review/acceptance of possible failure	P
Project sponsor/champion	S

. As with Fortune and White’s work on the traditional project management literature, shown above at Table 2, this provides a snap-shot of where the research community had got to in terms of deriving a definitive list of CSFs for IT project management by 2010. Fortune and White’s taxonomy is used in order to determine whether the same emphasis is placed on the same CSFs, although different terms may have been used to describe the same concept in the original source texts.

As with the previous list, the CSFs appear in order of frequency of citation on the basis that this demonstrates their level of perceived importance. The three most cited are ‘User/client involvement’, ‘Clear realistic objectives’ and ‘Support from senior management’. Two of these also appear in the top three for traditional project management: ‘Clear realistic objectives’ is second in both instances, while ‘Support from senior management’ switches from first to third, as shown at

Table 4. Top Three CSFs for IT and Traditional Project Management.

Rank	IT Projects	Traditional Projects
1	User-Client Involvement (S)	Support from Senior Management (S)
2	Clear Realistic Objectives (P)	Clear Realistic Objectives (P)
3	Support from Senior Management (S)	Strong Detailed Plan Kept Up-to-Date (P)

. Of the 58 IT project management publications reviewed, 84% included at least one of these top three CSFs in comparison to 81% identified by Fortune and White, while only 13% identified all three (17% for Fortune and White). Surprisingly, there is no reference to ‘Project sponsor/champion’ in the identified IT project management literature or to ‘Planned close down/review/acceptance’. However, it may be that ‘Project sponsor/champion’ has been subsumed into ‘Senior management support’.

Based on the perceived difference of IT projects, the expectation was that there would be a greater emphasis on the organisational and social factors. As discussed previously, the list of CSFs for traditional projects, shown at Table 2, is split between the Process issues (11) and the Social issues (9), with more limited reference to Organisational issues (6) and Technological issues (1). The list for IT project management shows a similar split between Process (10) and Social (9). Of the others, there are five Organisational issues and only one CSF that relates to the Technological issues. Of the top three CSFs, two are concerned with Social factors and one with Process, compared to one for Social and two for Process in the traditional project top three. If this is expanded to consider the top ten for IT, three are relevant to Social issues, four to Process with two Organisational and one Technological issue. Therefore, there is a much more even spread across these four broad areas than might have been expected.

Maddison’s update of Fortune and White’s work in relation to the IT project management situation shows little difference in terms of the identified CSFs [54]. Overall, this comparison demonstrates that the CSFs identified for IT project management are broadly the same as for traditional projects, with a particularly high level of correspondence in terms of the top three CSFs and no great variance in terms of the emphasis on social and organisational issues. Therefore, how do these CSFs compare with a more current list of those being identified in relation to ERP projects? To answer this question, the next section charts the evolution of thinking about this type of project before deriving a synthesised list of identified CSFs from a series of literature reviews. This provides a basis for comparison with the snapshots of Fortune and White’s work from 2006 and the work on CSFs for IT project management from 2010.

6. CSFs for ERP Projects

Much of the early research on ERP projects was based on descriptive studies of specific experiences of implementation, both successful and unsuccessful [55]. This was in spite of the mature literature base that underpins traditional project management and, even more relevantly, IT project management. However, this initial concern with case studies indicates the requirement to describe and understand how a new technology operates in context before attempting to derive wider and more generally applicable lessons. Following these initial case studies, Francoise et al. note four key areas of research activity: the implementation process, related organisational problems, risk management and CSFs [56]. Grabski et al. identify a three-way split with studies on CSFs, organisational impact and economic impact [6]. The way in which the research is categorised notwithstanding, it is evident that the study of CSFs has emerged as the most prolific area of endeavour, perhaps largely due to the continued failure of ERP projects [21,57].

The focus of these studies on CSFs has typically been to identify those factors associated with successful implementation, which tend to be derived from either case studies or surveys [6]. Generally, this body of literature has followed much the same route as the research into traditional projects and IT projects. For example, the distinction between project and product success, which was highlighted by de Wit [34], Pinto and Covin [8], as well as Markus and Robey [47], is explored by Markus and Tanis in relation to ERP projects, albeit using different terminology [16]. ‘Project success metrics’ refers to the iron triangle, while ‘business value metrics’ refers to the wider business improvements resulting from the product. Similarly, the ERP literature shows the same preference for lists of CSFs, but with greater emphasis on their categorisation and less evidence of the frameworks that are seen in the IT project management literature. On the other hand, the ERP literature has diversified more rapidly, moving from consideration of CSFs for ERP projects in general to delving into more specific CSFs for different functional areas, for different sized organisations, for different countries, for different cultures, for different industries and for different stakeholder groups. However, for the purposes of this paper, it is the more general view of CSFs for ERP projects that is of interest, given that it provides a more direct comparison with the work on projects and IT projects.

As noted above, there has been a tendency to categorise the lists of CSFs for ERP projects with a view to illustrating the relationships between factors, their multi-dimensional and interlinked nature [21]. Akkermans and van Helden note the high level of correlation between CSFs for ERP projects and that, as a result, a change in one will impact on others [58]. In order to more clearly articulate this relationship, Grabski and Leech used factor and regression analysis in their 2007 study to show a significant five-way interaction between five broad factors: project management, change management, alignment of the business with the new system, internal audit activities and consultant planning activities [22]. This clearly demonstrates how the interrelationship between factors works, underlining the fact that focusing on one key area alone will not deliver success and that the impact of each factor “depends on or is moderated by the levels of the other factors” ([22], p. 35). The origins of this thinking also appear in the work undertaken by Pinto and Slevin [36], and Belassi and Tukel [37] in the traditional project management domain and by Markus and Robey [47], Pliskin et al. [48], Davis et al. [19], Sauer [51] and Fortune and Peters [53] in the IT project management literature, although they are not referenced by Grabski and Leech [22]. They also demonstrate that lists of CSFs provide no mechanism for taking these interrelationships into account.

However, the linkage with Slevin and Pinto’s work is clearly evident in efforts to differentiate between strategic and tactical CSFs, with a range of ERP authors suggesting variations on this theme [59]. Holland and Light simply borrow the strategic and tactical categories [60], while Esteves and Pastor expand them into a matrix that includes organisational and technological CSFs [61]. Al-Mudimigh et al. add an operational category [62] while, more recently, Finney and Corbett have reverted back to the original binary categories of strategic or tactical [28]. Others have categorised according to the stages in the project lifecycle, including Chen [63], Nah et al. [64] and Somers and Nelson [20]. Al-Mashari et al. established a taxonomy based on the setting-up, implementation and evaluation of an ERP project, aligned with business-wide performance measures [65]. Kerimoglu et al. then categorised CSFs according to technology, organisation, user, external expertise and ERP project, and then used them to represent either the ERP adopting organisation or the ERP system [66]. Mehrjerdi [67] uses Sauer’s Triangle of Dependence Approach [51] with its vertices of system, supporters and organisation to categorise Somers and Nelson’s list of 10 CSFs [20]. Therefore, in terms of the progression of the literature on CSFs for ERP projects, there is evidence of a degree of cross-reference to both the traditional and to the IT project management literature, although perhaps not to the extent that might be expected.

Not unexpectedly and as with studies of IT project management, this body of work shows early recognition of the complex organisational and cultural environment into which the ERP system is being introduced, going on to consider the level of technical expertise required for successful introduction. Davenport warns against a mismatch between the technical specifications and the business requirement [68], a view that aligns with Markus and Robey [47], Pliskin et al. [48] and Heeks et al. [51] in the IT project literature. This thinking is also replicated by Volkoff in relation to ERP projects, highlighting the need for mutual adaptation between the IT and user environment [69]. With strong links back to the work of Davis et al. [19], Wallace and Kremzar [18] argue that ERP systems are primarily people systems enabled through technology, while Genoulaz and Millet express their concern that project managers tend to focus on the technical and financial aspects of a project, whilst neglecting the non-technical issues, like people [70]. There is also evidence of systems thinking, as well as reference to Davis et al, with acknowledgement of the ERP system as a people system. For example, Ghosh and Skibniewski argue that ERP systems are complex adaptive systems and, therefore, all different, requiring unique project governance and management in order to adapt to interconnectedness and communication with, and control over, the different stakeholders [71]. It has been argued that research on ERP projects is treated as ‘secondary’ and that those concerned with the academic study of IT project management have neglected its importance [72]. However, from this overview, it appears that the ERP literature has followed much the same route as the IT project management literature, whilst also making reference to the project management literature, and that the effort is particularly vigorous with regard to the identification of CSFs. How then do the identified CSFs compare?

In order to answer this question, six review articles were selected from the ERP literature base. The first of these, published in 2000, is by Esteves-Sousa and Pastor-Collado, who derived 20 CSFs from 10 key papers, which they then categorised according to their strategic or tactical value to either the organisation or the technology, as discussed above [61]. Interestingly, in the technological category, only five CSFs appear as either strategic or tactical, while the remaining 15 are categorised as either strategic or tactical in the organisational category. Esteves-Sousa and Pastor-Collado then weighted these according to number of citations to show that the organisational aspects are more important than the technological. They then provide a detailed description of each CSF, aiming to capture exactly what action is required in order for that factor to be managed successfully. They conclude that most of the factors identified are ‘classics’, meaning that they are not specific to ERP projects and nodding towards the idea of a definitive core list. However, they also reiterate Bancroft et al.’s view that, given the complexity of these particular type of projects, each factor “takes on greater significance” ([73], p. 67). This suggests the need for more attention to be paid to how these CSFs are understood in a practical ERP project environment and increased scrutiny of how they are applied in project management terms.

The second paper is one of the most cited in relation to CSFs for ERP projects. Nah et al. analysed 10 articles that appeared between 1998 and 2000 to identify 11 CSFs [64]. They then categorised them according to the four phases of the ERP life cycle model, as proposed by Markus et al: chartering, described as decisions defining the business case and solution constraints; project (getting the system and end users up and running); shakedown (stabilising, eliminating bugs, getting to normal operations); and onward and upward (maintaining systems, supporting users, getting results, upgrading and system extensions) [74]. This process confirms the work of Pinto and Covin, which was undertaken a decade earlier, further demonstrating that different factors are important at different stages of a project [8]. In line with Esteves-Sousa and Pastor-Collado [61], Nah et al. add further definition to the very general descriptors that tend to be used for CSFs in order to make them more understandable and to enhance their utility for practitioners as well as for academics [64]. In other words, they attempt to change CSF descriptors from nouns to verbs, clearly stating how the factor needs to be managed, what needs to be done, rather than simply naming the CSF with a very general description, such as ‘Change Management’.

At the same time as Nah et al.’s study, Somers and Nelson undertook an extensive literature review to identify a list of 22 CSFs, although the exact number of articles from which this list was derived is not stated [20]. The list was then tested through a survey of 86 companies from 12 different industries to show that the three most critical CSFs for an ERP project are ‘Top management support’, ‘Project team competence’ and ‘Interdepartmental cooperation’. Only one of these, ‘Top management support’, appears in the top three for projects and IT projects. In line with Nah et al.’s work, described above, these 22 CSFs were then linked to a lifecycle model (initiation, adoption, adaptation, acceptance, routinisation, and infusion), a process that confirms Pinto and Covin’s view that CSFs are ‘temporal’, taking on particular significance in the project lifecycle for a particular period of time [8]. The ‘Top management support’ CSF was found to be vital at every stage of this lifecycle, apart from adaptation. Somers and Nelson stress the importance of attending to all of these CSFs, highlighting the significant effort and top management involvement required to ensure that a project receives the necessary resources, time and priority [20].

In 2007, Finney and Corbett undertook a systematic content analysis of 45 papers to identify 26 CSFs, arguing that much of the research into ERP projects has focused on either a specific CSF or a specific aspect of the implementation process with little research encompassing all significant CSF considerations [28]. In their view, the considerable research effort into CSFs for ERP projects has failed to take into account the stakeholder perspective. They go on to suggest that if project teams were aware of the concerns of their stakeholder groups then they would be able to address them more effectively, thereby enhancing the probability of success. In line with the work of Holland and Light [60] but without reference to Pinto and Slevin [36], they categorise these CSFs as either strategic or tactical. Their second intent in this study is to uncover the deeper meaning of some of the strategic and tactical aspects of the more widely cited CSFs, to make that meaning more explicit, thereby giving it greater utility in practice, and following the lead of Esteves-Sousa and Pastor-Collado [61], and Nah et al. [64].

Dezdar and Sulaiman undertook a comprehensive review of 95 articles published between 1999 and 2008 to identify 17 CSFs for ERP implementation projects [21]. They then compared their findings with the work of Nah et al. [65], Somers and Nelson [20], and Finney and Corbett [28]. They found that, of these 17 CSFs, 12 were common to all four studies. However, they also described two ‘new’ CSFs, defined as ‘system quality’ and ‘user involvement’, before revisiting Kerimoglu et al.’s model [66] to give three top level categories: ERP System Environment, ERP Adopting Organisation Environment, and ERP Implementation Success. ERP System Environment is further broken down into ERP Technology (with the CSFs being ‘careful system selection’, ‘software troubleshooting’ and ‘system quality’) and External Expertise (‘vendor support’ and ‘the use of a consultant’). ERP Adopting Organisation Environment is broken into ERP user (‘user training and education’), Organisation (‘top management support’, ‘enterprise-wide communication’, ‘business plan and vision’, ‘organisational culture’, and ‘business and IT legacy systems’) and ERP project (‘project management’, ‘business process reengineering’, ‘change management programme’, ‘ERP team composition’ and ‘project champion’). ERP Implementation Success is broken into ERP project success (‘on time’, ‘within budget’, ‘achieving pre-determined goals’) and ERP business success (‘inventory reduction’, ‘time to market reduction’, ‘personnel reduction’). This categorisation clearly and accurately identifies the source of any implementation problem.

In 2010, Leyh undertook a systematic literature review of articles from five different databases and several international conference proceedings to identify 185 papers and 31 CSFs [75]. The top three factors were ‘Top management support and involvement’, ‘Project management’ and ‘User training’, broadly aligning with the top three for IT project management. In 2015, and in association with Sander, he updated this review, increasing the base to 320 relevant papers to reconfirm both the 31 CSFs and the top three [76]. This gives a very full and detailed account of each CSF, clarifying exactly what each means, and again attempting to move from a short description to a full explanation of what a project manager should do specifically in order to manage each factor. They then compare their review with Finney and Corbett’s to show that the top five are the same, albeit not appearing in the same order, and categorise their CSFs according to whether they are tactical or strategic, in line with Esteves-Sousa and Pastor-Collado [61]. This again shows that the majority of CSFs (17 out of 31) sit within the organisational strategic or tactical areas, rather than the technological strategic or tactical, where there are only six CSFs. In addition, only one of the top 10 factors, ‘Organisational fit of the ERP system’ is categorised as technological.

Overall, these reviews identify a number of different CSFs that are derived from a varying number of articles using different search strategies. These different approaches aside, the second question for which an answer is sought is how these three lists compare and whether they include CSFs that are specific to each project type. Therefore, the CSFs identified in these six papers were also classified according to Fortune and White’s categories, a process that inevitably required an element of subjective interpretation of the varying terminology [46]. The results are shown at

Table 5. CSFs for Enterprise Resource Planning (ERP) Projects.

25 CSFs—Listed in Order of Importance
Derived from Examination of c.480 Publications
Listed in order of importance (based on numbers of citations)	Categorisation of Factors
	Organisational (O)/Process (P)/Social (S)/Technological (T)
Correct choice/past experience of project management methodology/tools (6)	P
Effective change management (6)	O
Good communication/feedback (6)	S
Project sponsor/champion (6)	S
Skilled/suitably qualified/sufficient staff/team (6)	S
Support from senior management (6)	O
Training provision (6)	S
Strong detailed plan kept up-to-date (5)	P
Effective monitoring/control (5)	P
Good performance by suppliers/contractors/consultants (5)	S
Strong business case/sound basis for project (5)	O
Organisational adaptation/culture/structure (4)	O
User/client involvement (4)	S
Clear realistic objectives (3)	P
Adequate budget (2)	P
Competent project manager (2)	S
Planned close down/review/acceptance of possible failure (1)	P
Realistic schedule (1)	P
Sufficient/well allocated resources (1)	P
Specific to ERP Projects (6 CSFs)
Business process re-engineering and minimum customisation (6)	O
Software analysis, testing and troubleshooting*	T
Appropriate business and IT legacy systems (5)	T
Careful selection of ERP software (4)	T
System quality (1)	T
ERP system acceptance/resistance (1)	O
Not included for ERP Projects (8 CSFs)
Environmental influences	O
Different viewpoints (appreciating)	S
Good leadership	S
Past experience (learning from)	S
Political stability	O
Project size (large)/level of complexity (high)/number of people involved (too many)/duration (over three years)	P
Proven/familiar technology	T
Risks addressed/assessed/managed	P

. It should be noted that Somers and Nelson do not state how many papers they reviewed and so the overall number of ERP publications can only be assessed.

Of Fortune and White’s original list of 27 CSFs for traditional projects, 25 were also identified in the IT project management literature and 19 in the ERP literature, while 17 were common across all three. In terms of the top three for traditional project management and IT project management, ‘Support from senior management’ is first for the general literature, third for the IT literature and cited by all six reviews of the ERP literature, whilst also being included in Somers and Nelson’s three most critical CSFs for ERP projects [20]. Leyh and Sander also identify ‘Top management support and involvement’ as the most important CSF, noting that it appears in more than 200 papers [76]. However, there is also evidence of CSFs that are specific to each project type. Eight CSFs appeared in the project and IT project literature but not in the ERP literature, while six are unique to ERP projects. These are: ‘Business Process Re-Engineering and minimum customisation’; ‘Software analysis, testing and troubleshooting’; ‘Appropriate business and IT legacy systems’; ‘Careful selection of ERP software’; ‘System Quality’; and ‘ERP system acceptance/resistance’.

There was an expectation that the CSFs for these projects would be different. In line with the forecast for the IT project management literature, it was thought that there would be factors related to organisational fit but also to the management of significant organisational and business change, and the management of end-to-end business processes. Overall, there were eight factors related to Social issues, eight to Process, five to Organisational and four to Technological. Of Somers and Nelson’s top three, one is Organisational (‘Interdepartmental cooperation’) and two are Social (‘Top management support’ and ‘Project team competence’ [20], while one of Leyh and Sanders’ list is concerned with Organisational issues (‘Top management support and involvement’), one with Social issues (‘User training’) and one with Process (‘Project management’) [76]. Six of the reviews identified the same nine CSFs, four of which are concerned with Technological issues. If these are compared with the top nine identified by the traditional and IT project management literature, the emphasis is not dissimilar, as shown at

Table 6. CSFs Categorised by Issue and Compared.

	Organisational	Process	Social	Technological
Traditional Projects	2	2	5	0
IT Projects	1	4	3	1
ERP Projects	2	1	5	1

, although there seems to be slightly more similarity between ERP and traditional projects, than ERP and IT projects.

The second question asked how the identified lists across these three bodies of research compare and whether they include CSFs that are specific to each project type. While it is recognised that the above comparison is not scientific but rather illustrative, it clearly shows that there is a core of CSFs that apply across all projects. It also demonstrates that, for all types of projects, there is evident concern about the wider issues that exist beyond the project management process, particularly in terms of the organisational and social issues. Given this, the next section considers in more detail whether this matters and what it means for project managers. In doing so, it focuses on the third question, whether this provides evidence of a definitive list that can be applied to all forms of project and, if so, what value this continued replication of research effort is delivering. It ends by tackling the final question, which asks where next for the study of CSFs and for CSFs for ERP projects in particular.

7. Discussion

Pinto and Slevin noted that “there are few topics in the field of project management that are so frequently discussed and yet so rarely agreed upon as that of the notion of project success” [35] (p.68). It is evident from the examination of the literature carried out for the purposes of this paper that there is an ongoing and enthusiastic effort to research this topic across all project domains. Despite this, Grabski et al. argue that those factors that it is both sufficient and necessary for the project manager to address have not yet been clearly identified [6]. However, the reviews and cross-comparison undertaken for this study demonstrate that there is, in fact, a high degree of similarity in terms of the CSFs being identified and that there has been for some time. Of course, this leaves open the question of whether these are the factors that it is sufficient and necessary to address; they have simply been identified. From the consolidated list for project management in 2006 to IT projects in 2010 to ERP projects in 2016, the same CSFs reappear with a core list of 17 that are evident across all three areas, as shown at

Table 7. A Core List of CSFs.

CSF	Categorisation of Factors
	Organisational (O)/Process (P)/Social (S)/Technological (T)
Support from senior management	O
Clear realistic objectives	P
Strong detailed plan kept up-to-date	P
Good communication/feedback	S
User/client involvement	S
Skilled/suitably qualified/sufficient staff/team	S
Effective change management	O
Competent project manager	S
Strong business case/sound basis for project	O
Sufficient/well allocated resources	P
Realistic schedule	P
Effective monitoring/control	P
Adequate budget	P
Organisational adaptation/culture, structure	O
Good performance by suppliers/contractors/consultants	S
Training provision	S
Correct choice/past experiences of project management methodology/tools	P

. As Esteves-Sousa and Pastor-Collado conclude, most of the factors identified are ‘classics’, meaning that they are not specific to ERP projects but are relevant to the management of any type of project [61]. This also confirms Francoise et al.’s view that it is easy to draw up a fairly comprehensive list of CSFs and that there is now a broad area of agreement on the few key areas that must go right [56].

Of the CSFs identified in this core list, seven relate to the Process of project management, six to the Social issues and four to Organisational. The fact that Technological issues do not feature seems to confirm Kappelman et al.’s assertion that they are not a direct cause of failure, but rather the manifestation of underlying Social and Process issues [15]. In other words, it is the understanding of the technology, and the skills and knowledge that pertain to it that are at fault, rather than the technology itself. The core list is presented diagrammatically at Figure 1, showing the overlap between CSFs for traditional, IT and ERP projects, along with those that are unique to a project type. Note that none were identified as being relevant only to IT projects. However, for the purposes of this exercise, the CSFs that were identified in the IT literature were interpreted fairly broadly to fit with the CSFs identified in the traditional project literature. Of the six CSFs that are specific to ERP projects, four relate to Technological issues, which is perhaps not unexpected given the challenges of these large-scale implementations. One is concerned with Organisational issues, the challenges of business process re-engineering across an organisation, which again relates specifically to this type of project. The other is a Social issue, focused on the potential resistance to or acceptance of the massive change that such a project is likely to bring. These CSFs clearly reflect the issues of this particular type of project. It is evident that there is a requirement to understand the technology being used in an ERP project, but also the organisational context into which that system is being introduced. Therefore, for the ERP project manager, the list of CSFs identifies the required core management skills and the six CSFs that are specific to ERP projects, confronting the technological issues and how they impact both organisationally and socially.

Despite this apparently positive conclusion, a note of caution must be added. Inevitably, the review of the ERP literature undertaken for this paper is not conclusive. It demonstrates a level of consistency across a relatively high number of CSFs and so suggests a degree of consolidation around those specific factors that need to be addressed. It also shows a clear alignment with the findings for both IT and traditional projects. However, there are a number of issues to be confronted when attempting this type of comparison, not least the fact that there is a wide-ranging difference in terms of the scope of these studies, particularly with reference to the number of journals identified and reviewed in order to create synthesised lists of CSFs. Dezdar and Sulaiman are critical of the inconsistent way in which the literature has developed, noting that different scholars identify and classify different CSFs using different approaches [21]. As a result, Law and Ngai criticise the many inconsistent and inconclusive findings [72]. These are sound points, which are equally applicable to the approach taken in the traditional and IT project literature. Most of these studies and literature reviews cannot be reproduced because descriptions of the review methods and procedures are lacking, highlighting a lack of methodological rigour. Inevitably, therefore, this makes cross-comparison difficult.

The analysis undertaken for the purposes of this paper is also open to criticism for its subjective and interpretive nature. The original terms used by the researchers to describe the CSFs that they have identified through their research have been translated according to Fortune and White’s categories for traditional projects, a task that required personal judgement and a certain amount of construal of the terminology being used. Strauss and Corbin warn of the dangers of using borrowed terms and suggest that researchers should be precise about the meanings of the terms that they choose to use [77]. Yet, due to the variation in the wording, it is inevitable that there is a level of interpretation in a study of this type. Dawson and Owens express their frustration that different authors use different terminology for the same CSF or encompass in one description what others describe in two [78]. Dezdar and Sulaiman highlight the need to begin systematising the terms that are used to describe them [21]. There is evidently a need for greater consensus on how these CSFs are described through use of a recognised and defined taxonomy. The identified CSFs for all types of project management should be logically structured in a way that makes sense to the business, not too deep or too wide, whilst containing all of the necessary terms to describe the business and make sense to the practitioner. The study conducted here provides a basis for this taxonomy to be developed further, providing a mechanism for describing the CSF that has been identified, for determining whether it has previously been identified or whether it is new or updated. In doing so, it may be that the credibility of this research is raised in the eyes of the practitioners, providing a clear line of thought and direction, rather than continual re-confirmation of the same CSFs using different terms.

By focusing the research in this way, attention can be turned from the description of lists to a deeper understanding of these identified factors and, more particularly, of their characteristics. To date, however, this is purely aspirational because the terminology remains broad and fails to capture the activity required; CSFs tend to be presented as nouns rather than verbs and as keywords or phrases rather than sentences that explain what is required of the project manager in order to ensure good performance. As discussed above, Dawson and Owens have noted the lack of depth in the identification of CSFs and the lack of definition of the concepts listed [78]. They use the example of ‘Change management’ which, despite being one of the most widely cited CSFs, has varied definitions with little explanation of what specific tactics are required. They criticise the lack of detail about the specific implementation tactics that are needed to manage change. Their point is sound. Overall, the terminology tends to be very general, failing to capture the essence of “the few key areas where ‘things must go right’” ([25], p. 85). It is one thing to note that change management is required, but quite another to determine what effective change management might be and how it might be delivered and measured. Again, the research effort would deliver better value to both other researchers and practitioners if the factors were to offer interpretive explanation rather than simply description.

While Fortune and Peters took a step along the path of supporting the management of CSFs with their FSM for IT project management, there is a requirement for further work that seeks to encapsulate the necessary activity that might ensure the delivery of a successful factor, in terms of the required behaviour and skills as well as the underlying issues, rather than simply offering a broad theme [53]. It is difficult for project managers to comprehend from these descriptive CSFs what they need to do to ensure that “things…go right”, how to give “constant and careful attention” or how to determine “good performance” ([25], p. 85). It is clearly evident that there has been a move in this direction in the current ERP literature. Esteves-Sousa and Pastor-Collado aim to capture exactly what needs to be managed in relation to each factor [61]. Nah et al. have also expanded on the single term approach to make these factors more understandable [64], while Dezdar and Sulaiman also attempt to uncover the deeper meaning of some of the more widely cited CSFs [21]. Leyh and Sander also clarify what is meant by each CSF, indicating required action as well as description [76]. This provides a good basis for continued refinement, thereby enabling practitioners to translate the theory of CSFs into actions that are operationally useful and ensuring that these factors become truly critical to the delivery of success.

The entire purpose of identifying CSFs is to assist project managers to manage their projects in order to deliver a successful product. When first outlined, the concept of CSFs generated interest within industry and was seen as a means of aiding the planning, management, monitoring and achievement of organisational goals through projects. The idea of CSFs as an insurance policy for the delivery of success was obviously highly desirable. Given this, it is evident that the identification of CSFs should not only be an academic pursuit for its own sake, but should produce an outcome that is of use to project managers and that will help them to deliver successful projects. This review of the generic, IT and ERP project management literature confirms that a great deal of work has been carried out to find ways of improving project management. The logical conclusion is that there is now sufficient understanding of these CSFs to enable good practice in the planning and management of all types of projects. Despite this, projects continue to fail with depressing regularity, particularly in the IT and ERP domains. Gartner has recently suggested that nearly all cloud ERP projects will fail by 2018 [79]. How can this be so, if the factors that determine success have been identified? More than 20 years ago, Martin Cobb of the Secretariat of the Treasury Board of Canada posed his famous paradox at the Standish Group’s CHAOS University, a conference where the year’s 10 most complex IT projects were being analysed [80]. He observed that it is known why projects fail and that the means of preventing their failure are also well known. His remarks are reinforced by the findings of this paper. Why then, he asked, do they still fail? His question remains pertinent to this day and particularly in relation to the identification of CSFs. If there is a definitive list and if this list has been apparent for a decade, reiterated according to different project types, as suggested by this study, why are projects and, in particular, ERP projects, still failing? Cobb’s paradox raises questions about the whole basis of this area of study and the perception that having commonly agreed CSFs will lead to the failure of fewer projects.

The answer to this question remains an ongoing challenge for the research community and yet it is potentially where greater value might be derived from their efforts. El Sawah et al. state that the understanding of the role of CSFs in success is still inadequate, suggesting that, while CSFs may have been identified, they have not been analysed to the extent that is required for them to really contribute to the success of a project [81]. As discussed above, lists, frameworks and categories do not necessarily establish meaningful validity for the project management practitioner. In addition, de Wit questions whether CSFs are good indicators or pre-conditions of success or failure and concludes that, while their presence might not guarantee successful project management, their absence will most likely to lead to the failure of the project [34]. In a study by Maddison, which took place between 2002 and 2010, practitioners were asked to assess their understanding and application of CSFs to a major government infrastructure project [54]. In terms of understanding, it was evident that they knew about CSFs, that they had permeated the project via specific policy and processes or as a result of oversight and assessment by external bodies, such as the UK National Audit Office. CSFs were also gleaned from similar projects and applied accordingly. However, as the project developed over time, it became increasingly unique, thereby making it self-reliant in terms of finding solutions to problems and switching the emphasis to learning from experience rather than managing a few key areas that must go right. Knowing and understanding the CSFs was one thing but the extent to which these CSFs were applied within the project was quite another and turned out to be variable with differing effect. There was evidence that the CSFs were being interpreted according to the context, culture and ways of working within the organisation and that this, in turn, was affecting the ways in which they were being applied. Therefore, the impact of these CSFs on this project was debatable.

Overall, research needs to pay more attention to how these CSFs are understood and used in a practical ERP project environment with increased scrutiny of how they are being used in project management terms. Collins suggests that the problem with IT failures is not a shortage of best practice, but the lack of adherence to it [82]. In relation to this discussion, identifying lists of CSFs as an academic study is one thing, but seeking evidence of their application in practice and the effect of that application is another. Sauser et al. confirm that, despite their academic popularity, their application has not been successful and the identification of CSF lists and frameworks seems to have had little impact on project management practices [83]. In their view, few organisations are actually using these findings to improve their project management processes. However, this is based on the continued failure rates rather than scrutiny of the understanding and application of CSFs in practice. Despite this extensive research, there still appears to be a dearth of research to determine whether the guidance on how to manage projects successfully, whatever their type, is being followed comprehensively, although there is anecdotal evidence that it is not [82]. As stated previously, this is where researchers should re-focus their activity, with a view to adding practical value and, ultimately, overturning the expectation of failure, as evidenced by Gartner’s comments on cloud ERP, despite the clear theoretical knowledge of how to succeed.

Early on, Pinto and Covin noted that some CSFs are common to all or most projects, but that there are also significant differences depending on the type of project being tackled [8]. The above comparison demonstrates that there is a degree of consistency but that the issue is how these CSFs are used in practice, whether lip service is paid as lists are ticked or whether these factors are actively being managed and, if so, to what effect. Bancroft et al. argued that, given the complexity of ERP projects, each factor “takes on greater significance” ([73], p. 67). This is an important point, illustrating further the need to understand the project type and to have an awareness as a project manager of where to focus effort. Around 25 years ago, Pinto and Mantel pointed out the uniqueness of each project [9]. This opened up a new line of thought that projects cannot be classified according to type and that the continued endeavours to identify a definitive list are in vain. Lyneis et al. argued that, given that projects are unique, learning across projects is difficult, drawing into question the entire premise of CSFs and the idea of a universally applicable list that needs to be managed to ensure success [10]. Howell argued that projects have to be managed according to their context [11]. This means that there is a requirement for highly specific management of a range of organisational and social issues that are particular to a defined context. Lauras et al. questioned the project manager’s ability to control a list of numerous CSFs in a complex, unique project that is context-specific [43]. These views suggest that the continued search for CSFs may be something of a wild academic goose chase, that there is little in the way of general project management theory that can be applied to a particular project in a specific context. These are statements that go much deeper than simply identifying lists and frameworks of CSFs, requiring further research if both researchers and project managers are to increase their understanding of the effect of context and, therefore, the success of projects.

Different projects require different management approaches and these different approaches need to take different CSFs into account. Similarly, the findings of this comparison demonstrate that there are certain CSFs within the ERP literature that relate specifically to the nature of the technology being implemented. Looking across these three areas of study, it is evident that the core CSFs have been identified and confirmed, suggesting that it is possible to determine a definitive list of CSFs. However, there is still an onus on each project manager to clearly understand how these CSFs might be applied in the unique context of their unique project, whatever its type, and then to identify those CSFs that are most likely to be relevant to that specific project within that specific context. This places a great deal of onus on the project manager, who needs to understand the organisation and the potential impact of the project on that organisation. As Pich et al. concluded, project management requires a constructivist, not an instructivist, approach [42]. In terms of CSFs, this is less about lists and much more about considering the skills that the project manager needs in order to carefully consider the system’s interaction with the organisation and to determine where the critical issues lie. The ‘one size fits all’ approach is sub-optimal; a project’s structure and management practices should be tailored to suit its context. It is through the examination of these issues that research can truly add value on the subject of CSFs for project management.

8. Conclusions

The aim of this study was to gain an insight into the research field of CSFs. Whilst this is an aim that has been set by many authors over time, this study is unique in that it examines three bodies of work, comparing the traditional project management literature with the IT and ERP project management literature. This overview, which demonstrates the immense effort that has gone into identifying CSFs over the years, began by querying the need to consider different types of projects. The ensuing examination determined that IT and ERP projects may indeed be considered different from other types of project because of the product that they deliver and the context in which it is delivered. IT projects were identified as having a close relationship with the organisational context and the user, while ERP projects are embedded within that organisational context. It was assessed that they are likely to share many of the same CSFs relating to organisational and social issues but that the CSFs for ERP projects are more likely to emphasise factors relating to the organisation, the management of significant organisational and business change, and the management of end-to-end business processes. Ultimately, this presents challenges for project managers that need to be clearly identified by the research community if theory is to have an impact on practice.

The comparison across the three areas of research demonstrated that each has moved in broadly the same direction over time. Three consolidated lists were identified to provide snap-shots over the period of a decade. This showed that the list for traditional project management, which was identified in 2006, was largely replicated by the IT project management research by 2010 and is evident in the ERP literature in 2016. This produced a core list of 17 CSFs that are prevalent across the three bodies of literature. Seven of these relate to the process of project management, six to the social issues and four to organisational. Despite the expectation that the nature of the different types of project might result in a different emphasis on the type of CSF being identified, there was little evidence of this. Therefore, this scrutiny resulted in the identification of a core list that is relevant to all forms of project, raising questions about why this research effort continues to be replicated and about the value of this replication to the operational project manager. There is, of course, nothing wrong with confirming and re-confirming knowledge; it is a key requirement of research and of the need to test research. There is no suggestion that this practice should discontinue, although there needs to be greater demonstration of methodological rigour and greater conformity in terms of the taxonomy being used in these studies to enable more precise testing of findings across bodies of work. A more precise and universal categorisation will give the practitioner a much clearer understanding of CSFs, what they are and how they should work, than the varied and confused picture that is currently being presented.

However, there is also little evidence that the theoretical work on CSFs is being transferred from academic papers to the way in which a practitioner approaches and undertakes a project. Project managers are supported by a plethora of advice, guidance, standardised tools, techniques and methods. CSFs need to offer far greater value than simply providing yet another list for project managers to tick. In order to add to their utility, there needs to be less description, less use of nouns and greater use of verbs to clearly articulate what the project manager needs to do in order to ensure that these CSFs are being managed to best effect. There also needs to be a greater research effort to determine the extent to which these CSFs are being understood and applied in the field, and how effective they are in terms of unique projects being undertaken in highly specific contexts. Research needs to move beyond the identification of CSFs to greater understanding of their application and why, despite knowledge of why projects fail, they continue to do so. There needs to be greater comprehension of the skills and knowledge required by a project manager in terms of a constructivist, rather than instructivist, approach. These words encompass a major challenge to the research community in terms of changing the question from what are the CSFs to how these CSFs can be of benefit to project managers and to their projects, to changing from description to interpretive explanation. The value of research into CSFs will only be confirmed when it is clearly demonstrated that it has a positive effect on project success.