Planning Phase: Business System Development

Lesson 2 – PLANNING PHASE A. Project Identification and Initialization Project Identified when someone in the organization identifies a business need to build a system. This could occur within a business unit or IT, discovered a steering committee charge with identifying business opport...

Lesson 2 – PLANNING PHASE A. Project Identification and Initialization Project Identified when someone in the organization identifies a business need to build a system. This could occur within a business unit or IT, discovered a steering committee charge with identifying business opportunities or evolve from a recommendation made by an external consultants. Business needs also can surface when the organization identifies unique and competitive ways using IT. Many organizations keep an eye on emerging technology which is technology that is still being developed and not yet viable for widespread business use. Both IT people and business people should closely work together to find ways for technology to support business needs Project Sponsor Someone who recognizes the strong business need for a system and has an interest in seeing the system succeed. He will work throughout the SDLC to make sure that the project is moving in the right direction from the perspective of the business. He serves as the primary point of contact for the system. Size or Scope of the Project Determines the kind of sponsor that is needed. A small size may require sponsorship on a single manager; while large size may need support may need from the entire senior management team or even the CEO. If the project is purely technical in nature, then the sponsorship from IT is appropriate. Business Requirements Requirements are what the IS will do or what functionality it will contain. They need to be explained at a high level so that the approval committee and the project team understand what the business expects from the final project. Business Requirements are what features and capabilities the IS will have to include. Business Value The project sponsor should have an idea of the business value to be gained from the system, both tangible and intangible. Tangible value can be quantified and measured easily while intangible value results from the intuitive belief that the system provides important, hard to measure and benefits to the organization. System Request A document that describes the business reasons for building a system and the value that the system is expected to provide. Elements of System Request - Project Sponsor The person who will serve as a primary contact for the project. - Business Need Presents the reasons prompting the project. - Business Requirements Refer to the business capabilities that the system will need to have. - Business Value Describes the business benefits that the organization expects from the system - Special Issues or Constraints Includes on the document as a catchall category for other information that should be considered in assessing the project. A. Feasibility Analysis Guides the organization in determining whether to proceed the project or not. It identifies the important risks associated with the project that must be addressed if the project is approved. 1. Technical Analysis The extent to which the system can be successfully designed, developed and installed by the IT group. It strives to answer the question: “Can we build it?”. a. Familiarity with the Application When the analysts with the business application area they have greater chance of misunderstanding the users or missing opportunities for improvements. b. Familiarity with the Technology When the system will use technology that has not been used before within the organization, there is a greater chance of problems will occur and delays will be incurred because of the need to learn how to use the technology. c. Project Size Measured as the number of people on the development team, the length of time it will take to complete the project or the number of the distinct features of the system. d. Compatibility New technology and applications need to be able to integrate with the existing environment for many reasons. 2. Economic Feasibility  Also called as Cost-Benefit Analysis (CBA) that identifies the financial risk associated with the project. It attempts to answer the question: “Should we build the system?”. It is determined by identifying the costs and benefits associated with the system, assigning values to them and then calculate the cash flow and return of investment for the project. a. Identify the Cost and Benefits Lists the tangible and intangible benefits for the project. It includes both the one-time and recurring costs. b. Assign Values to Costs and Benefits Work with business users and IT professionals to create numbers for each of the costs and benefits. Both tangible and intangible should be valued. c. Determine the Cash Flow Forecasts what the cost and benefits will be over a certain period time, usually three to five years. Apply a growth rate to the values if necessary. d. Assess Project’s Economic Value Evaluates the project’s expected return in comparison to its costs. Use one or more of the following evaluation techniques: Return of Investment (ROI) Calculates the rate the returned earned on the money invested in the project using the ROI formula. Break-Even Point (BEP) Finds the year in which the cumulative project benefits exceed cumulative costs. Apply the break-even formula using the figures for that year. This calculations measures how long it will take for the system to produce benefits that covers its costs. Net Present Value (NPV) Restates all costs and benefits in today’s present value, using an appropriate discount rate. Determines whether the total present value of benefits is greater than or less than the present value of costs. Table 2 is sample CBA (in PhP, increased/decreased by 5% yearly, round-off to one’s digit) 1. Organizational Feasibility How well the system ultimately will be accepted by its users and incorporated into the ongoing operations of the organization. It attempts to answer the question: “If we build it, will they come?”. a. Strategic Alignment It is the fit between the project and business strategy, the greater alignment, the less risky the project will be, form an organizational feasibility perspective. Many  IT projects fail when the IT department initiates them, because there is little or no alignment with business unit or organizational strategies. a. Stakeholder analysis Stakeholder is a person, group or organization that can affect or can be affected by a new system. Champion A high level executive and is usually the project sponsor who created the system request. He supports the project by providing time and resources and by giving political support within the organization by communicating the importance of the system to other organizational decision makers. Organizational Management Management support conveys to the rest of the organization the belief that the system will make a valuable contribution and that necessary resources will be made available. It encourages people in the organization to use the system and to accept the many changes that the system will likely create. System Users The ultimately will use the system once it has been installed in the organization. They perform tasks, providing feedback and making decisions.