Presentation on theme: "System Implementation Success Factors; It’s not just the Technology by Paula J. Vaughan University of Colorado at Boulder."— Presentation transcript:
System Implementation Success Factors; It’s not just the Technology by Paula J. Vaughan University of Colorado at Boulder
Scholars & Practitioners Practitioners, through the school of hard knocks and experience, can tell us “what” seems to work. Scholars through years of academic study and research, can tell us “why.” Common ground success factors: Interaction of technology and the organization User involvement and participation Resistance Commitment Planning Risk Mix it all together – then remember to toss in some common sense
Interaction of Technology & Organization “It don’t take much to see that something is wrong, but it does take some eyesight to see what will put it right again.” ~Will Rogers Scholars: Be cognizant of the cultural implications of a systems effort; it will impact all cultures within an organization. Plan for it. Practitioners: Examine business processes and information technologies together; both within the context of the organization as a whole.
Interaction of Technology & Organization - Scholars CIO: gain trust; move beyond a technical focus. IT assumptions differ from remainder of the org. Examine contextual interrelationship of processes, data, decision makers, operational workers. Be aware of IT’s impact on power relations. Systems are biased by their creators. New tools + tasks + knowledge requirements + value changes = disruption of employee’s role within the organization.
Interaction of Technology & Organization - Practitioners George Washington University: “We must seek synergy of technology and organizational process … we must implement a culture of change…” Valparaiso University: “There is one principle that undergirds our successes: this is about people, not technology.” University of Pennsylvania: “[technology] cannot substitute for organizational and cultural change. … jobs, skills, rewards, tools, organizational structures, and to some extent, their values and beliefs [are changed].”
Interaction of Technology & Organization - Practice Indiana U./Bloomington guiding principle: “Success would be measured from a user-centric point of view.” Goal: “At least 95% of the users… would agree that the improvements … more than outweighed the difficulties.” George Washington U. “infostructure” – an integrated approach to info systems designed via a collaborative, inclusive effort and supportive of university mission and goals. Purdue U: formal cross-functional, single-focused, strategically-oriented project team structure.
User involvement and participation “People’s minds are changed through observation and not through argument” ~ Will Rogers “No single quality of management practice is more highly correlated with success [than employee participation]” (Deetz, et al) “A user is involved when he or she considers a system to be both important and personally relevant.” (Barki and Hartwick)
Involvement and participation – scholarly considerations (why) Enhancing perceived control enhances adaptation to change and acceptance of the system. Increasing participation in one or more dimension (overall responsibility, user-system relationship or hands-on project tasks) enhances post- development user involvement and attitude. If an individual believes something is personally relevant, s/he will be more likely to form a positive attitude toward the system, increasing the desire to participate.
Involvement and participation – scholarly considerations Desire to be involved predictors: role, predisposition toward the project/IT, development conditions, beliefs of ability to effectively contribute, amount of control. Strength of involvement is directly related to extremity of attitude (positive and negative). Strength of participation-to-involvement relationship factors: reason for participating, kind of participation, amount of influence.
Involvement and participation – scholarly considerations Who to involve: key decision makers for authority and sponsorship; daily operations staff for insights and representation of diverse subcultures.
Involvement and participation – scholarly considerations Outcomes of involvement: Cognitive: system understanding, needs assessment, feature evaluation Motivational: ownership, reduced resistance to change, increased commitment
Involvement and participation – in practice (how) Rapid Application Development (Bradley Univ.). Weekly meetings (discussion, previews, set milestones), multiple levels of stakeholders. Balance to remove bias toward any one function. Joint Application Design (Arizona State). Results focus, deep into issues, dedicated project room. Put “developers and users together to set common expectations and [get] users actively involved so that they feel ownership of the system.”
Involvement and participation – in practice (how) Incremental Prototyping Methodology (School of the Art Institute of Chicago). Decreased development cycle, fit/gap analysis, modeling, hands-on simulation, testing, conversion, enhancements, development. Recommend 100% assignments, dedicated project space. Project Team + Core Team (Univ. of Colorado & Western Iowa Tech Community College). Wide representation ensures policy/procedure review by those most affected, increases commitment, better- rounded results. Nimble core team fosters communication and responsiveness.
Involvement and participation – in practice (who) At least consider each affected unit. Choose based upon ability to accomplish the tasks Choose those who will continue to support and integrate the new programs and processes into the post-implementation culture. Balance marketing types with technical types. Be wary of highly knowledgeable staff with a bias toward the status quo. Pair up visionaries with detailed pragmatists. Include new employees (fresh viewpoint) with employees familiar with older systems.
Involvement and participation – in practice (words of advice) Cleveland State: “A sense of efficacy in the process has to be developed.” University of Wisconsin-Madison: “An iterative, user-centered approach is essential for success.” Western Iowa Tech Community College: “…lack of ownership by the college as a whole could be viewed as the biggest problem resulting from the original implementation.” Indiana University/Bloomington: “[Faculty] endorsements helped to mitigate any perceptions that the computing center was issuing edicts…”
Involvement and participation – in practice (who) Personality recommendations: detailed knowledge of institutional operations, clearheaded analytic capabilities, creative and visionary, adaptable and comfortable with uncertainty, enjoy challenges, ability to bridge between software and business requirements, willingness to work for months or years under intense scrutiny and pressure, thick-skinned.
Involvement and participation – in practice (pragmatisms) As users become more involved with a project, they generate more ideas and requests. Bradley University: “At some point, we need to stop developing and implement…” University of Pennsylvania: “At some point the sponsor has to step in and say ‘Thank you, that’s enough.’”
Resistance “If you get to thinkin’ you’re a person of some influence, try ordering somebody else’s dog around” ~ Will Rogers By recognizing the potential for resistance in advance, project implementers can enhance the probability of avoiding resistance and can provide an opportunity to proactively and constructively confront resistance.
Resistance – Scholarly considerations (why) Three reasons for resistance (Markus) Factors internal to the person or group. Eliminate this resistance by changing personnel, educating, coercing, persuading and/or increasing participation. System-based factors (technically inadequate, poor ergonomic design, user-unfriendly). Eliminate by correcting the system or avoid by using skilled designers, modifying to better conform to procedures or by involving users to gather insights during the design. Person-based and system-based resistance may be held simultaneously. An individual may tend to resist a system but, all other factors being equal, this individual would be less likely to resist a well designed system.
Resistance – Scholarly considerations (why) Third reason: interaction between people and system. Combination of technical design of the system and the social context into which it is being introduced. Accounts for why one organization may accept a system while another does not (or why one system will be accepted by an org while another system is resisted). To protect against interaction resistance: address organizational problems prior to introducing a system change then introduce a system that supports the revised organizational situation. Establish a relationship between users and system designers so the design is a product of both.
Resistance – Scholarly considerations (why) Sociotechnical variant of resistance: system- prescribed shift in the division of roles and responsibilities leading to a structure of interaction at odds with the current culture. The source of resistance is not the system or the organization but is the interaction of the system and organization. Political variant of resistance: the interaction of the system design with the organizational distribution of power. The greater the impact on the power structure, the greater the resistance from those who lose power.
Resistance – Scholarly considerations Resistance is destructive if it results in ill will, conflict and/or consumes inordinate amounts of time and attention. Resistance is functional if it prevents the installation of a system that might have led to persistent negative consequence. Skeptics – a source of resistance: opinionated, vocal, divert attention from positive aspects of the project. The most effective (but difficult) way to neutralize skeptics is to convert them. Bring into the process early and in a significant way.
Resistance – Observations from Higher Ed Contributing factors from Higher Ed’s unique environment: Deeply entrenched structures (i.e., tenure) Diffusion of authority Politically-rooted organizational structures, Silos of closely controlled information Lack of incentives Unwieldy infrastructures Unbending academic cycles
Resistance – Observations from Higher Ed Western Iowa Tech Community College: “Resistance to change is a powerful force. Expecting change from those who are resistant is futile, even with supportive top-down leadership.” Deal with it by choosing project team members based upon orientation to change rather than functional expertise
Resistance – Observations from Higher Ed Cleveland State, Noting that policy changes meet greater resistance than process changes: “Many colleagues report that the inability to get even the simplest policy change has wrecked havoc with their implementation.” Deal with it by gathering support from faculty governance bodies, senior administration and, in some cases, the highest governing body of the institution.
Resistance – Observations from Higher Ed University of Colorado: Identified traditional resistors and brought them into the project at its inception to address concerns, fears, and requirements throughout the life of the project. These individuals/departments evolved into project champions and mentors. Virginia Commonwealth: When confronted by resistors, gained their trust by meeting individually with each resistor, at the resistor’s convenience, in their office, and listened.
Commitment “Actual knowledge of the future was never lower, but hope was never higher. Confidence will beat predictions any time.” ~ Will Rogers Successful development of an information system is dependent upon commitment to the project from all levels of the organization throughout the project life cycle. 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.” (Ginzberg)
Commitment - definitions Commitment is a complex state that involves the human psyche, external forces imposed on the individual and organization and the element of time. (Staw) Commitment is a state of mind that holds people and organizations in a line of behavior. (Staw) Commitment encompasses psychological forces that bind an individual to an action as well as structural conditions that make a behavior irrevocable or difficult to change. (Becker) Commitment affects the persistence of behavior. (Salancik)
Commitment – why and how Scholars: Executive level commitment is arguably the most important factor in information systems planning and implementation. Employees follow management’s lead. If positive, it encourages; if negative, it generates indifference and resistance. Practice: Simply having a sponsor is not enough. The sponsor must sell the project to the institution, visibly supporting the process and embedding the project effort into the organizational culture. Convince the organization that benefits outweigh angst. To do this, the sponsor must already have built credibility, trust and respect.
Commitment – why and how Psychological determinants scholarly definition: relationship between key individuals and the project. Psychological determinants dealt with in practice through project involvement and resistor conversion.
Commitment – why and how Social determinants, scholarly definition: groups involved with the project, public or organization-wide identification with the project, politics, prior resistance. Social determinants dealt with in practice by involving impacted subcultures and key political stakeholders.
Commitment – why and how Structural determinants, scholarly definition: political and managerial support for the project, strategic positioning of the project. Structural determinants, dealt with in practice by recognizing the importance of appropriate project sponsorship. Senior executive sponsorship is critical to establishing cross-boundary commitment. Institution-wide commitment requires consistent commitment across managers and departments. To ensure organization-wide commitment, the executive sponsor should not belong to IT.
Commitment cycle Typical cycle: initial commitment, withdraw the commitment, make a commitment to a new approach. Initial commitment is influence by project determinates (objective attributes such as cost, return on investment). Project evolution may lead to a decline of social and structural determinants which leads to a withdrawal of commitment. The project again becomes aware of the original problematic factors that were the original impetus for the project and the psychological determinants reassert themselves. Project determinants are renewed resulting in an escalation of commitment.
Planning “If you’re ridin’ ahead of the herd, take a look back every now and then to make sure it’s still there.” ~ Will Rogers Project planning is important as a project management tool and as a vehicle for weaving the project’s culture into the parent culture. Planning is made up of many detailed components, some more pertinent than others depending upon the organization. The final plan should reflect and fit your institution.
Planning – scholarly considerations (why) Begin with a vision, clearly defined and publicly stated. Without the vision, project direction, focus and shared commitment will be lacking. A detailed project plan can set accurate expectations and define the direction for user involvement thus reducing anxiety. A detailed project plan can contribute to shorter implementation time frames by providing focus and scope and reducing feature creep.
Planning – scholarly considerations (what) Ingredients of a successful project plan: Clear, concrete, focused on meaningful details Banish hidden agendas Clearly defined team member roles Analysis of organization’s needs Business process mapping Communication plan Specification of all affected (people, functions, processes, units, etc.) Success factors for the project and strategies for meeting them Risk analysis Evaluation criteria for potential systems Training requirements Project schedule
Planning – scholarly considerations (what) Essential component: collaborative mapping of business process to determine: Where intervention is actually needed Whether a technical solution is even appropriate The size and complexity of the problem The corresponding size and complexity of the solution
Planning in practice – beyond the scholarly thoughts Begin with a foundation phase (project formation, goal definition, means for achieving goal defined) Project goals should answer “what’s in it for me” for each impacted area Formally articulate expectations and assumptions; do not assume everyone is moving in the same direction Convert expectations to specific tasks and assignments (critical issues list). Define and publicize strategic objectives regardless of the scope of the project. University faculty and students) scrutinize administrative initiatives. Success factors and metrics should be developed and sanctioned by all areas of the institution.
Planning in practice – beyond the scholarly thoughts Realistic, flexible project schedule. Include all tasks. Allow for delays. Include time to honor pre-project commitments, project initiation time, team selection and formation tasks, vendor scheduling, institution-wide review and analysis activities and time for re-doing. Communicate, correct and re-communicate the schedule. Communication plan: formal & informal communication, private & public, frequency, methods, audiences. Often overlooked but important: team building, skills training, risk assessment, documentation resources, contingency planning.
Planning in practice – beyond the scholarly thoughts Use the project plan and scope to manage the often diverse agendas of higher ed cross- functional teams. The “go live” point of the project plan should be treated as a crisis and addressed by crisis management planning (quick response, communication paths, problem reporting mechanisms, tracking system, etc.).
Risks “Good judgment comes from experience, and a lot of that comes from bad judgment.” ~ Will Rogers “Through 2004, undermanaging project risk will result in implementation cost overruns of as much as 50 percent for half of the enterprises embarking on collaborative projects.” (Gartner, 2000)
Risks – Scholarly insights Individual project risk variables are not equally important in influencing success. (Jiang & Klein) Risks evaluated against dimensions of success: Critical risks for systems development: application complexity, lack of user experience, 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 is also significant. System quality (performance, flexibility of changes, response time, ease of use) satisfaction risk factor: technological newness. Key risk factor for organization impact success dimension: ability to earn user support for the system.
Risks – reality and practicality Institutions often underestimate the magnitude of changes and overestimate the ability of the organization to absorb these changes. Predict organizational reaction to change and direct the reaction toward the desired goal. The complexity of a system has a direct relationship to the amount of risk involved. Build specific strategies for working with the application during development, document the system, test, test, test. Complex systems typically cross numerous organizational boundaries, compounding complexity-associated risks. Strategically address through process mapping and by fostering user-involvement.
Risks – reality and practicality An inadequate decision-making structure is a critical risk factor. Art Institute of Chicago: empowered each of four levels of the project with decision making authority appropriate to their project responsibilities. Include senior management in decision making to avoid the risk of delayed decisions often found in a University’s multi-cultural, consensus-oriented environment. Failure to understand the risks of customizations “is the most serious mistake administrators can make.” (Smith, Educause Quarterly, 2000)
Communication “The greatest publicity and interest in the world is to be told about something, not to have read about it.” ~ Will Rogers Valparaiso: “Take your cue from Madison Avenue: to get people’s attention, communication needs to be frequent, repetitive and perhaps even annoying.” Cleveland State: “Constant communication is mandatory. No matter how often or in what medium you choose to communicate, it is never enough. Use every appropriate means at your disposal to let the campus community know what you are doing but make sure that the communications plan is appropriate to your campus culture.” Rice: “The most important lesson that we learned…was the need to keep open the channels of communication with all constituencies…” Rensselaer Polytechnic Institute: “…communicate what other people in the community should be aware of before ‘go live’.”
Training “If you send somebody to teach somebody, be sure that the system you are teaching is better than the system they are practicing.” Will Rogers Without training, system implementation will take longer, adaptation will be more problematic and frustration will be higher. Components of a successful training program: Process reengineering training and team training prior to project-specific work. Extensive documentation. Appropriate timing (project schedule, trainer and trainee availability). Appropriate training forum (classroom, computer-based, one-on-one). Building upon and coordinating with existing training expertise. Developing function-specific and broad-view training. Cross-functional training to ensure user understanding of institution-wide processes, new workflows and interdependencies. Testing the training as part of a pilot implementation. An in-house training curriculum to continue training beyond implementation.
System Implementation Success Factors – It’s not just the technology Presentation available at: SystemImplementationSuccessFactors.htm or contact Paula Vaughan at