In 2021, to the great disappointment of space exploration fans, NASA postponed a long-awaited return to the Moon by at least a year. The authorities admitted that the previous 2024 deadline for human landing “...was not grounded in technical feasibility.”
Tech miscalculations are not unique to ambitious, state-backed space endeavors. They may occur with initiatives of any size if their feasibility is not thoroughly analyzed. This article explains what aspects to examine before starting a software project. Don’t be like NASA; make sure that your product launch will succeed!
Feasibility study: why you need it
A feasibility study, or feasibility analysis, assesses the viability of the project idea from different perspectives. Its goal is to help top managers narrow down alternatives and make informed go/no-go decisions.
Five key areas to be covered in an overall feasibility study are hidden in the acronym TELOS, popular with product and project managers.
Five types of feasibility to be explored
As the picture above shows, TELOS stands for the following aspects.
Technical feasibility inspects whether software can be built at all with available tools and experts.
Economic feasibility examines the costs and financial benefits of the project. To determine economic feasibility, a rough order of magnitude (ROM) estimate is commonly performed.
Legal feasibility makes sure that your product complies with all regulations and doesn’t break any law. For example, medical software dealing with protected health information (PHI) must meet HIPAA rules. Besides that, you have to explore what legal risks there are and how they can impact your project.
Operational feasibility explores how a new project will impact daily processes in your company, what procedures should be implemented, and what efforts should be taken to maintain it. Say you’re going to launch a global e-commerce platform. Then, you need to have local warehouses, local service teams, and, in some cases, even local websites in each country. It’s very difficult to realize operationally and might make no sense at all — though the initial idea looks commercially attractive and technically feasible.
Scheduling feasibility gives you a notion of realistic deadlines and helps stick to them.
Obviously, a thorough feasibility study can’t be done without deep knowledge of finance, technologies, and legislation. No wonder that most research studies are often conducted by outside consultants.
When your feasibility consultant is too optimistic:)
In this article, we’ll concentrate on the technical side of feasibility, AltexSoft's area of expertise. That said, we can’t entirely decouple the tech aspect from other analysis aspects of the analysis as they all move forward hand in hand, impacting one another.
What is technical feasibility
In software engineering, technical feasibility (TF) is the most time-consuming and complex part of the full feasibility analysis. So, when speaking about the viability of digital products, we mean their TF in the first place.
As we mentioned before, technical feasibility explores the likelihood of a project being completed from a technical perspective. Yet it inevitably takes into account and depends on the available budget, timeframes, legal constraints, and post-development operations (support and maintenance.)
Feasibility is assessed at the ideation phase of product development, after gathering early project requirements — namely
- functional requirements, captured by business analysts and describing features of the solution; and
- non-functional requirements, usually collected by a software architect and related to the properties of the system — like performance, scalability, and so on.
The feasibility study occurs at the pre-development stage
If at the end of the day, feasibility is confirmed, the analysis serves as a foundation for a business plan that explains how to take the project from concept to reality. If it is not confirmed, you need to manage the client’s expectations and offer alternative ways to achieve business goals.
Tech feasibility assessment is not a matter of a single day. So, for convenience, we divided this process into two large stages: a theoretical study and practical testing with real people involved.
Technical feasibility study example
A technical feasibility study is an in-depth examination of tech factors related to the intended project. It touches on things like
- hardware and software components,
- technical risks and constraints,
- compatibility with other IT systems, and
- capabilities of your engineering team.
The study involves a sequence of steps we’ll examine in more detail.
Consider implementation alternatives
Experts involved: a software or solution architect, other tech leads.
The first thing to do is to consider implementation options. Here, we typically have several alternatives.
Do nothing. Sometimes, a thorough technical inspection reveals that the best option in the current situation is to remain with the existing system. Innovations may entail unjustified risks and unnecessary wastes of money while promising just a bit of improvement.
Select out-of-the-box software and configure it for your needs. Often, the most meaningful choice is to buy an off-the-shelf tool or integrate with a white-label solution, and adjust it to your needs.
It’s especially valid for сommon, widely-used apps like CRM or huge, complex infrastructures that take years to build from the ground up. Examples of massive, hard-to-develop platforms are property management systems for hotels, passenger service systems for airlines, and electronic health record systems for hospitals.
When selecting a ready-to-use product the following aspects should be carefully assessed:
- performance,
- ease of learning
- ease of deployment,
- level of support provided by the vendor,
- compatibility with your other key technologies,
- scalability, and
- licensing options.
Though in this scenario, you don’t need to design everything from scratch, there is still plenty of work to do: implementing and testing APIs, modifying and enhancing code according to your needs (in the case of open-source software), and ensuring that all components work as a single whole.
Read our articles about Sabre API integration and Amadeus API integration which explain that sometimes connecting to third-party platforms takes months and requires not only technical skills but also deep domain expertise.
If you are in the hospitality business, you may be interested in the article on how to integrate with Opera PMS.
Build a custom system. Custom development allows you to accurately meet all business requirements. If it’s feasible — or can be completed within the given time and budget frame — the next step would be investigating technologies and architecture to be used in the project.
Assess hardware and software environment
Experts involved: a software or solution architect, system analysts, IT engineers.
Whether you opt for a ready-to-use product or a custom solution, you must inventory the organization’s hardware and software to answer the question: “Is it possible to run the project using the existing environment?”
Modern systems are built with an eye to customer growth, which means handling more and more daily transactions. But that won’t be feasible without deploying extra servers, purchasing more storage space, and taking other measures to increase the capacity of the IT infrastructure.
For 24/7 service providers like online travel agencies or digital banking platforms, it’s critical not only to have enough processing power but also to permanently stay online. In this case, you must establish network redundancy.
A straightforward way to do it is to install at least one duplicate of the current hardware system (including servers, routers, and other devices) and run them side by side. Should the first traffic path fail, the second will instantly take over.
Besides stable Internet connection, many businesses have become heavily dependent on low network latency. This relates to user-generated content (UGD) streaming, online trading and gaming, video conferencing, and other interactive services where every millisecond of delay matters. For achieving the fastest response possible, you have to host servers as close to end users as possible which may lead to rebuilding the entire IT infrastructure.
The promising method for fixing latency issues in IoMT (Internet of Medical Things) and IoT systems is edge computing. It distributes some computing jobs across microservers, located near data sources (sensors and smart devices) instead of fully relying on remote centralized processors. On the dark side, the technology is still immature, entailing greater risks of failure.
There are a couple of other things to be checked when reviewing the IT infrastructure. The first one is security vulnerabilities, which are especially critical if you plan to store and process sensitive information. Also, consider the ability of the systems to interface with the equipment and software from third-party vendors.
Create several tech designs
Experts involved: a software or solution architect, tech leads, external consultants.
A rule of thumb for a feasibility study is to present several possible designs that roughly represent the system to be built. Each should give a holistic view of a solution and cover
- a high-level app architecture with major modules and interactions between them;
- data architecture, or how data will be gathered, processed, and stored;
- integrations with external data sources, services, and systems; and
- security mechanisms.
Each of the tech alternatives must be studied for all types of feasibility — economic, legal, operational, and scheduling.
Analyze tech risks and limitations
Experts involved: a software or solution architect, tech leads.
Besides feasibility aspects, analyze technical risks related to each option. They include but are not limited to
- third-party dependencies,
- early adoption of immature technologies,
- use of tools new to your team, and
- dealing with legacy systems.
Finally, you need to look into the technical limitations and pitfalls of proposed architectures. Namely, pay attention to
- performance constraints,
- implementation complexities,
- scalability concerns (will a system be able to handle a growing amount of work?),
- expendability concerns (will a system be able to support new functionality, interfaces, etc.?), and
- maintenance and support complexities.
Once all critical information is in place, all that is left to do is to decide on the best option.
Compare solutions and choose the best one
Experts involved: all the above-mentioned specialists.
To compare solutions and choose the optimal alternative, you may build a decision matrix.
Comparison of possible alternatives
According to the table above, Solution 1 may come with better performance but will cost twice as much as Solution 2. Besides, it poses maintenance challenges which entail hiring new experts or using external support services. And this makes Solution 1 less attractive in terms of operational feasibility. Note though that the decision matrix is given as an example, it’s not a strict guideline to follow.
Write a feasibility report
Experts involved: all of the above-mentioned specialists.
The logical outcome of the feasibility study is a document called a feasibility report. It can look different from company to company but typically contains the following sections.
Overview. Briefly explain the purpose of the project, its scope, and the problems it is expected to solve. Specify which aspects won't be covered and why.
Current situation description. Outline the current IT infrastructure and its problems. Describe the hardware, OS version, and characteristics of software to be replaced or integrated with a new tool.
Requirements. Include a brief summary of functional and non-functional requirements. You may attach or give a link to software requirements specification documents related to the project so that a reader could look through them without going any further.
Analysis of possible alternatives. Specify possible solutions to achieve a project’s goal including tools already existing in the market. Define major criteria to evaluate them — say, alignment with the desired objective, costs, legal fit, etc. Highlight the option that you recommend and give reasons for your choice. Make a point of benefits to be achieved when implementing the chosen alternative.
Risk analysis. List possible risks and constraints including legal ones related to the selected alternative (or alternatives) and suggest ways to eliminate them.
Requirements. Include a brief summary of functional and non-functional requirements. You may attach or give a link to software requirements specification documents related to the project so that a reader could look through them without going any further.
Recommendations. Summarize the key findings of your study and advise the course of action.
Feasibility testing and demonstration
Once the winning designs are determined and a feasibility report is written, you can further mitigate possible risks by testing the product hypothesis via
- proof of concept (POC),
- a prototype, and
- a minimum viable product or MVP.
While these terms are often mixed up and even used interchangeably, in fact, the processes behind them happen at different stages of product development and vary in objectives and resources involved.
Only the proof of concept directly relates to the technical feasibility assessment. But we’ll also eyeball the other two options as they are closely interconnected and pursue the same overall goal — testing before investing.
How proof of concept differs from a prototype and MVP
Build proof of concept to confirm tech feasibility
Experts involved: business analysts, UX/UI designers.
Proof of concept is a rough representation of a future product that is based on a feasibility study and targets internal stakeholders and investors. It’s the cheapest and fastest way to confirm that the selected solution will behave as expected in a particular environment. If not, you might opt for an alternative or just discard the idea.
There are no strict rules about what the POC must look like. It may come in the form of technical documentation, a presentation, a diagram, a wireframe (non-functional sketch of the future user interface), or their combination. In most cases, proof of concept doesn’t involve coding.
Doing a PoC is not mandatory, but is strongly recommended for the development of new products not currently available on the market. After proof of concept, you may move forward to the next testing method — prototyping.
Build a prototype to test an interface
Experts involved: business analysts, UX/UI designers, software developers.
A prototype is a low-cost, low-functionality, and low-engineering version of a future system. It turns proof of concept into a demo tool with a clickable design, visualizing a user flow. This way, you can show both investors and end customers how the product will look and feel. Feedback from live people will help you quickly identify and fix design flaws.
To dive deeper into the process, read our articles on prototyping and functional prototype.
Build an MVP to check market viability
Experts involved: project managers, software developers.
An MVP is a workable version of the system built on proof of concept, prototype, and software requirements specifications. It contains major features that solve user problems and is released to the market to collect feedback from a wider audience, measure results and, if necessary, make changes to the initial plan accordingly.
To learn more, read our dedicated article on a minimum viable product, its types, and building stages.
Ready, steady… launch! Or when technical feasibility matters most
How deep must feasibility research be to ensure that things will go right, with no nasty surprises at the development stage? The more innovative your project is, the more details your study should contain, period. TF analysis is especially critical when you get into
- new product development (NVP),
- adding new features, or
- fundamental redesign — say, you’re going to break your monolithic system into microservices.
Let’s put it another way. Are there cases when a feasibility assessment makes no sense? Definitely, yes, but you can count them on the fingers of one hand.
- You are pretty sure that your project is feasible.
- You ran a similar project or similar study in the past three years.
- Your project is small and quite simple, with minimal impact on long-term business goals.
In all other scenarios, a feasibility study is a must-have step allowing you to understand whether the software is worth investing in at all and how many alterations in the initial plan will cost you.
The popular Interstellar meme starring Matthew McConaughey gives us a clue why a feasibility study matters