Management Issues in Systems Development

1. Management Issues in Systems Development Chapter 10 Information Systems Management in Practice 8th Edition

2. Today’s Lecture • Introduction • Project Management • Definition, scope, best practices • Change management • Risk management • Modernizing Legacy Systems • To replace or not to? • Improvement

3. Today’s Lecture • Measuring systems benefits • Differentiating systems roles • IT investment assessments • Return on (IT) Investments • Conclusion

4. Introduction • What are the management issues surrounding systems development? • IS as three separate businesses (lens) • Infrastructure management (operations) • Customer relationship (helpdesk) • Product innovation (systems development) • Project management is most sought-after skill in systems development today

5. Introduction • IS as three separate businesses (lens) • Infrastructure management (operations) • Goal: reduce cost • Customer relationship (helpdesk) • Goal: Service • Often outsourced • Customer is the king • Product innovation (systems development) • Goal: Speed • Developer is the king

6. Project Management • Project is a collection of related tasks and activities undertaken to achieve a specific goal within a finite time period (temporal) • IT projects are similar to other forms but arguably more difficult • Intangibility (you cannot see it or feel it!) • IT project management • Coordination (managing interdependencies of numerous tasks)

7. Project Management cont’d • PMI (Project management Institute) • Established the standard for project management • The leading association in educating project managers in all fields • Certificate: PMP (Project Management Professional) • Book: A Guide to the Project Management Body of Knowledge (PMBOK) • Five processes: Initiation, planning, executing, controlling, and closing

8. Scope: Job of a Project Manager • Getting the project started • Managing the schedule • Managing the budget • Managing the benefits • Managing the risks, opportunities and issues • Soliciting feedback and formative evaluation

9. Scope: Job of a Project Manager cont’d • Risk: A potential threat or something that can go wrong that may prevent the project from achieving its business benefits • Risk Register (Risk Log) • Risk has potential to be happened • Opportunity: A project going better than planned • Issue: Something that threatens the success of the project • Issue log (Issue list) • Issue has already happened

10. A Day In the Life of an IT Project Manager • Larry Cone is VP Software Development • Cone began a highly informative and entertaining blog about his day-to-day experience • September 16, 2007: Learning from Failure • May 24, 2007: Everything You Need to Know about Software Architecture in kindergarten • October 10, 2006: To the user, definitions are the key • September 5, 2006: Don’t do the Wrong System

11. Change Management • Managing change (people side of system) • Assimilation of new systems into work processes • Resistance (organizational inertia) • Sponsor: Person or group that legitimize the change • Change agent: Person or group who causes the change to happen • Target: Person or group who is being expected to change

12. Risk Management • Management of risks in IT projects crucial • Technical risk • Sub-performance; scope creep • Business risk • IT-triggered organizational change not as planned • Three-step process whenever the main risks in the project change • Assess the risk • Mitigate the risk • Adjust project management approach

13. Risk Management cont’d • Assess change risks (predominant factors) • Leadership • Project leader should be business executive • How does project leadership affect outcome? • Employees’ perspective • How would they react and why? • Scope and urgency • Is the scope too wide? How urgent? • “plus-minus” decision tree • plus sign: positive support for business change • Minus sign: negative support for business change

14. Risk Management cont’d

15. Risk Management cont’d • Mitigate the risks • Risk avoidance • Identify and eliminate source of perceived risk • Risk limitation • Implementing controls to contain potential risk effects • Risk transfer • Letting others assume risk (outsourcing)

16. Risk Management cont’d • Adjust project management approach • Project management style • Authoritative vs. participatory • Project budget and timeframe • Rigid vs. flexible • Four Approaches • Big Bang Approach (all other 3 must be positive) • Improvisation • Guided evolution • Top-down coordination

17. Gibson’s Four Approaches to Risk Management

18. Dow Corning Case Example: Risk Management • Successful ERP implementation (1995-1999) • How did it manage the different business risks? • Phase 0: Get Ready (assessed risks) • Leadership (high) • Employee perception (high) • Scope and urgency (high)

19. Dow Corning cont’d • Phase 1: Understand the new system • Used improvisation approach of participatory management and flexible deadlines • Emphasized building employee commitment • Phase 2: Redesign work processes • Used guided evolution approach of participatory management and fixed deadlines • Achieving employee commitment did little to get work processes redesigned • Continued through the pilot (ERP cutover in new European subsidiaries)

20. Dow Corning cont’d • Phase 3: Implement ERP worldwide • Used top-down coordination with an authoritative management style and flexible timelines • Pilot’s success demonstrated managers’ resolve and shifted employee perception to the positive • “Company wide” scope created negative shift • Phase 4: Complete implementation • Used the Big Bang approach of authoritative management and firm deadlines • ERP implemented in most sites by 1998, so all risk factors turned positive

21. Fast Tips: Good IS Management • Establish the ground rules • Foster discipline, planning, documentation and management • Obtain and document “final” user requirements • Obtain tenders from all appropriate potential vendors • Include vendors in decision making • Convert existing data • Follow through after implementation

22. Modernizing Legacy Systems • BCG study: Replace or not? • About 40% of replacement projects fail • Seduction of “new toys” • Upgrading is a better option • BCG three analyses (replace or not) • Costs-benefits of system • Fit between new system and business needs • IS staff capabilities (Can they do the job?)

23. Options for Improving Legacy Systems • Restructuring the system • Getting system ready for reengineering • e.g., An application working fine but not running efficiently needs restructuring • 7 steps involved in the process

24. Restructuring the System

25. Options for Improving Legacy Systems cont’d • Reengineering the system (not BPR) • Reverse Engineering • Extracting and converting data elements from existing systems and formats • Forward Engineering • Moving them to new hardware platforms and creating new applications

26. Reengineering the System

27. Verizon Directories Case Example: Reverse Engineering • Produced, marketed and distributed telephone directories • Directory publishing system • Four main databases, designed application by application • Data elements difficult to change, enhance and reuse • Acquired reengineering tools to improve databases

28. Verizon Directories • Blueprint project • Used a graphical tool to “reverse engineer” a poorly designed database from its physical to its data model, and designed a new data model (blueprint) that is more flexible • Reuse project • Employed reengineering tools to reuse data elements in the largest existing database to create a new production scheduling system

29. Options for Improving Legacy Systems cont’d • Refurbishing the system • Add new extensions to a “good working” old system • Some examples of legacy system extensions • Supply input in a new manner • Make new uses of input • Allow programs to deal more comprehensively with data • Add a Web interface around a “blackbox” • e.g., FedEx’s package tracking system

30. Options for Improving Legacy Systems cont’d • Rejuvenate the system • Adding new functions to a reengineered system to make it more valuable • Phases of rejuvenation process • Recognize a system’s potential • Clean up the system and make it more efficient • Establish a strategic role for the system • Add new functionalities to create business value

31. Amazon.com Case Example: System Rejuvenation • Initiated Web Services program (2002) • Access to Amazon’s state-of-art Web technology platform (pay for what you use) • No control over how subscribers use its system, but in return, others are creating gadgets, links, services, and software that Amazon.com cannot accomplish on its own • Diversify into e-commerce platform business • Used Web Services to rejuvenate its internal system by giving it a strategic role via XML

32. Options for Improving Legacy Systems cont’d • Rearchitect the system • Involves having an architecture for new systems, and then using that design to upgrade legacy systems • CTOs now devising enterprise level IT architecture • How systems are interconnected • One-system-at-a-time migration strategy

33. Toyota Motor Sales Case Example: Rearchitect the System • Created global reference IT architecture • Standard and integrated application development environment • Mapping of business requirement to IT strategies • New architecture enabled the company to • Remediate legacy systems • Keep systems designs robust • Deliver application faster • Permit future flexibility

34. Options for Improving Legacy Systems cont’d • Replace with a package or service • Replace a legacy system with a commercial package • Commercial packages have many options and features that can be customized • Replace with service delivered over the Internet • Quick availability • Outsource IS responsibility to vendors • Cost can be expensed (tax benefits)

35. Wachovia Case Example: Replace with a service • Legacy contact management system • Incompatible with new systems and not adaptable for new business needs • Maintained by consultants ($) • Replaced with SalesForce CRM system • Pay by use • Equivalent to maintenance costs • Provides necessary management information

36. Options for Improving Legacy Systems cont’d • Rewrite the system • System is “too far gone” to rescue • Code convoluted and patched; technology antiquated • Alternative to replacement • Rare (usually only for very specialized systems)