Stop Building Software That Was Never Going to Work

Your dev team is excited. The product team has a vision. The CEO wants it yesterday. Everyone's ready to dive into code.

Stop.

Have you done a proper feasibility study? Or are you about to waste six months and a million dollars building something that was doomed from the start?

At 1985, we've seen too many projects fail not because of poor execution, but because no one asked the right questions before writing the first line of code. A feasibility study isn't bureaucratic overhead—it's your insurance policy against expensive mistakes.

Let's cut through the noise and explore what makes a feasibility study in software engineering not just necessary, but potentially the most valuable phase of your entire project lifecycle.

The Hard Truth About Software Projects

Software projects fail. A lot. The Standish Group's CHAOS report consistently shows that only about 30% of software projects are completed on time, on budget, and with all features as originally specified. Another 50% face significant challenges, and roughly 20% fail outright.

These aren't just statistics. They represent real companies, real budgets, and real careers. At 1985, we've been called in to rescue projects that were millions of dollars over budget simply because no one took the time to verify if what they wanted was actually achievable with their constraints.

A feasibility study is your first line of defense against becoming another statistic. It's the cold shower of reality before the excitement of development begins.

But here's the thing: most feasibility studies are done wrong. They're treated as a box-checking exercise rather than a critical investigation. They're rushed, superficial, or skewed toward a predetermined outcome. And that defeats their entire purpose.

What a Feasibility Study Actually Is (And Isn't)

A feasibility study in software engineering is a structured investigation that determines whether a proposed software project is technically possible, economically justifiable, and operationally viable within the organization's constraints.

It is not:

• A formality to please stakeholders
• A detailed project plan
• A guarantee of success
• A one-size-fits-all template

It is:

• A risk assessment tool
• A decision-making framework
• An opportunity to identify fatal flaws early
• A chance to explore alternatives before committing resources

The goal isn't to produce a thick document that gathers dust. It's to answer one question with brutal honesty: "Should we proceed with this project?"

Sometimes the most valuable outcome of a feasibility study is the decision not to move forward—saving millions in development costs for a product that would have failed anyway.

The Five Pillars of a Proper Feasibility Study

A comprehensive feasibility study examines a project from multiple angles. Each provides a different perspective on whether the project makes sense to pursue.

Technical Feasibility

This pillar answers the fundamental question: Can we actually build this?

At 1985, we've seen countless projects where clients come to us with ideas that sound simple but are technically complex or even impossible given current technology constraints. Technical feasibility isn't just about whether something can be built—it's about whether it can be built within your specific constraints.

Consider these critical questions:

• Does the required technology exist, or would it need to be developed?
• Does your team have the necessary technical expertise?
• Are there technical dependencies on third-party systems that might create bottlenecks?
• What are the performance requirements, and can they realistically be met?
• Are there security or compliance requirements that might create technical challenges?

A real-world example: A financial services client approached us wanting to build a mobile app that could process loan applications in under 3 seconds, including credit checks and fraud detection. Our technical feasibility study revealed that while the app itself could be built, the third-party credit check APIs they planned to use had response times averaging 4-7 seconds. This fundamental mismatch between expectations and technical reality would have doomed the project had we not identified it early.

Technical feasibility isn't just about saying "yes" or "no." It's about identifying technical risks and constraints that will shape the project's approach. Sometimes the answer is "yes, but..." which leads to valuable discussions about trade-offs and alternatives.

Economic Feasibility

Even if you can build it, should you? Economic feasibility examines whether the project makes financial sense.

This goes beyond simple ROI calculations. It requires honest assessment of:

• Development costs (including hidden costs like integration, testing, and deployment)
• Ongoing maintenance costs
• Opportunity costs of allocating resources to this project versus others
• Expected financial benefits (direct revenue, cost savings, productivity improvements)
• Time to break even

According to McKinsey, large IT projects run 45% over budget on average while delivering 56% less value than predicted. This happens because economic feasibility studies often rely on overly optimistic projections and incomplete cost analyses.

At 1985, we use a "truth-seeking" approach to economic feasibility. This means challenging assumptions, using historical data from similar projects, and building in contingency for the unknown. We've found that adding 30% to initial cost estimates and doubling expected timelines often produces more realistic projections.

A thorough economic feasibility study should include sensitivity analysis: How would the financial picture change if development takes 50% longer? What if user adoption is slower than expected? What if maintenance costs are higher?

Sometimes the most valuable outcome is identifying that a project doesn't make economic sense as initially conceived, but could be viable with a phased approach or reduced scope.

Operational Feasibility

A technically sound, economically viable project can still fail if it doesn't fit into your organization's operational reality.

Operational feasibility examines whether the proposed system will work within your organizational constraints and processes. It considers:

• User acceptance and training needs
• Changes to business processes required
• Organizational readiness for change
• Integration with existing workflows
• Support and maintenance requirements

According to a PwC study, 74% of IT projects that fail do so because of poor change management and user adoption issues—exactly the factors that operational feasibility aims to assess.

At 1985, we've seen brilliant technical solutions fail because they required users to dramatically change how they work without adequate support. We've also seen seemingly modest projects succeed wildly because they aligned perfectly with existing processes and pain points.

Operational feasibility requires honest assessment of your organization's culture, change readiness, and political realities. It's not just about whether the system can work—it's about whether it will work in your specific environment.

Schedule Feasibility

Can the project be completed in the required timeframe? Schedule feasibility examines timing constraints and dependencies.

This pillar is particularly important when:

• There are fixed deadlines (regulatory requirements, market windows, contractual obligations)
• The project depends on other initiatives or systems being completed
• Resources are only available during specific periods
• The business value depends on timing (seasonal business, competitive response)

Schedule feasibility requires honest assessment of development velocity, resource availability, and external dependencies. It should identify critical path items and potential bottlenecks.

A common mistake is creating schedules based on best-case scenarios rather than realistic projections. At 1985, we use historical velocity data and apply buffer factors based on project complexity to create schedules that teams can actually meet.

Legal Feasibility

Often overlooked but increasingly critical, legal feasibility examines whether the proposed system complies with relevant laws, regulations, and contractual obligations.

This includes:

• Data privacy regulations (GDPR, CCPA, HIPAA, etc.)
• Industry-specific regulations
• Intellectual property considerations
• Contractual obligations with partners, customers, or vendors
• Export control regulations
• Accessibility requirements

The cost of getting this wrong can be enormous. GDPR violations can result in fines up to 4% of global revenue. A single ADA lawsuit for an inaccessible website can cost hundreds of thousands in legal fees and damages.

Legal feasibility isn't just about avoiding problems—it's about identifying requirements that will shape the project's approach. For example, if your system needs to comply with HIPAA, that will influence architecture, security measures, and documentation requirements.

The Feasibility Study Process

Now that we understand the pillars, let's explore how to actually conduct a feasibility study that delivers value rather than just checking boxes.

Step 1: Define the Scope and Objectives

Before diving into analysis, clearly define what you're evaluating and why. This includes:

• The problem the proposed system aims to solve
• The high-level requirements and constraints
• The key stakeholders and their expectations
• The specific questions the feasibility study should answer

This step is crucial because it sets the boundaries of your investigation. Without clear scope, feasibility studies can become never-ending explorations or miss critical aspects entirely.

Document this in a brief (1-2 page) charter that stakeholders can review and approve before proceeding.

Step 2: Gather Information

With scope defined, collect the information needed to assess feasibility across all pillars. This typically includes:

• Interviews with stakeholders and potential users
• Analysis of existing systems and processes
• Market research and competitive analysis
• Technical research on potential solutions
• Financial data for cost-benefit analysis
• Legal and regulatory requirements

The quality of your feasibility study depends directly on the quality of information gathered. Don't rely solely on documentation—speak directly with the people who understand the current reality and future needs.

At 1985, we use a structured information gathering approach that includes:

• Stakeholder workshops to capture requirements and constraints
• Technical discovery sessions with architects and engineers
• Process mapping with current users
• Financial modeling with business stakeholders
• Legal and compliance reviews

Step 3: Analyze Alternatives

A common mistake in feasibility studies is evaluating only one approach. Instead, identify multiple potential solutions and assess each against the five pillars.

For example, if you're considering a custom CRM system, your alternatives might include:

• Building a custom solution from scratch
• Customizing an open-source platform
• Implementing a commercial off-the-shelf solution
• Outsourcing development to a specialized vendor
• Taking a hybrid approach

For each alternative, assess:

• Technical feasibility and risks
• Economic costs and benefits
• Operational impacts and requirements
• Schedule implications
• Legal and compliance considerations

This comparative approach often reveals that the initially preferred solution isn't actually the most feasible when all factors are considered.

Step 4: Document Findings and Recommendations

The output of your feasibility study should be a clear, concise document that:

• Summarizes the alternatives considered
• Presents the findings for each pillar of feasibility
• Identifies key risks and constraints
• Makes a clear recommendation (proceed, modify, or abandon)
• Outlines next steps if proceeding

Avoid the common trap of producing a massive document that no one will read. Focus on communicating the critical insights and decision points. Use visualizations where appropriate to make complex trade-offs clear.

The most effective feasibility study reports we've seen at 1985 include:

• An executive summary with clear recommendations
• A comparison matrix of alternatives
• Visual risk assessments
• High-level implementation roadmaps for recommended approaches

Step 5: Make the Go/No-Go Decision

The ultimate purpose of a feasibility study is to inform a decision. Based on the findings, stakeholders should decide whether to:

• Proceed with the project as conceived
• Modify the approach to address identified issues
• Abandon the project and explore alternatives
• Defer the decision pending additional information

This decision should be explicit, documented, and communicated to all stakeholders. If the decision is to proceed, the feasibility study becomes a foundation for project planning.

Common Pitfalls and How to Avoid Them

After conducting hundreds of feasibility studies at 1985, we've identified patterns in what goes wrong. Here are the most common pitfalls and how to avoid them:

Confirmation Bias

The Pitfall: Conducting the study to confirm a decision that's already been made rather than to objectively assess feasibility.

The Solution: Assign someone to play devil's advocate. Explicitly reward the identification of potential problems rather than punishing the bearer of bad news.

Scope Creep

The Pitfall: Allowing the scope of the proposed system to expand during the feasibility study, making accurate assessment impossible.

The Solution: Freeze requirements during the study period. Document new ideas for consideration in a separate phase.

Overoptimism

The Pitfall: Underestimating costs, risks, and challenges while overestimating benefits and team capabilities.

The Solution: Use historical data from similar projects. Apply appropriate contingency factors. Seek external validation of critical assumptions.

Insufficient Stakeholder Involvement

The Pitfall: Conducting the study in isolation without input from key stakeholders, leading to missed requirements or constraints.

The Solution: Identify and involve representatives from all stakeholder groups. Use structured workshops to gather diverse perspectives.

Analysis Paralysis

The Pitfall: Getting stuck in endless research and analysis without reaching conclusions.

The Solution: Set a timeframe for the study appropriate to the project's size and complexity. Focus on answering the critical questions rather than achieving perfect certainty.

Real-World Case Studies

Case Study 1: The Custom ERP That Wasn't Needed

A manufacturing client approached 1985 wanting to build a custom ERP system. Their existing system was "outdated" and "inflexible," and they believed a custom solution would provide competitive advantage.

Our feasibility study revealed:

• Technical Feasibility: High, but with significant complexity
• Economic Feasibility: Questionable, with development costs estimated at $2.5M and ongoing maintenance at $400K annually
• Operational Feasibility: Challenging, requiring extensive process changes and training
• Schedule Feasibility: 18-24 months for full implementation
• Legal Feasibility: No significant issues

However, during our alternatives analysis, we discovered that:

1. Most of their pain points could be addressed through better configuration of their existing system
2. The remaining gaps could be filled with targeted micro-applications integrated with their current ERP
3. This approach would cost approximately $600K and take 6 months

The client chose the alternative approach, saving nearly $2M in development costs and achieving their business objectives 18 months sooner than the custom approach would have allowed.

Case Study 2: The Regulatory Compliance System That Couldn't Wait

A financial services firm needed a new compliance monitoring system to meet upcoming regulations. The deadline was fixed by law, creating significant schedule constraints.

Our feasibility study assessed three alternatives:

1. Building a custom solution
2. Implementing a commercial compliance platform
3. Outsourcing compliance monitoring to a specialized service provider

The findings:

• Technical Feasibility: All approaches technically feasible
• Economic Feasibility: Custom solution most expensive initially but lowest TCO after 5 years
• Operational Feasibility: Commercial platform required least operational change
• Schedule Feasibility: Only the outsourced approach could meet the regulatory deadline
• Legal Feasibility: All approaches could satisfy regulatory requirements

Despite the long-term economic advantage of a custom solution, the schedule constraint was non-negotiable. The client chose the outsourced approach to meet the immediate regulatory requirement while simultaneously beginning development of a custom solution for long-term use.

This hybrid approach, identified through the feasibility study, allowed them to meet their legal obligations while still pursuing the most economically advantageous solution for the long term.

When to Conduct a Feasibility Study

Not every software project requires a full-scale feasibility study. Here's when you should definitely conduct one:

1. For large-scale systems with significant investment (typically >$500K)
2. When entering unfamiliar technical territory
3. When the project has strict constraints (regulatory, schedule, budget)
4. When the project impacts critical business processes
5. When multiple approaches could potentially meet the need

For smaller projects or enhancements to existing systems, a streamlined feasibility assessment might be sufficient. This could be as simple as a structured discussion addressing each pillar with key stakeholders.

The ROI of Feasibility Studies

Some organizations resist feasibility studies, seeing them as delays to "real work." But the return on investment is compelling:

• A typical feasibility study costs 1-3% of the total project budget
• According to our data at 1985, projects that conduct proper feasibility studies are 40% more likely to meet their objectives
• Identifying a non-viable project early can save 100% of what would have been wasted development costs

Consider a $1M software project. A $20K feasibility study that identifies a fatal flaw provides a 50x return on investment by preventing wasted development effort. Even if the project proceeds, the insights gained typically lead to more efficient execution, easily recouping the study cost.

Feasibility as a Competitive Advantage

In the rush to deliver software faster, many organizations skip or shortchange the feasibility study phase. This creates an opportunity for those who do it right.

At 1985, we've seen clients gain significant competitive advantage by taking the time to thoroughly assess feasibility before committing resources. They:

• Avoid expensive failures
• Identify more efficient approaches
• Align stakeholders around realistic expectations
• Make better resource allocation decisions

A feasibility study isn't just a risk management tool—it's a strategic advantage in a world where software development resources are scarce and expensive.

The next time you're tempted to skip straight to development, remember: the most expensive code is the code you write for a project that was never feasible in the first place.

This post was written by the team at 1985, an outsourced software development company specializing in helping organizations make smart technology decisions. We believe in doing the right work, not just doing the work right.