Success Factors in
Higher Education Administrative Systems Implementation:
A Review of the Literature

Introduction

System implementation efforts offer extraordinary challenges to information technology professionals and the organizations impacted by the implementations. A successful implementation can reap vast rewards in organizational strengths and efficiencies. A failure can drain an organization of people, funds and vitality. Consequently, many people have puzzled over the reasons for the successes and failures experienced with these implementations. This paper examines these complexities, as offered through scholarly research and discovers that many answers lie outside the bounds of technology.

• The interaction of technology and the organization – a broad concept that lays the groundwork for many of the other factors for consideration.
• User involvement and participation – influenced by a number of variables that must be carefully balanced in order to ensure success of the involvement.
• Resistance and skeptics – can work for or against a project depending upon how it is managed.
• Commitment – an essential ingredient for success but, because it involves a plethora of forces including the human psyche, is a challenge to achieve and maintain.
• Planning – more able to be controlled by project managers than other success factors, and involving many critical components.
• Risks – exist with every project but must be anticipated and managed in order to achieve success.

Technology affects "the ways in which organizational members must interact with one another to accomplish routine tasks."¹ System implementers must be cognizant of the cultural implications of the systems effort. Institutional and cultural separation between users and designers can easily result in a large gap between those who design the technology and those who actually use it. To address this "cross-cultural" gap, "enterprises should look for functional representatives with a broader understanding of the overall business beyond the daily transaction level, and technical representatives with an understanding of the potential business uses of technology."² The technologist should be aware that imposing a technological solution may exacerbate rather than resolve a problem. It is essential that the contextual interrelation of processes be examined, understood and documented before deciding that a new system might resolve any problems that lie within the processes. The organization must be aware that processes that have worked in the past may no longer be adequate. If both parties come to the table with their individual areas of expertise, without disabling biases, and with their minds open to a broad view of the situation at hand, an effective solution that complements the organization’s culture may be achieved. The cross-cultural gap extends to the highest echelons of the organization as well. In order for the CIO to be accepted as a member of the executive team, and to gain their trust and sponsorship for proposed IT initiatives, the CIO must extend beyond a technology focus and become a "full-spectrum contributor to the development and management of the organization’s business strategies."³ "Full-spectrum" includes understanding and appreciating organizational politics, basic financial issues, strategic planning, and other challenges faced by the CEO and executive team members. At all levels of the organization, nurturing a cross-cultural understanding of information technology and business practices will better position both the IT unit and the organization for the successful implementation of technology-based initiatives.

If a systems solution is decided upon, the impact of the solution on the organization must be planned for. An enterprise system will undoubtedly affect all aspects of the organization and, with today’s increasing reliance on cross-institutional partnerships, involve external organizations as well. The impact and how it is perceived and reacted to will differ from subculture to subculture because of differing uses and understanding of technologies. Adequately addressing the needs of these subcultures requires an in depth understanding of the language, processes and functions unique to the subculture and an appreciation for the values and beliefs embedded in the subculture. This understanding is best achieved by openly involving members of each subculture impacted by the systems process and/or by working intimately with the subcultures in their own environments.

The introduction of information technologies has a tremendous impact on power relations, work practices and value.⁴ Every system is biased by its creator(s). Like a work of art, the personalities, values and beliefs of the design team are imbedded in their creation (the system). An organization that opens itself up to a system implementation effort leaves itself vulnerable to power realignments imposed by the design of the system. Involving only management in the design could disempower downstream workers whereas involving end users offers the opportunity to empower these users with enhanced processes, job duties and organizational alignments. It is also important to recognize that technology is introducing a change in the relationship between the employee and the task accomplished through the use of this new technology tool. This impacts the knowledge required by the employee, knowledge that is a valued commodity in the community and treasured by the employee. The combined changes of tool, task, knowledge and value disrupt employees’ perceptions of their roles within the organization. Not only might they lose sight of which cog they are in their community’s wheel, they may no longer even recognize the wheel. Until employees become reconnected with their roles within the organization and are able to reform their assumptions about their workplace, acceptance of the new system will be difficult.

"No single quality of management practice is more highly correlated with success [than employee participation]."⁵ The question then becomes how to structure this participation to best ensure its success for the employee, the project and the organization.

Baronas and Louis examine the effect of change (anticipated differences in features) and surprise (unanticipated differences): "More important than the actual changes implementers might make are their skills at communicating them to users and linking them into users’ experiences. Implementation activities that assist users in making sense of and coping with changes, contrasts and surprises should contribute to system success."⁶ Baronas and Louis propose that user acceptance of a new system would be facilitated when:

• changes are realistically anticipated through input from knowledgeable sources;
• contrasts are given free expression through discussion among coworkers and between implementers and users;
• surprises are minimized through preview and realistic testing;
• assistance is provided in coping through the availability and coaching of experienced implementers.

System implementations often impose a threat of reduced control over a user’s work. Baronas and Louis suggest that when employees are given the opportunity to enhance perceived control during a system implementation, they will adapt to the resultant changes and more readily accept the system.⁷ Enhancement of control through involvement can be accomplished by:

• offering choices to the employee, involving them with meaningful decisions during the systems process;
• laying the groundwork for predictability by painting a complete and accurate picture in advance of the users’ exposure to the system during and after implementation;
• allowing the employee to assume some measure of responsibility during the system design and implementation process making them accountable for the results of specific tasks integral to the implementation process and encouraging shared ownership of the project;
• offering opportunities to reduce or escape from the stress that is inherent in a system implementation project.

System implementers often request "user participation." Barki and Hartwick define user participation as "a set of behaviors, activities and assignments that engage users throughout the systems development process."⁸ This participation has multiple dimensions: overall responsibility that the user may have with the project, the relationship between the user and the system, and hands-on project-related tasks. Increasing user participation in one or more of these dimensions enhances post-development user involvement and attitude. The effectiveness of involvement as a success factor can also be enhanced if implementers recognize that: "A user is involved when he or she considers a system to be both important and personally relevant."⁹

In addition, if an individual believes that the system is personally relevant, he will be more likely to form a positive attitude toward the system since attitudes are generally formed on the basis of beliefs.¹⁰ The strength of an individual’s involvement is directly related to the extremity of his or her attitude toward the system. A high level of involvement could drive an extremely positive or extremely negative attitude. A low level of involvement, however, leaves a person susceptible to other influencers (e.g., persuasive forces, factual arguments). With increased user involvement and a positive attitude, users will have an increased desire to participate in development.¹¹ Implementers might be able to enhance the probability of effective user involvement by examining several antecedents of and strategies for involvement including:^{12 13}

• Involvement roles (primary users, secondary users such as input specialists or recipients of outputs, top management)
• User predisposition toward the system (often based upon involvement with and attitude toward the present information system).
• Development conditions including the type of system (appropriateness of the system for the organization, the knowledge needed to work with the system and the impact of the system).
• User beliefs regarding perceived ability to effectively contribute during the development process. Low self-efficacy perceptions may inhibit a user’s desire to participate regardless of other factors. It is important to provide opportunities to participate where users will judge their experiences to be successful.
• Post-development cognitive, affective and motivational factors can be optimized by providing meaningful participation opportunities to users who deem the system to be personally relevant and important.
• Most importantly, user participation in systems development may revolve around the issue of user control. Maximizing the user’s instrumental control over the proposed system is a successful participation strategy.

Upon becoming a project participant, many factors influence the strength of the individual’s participation-to-involvement relationship:¹⁴

• Reasons for participating (i.e., voluntary or coerced). Hunton and Beeler’s field study indicated that coerced/mandated participation would be an ineffective means of gaining participation, particularly if the users do not gain a sense of responsibility or control during the course of their participation.¹⁵
• The kind of participation: direct involvement of affected users; indirect involvement (e.g., committee representation); consultative involvement (system design is influenced by the user but implemented by IT); representative involvement (users are represented on the design team); consensus involvement (involving all users throughout the organization).
• The degree of participation including the amount of influence the participation has on the project. As noted by Deetz, et al. "To be listened to and to have a stake in the outcomes are powerful forces."¹⁶ Degree of participation is also affected by the timing of the participation. The participant’s impact is strongest with an Instrumental Voice expressed throughout the decision process with evidence allowing users to believe that they have participated effectively in the development process.
• Hunton and Beeler conclude that the key information system success factor is to provide users with a sense of overall responsibility and system ownership.¹⁷

Who should participate is a critical decision point. While essential to involve key decision-makers for their insights, authority and sponsorship, one should also consider involving anyone who would be touched by the system. Staff members involved with daily operations offer important insights into critical operational success factors. As representatives of a variety of subcultures, they also bring a broad representative diversity to the project. The diversity of participation is especially critical when the system impacts wide reaching areas of the organization – as is the case with enterprise system implementations. Project success is dependent upon the insights and knowledge of invested members from each of the subcultures expected to embrace the system.

Markus offers three theories of why resistance may occur¹⁸:

• A person or subunit may resist because of factors unique to the individual or common to the entire group. Eliminating this resistance may require a change in personnel involved with the system implementation, educating the individual, coercing the resistor with edicts or policies, persuading the resistor, and/or by increasing user participation in order to earn their commitment to the project. Education and participation are far more preferable than coercion.
• Resistance may be a response to factors inherent in the system being implemented. People resist technically inadequate systems, systems of poor ergonomic design and "user-unfriendly" systems. If resistance is system-related, correcting the problems associated with the system should reduce or eliminate the resistance. To proactively address system-based resistance, use skilled designers, pay attention to ergonomic features, modify the system to better conform to organizational procedures, and involve users during the design phase.

The first theory involves internal factors while the second theory focuses on external factors. Both can be held simultaneously. An individual may have a tendency to resist a system – but, with all other factors being equal, this individual would be less likely to resist a well-designed system.

Interestingly, Markus’ third theory addresses the combination of system and person: resistance can be the result of the interaction between characteristics of the people being asked to adopt the system and characteristics of the system itself. Within the bounds of this third theory, the source of resistance lies with the interaction of the organization and system. This accounts for the acceptance of a system in one organizational setting while the same system might be rejected in a different organizational setting (or why one organization may accept one system while rejecting another). The third theory also introduces a political variant: resistance is the product of the interaction of the system’s design features with the intraorganizational distribution of power. The greater the impact of the system on existing power structures, the greater the resistance from those who lose power (or perceive that they will lose/have lost power). Those who believe they have gained power, however, are more likely to accept the system.

If resistance falls within the realm of this third theory, neither changing the individuals involved with the system nor changing the technical features of the system itself will reduce the resistance. To protect against interaction resistance, address organizational problems prior to introducing a system change. The organization must analyze its current situation, identify factors that will facilitate or hinder change, proceed with necessary changes, then introduce a system that supports the revised organizational situation. Consider restructuring the relationship between users and system designers. Design and implementation of the system will be enhanced by a positive, effective relationship between these two groups. Conversely, design will suffer and resulting structures will be negatively impacted if one group dominates over another during design.

One key to the successful use of the interaction theory is for the implementer to consider himself as one of the affected parties. By conducting a self-examination of one’s own interests, motives, payoffs and power bases, the implementer will enhance his understanding of other members’ reactions to the system design as well as the potential impact of the system implementation on the culture as a whole. This task also requires an empathetic examination of the interests, values and anxieties of the diverse organizational population. This should lead to advance recognition of the potential for resistance, providing two options: the ability to avoid resistance or pockets of resistance, and the opportunity to proactively and constructively confront the resistance.¹⁹

Markus notes that resistance can be destructive if it results in ill will, conflict or consumes inordinate amounts of time and attention. However, resistance can be functional if it prevents the installation of a system that might have led to persistent negative consequences such as chronic stress, high turnover and significant reductions in productivity. Resistance is not a problem to be solved so that a system can be installed exactly as originally intended. Rather, it is a useful clue to what went wrong and how the situation can be corrected.²⁰

Publicly expressed opinions of skeptics is one source of organizational resistance to IT initiatives. "Skeptics are highly opinionated about our performance and won’t hesitate to inform coworkers about what they consider to be our questionable management ability. Skeptics can divert attention from the positive aspects of our work."²¹ The most effective (but most difficult) way to neutralize skeptics is to convert them.²² Methodologies recommended for this conversion address many of the components of Markus’ interaction resistance theory. During a system implementation, bring skeptics into the process early and in a significant way. They should become system experts, mitigating their fears of loss of control or power. By developing a working relationship with skeptics, the project will benefit from their insights. If skeptics are involved with the design of success metrics, they can carry the results of these measurements back to their peers, building further support and winning over other skeptics. A project that does not welcome or foster genuine involvement of employees will breed cynicism.²³ Alternatively, a project that embraces the involvement of employees (supporters and critics) will breed project champions.

According to Newman and Sabherwal, successful development of an information system is dependent upon commitment to the project.²⁴ Commitment is a complex state involving the human psyche, external forces imposed upon the individual or organization, and the element of time that may or may not correspond to the timeline of the systems project. Staw defines commitment as "the state of mind that holds people and organizations in a line of behavior."²⁵ It encompasses psychological forces that bind an individual to an action as well as structural conditions that make a behavior irrevocable or difficult to change.²⁶ Commitment also affects the persistence of behavior.²⁷ Commitment to a systems project involves "doing what is necessary throughout the stages of system development, installation and use to assure that the problem is understood and that the system development solves that problem."²⁸ Commitment also involves a commitment to change. The organization must demonstrate a willingness to make changes to behavior, procedures, structure and any other factors that are necessary for the system to work.²⁹ This commitment must exist throughout the organization starting with top management. Commitment from the executive level is arguably the most important factor in information systems planning and implementation. When employees are able to participate in a systems project, they have the opportunity to follow management’s lead which, if positive, encourages commitment to the project goals. However, a lack of commitment will result in an organization permeated with indifference and resistance. Many of the leadership qualities described by Edgar Schein as necessary for building an organizational culture also apply to leading commitment for project initiatives: systematically paying attention to the project effort, responding to project-related crises in a manner reflecting the importance of the project as an integral part of the organization, ensuring adequate resource availability, coaching the organization in preparation for implementation, rewarding efforts made on behalf of the project, and recruiting individuals who will contribute to the project and/or the project-impacted organization.³⁰ For a project to succeed, commitment must come from all levels of the organization and be persistent through the project life cycle.

Determinants of commitment according to Newman and Sabherwal include:

• Project determinants - objective attributes associated with a project such as cost and return on investment.
• Psychological determinants - the relationship that key individuals and decision-makers have with the project.
• Social determinants - the groups involved with the project, the public or organization-wide identification with the project, politics, and prior resistance that may have existed.
• Structural determinants - attributes such as political and managerial support for the project, the strategic positioning of the project.

Newman and Sabherwal describe a dynamic model of commitment that recognizes the volatility of systems projects. This model includes the stages of making the initial commitment, withdrawing the commitment, committing to a new approach and the ensuing events including systems development activities. The initial commitment phase is influenced by the project determinants of budget, cost and anticipated benefits. As the project evolves, social and structural determinants (key project relationships, public identification with the project) may decline leading to the withdrawal of commitment. After this withdrawal, the organization will again become aware of the problematic factors that were the original impetus for the project and the psychological determinants (i.e., key decision-makers) will reassert themselves and renew the project determinants resulting in an escalation of commitment.³¹

System projects, particularly those involving enterprise systems, are very long term. According to Newman and Sabherwal, it is easier to maintain commitment if problems experienced during a project can be attributed to temporary causes or specific, avoidable project features.³² If an organization perceives a problem to be chronic and without resolution, commitment will fade. The long-term nature of information system projects can also impact the continuity of the project team, which is often the project’s core commitment source. To address this, system development projects should be supported by a wide group of stakeholders to ensure continuity even if the project champion or key team members leave.

A project plan begins with a vision. This vision should be clearly defined and publicly stated. Strong leadership with a clearly stated vision that is embraced by the organization will provide a powerful source of internal motivation enabling members of the organization to support each other’s efforts toward reaching a common goal; in this case, the successful system implementation. The vision should feed into the project plan. The extent of project definition and planning is a critical determinant of successful system implementations.^{33 34} To be successful, the project plan must be clear, concrete, focused on meaningful details and banish hidden agendas. According to Ginzberg, the project plan should include the following components:

• careful specifications of project team member roles,
• an analysis of the organization’s needs (addressing why the software is being implemented),
• a communication plan,
• specification of which people, units, functions and processes will be affected by the project,
• success factors for the project and strategies for meeting them,
• risk analysis,
• evaluation criteria for potential systems,
• training requirements, and
• the project schedule.

Such a detailed plan will set accurate expectations and define user involvement, reducing individual anxiety of the unknown.

Detailed project plans can also contribute to shorter implementation timeframes. The plan provides a focus and well-defined scope reducing "scope-creep." A compacted timeframe reduces the risk of implementing a system into an organization that has experienced significant evolution since the project’s inception. A phased or modular implementation might also be considered for the project timeframe. This approach can make the process more manageable and less daunting for developers and impacted users. Incremental implementations can provide incremental success stories that might help build project commitment and secure funding and support for the remainder of the project. However, phased projects introduce the complexity of multiple implementations and multiple disruptions complicated by multiple integration points between the modules and cultures involved.

An essential component of the project plan involves the mapping of business processes to determine where intervention is actually needed and whether a technical solution is appropriate. "Information systems cannot be designed independently of empirical knowledge of workplaces…in order to accurately represent the open systems’ properties of workplaces we should study them and incorporate tacit knowledge and articulation."³⁵ The analysis should determine the size and complexity of the problem and the corresponding size and complexity of the solution required to address the problem. Process mapping must involve strong, hands-on collaboration of the impacted users and system designers. The resulting understanding of the cultural context of the processes and their integration points will enable a more effective analysis of the types of change needed to address identified problems.³⁶

Research has shown that, while a well-defined project definition and plan contribute to success, they cannot make up for a lack of commitment.³⁷

"Through 2004, under-managing project risk will result in implementation cost overruns of as much as 50 percent for half of the enterprises embarking on collaborative projects."³⁸ Every systems implementation project involves some risks because of the organizational impact of the system. To help manage these risks, project leaders should be aware of the linkage between system success dimensions and project risks factors.^{39 40} Frequently cited risk factors include:

• project size,
• number of subcultures impacted,
• technological change,
• novelty of the application,
• personnel changes,
• lack of team expertise,
• unwilling users,
• lack of top management support,
• conflicting preferences between users and systems developers,
• high numbers and cultures involved in decision making,
• number of project partners,
• unrealistic schedules,
• unrealistic budget,
• lack of risk management,
• inappropriate user interfaces,
• flawed software functionality,
• continual requests for changes, and
• personnel shortfalls.

Success factors offer a contrast based on clarity, strength and inclusion:

• clearly defined goals,
• top management support,
• representative steering committee,
• sufficient and appropriate resources,
• competent team members,
• adequate communication,
• collaborative planning and management,
• formal risk management,
• clear project scope,
• rapid results,
• defined and effective decision-making structure,
• focus on organizational change issues,
• system quality,
• expectation management,
• user information satisfaction,
• IS usage, and
• cost/benefit productivity.

The Jiang and Klein survey of IS project managers found that individual project risk variables are not equally important in influencing success. The results evaluated risks against various dimensions of success ⁴¹:

• Critical risks for the systems development process include application complexity, lack of user experience, and general lack of team experience.
• Risks related to user satisfaction with system use are most affected by users’ experiences with the system. Clarity of role definition on the team was another significant risk factor within this success dimension.
• Technological newness is the most critical risk factor within the system quality satisfaction dimension (where "quality" is measured by performance, flexibility of changes, response time and ease of use).
• Within the organization impact success dimension, the key risk factor is the ability to earn user support for the system. Support is measured by the extent to which users believe the information made available to them meets their information requirement. It is a user view rather than a technical view of the system.⁴² Based on this finding, it appears that achieving maximum organizational effectiveness from a system depends upon users having a positive but realistic attitude toward the new system and valuing the outcomes of the system-induced changes. The user support factor manifested itself most frequently during the productive life of the system implying that visible sponsorship and meaningful system involvement must extend beyond the early days of implementation in order to foster continued user support and ensure long-term organization-wide system success.

Interaction of technology and the organization

Scholars describe the hazards of implementing systems in an unsuspecting culture. In fact, forward-thinking institutions are already working from proactive strategic principles that integrate information technology initiatives, culture (values, beliefs and goals) and the organization as a whole. These principles familiarize the organization with the challenges and opportunities offered by information technologies, foster collaboration for the development of information technology initiatives and build a foundation from which IT and the organization can partner in the pursuit of new initiatives. Bottom line: Cross-cultural understanding that permeates all levels of the organization is an essential element in system implementation efforts. An organization should not attempt a project without it.

Involvement

There is apparent general agreement that a wide swath of representatives must be involved in the project, and that involvement should begin early and last throughout the project. Theorists highlight multiple dimensions, the implications of the desire to be involved and the effect of involvement: predisposition toward IT, perceived ability to contribute, meaningful participation, shared control, heightened awareness and minimized surprises – to name a few.

Resistance

The literature presents many useful and interesting insights and theories regarding resistance. In particular, the interaction theory of resistance, which carries significant credibility based upon higher education’s experiences, points out that resistance may arise from the interaction of a particular person (or group) with a particular system. To counteract this, both sides of the resistance coin must be polished. There is a recommendation is to analyze the current situation first, then make the necessary changes to the organization, then add the system appropriate to the revised organization. In reality, often times an organization cannot be fundamentally changed without the system in place to support the change. However, organizations would benefit from adhering to the recommendation to analyze first; they could then set direction and choose a system based upon the organizational vision chosen by the (formal, inclusive) analysis process. The literature also discusses resistance spawned from the influence a system design can have on organizational power structures. This is seldom mentioned as a pre-implementation variable in the experiential readings although power restructuring outcomes are noted. Awareness of this aspect of a system implementation must be moved up to the inception stages of the project.

Commitment

There is general agreement that commitment is crucial to an implementation project. As practitioners struggle to earn this commitment, it is helpful to realize that commitment is mitigated by several influencers as described by the literature: objective, psychological, social, and structural. By recognizing each of these influencing variables, project sponsors can take a more comprehensive approach to building the commitment necessary for the success of the project. Scholars also emphasize the time dimension associated with commitment. Practitioners should not be caught by surprise if commitment takes on an ebb and flow. Instead, be prepared for this aspect of this success factor and include proactive strategies for both renewing and sustaining commitment.

Commitment is a critical success factor and scholars offer insights. Institutions are gaining commitment through many proven techniques, and must work with or without this commitment in a manner most appropriate for their specific organizational cultures.

Theorists on system implementations recognize that neither the organization nor the project is going to know where to go or how to get there without a plan. A plethora of components can go into a plan but it typically begins with a vision and builds from there. The decision of what to put in a plan should be based upon what is needed to initiate, manage, direct, guide, construct, nurture, validate and complete the project within your institution. If a component falls into any of these categories, it should be in the plan. Four C’s describe an effective plan: Clear, Concrete, Comprehensive, Communicated.

Risk

Risk is associated with almost everything we do; it is definitely associated with enterprise-wide systems projects. But just as we can reduce risk in our every day lives, we can proactively reduce project-associated risks. The literature has outlined key areas of risk that should be required reading for new implementers. Scholars have also given attention to linking individual risk factors to particular dimensions of success (systems development, user satisfaction, quality satisfaction and organizational impact). By analyzing the risk factors present in an institution and weighing them against the success factors most vulnerable to these risks, project managers can proactively turn the tide in favor of success.

Implementation practitioners have found that the idiosyncrasies and traditions of universities can make a fertile breeding ground for resistors and are tackling the issue of resistance head on corroborating many of the scholar-recommended techniques. Bringing resistors into the project early and in a significant way has proven to be an effective technique at more than one institution. (The scholarly literature highly recommends this technique but caution that it is the most difficult.)

Communication and Training

Although they are mentioned in the context of other success factors, the role of communication and training is emphasized more strongly by practitioners than by scholars in the literature. Regarding communication: Identify your audience, select your method, do it! get creative, and do it some more. Regarding training: Identify your audience, select your method, do it! get creative, and do it some more.

In other words, both are essential, neither can be overdone and both should be audience-specific. Communication is the glue that holds a culture together; training strengthens the threads of knowledge woven through the culture.

It would be interesting to compare scholarly findings with actual practice in the "test bed" of Higher Ed, and analyze any differences. Since the mid-90s, more and more institutions are currently engaging in significant systems implementation, as they are finding that their current systems, most developed in the early 80s, are inadequate. This trend will continue to increase, so having the wisdom of experience would be beneficial for these institutions.

Table of Contents | Main Body of Paper | References