What are the principal risk factors in information systems projects, and how can they be managed?

We have already introduced the topic of information systems risks and risk as­sessment in Chapter 8. In this chapter, we describe the specific risks to informa­tion systems projects and show what can be done to manage them effectively.

1. Dimensions of Project Risk

Systems differ dramatically in their size, scope, level of complexity, and orga­nizational and technical components. Some systems development projects are more likely to create the problems we have described earlier or to suffer delays because they carry a much higher level of risk than others. The level of project risk is influenced by project size, project structure, and the level of technical expertise of the information systems staff and project team.

• Project size. The larger the project—as indicated by the dollars spent, the size of the implementation staff, the time allocated for implementation, and the number of organizational units affected—the greater the risk. Very large-scale systems projects have a failure rate that is 50 to 75 percent higher than that for other projects because such projects are complex and difficult to control. The organizational complexity of the system—how many units and groups use it and how much it influences business processes—contributes to the complexity of large-scale systems projects just as much as technical charac­teristics, such as the number of lines of program code, length of project, and budget. In addition, there are few reliable techniques for estimating the time and cost to develop large-scale information systems.
• Project structure. Some projects are more highly structured than others. Their requirements are clear and straightforward, so outputs and processes can be easily defined. Users know exactly what they want and what the system should do; there is almost no possibility of the users changing their minds. Such projects run a much lower risk than those with relatively undefined, fluid, and constantly changing requirements; with outputs that cannot be fixed easily because they are subject to users’ changing ideas; or with users who cannot agree on what they want.
• Experience with technology. The project risk rises if the project team and the information system staff lack the required technical expertise. If the team is unfamiliar with the hardware, system software, application software, or database management system proposed for the project, it is highly likely that the project will experience technical problems or take more time to complete because of the need to master new skills.

Although the difficulty of the technology is one risk factor in information systems projects, the other factors are primarily organizational, dealing with the complexity of information requirements, the scope of the project, and how many parts of the organization will be affected by a new information system.

2. Change Management and the Concept of Implementation

The introduction or alteration of an information system has a powerful behav­ioral and organizational impact. Changes in the way that information is de­fined, accessed, and used to manage the organization’s resources often lead to new distributions of authority and power. This internal organizational change breeds resistance and opposition and can lead to the demise of an otherwise good system.

A very large percentage of information systems projects stumble because the process of organizational change surrounding system building was not properly addressed. Successful system building requires careful change management.

2.1. The Concept of Implementation

To manage the organizational change surrounding the introduction of a new information system effectively, you must examine the process of implementa­tion. Implementation refers to all organizational activities working toward the adoption, management, and routinization of an innovation, such as a new infor­mation system. In the implementation process, the systems analyst is a change agent. The analyst not only develops technical solutions but also redefines the configurations, interactions, job activities, and power relationships of various organizational groups. The analyst is the catalyst for the entire change process and is responsible for ensuring that all parties involved accept the changes cre­ated by a new system. The change agent communicates with users, mediates between competing interest groups, and ensures that the organizational adjust­ment to such changes is complete.

2.2. The Role of End Users

System implementation generally benefits from high levels of user involve­ment and management support. User participation in the design and opera­tion of information systems has several positive results. First, if users are heavily involved in systems design, they have more opportunities to mold the system according to their priorities and business requirements and more opportunities to control the outcome. Second, they are more likely to react positively to the completed system because they have been active partici­pants in the change process. Incorporating user knowledge and expertise leads to better solutions.

The relationship between users and information systems specialists has traditionally been a problem area for information systems implementation efforts. Users and information systems specialists tend to have different back­grounds, interests, and priorities. This is referred to as the user-designer communications gap. These differences lead to divergent organizational loy­alties, approaches to problem solving, and vocabularies.

Information systems specialists, for example, often have a highly technical, or machine, orientation to problem solving. They look for elegant and sophis­ticated technical solutions in which hardware and software efficiency is opti­mized at the expense of ease of use or organizational effectiveness. Users prefer systems that are oriented toward solving business problems or facilitating organizational tasks. Often the orientations of both groups are so at odds that they appear to speak in different tongues.

These differences are illustrated in Table 14.4, which depicts the typical con­cerns of end users and technical specialists (information systems designers) regarding the development of a new information system. Communication prob­lems between end users and designers are a major reason why user require­ments are not properly incorporated into information systems and why users are driven out of the implementation process.

Systems development projects run a very high risk of failure when there is a pronounced gap between users and technical specialists and when these groups continue to pursue different goals. Under such conditions, users are often driven away from the project. Because they cannot comprehend what the technicians are saying, users conclude that the entire project is best left in the hands of the information specialists alone.

2.3. Management Support and Commitment

If an information systems project has the backing and commitment of man­agement at various levels, it is more likely to be perceived positively by both users and the technical information services staff. Both groups will believe that their participation in the development process will receive higher- level attention and priority. They will be recognized and rewarded for the time and effort they devote to implementation. Management backing also ensures that a systems project receives sufficient funding and resources to be successful. Furthermore, to be enforced effectively, all the changes in work habits and procedures and any organizational realignments asso­ciated with a new system depend on management backing. If a manager considers a new system a priority, the system will more likely be treated that way by his or her subordinates. According to the Project Management Institute, executive sponsors who are actively engaged is the leading fac­tor in project success (Kloppenborg and Tesch, 2015; Project Management Institute, 2017).

2.4. Change Management Challenges for Business Process Reengineering, Enterprise Applications, and Mergers and Acquisitions

Given the challenges of innovation and implementation, it is not surprising to find a very high failure rate among enterprise application and business process reengineering (BPR) projects, which typically require extensive organizational change and which may require replacing old technologies and legacy systems that are deeply rooted in many interrelated business processes. A number of studies have indicated that 70 percent of all business process reengineering projects fail to deliver promised benefits. Likewise, a high percentage of enterprise applications fail to be fully implemented or to meet the goals of their users even after three years of work.

Many enterprise application and reengineering projects have been un­dermined by poor implementation and change management practices that failed to address employees’ concerns about change. Dealing with fear and anxiety throughout the organization, overcoming resistance by key man­agers, and changing job functions, career paths, and recruitment practices have posed greater threats to reengineering than the difficulties companies faced visualizing and designing breakthrough changes to business processes. All of the enterprise applications require tighter coordination among dif­ferent functional groups as well as extensive business process change (see Chapter 9).

Projects related to mergers and acquisitions have a similar failure rate. Mergers and acquisitions are deeply affected by the organizational characteris­tics of the merging companies as well as by their IT infrastructures. Combining the information systems of two different companies usually requires consider­able organizational change and complex systems projects to manage. If the inte­gration is not properly managed, firms can emerge with a tangled hodgepodge of inherited legacy systems built by aggregating the systems of one firm after another. Without a successful systems integration, the benefits anticipated from the merger cannot be realized, or, worse, the merged entity cannot execute its business processes effectively.

3. Controlling Risk Factors

Various project management, requirements gathering, and planning methodol­ogies have been developed for specific categories of implementation problems. Strategies have also been devised for ensuring that users play appropriate roles throughout the implementation period and for managing the organizational change process. Not all aspects of the implementation process can be easily controlled or planned. However, anticipating potential implementation prob­lems and applying appropriate corrective strategies can increase the chances for system success.

The first step in managing project risk involves identifying the nature and level of risk confronting the project. Implementers can then handle each proj­ect with the tools and risk management approaches geared to its level of risk. Not all risks are identifiable in advance, but with skillful project management, most are. Frequent communication and a culture of collaboration will help proj­ect teams adapt to unforeseen problems that arise (Browning and Ramasesh, 2015; Laufer et al., 2015; McFarlan, 1981).

3.1. Managing Technical Complexity

Projects with challenging and complex technology to master benefit from internal integration tools. The success of such projects depends on how well their technical complexity can be managed. Project leaders need both heavy technical and administrative experience. They must be able to anticipate problems and develop smooth working relationships among a predominantly technical team. The team should be under the leadership of a manager with a strong technical and project management background, and team members should be highly experienced. Team meetings should take place frequently. Essential technical skills or expertise not available internally should be secured from outside the organization.

3.2. Formal Planning and Control Tools

Large projects benefit from appropriate use of formal planning tools and formal control tools for documenting and monitoring project plans. The two most commonly used methods for documenting project plans are Gantt charts and PERT charts. A Gantt chart lists project activities and their corresponding start and completion dates. The Gantt chart visually repre­sents the timing and duration of different tasks in a development project as well as their human resource requirements (see Figure 14.4). It shows each task as a horizontal bar whose length is proportional to the time required to complete it.

Although Gantt charts show when project activities begin and end, they don’t depict task dependencies, how one task is affected if another is behind sched­ule, or how tasks should be ordered. That is where PERT charts are useful. PERT stands for “Program Evaluation and Review Technique,” a methodology developed by the U.S. Navy during the 1950s to manage the Polaris submarine missile program. A PERT chart graphically depicts project tasks and their inter­relationships. The PERT chart lists the specific activities that make up a project and the activities that must be completed before a specific activity can start, as illustrated in Figure 14.5.

The PERT chart portrays a project as a network diagram consisting of num­bered nodes (either circles or rectangles) representing project tasks. Each node is numbered and shows the task, its duration, the starting date, and the completion date. The direction of the arrows on the lines indicates the sequence of tasks and shows which activities must be completed before the commencement of another activity. In Figure 14.5, the tasks in nodes 2, 3, and 4 are not dependent on each other and can be undertaken simultane­ously, but each is dependent on completion of the first task. PERT charts for complex projects can be difficult to interpret, and project managers often use both techniques.

These project management techniques can help managers identify bottle­necks and determine the impact that problems will have on project comple­tion times. They can also help systems developers partition projects into smaller, more manageable segments with defined, measurable business results. Standard control techniques can successfully chart the progress of the project against budgets and target dates, so deviations from the plan can be spotted.

3.3. Increasing User Involvement and Overcoming User Resistance

Projects with relatively little structure and many undefined requirements must involve users fully at all stages. Users must be mobilized to support one of many possible design options and to remain committed to a single design. External integration tools consist of ways to link the work of the implementation team to users at all organizational levels. For instance, users can become active mem­bers of the project team, take on leadership roles, and take charge of installation and training. The implementation team can demonstrate its responsiveness to users, promptly answering questions, incorporating user feedback, and show­ing their willingness to help.

Participation in implementation activities may not be enough to overcome the problem of user resistance to organizational change. Different users may be affected by the system in different ways. Whereas some users may welcome a new system because it brings changes they perceive as beneficial to them, oth­ers may resist these changes because they believe the shifts are detrimental to their interests.

| FIGURE 14.4 A GANTT CHART

The Gantt chart in this figure shows the task, person-days, and initials of each responsible person as well as the start and finish dates for each task. The resource summary provides a good manager with the total person-days for each month and for each person working on the project to manage the project successfully. The project described here is a data administration project.

If the use of a system is voluntary, users may choose to avoid it; if use is mandatory, resistance will take the form of increased error rates, disruptions, turnover, and even sabotage. Therefore, the implementation strategy must not only encourage user participation and involvement, but it must also address the issue of counterimplementation. Counterimplementation is a deliberate strategy to thwart the implementation of an information system or an innova­tion in an organization.

Strategies to overcome user resistance include user participation (to elicit commitment as well as to improve design), user education and training, man­agement edicts and policies, and better incentives for users who cooperate. The new system can be made more user-friendly by improving the end-user inter­face. Users will be more cooperative if organizational problems are solved prior to introducing the new system.

4. Designing for the Organization

Because the purpose of a new system is to improve the organization’s perfor­mance, information systems projects must explicitly address the ways in which the organization will change when the new system is installed, including instal­lation of mobile and web applications. In addition to procedural changes, trans­formations in job functions, organizational structure, power relationships, and the work environment should be carefully planned.

Areas where users interface with the system require special attention, with sensitivity to ergonomics issues. Ergonomics refers to the interaction of people and machines in the work environment. It considers the design of jobs, health issues, and the end-user interface of information systems. Table 14.5 lists the organizational dimensions that must be addressed when planning and imple­menting information systems.

Although systems analysis and design activities are supposed to include an organizational impact analysis, this area has traditionally been neglected. An organizational impact analysis explains how a proposed system will af­fect organizational structure, attitudes, decision making, and operations. TP in­tegrate information systems successfully with the organization, thorough and fully documented organizational impact assessments must be given more at­tention in the development effort.

Sociotechnical Design

One way of addressing human and organizational issues is to incorporate sociotechnical design practices into information systems projects. Designers set forth separate sets of technical and social design solutions. The social de­sign plans explore different workgroup structures, allocation of tasks, and the design of individual jobs. The proposed technical solutions are compared with the proposed social solutions. The solution that best meets both social and technical objectives is selected for the final design. The resulting sociotechni­cal design is expected to produce an information system that blends techni­cal efficiency with sensitivity to organizational and human needs, leading to higher job satisfaction and productivity.

You can see some of these project management strategies at work in the Interactive Session on Management, which describes how ConocoPhillips im­plemented a new access control system.

5. Project Management Software Tools

Commercial software tools that automate many aspects of project management facilitate the project management process. Project management software typi­cally features capabilities for defining and ordering tasks, assigning resources to tasks, establishing starting and ending dates to tasks, tracking progress at both individual and team levels, and facilitating modifications to tasks and re­sources. Many automate the creation of Gantt and PERT charts and provide communication, collaboration, and social tools.

Some of these tools are large sophisticated programs for managing very large projects, dispersed work groups, and enterprise functions. These high- end tools can manage very large numbers of tasks and activities and com­plex relationships. The most widely used project management tool today is Microsoft Project, but there are also lower-cost tools for smaller projects and small businesses. Many project management applications are now cloud-based to enable project team members to access project management tools and their data wherever they are working. The Interactive Session on Technology describes some capabilities of cloud-based Microsoft Project Online.

While project management software helps organizations track individual projects, the resources allocated to them, and their costs, project portfolio management software helps organizations manage portfolios of projects and dependencies among them. Project portfolio management software helps man­agers compare proposals and projects against budgets and resource capacity lev­els to determine the optimal mix and sequencing of projects that best achieves the organization’s strategic goals.

Source: Laudon Kenneth C., Laudon Jane Price (2020), Management Information Systems: Managing the Digital Firm, Pearson; 16^th edition.