What Is a Feasibility Study?
What Is a Feasibility Study?
A clinic wants to replace its paper appointment book with an online booking system. An online retailer wants to build a real-time inventory dashboard. A logistics firm wants to automate its last-mile delivery routing. Each idea sounds promising — but before a single line of code is written, a critical question must be answered: should this project go ahead at all?
A feasibility study is a structured, evidence-based investigation that answers exactly that question. It examines whether a proposed system or project is worth pursuing, from multiple angles: technical capability, financial viability, organizational readiness, legal compliance, and more. The output is not a design document — it is a go/no-go recommendation backed by analysis.
Why Feasibility Studies Exist
Software projects fail for predictable reasons. The Standish Group Chaos Report consistently finds that over 30% of IT projects are cancelled outright, and fewer than 20% finish on time, on budget, and with all originally promised features. Many of those failures were foreseeable: the technology was not mature enough, the budget was unrealistic, the organization had no appetite to change its processes, or a key regulation made the approach illegal.
A feasibility study forces the project team and sponsors to confront those questions systematically — before commitments are made, contracts are signed, or development begins. The cost of a good feasibility study is typically 1–3% of total project cost. The cost of discovering a fatal flaw after development starts is many times larger.
Consider a concrete example. A mid-sized logistics firm wants to build a proprietary AI-based route optimization engine to replace its current manual dispatching. A naive analysis might say "Yes, route optimization is a solved problem — let's build it." A feasibility study would reveal:
- The firm has only two data engineers and no ML expertise (technical risk).
- Commercial routing SaaS products already exist for a fraction of the build cost (economic alternative).
- Dispatchers have informally resisted previous automation attempts (operational risk).
- The project timeline overlaps with a peak season freeze on IT changes (schedule constraint).
None of these problems is fatal in isolation, but together they might redirect the project toward a "buy or subscribe" decision rather than a custom build — saving months of wasted effort.
The Dimensions of Feasibility
A thorough feasibility study examines a project through five to six distinct lenses. Analysts sometimes remember them with the acronym TELOS (Technical, Economic, Legal, Operational, Schedule), with some frameworks adding a sixth — Risk. Each dimension asks a different question and can independently produce a no-go verdict.
Each Dimension at a Glance
Later lessons explore each dimension in depth. Here is a quick orientation:
- Technical feasibility — Does the required technology exist and is your team capable of implementing it? A clinic wanting to build a real-time video consultation feature must ask whether its servers, network, and staff can support WebRTC — not just whether WebRTC exists as a technology.
- Economic feasibility — Do the projected benefits (revenue, cost savings, productivity gains) justify the full costs (development, licenses, training, maintenance) over a realistic time horizon? This is where Net Present Value (NPV), Return on Investment (ROI), and payback period calculations live.
- Legal feasibility — Does the proposed system comply with applicable regulations? A patient booking system that stores health data must comply with HIPAA or GDPR depending on jurisdiction. A financial platform must align with local banking and data-residency laws.
- Operational feasibility — Will the organization actually use the system? A technically perfect system that dispatchers refuse to adopt, or that requires a complete process overhaul the business is unwilling to fund, is not operationally feasible.
- Schedule feasibility — Can the project be completed within the time frame that makes it valuable? An e-commerce platform that misses the holiday shopping season by two months may have lost its primary business case.
- Risk assessment — What are the major threats (technology, market, organizational, financial) and how likely and severe are they? A project with acceptable scores on all five TELOS dimensions may still fail if one catastrophic risk has not been mitigated.
The Go/No-Go Decision
At the end of a feasibility study, the analyst and sponsors sit down with the findings and make one of three recommendations:
- Go — the project is feasible on all significant dimensions; proceed to detailed requirements and planning.
- Go with conditions — the project is feasible if specific conditions are met (e.g., hire a security specialist, reduce scope, obtain regulatory pre-approval).
- No-go — one or more dimensions present insurmountable obstacles; the project should be abandoned or fundamentally redesigned.
A "no-go" verdict is not a failure — it is exactly the result the feasibility study is designed to deliver when appropriate. Stopping a doomed project early saves budget, team morale, and opportunity cost. The money not spent on an infeasible system can be redirected to one that will actually work.
Who Conducts a Feasibility Study?
In most organizations a feasibility study is led by a systems analyst or business analyst, often working alongside a small team that includes a subject matter expert from the business, a technical architect, a finance representative, and — for regulated industries — a compliance officer. Keeping the team small but cross-functional is important: an analyst working alone will miss business nuances; a team of developers working without a finance perspective will underestimate costs.
The study is commissioned by a project sponsor — usually a senior manager or executive who holds the budget authority and must ultimately make the go/no-go call. The analyst's job is to produce an honest, evidence-based report. It is the sponsor's job to make the decision.
Feasibility vs. Requirements
A common confusion among new analysts is mixing feasibility analysis with requirements gathering. They are sequential, not simultaneous. The feasibility study answers "should we build this?" Requirements analysis (the next phase) answers "what exactly must it do?" Starting requirements before feasibility is complete often means writing detailed specifications for a system that should never have been approved — wasted effort that also anchors stakeholders emotionally to a bad idea.
A Quick Summary
A feasibility study is the analyst's first major deliverable on any significant project. It is a disciplined investigation across six dimensions — Technical, Economic, Legal, Operational, Schedule, and Risk — that produces a defensible go/no-go recommendation. Its value is not in the paperwork it generates but in the bad projects it prevents and the good ones it helps launch with their eyes open.
In the lessons that follow, we will examine each dimension in detail, learn how to quantify costs and benefits, build a risk register, and structure the final feasibility report — illustrated throughout with the clinic booking system, online store, and logistics firm scenarios introduced here.