Advertisement

Elucidation of IS project success factors: an interpretive structural modelling approach

  • D. Laurie Hughes
  • Nripendra P. Rana
  • Yogesh K. DwivediEmail author
Open Access
Notes to production: S.I. : Project Management and Scheduling 2018

Abstract

This study extends the debate surrounding the components of IS project success by reviewing success factors from the perspective of their interdependency and influence on each other. This research utilises interpretive structural modelling as the methodology and framework to develop the relationships between the selected factors. This approach is presented as a mechanism that can provide greater insight to the underlying causal interrelationships associated with IS project success and the successful transition to operations. The findings identify a number of key outcomes that have significant driving influence on other interconnected factors in the final model. This study highlights the benefits of an interpretive approach where IS factor interrelationships can be modelled to demonstrate potential influence on other connected factors thereby, increasing the chances of project success.

Keywords

Information systems Projects Success factors Critical success factors Interpretive structural modelling 

1 Introduction

Delivering IS projects successfully has been the goal of many organisations and government departments over a number of years. However, successful outcomes are often hard to define and difficult to achieve (Atkinson 1999; Muller and Jugdev 2012). Researchers have articulated alternative views on how to (a) measure and define success and (b) provide a definitive list of success factors (Dwivedi et al. 2015). Success can often be time bound as initial benefits may not be initially realised when an Information System (IS) is delivered and transitioned to operations. This may lead to the executive questioning the return on investment for the perceived failure of the IS project. However, when benefits are realised after 6 months of operations and the organisation has started to see the positive impact of the project, the executive may reflect on the project from an alternative and more positive perspective (Pinto and Mantel 1990; Wateridge 1995).

Historically, studies have referenced projects being measured against very specific and technical criteria namely: time, cost and quality, often termed the iron triangle. Projects were traditionally judged against one or more of these measures. Generally, the IS literature has highlighted the fundamental issues with this approach, identifying the lack of stakeholder satisfaction criteria or factors relating to the longer-term benefits realisation and value to the organisation (Atkinson 1999; Sauer 1993). Success should be measured by a more interrelated, interdependent and holistic set of criteria that includes stakeholder support for the overall system (Delone and McLean 1992; Rana et al. 2015). Project management standards guidance and methods such as those from the OGC Group and Project Management Institute (PMI), emphasise the importance of defining success criteria at the start of a project and for success to be aligned with organisational benefits realisation (Hughes et al. 2015; Kerzner 2013). The reality within many organisations is that projects are rarely viewed as 100% successful. There are often compromises to be made in the context of scope, functionality, schedule, budget and quality of deliverables, any one of which, could be viewed as categorising the project as only a partial success or alternately a partial failure (Kerzner 2015).

Studies have attempted to define the key set of factors to aid project managers and executives in the delivery of successful IS projects. Whilst many studies provide a list of success factors (SFs) positioned as a set criteria that if followed, can increase the potential of success, many of these factors vary in scope and content between studies (Belassi and Tukel 1996; Muller and Jugdev 2012). This lack of consensus is demonstrated by the variance of views in a number of widely cited studies focusing on SFs (Cooke-Davies 2002; Morris and Hough 1987; Pinto and Slevin 1987).

This study attempts to extend the body of knowledge by exploring the relationships between SFs and identifying how any potential associations between factors can provide fresh insight to the delivery of successful project outcomes. The relationships between factors are developed using a mathematically derived methodology—interpretive structural modelling (ISM). ISM structures a complex problem around a process of modelling via a set of interconnected matrices to represent factor interdependencies (Warfield 1974). This approach imposes classification and direction on the relationships between elements within a complex system (Sage 1977). To the best of our knowledge, this is the first study to examine the inter-relationships between IS project success factors utilising the ISM methodology. The key objectives of this study are as follows:
  • to identify the key interrelationships between SFs based on empirical data via expert participant opinion;

  • to develop a model of the causal links between SFs to identify interdependencies in the context of driving and dependent factors;

  • to present a relationship driven architecture that can clearly identify how certain individual SFs can affect and be affected by other factors in the model and how this can be represented in the real world context;

  • to demonstrate how the application of the ISM methodology can provide fresh insight and contribution to the literature, thereby, furthering the research within this field.

The remaining content of this paper is structured around the following sections: Literature Review, Selection of ISM factors, Research Methodology, ISM process including the steps required to progress through the methodology, Discussion of Results followed by Conclusions.

2 Literature review

The literature has presented a wide variation of approaches to the definition of key factors that are associated with successful project outcomes. The ten critical success factors (CSFs) presented by Pinto and Slevin (1987), indicate a level of interconnectivity between the factors but omit to discuss the factors in the context of their dependencies with each other. Subsequent studies extended this research categorising the CSFs from the tactical and strategic viewpoints at specific stages of the project lifecycle (Pinto and Slevin 1988; Pinto and Prescott 1988). More recent studies reflect the acknowledgement and importance of increased stakeholder involvement and alignment of benefits in driving successful IS project outcomes (Atkinson 1999; Dwivedi et al. 2015; Fortune and White 2006; Muller and Jugdev 2012). The widely cited Real Success Factors outlined in Cooke-Davies (2002), presents a list of 12 factors based on analysis from a number of organisations across 136 separate projects. However, the factors omit any people or change management related factors, therefore, deviating from the main body of research that supports the influence of people orientated or “soft” factors (Hyvari 2006; Muller and Jugdev 2012).

The literature references the transition to a more stakeholder satisfaction oriented criteria (Atkinson 1999; Dwivedi et al. 2015), where studies have referenced this change in emphasis and contribution to successful outcomes. The inclusion of SFs related to benefits management and realisation aligned with user adoption factors, highlights how success is influenced by a more inclusive set of measures (Fortune and White 2006; Hughes et al. 2015; Turner 2009). Studies have outlined how success is driven by specific key factors related to the style and contribution of the project manager, namely—multi-skilled requirements (Hyvari 2006), performance and leadership style (Söderlund 2004; Turner and Müller 2005), personality traits (Creasy and Anantatmula 2013), application of soft skills (Lechler and Dvir 2010; Sumner et al. 2006). Many facets of success are influenced either directly or indirectly by this key role and the interdependencies between project management and other related factors. However, the literature has not explored the causal relationships between this and other SFs and their bearing on IS success.

This study attempts to provide greater insight into the associated relationships between IS related SFs by applying the ISM methodology to a key set of literature derived project success factors. ISM has been used as the method of choice for a number of non-IS success factor related genre studies: digital government (Janssen et al. 2018), big data (Dwivedi et al. 2017), selection of vendors (Mandal and Deshmukh 1994), agility within supply chains (Agarwal et al. 2007), Interactions and barriers in logistics (Ravi and Shankar 2005), sustainable and green supply chains: (Lim et al. 2017; Thamsatitdej 2017), knowledge management in engineering (Singh et al. 2003; Agarwal and Shankar 2003), agile manufacturing (Meade and Sarkis 1999; Purohit et al. 2016). There are limited number of instances in the literature where ISM has been combined with IS related factors: risk factors in software engineering projects (Samantra et al. 2016), critical success factors within banking (Salimifard et al. 2010; Singh 2011), information security parameters (Chander et al. (2013), Manufacturing related IT enablers (Thakkar et al. 2007). These studies although providing context, are not related to understanding IS project SFs and furthering the study of the interrelationships and causal links between factors. The ISM and Interpretive Ranking Process (IRP) related studies by Hughes et al. (2016) and Hughes et al. (2017), focus on IS failure interrelationships and ranking of factors, but omit to develop the required level of analysis relating to IS success factors. To our knowledge this study is the first to incorporated the ISM method to develop a greater understanding of the underlying interrelationships between SFs. We present this approach as a new mechanism to further the research in this area supported by an evidence based—interpretive methodology.

3 Selection of ISM factors

Table 1 contains the list of factors selected from the IS literature. The presented factors represent a summarised and synthesised form of the key success factors from relevant case studies, taxonomy orientated studies and wider research on the underlying SFs of IS projects.
Table 1

List of IS success factors

No.

Success factor name

Definition

References

1

Engaged and committed sponsorship

Effective and supportive sponsor fully engaged and committed to the project

Christianson and Walker (2004), El Emam and Koru (2008), Gray (2001), Kearns (2007), Lemon et al. (2002), Nixon et al. (2012), Patton and Shechet (2007), Prosci (2012), Schmidt et al. (2001), Sumner et al. (2006), Standish Group (2013), Young (2005)

2

User involvement throughout the project

Users included as key stakeholders early in the project lifecycle and throughout the project

Barker and Frolick (2003), Dan et al. (1998), Gauld (2007), Keil et al. (1998), Niekerk and Steyn (2011), Pan et al. (2008), Poon et al. (2011), Procaccino et al. (2005), Scott and Vessey (2000), Yeo (2002)

3

Use of skilled resources

The project team is formed around a set of people that have the required skills and experience

Procaccino et al. (2005), Sumner and Molka-Danielsen (2010)

4

Skills, experience and style of PM

The appointed project manager has the required blend of skills, experience and style to manage the project effectively

Atkinson (1999), Belout and Gauvreau (2004), Christianson and Walker (2004), de Miranda Mota and de Almeida (2012), Haggerty (2000), Hyvari (2006), Marnewick (2012),.Mir and Pinnington (2014), Muriithi and Crawford (2003), Turner and Müller (2005)

5

Management of scope

Project scope is formally managed as a key project process

Dekkers and Forselius (2007), El Emam and Koru (2008), Keil et al. (1998), Parsons-Hann and Liu (2005), PMI (2014), Schmidt et al. (2001), Tamai and Kamata (2009)

6

Project audit process in place

Organisation has a formal project audit function in place

Hughes et al. (2015), Jones (2006), Kerzner (2013), PMI (2014), Verner et al. (2008)

7

Use of project management methodology

Projects managed in accordance with a defined methodology

Lepmets (2010),), Papke-Shields et al. (2010), Poon et al. (2011), Tiwana and McLean (2003)

8

Clear business case

The project has clear and defined business case

OGC Group (2013), Kerzner (2015), Pan et al. (2008), PMI (2014)

9

Resistance management process

The processes required to management user resistance are an integral component of the project

Bartis and Mitev (2008), Beynon-Davies (1995), Brown and Jones (1998), Dwivedi et al. (2015), Fitzgerald and Russo (2005), Gauld (2007), Hiatt and Creasey (2012), Klaus and Blanton (2010), McGrath (2002), Prosci (2012)

10

Organisation project maturity

The organisation has a project oriented culture and a record of project delivery

Hiatt and Creasey (2012), Lechler and Dvir (2010), Kerzner (2015)

11

Formalised role definitions

The project has formal established role definitions

Avison and Wilson (2002), Kerzner (2013), OGC Group (2013), Philip et al. (2009), PMI (2014)

12

Tools and infrastructure

The project has the required tools and infrastructure

Kerzner (2015), Milosevic and Patanakul (2005), Raymond and Bergeron (2008)

13

Formal risk management

The project has a formal process in place to manage risk

Cooke-Davies (2002), de Bakker et al. (2010), OGC (2013); PMI (2014)

14

Short stage duration

The project has been structured to ensure stages are short

Bendavid and Golany (2009), Cooke-Davies (2002), de Miranda Mota and de Almeida (2012), Jones (2006), Standish Group (2013), Verner and Abdullah (2012), Wu et al. (2009)

15

Effective benefits management process

Project benefits are defined and a process exists to ensure they can be managed

Letavec (2014), Kerzner (2015), PMI (2014)

16

Integrated change and project management

Project and change management coexist with integrated plans and defined dependencies

Ash (2007), Hornstein (2015), Hughes et al. (2015), Leyland et al. (2009), Parker et al. (2013), Jarocki (2014)

17

Established post mortem process

A Post mortem process is setup and an integral component of the lifecycle

Castejón-Limas et al. (2011), de Wit (1988), Ewusi-Mensah and Przasnyski (1995), Hughes et al. (2015), Kerzner (2013), Verner et al. (2008)

3.1 Engaged and committed sponsorship

Effective and supportive sponsorfully engaged and committed to the project. This factor relates to the role of the project sponsor and their contribution to the success of the project. Engaged and committed sponsorship is a key contributor to success and it is vital that organisations appoint an appropriate senior manager able to drive the project forward. A project that does not have the full support of the executive sponsor or where a sponsor is shown to be ineffective or lacking in the role, is a significant risk to successful outcomes (El Emam and Koru 2008; Keil et al. 1998; Lemon et al. 2002; Schmidt et al. 2001). Studies have highlighted that leadership and top management support are critical to the success and failure of projects (Christianson and Walker 2004; Gray 2001; Nixon et al. 2012; Sumner et al. 2006; Young 2005). The contribution of top management support and the importance of selecting a suitable project sponsor cannot be underestimated in the context of its impact on successful project outcomes. The role of the project sponsor and their degree of commitment and effectiveness, has been cited as the top predictor of project success in industry based studies (Prosci 2012; Standish Group 2013) and is reinforced in the academic literature (Kearns 2007; Patton and Shechet 2007).

3.2 User involvement throughout the project

Users included as key stakeholders early in the project lifecycle and throughout the project. User involvement at an early stage in the project and throughout the lifecycle, is seen as a fundamental tenant of success. Failing to engender the required process for the ongoing communication with users throughout the lifecycle of a project, has been a key failure factor within many studies (Barker and Frolick 2003; Gauld 2007; Keil et al. 1998; Pan et al. 2008; Scott and Vessey 2000; Yeo 2002). Project success is influenced by effective communication with users throughout the project lifecycle underpinned by an effective stakeholder identification and analysis exercise at project start (Dan et al. 1998; Niekerk and Steyn 2011; Poon et al. 2011; Procaccino et al. 2005).

3.3 Use of skilled resources

The project team is formed around a set of people that have the required skills and experience. Successful projects require access to experienced staff with the appropriate technical and managerial skills at each stage of the project. Successful projects require dedicated skilled and experienced resources to fulfil the many and varied roles required to deliver the project. Project teams need to be structured with staff possessing the relevant skills capable of delivering to plan (Procaccino et al. 2005; Sumner and Molka-Danielsen 2010) and the necessary experience to maintain the momentum of delivery throughout the project lifecycle.

3.4 Skills experience and style of project manager

The appointed project manager has the required blend of skills, experience and style to manage the project effectively. This factor relates to the appointment of an experienced and qualified project manager who is able to manage the project taking into account the culture of the organisation and experience of stakeholders. Projects can suffer from significant complexity in the political and technical context (de Miranda Mota and de Almeida 2012). Studies have highlighted the links between project management competency and the success of the project (Haggerty 2000; Mir and Pinnington 2014). The modern project manager needs the right blend of technical experience, leadership style, people skills and political abilities to drive projects forward (Hyvari 2006; Muriithi and Crawford 2003; Turner and Müller 2005). Projects require intelligent leadership (Christianson and Walker 2004) and a balancing of focus on the technical deliverables with the people related factors (Atkinson 1999; Belout and Gauvreau 2004; Marnewick 2012).

3.5 Management of scope

Project scope is formally managed as a key project process. The management of project scope is a fundamental product of successful project management and project delivery. Projects are subject to changes to requirements and as the project progresses through its various phases the scope of the project must be managed within a structured change environment. Projects have failed due to poor scope management with changes to requirements being poorly managed and not controlled effectively (El Emam and Koru 2008; Keil et al. 1998; Schmidt et al. 2001). Changes to scope are a natural consequence of the project lifecycle, especially on large projects where the project duration may be measured in years not months. However, if this process is poorly managed and scope is allowed to increase and drift, successful outcomes are unlikely. Scope management is defined as a key knowledge area within the PMBoK® and is positioned as being a core component of project success (PMI 2014). The literature supports the link between project success, the formal management of requirements and project scope (Dekkers and Forselius 2007; Parsons-Hann and Liu 2005; Tamai and Kamata 2009).

3.6 Project audit process in place

Organisation has a formal project audit function in place. This factor relates to organisations accepting the benefits of early and mid-cycle project audit ensuring projects are assessed at key stages. Projects can suffer where organisations do not have effective processes in place to audit quality and progress against plan (Jones 2006; Kerzner 2013; Verner et al. 2008). Project health checks and audits can give the executive valuable information on project status based on an independent assessment of its viability, performance against baseline, risk and potential benefits realisation (PMI 2014). Many organisations, in particular public sector organisations, attempt to manage the risk of failure by instigating audits at the end of each stage. These audits are seen as gateways to progression to the next stage and depending on project size, are mandatory for UK Government projects. However, large projects may have long lead-times where timescales between stages may be many months or in some cases—years. Successful outcomes are better served by ensuring project audits and regular assessments of progress are integrated into the project methodology and enforced by the executive (Hughes et al. 2015; Kerzner 2013).

3.7 Use of a project management methodology

Projects managed in accordance with a defined methodology. Organisations can better assure success where projects are structured around a formal methodology where the project organisation, deliverables and accountabilities are all clearly defined. Successful outcomes are influenced by the adoption of project management practices as part of an overall methodology. However, this practice can only provide the necessary conditions for success and cannot be a guarantee of success (Lepmets 2010; Poon et al. 2011). Successful project managers need to apply methodology intelligently ensuring they strike the right balance between rigor and process with that of imagination and pragmatism to suit the context of the organisation (Tiwana and McLean 2003). Success can also be influenced by the selection of an appropriate methodology that fits the organisations cultural and practical requirements (Papke-Shields et al. 2010).

3.8 Clear business case

The project has a clear and defined business case. This factor highlights the criticality of developing a business case that sets out the justification, timescales, benefits to the organisation and costs of the project. The project business case sets out the required information to assess whether the project is or remains viable and is deemed to be a worthwhile investment for the organisation (OGC Group 2013; PMI 2014). When a project doesn’t have a viable business case or where the justification for the project has changed, the project is unlikely to deliver its defined benefits (Kerzner 2015; Pan et al. 2008). Successful outcomes are influenced by the quality and maintenance of the business case and inherent benefits to the organisation.

3.9 Resistance management process

The processes required to manage user resistance are an integral component of the project. This factor relates to organisations understanding that resistance to change can be a significant factor that can negatively affect the progress of projects. Organisations that understand the key importance of managing user resistance have established processes and procedures in place to deal with these sorts of issues as they arise and to plan for resistance from the onset (Prosci 2012). Studies have highlighted the significant problems faced by organisations when projects fail to manage user resistance issues effectively (Beynon-Davies 1995; Brown and Jones 1998; Fitzgerald and Russo 2005; Gauld 2007; McGrath 2002). It is generally accepted within practice and also in the literature, that organisations need to take steps to incorporate user resistance strategies early in the project life cycle (Bartis and Mitev 2008; Klaus and Blanton 2010). Failing to tackle these issues carries risk throughout the project thereby, increasing the chance of failure (Prosci 2012). Anxiety and fear of the unknown are powerful emotions both requiring a deeper understanding to get to the root of any resistance. Projects will increase the chances of success if effort is made to analyse the source and contextual aspects of resistance, engendering an understanding of cultural issues and the history of change within the organisation (Hiatt and Creasey 2012). Organisations need to develop effective processes to manage resistance as part of an overall strategic view of change management. This is crucial to the emergent and dynamic nature of modern systems implementation (Dwivedi et al. 2015).

3.10 Organisation project maturity

The organisation has a project oriented culture and a record of project delivery. This factor relates to the organisation adopting a project focussed culture and infrastructure aligned with delivering projects to a defined business case. Organisations that have established a capability that understands project structures, terminology, working practices and methods are more likely to react positively to new change initiatives (Hiatt and Creasey 2012). An organisation that exhibits a good level of project maturity is likely to possess an existing set of processes, tools and procedures, project templates governance structure and established lessons learned process. Achieving project maturity takes time and requires commitment at all levels of the organisation with the pragmatic implementation of appropriate levels of project management and planning (Kerzner 2015; Lambrechts et al. 2011). Establishing appropriate internal cross-functional organisational structures and the alignment with a project management delivery structure can have important implications for project success (Lechler and Dvir 2010).

3.11 Formalised role definitions

The project has clearly set out the required individual role definitions and responsibilities. This factor relates to the organisation formally defining the various roles for the project ensuring that all responsibilities are clear and unambiguous. Projects may be structured around dispersed teams spread across separate geographical locations and time zones, emphasising the criticality of formalising key project roles. The negative consequences of ill-defined roles and responsibilities can be a significant risk to the project, where initiatives have suffered from significant communication issues, misunderstanding of requirements and unclear objectives (Avison and Wilson 2002; Philip et al. 2009). Each of the key project roles together with their responsibilities and communication paths are clearly set out in the guidance within PRINCE2® and PMBoK®. Projects are better aligned with success where staff are clear about their own individual roles and responsibilities. Clarity of roles and responsibilities is critical in the early stages of a project when teams are formed and ambiguity may exist over specific boundaries of responsibilities (Kerzner 2013).

3.12 Tools and infrastructure

The project has the required tools and infrastructure. This factor relates to the project having access to the required tools and infrastructure and the allocated budget to procure all necessary resources. Studies have highlighted the criticality of project managers utilising planning and budget management tools to be able to manage their projects effectively (Raymond and Bergeron 2008). Organisationally, projects can be complex, requiring disparate multi-disciplined teams of staff. Project managers need access to a core set of standard tools to enable them to manage the project effectively (Milosevic and Patanakul 2005). Organisations are increasingly requiring key data on project progress in the form of metrics and Key Performance Indicators (KPI) to ensure the project is on track to achieve success. A Project Management Information System (PMIS) can be a key component in working toward project success, mitigating problems with project communication facilitating the flow of critical status data at all levels of the project (Kerzner 2015).

3.13 Formal risk management

The project has a formal process in place to manage risk. This factor relates to the organisation having an established process to assess and manage threats to the project. Risk is defined as the probability and potential consequence of not achieving a specific project outcome or deliverable, normally expressed as a threat to the project (OGC 2013; PMI 2014). As such risk management is a key element of the practitioners responsibility and requires constant management throughout the lifecycle of the project (de Bakker et al. 2010). Cooke-Davies (2002) highlighted a number of risk related practices that were linked to success, namely: adequacy of risk management education within the organisation, processes for risk ownership, maintenance of a visible risk register and management plan. These specific practices together with the formal assessment and management of risk within the organisation, are key to mitigating the potential threats to successful project outcomes.

3.14 Short stage duration

The project has been structured to ensure stages are of short duration. This factor emphasises the potential impact on success where the project is structured around short duration stages to ensure adequate control is maintained throughout the lifecycle. Many organisations have experienced the extensive problems resulting from excess complexity and have drifted between long drawn out stages with distant milestones supported by a culture of non-delivery (de Miranda Mota and de Almeida 2012). Long stages are often associated with large projects that have been shown to have a significantly reduced chance of success than smaller and less complex projects, highlighting the inevitability of failure at some level (Standish Group 2013; Verner and Abdullah 2012). Studies have proposed that organisations should perhaps be managing, planning and assessing the viability of large and strategic projects in a different way (Bendavid and Golany 2009; Jones 2006; Wu et al. 2009). Breaking up large projects into smaller more manageable projects each with manageable short stage durations needs to be a key component of an effective strategy to deliver successful outcomes (Cooke-Davies 2002).

3.15 Effective benefits management process

Project benefits are defined and a process exists to ensure they can be managed. This factor emphasises the criticality of defining project benefits and establishing a process to formalise benefits realisation. Benefits in the project context are the measured outcomes of a project that are the perceived advantages, values and improvements to the organisation that can be directly linked with the project deliverables (Letavec 2014). Benefits need to be identified, documented and managed through to delivery as part of the process of benefits realisation (PMI 2014). Some benefits cannot be measured until many months after project delivery. Furthermore benefits may not be fully realised until other components or associated projects are delivered perhaps as part of a programme of work. Benefits may change over the lifecycle of a project especially on long lead-time or large and complex projects. Projects can increase the chances of successful outcomes by implementing an effective benefits management processes that fully supports the realisation of benefits to the organisation (Kerzner 2015).

3.16 Integrated change and project management

Project and change management coexists with integrated plans and defined dependencies. This factor is associated with the project executive visibly supporting the integration of project and change management to ensure full benefits of both disciplines are realised. Historically, traditional project management has failed to recognise many of the people related aspects, instead concentrating on the tangible, technical deliverables (Leyland et al. 2009; Hughes et al. 2015). However, studies have highlighted the importance of ensuring these two disciplines are coordinated and integrated within an overall methodology and the reality that in practice, change and project management are inseparable (Ash 2007; Hornstein 2015; Parker et al. 2013). Success relies on the establishment of a culture that moves away from a silo, competing and non-cooperating practice to a more collaborative model (Hornstein 2015). Moving toward a more integrated methodology, with unified plans, co-located organisation and clear management structure, gives the best chance of success (PMI 2014; Prosci 2012). The required cultural shift required for organisations to benefit from integrated change and project management has the potential to deliver more consistent and successful outcomes (Jarocki 2014).

3.17 Established post mortem process

A Post mortem process is established as an integral component of the lifecycle. This factor relates to the organisation establishing a formal post mortem and project health check structure and process with the necessary resources in place. There is often a tendency for organisations to progress to the next project without learning the lessons from existing projects as pressure from senior management moves the focus to the new initiative (Hughes et al. 2015). Studies have highlighted as many as 81% of organisations generally do not conduct post mortem reviews and for those organisations that do, many seem to restrict this practice to successful projects only (Ewusi-Mensah and Przasnyski 1995; Verner et al. 2008). It is clear that all organisations, large or small can benefit from learning the lessons from previous projects even when the project is not a success (Kerzner 2013). This requires the consistent collecting and recording of key data and lessons learned (Castejón-Limas et al. 2011). Embedding this activity into a project methodology can ensure that organisations treat post-mortems as an accepted part of the process and senior management can monitor the outputs. The guidance within PRINCE2® and PMBoK® highlights the importance of post mortem based activities for realising success on future projects. Identifying what went wrong and applying the lessons learned on subsequent projects is key to maximising the chances of project success (de Wit 1988).

4 Research methodology: ISM process

ISM is a mathematically derived methodology that can represent a complex problem via a systematic process based on the structural modelling of interconnected matrices (Sage 1977, Warfield 1974). ISM enables the creation of models that represent interdependencies between a set of factors highlighting potential influences they may have on each other (Agarwal et al. 2007; Cherrafi et al. 2017; Gopal and Thakkar 2016; Haleem et al. 2012; Kumar et al. 2016; Purohit et al. 2016). The ISM process requires a set of participants—experts in the subject matter, to provide a consensus view on the relationships between a set of factors via structured debate (Agarwal et al. 2007; Janes 1988; Ravi and Shankar 2005). Researchers have utilised expert participants in previous studies in the application of Delphi, IRP and Decision Making Trial and Evaluation Laboratory (DEMATEL), to provide judgement and contextualised perspective on factor interrelationships (Haleem et al. 2012; Schmidt et al. 2001; Tzeng and Huang 2012). These initial factor interdependencies are subsequently processed via the ISM methodology to develop the requisite interrelationships between the factors for each ISM step. This process is extended at each stage to formally identify the dependent links between each of the factors.

Although not a formal element in the ISM process, many studies develop an additional step to derive the Matrics d’Impacts Croises-Multiplication Applique an Classment (MICMAC) (translated to Cross-Impact Matrix Multiplication Applied to Classification) analysis (Duperrin and Godet 1973) after the canonical form step. This step is used to visually represent the driving and dependence power of the variables via a structured quadrant separated matrix (Sharma and Gupta 1995; Mandal and Deshmukh 1994). The MICMAC step is included in this study. The ISM process is presented in Fig. 1.
Fig. 1

ISM process (

adapted from Agarwal et al. 2007)

The ISM process requires a set of expert participants to provide a consensus view on the relationships between a set of variables (Agarwal et al. 2007; Janes 1988; Ravi and Shankar 2005). The review of the selected IS success factors entailed the discussion and analysis of nine expert participants. Each of the experts are IS practitioners working within a number of different sectors: NHS, finance, public sector, consultancy, and Ministry of Defence, undertaking a variety of roles within their respective organisations including: project and change management, business analysis and systems development. The participants were specifically selected to offer their practitioner based perspective and experience on the interdependencies between the success factors in compliance with the ISM process. Data was collected in a semi-structured interview format with the researcher leading the experts through the set of specific pre-prepared questions relating to the potential interdependencies between each of the factors. Participants were asked to interpret the extent of the relationship between each of factors in accordance with the ISM process. The results of this step in the ISM method are detailed in the next section. The consensus view on the extent and type of the relationship was discussed and recorded. The summarised data forms the basis of the initial Structured Self Interaction Matrix as outlined in Table 2.
Table 2

Structured Self Interaction Matrix (SSIM)

5 ISM results

The selected factors listed in Table 1 are processed in alignment with the ISM methodology. The following steps present the ISM process in detail, identifying the key activities and outputs at each stage leading to the final digraph.

5.1 Structured Self Interaction Matrix (SSIM)

The expert participants were tasked with identifying all pair-wise relationships between the factors. This process entails the experts ascertaining whether one factor has influence over another and how the same factor may be influenced by other factors in the matrix. The SSIM matrix is set out in Table 2. The presented SSIM data outlines the relationships between the factors in terms of i (rows) and j (columns) and their respective relations. A simple notation using the symbols: V, A, X, O is used to denote each of the separate relationships.
  • V: variable i will have an influence on variable j;

  • A: variable i will be influenced by variable j;

  • X: variable i and variable j will be influenced by each other;

  • O: variables i and j are not related and no influence exists.

The data within the SSIM (as shown in Table 2) is the output of the data gathering exercise with the expert participants. The matrix is populated using the V, A, X, O notation as described above. The shaded section in Table 2 signifies the duplicate (j, i) references within the matrix and are ignored for this exercise.

5.2 Initial Reachability Matrix (IRM) and Final Reachability Matrix (FRM)

The next step in the ISM process is the development of the initial and final reachability matrices. The SSIM notation is converted to a binary format structured to align with the following rules:
  • if the (i, j) cell entry in the SSIM is V, then the equivalent (i, j) entry in the IRM becomes: 1 and the (j, i) cell entry becomes: 0;

  • if the (i, j) cell entry in the SSIM is A, then the equivalent (i, j) entry in the IRM becomes: 0 and the (j, i) cell entry becomes 1;

  • if the (i, j) cell entry in the SSIM is X, then the equivalent (i, j) entry in the IRM becomes: 1 and the (j, i) cell entry also becomes 1;

  • if the (i, j) cell entry in the SSIM is O, then the equivalent (i, j) entry in the IRM becomes: 0 and the (j, i) cell entry also becomes 0;

Table 3 highlights the completed IRM where the data in the SSIM has been converted to binary format via the rules outlined above.
Table 3

Initial Reachability Matrix (IRM)

(i)

Elements (j)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

1

1

1

0

0

1

0

1

1

1

0

1

1

1

0

1

1

0

2

0

1

0

0

1

0

0

0

1

0

0

0

0

0

0

1

0

3

0

1

1

1

1

1

1

1

1

1

1

1

1

0

1

1

1

4

1

1

1

1

1

1

1

1

1

0

1

1

1

1

1

1

1

5

0

1

0

0

1

0

0

1

1

0

0

1

0

0

1

0

0

6

1

0

1

1

0

1

1

1

0

1

1

1

1

0

1

1

1

7

0

1

1

1

1

0

1

1

1

1

1

1

1

1

1

1

1

8

1

1

0

0

1

0

0

1

0

0

0

0

0

0

1

1

0

9

1

0

0

0

0

0

0

0

1

0

0

0

1

0

0

0

0

10

0

0

0

1

1

1

1

1

1

1

0

1

0

1

1

1

1

11

0

1

0

0

0

0

0

0

1

1

1

0

0

0

0

1

0

12

0

0

0

1

0

0

0

0

0

0

0

1

1

0

0

1

1

13

0

0

0

0

0

0

0

1

1

1

0

0

1

0

1

1

1

14

0

1

0

0

0

0

0

0

0

0

0

0

0

1

0

0

0

15

0

0

0

0

1

0

0

1

0

0

0

0

0

0

1

1

0

16

0

0

0

0

1

0

1

1

1

0

1

1

1

0

1

1

1

17

0

0

0

0

0

0

0

0

0

0

0

0

1

0

0

0

1

Table 4 applies transitivity to the IRM. Transitivity is bolded using the notation 1*. Transitivity can be described in the context of:
Table 4

Final Reachability Matrix (FRM)

(i)

Elements (j)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

1

1

1

1*

1*

1

0

1

1

1

1*

1

1

1

1*

1

1

1*

2

1*

1

0

0

1

0

1*

1*

1

0

1*

1*

1*

0

1*

1

1*

3

1*

1

1

1

1

1

1

1

1

1

1

1

1

1*

1

1

1

4

1

1

1

1

1

1

1

1

1

1*

1

1

1

1

1

1

1

5

1*

1

0

1*

1

0

0

1

1

0

0

1

1*

0

1

1*

1*

6

1

1*

1

1

1*

1

1

1

1*

1

1

1

1

1*

1

1

1

7

1*

1

1

1

1

1*

1

1

1

1

1

1

1

1

1

1

1

8

1

1

0

0

1

0

1*

1

1*

0

1*

1*

1*

0

1

1

1*

9

1

1*

0

0

1*

0

1*

1*

1

1*

1*

1*

1

0

1*

1*

1*

10

1*

1*

1*

1

1

1

1

1

1

1

1*

1

1*

1

1

1

1

11

1*

1

0

1*

1*

1*

1*

1*

1

1

1

1*

1*

1*

1*

1

1*

12

1*

1*

1*

1

1*

1*

1*

1*

1*

1*

1*

1

1

1*

1*

1

1

13

1*

1*

0

1*

1*

1*

1*

1

1

1

1*

1*

1

1*

1

1

1

14

0

1

0

0

1*

0

0

0

1*

0

0

0

0

1

0

1*

0

15

1*

1*

0

0

1

0

1*

1

1*

0

1*

1*

1*

0

1

1

1*

16

1*

1*

1*

1*

1

0

1

1

1

1*

1

1

1

1*

1

1

1

17

0

0

0

0

0

0

0

1*

1*

1*

0

0

1

0

1*

1*

1

If A is connected to B (\( A \to B \)) and B is connected to C (\( B \to C \)) a transitive relationship exists between A and C (\( A \to C \)).

The process to develop the Final Reachability Matrix (FRM) from the IRM to include transitivity is set out in (1):

∀i ∀j ∀k, if ∃ k such that k ≠ i and k ≠ j
$$ \left( {{\text{M}}\left[ {{\text{i}},{\text{ k}}} \right] = 1} \right) \wedge \left( {{\text{M}}\left[ {{\text{k}},{\text{ j}}} \right] = 1} \right) \wedge \left( {{\text{M}}\left[ {{\text{i}},{\text{ j}}} \right] = 0} \right){\text{ then M}}\left[ {{\text{i}},{\text{ j}}} \right] = 1^* $$
(1)
  • M is the IRM.

  • i, j represents the rows and columns respectively.

  • k represents the (i, j) cell reference in the transitivity process.

  • ∀ represents: for all instances of: i, j, k.

  • ∃ denotes a match between column instance ‘1’ and row instance ‘1’ at location k.

If all three conditions are true i.e. If (M[i, j] = 0) and (M[i, k] = 1) and (M[k, j] = 1), then we set M[i, j] = 1* to signify transitivity at this cell reference.

5.3 Partitioning of the FRM

The completed FRM must now be assessed based on the reachability and antecedent sets for each of the variables in the matrix (Warfield 1974). The reachability set R(Pi) consists of the element itself together with other elements which it may help to achieve. The antecedent set A(Pi) consists of the element itself and other elements which may help in achieving it.

Iteration I of the level partition matrix identifies the instances of a match between the reachability and intersection sets. Where a match exists; “I” is inserted against the appropriate variable. The matching elements identified in Table 5: (8) Clear business case, (9) Resistance mgt process, (15) Effective benefits mgt process, (16) Integrated change and project mgt, (17) Established post mortem process will be at the top level in the ISM diagram exhibiting high levels of dependency. This process is followed for the remaining levels, but for each iteration the instances of matches in the previous iteration are removed from the matrix.
Table 5

Level partition—iteration I

Element P(i)

Reachability set R(Pi)

Antecedent set: A(Pi)

Intersection R(Pi) and A(Pi)

Level

1

1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16

1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 15, 16

 

2

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16

 

3

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 3, 4, 6, 7, 10, 12, 16

1, 3, 4, 6, 7, 10, 12, 16

 

4

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 3, 4, 5, 6, 7, 10, 11, 12, 13, 16

1, 3, 4, 5, 6, 7, 10, 11, 12, 13, 16

 

5

1, 2, 4, 5, 8, 9, 12, 13, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16

1, 2, 4, 5, 8, 9, 12, 13, 15, 16

 

6

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

3, 4, 6, 7, 10, 11, 12, 13

3, 4, 6, 7, 10, 11, 12, 13

 

7

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16

1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16

 

8

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

I

9

1, 2, 5, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 2, 5, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

I

10

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 3, 4, 6, 7, 9, 10, 11, 12, 13, 16, 17

1, 3, 4, 6, 7, 9, 10, 11, 12, 13, 16, 17

 

11

1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16

1, 2, 4, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16

 

12

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16

 

13

1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

 

14

2, 5, 9, 14, 16

1, 3, 4, 6, 7, 10, 11, 12, 13, 14, 16

14, 16

 

15

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

I

16

1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

I

17

8, 9, 10, 13, 15, 16, 17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

8, 9, 10, 13, 15, 16, 17

I

Table 6 outlines iteration II for matches between the reachability and intersection sets for the next level with the previous level matching factors removed. The matching elements at this level are: (2) User involvement throughout the project and (5) Management of scope. These factors will be positioned at the 2nd level of the ISM model.
Table 6

Level partition—iteration II

Element P(i)

Reachability set R(Pi)

Antecedent set: A(Pi)

Intersection R(Pi) and A(Pi)

Level

1

1, 2, 3, 4, 5, 7, 10, 11, 12, 13, 14

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13

1, 2, 3, 4, 5, 7, 10, 11, 12, 13

 

2

1, 2, 5, 7, 11, 12, 13

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 2, 5, 7, 11, 12, 13

II

3

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 12

1, 3, 4, 6, 7, 10, 12

 

4

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 5, 6, 7, 10, 11, 12, 13

1, 3, 4, 5, 6, 7, 10, 11, 12, 13

 

5

1, 2, 4, 5, 12, 13

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 2, 4, 5, 12, 13

II

6

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14

3, 4, 6, 7, 10, 11, 12, 13

3, 4, 6, 7, 10, 11, 12, 13

 

7

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 2, 3, 4, 6, 7, 10, 11, 12, 13

1, 2, 3, 4, 6, 7, 10, 11, 12, 13

 

10

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

 

11

1, 2, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 2, 3, 4, 6, 7, 10, 11, 12, 13

1, 2, 4, 6, 7, 10, 11, 12, 13

 

12

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13

 

13

1, 2, 4, 5, 6, 7, 10, 11, 12, 13, 14

1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13

1, 2, 4, 5, 6, 7, 10, 11, 12, 13

 

14

2, 5, 14

1, 3, 4, 6, 7, 10, 11, 12, 13, 14

14

 
Iteration III is outlined in Table 7. Matches are found for the factor: (14) Short stage duration. This element will form the third level in the ISM model.
Table 7

Level partition—iteration III

Element P(i)

Reachability set R(Pi)

Antecedent set: A(Pi)

Intersection R(Pi) and A(Pi)

Level

1

1, 3, 4, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 7, 10, 11, 12, 13

 

3

1, 3, 4, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 12

1, 3, 4, 6, 7, 10, 12

 

4

1, 3, 4, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

 

6

1, 3, 4, 6, 7, 10, 11, 12, 13, 14

3, 4, 6, 7, 10, 11, 12, 13

3, 4, 6, 7, 10, 11, 12, 13

 

7

1, 3, 4, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

 

10

1, 3, 4, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

 

11

1, 4, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 4, 6, 7, 10, 11, 12, 13

 

12

1, 3, 4, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

 

13

1, 4, 6, 7, 10, 11, 12, 13, 14

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 4, 6, 7, 10, 11, 12, 13

 

14

14

1, 3, 4, 6, 7, 10, 11, 12, 13, 14

14

III

The next iteration of the level partition process is shown in Table 8. Factors (1) Engaged and committed sponsorship, (4) Skills, experience and style of PM, (7) Use of project mgt methodology, (10) Organisation project maturity, (11) Formalised role definitions, (12) Tools and infrastructure, (13) Formal risk mgt, are the factors at this level and will be positioned at level four in the ISM model.
Table 8

Level partition—iteration IV

Element P(i)

Reachability set R(Pi)

Antecedent set: A(Pi)

Intersection R(Pi) and A(Pi)

Level

1

1, 3, 4, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 7, 10, 11, 12, 13

IV

3

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 12

1, 3, 4, 6, 7, 10, 12

 

4

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

IV

6

1, 3, 4, 6, 7, 10, 11, 12, 13

3, 4, 6, 7, 10, 11, 12, 13

3, 4, 6, 7, 10, 11, 12, 13

 

7

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

IV

10

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

IV

11

1, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 4, 6, 7, 10, 11, 12, 13

IV

12

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

IV

13

1, 4, 6, 7, 10, 11, 12, 13

1, 3, 4, 6, 7, 10, 11, 12, 13

1, 4, 6, 7, 10, 11, 12, 13

IV

Table 9 presents the iteration at level V in the ISM process. This iteration identifies two matches at this level: (3) Use of skilled resources, (6) Project audit process in place. These factors will be positioned at the lowest level of the digraph as they exhibit the highest levels of driving power and therefore, influence on other factors in the model.
Table 9

Level partition—iteration V

Element P(i)

Reachability set R(Pi)

Antecedent set: A(Pi)

Intersection R(Pi) and A(Pi)

Level

3

3, 6

3, 6

3, 6

V

6

3, 6

3, 6

3, 6

V

5.4 Development of the canonical form matrix

Table 10 shows the canonical form of the matrix. The canonical form is a restructured version of the FRM where the factors are grouped to align with the level partition stage. The Level column in the table highlights the implicit ordering that will be represented in the final ISM diagram denoting the dependent and driving attributes of each of the factors.
Table 10

Canonical form of FRM

Elements

8

9

15

16

17

2

5

14

1

4

7

10

11

12

13

3

6

Level

Reachability set: R(Pi)

8

1

1

1

1

1

1

1

0

1

0

1

0

1

1

1

0

0

1

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

9

1

1

1

1

1

1

1

0

1

0

1

1

1

1

1

0

0

1

1, 2, 5, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

15

1

1

1

1

1

1

1

0

1

0

1

0

1

1

1

0

0

1

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

16

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

1

1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

17

1

1

1

1

1

0

0

0

0

0

0

1

0

0

1

0

0

1

8, 9, 10, 13, 15, 16, 17

2

1

1

1

1

1

1

1

0

1

0

1

0

1

1

1

0

0

2

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

5

1

1

1

1

1

1

1

0

1

1

0

0

0

1

1

0

0

2

1, 2, 4, 5, 8, 9, 12, 13, 15, 16, 17

14

0

1

0

1

0

1

1

1

0

0

0

0

0

0

0

0

0

3

2, 5, 9, 14, 16

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

4

1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

4

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

4

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

7

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

4

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

10

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

4

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

11

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

1

4

1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

12

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

4

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

13

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

1

4

1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

3

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

5

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

6

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

5

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

5.5 Driving and dependence power: (MICMAC) analysis

Table 11 presents the Canonical form from the previous step with the addition of the driving and dependence power ratings. The driving and dependence figures are summed across each axis to provide the totals. These totals represent the factors that exhibit the greatest influence and dependence on connected factors. The ratings are scored 1–17 to match the number of factors. A driving power of 16 or 17, demonstrates a factor that has significant influence on other interconnected factors. Whereas a factor with a dependence power of the same level (16 or 17), denotes a factor that can be significantly influenced by connected factors in the model.
Table 11

Driving and dependence power applied to the canonical form matrix

Elements

8

9

15

16

17

2

5

14

1

4

7

10

11

12

13

3

6

Driving power

Reachability set: R(Pi)

8

1

1

1

1

1

1

1

0

1

0

1

0

1

1

1

0

0

12

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

9

1

1

1

1

1

1

1

0

1

0

1

1

1

1

1

0

0

13

1, 2, 5, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17

15

1

1

1

1

1

1

1

0

1

0

1

0

1

1

1

0

0

12

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

16

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

16

1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

17

1

1

1

1

1

0

0

0

0

0

0

1

0

0

1

0

0

7

8, 9, 10, 13, 15, 16, 17

2

1

1

1

1

1

1

1

0

1

0

1

0

1

1

1

0

0

12

1, 2, 5, 7, 8, 9, 11, 12, 13, 15, 16, 17

5

1

1

1

1

1

1

1

0

1

1

0

0

0

1

1

0

0

11

1, 2, 4, 5, 8, 9, 12, 13, 15, 16, 17

14

0

1

0

1

0

1

1

1

0

0

0

0

0

0

0

0

0

5

2, 5, 9, 14, 16

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

16

1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

4

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

7

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

10

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

11

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

1

16

1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

12

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

13

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

0

1

16

1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

3

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

6

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

17

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

Dependence power

16

17

16

17

16

16

16

11

15

11

14

12

14

15

16

8

8

  

MICMAC analysis is used to visually represent the driving power and dependence power of the factors and multiplication properties of matrices (Sharma and Gupta 1995; Mandal and Deshmukh 1994). The MICMAC diagram is useful for highlighting the key enablers and dependent factors that drive the system in terms of the IS SFs influence.

The MICMAC diagram presented in Fig. 2 highlights the driving and dependence attributes of the factors and classifies the four quadrants as follows:
Fig. 2

MICMAC diagram

  • Autonomous—identifies factors that have weak driving power and weak dependence and therefore, low impact. This means they are relatively disconnected from the system having few links to other factors.

  • Linkage—identifies factors that have strong dependency power and strong driving power. As such the factors within this quadrant are classed as unstable as any action on these factors will have a corresponding effect on other variables and feedback on themselves.

  • Dependent—identifies factors that have strong dependence power but weak driving power.

  • Independent—identifies factors that have weak dependency power but strong driving power and are often termed—key factors.

The MICMAC analysis in Fig. 2 highlights that the majority of factors are positioned within the Linkage quadrant. This highlights the unstable nature of factors in this quadrant. These factors exhibit strong dependency power and strong driving power. The net effect of these attributes is that any action on these factors will have a corresponding effect on other factors and feedback on themselves.

The factors: (3) Use of skilled resources and (6) Project audit process in place are located within the Independent quadrant. These factors generally have weak dependency power but strong driving power demonstrating high levels of influence on connected factors at higher levels in the digraph. Two factors are located within the Dependent quadrant—(14) Short stage duration and (17) Established post mortem process. Dependent factors have strong dependence power but relatively weak driving power. No factors are located within the Autonomous area of the MICMAC diagram.

Closer inspection of the Linkage quadrant highlights three main areas of clustering within this sector. The factors: (4) Skills, experience and style of PM, and (10) Organisation project maturity, are located toward the top left of the quadrant. These two factors exhibit maximum levels of driving power, but in comparison to the remaining factors in this quadrant, demonstrate weaker levels of dependence power. The second area of clustering within this quadrant includes the following factors: (7) Use of project mgt methodology, (12) Tools and infrastructure, (11) Formalised role definitions, (1) Engaged and committed sponsorship, (13) Formal risk mgt, (16) Integrated change and project management. These factors are located high within the quadrant with near maximum level of driving power but also exhibiting relatively high levels of dependence power. The third cluster of factors within this quadrant includes: (8) Clear business case, (15) Effective benefits mgt process, (2) User involvement throughout the project, (5) Management of scope and (9) Resistance management process. These factors exhibit lower levels of driving power whilst demonstrating relatively high levels of dependence power.

5.6 ISM model/digraph

The development of the ISM process model or digraph is the final step in the ISM process as shown in Fig. 3 and displays the visual representation of the factors and their associations with each other.
Fig. 3

ISM Model/Digraph

The digraph is developed from the Canonical form in Tables 10 and 11. The top level of the ISM diagram identifies the five factors that were identified in the level I partition processing, namely: (8) Clear business objectives, (9) Resistance management process, (15) Effective benefits management process, (16) Integrated change and project management, (17) Established post mortem process. These factors have maximum levels of dependence power but varying levels of driving power therefore, are significantly reliant on the lower level connections in the model. The next subsequent levels depict: (2) User involvement throughout the process, (5) Optimisation of scope and (14) Short stage duration respectively. A large number of factors are directly connected to (14) Short stage duration. Level four in the digraph identifies seven factors namely: (1) Engaged and committed sponsorship, (4) Skills, experience and style of PM, (7) Use of project mgt methodology, (10) Organisation project maturity, (11) Formalised role definitions, (12) Tools and infrastructure, (13) Formal risk mgt. The final layer in the model depicts (3) Use of skilled resources and (6) Project audit process in place. These lower level factors have strong driving power and therefore, influence over other connected factors in the model.

6 Discussion of results

The MICMAC and digraph analysis highlights diagrammatically the strong levels of interdependency between the factors and potential influence certain factors have on others in the model. The clustering of factors in the Linkage quadrant highlights the instability of the relationships in that any action on these factors has a corresponding effect on other factors and feedback on themselves. The two factors at the lowest level of the digraph and MICMAC: (3) Use of skilled resources and (6) Project audit process in place are identified in the model as exhibiting the maximum levels of driving power. The net effect of these factor characteristics are that in instances where a project is staffed with skilled, experienced, capable resource and where the organisation has an established project health check and audit function, these factors can drive success. Previous studies have emphasised the links between IS project success and the performance of these key factors (Creasy and Anantatmula 2013; Esa and Samad 2014; Kerzner 2015; Mir and Pinnington 2014; Procaccino et al. 2005; Turner and Müller 2005). This study extends these findings by connecting the criticality of these two separate factors and their joint influence potential within the model. Organisations would be wise to ensure these building blocks are in place to leverage the potential influence from these two factors in driving successful outcomes.

The factor: (1) Engaged and committed sponsorship is cited as a key influencer of success in many aspects of the literature (Prosci 2012; Standish Group 2013; Young 2005) where studies have identified the criticality of appointing the right person within the organisation to drive the project and engage the key stakeholders. This study supports these findings, in that this factor demonstrates near maximum levels of driving power and high levels of dependency in the MICMAC and digraph analysis. This factor is also closely associated with the factors: (4) Skills, experience and style of PM, (7) Use of project mgt methodology, (10) Organisation project maturity, (11) Formalised role definitions, (12) Tools and infrastructure, (13) Formal risk mgt, highlighting the significant role these closely coupled factors have on the remaining connections within the model. The digraph illustrates that (1) Engaged and committed sponsorship is dependent on (3) Use of skilled resources and (6) Project audit process in place. This deviates somewhat from the literature in that these factors although listed as independently aligned with success within a number of studies, are not identified in the context of their interdependency. The nature of these relationships suggests that for a project to benefit from good and effective sponsorship, the organisation needs to ensure that the project has a skilled team in place and that audit processes are established to drive and assure the benefits of engaged and committed sponsorship.

The realisation that large and complex projects need to be structured and managed in a different way to influence a change in outcomes, has been the subject of much debate in the literature (Dwivedi et al. 2015; Hughes et al. 2015; Standish Group 2013). The factor (14) Short stage duration is one approach to ensuring that projects do not drift and that early warning signs are identified at each step in the lifecycle. This factor is shown in the model to be highly dependent on: (1) Engaged and committed sponsorship, (4) Skills, experience and style of PM, (7) Use of project mgt methodology, (10) Organisation project maturity, (11) Formalised role definitions, (12) Tools and infrastructure, (13) Formal risk mgt. This interdependency suggests that organisations need to put steps in place to formalise these related factors to gain maximum benefits from structuring projects around short duration stages. Success is better assured in instances where stages are kept short with agreed milestones and clear performance indicators (Cooke-Davies 2002; Shenhar et al. 2001).

The high levels of dependency power of the factors located at the top of the digraph: (8) Clear business case, (9) Resistance mgt process, (15) Effective benefits mgt process, (16) Integrated change and project mgt, (17) Established post mortem process, demonstrate how these factors can be influenced by the interconnected factors lower down in the model. Understanding that success for each of these heavily dependent factors, is reliant on many other interconnected factors, is a key consideration within organisations. The literature has cited numerous instances were projects have failed to manage these areas effectively with resulting negative consequences on project outcomes (Lemon et al. 2002; McGrath 2002; Mitev 1996). Studies have supported the correlation between user involvement and project success where resistance management is a key factor (Belout and Gauvreau 2004; Poon et al. 2011). Further studies have highlighted the criticality of an effective benefits management processes (Kerzner 2015) and the positive impact on outcomes when project and change management are integrated (Ash 2007; Hornstein 2015; Parker et al. 2013). The digraph demonstrates how these factors are directly dependent on (2) User involvement throughout the process, (5) Optimisation of scope. The literature supports formal optimisation and management of scope (Dekkers and Forselius 2007; Parsons-Hann and Liu 2005; Tamai and Kamata 2009) highlighting the criticality of these factors and contribution to positive project outcomes. The results indicate that organisations could better assure success by manage these factors closely, recognising the influence they have on factors at the top of the model.

7 Conclusions

Studies have explored the factors surrounding the success of IS projects, but in the main have failed to progress beyond developing lists of recommended SFs, omitting to analyse the relationships and potential influence between factors. This study has explored the interrelationships between IS SFs incorporating ISM as the methodology to develop and contextualise the dependent relationships. This approach has yielded further insight to the interdependencies between SFs and their contribution to successful project outcomes extending the existing research and our understanding of this topic.

The findings in this study highlight the significant interconnectivity of many SFs identifying strong relationship between the factors within the model. The results highlight the significant driving power and therefore influence that the factors: (3) Use of skilled resources and (6) Project audit process in place. These two factors underpin the success of many other factors in the model. Organisations are recommended to pay particular attention to these two factors as significant influencers of successful outcomes. The high levels of dependency power of the factors positioned at the top of the digraph: 8) Clear business case, (9) Resistance mgt process, (15) Effective benefits mgt process, (16) Integrated change and project mgt, (17) Established post mortem process, indicate the criticality of organisations closely managing the interconnected factors lower in the model to increase the potential for success.

This study is presented as a valuable contribution to the greater understanding of the components of IS project success and is positioned as a potential framework to guide academics and practitioners in the deeper understanding of this subject. To our knowledge; this study is the first to explore the structure and nature of the interdependencies between the factors surrounding IS project success using ISM. This research asserts that by adopting an ISM based approach, the novelty of the interdependencies between SFs provides a deeper understanding and application over previous research on this topic. This new insight provides valuable clarity in identifying the importance and influence of specific SFs and how these can contribute to IS project success. Many of the findings from this study provide new insight to practice within organisations as well as contributing to the wider body of literature.

7.1 Limitations of study and suggested future research

This research is limited by certain constraints of implementing the ISM method. Specifically, the method does not offer a comprehensive mechanism to support the ranking of factors within the model. Future research is recommended to develop this area to provide a richer more detailed understanding of the interrelationships, integrated with a ranking element within the method.

Notes

References

  1. Agarwal, A., & Shankar, R. (2003). On-line trust building in e-enabled supply chain. Supply Chain Management: An International Journal, 8(4), 324–334.CrossRefGoogle Scholar
  2. Agarwal, A., Shankar, R., & Tiwari, M. K. (2007). Modeling agility of supply chain. Industrial Marketing Management, 36(4), 443–457.CrossRefGoogle Scholar
  3. Ash, C. (2007). Convergence of IT project management and change management: A comparative study. In Proceedings of the European and mediterranean conference on information systems, EMCIS 2007, Valencia, Spain (pp. 1–8).Google Scholar
  4. Atkinson, R. (1999). Project management: Cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project Management, 17(6), 337–342.CrossRefGoogle Scholar
  5. Avison, D., & Wilson, D. (2002). IT failure and the collapse of One. Tel. In Proceedings of the IFIP 17th world computer congress: TC8 stream on information systems—The e-business challenge (pp. 31–46).Google Scholar
  6. Barker, T., & Frolick, M. (2003). ERP implementation failure a case study. Information systems management, Fall.Google Scholar
  7. Bartis, E., & Mitev, N. (2008). A multiple narrative approach to information systems failure: A successful system that failed. In Proceedings of the 15th European conference on information systems, San Francisco (pp. 1421–1433).Google Scholar
  8. Belassi, W., & Tukel, O. I. (1996). A new framework for determining critical success/failure factors in projects. International Journal of Project Management, 14(3), 141–151.CrossRefGoogle Scholar
  9. Belout, A., & Gauvreau, C. (2004). Factors influencing project success: The impact of human resource management. International Journal of Project Management, 22(1), 1–11.CrossRefGoogle Scholar
  10. Bendavid, I., & Golany, B. (2009). Setting gates for activities in the stochastic project scheduling problem through the cross entropy methodology. Annals of Operations Research, 172(1), 259–276.CrossRefGoogle Scholar
  11. Beynon-Davies, P. (1995). Information systems failure: The case of the London ambulance services computer aided despatch project. European Journal of Information Systems, 4(3), 171–184.CrossRefGoogle Scholar
  12. Brown, A., & Jones, M. (1998). Doomed to failure: Narratives of inevitability and conspiracy in a failed IS project. Organisation Studies, 19(1), 73–88.CrossRefGoogle Scholar
  13. Castejón-Limas, M., Ordieres-Meré, J., González-Marcos, A., & González-Castro, V. (2011). Effort estimates through project complexity. Annals of Operations Research, 186(1), 395–406.CrossRefGoogle Scholar
  14. Chander, M., Jain, S. K., & Shankar, R. (2013). Modeling of information security management parameters in Indian organisations using ISM and MICMAC approach. Journal of Modelling in Management, 8(2), 171–189.CrossRefGoogle Scholar
  15. Cherrafi, A., Elfezazi, S., Garza-Reyes, J. A., Benhida, K., & Mokhlis, A. (2017). Barriers in Green Lean implementation: A combined systematic literature review and interpretive structural modelling approach. Production Planning & Control, 28, 829–842.CrossRefGoogle Scholar
  16. Christianson, D., & Walker, D. (2004). Understanding the role of “vision” in project success. IEEE Engineering Management Review, 32(4), 57–73.CrossRefGoogle Scholar
  17. Cooke-Davies, T. (2002). The ‘real’ success factors on projects. International Journal of Project Management, 20(3), 185–190.CrossRefGoogle Scholar
  18. Creasy, T., & Anantatmula, V. S. (2013). From every direction: How personality traits and dimensions of project managers can conceptually affect project success. Project Management Journal, 44(6), 36–51.CrossRefGoogle Scholar
  19. Dan, J., Broome, A., & Joyce, W. (1998). Human barriers to project success. Computer Bulletin, 40(3), 24–25.CrossRefGoogle Scholar
  20. de Bakker, K., Boonstra, A., & Wortmann, H. (2010). Does risk management contribute to IT project success? A meta-analysis of empirical evidence. International Journal of Project Management, 28(5), 493–503.CrossRefGoogle Scholar
  21. de Miranda Mota, C. M., & de Almeida, A. T. (2012). A multicriteria decision model for assigning priority classes to activities in project management. Annals of Operations Research, 199(1), 361–372.CrossRefGoogle Scholar
  22. de Wit, A. (1988). Measurement of project success. International Journal of Project Management, 6(3), 164–170.CrossRefGoogle Scholar
  23. Dekkers, C., & Forselius, P. (2007). Increase ICT project success with concrete scope management. In EUROMICRO 2007: Proceedings of the 33rd EUROMICRO conference on software engineering and advanced applications SEAA 2007, Lübeck, Germany (pp. 385–392).Google Scholar
  24. DeLone, W. J., & McLean, E. R. (1992). Information systems success: The quest for the dependent variable. Information Systems Research, 3(1), 60–95.CrossRefGoogle Scholar
  25. Duperrin, J. C., & Godet, M. (1973). Methode de hierarchisation des elements d’un systeme. Rapport economique du CEA, 1(2), 49–51.Google Scholar
  26. Dwivedi, Y. K., Janssen, M., Slade, E. L., Rana, N. P., Weerakkody, V., Millard, J., et al. (2017). Driving innovation through big open linked data (BOLD): Exploring antecedents using interpretive structural modelling. Information Systems Frontiers, 19(2), 197–212.CrossRefGoogle Scholar
  27. Dwivedi, Y. K., Wastell, D., Laumer, S., Henriksen, H. Z., Myers, M. D., Bunker, D., et al. (2015). Research on information systems failures and successes: Status update and future directions. Information Systems Frontiers, 17(1), 143–157.CrossRefGoogle Scholar
  28. El Emam, K., & Koru, A. (2008). A replicated survey of IT software project failures. IEEE Software, 25(5), 84–90.CrossRefGoogle Scholar
  29. Esa, M., & Samad, Z. (2014). Preparing project managers to achieve project success-human related factor. International Journal Research Management Technology, 4(2), 104–110.Google Scholar
  30. Ewusi-Mensah, K., & Przasnyski, Z. (1995). Learning from abandoned information systems development projects. Journal of Information Technology, 10, 3–14.CrossRefGoogle Scholar
  31. Fitzgerald, G., & Russo, N. R. (2005). The turnaround of the London ambulance service computer-aided dispatch system (LASCAD). European Journal of Information Systems, 14(3), 244–257.CrossRefGoogle Scholar
  32. Fortune, J., & White, D. (2006). Framing of project critical success factors by systems model. International Journal of Project Management, 24(1), 53–65.CrossRefGoogle Scholar
  33. Gauld, R. (2007). Public sector information system failures: Lessons from a New Zealand hospital organisation. Government Information Quarterly, 24, 102–114.CrossRefGoogle Scholar
  34. Gopal, P. R. C., & Thakkar, J. (2016). Analysing critical success factors to implement sustainable supply chain practices in Indian automobile industry: A case study. Production Planning & Control, 27(12), 1005–1018.CrossRefGoogle Scholar
  35. Gray, R. J. (2001). Organisational climate and project success. International Journal of Project Management, 19(2), 103–109.CrossRefGoogle Scholar
  36. Haggerty, N. (2000). Understanding the link between IT project manager skills and project success research in progress. In Proceedings of the 2000 ACM SIGCPR conference on computer personnel research (pp. 192–195). ACM.Google Scholar
  37. Haleem, A., Sushil, Qadri, M. A., & Kumar, S. (2012). Analysis of critical success factors of world-class manufacturing practices: An application of interpretative structural modelling and interpretative ranking process. Production Planning & Control, 23(10–11), 722–734.CrossRefGoogle Scholar
  38. Hiatt, J. M., & Creasey, T. M. (2012). Change management: The people side of change. Loveland, CO: Prosci Inc.Google Scholar
  39. Hornstein, H. (2015). The integration of project management and organizational change management is now a necessity. International Journal of Project Management, 33(2), 291–298.CrossRefGoogle Scholar
  40. Hughes, D. L., Dwivedi, Y. K., & Rana, N. P. (2017). Mapping IS failure factors on PRINCE2® stages: An application of interpretive ranking process (IRP). Production Planning & Control, 28(9), 776–790.CrossRefGoogle Scholar
  41. Hughes, D. L., Dwivedi, Y. K., Rana, N. P., & Simintiras, A. C. (2016). Information systems project failure: Analysis of causal links using interpretive structural modelling. Production Planning & Control, 27(16), 1313–1333.CrossRefGoogle Scholar
  42. Hughes, D. L., Dwivedi, Y. K., Simintiras, A. C., & Rana, N. P. (2015). Success and failure of IS projects: A state of the art analysis and future directions. Dordrecht: Springer.Google Scholar
  43. Hyvari, I. (2006). Success of projects in different organizational conditions. Project Management Journal, 37(4), 31–42.CrossRefGoogle Scholar
  44. Janes, F. R. (1988). Interpretive structural modelling: A methodology for structuring complex issues. Transactions of the Institute of Measurement and Control, 10(3), 145–154.CrossRefGoogle Scholar
  45. Janssen, M., Rana, N. P., Slade, E. L., & Dwivedi, Y. K. (2018). Trustworthiness of digital government services: Deriving a comprehensive theory through interpretive structural modelling. Public Management Review, 20(5), 647–671.CrossRefGoogle Scholar
  46. Jarocki, T. L. (2014). One solution for project success: Project and change management in the PMBOK ® guide. Project Management Institute: Newtown Square.Google Scholar
  47. Jones, C. (2006). Social and technical reasons for software project failures. CrossTalk, 19(6), 4–9.Google Scholar
  48. Kearns, G. (2007). How the internal environment impacts information systems project success: An investigation of exploitative and explorative firms. Journal of Computer Information Systems, 38(1), 63–75.Google Scholar
  49. Keil, M., Cule, P. E., Lyytinen, K., & Schmidt, R. C. (1998). A framework for identifying software project risks. Communications of the ACM, 41(11), 76–83.CrossRefGoogle Scholar
  50. Kerzner, H. (2013). Project management. A systems approach to planning, scheduling and controlling (5th ed.). Hoboken, New Jersey: Wiley.Google Scholar
  51. Kerzner, H. (2015). Project management. 2.0 (1st ed.). Hoboken, New Jersey: Wiley.CrossRefGoogle Scholar
  52. Klaus, T., & Blanton, J. E. (2010). User resistance determinants and the psychological contract in enterprise system implementations. European Journal of Information Systems, 19(6), 625–636.CrossRefGoogle Scholar
  53. Kumar, S., Luthra, S., Govindan, K., Kumar, N., & Haleem, A. (2016). Barriers in green lean six sigma product development process: An ISM approach. Production Planning & Control, 27(7–8), 604–620.Google Scholar
  54. Lambrechts, O., Demeulemeester, E., & Herroelen, W. (2011). Time slack-based techniques for robust project scheduling subject to resource uncertainty. Annals of Operations Research, 186(1), 443–464.CrossRefGoogle Scholar
  55. Lechler, T. G., & Dvir, D. (2010). An alternative taxonomy of project management structures: Linking project management structures and project success. IEEE Transactions on Engineering Management, 57(2), 198–210.CrossRefGoogle Scholar
  56. Lemon, W. F., Liebowitz, J., Burn, J., & Hackney, R. (2002). Information systems project failure: A comparative study of two countries. Journal of Global Information Management, 10(2), 28–39.CrossRefGoogle Scholar
  57. Lepmets, M. (2010). Which process model practices support project success? Systems, software and services process improvement (pp. 119–129). Berlin: Springer.CrossRefGoogle Scholar
  58. Letavec, C. (2014). Strategic benefits realization: Optimizing value through programs, portfolios, and organisational change management. Plantation: J. Ross.Google Scholar
  59. Leyland, M., Hunter, D., & Dietrich, J. (2009). Integrating change management into clinical health information technology project practice. In World congress on privacy, security, trust and the management of e-business, 2009. CONGRESS’09 (pp. 89–99).Google Scholar
  60. Lim, M. K., Tseng, M. L., Tan, K. H., & Bui, T. D. (2017). Knowledge management in sustainable supply chain management: Improving performance through an interpretive structural modelling approach. Journal of Cleaner Production, 162, 806–816.CrossRefGoogle Scholar
  61. Mandal, A., & Deshmukh, S. G. (1994). Vendor selection using interpretive structural modelling (ISM). International Journal of Operations & Production Management, 14(6), 52–59.CrossRefGoogle Scholar
  62. Marnewick, C. (2012). A longitudinal analysis of ICT project success. In ACM international conference proceeding series, SAICSIT, SA (pp. 326–334).Google Scholar
  63. McGrath, K. (2002). The golden circle: A way of arguing and acting about technology in the London ambulance service. European Journal of Information Systems, 11(4), 251–266.CrossRefGoogle Scholar
  64. Meade, L. M., & Sarkis, J. (1999). Analyzing organisational project alternatives for agile manufacturing processes: An analytical network approach. International Journal of Production Research, 37(2), 241–261.CrossRefGoogle Scholar
  65. Milosevic, D., & Patanakul, P. (2005). Standardised project management may increase development projects success. International Journal of Project Management, 23(3), 181–192.CrossRefGoogle Scholar
  66. Mir, F., & Pinnington, A. (2014). Exploring the value of project management: Linking project management performance and project success. International Journal of Project Management, 32(2), 202–217.CrossRefGoogle Scholar
  67. Mitev, N. N. (1996). More than a failure? The computerized reservation systems at French Railways. Information Technology & People, 9(4), 8–19.CrossRefGoogle Scholar
  68. Morris, P. W., & Hough, G. (1987). The anatomy of major projects: A study of the reality of project management. Oxford: Major Projects Association.Google Scholar
  69. Muller, R., & Jugdev, K. (2012). Critical success factors in projects: Pinto, Slevin and Prescott—The elucidation of project success. International Journal of Managing Projects in Business, 5(4), 757–775.CrossRefGoogle Scholar
  70. Muriithi, N., & Crawford, L. (2003). Approaches to project management in Africa: Implications for international development projects. International Journal of Project Management, 21(5), 309–319.CrossRefGoogle Scholar
  71. Niekerk, S., & Steyn, H. (2011). Defining’ project success’ for a complex project: The case of a nuclear engineering development. Journal of Industrial Engineering, 22(1), 123–136.Google Scholar
  72. Nixon, P., Harrington, M., & Parker, D. (2012). Leadership performance is significant to project success or failure: A critical analysis. International Journal of Productivity and Performance Management, 61(2), 204–216.CrossRefGoogle Scholar
  73. OGC Group. (2013). Managing successful projects with PRINCE2. London: TSO.Google Scholar
  74. Pan, G., Hackney, R., & Pan, S. L. (2008). Information Systems implementation failure: Insights from prism. International Journal of Information Management, 28(4), 259–269.CrossRefGoogle Scholar
  75. Papke-Shields, K. E., Beise, C., & Quan, J. (2010). Do project managers practice what they preach, and does it matter to project success? International Journal of Project Management, 28(7), 650–662.CrossRefGoogle Scholar
  76. Parker, D., Charlton, J., Ribeiro, A., & Pathak, R. D. (2013). Integration of project-based management and change management: Intervention methodology. International Journal of Productivity and Performance Management, 62(5), 534–544.CrossRefGoogle Scholar
  77. Parsons-Hann, H., & Liu, K. (2005). Measuring requirements complexity to increase the probability of project success. ICEIS, 3, 434–438.Google Scholar
  78. Patton, N., & Shechet, A. (2007). Wisdom for building the project manager/project sponsor relationship: Partnership for project success. The Journal of Defense Engineering, 20(11), 4–9.Google Scholar
  79. Philip, T., Schwabe, G., & Ewusi-Mensah, K. (2009). Critical issues of offshore software development project failures. In ICIS 2009 Proceedings: Thirtieth international conference on information systems. Phoenix, AZ.Google Scholar
  80. Pinto, J. K., & Mantel, S. J. (1990). The causes of project failure. IEEE Transactions on Engineering Management, 37(4), 269–276.CrossRefGoogle Scholar
  81. Pinto, J. K., & Prescott, J. (1988). Variations in critical success factors over the stages in the project life cycle. Journal of Management, 14(1), 5–18.CrossRefGoogle Scholar
  82. Pinto, J. K., & Slevin, D. P. (1987). Critical factors in successful project implementation. IEEE Transactions on Engineering Management, 34(1), 22–27.CrossRefGoogle Scholar
  83. Pinto, J. K., & Slevin, D. P. (1988). Project success: Definitions and measurement techniques. Project Management Journal, 19(1), 67–72.Google Scholar
  84. Poon, S. K., Young, R., Irandoost, S., & Land, L. (2011). Re-assessing the importance of necessary or sufficient conditions of critical success factors in IT project success: A fuzzy set-theoretic approach. In 9th European conference on information systems, ECIS 2011. Google Scholar
  85. Procaccino, J. D., Verner, J. M., Shelfer, K. M., & Gefen, D. (2005). What do software practitioners really think about project success: An exploratory study. Journal of Systems and Software, 78(2), 194–203.CrossRefGoogle Scholar
  86. Project Management Institute (PMI). (2014). A guide to the project management body of knowledge (PMBOK ® guide) (5th ed.). Newtown Square, PA: PMI Publications.Google Scholar
  87. Prosci. (2012). Best practices in change management. Prosci benchmarking report. Loveland, CO: Prosci®.Google Scholar
  88. Purohit, J. K., Mittal, M. L., Mittal, S., & Sharma, M. K. (2016). Interpretive structural modeling-based framework for mass customisation enablers: An Indian footwear case. Production Planning & Control, 27(9), 774–786.CrossRefGoogle Scholar
  89. Rana, N. P., Dwivedi, Y. K., Williams, M. D., & Weerakkody, V. (2015). Investigating success of an e-government initiative: Validation of an integrated IS success model. Information Systems Frontiers, 17, 127–142.CrossRefGoogle Scholar
  90. Ravi, V., & Shankar, R. (2005). Analysis of interactions among the barriers of reverse logistics. Technological Forecasting and Social Change, 72(8), 011–1029.CrossRefGoogle Scholar
  91. Raymond, L., & Bergeron, F. (2008). Project management information systems: An empirical study of their impact on project managers and project success. International Journal of Project Management, 26(2), 213–220.CrossRefGoogle Scholar
  92. Sage, A. P. (1977). Methodology for large-scale systems. New York: McGraw-Hill College.Google Scholar
  93. Salimifard, K., Abbaszadeh, M. A., & Ghorbanpur, A. (2010). Interpretive structural modeling of critical success factors in banking process re-engineering. International Review of Business Research Papers, 6(2), 95–103.Google Scholar
  94. Samantra, C., Datta, S., Sankar Mahapatra, S., & Ranjan, B. (2016). Interpretive structural modelling of critical risk factors in software engineering project. Benchmarking: An International Journal, 23(1), 2–24.CrossRefGoogle Scholar
  95. Sauer, C. (1993). Why information systems fail: A case study approach. London: Alfred Waller Ltd.Google Scholar
  96. Schmidt, R., Lyytinen, K., Keil, M., & Cule, P. (2001). Identifying software project risks: An international Delphi study. Journal of Management Information Systems, 17(4), 5–36.CrossRefGoogle Scholar
  97. Scott, J., & Vessey, I. (2000). Implementing enterprise resource planning systems: The role of learning from failure. Information Systems Frontiers, 2(2), 213–232.CrossRefGoogle Scholar
  98. Sharma, H. D., & Gupta, A. D. (1995). The objectives of waste management in India: A futures inquiry. Technological Forecasting and Social Change, 48(3), 285–309.CrossRefGoogle Scholar
  99. Shenhar, A., Dvir, D., Levy, O., & Maltz, A. (2001). Project success: A multidimensional strategic concept. Long Range Planning, 34(2001), 699–725.CrossRefGoogle Scholar
  100. Singh, R. K. (2011). Developing the framework for coordination in supply chain of SMEs. Business Process Management Journal, 17(4), 619–638.CrossRefGoogle Scholar
  101. Singh, M. D., Shankar, R., Narain, R., & Agarwal, A. (2003). An interpretive structural modeling of knowledge management in engineering industries. Journal of Advances in Management Research, 1(1), 28–40.CrossRefGoogle Scholar
  102. Söderlund, J. (2004). Building theories of project management: Past research, questions for the future. International Journal of Project Management, 28(2), 130–141.CrossRefGoogle Scholar
  103. Standish Group. (2013). CHAOS MANIFESTO think big act small. Boston. http://www.stansdishgroup.com. Accessed 20 June 2018.
  104. Sumner, M., Bock, D., & Giamartino, G. (2006). Exploring the linkage between the characteristics of it project leaders and project success. Information Systems Management, 23(4), 43–49.CrossRefGoogle Scholar
  105. Sumner, M., & Molka-Danielsen, J. (2010). Global IT teams and project success. In Proceedings of the 2010 special interest group on management information system’s 48th annual conference on computer personnel research on computer personnel research (pp. 34–42). ACM.Google Scholar
  106. Tamai, T., & Kamata, M. I. (2009). Impact of requirements quality on project success or failure. Design requirements engineering: A ten-year perspective (pp. 258–275). Berlin: Springer.CrossRefGoogle Scholar
  107. Thakkar, J., Kanda, A., & Deshmukh, S. G. (2007). Evaluation of buyer-supplier relationships using an integrated mathematical approach of interpretive structural modeling (ISM) and graph theoretic matrix: The case study of Indian automotive SMEs. Journal of Manufacturing Technology Management, 19(1), 92–124.CrossRefGoogle Scholar
  108. Thamsatitdej, P. (2017). Eco-design practices towards sustainable supply chain management: Interpretive structural modelling (ISM) approach. International Journal of Sustainable Engineering, 10(6), 326–338.CrossRefGoogle Scholar
  109. Tiwana, A., & McLean, E. R. (2003). The tightrope to e-business project success. Communications of the ACM, 46(12), 345–350.CrossRefGoogle Scholar
  110. Turner, J. R. (2009). The handbook of project-based management: Leading strategic change in organisations (3rd ed.). London, UK: McGraw-Hill.Google Scholar
  111. Turner, J., & Müller, R. (2005). The project manager’s leadership style as a success factor on projects: A literature review. Project Management Journal, 36(2), 49–61.CrossRefGoogle Scholar
  112. Tzeng, G. H., & Huang, C. Y. (2012). Combined DEMATEL technique with hybrid MCDM methods for creating the aspired intelligent global manufacturing & logistics systems. Annals of Operations Research, 197(1), 159–190.CrossRefGoogle Scholar
  113. Verner, J. M., & Abdullah, L. M. (2012). Exploratory case study research: Outsourced project failure. Information and Software Technology, 54(8), 866–886.CrossRefGoogle Scholar
  114. Verner, J., Sampson, J., & Cerpa, N. (2008). What factors lead to software project failure? In Proceedings of the 2nd international conference on research challenges in information science, RCIS 2008 (pp. 71–79).Google Scholar
  115. Warfield, J. N. (1974). Developing subsystem matrices in structural modeling. Systems, Man and Cybernetics, IEEE Transactions on, 1, 74–80.CrossRefGoogle Scholar
  116. Wateridge, J. (1995). IT projects: A basis for success. International Journal of Project Management, 13(3), 169–172.CrossRefGoogle Scholar
  117. Wu, F., Li, H. Z., Chu, L. K., Sculli, D., & Gao, K. (2009). An approach to the valuation and decision of ERP investment projects based on real options. Annals of Operations Research, 168(1), 181.CrossRefGoogle Scholar
  118. Yeo, K. T. (2002). Critical failure factors in information system projects. International Journal of Project Management, 20(3), 241–246.CrossRefGoogle Scholar
  119. Young, R. (2005). An example of relevant IS research for top managers on IT project failure. In ACIS 2005 proceedings: 16th Australasian conference on information systems.Google Scholar

Copyright information

© The Author(s) 2019

OpenAccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Authors and Affiliations

  • D. Laurie Hughes
    • 1
  • Nripendra P. Rana
    • 2
  • Yogesh K. Dwivedi
    • 2
    Email author
  1. 1.C/O School of ManagementSwansea University Bay CampusSwanseaUK
  2. 2.Emerging Markets Research Centre (EMaRC), School of ManagementSwansea University Bay CampusSwanseaUK

Personalised recommendations