Mitigating/Preventing IS Project Failure

INTRODUCTION

Information systems (IS) software projects must be considered as risky undertakings.

The very nature of software contributes to this riskiness in that it consists of intellectual concepts without physical substance.

describes software, the output of the project, as " pure thought-stuff, infinitely malleable" and " invisible and unvisualizable." The effects of these risky characteristics are manifest in the frequent reports of IS projects that are late and over budget. Furthermore, many systems don’t meet the needs of the business when they are delivered and have a low user satisfaction rating. This set of truisms seems to surround information systems projects. A Standish Group study found that over 50 percent of IS projects were late or over budget.

This was estimated to amount to $63 billion in cost overruns and another $91 billion in canceled software projects. The ultimate extension of the late and over-budget condition occurs when projects become victims of escalation - the condition of continuing, even increasing, expenditure on a project that to the onlooker is clearly a failure.

Why does this happen and what, if anything, can managers do about it? This Section develops a behavioral model and concomitant strategies that include strategies for executives and user managers that are as fundamental to IS project success as are the strategies for IS project managers. In addition, a particular case is discussed that has already been published and discussed elsewhere to illustrate how these strategies can be used to identify where, and why, an IS project is going off track and how these strategies might be used to avoid IS project failure.

RISKS and RESPONSIBILITIES

IS project failure is not a new problem. It has existed since information systems moved beyond simple automation. Historically, the responsibility for IS project failure has been laid squarely on the shoulders of the IS project manager. The project is defined and the IS project manager is charged with the responsibility of delivering a system that meets the requirements, is on time, and is on budget. This Section shows how reality may be somewhat more complex. Developing strategies for IS project managers alone is insufficient and requires moving beyond the typical IS-centric view of the traditional literature.

Traditionally, in books and articles, IS project managers have been advised to follow a structured approach to managing risk: identify individual risks, assess their impact, and develop coping strategies for each risk. However, as is shown later in this Section, this approach rapidly becomes completely unwieldy as the number of risks to be managed increases. Therefore, the authors break with this tradition by showing that risks can be classified into four major types according to their sources, and then managed by dealing with the sources rather than with the individual risks. This approach yields strategies that are manageable as opposed to the unwieldiness of trying to contain each risk individually.

What Is Meant by Risk

Before proceeding any further in this exploration it’s necessary to discuss what is meant by risk in the context of this Section. In the management domain, risk is defined as negative outcome and the size of the risk is the loss incurred if the outcome should occur. Positive outcomes are not seen as risk. Thus, in management terms, there are upside potential and downside risk. Furthermore, managers differentiate between risk-taking and gambling. Gambling is seen as accepting the odds - passive management - whereas risk-taking is seen as managing the odds to achieve a favorable outcome.

This Section uses this management definition of risk, and all of the following discussions are framed by this definition.

That a risk may have a low probability of occurrence does not negate the need to manage it at some level. If an event occurs that causes the derailment of a project, that event is a risk prior to its occurrence. Such an event is frequently unforeseen -- an unrecognized risk. Had it been foreseen, it would have been treated as a risk to be managed. An unforeseen risk is like an invisible " sword of Damocles" waiting to fall upon the unwary, hence the literature' s emphasis on the identification of risk.

Identifying the risk and then managing it does not make this sword go away, it merely postpones its falling, preferably forever. From this perspective, the purpose of managing a given risk is to defer indefinitely the occurrence of the undesired outcome. Thus, management of a risk is continuous. For example, obtaining top management commitment to a project, a condition regarded as essential by many, even beyond IS project literature, may not be sufficient. The risk always exists that the project manager will lose that top management support for one reason or another. To manage this risk requires that the project manager work actively to maintain the support. The risk outcome is defined as occurring if the project manager loses that support. Once the project manager has reestablished top management support, the potential of losing it becomes a risk once again. This is but one risk of many to be managed.

In getting to the roots of IS project risk, new dimensions of risks are disclosed beyond those usually considered to be the responsibility of the project manager.

These new dimensions also impinge upon the responsibilities of the investing executive. Although some project risks are under the control of the IS project manager, others are only partially, or not at all, under his or her control. If the investment is to be adequately protected and the expected outcomes achieved, management of these shared risks must be a joint responsibility of the investing manager, user management, and the IS management. Thus, even though the proposals in this Section are derived from a study of IS project managers, the implications are as important to non-IS managers as they are to the IS community.

Prior Approaches: Individual Risk

In the literature on IS project failure and the management of risks, there are two approaches to achieving IS project success. Both these approaches seek to establish discrete risk elements to be separately managed. One of the approaches recommends managing IS project risks through the identification and control of individual risk items, the risk management approach. A second approach is based on contingency theory: project success is contingent upon the presence of some set of factors. The second approach is predominant in the IS implementation literature.

Several distinctions can be drawn between these two approaches. First, it can be argued that the contingency factors are framed as positive elements that affect the success of a project, whereas risk factors are framed as negative elements that cause failure. These two streams can be further differentiated in that the stream dealing with contingency factors represents a static view of projects, with the implicit assumption that once a factor is present (e.g., top management support) it remains present. In contrast, the risk management perspective represents a more dynamic view, suggesting that risk factors (e.g., the possibility of a lack of top management support) represent a constant threat and must be managed actively for the entire duration of the project and thus lends itself to the discussion of management processes and strategies more than do event-based contingency factors. The remaining discussion is built upon the ideas of managing risk. A number of authors have sought to propose ways of managing IS project risk.

Anecdotal prescriptions have been offered but, like many such prescriptions, they smack somewhat of the " silver bullet."

However, one thing these authors have in common is their suggestion that if risk is to be managed, it must first be identified.

In prior literature, the management strategy proposed has been to develop checklists of risks and then to manage each risk as a distinct entity. However, complex projects may have many risks, and managing such a multiplicity of risks, some undefined or unrecognized, as unique items on a checklist is impractical.

Managers need a means of reducing long checklists to some manageable form without discarding any of the risk items. A possible solution to this problem is now discussed.

Proposed Approach: Categorizing Risk

In contrast to prior approaches, the authors propose an integrative approach that enables risks to be consolidated into categories. Each category requires a different managerial behavior together with concomitant risk mitigation strategies. Using this integrative approach, risk becomes more manageable and managers need not concern themselves with failing to identify every risk item or contingency factor.

This new model of an IS project is grounded in the data from a study of IS project risk undertaken by the authors. In this study, 41 experienced, practicing IS project managers defined, and reached consensus on, a list of 53 risk items. A detailed description of the study that developed this risk list is found elsewhere.

The approach taken to developing the model in Exhibit 1 was to look for patterns in the risk items in the above-mentioned study that show some risks as being similar to each other but different from other risks. In developing mitigation strategies for managers, the patterns sought were those that indicated differing behavioral perspectives. The process of pattern recognition was through repeated inspection of the data from the above study.

Ex. 1. A Risk Categorization and Behavior Model

The first pattern to emerge from this inspection process was that some of the risk items were totally under the control of the project manager and others were not. The resulting division is characterized as Inside and Outside risks (i.e., risks totally within the project manager' s purview, or risks outside that purview). However, there was still considerable variation amongst the risks within each group. Further inspection resulted in the recognition of two subgroups of Inside risks which are called Task and Self, and two subgroups of Outside risks that are called Client and Environment.

The Task classification refers to those risks that were the subject to the active direction of the IS project manager (e.g., Poor team relationships). These are the risk management elements typically found in the classic project management literature. The risks in the Self category reflect the characteristics of the project manager himself or herself, and are related to the understanding and capability of the project manager (e.g., Lack of effective project management skills).

The risks classified as Client are risks that cannot be controlled by the project manager but are risks over which the project manager may exert some influence (e.g., Failure to manage end user expectations). The Environment risks are external to the project and can be neither controlled nor influenced by the project manager (e.g., Unstable corporate environment).

Because the risks thus identified are from the project manager' s perspective, the different classes can be linked to the project manager views, as shown in Exhibit 1.

Each of the 53 risk items from the study was segmented into one of these four categories. It should be noted that the categories into which the risks have been put are a result of the authors' perspectives based on their own project management experiences. The results of this categorization are shown in Exhibit 2.

Ex 2. Categorized Risk Items

As may be seen from Exhibit 2, there is homogeneity within each category and difference between categories. However, there may be some borderline cases in which the reader feels that a particular risk may belong in another category. We believe this to be appropriate in that some risks may have a contextual element. For example, it may be that in one project, a risk such as Bad estimation may be classified as Self and in another, Task. Bad estimation as a result of no estimating methodology could be seen as falling in the Self category. On the other hand, where an estimating methodology exists but is poorly executed, this risk could belong in the Task category. The purpose of the model is to develop mitigation strategies relevant to the category rather than to each individual risk in isolation. Thus the risk will be managed in accordance with the category in which it falls within a given context.

However, such contextual capabilities within the model may add to its applicability in both the general and the specific case, because any so-called borderline risk will be subsumed into a category and managed according to the strategy relevant to that category.

BEHAVIORS and STRATEGIES

Given the links between the four risk classes and the project manager, it’s appropriate to now explore the possibility of differing behaviors being required of the project manager in dealing with each of the four categories. The following section proposes a set of behaviors appropriate to each link. Each of these links has been named in Ex 1 to capture the associated behaviors.

Self Assessment

The link between project manager and the class of risks called Self suggests a behavior that can be called Assess. Because the risks in the Self category concern the project manager' s abilities, capabilities, and knowledge regarding the management of IS projects (e.g., Lack of project management skills), the project manager needs to continually assess her capabilities against the project needs. The project manager can then handle any recognized shortfall in capability herself.

Assessment also may need to be done by others – E.g., the project manager' s manager or outside auditors - to identify any shortfalls not recognized by the project manager herself. The Assess behavior requires of the project manager that she periodically ask questions of herself that are aimed at surfacing the risks in the Self category. Unfortunately, it’s difficult to get an accurate answer when people ask themselves such questions as " Am I managing change properly?" " Do I lack effective project management skills?" " Do I lack an effective project management methodology?" Yet these are the first three risk items in the Self category shown in Exhibit 2. The same problem exists for each of the risk items when phrased by individuals as a question of themselves. Nonetheless, a project manager must ask these questions of herself and answer to the best of her ability. However, there are strategies that can make a project manager more effective in answering these questions. One way is to use independent auditors. This is a viable proposition where there are knowledgeable experienced project managers in-house who can execute an unbiased audit. A second form of audit is to use assessment mechanisms such as those offered by the Software Engineering Institute and its Process Maturity Model.

A third way of handling these questions is for the project manager to benchmark other projects and other organizations to compare and learn. These three different, but complementary, strategies may greatly enhance the project manager' s ability to exercise the Assess behavior.

Task Control

The risk factors classified as Task (e.g., Insufficient/inappropriate staffing) imply a Control behavior by the project manager in dealing with the risks. It’s the task of the project manager to take care of these, thus calling for a task management approach. It’s generally this behavioral link that is the subject of project management texts and education and should be ingrained in any experienced project manager. Thus, Assess and Control describe the behaviors required of project managers in handling inside risks. Now, the outside risks need to be addressed.

Environmental Monitoring

The risks that fall under the environment class are those about which the project manager can do little. Some risk items might even be granted the sobriquet " Act of God." However, should an event represented by such a risk occur, the project manager needs to maximize her lead-time to react. The other type of environmental risk is rooted in the industry environment, competition, and government action.

These types of risk require that the project manager be cognizant of them even if she can do nothing to prevent their occurrence. Thus we suggest the behavior Monitor to represent keeping abreast of the environmental risks in order to maximize the possibilities for response. The monitor behavior is relatively straightforward.

Unfortunately, it can also be time consuming. Under the Environment risks () we see those things that relate to the industry, the company, and the company' s position in the industry. This monitoring responsibility requires the project manager to be knowledgeable about what is going on " out there" and how it might affect the company and hence the project. E.g., the IS project manager should be aware of the potential of a corporate takeover, assess possible impacts, and establish strategies to deal with those impacts. One way of gaining this knowledge is to read the industry trade press rather than the computer trade press.

Industry conferences are another excellent source of monitoring information. Many companies have internal industry and marketing seminars. If a project manager can understand the product and market from the perspective of the company' s own marketing force, it will enhance the project managers understanding of the environment at large.

Client Relationships

Relate is the behavior required to handle that category of risks denoted Client. The Client project risks are those associated with the people internal to the company with whom the project manager deals. These are the people who are essential to the successful outcome of the project. They are also the people who define what constitutes a successful outcome. It’s essential that the project manager establish relationships with these individuals and groups, preferably before the project is initiated.

The term Client is used here advisedly. It encompasses that group of people who fund, as well as that group who will use, the system and, therefore, such groups may be defined as the project manager' s market. A key marketing philosophy propounded by both practitioners and academics is that of Relationship Marketing, or Relationship Management. This philosophy espouses building and maintaining long-term relationships with clients (customers) regardless of any current sales activity. In other words, the sale is made within the relationship, as opposed to the traditional approach of building the relationship around the sale. For a particular project, top management commitment and user involvement are easier to obtain if there has been a strong relationship between the parties built up over time.

It’s not the purpose of this Section to describe relationship marketing and relationship management; there is a wealth of material available elsewhere. The important lesson for project managers is to realize that marketing themselves and their departments in the context of long-term relationships is a fundamental responsibility of IS management. It’s equally important that the client community also subscribes to building strong relationships with IS management.

The activities discussed under Monitor now acquire an additional role. To establish this relationship with a group (e.g., top management), the project manager must demonstrate an interest in, and knowledge of, those things that interest the group.

Monitoring will provide the project manager with the initial knowledge to gain access to each group that constitutes a target market. The relationship can be enhanced by information sharing and establishing bonds of common interests. However, this act of sharing is not solely the responsibility of the project manager. It requires the active participation of the investing executives, as well as the user management, to ensure that the IS project manager is fully cognizant of the effects that the changing environment is having on the organization as a whole, and the resulting potential impacts on the needs the system is supposed to fulfill. Clients may also be considered to have different levels of sponsorship of the project.

In many studies, failure to gain top management commitment is seen as a key determinant of project failure. Top management commitment represents the active sponsorship of the project. This notion of sponsorship however, extends beyond top management. It’s needed throughout the ranks of management and users affected by the project. It’s here that the IS project manager can look to the sponsorship strategies and processes of sponsor-dependent sports such as motor racing, events such as the Olympic Games, or sponsor-dependent organizations in the arts. These organizations must actively seek sponsors and continuously work at maintaining that sponsorship. The IS project manager must do the same.

To many, the strategies outlined may seem obvious but, obvious or not, they don’t seem to get executed effectively. As a case in point, consider now Smith' s dilemma, using the proposed model as a vehicle for discussion.

SMITH'S DILEMMA

A brief synopsis of the case follows. In this case, a CIO, Smith, has " fulfilled to the letter the role of CIO that Smith [CEO and president] had described."

In particular, for our analysis, Smith was charged with developing an information system called Lifexpress that was supposed to provide the company' s insurance agents with a competitive advantage. The system took three years to develop and is being rolled out at the time of the case. Unfortunately, the company' s competitors have launched similar systems. Moreover, these competitor systems seem to be better than Lifexpress. Thus, the multi-million dollar system won’t have the hoped-for impact, which is a great concern to the company' s executives. " To Smith' s distress, her boss was clearly trying to hold her accountable for more than the creation and implementation of the system - he was putting her on the hook for the results of the system, too." The case further notes: " She had delivered the system on time and on budget, and had met all the specifications that Jones and the other senior managers had agreed to." Smith had been trying to explain to her boss what she could control and what she could not. This merely resulted in her boss' s becoming impatient. Jones tells Smith: " We have to figure out how to get this thing fixed and back on track fast. We' re losing a lot of momentum. I don' t think you have kept us properly informed." Here we have a case of a project manager delivering on what she thought were her commitments and yet the project is clearly falling into the "failing" category. Smith has done an excellent job of risk management within the traditional confines of IS project management. She has delivered a project according to her " contract." It met the agreed specifications for the agreed price and the agreed schedule and yet it is, for all intents and purposes, a waste of money. After all the time and expense, the system does not meet the needs of the business. Perhaps the first thing to note is that Smith was trying to establish that there were things over which she had control and things over which she did not. In the proposed model, the things over which she had control are have described as Task (e.g., schedule, budget, process, and technology). She exercised the appropriate behavior: control. Now, consider Smith' s behavior regarding Self, the other Inside risk category.

Smith is described as " wondering how she could begin to separate what she was responsible for from she wasn't (sic)." On the one hand, Smith wishes to be evaluated only on that which she can control, and on the other, her management wants her to take responsibility for the project' s outcome. Furthermore, she failed to understand the true requirements of the project. She understood the technical requirements as described to her three years ago, but failed to realize that the real requirement was for a " first-to-market" system that would give the company' s agents a competitive advantage over all other agents of all other companies. These characteristics, responsibility and misunderstanding the requirements, fall into the category Self. The act of " wondering" to which the case refers is an example of Assess behavior. It’s only now that she is becoming aware of the Self that is needed.

It’s only at this point that she is becoming aware of the true requirements. Lack of the proper assessment behavior has put both the project and her career in jeopardy.

The model uses two other risk categories: Client and Environment. Had Smith been properly monitoring the Environment, she would have been cognizant of the activities of the competition. She would have known how the competition was forcing changes to the scope and objectives of the project. Again, failure to monitor the environment and act accordingly placed the project at risk.

Finally, there is the client category of risk. Here is a case that had top management commitment, but the project still failed in the eyes of senior management. The case tells us that Smith started with a good relationship with Jones, the CEO. He had high hopes for her. The case also tells us she obtained an initial management commitment to Lifexpress. It appears she then reverted to focusing on task risks, the ones she could control. In so doing, she ignored maintaining, and further strengthening, her relationships with her clients, the company executives. As a result, executive concerns, even displeasure, come as a complete surprise to her. Had she exhibited relationship management behavior, she would not have been surprised and the executives would not have been surprised. In fact, she probably could have delivered a successful project in the first place, because she would have had executive guidance as to evolving needs, and furthermore, she could have managed client expectations of what could be delivered and when. Failure to actively seek and maintain sponsorship from her client community was a major contributor to her failure. Smith managed this project correctly, given the traditional approach of limiting project management to the elements she could control. These are the task-centered items that project managers learn to manage in project management classes and literature. However, once it becomes clear that the expectation of Smith is that she must be responsible for the outcome of the project, the scope of what it means to be an IS project manager becomes larger and much more complex. Smith' s management lexicon had limited her to identifying only one category of risk and thus exhibiting a single behavior. As discussed, exhibiting the other three behaviors might have enabled her to achieve the desired outcome.

The fault is not entirely Smith' s, however. Some of the blame must go to Jones.

Jones abdicated his responsibility in that he never checked that the system being developed by Smith would meet his company' s changing needs. He never took it upon himself to keep Smith abreast of the changing environment and changing needs. Similarly, Smith' s boss " was clearly trying to hold her accountable for more than the creation and implementation of the system - he was putting her on the hook for the results of the system, too." In so doing, he was raising Smith' s awareness of the risks in the Self category. This raising of awareness should have been done at the beginning of the project and should have been regularly assessed throughout the duration of the project. It’s too late now to tell Smith that she failed to assess, and manage, these risks. Thus, the behavior of her executives contributed to Smith' s project failure.

CATEGORIZED RISK and PREEMPTIVE STRATEGIES

Brooks tells us that projects fail one day at a time. This would suggest that failure is dynamic and its opportunities for occurrence are both ever- present and cumulative. Smith' s project did not fail on the day management first expressed dissatisfaction, it had been steadily failing for some time. Other well-known software failures, such as the California State DMV project, support this. The DMV project failure did not happen on the day before the state auditors arrived on the scene. As the audit report showed, this project had been on a failure track for some time. If we look at most IS project failures we find the seeds of failure sown earlier in the project and they mature in the soil of ignorance. This ignorance comes from inability to identify, and then manage, all IS project risks.

The IS Project Management Perspective

The IS project manager' s strategic behavior starts even before the project is initiated.

Instead of having to execute individual risk strategies every day, the project manager now has four behaviors he or she must continually exhibit. The control behavior should already be ingrained in any practicing project manager. However, the other three, assess, relate, monitor, may not be so familiar to many IS project managers. For the IS project manager, this model provides a new way of viewing the responsibilities he or she has. For example, in the case under discussion, had Smith had this behavioral model and acted accordingly she probably would not have been surprised by the expected scope of her responsibilities. She would have developed self-awareness. Furthermore, having established the requisite relationships, it’s unlikely that Smith would have been unaware that the system she was delivering no longer met the needs of the business. This model gives IS project managers new insights into risk and mitigation behaviors that may help them avoid the apparent fate of Smith and her project.

The Senior Management Perspective

Use of this model by project managers in isolation won’t be enough, as is clear from the discussion of Smith. The responsibility for the successful outcome of an IS project cannot lie with the IS project manager alone. The model also lays open the need for active participation and proactive responsiveness from the group of stakeholders called Clients. The need for the IS project manager to undertake relationship building and management has been asserted. However, the whole concept of relationships and their management requires the active participation of multiple parties. Success cannot be achieved unless those with whom the project manager must establish the relationship are willing to actively participate in that relationship. There may be a temptation for the executive to turn over responsibility to the IS project manager with an attitude of " leave it to the nerds." Succumbing to this temptation results in the executive' s abdicating, not delegating, responsibility.

The executive who stimulates the relationship with the IS community will probably be less prone to being victim of the Client set of risks than a counterpart who cuts off the Relate behavior.

The model, strategies, and behaviors can also be used in audit mode, as in the Smith case. They can be used, at any point in a given project, to evaluate which risk classes have the highest potential for project exposure, thus enabling management to focus on the behaviors necessary to minimize occurrence. Just as the project manager must continually assess and manage the risks in the Self category, there must also be those charged with the responsibility for external assessment, counseling, and training to ensure that these Self risks are being appropriately managed.

STRATEGIES OR TACTICS

Some strategies for preempting IS project risks have been presented; they are strategies, however, and, as such, they must be tailored to the project context, the circumstances surrounding the individuals, and the environment of the project.

Because an IS project is dynamic, this context can change rapidly. One such case could be where the incumbent project manager, who has a real grasp of the strategies and behaviors, is replaced by a new project manager exhibiting some of the shortfalls discussed under Self. This would require an immediate focus on the Assess behavior by both the IS project manager and the responsible company management.

The temptation to convert these generalized strategic behaviors into some set of tactics to be executed by all project managers should be resisted. E.g., there may be a temptation to identify approaches such as Object-Oriented (OO) Development as a strategy. The use of OO is more of a tactic than a strategy. In the risk items in Exhibit 2, use of OO is a tactic within Lack of effective development methodology. On the negative side, it could be viewed as a tactic that results in increasing risk due to Trying new development method. Each IS project is unique and dynamic. Each has its own changing context of environment, people, and relationships. The tactics developed for each project, therefore, are unique to that project context and relevant to some specific point in time. Even though we have developed the model from the project manager' s perspective, the development of these project specific tactics must be a shared responsibility. What is consistent between projects is the need for IS managers to acquire and exhibit each of the strategic behaviors along with the active participation and guidance of senior management.

==