1. 788 Post-Implementation Change Managing Incremental System Change (cf. ACM paper)  Implementation of entire systems and processes completely new ‘full replacement’ ‘radical’ BPR  Is well understood  There are methods and best practices

2. 788 Post-Implementation Change Incremental changes  The implementation of incremental changes such as: Maintenance (fixes) Upgrades Incremental enhancements  Are much less well understood  Frequently they are assumed to be unproblematic

3. 788 Post-Implementation Change Ignored Changes  One common change to the composite system – personnel – is largely ignored  We will explore the different effects from: Changes to operations personnel Changes to management

4. 788 Post-Implementation Change Incremental Change Defined  The effects of incremental changes are poorly anticipated because such changes: Are frequently inexpensive (relative to the cost of the total system) Effect only a portion of the total system Are frequently delegated to very new or very old IS personnel (the ‘hot’ talent likes to be assigned to the highest visibility projects – and nobody likes bug fixes)

5. 788 Post-Implementation Change Low cost means:  Low visibility within the IT department and in the organization. Incremental changes can frequently ‘slip under the radar’ of IT oversight committees.  It is human nature in general to allocate attention based on cost (resource consumption). End users expect low cost to equal simple and quick  However low cost changes are not necessarily low impact changes  A simple example: an increase in the length of a part number takes only 5 minutes after midnight with some DBMS – but renders 5000 cases of expensive preprinted forms useless. (Cost of change: $200. Cost of forms: $200,000)

6. 788 Post-Implementation Change Incremental Process Change  Since business users can implement manual process changes without IT assistance, such changes are even more vulnerable to incremental change side effects.  Another simple example: one university removed secretaries from the loop in expense reimbursement processing reasoning faculty could do it themselves and save money. The secretaries were vital for error checking the expense forms. The change failed.

7. 788 Post-Implementation Change Maintenance fixes  AKA ‘bug’ fixes “Make the system not crash!” “Make the system do what it is supposed to do!”  Arguably the lowest potential for retraining and unanticipated side effects since when accomplished properly the changes simply cause the system to “do what it’s supposed to.”

8. 788 Post-Implementation Change Maintenance fixes (2)  However few changes are free of side effects  True ‘bugs’, i.e. typos or minor misunderstanding are unproblematic  If the misunderstanding is fundamental, then the fix can have unintended consequences  Example from practice: a report is incorrect. The user assumes the only change required is to the print format. In fact, the analyst misunderstood the requirements and 2 additional pieces of data need to be captured on the order form, which ripples through the system...

9. 788 Post-Implementation Change Upgrades  IT departments have learned to justifiably fear upgrades to widely used software due to: Possible increase in cost Retraining Resentment from users Incompatibility with prior versions Loss of functions from prior versions  However maintenance agreements frequently require upgrades  Larry Wood’s (COBA Systems Administrator) on upgrading Office

10. 788 Post-Implementation Change Incremental Enhancements  It has been said that “the only system that is truly finished is one that is no longer being used.”  Successful systems are usually enhanced continually  As with other incremental changes the effects on the organization are frequently underestimated (cf. the reading on post-deployment changes)

11. 788 Post-Implementation Change Incremental Enhancements (2)  IT departments can be proactive by insisting (sometimes uncomfortably) that the true cost of an enhancement be recognized: Software cost Retraining Downtime A very real possibility of introducing a new round of bug fixes to an otherwise completed system

12. 788 Post-Implementation Change Personnel Changes  Changes in personnel can have predictable effects on fully implemented systems  New management personnel will frequently see opportunities for enhancements to fit their style of management or to fix real or perceived shortcomings in the existing system.  IT should plan for this and meet with the new management at the earliest convenient opportunity.

13. 788 Post-Implementation Change Personnel Changes (2)  Changes (attrition) in operations personnel can have curious effects.  Systems that have been stable for years can suddenly develop a number of ‘bugs’.  In fact, knowledge of workarounds known to previous operators has left with the old operator.

14. 788 Post-Implementation Change Personnel Changes (3)  Loss of in-depth system behavior (workarounds) can be highly problematic since such workarounds may have hidden system ‘bugs’ from both IT and operations management for years.  Possible solution: Open communication with end users. Meet with them and encourage discussion of ANY aspect of the system. Anticipate retraining whenever key operations personnel leave the organization. Document system procedures more fully