لطفا منتظر باشید ...
chapter 4. In this section we undertake a qualitative analysis of the same technical and technological factors as presented in the abandonment framework of chapter 3. We are particularly interested in elucidating the nature of these factors and their impact on the different stages of the development life cycle. The dominant factors that comprise the group of sociotechnical factors in abandoned projects listed below are derived from table 3.2:
Unrealistic project goals and objectives
Inappropriate project-team composition
Project management and control problems
Inadequate technical know-how
Problematic technology base/infrastructure
Changing requirements
The two factor elements—unrealistic project goals and objectives, and changing requirements—have been discussed at length and illustrated with specific reference to the five project cases: Confirm, Delta, TSM, DIA's BHS, and CODIS. I do not wish to extend the discussion here except to point out that these two factors are both inextricably linked to the technical and technological directions a project may take. They provide the needed strategic vision and the corrective changes in direction respectively of the project development process from the technical and technological perspectives. Their particular relevance in this context is therefore in helping to formulate the functional specifications at the requirements stage of the life cycle, which will drive the rest of the project's technical development.The factors were collectively described as having a critical impact on the design and implementation stages of the development life cycle, but as having mild critical influence at the requirements stage. Following the format laid out in chapter 4, we will take up the remaining four technical-factor elements, discussing their characteristics and illustrating them with supportive facts culled from the five project cases—Confirm, Delta, TSM, DIA's BHS, and CODIS.
Inappropriate Project-Team Composition
Software projects are inherently team oriented and involve acquisition and sharing of problem-domain knowledge among team members, collaboration and coordination with individual members, and consensus decision making. The organization of the team is fundamental to a successful project outcome because it lays the foundation for the effective and efficient workings of the project group. The composition of the team becomes relevant in structuring the collective responsibilities of the participants to ensure the success of the development effort. Alan Howard (2001) alludes to the "development personalities" of the individual team members as an important factor to consider when putting together a software project team. Similarly, Klein Jiang, and Tesch (2002) discuss the varying professional orientations of the development team members as important to successful project outcome.Team building becomes essential if the individual talents and capabilities of the members are to be molded and transformed into the collective expertise of the team in its thinking and interactions. Project success will largely be influenced to the extent that such team-oriented qualities and characteristics can be made transparent in the work of the team. Who becomes part of the project team is therefore of immense significance. For example, Boehm (1981, 688) describes "personnel attributes and human relations activities" as the two most influential attributes "for improving software productivity." Brooks (1987, 18) makes essentially the same point when he refers to "people" as the "great designers" on whose shoulders rests the "central question" of how to improve software development. In actual software development practice, Curtis et al. (1988, 1284) quote one of the vice presidents of the companies they studied to the effect that "the most important thing you do for a project is selecting staff… . The success of the software development organization is very, very much associated with its ability to recruit good people." We can thus surmise that the caliber of the team members and the contributions each member is expected to make to the project are significant chapter 4, the singular failure of DIA authorities to include the airlines on the team that put together the plans for the airportwide baggage handling system contributed mightily to the frequent design changes requested by the air carriers, which was a source of delays and cost overruns. In addition, lack of structure and organizational purpose to the team's efforts, aggravated by lack of leadership and active interaction among all three stakeholder groups—senior management, technical staff, and users—is likely to lead to problems at later stages of the systems development life cycle, as we will discuss later in this chapter.
Project Management and Control Problems
Software development as a "goal-directed activity" needs to be managed and controlled with the intent of producing the desired artifact within an estimated time frame and budget. The technical dimension of this sociotechnical, purposeful activity requires that some structure be imposed on the development process. There are several variants of the systems development life-cycle model or methodology that are widely available and used in practice in organizations. The recognized advantages of using a phased life-cycle approach to new systems development are to help the project team realize what activities are to be undertaken and what the deliverables for each stage may be, enable different types of communication between the activities of the different stages, and determine whether the deliverables of each stage are satisfactory prior to proceeding to the next stage. These "intellectually demanding" and complex sets of activities are also frequently iterative, further complicating the development process. Still, the phased life-cycle approach has been instrumental in helping to manage and control the development of large software projects successfully. Bad project management practices are often at the heart of software project failure (Glaser 1984).In the Confirm case, the CEO of AMR Corporation, the parent company of AMRIS, is quoted as having stated in a letter to the other three partners that "the individuals to whom we gave responsibility for managing Confirm have proven to be inept. Additionally, they have apparently deliberately concealed a number of important technical and performance problems" (Zellner 1994, 36). The above statements were later retracted by AMR. McPartlin reports that "there never was a coverup, nor had there even been an investigation of a possible cover-up," and that the eight Confirm managers chose to resign en masse after problems were uncovered on the project. However, this view of the events and conditions surrounding Confirm is vigorously disputed by the Marriott Corporation, which alleged in its suit that the eight top AMRIS executives associated with Confirm "were fired for concealing information about the project" (McPartlin 1992, 12) McPartlin further reports that the Marriott suit alleged that "if employees spoke up about problems…they were quickly reassigned." The implication here is that there were attempts within AMRIS to present the most favorable picture regarding the status of the project and that dissenting or less favorable views were perhaps discouraged.This dispute between AMR and the consortium partners with respect to how Confirm was managed is one of the core problems the project faced. It was hard to resolve in the aftermath of the project's demise as each side, perhaps for litigious reasons, tried to blame the other for the project's failure. Notwithstanding the veracity of each side's claims, it is apparent that management's failure to manage the project satisfactorily "created an environment" where the alleged concealment of the activities could have occurred (Ewusi-Mensah 1997, 78). Furthermore, it is worth noting that even if the alleged concealment of the activities on the project did not take place, the IBM review commissioned by AMRIS clearly urged a "more critical review and immediate corrective action by AMRIS management," and stated that neglecting to take these steps would "almost assuredly result in failure" (Zellner 1994, 36). Studies by Curtis, Krasner, and Iscoe (1988, 1284) have correctly asserted that in software development there is a "constant need to share and integrate information." Thus "communication [is] necessary to develop a shared vision of the system's structure and function, and the coordination necessary to support dependencies and manage changes on large systems projects." Unfortunately, this dispute about who concealed what vital information from whom indicates a lack of the information sharing and communication that a project of Confirm's size and magnitude desperately needed in order to succeed.The available literature on the Delta project does not provide us with adequate information with which to assess how the project was managed. In its suit the trustee alleged that Andersen's management of the project was "marred by problems, defects, deficiencies and errors" (LJX files, 1998, 32). For example, the reassignment practices Andersen engaged in—specifically, the "shuffling of Andersen personnel"— "severely disrupted the project," by causing "delays and inferior work product, because various long-term tasks … were not performed and monitored by the same person from beginning to end, or even for substantial periods of time" (LJX files, 1998, 45). Moreover, the added time pressures that came with the acquisition of the UHC contract severely affected the management of the project. Bulkeley (1996, 3) reports that FoxMeyer was unable to reengineer its related business practices to make the software more efficient. The project even "skipped testing some parts of the system where the software hadn't been customized." All of this was done in a misguided effort to save development time. These decisions created problems that contributed to the operational difficulties experienced in warehouses servicing the UHS Consortium (Jesitus 1997). The trustee alleged that it was Andersen's "flawed project management" that contributed to the inventory-discrepancy problems that were at the heart of the SAP conversion (LJX files, 1998, 32, subsection ii). All of this is in contrast to claims Andersen allegedly made prior to gaining the contract, citing "unsurpassed project management techniques to structure and implement and ensure quality control of its work for FoxMeyer" (LJX files, 1998, 22).The TSM systems project presented a far different picture. The GAO alleged in its July 1995 report that almost a decade after TSM was initiated, the IRS had failed to put in place "an effective process for selecting, prioritizing, controlling, and evaluating the progress and performance of major information systems investments" (GAO, 1995, 25). The GAO (1995, 27) further alleged that the IRS "lacked comprehensive decision criteria for controlling and evaluating TSM projects throughout their life cycles." We are therefore left to speculate as to which life-cycle stages the IRS was most vulnerable in in its various TSM systems projects. This failure is contrary to the best practices in the software industry, where organizations typically have in place criteria for evaluating the expected benefits of the systems under development, as well as their potential risks, uncertainties, and estimated costs and times of completion. The software development process at the IRS was described in the GAO report as "chaotic" at times and as "ad hoc." In an environment where about 2,000 people were working in software development, plus several hundred more from outside companies in contractual arrangements, the lack of detailed and repeatable procedures for developing software had a negative impact on the IRS's ability to build the TSM systems economically and on time and to have them perform as intended. At the end of the GAO study, the IRS had begun the process of developing draft criteria to tackle the problems associated with its software development practices. Although the GAO found these efforts commendable, it still considered them insufficient to deal with some of the issues associated with the review of projects for top-management decision-making purposes.The management and control of BHS were assumed by the project management team of DIA, with the manager specifically assigned to handle various DIA structures, such as the people-mover, passengerbridge main landside building complex, airside concourse building, and other structures dealing directly with BAE. However, despite the area manager's extensive experience in construction project control management, it was insufficient to deal with airport construction in general and with baggage system technologies in particular, or even with the introduction of new technologies into the implementation (Montealegre et al. 1996).In addition to the area manager who had responsibility for the BHS project, each concourse had its own manager and a manager for the main terminal as well. The management setup proved unwieldy because of the integrated nature of the BHS, creating an additional bottleneck in the implementation, since BAE was therefore required to consult with each of the senior managers in charge of each concourse in order to resolve each issue. The problem is clearly stated by Gene DiFonso: "The bag system … traversed all of them. If I had to argue a case for right of way, I would have to go to all the managers because I was traversing all four empires" (Montealegre et al. 1996, 11).This sort of arrangement for managing control of the BHS created problems with coordinating the various design changes taking place in each concourse. With the frequent changes to the design being proposed by the user groups of each concourse, it became particularly troublesome to manage the disparate units without a centralized decision maker with the authority to resolve conflicts and make systemwide decisions beneficial to the entire DIA project. With hindsight, it is apparent that this project management approach had a negative impact on the ability of BAE to properly manage and control the large and richly complex BHS project.BHS itself was organized into three main areas—mechanical engineering, industrial control, and software design—for ease of management and control under DiFonso as the project manager. Before the untimely death of Chief Airport Engineer Walter Slinger, the DIA project's cumbersome coordination, control, and management setup did not have a significant effect on the ability of DiFonso to manage BHS, because Slinger was able to use his considerable influence to provide solutions to any ease-of-access problems the BHS project encountered. However, the situation changed significantly when Slinger's deputy, Gail Edmond, took charge. Because Edmond lacked Slinger's influence and was not given the same autonomy and authority he had had, DiFonso was not able to enjoy the same ease of access to work areas as was previously available. DiFonso offers a reason for the disparity: "[Slinger] clearly understood the problem the city was facing [i.e., with respect to BHS in the DIA project] and he understood the short timeframe under which we were operating. He was the one that accepted all of the contractual conditions, all the milestones of the original contract" (Montealegre et al. 1996, 11, 12). In DiFonso's estimation, Slinger's successor did not have the same understanding and authority, and as a result the project suffered various setbacks. He elaborates: "Not only did we not get the unrestricted access that was agreed upon, we didn't even have reasonable access." For instance, barely ten days after Slinger's death, a request for access to Concourse C by a BAE millwright was rebuffed by one of the DIA project contractors working in the area. Similar incidents prevented BAE from gaining access to other work sites.In the CODIS project, the failure to provide any systems development methodology to guide the project resulted in the project being tackled as another systems maintenance problem. The vice president of marketing remarked that "there was no planning developed for the project; no meetings were held to discuss systems development efforts; and the project never moved beyond the level of what we wanted to do and could the computer do it." This view was echoed by another project participant, the vice president of strategic planning: "All we had at the end of the two years was a ‘lot of paper documentation’ to show for our efforts.… The MIS group always talked about the capabilities of the new system as having the ability to do what [the user] wanted [it] to do" (Ewusi-Mensah 1998, 12).The review of project management practices, or lack thereof, attributed to the five project cases underscores the important role management has in ensuring that proper management and control practices are instituted organizationwide and enforced in software development projects. The evidence suggests that it should be the joint responsibility of management and technical staff to come up with a set of metrics and development methodology that can be used to monitor and manage progress on the projects. In particular, mechanisms need to be in place to induce compliance by the technical staff with accepted industry standards for reporting and dealing with problems uncovered in any phase of the development process. The absence of good measurement systems or metrics to gauge and monitor progress on a project will undoubtedly make it very difficult for any organization to identify and correct development problems early, before they blossom into major disasters. Still, management will be well advised to heed Krault and Streeter's (1995, 80) caution that managers should not be "misled by an illusion of control," because technical staff often view "software metric data and status reviews" primarily as instruments used by senior managers with little impact on the day-to-day activities of software development.
Inadequate Technical Know-How
One of the technical dimensions of software development concerns the level of experience and technical know-how of the project team engaged in the development process. The team's technical capabilities and collective expertise must not be underestimated, nor should they be a matter for speculation. This is of fundamental importance to the success or failure of a software project. At the core of a number of failed and abandoned projects are insufficient technical experience and know-how. The fact remains that lack of familiarity with a form of information technology new to the organization is not uncommon in a variety of organizations undertaking a software development project. As the KPMG study (Cole 1995) found, "technology new to the organization" is one of the leading causes of project failures or runaways. It is also one of the major risk factors associated with software projects, as studies by Barki, Rivard, and Talbot (1993, 2001) and Boehm (1991) confirm.In the Confirm case, the experience of the technical personnel was an issue of concern; James Yoakum of Marriott is reported to have alleged that "AMR hired people off the street and proceeded without the right manager running it" (McPartlin 1992, 12). McPartlin further reports that from the start the leader of the Confirm development team "was in over his head." However, the validity of these allegations cannot be independently verified; we are, therefore, left to speculate on their relevance in this context. The intent of these comments may have been to create an overall impression that the project team's experience and leadership were inadequate to take on a project of the size and complexity of chapter 1. Effective coordination of the various subparts is therefore essential for project success, thus introducing another layer of complexity, risk, and uncertainty into the development process. The BHS project illustrates these challenges, because of the coordination difficulties BAE encountered in gaining access to various work sites. Indeed, the role of a competent project leader with "both application–domain knowledge and software knowledge" to guide and coordinate the activities of the various subgroups is vitally critical to the project's success (Krault and Streeter 1995, 69; also see Curtis, Krasner, and Iscoe 1988, for a similar view).
Problematic Technology Base/Infrastructure
Technology infrastructure includes the IT resources of the organization— that is, computer hardware, telecommunications and networking facilities, software tools, software development methodologies, the requisite technical personnel, and so on. The technology infrastructure provides a critical foundation for an organization's new systems development projects. It furnishes the essential physical structure on which the entire systems development effort rests. Any structural weaknesses in the technology are bound to pose a major threat to the viability of the systems development process. Consequently, it is incumbent on the project leadership to be unequivocally certain that the existing technology infrastructure is judged appropriate to the task prior to the start of any major systems development project. Similarly, the senior management of the organization has a responsibility to satisfy itself that the organization's technology base is indeed adequate to the task. "Projects must not be approved for development unless and until senior executives are fully convinced that the organization's technology base is satisfactory to the task. Failure to get that assurance from the IT management unduly increases the risks and uncertainties normally associated with systems development work to an unacceptable level," laying the foundation for potential problems in the projects in the future (Ewusi-Mensah 1997, 77).For the Confirm project, Flowers (1997) provides a schematic representation of the design architecture, illustrated in figure 5.1.
Figure 5.1: Structure of Confirm system. Source: Flowers 1997
The Transaction Management Function (TMF) was to provide the interface to the various classifications of users—Airline Reservation Systems, Hotel Management Systems, Travel Agents, and Others—and to the two IBM mainframe computers. One mainframe computer would run the IBM MVS operating system and would be used to store data on pricing and customers in DB2 databases, together with decision-support system (DSS) data. The other mainframe computer was to use IBM's Transaction Processing Facility (TPF) operating system to process car and hotel reservations using C-language program instructions. The two mainframe computers were to be "connected to each other through a channel-to-channel bridge," as McPartlin (1992, 12) notes. However, the expected communication between the two computers did not work as planned. In addition, there were recovery problems associated with the DB2 relational databases in the event of a system crash.The failure of the database to recover in the event of a crash was attributed, by the vice president of operations for Intrico, to the fact that "in the development of the DB2-based decision support system, the company mistakenly implemented a version of Texas Instruments' [TI] Information Engineering Facility (IEF) computer-aided software engineering tool in which IEF generates its own database structure." The vice president is again reported to have suggested that for Confirm's size, Intrico "should have implemented a version of IEF in which the structure is dictated [because] … the system was so big that what IEF generated would have been impossible to maintain" (Halper 1992, 10).The decision to have a version of TI's IEF CASE tool generate its own database structure was indeed fateful because it became a major contributor to Confirm's failure. The failure should have been anticipated, since AMRIS had never used a CASE tool for that purpose before. It had no prior experience from which to determine if it would work, and in the event of a failure what the likely problems would be and how they might be corrected. As it turned out, the CASE tool did not work as expected and the failure became a basis for severe criticism of the project's management.Another major source of the failure was the inability of TMF to handle the interface problems associated with the two mainframe systems, as well as with the Airline and Hotel reservation systems and the users' and travel agents' terminals connected to the Confirm system. The data overload the system experienced had not been previously tested or simulated to determine if the design could withstand that level of stress. Furthermore, the failure of the DB2 database to recover fully in the event of a crash compounded the problem. The orders-of-magnitude difficulties presented by the size of the project and the distributed system associated with the project should have led AMRIS management to be somewhat more cautious about trying out technologies not yet proven in the organization, or at least technologies with which they had no prior experience. In addition, if the charge that people were "hired off the street" for the project is valid, it further raises some serious questions as to the capacity of the project team to deal with the technology, and their likelihood of success.At the core of the Delta project is a client-server system that was to be installed by Hewlett-Packard, and on which the SAP R/3 software was to be implemented. The client-server system was intended to replace the aging Unisys mainframe computer system on which the FoxMeyer distribution system was implemented. The move to the client-server system was necessitated by the company's business strategy and the anticipated growth in business, which top management envisioned would outstrip the mainframe technology (Jesitus 1997; Bulkeley 1996).The SAP R/3 was originally designed for manufacturers, and FoxMeyer's own independent consultant suggested that it lacked "many features for the wholesale distribution business" because it had never been implemented to run an operation of that nature (Bulkeley 1996, 2). This concern about the software's capacity to handle the huge volume of FoxMeyer's business transactions led the project team first to run simulations to test whether SAP R/3 could handle the 500,000 lines of invoice FoxMeyer generated each day. Unfortunately, the simulations never came close to approximating the level of data involved in a typical operating environment (Bulkeley 1996; Jesitus 1997). In other words, the technology support that FoxMeyer management expected would lead them to create a more cost-effective and efficient operation (with anticipated savings of up to $40 million a year) had no proven record to justify their faith in its viability. The bankruptcy trustee accused Andersen of failing to inform FoxMeyer of SAP's volume limitations, which rendered it "incapable of running the sales distribution/order processing operations at each warehouse" (LJX files, 1998, 38). SAP R/3 had not even been proven capable of handling more than 10,000 lines of invoice a day. It was alleged that Andersen became aware of this fact soon after work on the project began, yet failed to disclose the information to FoxMeyer executives. Furthermore, the technical staff Andersen assigned to the project was alleged to lack the requisite technical expertise and experience.The trustee specifically stated in his suit that Andersen had never "implemented any solution to allow SAP to meet the volume demands" of the company. For example, the allegation stated categorically that none of FoxMeyer's seventeen non-UHC warehouses were ever converted by Andersen to run/operate the SAP system (LJX files, 1998, 40). For an IT project to succeed, both the hardware infrastructure and the software to run on it have to be proven effective and capable of handling the volume of data in a typical operating day in the systems environment. This was not the case in the Delta project.Furthermore, the computerized warehouse developed by Pinnacle Automation to provide "state-of-the-art computerized pickers" was reported to be "so bug-ridden" that it required several extra months of testing. Because the system kept failing and shutting down the conveyor belt additional manpower was required to put the orders together on the right track (Bulkeley 1996, 3). However, Jesitus (1997, 36) reports that Pinnacle accepted responsibility only for "problems of motherboard failure" and placed the bulk of the responsibility for the systems failure on the existing Unisys-based system. Pinnacle believed that integrating the Unisys-based system with SAP R/3 failed to give the Pinnacleinstalled computerized pickers the right information in a timely manner (Jesitus 1997). Changes in the original design specifications requested by FoxMeyer after the project had been started were also fingered as contributing to the overall problems of the systems failure. For example, one of Pinnacle's executives claimed that "we were told to design a system that could ship in X number of hours, and we designed a system that could do that. Then, later, it became a requirement that they be able to ship in one-third to one-half that time" (Jesitus 1997, 36). These are some of the factors that contributed to the project's failure.The GAO (1995) report on TSM found a number of deficiencies with respect to TSM technical activities. There was, for example, nonexistent systems architecture for TSM, and there were no defined interfaces and standards to ensure that TSM components would successfully integrate and interoperate. In fairness, GAO also found ongoing work on an integrated systems architecture for TSM, but it considered that to be of limited value since work on TSM was already in progress. In a Computer World article on Hank Philcox, then chief information officer for the IRS, Anthes (1996b, 28) writes that "the IRS computer systems were on the verge of collapse" in 1986 when Philcox took charge of TSM. Anthes also comments on Philcox's response to criticisms that the TSM project had "wasted $2.5 billion," claiming that they had made substantial progress and built an infrastructure where before "underpowered mainframes and inefficient software took five days to do ‘weekend’ file updates." By 1990 the improvements in infrastructure— "automation plus the network"—were credited with having reduced processing delays and manual effort in IRS operations. The productivity increases were such that a net of 4,000 clerical positions was eliminated.The BHS project ran into severe problems as a consequence of several factors, which included lack of adequate infrastructure. Because the plans for the baggage handling system were drawn up rather late, insufficient consideration was given to some of the critical underlying infrastructure features needed for a baggage system. As DiFonso explained later, the city severely underplayed "the importance and significance of some of the requirements of a baggage system, that is arranging things for the space into which [the system] must fit, accommodating the weight it may impose on the building structure, the power it requires to run, and the ventilation and air conditioning that may be necessary to dissipate the heat it generates" (Montealegre et al. 1996, 10).Whether the above-cited complaints can be explained away as the consequence of the BHS specifications being put together by airport planners and consultants, perhaps with limited knowledge and understanding of the type of infrastructure provisions that needed to be made for the BHS project, is unclear. Although time pressures constrained the work of BAE on the BHS project, the failure of the city to include any organization or persons with expertise and experience in baggage handling systems in the development of the BHS specifications was a critical omission that had severe repercussions for the project's outcome. Another major infrastructure issue was that of securing a smooth power supply for the project. According to BAE's DiFonso, the city of Denver had a problem supplying "clean" electricity to the baggage system. This created its own set of problems for the BHS project because of the extreme sensitivity of the motors and circuitry to power surges and fluctuations (Montealegre et al. 1996). Attempts made to resolve this problem became lost in a tangle of bureaucracy, which resulted in further delays on the project since the filters required to handle the current fluctuations were not received until March 1994—the second date for the scheduled opening of the airport. It is amply clear in this case that the lack of available infrastructure, including a smooth power supply for the BHS project, was a major factor in the problems BAE encountered in attempting to complete the project under the tight schedule.The CODIS project was in an even more precarious position with respect to its technology infrastructure. The new vice president of MIS, hired to manage the MIS department, described what he found when he joined the company as follows: "The mainframe computer had reached its capacity; they were running three different operating systems, none of which was current; there was no documentation for the application programs which were 15–17 years old; there was a proliferation of PCs with end-users actively involved in finding ‘PC kinds of solutions’ to their problems without any input from the MIS department; IS personnel were not up-to-date on technology, they were preoccupied with maintenance and enhancements to the existing applications," among a host of other problems (Ewusi-Mensah 1992, 8).The above cases collectively convey a stark picture of projects lacking the technology infrastructure to serve as a foundation prior to their onset. All the projects experienced difficulties that may be partly attributable to deficiencies in the existing technology base and/or physical infrastructure. It is conceivable, though highly unlikely because of other factors, that the projects could have succeeded had these infrastructure deficiencies been dealt with appropriately prior to the start of the projects. That the projects were allowed to proceed in spite of the weak technology bases speaks unfavorably about the failure of technical and managerial leadership in the respective organizations. Therefore, it is not surprising that management problems are often cited in studies of software failures, runaways, and abandonment as being among the leading causes (see, for example, Ewusi-Mensah 1997; Cole 1995; Standish Group 1995; Johnson 1995).
