The Traditional System Development Life Cycle SDLC Need

The Traditional System Development Life Cycle (SDLC) Need Planning Analysis Design Implementation System

System Implementation Headaches and How to Spot Them 1 No project team or management support. 2 Hazy purpose, no defined schedule, a ballooning scope. 3 Unclear aspects of make-vs. -buy decisions. 4 Few product integrations are functional right out of the box. 5 Qualitative benefits, some benefits (and costs) are fuzzy. 6 No user buy-in. 7 Poor project management skills. 8 No accountability and no responsibility.

A Project Management Primer Trepper (2000 a) • • • Defining requirements. Managing change. Obtaining executive-level-buy-in. Setting project timelines based on realistic goals and priorities. Solving project management problems with a technology silver bullet or training. 5 things that many firms do not do at all: • • • Establish or define baselines. Have defined project control functions. Offer formal training. Take the time to define repeatable processes. Correctly estimate how difficult or complex a program is.

Project Management Skills • Leadership • Communication • Conflict resolution • Negotiation • Team building • Listening skills • Relationship management

Project Success Factors 1 2 3 4 5 6 7 8 9 10 Executive support. End-user involvement. Experienced project manager. Clear business objectives. Minimized scope. Standard infrastructure. Firm basic requirements. Formal methodology. Reliable estimates. Skilled staff.

Software Project Risks • • • Lack of top management commitment to the project. Failure to gain user commitment. Misunderstanding the requirements. Lack of adequate user involvement. Lack of required knowledge/skills in the project personnel. Lack of frozen requirements. Changing scope/objectives. Introduction to new technology. Failure to manage end user expectations. Insufficient/inappropriate staffing.

Anatomy of a Data Warehouse Implementation Failure Red Flags • No prelaunch objectives or metrics. • Many major systems projects underway simultaneously. • The CEO set budgets and deadlines before the project team was on board. • No insider presence on the data warehouse project team. • Overburdened project manager. • Source data availability unconfirmed at the outset. • No user demand for sophisticated data analysis. • No routine meetings of executive sponsors and project manager. • No initial involvement of business managers. • Failure of the pilot project. Lessons Learned • Executive sponsorship and partnership with IS are the most critical success factors for developing a data warehouse. • Don’t let the project proceed without a clear understanding of the business objectives and how they will be measured. • Do an incremental pilot project to determine whether you can obtain the projected benefit. • Expect to make a major investment in ongoing management of the data warehouse. • When all else fails, cut and run.

Prototyping Development Process: A Rapid Application Development (RAD) Method Need Planning Analysis Design Implementation Prototype Not OK Prototype OK Implementation System

Throwaway Prototyping Development Process: Another Rapid Application Development Method Need Planning Design Prototype OK Design Prototype Not OK Design Analysis Implementation Design Prototype System

Prototyping works because… • Gain the unshakable support of the company’s top business executive. • Align new systems across several business processes, not just one. • Slice up a project into pieces. • Deliver results in phases, not at the end.

How Companies Speed IT Deployment 1 Target small, tactical applications. 2 Make application deployment iterative and open to customization. 3 Use commodity hardware. 4 Use object technology. 5 Develop big projects already underway. 6 Break major projects into manageable deliverable chunks. 7 Use packaged applications. 8 Employ IT service providers.

How to Engage Users in Software Development 1 2 3 4 5 6 7 8 9 10 Get management buy-in. Understand the users’ business. Consider the users’ priorities. Assign good communicators. Talk with users all along the business process. Don’t meet at their offices. Turn off cell phones. Focus on users’ problems, not IT. Listen well; explain things back. Use prototypes.

Change Management • Unfreezing. Create an awareness of the need for change and a climate receptive to change. • Moving. Change the magnitude and/or direction of the forces defining the initial need for change by developing new methods and learning new attitudes and behaviors. • Refreezing. Reinforce the desired changes that have occurred and establish a maintainable and stable new equilibrium.

Favorable and Unfavorable Forces During Stages of Lewin-Schein Change Model Stage of Change Unfreezing Favorable Forces • Top managers felt the problem was important to the company • Top management became involved • Unit management recognized a need to change • Top management initiated the project • Both top management and unit management were open and candid during discussion • Unit managers were willing to revise some of their initial assumptions Moving Refreezing Unfavorable Forces • Unit managers were unable to state their problems clearly • Top management felt the overall problem was too big • Unit management felt threatened by the project • Some unit management resented the project • Unit management lacked confidence in the analysis • Unit managers felt they were capable of handling the project alone • Unit management and analysts gathered data jointly • All relevant data were accessible and available • New alternations were devised • Unit management reviewed and evaluated all alternatives • Top management was advised of options • Top management was participated in the development of a solution. • All proposals for solutions were improved sequentially • Analysts were often not effective in educating unit management • Unit management tried the solution • Frequency of utilization demonstrated the superiority of the solution • Analysts initiated positive feedback after early adoption and use • Final solution was widely accepted after initial success • Unit management expressed satisfaction wit the new solution • Analysts did not try to support new managerial behavior after the solution was used • Analysts did not try to reestablish stability after the solution was used • Results were often difficult to quantify or measure • Unit management did not participate in the development of new solutions • Unit management often did not fully understand the proposed solution of the analysts • Analysts felt the project was concluded too quickly

Selecting a Vendor 1 Establish the need as it relates to the business. 2 3 3 4 5 5 6 7 8 9 10 11 12 Select a team that includes both technical and management members. Chose a strategy. Attempt to standardize. Write a request for proposals (RFP). This forces the team to consider what is important. Focus on the total cost of ownership, not just the initial cost. Develop your negotiation strategy in parallel with your RFP. Consider the value of relationships as you evaluate bids. Keep your options open. Be a good customer. If possible, split the contract between two vendors. Anticipate the future. Stay pragmatic. Do not let technology distract you.