Week 12 Tutorial - Solutions PDF

Wk12 Tutorial IAB305 Enterprise systems Lifecycle Science Faculty: School of Information Systems Tutor: CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Impacts of Change Implementation of an Enterprise l...

Wk12 Tutorial IAB305 Enterprise systems Lifecycle Science Faculty: School of Information Systems Tutor: CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Impacts of Change Implementation of an Enterprise level IS project can be a transformational change. It can have a wide reaching effect on an organisation at many levels. Changes may effect: Customer Relationships Supplier relationships Staffing levels Policies & procedures Business Processes All of these will affect the employees who work there! CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Impacts of Change The majority of People, do not like and resist change! Especially in the workplace. They will have many reasons for this: Is my job safe? Fear of the unknown Disrupted routines and habits This where good Loss of confidence or control of their role leadership and emotional intelligence Risk of embarrassment comes into play! CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Impacts of Change Change must be managed carefully and documented. Within a managed project change is initiated with a “Request for Change” document. It should contain: The project name The request number The requestor Description of the change The reason for the change The impact of the change The proposed action to be taken The business priority of the change CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Prepare to Manage Change People factors have the highest level of difficulty and the longest time to resolve of any dimension of change management A skilled Change Manager is required! CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Change Manager Skillset Change managers need four core competencies: 1. Good intrapersonal skills. 2. Good interpersonal skills. 3. General consultation skills. 4. An understanding of organisation development theory. CRICOS No.00213J Waddell, Creed, Cummings & Worley- Change management 7th Ed IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Organisational change management Organisation-wide transformations resulting from business process initiatives have significantly increased the importance of managing the effect of change on staff, systems and culture Staff education is a critical aspect of introducing new IS initiatives Explaining the rationale for the new system Explaining how staff will be impacted Treating users as stakeholders and involving them in development processes Training users in use of the new system Engaging with users and acting on their suggestions CRICOS No.00213J Bocij, Greasley & Hickie, Business Information Systems, Pearson 2015 IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Encouraging user involvement in IS initiatives Appoint senior managers as system sponsors or champions Identify and engage system owners early in IS initiatives Identify stakeholders at all operational location for the new IS initiative Understand the notions of: Legitimisers who guard the operational norms and value expected from the new system; experienced in their job roles they are viewed as experts by other staff Opinion leaders who other staff will watch to see if they embrace the new system and associated changes Both parties needs to be involved early in planning and developing the new system CRICOS No.00213J Bocij, Greasley & Hickie, Business Information Systems, Pearson 2015 IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Staff reactions to change (Hopson & Scally) Resistance to change is inevitable and needs to be carefully managed. It may occur in the form of: Aggression – various forms sabotage of new IS initiatives Projection – where system is blamed for difficulties arising Avoidance – where staff withdraw from or simply avoid using it or adopt manual alternatives Targeted training and education are essential… CRICOS No.00213J Bocij, Greasley & Hickie, Business Information Systems, Pearson 2015 IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Change management approach I Implementing a new IS initiative should involve: Developing an action plan Assigning managers as change sponsors or champions Identifying and engaging system owners early in IS initiatives Identifying stakeholders at all operational location for the new IS initiative Developing employee change teams Encouraging open communications and feedback about organisational changes CRICOS No.00213J Bocij, Greasley & Hickie, Business Information Systems, Pearson 2015 IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Change management approach II Key tactics recommended by change experts Involve as many people as possible in IS initiative planning and development activities Make constant change an expected part of the culture Tell everyone as much as possible about everything, as often as possible, in person Make liberal use of financial incentives and recognition Work within the company culture, not around it CRICOS No.00213J Bocij, Greasley & Hickie, Business Information Systems, Pearson 2015 IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Change Management Models Implementing an IS solution requires change within an organisation How are we to manage this process? There are a selection of models and frameworks that can be adopted. These provide guidance and prompt questions that should be asked This helps to build a Change Management Strategy which you can plan and put into practice CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  ADKAR Model Individual goal-oriented model – focuses on activities that achieve results Developed by Prosci in the late 1990s Assists with diagnosing resistance to change and goal setting for change participants Awareness of the need to make a change Desire to participate and support the change Knowledge of how to make the change Ability to implement the change Reinforcement to keep the change in place CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Six Change Model Six approaches to dealing with resistance Education & communication 1. Education and communication Explicit & implicit Participation & Involvement 2. Participation and involvement coercion 3. Facilitation and support Overcome Resistance to Change 4. Negotiation and agreement Manipulation Facilitation 5. Manipulation and co-option & co-option & Support 6. Explicit and implicit coercion Negotiation & Agreement Developed by Kotter & Schlesinger, 1979 Focuses on minimising/decreasing resistance to change How does your strategy facilitate each of these approaches ? CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Lewin’s Freeze Change Model Lewin & Schein model for achieving organisational change: 1. Unfreeze present position creating a climate for change by educating/engaging future participants 2. Change from present position to new system 3. Refreeze by making the system an accepted part of the organisation 1.Unfreeze 2.Change 3.Freeze CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  McKinsey 7S Model Developed by Peters & Waterman whilst at McKinsey & Co in 1984 Iterative process Aims to assess current state of an organisation, compare current state to desired state, identify gaps and create a plan to address them Strategy: a plan required to achieve an organisation’s vision and meet required overall objectives Structure: evaluate if organisational structure and leadership can meet the needs of the organisation once change is enacted Systems: evaluation of the policies, processes, and procedures of an organisation Shared values: evaluation of core values of the organisation Skills: evaluate skills at three levels: desired, those needed for the change journey, and current Style: evaluation of the effectiveness of leadership in the organisation Staff: reviewing what is required for staff to be successful CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Kotter’s Eight Step Model Eight step model for change 1. Establish a sense of urgency proposed by Kotter in 1996 Focuses on building employee 2. Create a guiding coalition support and understanding along with strengthening change and 3. Develop a vision and strategy accountability Provides an instructional 4. Communicate the change vision perspective of what you should do Based on an organisational 5. Empower broad-based action perspective 6. Create short-term wins 7. Consolidate gains and produce more change 8. Anchor new approaches in the culture CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  What is Risk? Risk can be defined as the possibility of danger, harm or loss. Risk can be viewed as the combination of the likelihood of an event and the consequences or loss if the event occurs. Risk = Likelihood + Consequences CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  What is Risk? Risk Management - identifying, analysing, and responding to risk factors throughout the life of a project. Project risk - any possible event that can positively or negatively affect the viability of a project or the project’s objectives. Risk exists the moment a project is conceived. Risk = (Probability of Event)×(Consequences of Event) Probability: 0 (almost never) to 1 (almost surely), or 0% to 100% Consequence: $ value No.00213J CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  What is Risk? Risk vs. Stake (amount invested) As the Project progresses in time, Pre-project Initiation Delivery Final the level of risk rises in line with the stage Stages Stage amount of investment at stake and while the value of the finished Opportunity and risk Increasing Risk project increases. $ Value Period of highest risk Amount at stake impact Time No.00213J CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Managing Risk in Prince2 PRINCE2 recommends that each project have its own Risk Management Strategy document. Produced during project Initiation Risk Management Strategy document; defines the procedures of how Risk will be identified, assessed, controlled and communicated is created and customised to suit the project in the Initiation stage by the Project Manager. No.00213J CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Managing Risk in Prince2 Risk Management procedure: 1. Identify (Event and Cause) Record all related details in the Risk Register 2. Assess (Probability impact; Proximity) Probability impact (to project objectives) - low, med, high Proximity (likelihood or how soon) - low, med, high 3. Plan the response Threat (Avoid; Reduce; Transfer; Fall back; Accept, Share) Opportunity (Exploit, Enhance, Reject Share) 4. Implement the response Risk Owner and Actionee 5. Communicate Reports: Checkpoint, Highlight, End stage No.00213J CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Risk Assessment Risk Assessment is the use of standard techniques (eg. ISO 27005, 31000) to identify potential threats (issues) to the continuity of a service and the likelihood of their occurrence and their impact Once identified and understood, threats can be evaluated and reduced with the help of risk analysis Risks may appear and disappear during a Project at specific times Risks are re-assessed during the project CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Risk Assessment Techniques to identify Risks; Categories of Risk; Brainstorming meetings (Question: Can you think of examples for each type?) Expert opinion Technology Risks Past history People Risks Multiple (or team based) assessments Organisational Risks Delphi Requirements Risks Inductive reasoning (ex; HAZOP) Estimation Risks Internal Risks External Risks No.00213J CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Risk Assessment List All Risks CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Risk Assessment Used to Label Risks once identified and assessed A quick reference method of identifying a risk profile CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Risk Management - Responses Four basic risk Management Strategies Avoid Change process /procedure to avoid risk Transfer Outsource risk to a third party specialist Reduce Good Project Management Practice Accept Risks outside our control, (weather, war etc) No.00213J CRICOS No.00213J https://reciprocity.com/risk-control-risk-management-whats-the-difference/ IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Exercise 1: Risk Identification One of the most famous system failures was the Denver International Airport’s (DIA) baggage system. When the automated baggage system design for DIA was introduced, it was hailed as the saviour of modern airport design. The design relied on a network of 300 computers to route bags, and 400 delivery belts to carry luggage across more than 33km of track. Laser scanners were to read barcoded luggage tags, while advanced scanners would track the movement of toboggan-like baggage carts. DIA opened its doors for reporters to witness its revolutionary baggage handling systems as soon as the system development was finished. The scene was rather unpleasant. Bags were chewed up, lost and misrouted, in what has since become a legendary systems nightmare. One of the biggest mistakes in the baggage handling system fiasco was that not enough time was allowed to develop the system properly. At the beginning of the project, DIA assumed it was the responsibility of the individual airlines to find their own way of moving the baggage from the plane to the baggage claim area. The automated baggage system was not involved in the initial planning of DIA project. By the time the developers of DIA decided to create an integrated baggage system, the time frame for designing and implementing such a complex and huge system was impossibly short. Another common mistake that occurred during the project was that the airlines kept changing their business requirements. This caused numerous issues, including the implementation of power supplies that were not properly updated for the revised system design, which in turn caused overloaded motors and mechanical failures. Besides the power supply design problem, the optical sensors did not read the barcodes correctly, causing issues with baggage routing. Finally, BAE, the company that designed, developed, and implemented the automated baggage system for DIA, had never created a baggage system of this size before. BAE had created a similar system in an airport in Munich, Germany, where the scope was much smaller. Essentially, the baggage system had an inadequate infrastructure since it was designed for a much smaller system. DIA simply could not open without a functional baggage system, so the city had no choice but to delay the opening for over 16 months, costing taxpayers roughly US$1 million per day, which resulted in a loss of around US$500 million. Question: What risks were involved in the project and how could they be addressed to save taxpayers hundreds of millions of dollars? CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Exercise 1: Risk Identification Group/Class Discussion: CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Exercise 1: Risk Identification Suggested Answers: 1. Timeline: One of the biggest mistakes in the baggage handling system fiasco was that not enough time was allowed to develop the system properly. 2. Roles misunderstanding: DIA assumed it was the responsibility of the individual airlines to find their own way of moving the baggage from the plane to the baggage claim area. 3. Integration Requirements were missing: The automated baggage system was not involved in the initial planning of DIA project. By the time the developers of DIA decided to create an integrated baggage system, 4. Changing Requirements: Another common mistake that occurred during the project was that the airlines kept changing their business requirements. 5. Capacity Management: Besides the power supply design problem, the optical sensors did not read the barcodes correctly, causing issues with baggage routing. 6. Technical Capability of the third-party vendor: had never created a baggage system of this size before. CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Exercise 2: Change Management Strategy Throughout the 1960s, 1970s, and 1980s, the U.S. Army automated its installations (“army bases,” in civilian terms). Automation was usually a local effort at each of the more than 100 bases. Although some bases had developed software together (or borrowed software developed at other bases), each base often had software that performed different functions or performed the same function in different ways. In 1989, the army decided to standardize the software so that the same software would be used everywhere. This would greatly reduce software maintenance and reduce training when soldiers were transferred between bases. The software took four years to develop. The system was quite complex, and the project manager was concerned that there was a high risk that not all requirements of all installations had been properly captured. The cost and time were less important since the project had already run for four years and costed $100 million. Therefore, the project manager chose a modular pilot rollout plan using parallel changeover. The manager selected seven installations, each representing a different type of army installation (e.g., training base, arsenal, and depot) and began the rollout plan. All went well, but several new features were identified that had been overlooked during the analysis, design, and development. These were added and the pilot testing resumed. Finally, the system was installed in the rest of the army installations using a phased direct changeover of the whole system. Question: Based on the case study, suggest an organisational change management method, and explain why you think it is appropriate for organisational change management? CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Exercise 2: Change Management Strategy Group work/Class Discussion: CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Exercise 2: Change Management Strategy Suggested Answers: McKinsey’s 7S is the preferred method, this is a big complex, enterprise-wide change. It would have allowed them to closely look at all aspects of the organisation. CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems  Thank you for attending! See you next time! CRICOS No.00213J IAB305 Enterprise Systems Lifecycle Science Faculty: School of Information Systems