Modern Systems Analysis and Design PDF

Modern Systems Analysis and Design Chapter 5 Initiating and Planning Systems Development Projects  Learning Objectives ✓ Describe the steps involved in the project initiation and planning process. ✓ Explain the need for and the contents of a Project...

Modern Systems Analysis and Design Chapter 5 Initiating and Planning Systems Development Projects  Learning Objectives ✓ Describe the steps involved in the project initiation and planning process. ✓ Explain the need for and the contents of a Project Scope Statement and Baseline Project Plan. ✓ List and describe various methods for assessing project feasibility. ✓ Describe the differences between tangible and intangible benefits and costs and between one-time vs. recurring benefits and costs. 2  Learning Objectives (Cont.) ✓ Perform cost-benefit analysis and describe what is meant by the time value of money, present value, discount rate, net present value, return on investment, and break-even analysis. ✓ Describe the general rules for evaluating technical risks associated with a systems development project. ✓ Describe the activities and participant roles within a structured walkthrough. 3  Initiating and Planning Systems Development Projects ◼ What must be considered when making the decision on the division between Project Initiation and Planning (PIP) and analysis? ◼ How much effort should be expended on the PIP process? ◼ Who is responsible for performing the PIP process ◼ Why is PIP such a challenging activity? 4 The Process of Initiating and Planning IS Development Projects FIGURE 5-1 Systems development life cycle with project initiation and planning highlighted 5  The Process of Initiating and Planning IS Development Projects (Cont.) ◼ Project initiation focuses on activities designed to assist or help in organizing a team to conduct project planning. 6  The Process of Initiating and Planning IS Development Projects (Cont.) ◼ Establishing the Project Initiation Team. ◼ Establishing a Relationship with the Customer. ◼ Establishing the Project Initiation Plan. ◼ Establishing Management Procedures. ◼ Establishing the Project Management Environment and Project Workbook. ◼ Developing the Project Charter. 7  The Process of Initiating and Planning IS Development Projects (Cont.) ◼ The key activity of project initiation is the development of the project charter.  A short document that is prepared for both internal and external stakeholders  Provides a high-level overview of the project  Useful communication tool that helps to assure that the organizations and other stakeholders understand the initiation of a project 8  The Process of Initiating and Planning IS Development Projects (Cont.) ◼ A project charter typically contains:  Project title and date of authorization  Project manager name and contact information  Customer name and contact information  Projected start and completion dates  Key stakeholders, project role, and responsibilities  Project objectives and description  Key assumptions or approach  Signature section for key stakeholders 9  The Process of Initiating and Planning IS Development Projects (Cont.) ◼ The key activity of project planning is the process of defining clear, discrete or separate activities and the work needed to complete each activity within a single project. ◼ The objective of the project planning process is the development of a Baseline Project Plan (BPP) and the Project Scope Statement (PSS). 10  Elements of Project Planning ◼ Describe project scope, alternatives, feasibility. ◼ Divide project into tasks. ◼ Estimate or guess resource requirements and create resource plan. ◼ Develop preliminary schedule. ◼ Develop communication plan. 11  Elements of Project Planning (Cont.) ◼ Determine standards and procedures. ◼ Identify and assess or evaluate risk. ◼ Create preliminary budget. ◼ Develop a statement of work. ◼ Set baseline project plan. 12  Deliverables and Outcomes ◼ Business Case  Justification for an information system  Presented in terms of the tangible and intangible economic benefits and costs  The technical and organizational feasibility of the proposed system 13  Deliverables and Outcomes (Cont.) ◼ Baseline Project Plan (BPP) A major outcome and deliverable from the PIP phase  Contains the best estimate of a project’s scope, benefits, costs, risks, and resource requirements 14  Deliverables and Outcomes (Cont.) ◼ Project Scope Statement (PSS) A document prepared for the customer  Describes what the project will deliver  Outlines at a high level all work required to complete the project 15  Assessing Project Feasibility ◼ Economic ◼ Technical ◼ Operational ◼ Scheduling ◼ Legal and contractual ◼ Political 16  Assessing Project Feasibility (Cont.) FIGURE 5-2 System Service Request for Customer Tracking System (Pine Valley Furniture). 17  Assessing Project Feasibility (Cont.) ◼ Economic feasibility: A process of identifying the financial benefits and costs associated with a development project  Often referred to as a cost-benefit analysis  Project is reviewed after each SDLC phase in order to decide whether to continue, redirect, or kill a project 18  Determining Project Benefits ◼ Tangible benefits: Refer to items that can be measured in dollars and with certainty or confidence. ◼ Examples include:  reduced personnel expenses,  lower transaction costs, or  higher profit margins. 19  Determining Project Benefits (Cont.) ◼ Most tangible benefits will fit within the following categories:  Cost reduction and avoidance  Error reduction  Increased flexibility  Increased speed of activity  Improvement of management planning and control  Opening new markets and increasing sales opportunities 20  Determining Project Benefits (Cont.) ◼ Intangible benefits are benefits derived from the creation or design of an information system that cannot be easily measured in dollars or with certainty.  May have direct organizational benefits, such as the improvement of employee morale or confidence.  May have broader societal implications, such as the reduction of waste creation or resource consumption. 21  Determining Project Costs ◼ Tangible cost: a cost associated with an information system that can be measured in dollars and with certainty ◼ IS development tangible costs include:  Hardware costs,  Labor costs, or  Operational costs including employee training and building renovations. 22  Determining Project Costs (Cont.) ◼ Intangible cost: a cost associated with an information system that cannot be easily measured in terms of dollars or with certainty ◼ Intangible costs can include:  Loss of customer goodwill,  Employee morale, or  Operational inefficiency. 23  Determining Project Costs (Cont.) ◼ One-time cost: a cost associated with project start-up and development or system start-up ◼ These costs encompass or include activities such as:  Systems development,  New hardware and software purchases,  User training,  Site preparation, and  Data or system conversion. 24  Determining Project Costs (Cont.) ◼ Recurring cost: A cost resulting from the ongoing evolution or development and use of a system ◼ Examples of these costs include:  Application software maintenance,  Incremental data storage expenses,  Incremental communications,  New software and hardware leases, and  Supplies and other expenses (i.e. paper, forms, data center personnel). 25  Determining Project Costs (Cont.) ◼ Both one-time and recurring or frequent costs can consist of items that are fixed or variable in nature. ◼ Fixed costs are billed or incurred(gained) at a regular interval and usually at a fixed rate. ◼ Variable costs are items that vary in relation to usage.(long distance phone charges) 26  Determining Project Costs (Cont.) ◼ Procurement  Consulting, equipment, site preparation, capital, management time ◼ Start-up  Operating systems, communications installation, personnel hiring, organizational disruption ◼ Project-related  Application software, software modification, personnel overhead, training, data analysis, documentation ◼ Operating  System maintenance, rental, asset depreciation, operation and planning 27  The Time Value of Money ◼ Most techniques used to determine economic feasibility encompass(include) the concept of the time value of money(TVM),which reflect the notion that money available today is worth(value,price) more than the same amount tomorrow.As previously discussed,the development of an information system has both one-time and recurring costs. ◼ Net Present Value (NPV)  Use discount rate to determine present value of cash outlays and receipts ◼ Return on Investment (ROI)  Ratio of cash receipts to cash outlays ◼ Break-Even Analysis (BEA)  Amount of time required for cumulativeincreasing cash flow to equal initial and ongoing investment 28  The Time Value of Money ◼ Suppose you want to buy a used car from an acquaintance (friend,collegue) and she asks that you make three payments of 1500$ for three years,beginning next year,for a total of 4500$.If she would agree to a single lump-sum payment at the time of sale(and if you had the money),what amount do you think she would agree to?should the single payment be 4500$?should it be more or less? To answer this question,we must consider the time value of money.Most of us would gladly accept 4500$ today rather than three payments of 1500$.because a dollar today is worth(value,price) more than a dollar tomorrow or next year, ◼ The rate at which money can be borrowed or invested is referred to as the cost of capital,and is called the discount rate for TVM calculations.Let suppose that the seller could put the money received of the sale of the car in the bank and receive a 10 percent return on her investment. A simple formula can be used when figuring out the present value of the three 1500$ payment. ◼ Time value of money (TVM): the concept that money available today is worth more than the same amount tomorrow ◼ Discount rate: the rate of return used to compute the present value of future cash flows (the cost of capital) ◼ Present value: the current value of a future cash flow 29  The Time Value of Money (Cont.) ◼ Net Present Value  PVn = present value of Y dollars n years from now based on a discount rate of i.  NPV = sum of PVs across years.  Calculates time value of money 30  The Time Value of Money (Cont.) ◼ Break-even analysis: a type of cost-benefit analysis to identify at what point (if ever) benefits equal costs Using data from figure 5-6 Break-Even ration = 15,303-9139 /15,303=.403 31  Assessing Technical Feasibility ◼ Technical feasibility: a process of assessing the development organization’s ability to construct a proposed system ◼ This analysis should include an assessment of the development group’s understanding of the possible target hardware,software and operating environments to be used,as well as system size,complexity and the group’s experience with similar systems. ◼ It is important to note that all projects have risk and that risk is not necessarily something to avoid. 32  Assessing Technical Feasibility ◼ The potential or possible consequences or cost of not assessing and managing risks can include the following:  Failure to attainget expected benefits from the project,  Inaccurate project cost estimates,  Inaccurate project duration estimates,  Failure to achieve adequate suitable system performance levels, and  Failure to adequately integrate the new system with existing hardware, software, or organizational procedures. 33  Project Risk Factors ◼ Project size  Team size, organizational departments, project duration, programming effort ◼ Project structure  New system vs. renovated(renew) existing system, resulting organizational changes, management commitment to system, user perceptions(opinion) and willingness to participate in effort ◼ Development group  Familiarity(knowledge,understanding) with platform, software, development method, application area, development of similar systems ◼ User group  Familiarity with IS development process, application area, se of similar systems 34  Assessing Technical Feasibility (Cont.) ◼ Risk can be managed on a project by:  Changing the project plan to avoid risky factors.  Assigning project team members to carefully manage the risky aspects.  Setting up monitoring methods to determine whether or not potential risk is, in fact, materialize.(occur) 35  Assessing Technical Feasibility (Cont.) ◼ The four primary factors associated with the amount of technical risk on a given project are:  Project size, (large projects are riskier than small projects)  Project structure,A system in which the requirement are easily obtained and highly structured will be less risky than one in which requirements are messy(confused).For example, the development of a payroll system has requirement they may be easy to obtain due to legal reporting requirements and standard accounting procedures. On the other hand, the development of an executive support system would need to be customized to the particular executive decision style and critical success factors of the organization, thus making its development more risky.  The development group’s experience with the application and technology area, The development of a system employing(using) commonly used or standard technology will be less risky than one employing(using) novel(new) or nonstandard technology.  The user group’s experience with systems development projects and the application area.( A project is less risky when the user group is familiar with the systems development process and application area than if the user group is unfamiliar with them.Successful IS projects require active involvement and cooperation between the user and development groups.User familiar with application area and the system development process are more likely to understand the need for their involvement and how this involvement can influence the success of the project. 36  Assessing Technical Feasibility (Cont.) ◼ Four general rules emerged as technical risk assessments:  Larger projects are riskier than smaller projects. A system in which the requirements are easily obtained and highly structured will be less risky than one in which requirements are messy, ill structured, ill defined, or subject to the judgment of an individual. 37 Assessing Technical Feasibility (Cont.)  Thedevelopment of a system employing commonly used or standard technology will be less risky than one employing novel or nonstandard technology. A project is less risky when the user group is familiar with the systems development process and application area than if unfamiliar. 38  Assessing Technical Feasibility (Cont.) FIGURE 5-8 Effects of degree of project structure, project size, and familiarity with application area on project implementation risk (Source: Based on 7th Applegate, Austin, and McFarlan. 2007; Tech Republic, 2005.) 39  Assessing Other Feasibility Concerns ◼ Operational  Does the proposed system solve problems or take advantage of opportunities?Its purpose is to gain an understanding of the degree to which the proposed system will likely solve the business problems or take advantage of the opportunities. ◼ Scheduling  Can the project time frame and completion dates meet organizational deadlines? ◼ Legal and Contractual  What are legal and contractual ramifications or effects of the proposed system development project? ◼ Political  How do key stakeholders view the proposed system?Those stakeholders not supporting the project may take steps to block, disturb,or change intended focus of the project. 40  Building the Baseline Project Plan ◼ All the information collected during project initiation and planning is collected and organized into a document called the Baseline project plan.Once the BPP is completed, a formal review of the project can be conducted with project clients and other interested parties. ◼ Baseline Project Plan (BPP) is a document plan or intended primarily to guide the development team. ◼ Sections: ( Baseline project plan report)  Introduction Provides an exectuve summary that specifies the project’s scope,feasibility,justification,resource requirement,schedule  System description Provides brief presentation of system configurations,input information,tasks performed,resultant information.  Feasibility assessment Provide all feasibility analysis,e.g economic,technical,operational,etc  Management issues Provides a description of the team member roles, communication procedures, relevant issues related to the project uncovered during planning. 41  Building the Baseline Project Plan (Cont.) ◼ Project Scope statement is part of the BPP introduction. Project scope statement for the Customer Tracking Systems(CTS) (pine valley furniture) ◼ Sections:  Problem statement (sales growth has outpaced the marketing department’s ability to accurately track and forecast customer buying trends.  Project objectives To enable the marketing department to accurately track and forecast customer buying patterns in order to better serve customers with the best mix of products.  Project description A new information system will be constructed that will collect all customer purchasing activity,support display and reporting of sales information,aggregate data to assist marketing personnel in understanding dynamic market conditions.  Business benefits Improved understanding of customer buying patterns,utilization of marketing and sales personnel,utilization of production and materials  Deliverables customer tracking system analysis and design,customer tracking system programs,training procedures  Expected duration 5 month 42  Factors in Determining Scope ◼ Organizational units affected by new system ◼ Current systems that will interact with or change because of new system ◼ People who are affected by new system ◼ Range of potential system capabilitiesskills 43 Diagram Depiction of Project Scope FIGURE 5-11 Context-level data flow diagram showing project scope for Purchasing Fulfillment System (Pine Valley Furniture) 44 Building the Baseline Project Plan (Cont.) ◼ System description section outlines possible alternative solutions. ◼ Feasibility assessment section outlines issues related to project costs and benefits, technical difficulties, and other such concerns. ◼ Management issues section outlines a number of managerial concerns related to the project. 45  Reviewing the Baseline Project Plan ◼ Structured Walkthroughs: a peer-group review of any product created during the system development process (The objective of this review is to ensure that the proposed system conforms to organizational standards and to make sure that all relevant parties understand and agree with the information contained in the BPP.A common method for performing this review is called structured walkthrough. ◼ At walkthrough meeting ,there is a need to have individuals play specific roles. These roles are as follows. ◼ Roles: coordinator,This person plans the meeting and facilitates a smoot meeting process presenter,This person describes the work product to the group.Ther presenter is usually an analyst. user,This person (or group) makes sure that the work product meets the needs of the project’s customers. secretary, This person takes notes and record decisions made by the group. standard-bearer, The role of this person is to ensure that the work product follow to organizational technical standards. maintenance oracle This person reviews the work product in terms of future maintenance activites.The goal is to make the system and its documentation easy to maintain. ◼ Can be applied to Walk through meetings are a common occurrence in most systems development groups and BPP, including--system specifications, logical and physical designs, program code, test procedures, manuals and documentation. 46  Summary ◼ In this chapter you learned how to: ✓ Describe steps involved in project initiation and planning. ✓ Explain the need for and contents of Statement of Work and Baseline Project Plan. ✓ List and describe methods for assessing project feasibility. ✓ Describe tangible vs. intangible costs and benefits, and one-time vs. recurring costs and benefits. 47  Summary (Cont.) ✓ Perform cost-benefit analysis, and understand time value of money, present value, discount rate, return on investment, and break-even analysis. ✓ Describe rules for evaluating technical risk of systems development projects. ✓ Describe activities and roles of structured walkthroughs. 48