Software Development Failures [Electronic resources] : Anatomy of Abandoned Projects نسخه متنی

How to Minimize Project Cancellations

As intimated previously, the pattern that emerges from a synthesis of the data from my research and that of others is quite clear: software/IS project cancellation is a multidimensional or multifaceted issue with numerous and/or various interacting parts. There are, however, steps executives can take with respect to project selection and management in their organizations to minimize the likelihood of a project cancellation decision. To ensure successful development of software/IS projects, senior executives should be prepared to take specific steps to guide the process, and when all else fails, they should be ready to cut the organization's losses on the project by terminating it. In the five cases discussed in the book, I have focused on the factors that contributed to the decision to terminate or substantially limit the scope of the projects. My intention was to highlight the significance of the issues raised by the factors in order to instruct senior executives and project leaders on the pitfalls and other telltale signs to watch out for in the design, development, and management of large, complex software/IS projects. I now discuss the specific guidelines executives and/or project leaders can adopt in managing projects to minimize the threat of project cancellations by drawing attention to the key issues in project development that are critical to success.

Project Goals and Objectives

The first critical issue is to have general agreement on a well-articulated set of project goals and objectives. Without a consensus on what the project is expected to achieve in satisfying the specific information requirements the company has identified, the development effort may revolve around a vague and immeasurable set of systems requirements. In a field study of large software systems, Curtis, Krasner, and Iscoe (1988, 1275) have determined that "fluctuations or conflict among systems requirements caused problems on every large project." They attribute the problem partly to "incomplete analysis of requirements" and/or lack of sufficient application-domain knowledge on the part of the analysts. They further argue that, at the project level, unstable requirements "usually resulted from the absence of a defined mission, leading them to state that "without a sense of mission the motivation for the project could not be translated into clear product requirements." These findings are echoed by Krault and Streeter (1995), who describe the problem under the general rubric of software complexity and uncertainty. It is clear that reaching a consensus on the goals and objectives of the project is paramount in providing an agreed-on basis on which the requirements can be developed. Thus one major contributor in the problem of creeping or fluctuating requirements may be controlled if not eliminated. This, in turn, will contribute to ease of communication among the team members in describing the essence of the problem complexity and the systems requirements to be satisfied.

In addition, sponsorship of the project should, as far as possible, be broadly based. Research data suggest that projects that enjoy broader support from other managers or are more consensus based tend to avoid the common pitfalls that characterize canceled projects (Ewusi-Mensah and Przasnyski 1991). Curtis, Krasner, and Iscoe. (1988, 1277) have reached a similar conclusion; they report that "for projects started for political reasons requirements fluctuated with the prevailing attitudes of those who approved funds." The consensus-based projects are better able to withstand the changing fortunes of organizational politics and their effects on project goals and requirements.

This is not to suggest that projects associated with one manager or sponsor should be taken less seriously than usual. On the contrary, sponsors of such projects should be compelled or encouraged to sell the merits of the project to other senior colleagues in other organizational units as well as to subordinates within their own organizational unit. In other words, it is important to build a supportive base in the organization for such a project so that in the event of the original sponsor's departure, the project will not risk cancellation because of the lack of internal organizational support.

Project Team

The composition of the project team must be another issue of concern to executives overseeing systems development efforts. Inasmuch as it is beneficial to have broad-based support for and agreement on the goals of the project, it is equally essential that the team members be drawn chapter 7; in each, members of the various orientation groups on the development team play representative roles. In fact, the length of time that a team is reported to spend in the requirements phase of the project is partly dependent on "the breadth and depth of knowledge the team members bring to the project" (Waltz, Elam, and Curtis 1993, 69). Consequently, one must be selective in deciding on the composition of the team to facilitate the project development efforts and help contain the cost of the project.

Project Leadership

Project leadership is another important issue executives need to resolve early on in the development process. Executives need to appoint someone who is widely respected in the organization and has sufficient knowledge, credibility, integrity, and technical experience to lead the project. As Krault and Streeter (1995) succinctly argued, large projects are more likely to succeed if they are led by individuals who have a clear understanding of the application-domains and have the requisite software knowledge to guide and coordinate the efforts of the project teams. Although such individuals may be difficult to identify, their impact on projects cannot be underestimated. The diverse issues that a project leader may be required to address include, for example, "resolving conflicting requirements, negotiating with the customer, ensuring that the development staff shares a consistent understanding of the design, and providing communications between … contending groups" (Curtis, Krasner, and Iscoe 1988, 1284).

Thus a respected project team leader with the backing of senior management and the authority to make critical decisions is an important signal to the rest of the team about management's commitment to the success of the project. The project leader must be required to report on a regular basis to senior executives on the progress of the project; on specific problems encountered in the course of the project such as budget overruns, schedule delays, or changes in the scope of the problem; and on the credible steps being taken to resolve those problems in order to bring the project into compliance with the expected results. As noted, one of the responsibilities of the project leader is to maintain the right balance among the three elements—resources, features, and schedule—that constitute the project triangle. It is the responsibility of the project leader to ensure that requirements changes resulting in additional and/or revised systems functionalities are properly factored into the revised resource needs and schedule modifications. When the requirements changes are significant, the project leader must request additional resources and make revisions to the schedule to reflect the overall changes in the project development. The project leader must constantly work to control the requirements changes and whenever feasible, use flexible design architecture to minimize the extent of resource and schedule changes resulting from volatility in the requirements.

Active Involvement of Executives

Executive involvement in the project should be perceived throughout the organization as active rather than passive. This will convince the team members of the commitment of top management to the project's success. Such an impression will in turn elicit an equally significant commitment to the project from the team, which recognizes that success on the project will reflect favorably on them and will probably advance their careers within the organization. Another beneficial side of the issue is that executives will become aware much sooner than usual if the project is experiencing any difficulties, which, if not resolved appropriately and quickly, can lead to problems later on. Such valuable project information obtained on a timely basis will enable executives to take the steps needed to resolve the problems, but failing that, to move quickly to extricate the organization from the project and minimize the organization's losses. It is especially important that executives guard against the problem of overcommitting organizational resources to failing projects. Specifically, active involvement of executives in the life of the project entails undertaking key steps with regard to project management and control.

Project Management and Control

A number of related issues—for example, project reviews, project audits, technical experience, and form of executive involvement—fall into this category and thus will be discussed separately as follows.

Project Reviews Project review meetings must be held frequently with the project leadership and must cover all aspects of the project, from technology-related issues to project economics (i.e., costs and completion schedule) and organizational issues. The evidence suggests that organizational politics and/or disagreements tend to dominate decisions on software project cancellation, and so it may be prudent for executives to pay particular attention to the organizational behavioral issues involved in the project selection or approval and development processes (Ewusi-Mensah and Przasnyski 1991, 1994). Behavioral processes, as Curtis, Krasner, and Iscoe (1988) point out, can also be at the root of problems preventing us from gaining greater understanding of the factors that influence project development success.

Project Audits It is useful to distinguish between project reviews and audits. Projects must be reviewed regularly to determine if sufficient progress is being made toward their stated goals and objectives, and within the prescribed time frame. Project audits must be conducted by outsiders, either internal or external to the organization and to its project team, to verify the work of the project management with respect to the results of the project reviews. Unlike project reviews, audits can be infrequent and can be conducted whenever senior management feel they are warranted. Resistance to project audits may suggest hidden problems with the project that should immediately raise some concerns with senior management. The auditor(s) selected must be technically capable, credible, and unbiased toward either senior management or the development team; any questions about their integrity will rightly raise doubts or questions about their findings.

Technical Experience The technical skills, knowledge, and experience, in conjunction with the relevant application-domain knowledge, and the general competence of the technical staff should be another concern requiring executive involvement. Executives need to be fully convinced of the capabilities of the in-house technical staff to tackle the project successfully. Whenever their assessment of the situation raises doubts, it is wise to seek outside assistance from technically competent companies that specialize in the kind of systems development effort being undertaken. In this regard, employing the services of outside consultants to supplement in-house expertise can be beneficial to the project team. However, the process by which consultants are chosen should be carefully scrutinized to ensure that the organization ends up with precisely the help it needs. Also, where the company's competitive position will not be compromised, it will be all right to seek advice from other colleagues in the industry as to how to undertake a project of that magnitude and significance.

Form of Executive Involvement Executive involvement in the project should not only be restricted to the regularly scheduled review meetings with the project leader. From time to time executives should arrange to meet with as many of the project team members as possible, for the following purposes: to convince and reassure the team of the company's continued commitment to the project and of the value the executives place on the work the team is doing; to find out firsthand from the various members of the team what, if any, specific problems are being encountered and what the executives can do to help move the project along successfully; and to open up a dialogue with the team so that in the event that the project leader is less than forthcoming, the executives will have a chance to learn directly from the team members how the project is progressing.

Despite their possible lack of technical background, executives should resist the tendency to defer every major decision on the project to the project leader or the technical people. In fact, if necessary, consultants can be brought in to review the work of the project team and report their findings to management, as was done in the case of the Confirm project. The upshot of all this is to make executives well informed on the progress of the project and to enable them to stay on top of the "small" problems that might otherwise mushroom into the bigger issues which end up destroying projects.

Technology Base/Infrastructure

Equally important to the success of the software project is the technology infrastructure in the organization prior to the start of the project. Having the necessary technology in-house indicates that the organization most likely has the in-house expertise and experience to use it appropriately in the project development. Of course, for some projects the existing in-house technology may not be adequate, making it necessary to acquire new or additional technology to fill the identified need. In such an instance, a careful assessment needs to be made to ensure that the inhouse technical expertise and experience will be up to the challenge. In addition, sufficient time must be factored into the prospective project schedule to give the project team members time to learn and work with the technology prior to having to use it in the project. All these technology-related factors must be fully vetted by senior management in consultation with the project or IT leadership before a final decision is made to proceed with the development. Failure to consider all these technology-related factors may be laying the foundation for the eventual collapse of the project. In this respect Confirm, FoxMeyer's Delta, and DIA's BHS projects are classic examples.

User Involvement

The project leadership and senior management should seek the active involvement of a diverse group of users as participants in the requirements definition and design stages of the development process. Whenever such participation is visibly absent, senior executives should act swiftly to determine the basis for this and take corrective action to restore the link. The level and frequency of interaction between the user groups and the technical personnel should be high, almost day-to-day, especially in the early, critical conceptual stages of analysis and design, in order to clarify the varied issues that are bound to crop up in the course of the project. The objective is to foster an environment in which cooperation, communication, learning, and an exchange of views on the technical capabilities of the system vis--vis the users' expectations and the information needs are a significant part.

On the other hand, the frequency of interaction and communication between the users and senior management involved in the project need not be as high as between the users and the technical personnel. This level of interaction must not be viewed as an end run to bypass the project leadership to obtain information, but rather as another independent source of information senior management can take advantage of to gain access to differing views, which may otherwise elude them, on the project development. Nonetheless, this interaction is critical to successful project development for conveying the level of senior management commitment to and interest in the successful outcome of the development process to both the users and technical groups. When the level of interaction and communication is judged satisfactory by all three stakeholder groups, the likelihood of project success may be significantly increased. User involvement in software development projects is a necessary but not a sufficient criterion for project development success. There is still a significant risk of project failure or abandonment if there is no active involvement from the technical personnel and from senior management, as was the case in CODIS.

Cost of Project

Escalating project cost is often cited as one of the reasons for project cancellation. Executives, therefore, need to be fully apprised as to how the funds appropriated for the systems development are being spent. The development cost of a project tends to increase over time and reaches a peak at the coding and testing stage. Research has shown that the cost of corrective design errors tends to increase dramatically the later in the development process such errors are detected because so much rework and retesting are required. Thus to rein in the overall cost of the project development, executives need to take steps to ensure that work done in the critical early stages of analysis and design, in particular, fulfill all expectations and meet the highest standards. Executives should also do all they can to minimize the problem of "creeping, fluctuating or conflicting" requirements specifications, which can contribute substantially to escalating project development costs.

Schedule Delays

Executives should also resist the temptation to add more people to the project team if the project begins to experience schedule delays. Brooks's ([1975] 1995) admonition of "the mythical man-month" should be taken seriously here because the more people that are added to the project, especially in the later stages, the more likely the project is to fall further behind schedule, notwithstanding Abdel-Hamid and Madnick's (1990) contrary claim, because of the communication delays and the learning curve necessary to bring those new participants up to the current project staff's level of knowledge. It is, therefore, necessary that estimates of the technical staff required to do the job be carefully reviewed for accuracy, taking into consideration possible emergencies (like illness), the learning necessary among team members especially in the requirements phase, and other issues that if left out create a far rosier picture of the project's human resource requirements and completion schedule than is warranted. In addition, those involved should be the most capable in the company of tackling the project; when this is not possible, outside assistance should be sought to augment the in-house capability.