Although project management is often said to have its roots in other traditional fields, such as construction, Morris (2002) asserts that modern project management practices have their origins in the 1950s US aerospace agencies. Much has been written about Information System (IS) / Information Technology (IT) project initiatives in both the public and private sectors. In fact, many information systems frequently fall short of their requirements, and are, more often than not, costlier and arrive later than anticipated, if indeed they are completed at all. For instance, according to a report for the Organization for Economic Co-operation and Development (2001), failures of major IT investments and key systems development projects have raised concerns for the achievement of service improvement through information technology. Additionally, it has been argued that failures in IT projects are more common than failures in any other aspect of modern business (Nulden, 1996). The widely-cited Standish Group (1994) study, carried out in the US, classified IT projects as follows: • Resolution Type 1 (Project Success): The project is completed on-time and on-budget, with all features and functions as initially specified. • Resolution Type 2 (Project Challenged): The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified. • Resolution Type 3 (Project Impaired): The project is cancelled at some point during the development cycle. The report estimated the success rate was only 16.2%, while challenged projects accounted for 52.7%, and impaired projects (cancelled) amounted to 31.1%. Since large complex projects in any area are difficult to organize, it could be said that the level of abstraction required often leads to a lack of understanding between all stakeholders involved with the project. Callahan and Moretton (2001) describe software design as being “in the code”. They assert that since it is not visible, it makes it hard to use software design as a focal point for development project coordination and integration, unlike many physical designs which can be made visible to all project participants. As a result of this “invisibility”, managing the development of an IS project is arguably more problematic than project management within the manufacturing sector because software development is often a highly conceptual and complex process. Indeed, a lack of adequate project management knowledge could be said to be a major contributing factor to unsuccessful IS projects. For instance, as project managers should be aware, unless specific objectives and clear-cut end points have been set, it can be difficult to know if a milestone has been reached and indeed if the required end-product has been produced. However, making use of proprietary tools such as Microsoft™ Project is sometimes mistakenly thought of as project management, whereas real project management expertise goes beyond the mere production of Gantt or Pert (Program Evaluation Review Technique) charts, which simply represent project activities in the form of bar charts or flow diagrams. As Mandl-Striegnitz et al. (1998) point out, important project management techniques include estimation of costs and explicit identification of risks. Clearly, there is a need for more in-depth research to gain a better understanding relating to the complex role of project management within the whole IS design and development process. This discussion considers how these problems affect contemporary IS project management research and explores the methodological approaches open to researchers carrying out investigations in this area.
DEVELOPMENT PROJECT MANAGEMENT CAPABILITY OF THE INFRASTRUCTURE PROGRAM. CHERNOBYL CASE
