Although we will discuss feasibility analysis now within the context of project initiation, most project teams will revise their 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 necessary improvements. Technical Feasibility The first technique in the feasibility analysis is to assess the technical featibility 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? Many risks can endanger the successful completion of the project. First and foremost is the users and analysts’ humiliarity 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 are less familiar with an application. such as with the development of a system to support a new business innovation (c.es Microsoft starting up a new Internet dating service). 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 tectmical risk When a system will use technology that has not been used before within the bryan- ization, there is a greater chance that problems will occur and deluys will be incurred because of the need to learn how to use the technology. Risk increases dra- matically when the technology itself is new (e.g., web development using Ajax). 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. The extent to which the project is highly integrated with other systems (which is typical of large systems) can cause problems, because complexity is increased when many systems must work together. Finally, project teams need to consider the compatibility of the new system with the technology that already exists in the organization Systems farcly are 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 sys- tems, 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 (c-g., how large does a project need to grow before it becomes less feasible?). One approach is to compare the project under consideration with prior projects undertaken by the * We use the words build it in the best sens. Organizations can also choose to buy a commercial software package and install it, in which case the question might be “Can we select the right package and successfully installing