Feasibility Analysis and Project Selection

Introduction

System analysis and design begins long before analysts draw models or write requirements. An organization must first determine whether a proposed information system is desirable, achievable, affordable, acceptable, lawful, and deliverable within the required time. Feasibility analysis provides this disciplined investigation. Project selection compares feasible alternatives and recommends the proposal that offers the strongest overall value in relation to cost, risk, strategic fit, and organizational capacity.

A technically excellent system may fail because users reject it. A profitable idea may be unlawful. A low-cost solution may create unacceptable security risks. Feasibility analysis therefore does not ask only, “Can we build it?” It asks, “Should we build it, under what conditions, and compared with which alternatives?”

Learning Objectives

After completing this chapter, you should be able to:

1. Explain the purpose, scope, and stages of feasibility analysis.
2. Evaluate technical, economic, operational, legal, schedule, and organizational feasibility.
3. Prepare a cost-benefit analysis using tangible and intangible benefits.
4. Apply ROI, payback period, present value, and risk-adjusted reasoning.
5. Use weighted-scoring techniques to compare project alternatives.
6. Identify feasibility risks, assumptions, constraints, and ethical issues.
7. Prepare a defensible project-selection recommendation.

1. Feasibility Analysis in the Systems Life Cycle

Feasibility analysis normally follows preliminary problem identification and precedes detailed requirements analysis. Its output is a feasibility report or business case containing the problem, alternatives, assumptions, estimated costs and benefits, risks, constraints, and recommendation.

The analysis is iterative. Early estimates are uncertain; as requirements, architecture, vendors, and organizational impacts become clearer, estimates should be updated. A feasibility decision is therefore a reasoned decision based on available evidence, not a guarantee of success.

A useful distinction is:

• Feasible: Practically achievable under stated constraints.
• Viable: Likely to produce sufficient value to justify investment.
• Desirable: Aligned with stakeholder needs and organizational strategy.
• Approved: Formally authorized after governance review.

A project may be feasible but not selected because another feasible project has greater strategic value.

The feasibility dimensions

These dimensions overlap. For example, a legal requirement may increase cost; a compressed schedule may require a simpler technical design; and limited organizational capacity may make an otherwise affordable system infeasible.

2. Defining the Proposal and Its Alternatives

Poorly defined proposals produce unreliable feasibility studies. The analyst should first document:

• the business problem and its causes;
• affected stakeholders and users;
• objectives expressed as measurable outcomes;
• scope boundaries and exclusions;
• current-system limitations;
• assumptions and constraints;
• candidate alternatives; and
• decision criteria and approval authority.

Alternatives should include more than a preferred technology. Common alternatives are:

1. Do nothing: Continue the current system, accepting its costs and risks.
2. Improve the existing system: Modify current processes or software.
3. Build internally: Develop and operate a custom solution.
4. Buy or subscribe: Acquire commercial software or cloud services.
5. Outsource: Transfer development or operations to a supplier.
6. Hybrid approach: Combine internal capabilities with external services.
7. Pilot or phased implementation: Test the concept before full deployment.

The “do nothing” alternative is important because it establishes the baseline against which incremental costs and benefits are measured. It is not necessarily cost-free: existing maintenance, inefficiency, security exposure, and missed opportunities continue.

3. Technical Feasibility

Technical feasibility assesses whether the proposed solution can be designed, implemented, integrated, secured, maintained, and scaled with available technology and expertise.

3.1 Technical assessment areas

Technology maturity. Mature technologies generally have stronger documentation, tools, talent pools, and support. Emerging technologies may offer advantages but introduce uncertainty.

Architecture and integration. The analyst examines compatibility with operating systems, networks, databases, identity services, APIs, legacy systems, and data standards. An interface that is technically possible may still be expensive or unreliable if the legacy system is poorly documented.

Capacity and performance. Expected transaction volume, response time, storage, availability, and growth must be estimated. Capacity should be assessed for normal and peak demand.

Security and resilience. The design should address authentication, authorization, encryption, logging, backup, disaster recovery, vulnerability management, and incident response.

Skills and support. The organization must determine whether it has analysts, developers, testers, administrators, data specialists, and security expertise. Skills may be developed, hired, or obtained from vendors, but each choice affects cost and risk.

Maintainability and scalability. A solution should remain understandable and modifiable. Technical debt, proprietary dependency, data migration complexity, and vendor lock-in should be considered.

A proof of concept is valuable when feasibility depends on uncertain integration, performance, or machine-learning behavior. A proof of concept reduces uncertainty; it does not substitute for a complete production design.

3.2 Technical feasibility questions

• Can required data be obtained, cleaned, migrated, and governed?
• Can the solution meet availability and performance requirements?
• Are interfaces and standards available?
• Can security controls be implemented and independently tested?
• Is the technology mature enough for the consequences of failure?
• What happens if a supplier discontinues the product?
• Can the system be operated and maintained after implementation?

4. Economic Feasibility and Cost-Benefit Analysis

Economic feasibility compares the expected incremental benefits of an alternative with its incremental costs. Estimates should include the complete life cycle, not merely purchase price.

4.1 Cost categories

One-time costs may include feasibility work, procurement, configuration, development, data conversion, training, testing, deployment, and process redesign.

Recurring costs may include subscriptions, hosting, support, licenses, security monitoring, maintenance, staff, connectivity, and periodic upgrades.

Transition costs arise while old and new systems operate together. Productivity may temporarily fall, and parallel running may be necessary.

Risk allowances address uncertainty. They should be documented rather than hidden in arbitrary inflation of estimates.

4.2 Benefits

Benefits may be:

• Tangible: reduced labor hours, lower error costs, reduced inventory, or increased revenue.
• Intangible: improved trust, employee morale, service quality, or managerial insight.
• Direct: immediately attributable to the system.
• Indirect: produced through related process or organizational changes.
• One-time: such as avoided migration loss.
• Recurring: such as annual savings.

Intangible benefits should not be ignored. They may be described with measurable indicators, such as satisfaction scores, complaint rates, decision turnaround time, or compliance incidents.

4.3 Basic financial measures

Net benefit over a period is:

Return on investment (ROI) is commonly expressed as:

Here, benefits and costs must cover the same evaluation period and use consistent treatment of taxes, inflation, and financing. ROI is a ratio, not a complete investment decision rule; it can favor a small project with a high percentage return over a strategically essential project with a larger absolute benefit.

Payback period is the time required for cumulative net cash inflows to recover the initial investment. If annual net cash inflow is constant:

This shortcut applies only when annual net inflows are approximately equal. With unequal cash flows, cumulative cash flows must be calculated year by year. Payback ignores benefits and costs after recovery and normally ignores the time value of money.

4.4 Discounted cash flow and net present value

Money received in the future is generally worth less than money received today because of opportunity cost, risk, and inflation. Net present value (NPV) discounts future net cash flows:

where C₀ is the initial cash outflow at time zero, Cₜ is the net cash flow in period t, r is the discount rate per period, and n is the number of periods. Cash flows must use the same time unit as the discount rate. Under the usual financial assumptions, a positive NPV indicates that the project is expected to create value at the selected discount rate, although strategic, legal, and operational factors remain relevant.

Worked example: economic comparison

An organization considers a system costing $60,000 initially. It expects net benefits of $25,000 in each of the next three years. Ignoring tax and residual value:

Total benefits = 3 × $25,000 = $75,000.

ROI = ($75,000 − $60,000) ÷ $60,000 × 100% = 25%.

Payback period = $60,000 ÷ $25,000 = 2.4 years.

If the discount rate is 10%, the NPV is approximately:

NPV = −60,000 + 25,000 ÷ 1.10 + 25,000 ÷ 1.10² + 25,000 ÷ 1.10³

= −60,000 + 22,727 + 20,661 + 18,783

= approximately $2,171.

The project has a positive but modest discounted value. Decision makers should investigate estimation uncertainty, implementation risk, and whether the benefits are genuinely incremental.

5. Operational Feasibility

Operational feasibility asks whether the system will function effectively in the real organization. It focuses on people, processes, policies, and day-to-day use.

Important questions include:

• Does the proposed process solve the original problem?
• Are roles, responsibilities, and decision rights clear?
• Will users have incentives and time to adopt the system?
• Does the system support accessibility and different user abilities?
• Are training, help-desk, and support arrangements adequate?
• Can existing work continue during transition?
• How will performance and benefits be measured after implementation?

Resistance is not automatically irrational. Users may identify risks that sponsors overlook, such as increased workload, surveillance, loss of autonomy, or unrealistic targets. Good analysis distinguishes legitimate concerns from misinformation and addresses both through participation, communication, training, and redesign.

Operational feasibility is strengthened by prototypes, usability testing, workflow simulation, pilot deployment, role-based training, and clearly assigned ownership.

6. Legal, Ethical, and Regulatory Feasibility

Legal feasibility examines whether the project complies with applicable law, regulation, contracts, standards, and internal policies. The precise rules depend on jurisdiction and sector, so analysts should obtain qualified legal advice rather than treating a checklist as legal approval.

Relevant issues may include:

• privacy and lawful processing of personal data;
• consent, retention, access, correction, and deletion requirements;
• intellectual-property ownership and software licensing;
• accessibility and non-discrimination obligations;
• employment, consumer-protection, financial, health, or education regulation;
• records management and audit requirements;
• cloud, outsourcing, cross-border transfer, and supplier contracts;
• cybersecurity notification duties; and
• electronic transactions and evidence.

Ethical feasibility is broader than legal compliance. A system can be legal yet unfair, intrusive, opaque, or harmful. Analysts should examine data minimization, purpose limitation, explainability, bias, human oversight, and possible effects on vulnerable groups. Automated decisions require particular care: data quality does not guarantee fairness, and an accurate average prediction may still produce discriminatory outcomes for a subgroup.

A legal and ethical review should identify obligations, owners, evidence required for compliance, and consequences of non-compliance. Compliance should be designed into requirements and architecture rather than added at the end.

7. Schedule Feasibility

Schedule feasibility evaluates whether the project can deliver its required scope by the required date with available resources and dependencies.

The analyst should identify activities, estimates, dependencies, milestones, procurement lead times, approvals, testing windows, training, migration, and contingency. A schedule becomes unreliable when it includes only development and omits requirements validation, security review, user acceptance testing, data cleansing, deployment, and stabilization.

For an activity with optimistic time a, most-likely time m, and pessimistic time b, the PERT expected time is:

This estimate assumes a suitable three-point model and is useful for planning uncertainty; it is not a guarantee and should not replace empirical estimates. Activities on the critical path determine the earliest possible project completion. A delay in a critical-path activity delays the project unless schedule compression or replanning occurs.

Schedule compression may involve adding resources, overlapping activities, reducing scope, or using phased delivery. Adding resources does not always shorten a task because communication and coordination overhead may increase. A deadline should therefore be treated as a constraint to analyze, not a date to declare achievable without evidence.

8. Organizational and Strategic Feasibility

Organizational feasibility concerns strategic alignment, sponsorship, governance, culture, capability, and competing priorities. A project can have a positive NPV and still fail because no business owner accepts responsibility for its outcomes.

Assessment areas include:

• alignment with organizational strategy and portfolio priorities;
• executive sponsorship and stakeholder authority;
• availability of business and technical staff;
• maturity of project, data, security, and change management;
• compatibility with organizational culture;
• decision-making and escalation arrangements;
• funding continuity; and
• ability to measure and realize benefits.

A benefit owner should be assigned for each major expected benefit. For example, the IT department may deliver a reporting platform, but a sales director may own the improvement in sales forecasting. This prevents “benefits” from becoming unsupported claims in a business case.

9. Risk Analysis in Feasibility Studies

Risk is uncertain future variation that may affect objectives. A feasibility study should record risks, causes, consequences, likelihood, impact, response, owner, and trigger indicators.

A simple qualitative risk matrix classifies likelihood and impact as low, medium, or high. A quantitative expected monetary value may be calculated as:

For example, a 20% probability of a $30,000 loss gives an EMV of $6,000. EMV is useful for aggregating some financial uncertainties, but it does not capture reputational harm, legal consequences, correlated risks, or the difference between a frequent small loss and a rare catastrophic loss.

Common responses are avoid, reduce, transfer, accept, or exploit. A vendor contract may transfer some delivery risk but cannot transfer the organization's accountability for privacy or service outcomes. Risk analysis should be revisited when assumptions change.

10. Weighted-Scoring for Project Selection

Financial analysis alone is insufficient when projects have different strategic, technical, social, or regulatory effects. A weighted-scoring model compares alternatives against explicit criteria.

Let w_i be the weight of criterion i, with all weights summing to 1, and let s_ij be the score of alternative j on criterion i. The weighted score is:

Scores must use a common scale, such as 1 to 5, and evaluators should define what each score means. A cost criterion must be scored so that a higher score consistently means more desirable; otherwise the result can be mathematically neat but conceptually wrong.

Worked selection example

Two alternatives are scored from 1 (poor) to 5 (excellent).

Build: 0.25(5)+0.20(3)+0.25(4)+0.15(3)+0.15(4)=3.85.

Subscribe: 0.25(4)+0.20(5)+0.25(3)+0.15(4)+0.15(4)=3.95.

The subscription alternative ranks higher, but the difference is small. Decision makers should conduct sensitivity analysis: if the strategic-fit weight or subscription cost changes, the recommendation may change. A high score does not override a mandatory legal or security failure. Such criteria should be treated as gates before weighted scoring.

11. Preparing the Feasibility Report

A professional report commonly contains:

1. Executive summary and recommendation.
2. Problem statement, objectives, scope, and stakeholders.
3. Current-state assessment and baseline costs.
4. Alternatives considered, including do nothing.
5. Technical, economic, operational, legal, schedule, and organizational findings.
6. Assumptions, constraints, dependencies, and exclusions.
7. Cost-benefit calculations and sensitivity analysis.
8. Risk register and proposed controls.
9. Implementation approach, milestones, and governance.
10. Decision criteria, approval required, and next steps.

The report should distinguish facts, estimates, assumptions, judgments, and unresolved questions. Confidence ranges are preferable to false precision. For example, “$80,000–$100,000 based on three supplier quotations” is more credible than “$91,347” when design is incomplete.

Illustrative Case: Student Service Portal

Background

A fictional university receives registration, fee, and examination queries through email, telephone, and counter service. Response times are long, students receive inconsistent answers, and staff duplicate data entry.

Problem and alternatives

The university defines an objective: reduce average response time by 40% within one academic year while maintaining privacy and accessibility. It considers:

• continuing the current process;
• customizing the existing student-information system;
• subscribing to a service-management portal integrated through APIs; and
• building a new portal internally.

Analysis

Technical investigation finds that the existing system has documented APIs, but its data model contains duplicate student records. The subscription portal is technically feasible if identity federation and data-processing terms are approved. A custom portal offers flexibility but requires scarce security and integration skills.

Economic analysis includes configuration, integration, training, data cleansing, subscription, support, and transition costs. The team avoids counting “hours saved” as a benefit unless the university can actually redeploy those hours or reduce overtime. It estimates benefits through reduced overtime, fewer duplicate contacts, and improved retention-related service quality.

Operational workshops reveal that students need mobile accessibility and clear escalation paths. Staff request a knowledge-base editing workflow and fear that automation will conceal unusual cases. The proposed design therefore includes human escalation and service-quality monitoring.

Legal review identifies privacy, retention, accessibility, supplier audit, and breach-notification requirements. The procurement contract must specify data ownership, return and deletion, incident notification, subcontractors, availability, and exit assistance.

Schedule analysis shows that a full custom build cannot be safely tested before registration. A phased subscription pilot covering fees and enrollment is feasible before the peak period; examination services can follow after evaluation.

Recommendation and outcome

The illustrative steering committee selects a phased subscription pilot, subject to security and contract gates. It assigns the registrar as benefit owner, IT as technical owner, and a student representative group for usability testing. Success measures include response time, first-contact resolution, accessibility defects, user satisfaction, privacy incidents, and support workload.

The case demonstrates that project selection is not simply “buy versus build.” It combines evidence from architecture, economics, operations, law, schedule, and governance. The phased approach also creates a controlled opportunity to learn before committing to full deployment.

Challenges and Limitations

Feasibility analysis has unavoidable limitations:

• early costs and benefits are uncertain;
• intangible benefits are difficult to monetize;
• weighted scores may conceal subjective judgments;
• stakeholders may deliberately bias assumptions;
• interdependent projects may invalidate isolated analysis;
• benefits may depend on organizational change rather than software alone;
• future regulation and technology may change;
• discount rates and planning horizons influence financial conclusions; and
• a feasible project may still fail through weak execution.

Good practice is not to pretend uncertainty does not exist. It is to expose assumptions, test alternatives, document confidence, perform sensitivity analysis, and define conditions for proceeding.

Contemporary Practice and AI

Cloud services, low-code platforms, automation, and generative artificial intelligence can reduce development time, but they do not remove feasibility responsibilities. AI projects require additional examination of training-data rights, privacy, bias, explainability, model drift, security, human oversight, and error consequences. Vendor claims should be tested with representative data and measurable acceptance criteria.

Modern organizations increasingly use product discovery, agile delivery, platform engineering, sustainability assessment, and continuous business-case review. A project may begin with a small experiment, pass a governance gate, and then receive funding incrementally as evidence accumulates. This reduces exposure but requires disciplined stopping rules; a pilot should not continue indefinitely without demonstrating value.

Best-Practice Checklist

• Define the problem before selecting a technology.
• Compare several alternatives, including do nothing.
• Use life-cycle costs and incremental benefits.
• Separate mandatory compliance gates from discretionary scoring.
• Involve users, technical specialists, finance, legal, security, and operations.
• State assumptions and confidence ranges.
• Use ROI and payback with NPV or other time-value analysis where appropriate.
• Test technical uncertainty through prototypes or pilots.
• Assign owners for risks and benefits.
• Revisit feasibility when scope, estimates, regulations, or dependencies change.
• Make ethical, accessibility, privacy, and security requirements explicit.

Chapter Summary

Feasibility analysis determines whether a proposed information system is achievable, valuable, acceptable, lawful, timely, and aligned with organizational capability. It examines technical, economic, operational, legal, schedule, and organizational dimensions. Economic analysis includes complete life-cycle costs, tangible and intangible benefits, ROI, payback, and discounted cash flow such as NPV. Risk analysis exposes uncertainty and assigns responses. Weighted-scoring models support comparison across financial and non-financial criteria, but mandatory legal or security requirements should operate as gates. A sound project-selection recommendation is evidence-based, transparent about assumptions, sensitive to uncertainty, and connected to benefit ownership and governance. Feasibility is not a one-time formality: it should be reviewed as knowledge improves and conditions change.

Key Terms

Feasibility analysis: Systematic assessment of whether a proposed project should and can proceed.

Project selection: Choosing among feasible project alternatives.

Technical feasibility: Assessment of technology, integration, security, skills, and maintainability.

Economic feasibility: Assessment of costs, benefits, financial value, and affordability.

Operational feasibility: Assessment of organizational use, processes, acceptance, and support.

Legal feasibility: Assessment of laws, regulations, contracts, licenses, and policy obligations.

Schedule feasibility: Assessment of whether required outcomes can be delivered on time.

Organizational feasibility: Assessment of strategic fit, sponsorship, culture, and capability.

Business case: Structured justification for investment and action.

Baseline: The current situation against which incremental change is measured.

Tangible benefit: Benefit that can be directly measured in financial or operational terms.

Intangible benefit: Benefit that is real but difficult to express precisely in monetary terms.

ROI: Return on investment, commonly net benefit divided by cost.

Payback period: Time required to recover an initial investment from net cash inflows.

NPV: Present value of future net cash flows minus the initial investment.

Risk: Uncertainty that may affect project objectives.

EMV: Expected monetary value, calculated as probability multiplied by monetary impact.

Weighted-scoring model: Decision method combining criterion scores and weights.

Critical path: Sequence of schedule activities determining the earliest completion date.

Benefit owner: Person accountable for realizing and measuring an expected benefit.

Review Questions

Short Answer Questions

1. What is the purpose of feasibility analysis in the systems life cycle?
2. Distinguish tangible benefits from intangible benefits.
3. Why should the do-nothing alternative be included in a feasibility study?
4. What is the difference between ROI and payback period?
5. Why should legal and security requirements sometimes be treated as decision gates?

Long Answer Questions

1. Explain the six major dimensions of feasibility and show how they influence one another.
2. Describe how a complete life-cycle cost-benefit analysis should be prepared.
3. Explain NPV, including its variables, assumptions, and limitations in information-system decisions.
4. Describe the process of preparing and evaluating a weighted-scoring model.
5. Discuss how stakeholder participation, change management, and benefit ownership affect operational feasibility.

Analytical / Application Questions

1. An organization can build a system for $120,000 with annual net benefits of $50,000 for three years, or subscribe for $20,000 initially and $35,000 annually with annual benefits of $48,000. Identify the cost and benefit assumptions that must be clarified before selecting an option, and recommend suitable comparison measures.
2. A project has strong ROI but requires personal-data processing, lacks a data-retention design, and cannot complete a privacy review before launch. Should it proceed? Justify your answer using feasibility gates and risk reasoning.
3. Construct a weighted-scoring model for selecting between an internal build and a cloud service. Choose at least five criteria, assign weights totaling 1, define a 1–5 scoring scale, and explain how sensitive your recommendation is to changes in the weights.

Multiple Choice Questions with Answers

Question 1

Which alternative establishes the baseline for incremental project costs and benefits?

A. The do-nothing alternative

B. The most expensive alternative

C. The vendor-preferred alternative

D. The technically newest alternative

Correct Answer: A. The do-nothing alternative

Question 2

Which feasibility dimension focuses primarily on user acceptance, processes, training, and support?

A. Technical feasibility

B. Operational feasibility

C. Schedule feasibility

D. Legal feasibility

Correct Answer: B. Operational feasibility

Question 3

A project costs $40,000 and produces total benefits of $50,000 over the evaluation period. What is its simple ROI?

A. 10%

B. 20%

C. 25%

D. 40%

Correct Answer: C. 25%

Question 4

Which measure explicitly discounts future cash flows?

A. Payback period

B. Simple ROI

C. Gross benefit

D. Net present value

Correct Answer: D. Net present value

Question 5

In a weighted-scoring model, what must the criterion weights usually sum to?

A. 0.5

B. 1.0

C. 5.0

D. 100.0

Correct Answer: B. 1.0

Question 6

A risk has a 0.10 probability of causing a $50,000 loss. What is its expected monetary value?

A. $500

B. $5,000

C. $50,000

D. $500,000

Correct Answer: B. $5,000

Question 7

Which issue is most directly associated with legal feasibility?

A. Response-time capacity

B. Developer productivity

C. Privacy and software licensing obligations

D. Employee enthusiasm

Correct Answer: C. Privacy and software licensing obligations

Question 8

Why is a prototype useful in feasibility analysis?

A. It guarantees production success

B. It eliminates the need for requirements

C. It reduces uncertainty about selected technical issues

D. It replaces legal review

Correct Answer: C. It reduces uncertainty about selected technical issues

Question 9

If an initial investment is $60,000 and constant annual net cash inflow is $15,000, the simple payback period is:

A. 2 years

B. 3 years

C. 4 years

D. 5 years

Correct Answer: C. 4 years

Question 10

Which statement about a high weighted score is correct?

A. It automatically overrides a legal prohibition

B. It proves that all estimates are accurate

C. It removes the need for stakeholder participation

D. It supports comparison but does not replace judgment or mandatory gates

Correct Answer: D. It supports comparison but does not replace judgment or mandatory gates