The Software Wiki

Feasibility study

Properties2
tagsprocess, concept
aliasesFeasibility analysis, Feasibility assessment, Feasibility report, TELOS

6 min read

Feasibility study

By Allen Jay Bercero

A feasibility study is an assessment carried out before committing serious time or money to a project, to judge whether the proposed software is actually worth building, whether it is technically possible, economically worthwhile, legally allowed, operationally workable, and achievable in the time available. It ends with a clear go / no-go recommendation.

It belongs to the Planning stage of the SDLC. Its whole job is to catch expensive mistakes on paper, cheaply, before anyone writes code, to answer “should we even do this, and can we?” rather than “how will we do it?”

Also known as

feasibility analysis · feasibility assessment · feasibility report · (in lean/agile teams) often folded into product discovery, a spike, or a proof of concept instead of a formal document

Don't confuse with: business plan, business case & friends

This is the distinction people get wrong most (see the note below on why).

  • Business plan: written after you’ve decided to go ahead. It describes how you’ll build, run, market, and fund the venture: company description, marketing plan, operations, management team, and multi-year financial projections. Its purpose is execution and attracting investment. A feasibility study asks “should we?”; a business plan assumes “we are. Here’s how.”
  • Business case: the focused argument for why the investment is justified (costs vs. benefits vs. alternatives, ROI). Often written up from a feasibility study’s findings.
  • Project charter: the document that formally authorizes the project once it’s approved (names the sponsor, objectives, high-level scope).
  • Software requirements specification (SRS): the detailed what to build, produced later, in the Requirements stage.
  • Proof of concept (PoC) / spike: a small build to prove one specific thing is technically possible. It’s evidence that feeds the technical-feasibility section; it isn’t the study itself.

A SWOT analysis, an executive summary, and financial projections appear in BOTH feasibility studies and business plans. Seeing them tells you nothing about which document you’re holding. Look at the purpose instead.

The five dimensions (TELOS)

A thorough feasibility study checks the idea from five angles, remembered by the acronym TELOS:

DimensionThe question it answersTypical evidence
TechnicalCan we actually build it with technology and skills we have or can get?architecture sketch, a proof-of-concept, team skill audit
EconomicIs it worth it? Do the benefits beat the costs?cost–benefit analysis, ROI, payback period, total cost of ownership
LegalAre we allowed to? Any regulatory, licensing, IP, or privacy blockers?regulations, data-protection law, contracts, patents
OperationalWill it fit how the organization and users actually work, and will they adopt it?stakeholder input, process fit, change-management risk
SchedulingCan it be done in the time available?high-level timeline, dependencies, deadline vs. estimate

(Market feasibility (is there real demand?) is sometimes added as a sixth, especially for products aimed at customers.)

In plain English

Five gut-checks before you commit: Can we build it? Is it worth it? Are we allowed? Will people use it? Can we finish in time? If any answer is a hard no, that’s what the study is for.

How to conduct one

  1. Define the problem and scope. What need or opportunity is this, and what are the boundaries?
  2. Gather information. Talk to stakeholders; document constraints and the current situation.
  3. Identify alternatives. Usually at least: build it, buy/adopt an existing solution, or do nothing. (Do-nothing is a real option and a useful baseline.)
  4. Assess each alternative against the five TELOS dimensions.
  5. Analyze costs, benefits, and risks. Quantify where you can; name assumptions where you can’t.
  6. Recommend. A clear verdict (go, no-go, or go with conditions) with the reasoning. This recommendation is the point of the whole exercise.

What goes in the report (format)

A typical software feasibility study report:

  1. Title page
  2. Table of contents
  3. Executive summary: the recommendation and key findings up front, for readers who won’t read further
  4. Introduction: background, problem/opportunity statement, objectives, and scope
  5. Current situation: the context and any existing system
  6. Proposed solution(s): the alternatives considered
  7. Feasibility analysis: one section each for Technical, Economic, Legal, Operational, Schedule (SWOT and a risk assessment usually live here)
  8. Cost–benefit analysis / financials
  9. Risks and assumptions
  10. Recommendation and conclusion: go / no-go / go-with-conditions
  11. Appendices: data, diagrams, supporting detail

In agile / modern practice

Heavyweight formal feasibility studies are mostly an enterprise and plan-driven habit, common for large, high-cost, or regulated projects. Startups and agile teams usually do a lighter-weight version of the same thinking:

  • a Lean canvas or one-page brief instead of a long report,
  • a technical spike / proof of concept to settle just the risky technical question,
  • an MVP to test market feasibility empirically, by shipping something small to real users, rather than arguing it on paper.

The five TELOS questions still apply; only the ceremony shrinks.

Feasibility study vs. business plan: a lending app

For a mobile app connecting borrowers to lending firms, a feasibility study would weigh: technical (can we integrate with banks/payment rails and secure sensitive financial data?), economic (build cost vs. projected fee revenue and payback), legal (lending regulation, data-privacy law), operational (will lenders and borrowers actually adopt it?), and schedule (can we launch before a competitor?), then end with go or no-go. A business plan for the same app instead assumes the go decision is made and lays out the mission, marketing plan, org chart, and multi-year financial projections. Same subject; different document, different purpose.

See also

References

Graph View

Backlinks