Framing of project critical success factors by a systems model

INTERNATIONAL JOURNAL OF PROJECT MANAGEMENT International Journal of Project Management 24 (2006) 53–65 www.elsevier.com/locate/ijproman Framing of project critical success factors by a systems model Joyce Fortune *, Diana White Department of Technology Management, Faculty of Technology, The Open University, Walton Hall, Milton Keynes MK7 6AA, United Kingdom Received 11 June 2004; received in revised form 27 June 2005; accepted 14 July 2005 Abstract Perhaps the best known approach for tackling the human and organisational aspects of projects is through the use of Ôcritical success factorsÕ but although the approach has very many champions it is not without its critics. This paper sets out the findings of a major review of the sets of factors that are available and outlines the main reservations that have been expressed about the approach. It then shows how a systems model, the Formal Systems Model, can be used as a framing device to deliver the benefits of taking account of Ôcritical success factorsÕ whilst at the same time avoiding the problems associated with Ôcritical success factorsÕ that give rise to the criticisms. Two IS projects are used to demonstrate use of this framing devise. When observation began at the start of the projects they looked very similar and equally likely to succeed. In the event, one of the projects was largely successful across the whole of the range of measures normally used to judge success whilst the other exhibited most of the characteristics of failure. Analysis using the framing device is well able to demonstrate the marked differences in the ways the two projects were managed and to account for stark contrast in the levels of success achieved. The paper concludes that the Formal System Model allows the underlying benefits of Ôcritical success factorsÕ to be secured whilst overcoming most of the problems associated with a checklist approach.
2005 Elsevier Ltd and IPMA. All rights reserved. Keywords: Critical success factors; Formal system model; Human and organisational aspects of projects 1. Introduction The concept of success factors is usually credited to Daniel [1] who introduced it in relation to the Ômanagement information crisisÕ that was being brought about Ôby too rapid organizational changeÕ. In his seminal paper on the topic Rockart [2] unpacked the term Ôcritical success factorsÕ (CSFs) thus: . . .the limited number of areas in which results, if they are satisfactory, will ensure successful competitive performance for the organization . . . . . . the few key areas where Ôthings must go rightÕ for the business to flourish. * Corresponding author. Tel.: +44 01908 654896; fax: +44 01908 653718. E-mail address: J.Fortune@open.ac.uk (J. Fortune). 0263-7863/$30.00
2005 Elsevier Ltd and IPMA. All rights reserved. doi:10.1016/j.ijproman.2005.07.004 . . . areas of activity that should receive constant and careful attention from management. . . . the areas in which good performance is necessary to ensure attainment of [organizational] goals. Rockart gave his examples of critical success factors at industry and organization level from the perspective of the Chief Executive but sets of factors have now been developed at very many different levels and across a huge range of undertakings and activities. Where project management is concerned, the search for CSFs began in the 1960s. Since then very many authors have published lists of factors, sometimes relating them to specific problem domains and types of activity, sometimes stressing their applicability to all types of projects and sometimes turning the notion on its head and referring instead to critical failure factors. There have also been a significant number of studies comparing sets 54 J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 of factors and either trying to identify the definitive list or pointing out the need to match the list used to the project being undertaken. In recent times, the flow of research publications identifying new sets of factors has slowed but reference to and use of the concept has not diminished. 2. Comparison of sets of factors This section is based upon a review of 63 publications that focus on CSFs. Between them they draw on a variety of data sources and encompass theoretical studies and empirical studies of successful and unsuccessful projects. The CSFs cited across the 63 publications are listed in Table 1 in decreasing order of frequency of occurrence. It should be noted that in a number of papers, factor definitions were unclear. For example the factors Ôboard sponsorship supportÕ [3] and Ôupper management buy-inÕ [4] have been categorised here under the heading Ôsupport from senior managementÕ but it is accepted that they could also have been categorised under the heading of Ôproject sponsor/championÕ. The table shows there is only limited agreement among authors on the factors that influence project success. The three most cited factors are: the importance of a project receiving support from senior management; having clear and realistic objectives; and producing an efficient plan. However, although 81% of the publications include at least one of these three factors, only 17% cite all three. This lack of concurrence has also been identified by Wateridge [46] who states that Ôthere does not appear to be a consensus of opinion among researchers and authors on the factors that influence project successÕ. Another of the many interesting things that emerge from the comparison between publications is that although the importance of having a committed project sponsor or an executive to support or ÔchampionÕ the project was only cited in 19% of the publications examined, a study undertaken by Poon and Wagner [35] ranked this factor as the most critical. Similarly the studies undertaken by Cash and Fox [14], Martinez [18] and Jang and Lee [29] rank this factor among the three most critical and Larsen and Myers [66] in their case study evaluating a package-driven process re-engineering project found that a number of the managers they interviewed attributed initial project success to the commitment of the projectÕs sponsor. 3. Criticisms of the critical success factor approach In addition to the lack of agreement between authors that has been demonstrated above, two criticisms of the CSF approach emerge from the literature. The first is that the inter-relationships between factors are at least as important as the individual factors but the CSF approach does not provide a mechanism for taking account of these inter-relationships. As Nandhakumar [67] points out, Ôa better understanding of the relationship between key success factors and the EIS development is required if success factors are to be of any guidance to the practitioners to develop effective information systemsÕ. Belassi and Tukel [24] provide an example of the problem. For instance, top management support is a factor related to an organization which can be affected by the general state of the economy. Similarly, the uniqueness of the project activities can affect the project managerÕs competence on the job. Lack of top management support together with the project managerÕs lack of competence on the job might lead to project failure. Larsen and Myers [66] draw attention to the second criticism: Ôthe factor approach tends to view implementation as a static process instead of a dynamic phenomenon, and ignores the potential for a factor to have varying levels of importance at different stages of the implementation processÕ. The next section of this paper will propose a way of overcoming these difficulties whilst allowing almost all CSFs that have been identified as a result of a substantial review of the literature to be taken into account. 4. The Formal System Model Fig. 1 shows a model of a robust system that is capable of purposeful activity without failure. This model, known as the Formal System Model (FSM), was developed as part of their failures method by Bignell and Fortune [68]. It unites most core systems concepts and was adapted from Checkland [69], who in turn drew on the ideas of Churchman (particularly his concept of a teleological system) [70] and Jenkins [71]. The formal system at the heart of the model comprises a decision-making subsystem, a performancemonitoring subsystem and a set of subsystems and elements which carry out the tasks of the system and thus effect its transformations by converting inputs into outputs. The decision-making subsystem manages the system. It is responsible for decisions about how the purposes of the system are to be achieved such as which transformations are to be carried out and by what means and for providing the resources to enable this to happen. It makes known its expectations to the subsystems and components that carry out the systemÕs transformations and to the performance monitoring subsystem. It is therefore the decision-making subsystem 55 J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 Table 1 Critical success factors identified across 63 publications Critical factor Literature Count of citations Support from senior management Avots [5] ; Cleland and King [6] ; Morris [7] ; Pinto and Slevin [8] ; Morris and Hough [9] ; Stoddart-Stones [10] ; Magal et al. [11] ; Pinto and Mantel [12] ; McComb and Smith [13] ; Cash and Fox [14] ; Yap et al. [15] ; Pollalis and Frieze [16] ; Tennant [4] ; Selin and Selin [17] ; Martinez [18] ; The Standish Group [19] ; Couillard [20] ; Wastell and Newman [21] ; Tan [22] ; Munns and Bjeirmi [23] ; Belassi and Tukel [24] ; KPMG [25] ; McCormack [3] ; McGolpin and Ward [26] ; Dvir et al. [27] ; Kasser and Williams [28] ; Jang and Lee [29] ; Whittaker [30] ; Turner [31] ; Weir [32] ; Taylor [33] ; Thite [34] ; Poon and Wagner [35] ; Cooke-Davies [36] ; Andersen et al. [37] ; Caldeira and Ward [38] ; Yeo [39] ; Westerveld [40] ; Turner [41] Baker et al. [42] ; Morris [7] ; Hughes [43] ; Pinto and Slevin [8] ; Pinto and Mantel [12] ; Tennant [4] ; Selin and Selin [17] ; Harding [44] ; Couillard [20] ; Yeo [45] ; Wateridge [46] ; The Standish Group [19] ; Beare [47] ; Tan [22] ; Munns and Bjeirmi [23] ; Spinelli [48] ; Cicmil [49] ; Dvir et al. [27] ; Glass [50] ; Kasser and Williams [28] ; Jang and Lee [29] ; Clarke [51] ; Weir [32] ; Taylor [33] ; Thite [34] ; Poon and Wagner [35] ; Anderson et al. [37] ; Caldeira and Ward [38] ; Yeo [39] ; Westerveld [40] ; Turner [41] Avots [5] ; Baker et al. [42] ; Cleland and King [6] ; Morris [7] ; Morris and Hough [9] ; Pinto and Mantel [12] ; Pollalis and Frieze [16] ; Martinez [18] ; The Standish Group [19] ; Wateridge [46] ; Couillard [20] ; Smart [52] ; Williams [53] ; Belassi and Tukel [24] ; KPMG [25] ; Spinelli [48] ; McCormack [3] ; McGolpin and Ward [26] ; Dvir et al. [27] ; Kasser and Williams [28] ; Glass [50] ; Whittaker [30] ; Clarke [51] ; Turner [31] ; Taylor [33] ; Andersen et al. [37] ; Yeo [39] ; Westerveld [40] ; Turner [41] Avots [5] ; Cleland and King [6] ; Morris [7] ; Hughes [43] ; Pinto and Slevin [8] ; Curtis et al. [54] ; Magal et al. [11] ; Pinto and Mantel [12] ; McComb and Smith [13] ; Cash and Fox [14] ; Pollalis and Frieze [16] ; Wateridge [46] ; Couillard [20] ; Tan [22] ; Gowan and Mathieu [55] ; Hilderbrand [56] ; Spinelli [48] ; Dvir et al. [27] ; Kasser and Williams [28] ; Clarke [51] ; Turner [31] ; Thite [34] ; Cooke-Davies [36] ; Andersen et al. [37] ; Yeo [39] ; Westerveld [40] ; Turner [41] Morris [7] ; Pinto and Slevin [8] ; Curtis et al. [54] ; Magal et al. [11] ; Pinto and Mantel [12] ; McComb and Smith [13] ; Yap et al. [15] ; Pollalis and Frieze [16] ; Wateridge [46] ; Smart [52] ; Beare [47] ; Wastell and Newman [21] ; Belassi and Tukel [24] ; Munns and Bjeirmi [23] ; Cicmil [49] ; Spinelli [48] ; McCormack [3] ; Dvir et al. [27] ; Jang and Lee [29] ; Turner [31] ; Caldeira and Ward [38] ; Yeo [39] ; Westerveld [40] ; Turner [41] Baker et al. [42] ; Morris [7] ; Pinto and Slevin [8] ; Curtis et al. [54] ; Magal et al. [11] ; Pinto and Mantel [12] ; McComb and Smith [13] ; Cash and Fox [14] ; Pollalis and Frieze [16] ; Tennant [4] ; Martinez [18] ; Willcocks and Griffiths [57] ; The Standish Group [19] ; Dvir et al. [27] ; Glass [50] ; Jang and Lee [29] ; Weir [32] ; Poon and Wagner [35] ; Caldeira and Ward [38] ; Westerveld [40] Avots [5] ; Pinto and Mantel [12] ; McComb and Smith [13] ; Cash and Fox [14] ; Pollalis and Frieze [16] ; Martinez [18] ; Willcocks and Griffiths [57] ; Smart [52] ; The Standish Group [19] ; Hougham [58] ; Cicmil [49] ; McGolpin and Ward [26] ; Dvir et al. [27] ; Weir [32] ; Taylor [33] ; Thite [34] ; Poon and Wagner [35] ; Cooke-Davies [36] ; Yeo [39] Avots [5] ; Baker et al. [42] ; Morris [7] ; Pinto and Slevin [8] ; Pollalis and Frieze [16] ; Martinez [18] ; Cannon [59] ; Couillard [20] ; Pinto and Kharbanda [60] ; Belassi and Tukel [24] ; Munns and Bjeirmi [23] ; Spinelli [48] ; Dvir et al. [27] ; Glass [50] ; Weir [32] ; Taylor [33] ; Andersen et al. [37] ; Westerveld [40] ; Turner [41] Avots [5] ; Pollalis and Frieze [16] ; Smart [52] ; Pinto and Kharbanda [60] ; Munns and Bjeirmi [23] ; KPMG [25] ; McGolpin and Ward [26] ; Dvir et al. [27] ; Whittaker [30] ; Poon and Wagner [35] ; Cooke-Davies [36] ; Andersen et al. [37] ; Caldeira and Ward [38] ; Yeo [39] ; Westerveld [40] ; Turner [41] Morris [7] ; Pinto and Slevin [8] ; Morris and Hough [9] ; Yap et al. [15] ; Pollalis and Frieze [16] ; Tennant [4] ; McCormack [3] ; The Standish Group [19] ; Belassi and Tukel [24] ; Gowan and Mathieu [55] ; Dvir et al. [27] ; Kasser and Williams [28] ; Turner [31] ; Caldeira and Ward [38] ; Westerveld [40] ; Turner [41] Morris and Hough [9] ; Cash and Fox [14] ; Pollalis and Frieze [16] ; Tennant [4] ; Martinez [18] ; Smart [52] ; Gowan and Mathieu [55] ; Pinto and Kharbanda [60] ; Dvir et al. [27] ; Turner [31] ; Thite [34] ; Andersen et al. [37] ; Caldeira and Ward [38] ; Westerveld [40] ; Turner [41] Morris [7] ; Pinto and Mantel [12] ; McComb and Smith [13] ; Pollalis and Frieze [16] ; Cannon [59] ; Williams [53] ; Yeo [45] ; Tan [22] ; KPMG [25] ; Dvir et al. [27] ; Glass [50] ; Poon and Wagner [35] ; Caldeira and Ward [38] ; Yeo [39] Cleland and King [6] ; Morris [7] ; Morris and Hough [9] ; Pinto and Mantel [12] ; McComb and Smith [13] ; Tennant [4] ; Selin and Selin [17] ; Dvir et al. [27] ; Glass [50] ; Kasser and Williams [28] ; Weir [32] ; Yeo [39] ; Westerveld [40] ; Turner [41] (continued on 39 Clear realistic objectives Strong/detailed plan kept up to date Good communication/ feedback User/client involvement Skilled/suitably qualified/ sufficient staff/team Effective change management Competent project manager Strong business case/ sound basis for project Sufficient/well allocated resources Good leadership Proven/familiar technology Realistic schedule 31 29 27 24 20 19 19 16 16 15 14 14 next page) 56 J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 Table 1 (continued) Critical factor Literature Count of citations Risks addressed/assessed/ managed Morris and Hough [9] ; Selin and Selin [17] ; Smart [52] ; Beare [47] ; Williams [53] ; KPMG [25] ; Baldry [61] ; Dvir et al. [27] ; Whittaker [30] ; Weir [32] ; Cooke-Davies [36] ; Yeo [39] ; Westerveld [40] Morris [7] ; Morris and Hough [9] ; Cash and Fox [14] ; Yap et al. [15] ; Martinez [18] ; McGolpin and Ward [26] ; Jang and Lee [29] ; Baldry [61] ; Thite [34] ; Poon and Wagner [35] ; Caldeira and Ward [38] ; Yeo [39] McComb and Smith [13] ; Cash and Fox [14] ; Pollalis and Frieze [16] ; Selin and Selin [17] ; Cicmil [49] ; Dvir et al. [27] ; Weir [32] ; Thite [34] ; Poon and Wagner [35] ; Cooke-Davies [36] ; Westerveld [40] ; Turner [41] Baker et al. [42] ; Cleland and King [6] ; Morris and Hough [9] ; Dvir et al. [27] ; McComb and Smith [13] ; Pollalis and Frieze [16] ; Tennant [4] ; Glass [50] ; Caldeira and Ward, [38] ; Westerveld [40] ; Turner [41] Pollalis and Frieze [16] ; Cannon [59] ; Willcocks and Griffiths [57] ; Martinez [18] ; Couillard [20] ; Hougham [58] ; Gowan and Mathieu [55] ; Taylor [33] ; Thite [34] ; Cooke-Davies [36] Morris and Hough [9] ; Pollalis and Frieze [16] ; McCormack [3] ; KPMG [25] ; Glass [50] ; Jang and Lee [29] ; Caldeira and Ward [38] ; Yeo [39] ; Westerveld [40] ; Turner [41] Avots [5] ; Cleland and King [6] ; Sauer [62] ; Beare [47] ; Pinto and Kharbanda [60] ; Munns and Bjeirmi [23] ; McCormack [3] McGolpin and Ward [26] ; Dvir et al. [27] Magal et al. [11] ; Yap et al. [15] ; Pinto and Kharbanda [63] ; Pinto and Kharbanda [60] ; McCormack [3] ; Dvir et al. [27] ; Caldeira and Ward [38] Morris and Hough [9] ; Pollalis and Frieze [16] ; Tennant [4] ; Sauer [62] ; Yeo [45] ; Pinto and Kharbanda [60] Hughes [43] ; Munns and Bjeirmi [23] ; Dvir et al. [27] ; Glass [50] ; Jang and Lee [29] ; Turner [41] 13 Morris [7] ; Cleland and King [6] ; Archibald [65] ; Pinto and Kharbanda [60] ; Caldeira and Ward [38] ; Westerveld [40] Yap et al. [15] ; Dvir et al. [27] ; Jordan et al. [64] ; Sauer [62] ; Cooke-Davies [36] Hughes [43] ; Selin and Selin [17] ; Cannon [59] ; Cooke-Davies [36] 6 Curtis et al. [54] ; Pinto and Kharbanda [63] ; Turner [41] 3 Project sponsor/champion Effective monitoring/control Adequate budget Organisational adaptation/ culture/structure Good performance by suppliers/ contractors/consultants Planned close down/review/ acceptance of possible failure Training provision Political stability Correct choice/past experience of project management methodology/tools Environmental influences Past experience (learning from) Project size (large)/level of complexity (high)/number of people involved (too many)/ duration (over 3 years) Different viewpoints (appreciating) 12 12 11 10 10 9 7 6 6 5 4 = Empirical-data mainly obtained from survey(s). = Empirical-data mainly obtained from case studies(s). = Theoretical – but data often based on work of others. that allows the system to exhibit choice, and thus behave as a purposeful system. The performance monitoring subsystem is charged with observing the transformation processes and reporting deviations from the expectations to the decision-making subsystem so that it can initiate corrective action where necessary. The other features of the model include: a continuous purpose or mission that gives rise to expectations; a degree of connectivity between the components; an environment with which the system interacts; boundaries separating the system from its wider system and the wider system from the environment; resources; and some guarantee of continuity. The FSM has been used successfully over a long period of time to investigate failures (see [72,73]). The way it is used is to conceptualize a situation as a system and then compare the resulting system with the FSM in order to determine the extent to which the components, links and other features necessary for purposeful activity without failure are present. Such comparisons across a broad range of projects have revealed a number of common themes. These include: 1. Deficiencies in the apparent organizational structure of the system, such as a lack of a performance-measuring subsystem or a control/decision-making subsystem. 2. No clear statements of purpose supplied in a comprehensible form to the system from the wider system. 3. Lack of an effective means of communication between the various subsystems. 4. Not enough consideration given to the influence of the environment, and insufficient resources to cope with those environmental disturbances that were foreseen. 5. An imbalance between the resources applied to the basic transformation processes and those allocated to the related monitoring and control processes, perhaps leading at one extreme to quality problems and at the other to cost increases or delays. J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 Table 2 Critical success factors mapped onto components of the Formal System Model Environment attempts to influence disturbs Wider system boundary Wider system formulates initial design of provides resources and legitimates area of operation makes known expectations supplies performance information Component of FSM/ project attributes Critical success factors from literature Goals and objectives Clear realistic objectives Strong business case/sound basis for project Performance monitoring Effective monitoring/control Planned close down/review/acceptance of possible failure Decision-maker(s) Support from senior management Competent project manager Strong/detailed plan kept up to date Realistic schedule Good leadership Correct choice/past experience of project management methodology/tools System Boundary System Decision-making subsystem decides on transformations implemented by designed set of provides resources and legitimates operations makes known expectations Transformations Skilled/suitably qualified/sufficient staff/team Communication Good communication/feedback Environment Political stability Environmental influences Past experience (learning from) Organisational adaptation/culture/structure Boundaries Project size/level of complexity/number of people involved/duration Resources Adequate budget Sufficient/well allocated resources Training provision Proven/familiar technology Good performance by suppliers/contractors/ consultants Continuity Risks addressed/assessed/managed reports to Subsystems and components that carry out transformations 57 Performance monitoring subsystem provides performance information Fig. 1. The Formal System Model. Table 2 shows that it is possible to map 23 of the 27 CSFs identified earlier in this paper with the features of the FSM directly and at least three of the remaining four are implicit within the systemic nature of the model. (These four are shown at the bottom of the table. The possible exception is the Project Champion but it can be argued that that role is covered by the legitimizing process.) The implication of the mapping shown in Table 2 is that the model contains within it the factors identified in the literature as being critical to success and can thus act as a framing device for project critical success factors. Furthermore, because the FSM is as concerned with the relationships between its components as it is with the components themselves it should provide a way of making links between factors and is thus be able to overcome the first of the two main criticisms outlined above. The FSM should also be able to deal with the second criticism of the CSF approach (that it is unable to cope with the dynamic nature of IS projects) because it is a dynamic model of a system that responds to decision making and interacts with its environment. User/client involvement Different viewpoints (appreciating) Project sponsor/champion Effective change management 5. Use of the FSM as a framing device Accounts of two similar projects, one successful and one not, will be used to investigate the proposal that the FSM, which has value in its own right, allows a very broad range of CSFs to be taken into account whilst overcoming problems associated with their use. Information about the projects was gathered via series of structured and semi-structured interviews whilst the projects were actually being carried out and therefore, by definition, before their level of success could be known. As Table 3 illustrates the two projects were very similar in terms of size and scope and at the outset both looked equally likely to succeed. In the event, however, the outcomes of the two projects were very, very different. Project A was largely successful across the whole of the range of measures normally used to judge success. Project B, on the other hand, exhibited most of the characteristics of failure; it was over-budget, late and did not 58 J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 Table 3 Project A and Project B – an initial comparison Project type Sector Initial schedule Budget Success criteria Number of stakeholders Customers IS software Project management software used Working environment Project A Project B Information system Public 10 months Generous On time, to quality, within budget, successful installation of advice and enforcement infrastructure 112 General public Bespoke Microsoft Project Extensive building work undertaken on main site Information system Public 14 months Realistic On time, within budget, successful installation of web-based information system 120 General public Off-the-shelf Microsoft Project Head office building completely refurbished meet stakeholdersÕ expectations. The two projects will be described briefly here. More detailed descriptions can be found in Fortune and Peters [74]. 5.1. Project A Project A was carried out by a Government Agency within a large Department of State. Its purpose was to set up a UK-wide help line to communicate information about a new, high-profile piece of legislation and to help with the enforcement of the requirements of the legislation. The help line and enforcement system had to be in place within eight months and the project as a whole brought to a close a further two months after that. A Project Board consisting of 30 people from senior levels of the Agency and the two Departments of State was put together to act as the decision makers for the project. The Board members recognised that because of their mix of cultures and lack of a shared geographical base they would need to establish robust line management reporting and decision making processes. Their solution was to recognise two members based in the north as project champions and arrange the remaining members into a functional matrix. An experienced Project Manager was appointed from within the organization. He was placed in charge of the day-to-day management of the project and was supported by a core team of 30 people who were also dispersed geographically. The size of the budget remains confidential, but it is possible to say that the Project Manager regarded it as generous. An Ôin-houseÕ Project Management Method (similar to PRINCE) with which most of the team were familiar was used to manage the project. As prescribed by the method, the project was divided into the following stages:      initiation, research, investigation, feasibility, business case,      funding, design, development, implementation, closure. During the course of the project it was felt that the method was Ôtoo heavyÕ and required far too much documentation so it was Ôcut downÕ. The software package ÔMicrosoft ProjectÕ was used as a tracking tool to enable time taken and costing information to be tracked weekly. It was also used to identify dependencies and flag those regarded as ÔcriticalÕ. The information it provided on project progress was fed back to the Project Board. Although there were some delays, unexpected events and setbacks during the course of the project, the projectÕs owners, the Project Manager and his team all regarded it as a success. The objectives set for it were met. By the appointed completion date a telephone help line staffed by trained operatives able to offer information and advice was operational and 14 teams of Inspectors had been put in place in locations across the United Kingdom and trained to carry out the necessary enforcement. The project was also within budget. The Closure stage was reached on schedule and a Post Implementation Review was completed before the project was formally brought to a close by which time the help line and the inspection teams were already embedded in the organization and judged to be working well. 5.2. Project B Project B was undertaken within a public sector organisation serving local government and was triggered by concerns that much of the organisationsÕ ITC equipment and software was out of date. A firm of outside consultants was called in to carry out an information and communication review and recommend a strategy which would carry the organisation forward. The consultantsÕ conclusion was that a completely new system was needed with Internet as the Ôkey technologyÕ and a new Windows-based client database at its heart. J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 59 Table 4 An evaluation of Projects A and B in relation to the CSFs identified in Table 1 Critical factor Project A Project B Taken account of Comments Taken account of Comments Support from senior management X The Project Board supported the Project Manager. They met on a weekly basis · There was no evidence of the Project Manager receiving support from the Management Team. For example, he was required to carry out all his existing duties in addition to managing the project Clear realistic objectives X The project requirements were clearly defined and perceived to be realistic. (This perception was proved to be valid.) X The project requirements were clearly defined and at senior levels, at least, were regarded as realistic Strong/detailed plan kept up to date X A clear plan was formulated and an efficient planning and control system was operated to keep them up to date. · No detailed plan established. Although the schedule was changed on a number of occasions no measures were taken to monitor performance regularly Good communication/ feedback X A robust line management reporting system was established between the Project Board and the Project Manager and between the latter and his Team · Communication was poor and usually took place by e-mail. Formal meetings were rare. Little feedback was given User/client involvement X Those who would be using the system became involved during the project and though they did not participate directly end usersÕ needs were considered · These were not considered. Indeed, the opinions of the primary users were ignored at the design stage Skilled/suitably qualified/ sufficient staff/team X All 30 members of the had worked on earlier projects run using the same ÔinhouseÕ Project Management Method and most had worked with the Project Manager before · Neither the Project Manager nor any members of his Team had previous project experience and only one Project Team member had any IT/IS qualifications Effective change management N/A N/A Competent project manager X Yes · No Strong business case/sound basis for project X Established as one of the stages of the ÔinhouseÕ Project Management Method used. X Case signalled very clearly because current ITC equipment and software was recognised as out of date Sufficient/well allocated resources X All types of resource were sufficient and well allocated. X Adequate resources (apart from staffing) were available but were not always allocated as well as they might have been Good leadership X The Project Manager proved to be a charismatic leader · The Project Manager had inadequate leadership skills Proven/familiar technology X Yes · Those in organization not familiar with the technology being introduced Realistic schedule X Yes X Original schedule was realistic though delays early on meant the project soon fell behind schedule Risks addressed/assessed/ managed X At the start of the project the Project Manager tried to identify all the risks that would need to be managed to ensure project success. All risks that did arise were managed successfully · The Project Manager identified the project as a Ôrisky ventureÕ but he did not undertake a risk analysis. No contingency measures were put in place Project sponsor/champion X Two members of the Project Board acted as project champions · No Effective monitoring/control X Yes, assisted by use of Microsoft Project · No (continued on next page) 60 J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 Table 4 (continued) Critical factor Project A Project B Taken account of Comments Taken account of Comments Adequate budget X Budget described as ÔgenerousÕ X Budget described as ÔadequateÕ Organisational adaptation/ culture/structure X Potential ÔclashÕ of cultures between agencies involved in the project identified as a risk and managed accordingly · No effort made to take account of problems caused by the organisationÕs culture such as the communication difficulties arising from excessive reliance on e-mail. Good performance by suppliers/contractors/ consultants X Yes · Suppliers performed poorly; new software was late, and essential hardware was faulty or late Planned close down/review/ acceptance of possible failure X There was a planned closedown and a post implementation review was undertaken. Lessons learnt were recorded · The scope of the project was reduced towards the end and no planned closedown took place. No formal review was undertaken Training provision X Although some training was late, all staff were adequately trained · Training was inadequate and late. User manuals did not progress beyond the draft stage Political stability X Yes X Yes Correct choice/past experience of project management methodology/tools X A familiar Project Management Method was chosen and adapted to meet the projectÕs needs · No project management method was used. Gantt Charts were produced for scheduling purposes but the schedules were not adhered to Environmental influences X Taken account of successfully · Not considered and no effective action taken when they did interfere with the project Past experience (learning from) X Every indication that Project Manger had learnt from his extensive past experience. · No Project size (large)/level of complexity (high)/number of people involved (too many)/duration (over 3 years) Different viewpoints (appreciating) Counts of ÔyesÕ N/A X N/A Account taken of the viewpoints of end users, Project Team and the needs of the organisation 25/25 = 100% The consultantsÕ proposal was accepted by the threestrong Management Team that ran the organization and a Project Manager and four team members were appointed. The Management Team, rather than the Project Manager, took on the role of main decision maker and co-opted further staff onto the project team as and when necessary. In order to meet the various logistical considerations a 14 months schedule was drawn up and a budget, described as ÔadequateÕ was agreed. Use of the project management methodology PRINCE2 was considered but in the end no formal methodology was used. ÔMicrosoft ProjectÕ, of which none of the project team had any previous experience, · Viewpoints of end users and the Project Team not considered 6/25 = 24% was used so that Gantt Charts could be produced for scheduling purposes. Although the project had been scheduled for a summer start the Project Manager and his team were so busy with their routine duties that they did not hold their first team meeting until nearly six months later. The main item on the agenda was the rescheduling of the project so as to meet the deadline that had been fixed. However, it was not long before the project fell behind the revised schedule as the first of a series of problems started to emerge. The project was eventually drawn to a close over six months later than originally envisaged and although one of the primary aims was achieved – the J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 Environment including national economy, Parliament, legislation disturbs Wider System Boundary PROJECT BOARD sets out requirements (help line/enforcement system to be completed on time, to budget) formulates business plan, schedule, requirment for system to meet quality standards, projectto fit in with organisation/other initiatives defines legislation, defines final rules and regulations provides funds for setting up costs, identifies technology, makes staff available, appoints Independent Auditor, provides late publicity feeds back information on progress System Boundary IMPLEMENTATION SYSTEM Project Manager having considered end users,the effectof travelling (time/stress) on team, mix of cultures involved sets out objectives, business plan, measures of performance, defines quality, suggests 'risk diary', decides on schedule, tracking system, communications plan, sets up weekly meetings shares past experience, provides funds, appoints team, equipment, technology, training suggests project management method/tools, expects effective management of risk , loyalty, regular communication, project to fit in with other initiatives, supports team decisions no authority to influence feeds back information on progress Performance monitoring sub system Project Team Members undertaking transformations Change agent flags critical dependencies,tracks finance, issues papers on out standing issues, monitors team performance, risks, quality, change, close down, lessons learnt provide performance information Unsuccessful attempt to influence Fig. 2. Model of Project A. Independent Auditor 61 62 J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 Environment including Suppliers, Consultants, Contracts, other parts of Organisation, staff, outside contractors very limited attempt to influence communication culture Wider System Boundary MANAGEMENT TEAM formulates infrastructure, sets out project plan, use of project management tool (instructions unclear) provides adequate budget, appoints project manager and team, appoints co-opted team, signs contracts with suppliers sets sc hedule, requires users to be trained supplies limited information on progress System Boundary INFRASTRUCTURE SETTING SYSTEM Project Manager having no previous project management experience sets out limited plan provides funds Project Team carries out normal duties and implementation activities Distributes Gantt Charts, makes known system requirements Co-opted team attempts to train staff Unsuccessful attempt to influence Fig. 3. Model of Project B. 63 J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 Table 5 Comparison between the features of the Formal System Model and Projects A and B Feature of FSM/project attributes Project A Project B Main decision-makers (wider system) Project Manager (system) Main decision-makers (wider system) Project Manager (system) Yes Yes Yes Transformations Yes Yes Yes – but on a number of occasions expectations not clear – Yes Yes No Yes – but expectations not made clear – Communication Environment Boundaries Resources Continuity Viewpoints Project Champion Change Agent Counts of ÔyesÕ Yes No Yes Yes – but poor publicity Yes Yes – but not adequately Yes Yes 10/11 Yes Yes Yes Yes Yes Yes Yes Yes 12/12 No No Yes No No No No No 3/11 Yes No Yes – but expectations not made clear Yes – but normal duties also carried out No No No No No No No No 3/12 Total counts 22/23 = 96% Goals objectives Performance monitoring Decision-maker(s) new Windows-based client database was put in place successfully – many other objectives were not met. Furthermore, the project exceeded its budget by around 25%. Unfortunately the completion of the project did not mean an end to the problems associated with it. A number of technical limitations/inadequacies to the new information system came to light soon after it went live. The effect of these was to reduce the amount of activity the organisation was able to undertake and this in turn led to a reduction in the organizationÕs income. Many members of staff were unhappy with the new system. In part their dissatisfaction was due to their lack of training but it was also triggered by their belief that their opinions had been ignored when design decisions had been made early in the projectÕs life cycle. 5.3. Critical success factors and the projects Table 4 shows an evaluation of the two projects in relation to the CSFs identified in Table 1. 5.4. Formal system model and the projects Figs. 2 and 3 show Projects A and B, respectively, presented in the format of the FSM. It is clear from Fig. 2 that there is a very close match between Figs. 1 and 2. The presence of the components and interactions needed for purposeful activity without failure is a reflection of the success of Project A. By contrast, comparison of Fig. 3 with Fig. 1 reveals the many discrepancies that are a strong reflection of the lack of success of Project B. For example no evidence of performance monitoring, unclear expectations, no communications plan, and a very limited attempt to influence the environment. 6/23 = 26% Table 5 shows the information used to prepare Figs. 2 and 3 in non-diagrammatic form. It is very noticeable that there is a high degree of correspondence between Tables 4 and 5 but the holistic impression of the two projects that is painted in Figs. 2 and 3 is lost in the Tables. It can be argued that if action to remedy shortcomings was going to be taken during the life of Project B Fig. 3 would give much greater guidance on where to concentrate that action. 6. Conclusion This paper has shown three things. Through a review of sets of critical success factors from 63 publications it has revealed that there is a lot of overlap between sets but the factors selected for inclusion in individual lists vary to a considerable extent. Second, it has shown that the Formal System Model contains within it all of the factors that are covered by sets of CSFs but has the advantage of being able to consider the relationships between factors and, because it is dynamic, overcomes the third criticism of the CSF approach. Thirdly, it has demonstrated that the Formal System Model is capable of distinguishing between successful and unsuccessful projects and therefore if used in the planning and implementation phases can provide a way of tackling the human and organisational aspects of systems development projects. References [1] Daniel DR. Management information crisis. Harvard Bus Rev 1961(September–October):111–21. 64 J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 [2] Rockart JF. Chief executives define their own data needs. Harvard Bus Rev 1979(March–April):81–93. [3] McCormack S. The lemon factor. The Engineer 1997(June):22–4. [4] Tennant DV. Avoiding failure in project management. In: Proceedings of the advances in instrumentation and control: ISA conference and exhibition; 1993. p. 675–86. [5] Avots I. Why does project management fail? California Manage Rev 1969;12(1):77–82. [6] Cleland DI, King WR. Systems analysis and project management. New York: McGraw-Hill; 1983. [7] Morris PWG. Research at Oxford into the preconditions of success and failure of major projects: In: Proceedings of the 18th annual seminar/symposium of the Project Management Institute, Montreal, Canada; 1986. p. 53–66. [8] Pinto JK, Slevin DP. Critical factors in successful project implementation. IEEE Trans Eng Manage 1987;EM-34(1):22–7. [9] Morris PWG, Hough GH. The anatomy of major projects. Chichester: Wiley; 1987. [10] Stoddart-Stones R. Development of project management systems for major projects. Int J Project Manage 1988;6(1):34–8. [11] Magal SR, Carr HH, Watson H. Critical success factors for information centre managers. MIS Quart 1988;12:413–26. [12] Pinto JK, Mantel SJ. The causes of project failure. IEEE Trans Eng Manage 1990;37(4):269–76. [13] McComb D, Smith JY. System project failure: the heuristics of risk. J Inform Syst Manage 1991;8(1):25–34. [14] Cash C, Fox R. Elements of successful project management. J Syst Manage 1992;43(9):10–2. [15] Yap CS, Soh CPP, Raman KS. Information systems success factors in small business. OMEGA 1992;20(5/6):597–609. [16] Pollalis YA, Frieze IH. A new look at critical success factors in IT. Inform Strategy 1993(Fall):24–34. [17] Selin G, Selin M. Reasons for project management success and failure in multiproject environment: In: Proceedings of the INTERNET world congress, Oslo, Norway; 1994. p. 513–9. [18] Martinez EV. Avoiding large-scale information systems project failure: the importance of fundamentals. Project Manage J 1994;25(2):17–25. [19] The Standish Group. http://www.standishgroup.com/chaos.htm [accessed April 2000]. [20] Couillard J. The role of project risk in determining project management approach. Project Manage J 1995;26(4):3–15. [21] Wastell D, Newman M. Information system design, stress and organisational change in the ambulance service: a tale of two cities. Acc Manage Inform Technol 1996;6(4):283–300. [22] Tan RR. Success criteria and success factors for external technology transfer projects. Project Manage J 1996;27(2):45–56. [23] Munns AK, Bjeirmi BF. The role of project management in achieving project success. Int J Project Manage 1996;14(2):81–7. [24] Belassi W, Tukel OI. A new framework for determining critical success/failure factors in projects. Int J Project Manage 1996;14(3):141–51. [25] KPMG. What went wrong? Unsuccessful information technology projects. KPMG Strategic and Technology Services; 1997. [26] McGolpin P, Ward J. Factors influencing the success of strategic information systems. In: Mingers J, Stowell F, editors. Information systems: an emerging discipline? London: McGraw-Hill; 1997. p. 287–327. [27] Dvir D, Lipovetsky S, Shenhar A, Tishler A. In search of project classification: a non-universal approach to project success factors. Res Policy 1998;27:915–35. [28] Kasser J, Williams VR. What do you mean you canÕt tell me if my project is in trouble?: In: Proceedings of the FESMA98, Antwerp, Belgium; 1998. [29] Jang Y, Lee J. Factors influencing the success of managing consulting projects. Int J Project Manage 1998;16(2):67–72. [30] Whittaker B. What went wrong? Unsuccessful information technology projects. Informat Manage Comput Security 1999;7(1):23–9. [31] Turner JR. The handbook of project based management. second ed. London: McGraw-Hill; 1999. [32] Weir S. Designing and managing successful projects. http:// www.jws.net/weir/design.html [accessed December 1999]. [33] Taylor A. IT projects: sink or swim. Comput Bull 2000(January): 24–6. [34] Thite M. Leadership styles in information technology projects. Int J Project Manage 2000;18:235–41. [35] Poon P, Wagner C. Critical success factors revisited: success and failure cases of information systems for senior executives. Decision Support Syst 2001;30(4):393–418. [36] Cooke-Davies T. The ÔrealÕ success factors in projects. Int J Project Manage 2002;20(3):185–90. [37] Andersen ES, Dyrhaug QX, Jessen SA. Evaluation of Chinese projects and comparison with Norwegian projects. Int J Project Manage 2002;20(8):601–9. [38] Caldeira MM, Ward JM. Understanding the successful adoption and use of IS/IT in SMEs: an explanation from Portuguese manufacturing industries. Inform Syst J 2002;12:121–52. [39] Yeo KT. Critical failure factors in information system projects. Int J Project Manage 2002;20(3):241–6. [40] Westerveld E. The Project Excellence Model: linking success criteria and critical success factors. Int J Project Manage 2003;21:411–8. [41] Turner JR. Managing Web projects. Aldershot: Gower; 2004. [42] Baker BN, Murphy DC, Fisher D. Factors affecting project success. In: Cleland DI, King WR, editors. Project management handbook. New York: Van Nostrand Reinhold; 1983. p. 669–85. [43] Hughes MW. Why projects fail: the effect of ignoring the obvious. Ind Eng 1986;18:14–8. [44] Harding JS. A crash course in project engineering. Chem Eng 1995;102:118–26. [45] Yeo KT. Planning and learning in major infrastructure development: systems perspectives. Int J Project Manage 1995;13(5):287–93. [46] Wateridge J. IT projects: a basis for success. Int J Project Manage 1995;13(3):169–72. [47] Beare D. Risk management in information systems development: a case study. Eng Manage J 1995(April):63–5. [48] Spinelli D. Keys to success in management projects. Network World 1997;4(14). [49] Cicmil SJK. Critical factors of effective project management. The TQM Mag 1997;9(6):390–6. [50] Glass RL. Software runaways: lessons learned from massive software project failure. New Jersey: Prentice-Hall; 1998. [51] Clarke A. A practical use of key success factors to improve the effectiveness of project management. Int J Project Manage 1999;17(3):139–45. [52] Smart G. DonÕt be a system victim. Internal Auditing 1995:18–21. [53] Williams BR. Why do software projects fail? GEC J Res 1995;12(1):13–6. [54] Curtis B, Krasner H, Iscoe N. A field study of the software design process for large systems. Commun ACM 1988;31(11):1268–87. [55] Gowan JA, Mathieu RG. Critical factors in information system development for a flexible manufacturing system. Comput Ind 1996;28:173–83. [56] Hilderbrand C. Loud and clear. CIO 1996;9(13):56–60. [57] Willcocks L, Griffiths C. Predicting risk of failure in large-scale information technology projects. Technol Forecast Social Change 1994;47:205–28. [58] Hougham M. London Ambulance Service computer-aided despatch system. Int J Project Manage 1996;14(2):103–10. J. Fortune, D. White / International Journal of Project Management 24 (2006) 53–65 [59] Cannon JA. Why IT applications succeed or fail. Ind Commer Train 1994;26(1):10–5. [60] Pinto JK, Kharbanda OP. How to fail in project management (without really trying. Bus Horizons 1996;35(4):45–53. [61] Baldry D. The evaluation of risk management in public sector capital projects. Int J Project Manage 1998;16(1):35–41. [62] Sauer C. Why information systems fail: a case study approach. Henley on Thames: Alfred Waller; 1993. [63] Pinto JK, Kharbanda OP. Lessons from an accidental profession. IEEE Eng Manage Rev 1995;23(4):18–27. [64] Jordan G, Lee I, Cawsey G. Learning from experience. London: H.M. Stationery Office; 1988. [65] Archibald RD. Managing high-technology programs and projects. Second ed. Chichester: Wiley; 1992. [66] Larsen M, Myers M. When success turns into failure: a packagedriven process re-engineering project in the financial services industry. J Strategic Inform Syst 1999;8(4):395–417. [67] Nandhakumar J. Design for success?: critical success factors in executive information systems development. Eur J Inform Syst 1996;5(1):62–72. [68] Bignell V, Fortune J. Understanding systems failures. Manchester: University of Manchester Press; 1984. 65 [69] Checkland PB. Systems thinking, systems practice. Chichester: Wiley; 1981. [70] Churchman CW. The design of inquiring systems. New York: Basic Books; 1971. [71] Jenkins GM. The systems approach. J Syst Eng 1969;1:3–49. [72] Fortune J, Peters G. The formal system paradigm for studying failures. Technol Anal Strategic Manag 1990;2(4):383–90. [73] Fortune J, Peters G. Learning from failure. Chichester: Wiley; 1995. [74] Fortune J, Peters G. Information systems: achieving success by avoiding failure. Chichester: Wiley; 2005. Joyce Fortune is Head of the Department of Technology Management at the Open University. Her teaching and research interests include systems failures, quality management and technology strategy. Her most recent publications cover topics such as risk in project management, human rights and ethical policing, emergence and systems approaches to failure. Diana White is a Visiting Research Fellow in the Faculty of Technology at the Open University. In 2003, she was awarded a PhD by the University for a thesis entitled A Systems View of Project Management Risk and has published a number of papers in this area.