Feasibility is the measure of how beneficial or practical the development of the Life cycle an information system will be to an organization. Feasibility analysis is the process which feasibility is measured.
Feasibility should be measured throughout the life cycle. In earlier chapters we called this a creeping commitment approach to feasibility. The scope and complexity of an apparently feasible project can change after the initial problems and opportunities are fully analyzed or after the system has been designed. Thus, a project that is feasible at one point may become infeasible later. Let‘s study some checkpoints for our systems development life cycle.
If you study your company‘s project standards or systems development life cycle (SDLC), you`ll probably see a feasibility study phase or deliverable, but not an explicit ongoing process. These checkpoints and reviews identify specific times during the life cycle when feasibility is reevaluated. A project can be canceled or revised in scope, schedule, or budget at any of these checkpoints. Thus, an explicit feasibility analysis phase in any life cycle should be considered to be only an initial feasibility assessment.
Feasibility checkpoints can be installed into any SDLC that you are using. The checkpoints are represented red diamonds. The diamonds indicate that a feasibility reassessment and management review should be conducted at the end of the prior phase (before the next phase). A project may be canceled or revised at any checkpoint, despite whatever resources have been spent. This idea may bother you at first. Your natural inclination may be to justify continuing a project based on the time and money you‘ve already spent. A fundamental principle of management is never to throw good money after bad—cut your losses and move on to a more feasible project. That doesn‘t mean the costs already spent are not important. Costs must eventually be recovered if the investment is ever to be considered a success.