My Project - Part One - Planning Phase - PDF

MY PROJECT PART ONE PLANNING PHASE Planning st System Request Chapter 1 Project Initia...

MY PROJECT PART ONE PLANNING PHASE Planning st System Request Chapter 1 Project Initiation Feasibility Analysis llyysiss Project Workplan lan Chapter 2 Staffing Plan Project Management Project Standards rdss Risk Assessment ntt n Analysis The Planning Phase involves two primary issues: understanding why an information system should be developed and creating a plan for how the project team should develop it. Design The deliverables from both steps are combined into the project plan. The project sponsor and approval committee Implementation then decide if the project should continue on.  CHAPTER 1 THE SYSTEMS ANALYST AND INFORMATION SYSTEMS DEVELOPMENT PLANNING TASK Identify project. Develop systems request. CHECKLIST Analyze technical feasibility. Analyze economic feasibility. Analyze organizational feasibility. Perform project selection review. Estimate project time. Identify project tasks. Create work breakdown structure. Create PERT Charts. Create Gantt Charts. Manage scope. Staff project. Create project charter. Set up CASE repository. Develop standards. Begin documentation. Assess and manage risk. T his chapter introduces the role of the systems analyst in information systems develop- ment projects. First, the fundamental four-stage systems development life cycle (planning, analysis, design, and implementation) is established as the basic framework for the informa- tion system (IS) development process. Next, ways in which organizations identify and initiate potential projects are discussed. The first steps in the process are to identify a project that will deliver value to the business and to create a system request that provides the basic informa- tion about the proposed system. Next, the analysts perform a feasibility analysis to determine the technical, economic, and organizational feasibility of the system. OBJECTIVES Explain the role played in information systems development by the systems analyst. Describe the fundamental systems development life cycle and its four phases. Explain how organizations identify IS development projects. Explain the importance of linking the information system to business needs. Be able to create a system request. Describe technical, economic, and organizational feasibility assessment. Be able to perform a feasibility analysis.  Introduction 3 INTRODUCTION The systems development life cycle (SDLC) is the process of determining how an information system (IS) can support business needs, designing the system, building it, and delivering it to users. If you have taken a programming class or have programmed on your own, you have probably experienced some success in developing small software applications. Creating high-quality information systems that meet expectations and provide meaningful value to organizations is a much more complex endeavor, however. Numerous studies over the years report that projects involving information technology experience failure rates from 30 to 70%.1 The definition of failure in these studies is often quite different, so the meaning of these statistics is hard to pin down. It is clear, though, that bringing an information system development project to a successful conclusion is difficult and many things need to be done right if we hope to achieve a positive outcome. Although we would like to promote this book as a “silver bullet” that will keep you from experiencing failed IS projects, we must admit that such a silver bullet guaranteeing IS devel- opment success does not exist.2 Instead, this book will provide you with many fundamental concepts and practical techniques that you can use to improve the likelihood of success. The systems analyst plays a key role in the SDLC, analyzing the business situation, identi- fying opportunities for improvements, and designing an information system to implement the improvements. Many systems analysts view their profession as one of the most interesting, exciting, and challenging jobs around. As a systems analyst, you will work as a team with a variety of people, including business and technical experts. You will feel the satisfaction of seeing systems that you designed and developed make a significant positive business impact, while knowing that your unique skills helped make that happen. It is important to remember that the primary objective of the systems analyst is not to create a wonderful system. The primary goal is to create value for the organization, which for most companies means increasing profits. (Government agencies and not-for-profit organiza- tions measure value differently.) Many failed projects were abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would sup- port the organization’s goals, improve business processes, and integrate with other information systems to provide value. An investment in an information system is like any other investment, such as a new machine tool. The goal is not to acquire the tool, because the tool is simply a means to an end; the goal is to enable the organization to perform work better so that it can earn greater profits or serve its constituents more effectively. This book introduces you to the fundamental skills needed by a systems analyst. This is a pragmatic book that discusses best practices in systems development; it does not present a general survey of systems development that exposes you to everything about the topic. By definition, systems analysts do things and challenge the current way that an organization works. To get the most out of this book, you will need to actively apply the ideas and concepts in the examples and in the “Your Turn” exercises that are presented throughout to your own systems development project. This book will guide you through all the steps for delivering a successful information system. In the text, we illustrate how one organization, called Tune Source, applies the steps in one project, developing a Web-based digital music sales system. (Other illustrations of successful IS projects are provided on the course web site.) By the time 1Michael Krigsman, “CIO Analysis: Why 37 Percent of Project Fail”, zdnet.com, accessed February 2014. 2The idea of using the silver bullet metaphor was first described in a paper by Frederick Brooks. See Frederick P. Brooks, Jr., “No Silver Bullet—Essence and Accident in Software Engineering,” Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, H.-J. Kugler (ed.), 1986: 1069–76. 4 C ha pt e r 1 The Systems Analyst and Information Systems Development CONCEPTS 1-A Managerial Causes of IT Failures IN ACTION A significant proportion of IT projects fail to fulfill their An analysis of these IT failures reveals several contrib- original objectives, resulting in wasted resources and a uting factors. First, Qantas faced the challenges of a compli- damaged reputation for the responsible IT department. cated technical infrastructure and outdated legacy In many cases, the causes of the failure are organiza- applications. More significantly, however, was the failure of tional issues, not technical issues. company leadership to understand basic IT issues. In public Qantas, the Australian national airline, has endured statements, the company CFO seemed not to care about the two high-profile IT failures in recent years. In 1995, user perspectives on new software, preferring instead to put Project eQ, a 10-year technology services contract with in what management thought was appropriate. This atti- IBM, was cancelled after four years, at a cost of $200 tude, in part, led to union problems and claims of poorly million. Poor planning contributed to the failure to designed, hard-to-use software and inadequate training. upgrade a complex and unwieldy IT infrastructure sad- Aging applications and an unwieldy technical infra- dled with 700-odd applications written in older pro- structure are challenges faced by many organizations gramming languages. today. But the senior-management attitude that seem- In 2008, Qantas canceled Jetsmart, a $40 million ingly disregards the views of software users casts serious parts-management system implementation, due in part to questions about Qantas’ prospects for IT project success a dispute with the unionized users (aircraft mechanics) of in the future. the system. The union advised its members not to assist Adapted from: Michael Krigsman, “Quantas Airways: A with the implementation, claiming the software unneces- Perfect Storm for IT Failures?”, 2/29/08, zdnet.com, accessed sarily increased the members’ workload. March 2014. you finish the book, you will not be an expert analyst, but you will be ready to start building systems for real. In this chapter, we first describe the role of the systems analyst in information systems development projects. We discuss the wide range of skills needed to be successful in this role, and we explain various specialties that systems analysts may develop. We then introduce the basic SDLC that information systems projects follow. This life cycle is common to all projects and serves as a framework for understanding how information systems projects are accom- plished. We discuss how projects are identified and initiated within an organization and how they are initially described in a system request. Finally, we describe the feasibility analysis that is performed, which drives the decision whether to proceed with the project. THE SYSTEMS ANALYST The systems analyst plays a key role in information systems development projects. The sys- tems analyst works closely with all project team members so that the team develops the right system in an effective way. Systems analysts must understand how to apply technology to solve business problems. In addition, systems analysts may serve as change agents who iden- tify the organizational improvements needed, design systems to implement those changes, and train and motivate others to use the systems. Systems Analyst Skills New information systems introduce change to the organization and its people. Leading a successful organizational change effort is one of the most difficult jobs that someone can do. Understanding what to change, knowing how to change it, and convincing others of the need for change require a wide range of skills. These skills can be broken down into six major categories: technical, business, analytical, interpersonal, management, and ethical.  The Systems Analyst 5 Spotlight on Ethics-1 James is a systems analyst on a new account manage- James is uncomfortable with the request. He is not ment system for Hometown National Bank. At a recent sure the bank has the right to use a person’s data for meeting with the project sponsor, James learned about purposes other than the original intent. Who “owns” this some new ideas for the system that were not a part of data, the bank that collected it as a part of a customer the original project scope. Specifically, the bank’s mar- opening an account, or the customer who the data keting director has asked that some of the data that will describes? Should James insist that the customers give be collected by the new system from customers who authorization to use “their” data in this way? Or should open new checking and savings accounts also be used he say nothing and ignore the issue? Is it necessary (or as the basis of a marketing campaign for various loan appropriate) for a systems analyst to be an ethical watch- products the bank offers. dog in a systems development project? Why or why not? Analysts must have the technical skills to understand the organization’s existing technical environment, the new system’s technology foundation, and the way in which both can be fit into an integrated technical solution. Business skills are required to understand how IT can be applied to business situations and to ensure that IT delivers real business value. Analysts are continuous problem solvers at both the project and the organizational level, and they put their analytical skills to the test regularly. Often, analysts need to communicate effectively, one-on-one with users and business managers (who often have little experience with technology) and with programmers (who often have more technical expertise than the analyst does). They must be able to give presenta- tions to large and small groups and to write reports. Not only do they need to have strong interpersonal abilities, but they also need to manage people with whom they work, and they must manage the pressure and risks associated with unclear situations. Finally, analysts must deal fairly, honestly, and ethically with other project team members, managers, and system users. Analysts often deal with confidential information or information that, if shared with others, could cause harm (e.g., dissent among employees); it is important for analysts to maintain confidence and trust with all people. Systems Analyst Roles As organizations and technology have become more complex, most large organizations now build project teams that incorporate several analysts with different, but complementary roles. In smaller organizations, one person may play several of these roles. Here we briefly describe these roles and how they contribute to a systems development project. YO U R 1-1 Being an Analyst TU R N Suppose you set a goal to become an analyst after you Question graduate. What type of analyst would you most prefer to be? Why does this particular analyst role appeal to Develop a short plan that describes how you will pre- you? What type of courses should you take before you pare for your career as an analyst. graduate? What type of summer job or internship should you seek? 6 C ha pt e r 1 The Systems Analyst and Information Systems Development The systems analyst role focuses on the IS issues surrounding the system. This person develops ideas and suggestions for ways that IT can support and improve business processes, helps design new business processes supported by IT, designs the new information system, and ensures that all IS standards are maintained. The systems analyst will have significant training and experience in analysis and design and in programming. The business analyst role focuses on the business issues surrounding the system. This person helps to identify the business value that the system will create, develops ideas for improving the business processes, and helps design new business processes and policies. The business analyst will have business training and experience, plus knowledge of analysis and design. The requirements analyst role focuses on eliciting the requirements from the stakeholders associated with the new system. As more organizations recognize the critical role that com- plete and accurate requirements play in the ultimate success of the system, this specialty has gradually evolved. Requirements analysts understand the business well, are excellent commu- nicators, and are highly skilled in an array of requirements elicitation techniques (discussed in Chapter 3). The infrastructure analyst role focuses on technical issues surrounding the ways the sys- tem will interact with the organization’s technical infrastructure (hardware, software, net- works, and databases). This person ensures that the new information system conforms to organizational standards and helps to identify infrastructure changes that will be needed to support the system. The infrastructure analyst will have significant training and experience in networking, database administration, and various hardware and software products. Over time, an experienced infrastructure analyst may assume the role of software architect, who takes a holistic view of the organization’s entire IT environment and guides application design deci- sions within that context. The change management analyst role focuses on the people and management issues surrounding the system installation. This person ensures that adequate documentation and support are available to users, provides user training on the new system, and develops strat- egies to overcome resistance to change. The change management analyst will have signifi- cant training and experience in organizational behavior and specific expertise in change management. The project manager role ensures that the project is completed on time and within budget and that the system delivers the expected value to the organization. The project manager is often a seasoned systems analyst who, through training and experience, has acquired special- ized project management knowledge and skills. More will be said about the project manager in the next chapter. The roles and the names used to describe them may vary from organization to organiza- tion. In addition, there is no single typical career path through these professional roles. Some people may enter the field as a more technically oriented programmer/analyst. Others may enter as a business-oriented functional specialist with an interest in applying IT to solve busi- ness problems. As shown in Figure 1-1, those who are interested in the broad field of informa- tion systems development may follow a variety of paths during their career. THE SYSTEMS DEVELOPMENT LIFE CYCLE In many ways, building an information system is similar to building a house. First, the owner describes the vision for the house to the developer. Second, this idea is transformed into sketches and drawings that are shown to the owner and refined (often, through several draw- ings, each improving on the other) until the owner agrees that the pictures depict what he or she wants. Third, a set of detailed blueprints is developed that presents much more specific information about the house (e.g., the layout of rooms, placement of plumbing fixtures and  The Systems Development Life Cycle 7 Change Requirements management analyst analyst Entry-level Business business function analyst specialist Project manager Systems analyst Entry-level programmer/ analyst Infrastructure Software analyst architect More common path FIGURE 1-1 Career Paths for Less common path System Developers electrical outlets, and so on). Finally, the house is built following the blueprints—and often with some changes and decisions made by the owner as the house is erected. Building an information system using the SDLC follows a similar set of four fundamental phases: planning, analysis, design, and implementation (Figure 1-2). Each phase is itself com- posed of a series of steps, which rely on techniques that produce deliverables (specific docu- ments and files that explain various elements of the system). Figure 1-3 provides more detail on the steps, techniques, and deliverables that are included in each phase of the SDLC and outlines how these topics are covered in this textbook. Figures 1-2 and 1-3 suggest that the SDLC phases proceed in a logical path from start to finish. In some projects, this is true. In many projects, however, the project team moves through the steps consecutively, incrementally, iteratively, or in other patterns. Different pro- jects may emphasize different parts of the SDLC or approach the SDLC phases in different ways, but all projects have elements of these four phases. For now, there are two important points to understand about the SDLC. First, you should get a general sense of the phases and steps that IS projects move through and some of the techniques that produce certain deliverables. In this section, we provide an overview Planning Analysis Design Implementation Idea System success FIGURE 1-2 The Systems Development Life Cycle 8 C ha pt e r 1 The Systems Analyst and Information Systems Development Phase Chapter Step Technique Deliverable Planning 1 Identify opportunity Project identification System request Focus: Why build 1 Analyze feasibility Technical feasibility Feasibility study this system? Economic feasibility How to structure Organizational feasibility the project? 2 Develop workplan Time estimation Project plan Primary outputs: Task identification —Workplan —System request with Work breakdown structure feasibility study PERT chart —Project plan Gantt chart Scope management 2 Staff project Project staffing —Staffing plan Project charter 2 Control and direct project CASE repository —Standards list Standards —Risk assessment Documentation Timeboxing Risk management Analysis 3 Develop analysis strategy Business process automation System proposal Focus: Who, what, Business process improvement where, and when for Business process reengineering this system? 3 Determine business Interview —Requirements definition Primary output requirements JAD session —System proposal Questionnaire Document analysis Observation 4 Create use cases Use case analysis —Use cases 5 Model processes Data flow diagramming —Process models 6 Model data Entity relationship modeling —Data model Normalization Design 7 Design physical system Design strategy Alternative matrix Focus: How will this System specification system work? 8 Design architecture Architecture design —Architecture report Primary output: Hardware and software selection —Hardware and software specification —System specification 9 Design interface Use scenario —Interface design Interface structure Interface standards Interface prototype Interface evaluation 10 Design programs Data flow diagramming —Physical process model Program structure chart —Program design Program specification 11 Design databases and files Data format selection —Database and file specification Entity relationship modeling —Physical data model Denormalization Performance tuning Size estimation Implementation 12 Construct system Programming Test plan Focus: Delivery and Software testing Programs support of completed Performance testing Documentation system Migration plan Primary output: 13 Install system Conversion strategy selection —Conversion plan —Installed system —Business contingency plan Training —Training plan 13 Maintain system Support selection Support plan System maintenance Problem report Project assessment Change request 13 Post-implementation Post-implementation Post-implementation audit audit report FIGURE 1-3 Systems Development Life Cycle Phases  The Systems Development Life Cycle 9 of the phases, steps, and some of the techniques that are used to accomplish the steps. Second, it is important to understand that the SDLC is a process of gradual refinement. The deliverables produced in the analysis phase provide a general idea what the new system will do. These deliverables are used as input to the design phase, which then refines them to produce a set of deliverables that describes in much more detailed terms exactly how the system should be built. These deliverables in turn are used in the implementation phase to guide the creation of the actual system. Each phase refines and elaborates on the work done previously. Planning The planning phase is the fundamental process of understanding why an information system should be built and determining how the project team will go about building it. It has two steps: 1. During project initiation, the system’s business value to the organization is identified— how will it contribute to the organization’s future success? Most ideas for new systems come from outside the IS area and are recorded on a system request. A system request presents a brief summary of a business need and explains how a system that addresses the need will create business value. The IS department works together with the person or department generating the request (called the project sponsor) to conduct a feasibility analysis. The feasibility analysis examines key aspects of the proposed project: The technical feasibility (Can we build it?) The economic feasibility (Will it provide business value?) The organizational feasibility (If we build it, will it be used?) The system request and feasibility analysis are presented to an information systems approval committee (sometimes called a steering committee), which decides whether the project should be undertaken. 2. Once the project is approved, it enters project management. During project management, the project manager creates a workplan, staffs the project, and puts techniques in place to help control and direct the project through the entire SDLC. The deliverable for project management is a project plan that describes how the project team will go about develop- ing the system. Analysis The analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used (Figure 1-3). During this phase, the project team investi- gates any current system(s), identifies improvement opportunities, and develops a concept for the new system. This phase has three steps: 1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually includes studying the current system (called the as-is system) and its problems, and envi- sioning ways to design a new system (called the to-be system). 2. The next step is requirements gathering (e.g., through techniques such as interviews, group workshops, or questionnaires). The analysis of this information—in conjunction with input from the project sponsor and many other people—leads to the develop- ment of a concept for a new system. The system concept is explained through a set of requirement statements and a set of business analysis models that describe how the business will operate if the new system is developed. The analysis models represent user/system interactions and the data and processes needed to support the underlying business process. 10 C ha pt er 1 The Systems Analyst and Information Systems Development 3. The analyses, system concept, requirements, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key deci- sion makers (e.g., members of the approval committee) who will decide whether the project should continue to move forward. The system proposal is the initial deliverable describing the requirements the new system should satisfy. Some experts suggest this phase would be better named analysis and initial design, rather than analysis, since it really provides the first step in the new system design. Since most organizations continue to use the name analysis for this phase, we will use it in this book as well. It is important to remember, however, that the deliverable from the analysis phase is both an analysis and a high-level initial design for the new system. Design The design phase decides how the system will operate in terms of the hardware, software, and network infrastructure that will be in place; the user interface, forms, and reports that will be used; and the specific programs, databases, and files that will be needed. Although most of the strategic decisions about the system are made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. The design phase has four steps: 1. The design strategy must be determined. This clarifies whether the system will be developed by the company’s own programmers, whether its development will be outsourced to another firm (usually a consulting firm), or whether the company will buy and install a prewritten software package. 2. This leads to the development of the basic architecture design for the system that describes the hardware, software, and network infrastructure that will be used. In most cases, the system will add to or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g., by navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use. 3. The database and file specifications are developed. These define exactly what data will be stored and where they will be stored. 4. The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do. This collection of deliverables (architecture design, interface design, database and file specifications, and program design) is the system specification that is used by the program- ming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue (Figure 1-3). Implementation The final phase in the SDLC is the implementation phase, during which the system is actually built (or purchased and installed if the design calls for a prewritten software package). This is the phase that usually gets the most attention, because for most systems it is the longest and most expensive single part of the development process. This phase has three steps: 1. System construction is the first step. The system is built and tested to ensure that it per- forms as designed. Since the cost of fixing bugs can be immense, testing is one of the most critical steps in implementation. Most organizations should spend more time and attention on testing than on writing the programs in the first place.  Project Identification and Initiation 11 2. The system is installed. Installation is the process by which the old system is turned off and the new one is turned on. There are several approaches that may be used to convert from the old to the new system. One of the most important aspects of conversion is training, during which users are taught to use the new system and help manage the resulting organizational changes. 3. The analyst team establishes a support plan for the system. This plan usually includes a formal or informal post-implementation review, as well as a systematic way for identify- ing major and minor changes needed for the system. PROJECT IDENTIFICATION AND INITIATION Where do project ideas come from? A project is identified when someone in the organiza- tion identifies a business need to build a system. Examples of business needs include sup- porting a new marketing campaign, reaching out to a new type of customer, or improving interactions with suppliers. Sometimes, needs arise from some kind of “pain” within the organization, such as a drop in market share, poor customer service levels, unacceptable product defect rates, or increased competition. New business initiatives and strategies may be created and a system to support them is required, or a merger or acquisition may require systems to be integrated. Business needs also can surface when the organization identifies unique and competitive ways of using IT. Many organizations keep an eye on emerging technology, which is technology that is in the early stages of widespread business use. For example, if companies stay abreast of technological advances such as cloud computing, mobile apps, or Big Data, they can develop business strategies that leverage the capabilities of these technologies and introduce them into the marketplace as a first mover. Ideally, companies can take advantage of this first mover posi- tion by making money and continuing to innovate while competitors trail behind. Today, many new information system projects grow out of business process management (BPM) initiatives. BPM is a methodology used by organizations to continuously improve end- to-end business processes. BPM can be applied to internal organizational processes and to processes spanning multiple business partners. By studying and improving their underlying business processes, organizations can achieve several important benefits, including: enhanced process agility, giving the organization the ability to adapt more rapidly and effectively to a changing business environment; improved process alignment with industry “best practices”; and increased process efficiencies as costs are identified and eliminated from process workflows. BPM generally follows a continuous cycle of systematically creating, assessing, and alter- ing business processes. Business analysts, with their in-depth business knowledge, play a particularly important role in BPM by: 1. defining and mapping the steps in a business process, 2. creating ways to improve on steps in the process that add value, 3. finding ways to eliminate or consolidate steps in the process that do not add value, 4. creating or adjusting electronic workflows to match the improved process maps. The last step is particularly relevant to our discussion since the need for information sys- tems projects is frequently identified here. In fact, the automation of business processes (termed business process automation), is the foundation of many information technology sys- tems. In these situations, technology components are used to complement or substitute for manual information management processes with the intent of gaining cost efficiencies. 12 C ha pt er 1 The Systems Analyst and Information Systems Development BPM practitioners recognize, however, that it is not always advisable to just “pave the cow paths” by simply adding automation to speed up existing processes (step 4 above). In many situations, business process improvement (BPI) results from studying the business processes, creating new, redesigned processes to improve the process workflows, and/or utilizing new technologies enabling new process structures (steps 2, 3, and 4 above). For example, could a retail store’s checkout process be redesigned along the lines of the EZPass toll collection sys- tem on highways? Could customers check out and pay with their mobile devices while clerks simply review the contents of the customer’s shopping bag? Projects with a goal of BPI make moderate changes to the organization’s operations, and can improve efficiency (i.e., doing things right) and improve effectiveness (i.e., doing the right things). These types of projects involve more risk than business process automation projects since more significant changes are made to the organization’s operations. BPM may also reveal the need for the complete revamping of the organization’s business processes, termed business process reengineering (BPR). BPR means changing the fundamental way in which the organization operates—“obliterating” the current way of doing business and making major changes to take advantage of new ideas and new technology. As you might expect, BPR projects involve substantial risk due to the significant organizational and opera- tional changes that result. Top management support and careful management are critical in these fairly rare types of projects. Both IT people (i.e., the information systems experts) and business people (i.e., the sub- ject matter experts) should work closely together to find ways for technology to support busi- ness needs. In this way, organizations can leverage the exciting technologies available while ensuring that projects are based upon real business objectives such as increasing sales, improv- ing customer service, and decreasing operating expenses. Ultimately, information systems need to affect the organization’s bottom line (in a positive way!). When a strong business need for an information system is recognized, often as a result of BPM, a person (or group) who has an interest in the system’s success typically steps forward. We call this person (or group) the project sponsor. Often, the project sponsor develops the initial vision of the new system. The project sponsor works throughout the SDLC to make sure that the project is moving in the right direction from the perspective of the business and serves as the primary point of contact for the project team. Usually, the sponsor of the project is from a business function such as marketing, accounting, or finance; however, members of the IT area also can sponsor or cosponsor a project. CONCEPTS 1-B BPI on the Farm IN ACTION In the farming industry, grain is commonly loaded smartphone from the truck cab. Through the app, the into large grain-hauling trucks by the driver parking driver can initiate, monitor, and control the filling under the grain bin, jumping out of the truck cab, process without a grain bin operator and without leav- signaling the grain bin operator to start filling, moni- ing the truck. This real-world example illustrates BPI, toring the fill level, signaling the bin operator to stop the redesign of a business process with the right appli- filling, jumping back into the truck cab, driving 3 feet cation of information technology, providing signifi- forward, and repeating the cycle numerous times until cant efficiency gains. the truck bed is full. This laborious process can be simplified by digitizing the process. Cameras and Adapted from: Nicole Laskowski, “Crowdsourcing is the new secure Wi-Fi can be installed on the grain bin. When cloud computing—Get with it, CIOs,” searchcio.techtarget. a truck arrives, the driver can open an app on his com, accessed February 2014.  Project Identification and Initiation 13 YO U R 1-2 Implementing a Satellite Data Network TU R N A major retail store spent $24 million dollars on a large high-end (and high-profit) snow throwers quite quickly, private satellite communication system that provides the company’s nearest warehouse can prepare next-day state-of-the-art voice, data, and video transmission shipments to maintain a good inventory balance, while between stores and regional headquarters. When an item the competitor may not move quite as quickly and thus gets sold, the scanner software updates the inventory lose out on such quick inventory turnover. system in real time. As a result, store transactions are passed on to regional and national headquarters instantly, Questions which keeps inventory records up to date. One of the store’s major competitors has an older system in which 1. Do you think a $24 million investment in a transactions are uploaded at the end of a business day. private satellite communication system could be The first company feels that its method of instant com- justified by a cost-benefit analysis? Could this be munication and feedback allows it to react more quickly done with a standard communication line (with to changes in the market, giving the company a competi- encryption)? tive advantage. For example, if an early winter snowstorm 2. How might the competitor attempt to close the causes stores across the upper Midwest to start selling “information gap” in this example? The size or scope of the project often determines the kind of sponsor who is involved. A small, departmental system might be sponsored by a single manager; however, a large, organizational initiative might be sponsored by the entire senior management team and even the CEO. If a project is primarily technical in nature (e.g., improvements to the exist- ing IT infrastructure or research into the viability of an emerging technology), then spon- sorship from IT is appropriate. When projects have great importance to the business, yet are technically complex, joint sponsorship by both the business and IT functions may be necessary. The business need drives the high-level business requirements for the system. Business requirements describe the reasons for developing the system and outline the capabilities it will provide the organization. These requirements need to be explained at a high level so that the approval committee and, ultimately, the project team understand what the business expects from the final product. Business requirements summarize the features the information system must include, such as the ability to collect customer orders online or the ability for suppliers to receive inventory status information as sales occur. The project sponsor has the insights needed to determine the business value that will be gained from the system, in both tangible and intangible ways. Tangible value can be quantified and measured easily (e.g., 2% reduction in operating costs). An intangible value results from an intuitive belief that the system provides important, but hard-to-measure, benefits to the organization (e.g., improved customer service, a better competitive position). Once the project sponsor identifies a project that meets an important business need and he or she can identify the business requirements and business value of the system, it is time to formally initiate the project. In most organizations, project initiation begins by preparing a system request. System Request A system request is a document that describes the business reasons for building a system and the value that the system is expected to provide. The project sponsor usually completes this 14 C ha pt er 1 The Systems Analyst and Information Systems Development form as part of a formal system project selection process within the organization. Most system requests include five elements: project sponsor, business need, business requirements, business value, and special issues (Figure 1-4). The sponsor describes the person who will serve as the primary contact for the project, and the business need presents the reasons prompting the project. The business requirements of the project refer to the business capabilities that the sys- tem must have, and the business value describes the benefits that the organization should expect from the system. Special issues are included on the document as a catchall category for other information that should be considered in assessing the project. For example, the project may need to be completed by a specific deadline. Any special circumstances that could affect the outcome of the project must be clearly identified. The completed system request is submitted to the approval committee for consideration. This approval committee could be a company steering committee that meets regularly to make information systems decisions, a senior executive who has control of organizational resources, or any other decision-making body that governs the use of business resources. The committee reviews the system request and makes an initial determination, based on the information provided, of whether to investigate the proposed project or not. If approved, the next step is to conduct a feasibility analysis. Element Description Examples Project Sponsor The person who initiates the Several members of the finance project and who serves as the department primary point of contact for the Vice president of marketing project on the business side CIO CEO Business Need The business-related reason for Reach a new market segment initiating the system Offer a capability to keep up with competitors Improve access to information Decrease product defects Streamline supply acquisition processes Business Requirements The new or enhanced business Provide onIine access to information capabilities that the system Capture customer demographic will provide information Include product search capabilities Produce performance reports Enhance online user support Business Value The benefits that the system will 3% increase in sales create for the organization 1% increase in market share Reduction in headcount by 5 FTEs $200,000 cost savings from decreased supply costs $150,000 savings from removal of outdated technology Special Issues or Issues that pertain to the approval Government-mandated deadline Constraints committee’s decision for May 30 System needed in time for the Christmas holiday season Top-level security clearance needed FIGURE 1-4 by project team to work with data Elements of the FTE, full-time equivalent. System Request Form  Project Identification and Initiation 15 1-C Interview with Don Hallacy, President, Technology CONCEPTS Services, Sprint Corporation IN ACTION At Sprint, network projects originate from two vantage and create a business case. This business case contains points—IT and the business units. IT projects usually the economic value added and the net present value of address infrastructure and support needs. The business- the project. unit projects typically begin after a business need is Of course, not all projects undergo this rigorous identified locally, and a business group informally col- process. The larger projects require more time to be laborates with IT regarding how a solution can be deliv- allocated to the analysis team. It is important to remain ered to meet customer expectations. flexible and not let the process consume the organiza- Once an idea is developed, a more formal request tion. At the beginning of each budgetary year, specific process begins, and an analysis team is assigned to inves- capital expenditures are allocated for operational tigate and validate the opportunity. This team includes improvements and maintenance. Moreover, this money members from the user community and IT, and they is set aside to fund quick projects that deliver immediate scope out at a high level what the project will do; create value without going through the traditional approval estimates for technology, training, and development costs; process. Don Hallacy Applying the Concepts at Tune Source Throughout the book, we will apply the concepts in each chapter to a fictitious company called Tune Source. For example, in this section, we will illustrate the creation of a system request. Tune Source is a company headquartered in southern California. Tune Source is the brainchild of three entrepreneurs with ties to the music industry: John Margolis, Megan Taylor, and Phil Cooper. Originally, John and Phil partnered to open a number of brick and mortar stores in southern California specializing in hard-to-find and classic jazz, rock, country, and folk record- ings. Megan soon was invited to join the partnership because of her contacts and knowledge of classical music. Tune Source quickly became known as the place to go to find rare audio recordings. Annual sales last year were $40 million with annual growth at about 3–5% per year. YO U R 1-3 Too Much Paper, Part 1 TU R N The South Dakota Department of Labor, Workers’ Com- Other folders could be very large, with numerous medi- pensation division was sinking under a load of paper cal reports from several doctors verifying the extent of a files. This state agency ascertains that employees are serious injury and treatment (such as an arm amputation). treated fairly when they are injured on the job. If a person A digital solution was suggested—reports could be sub- (or company) called to see the status of an injury claim, mitted online via a secure web site. Medical reports the clerk would have to take a message, get the paper file, could be submitted electronically, either as a pdf file or review the status, and call the person back. Files were as a faxed digital file. This solution would also mean that stored in huge filing cabinets and were entered by year the clerk taking the phone call could query the database and case number (i.e., the 415th person injured in 2008 by the person’s name and access the information in a would be in a file numbered 08-415). Few callers knew matter of seconds. the file number and would give their name and address and the date of injury. The clerk would look in a spiral Question notebook for the last name around the date that was given—and then find the file number to retrieve the Begin a systems request for this project. Focus on stating folder. Some folders were small—possibly documenting a the business need and the business requirements for this minor injury requiring only a brief treatment period. project. What is the value of this system? 16 C ha pt er 1 The Systems Analyst and Information Systems Development Background John, Megan, and Phil, like many others in the music industry, watched with alarm the rise of music-sharing web site like Napster, as music consumers shared digital audio files without paying for them, denying artists and record labels royalties associated with sales. Once the legal battle over copyright infringement was resolved and Napster was shut down, the partners set about establishing agreements with a variety of industry partners in order to offer a legitimate digital music download resource for customers in their market niche. Phil has asked Carly Edwards, a rising star in the Tune Source marketing department, to spearhead the digital music download project. Tune Source currently has a web site that enables customers to search for and purchase CDs. This site was initially developed by an Internet consulting firm and is hosted by a promi- nent local internet service provider (ISP) in Los Angeles. The IT department at Tune Source has become experienced with Internet technology as it has worked with the ISP to maintain the site. System Request At Tune Source, new IT projects are reviewed and approved by a project steering committee that meets quarterly. The committee has representatives from IT as well as from the major areas of the business. Carly’s first step was to prepare a system request for the committee. Figure 1-5 shows the system request she prepared. The project sponsor is Carly, and the business needs are to increase sales and provide a music download capability demanded by a System Request—Digital Music Download Project Project Sponsor: Carly Edwards, Assistant Vice President, Marketing Business Need: This project has been initiated to create the capability of selling digital music downloads to customers through kiosks in our stores and over the Internet using our web site. Currently, Customers have many alternatives for downloading music and we need to provide this capability to retain our competitive position. Our music archive of rare and hard-to-find music is underutilized. Business Requirements: Using this system over the Web or in-store kiosks, customers will be able to search for and purchase digital music downloads. The specific functionality that the system should have includes the following: Search for music in our digital music archive. Listen to music samples. Purchase individual downloads at a fixed fee per download. Establish a customer subscription account permitting unlimited downloads for a monthly fee. Purchase music download gift cards. Business Value: We expect that Tune Source will increase sales by enabling existing customers to purchase specific digital music tracks and by reaching new customers who are interested in our unique archive of rare and hard-to-find music. We expect to gain a new revenue stream from customer subscriptions to our download services. We expect some increase in cross-selling, as customers who have downloaded a track or two of a CD decide to purchase the entire CD in a store or through our web site. We also expect a new revenue stream from the sale of music download gift cards. Conservative estimates of tangible value to the company include the following: $757,500 in sales from individual music downloads FIGURE 1-5 $950,000 in sales from customer subscriptions $205,000 in additional in-store or web site CD sales System Request for $153,000 in sales from music download gift cards Tune Source Special Issues or Constraints: A template for this The marketing department views this as a strategic system. To prevent significant customer attrition, figure is available on this project should be completed as soon as possible. the student web site  Project Identification and Initiation 17 very competitive marketplace. Notice that the need does not focus on the technology associ- ated with the project. The emphasis is on the business aspects: increasing sales and maintain- ing a competitive position in the company’s market. In the system request, the project sponsor focuses on describing his or her vision of the business requirements at a very high level. Carly has expressed a clear vision of how this sys- tem will affect Tune Source: sales of individual music downloads, revenue from customer subscriptions, sales from cross-selling of CDs, and sales of music download gift cards. Carly acknowledges customer demand for this capability and also recognizes the need to respond to this demand in order to retain the business of its loyal customer base. The estimates of tangible value were difficult to develop, since this venture is completely new to Tune Source. To prepare for this, Carly had several of her staff members conduct both an in-store customer survey and an online customer survey to assess the customers’ interest in individual music downloads, subscription programs, and gift cards. The surveys also attempted to gauge the customers’ price sensitivity for these offerings. From the survey results, Carly and her staff developed a range of sales projections for the various revenue streams: a high-level estimate, a medium-level estimate, and low-level estimate. They also developed probability assessments for each of these outcomes, settling on a 25% likelihood for the high-level estimate, a 60% likelihood for the medium-level estimate, and a 15% likelihood for the low-level estimate. Based on the sales projections and the probability estimates, a weighted average estimated sales figure was computed for each revenue stream. For example, for individual downloads, Expected sales 5 (900,000 *.25) 1 (750,000 *.60) 1 (550,000 *.15) 5 225,000 1 450,000 1 82,500 5 757,500 These projections are summarized in Figure 1-6. After analyzing the survey results, Carly and her staff were confident that the sales projec- tions and probability estimates were as accurate as they could make them this early in the project. The completed system request is shown in Figure 1-5. Steering Committee Approval Carly Edwards presented the system request for the digital music download project to the Tune Source project steering committee at its next meeting. Response to the request was uniformly positive. The strong support for the project by John, Megan, and Phil, the company’s top executives, helped to spur the committee’s rapid approval of the project. Following approval of the system request, Jason Wells, a senior systems analyst in the IT department, was assigned to work with Carly to develop a preliminary feasibility analysis for the project. Sales Projections Individual Downloads Subscriptions Cross-Selling of CDs Gift Cards High-level estimate $900,000 $1,100,000 $250,000 $180,000 (prob. = 25%) Medium-level estimate 750,000 950,000 200,000 150,000 (prob. = 60%) FIGURE 1-6 Low-level estimate 550,000 700,000 150,000 120,000 Sales Projections for (prob. = 15%) Tune Source Digital Music Download Weighted average $757,500 $950,000 $205,000 $153,000 expected sales Project 18 C ha pt er 1 The Systems Analyst and Information Systems Development FEASIBILITY ANALYSIS Once the need for the system and its business requirements have been defined, the approval committee authorizes the systems analyst to prepare a more detailed business case to better understand the proposed information system project. Feasibility analysis guides the organiza- tion in determining whether to proceed with the project. Feasibility analysis also identifies the important risks associated with the project that must be managed if the project is approved. As with the system request, each organization has its own process and format for the feasibility analysis, but most include techniques to assess three areas: technical feasibility, economic feasibility, and organizational feasibility (Figure 1-7). The results of evaluating these three feasibility factors are combined into a feasibility study deliverable that is submit- ted to the approval committee. You might wonder at the omission of the element of time as a risk factor for the project. While the time available for a project can certainly be a concern, we consider time to be a project management issue. We will discuss project management strategies that can be used when time is tight in Chapter 2. Although we will discuss feasibility analysis now within the context of project initiation, most project teams revise the feasibility study throughout the SDLC and revisit its contents at various checkpoints during the project. If at any point the project’s risks and limitations outweigh its benefits, the project team may decide to cancel the project or make substantial revisions. Technical Feasibility The first issue in the feasibility analysis is to assess the technical feasibility of the project, the extent to which the system can be successfully designed, developed, and installed by the IT group. Technical feasibility analysis is, in essence, a technical risk analysis that strives to answer the question: “Can we build it?”3 Technical Feasibility: Can We Build It? Familiarity with application: Less familiarity generates more risk. Familiarity with technology: Less familiarity generates more risk. Project size: Large projects have more risk. Compatibility: The harder it is to integrate the system with the company’s existing technology, the higher the risk will be. Economic Feasibility: Should We Build It? Development costs Annual operating costs Annual benefits (cost savings and/or increased revenues) Intangible benefits and costs FIGURE 1-7 Organizational Feasibility: If We Build It, Will They Come? Feasibility Analysis Is the project strategically aligned with the business? Assessment Factors Project champion(s) A template for this Senior management Users figure is available on Other stakeholders the student web site 3 We use the words “build it” in the broadest sense. Organizations can also choose to buy a commercial software pack- age and install it, in which case the question might be “Can we select the right package and successfully install it?”  Feasibility Analysis 19 Many risks can endanger the successful completion of the project. First and foremost is the users’ and analysts’ familiarity with the application. When analysts are unfamiliar with the business application area, they have a greater chance of misunderstanding the users or missing opportunities for improvement. The risks increase dramatically when the users themselves have limited knowledge of the application. If the project involves a new business innovation, neither the users nor the analysts may have any direct knowledge or experience of the pro- posed new application. In general, the development of new systems is riskier than extensions to an existing system, because existing systems tend to be better understood. Familiarity with the technology is another important source of technical risk. When a system uses technology that has not been used before within the organization, there is a greater chance that problems and delays will occur because of the need to learn how to use the tech- nology. Risk increases dramatically when the technology itself is new (e.g., a Big Data project using Hadoop). When the technology is not new but the organization lacks experience with it, technical risk is reduced somewhat, since outside expertise should be available from vendors and consultants. Project size is an important consideration, whether 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 distinct features in the system. Larger projects present more risk, because they are more complicated to manage and because there is a greater chance that some important system requirements will be overlooked or misunderstood. Large systems are typically highly inte- grated with other systems, increasing project complexity. Finally, project teams need to consider the compatibility of the new system with the tech- nology that already exists in the organization. Systems are rarely built in a vacuum—they are built in organizations that have numerous systems already in place. New technology and applications need to be able to integrate with the existing environment for many reasons. They may rely on data from existing systems, they may produce data that feed other applications, and they may have to use the company’s existing communications infrastructure. A new CRM system, for example, has little value if it does not use customer data found across the organiza- tion in existing sales systems, marketing applications, and customer service systems. The assessment of a project’s technical feasibility is not cut and dried, because in many cases, some interpretation of the underlying conditions is needed (e.g., how large does a pro- ject need to grow before it is considered “big”?). One approach is to compare the project with prior projects undertaken by the organization. Another option is to consult with experienced IT professionals in the organization or with external IT consultants; often, they will be able to judge whether a project is feasible from a technical perspective. Economic Feasibility The second element of a feasibility analysis is to perform an economic feasibility analysis (also called a cost–benefit analysis). This attempts to answer the question “Should we build the system?” Economic feasibility is determined by identifying costs and benefits associated with the system, assigning values to them, calculating future cash flows, and measuring the finan- cial worthiness of the project. As a result of this analysis, the financial opportunities and risks of the project can be understood. Keep in mind that organizations have limited capital resources and multiple projects will be competing for funding. The more expensive the pro- ject, the more rigorous and detailed the analysis should be. Before illustrating this process with a detailed example, we first introduce the framework we will apply to evaluate project investments and the common assessment measures that are used. Cash Flow Analysis and Measures IT projects commonly involve an initial investment that produces a stream of benefits over time, along with some ongoing support costs. Therefore, the 20 C ha pt er 1 The Systems Analyst and Information Systems Development value of the project must be measured over time. Cash flows, both inflows and outflows, are estimated over some future period. Then, these cash flows are evaluated using several techniques to judge whether the projected benefits justify incurring the costs. A very basic cash flow projection is shown in Figure 1-8 to demonstrate these evalua- tion techniques. In this simple example, a system is developed in Year 0 (the current year) costing $100,000. Once the system is operational, benefits and on-going costs are projected over 3 years. In row 3 of this figure, net benefits are computed by subtracting each year’s total costs from its total benefits. Finally, in row 4, we have computed a cumulative total of the net cash flows. Two of the common methods for evaluating a project’s worth can now be determined. Each of these calculations will be explained here: Return on Investment The return on investment (ROI) is a calculation that measures the average rate of return earned on the money invested in the project. ROI is a simple calculation that divides the project’s net benefits (total benefits – total costs) by the total costs. The ROI formula is: Total Benefits 2 Total Costs ROI 5 Total Costs 152,000 2 138,000 14,000 ROI 5 5 5 10.14% 138,000 138,000 A high ROI suggests that the project’s benefits far outweigh the project’s cost, although exactly what constitutes a “high” ROI is unclear. ROI is commonly used in practice; however, it is hard to interpret and should not be used as the only measure of a project’s worth. Break-Even Point Another common approach to measuring a project’s worth is the break-even point. The break-even point (also called the payback method) is defined as the number of years it takes a firm to recover its original investment in the project from net cash flows. As shown in row 4 of Figure 1-8, the project’s cumulative cash flow figure becomes positive during Year 3, so the initial investment is “paid back” over two years plus some fraction of the third year. (In the year in which Cumulative Cash Flow turns positive): Number of years That year’s Net Cash Flow 2 That year’s Cumulative Cash Flow BEP = of negative cash 1 flow That year’s Net Cash Flow Year 0 Year 1 Year 2 Year 3 Total Total Benefits 45,000 50,000 57,000 152,000 Total Costs 100,000 10,000 12,000 16,000 138,000 Net Benefits FIGURE 1-8 3 (Total Benefits – Total Costs) (100,000) 35,000 38,000 41,000 14,000 Simple Cash Flow 4 Cumulative Net Cash Flow (100,000) (65,000) (27,000) 14,000 Projection  Feasibility Analysis 21 Using the values in Figure 1-8, the BEP calculation is: 41,000 2 14,000 28,000 BEP 5 2 1 521 5 2.68 years 41,000 41,000 The break-even point is intuitively easy to understand and does give an indication of a project’s liquidity, or the speed at which the project generates cash returns. Also, projects that produce higher returns early in the project’s life are thought to be less risky, since we can anticipate near-term events with more accuracy than long-term events. The break-even point ignores cash flows that occur after the break-even point has been reached; therefore, it is biased against longer-term projects. Discounted Cash Flow Technique The simple cash flow projection shown in Figure 1-8, and the return on investment and break-even point calculations all share the weakness of not recog- nizing the time value of money. In these analyses, the timing of cash flows is ignored. A dollar in Year 3 of the project is considered to be exactly equivalent to a dollar received in Year 1. Discounted cash flows are used to compare the present value of all cash inflows and outflows for the project in today’s dollar terms. The key to understanding present values is to recognize that if you had a dollar today, you could invest it and receive some rate of return on your investment. Therefore, a dollar received in the future is worth less than a dollar received today, since you forgo that potential return. If you have a friend who owes you $100 today, but instead gives you that $100 in 3 years—you’ve been had! Assuming you could have invested those dollars at a 10% rate of return, you will be receiving the equivalent of $75 in today’s terms. The basic formula to convert a future cash flow to its present value is: Cash flow amount PV 5 , where n is the year in which the cash flow occurs. (1 1 Rate of return) n The rate of return used in the present value calculation is sometimes called the required rate of return, or the cost of obtaining the capital needed to fund the project. Many organiza- tions will have determined the appropriate rate of return to use when analyzing IT invest- ments. The systems analyst should consult with the organization’s finance department. Using our previous illustration, $100 received in 3 years with a required rate of return of 10% has a PV of $75.13. 100 100 PV 5 5 5 75.13 (1 1 0.1) 3 1.331 In Figure 1-9, the present value of the projected benefits and costs shown in Figure 1-8 have been calculated using a 10% required rate of return. Year 0 Year 1 Year 2 Year 3 Total Total Benefits 45,000 50,000 57,000 PV of Total Benefits 40,909 41,322 42,825 125,056 Total Costs 100,000 10,000 12,000 16,000 FIGURE 1-9 Discounted Cash PV of Total Costs 100,000 9,091 9,917 12,021 131,029 Flow Projection 22 C ha pt er 1 The Systems Analyst and Information Systems Development Net Present Value (NPV) The NPV is simply the difference between the total present value of the benefits and the total present value of the costs. NPV 5 © PV of Total Benefits 2 © PV of Total Costs 5 $125,056 2 $131,029 5 ($5,973) As long as the NPV is greater than zero, the project is considered economically acceptable. Unfortunately for this project, the NPV is less than zero, indicating that for a required rate of return of 10%, this project should not be accepted. The required rate of return would have to be something less than 6.65% before this project returns a positive NPV. This example illus- trates the fact that sometimes the “naïve” techniques of ROI and BEP find that the project appears acceptable, but the more rigorous and financially correct NPV technique finds the project is actually unacceptable. Figure 1-10 reviews the steps involved in performing an economic feasibility analysis. Each step will be illustrated by an example in the upcoming sections. Identify Costs and Benefits The systems analyst’s first task when developing an economic feasibility analysis is to identify the kinds of costs and benefits the system will have and list them along the left-hand column of a spreadsheet. Figure 1-11 lists examples of costs and benefits that may be included. The costs and benefits can be broken down into four categories: (1) development costs, (2) operational costs, (3) tangible benefits, and (4) intangibles. Development costs are those tangible expenses that are incurred during the creation of the system, such as salaries for the project team, hardware and software expenses, consultant fees, training, and office space and equipment. Development costs are usually thought of as one-time costs. Operational costs are those tangible costs that are required to operate the system, such as the salaries for operations staff, software licensing fees, equipment upgrades, and cloud vendor fees. Operational costs are usually thought of as ongoing costs. As you can see from the list of Operational Costs in Figure 1-11, it is important to include every relevant cost factor over the life of the system, so that we estimate the Total Cost of Ownership (TCO). 1. Identify Costs and Benefits List the tangible costs and benefits for the project. Include both one-time and recurring costs. 2. Assign Values to Costs and Benefits Work with business users and IT professionals to create numbers for each of the costs and benefits. Even intangibles should be valued if at all possible. 3. Determine Cash Flow Forecast what the costs and benefits will be over a certain period, usually, 3–5 years. Apply a growth rate to the values, if necessary. 4. Assess Project‘s Economic Value Evaluate the project’s expected returns in comparison to its costs. Use one or more of the following evaluation techniques: Return on Investment (ROI) Calculate the rate of return earned on the money invested in the project, using the ROI formula. Break-Even Point (BEP) Find the year in which the cumulative project benefits exceed cumulative project costs. Apply the breakeven for- mula, using figures for that year. This calculation measures how long it will take for the system to produce benefits that cover its costs. FIGURE 1-10 Net Present Value (NPV) Restate all costs and benefits in today’s dollar terms (pre- sent value), using an appropriate discount rate. Determine Steps to Conduct an whether the total present value of benefits is greater than or Economic Feasibility less than the total present value of costs. Analysis  Feasibility Analysis 23 Development Costs Operational Costs Development team salaries Software upgrades Consultant fees Software licensing fees Development training Hardware repair and u