# Feasibility Study: [Project or initiative name]

> Full feasibility study that tests whether a proposed project can and
> should go ahead, assessed across the five TELOS dimensions: technical,
> economic, legal, operational and scheduling. It compares alternatives,
> scores each dimension against stated criteria, estimates costs, analyses
> risk and sensitivity, and ends with a clear go, conditional go or no-go
> recommendation. Replace every `[bracketed]` value and every row marked
> *Example*. Figures are illustrative; this is a format, not financial or
> legal advice.

<!--
Guidance: How to use this template
- Agree the assessment criteria and weights (section 4.1) with the
  sponsor before scoring. Changing weights after scoring looks like
  steering the answer.
- Assess every alternative on every TELOS dimension, including the
  "do nothing" option, so the comparison is fair.
- A feasibility study may legitimately conclude "no-go". Write the
  evidence first and the conclusion last.
- Record sources for every estimate so a reviewer can re-check them.
-->

## Document control

<!-- Guidance: Identify the sponsor who commissioned the study and who will act on its recommendation. -->

| Field | Value |
|---|---|
| Document ID | [FS-YYYY-001] |
| Project | [Project name] |
| Version | [0.1] |
| Status | [Draft / In review / Final] |
| Sponsor | [@sponsor] |
| Study lead | [@author] |
| Contributors | [@finance], [@legal], [@it-architect], [@operations] |
| Study period | YYYY-MM-DD to YYYY-MM-DD |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Sponsor | [@name] | [Accepted / Further work required] | YYYY-MM-DD |
| Finance | [@name] | [Cost estimates validated] | YYYY-MM-DD |
| Legal and compliance | [@name] | [Legal assessment reviewed] | YYYY-MM-DD |
| Portfolio board | [@name] | [Go / Conditional go / No-go] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes in scope, alternatives or conclusions. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Background, objectives and alternatives drafted |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* TELOS scoring and cost estimates added |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Final, recommendation accepted by sponsor |

## Contents

<!-- Guidance: Keep the list aligned with the headings below. -->

1. [Executive summary](#1-executive-summary)
2. [Background](#2-background)
3. [Objectives and scope](#3-objectives-and-scope)
4. [Alternatives and assessment method](#4-alternatives-and-assessment-method)
5. [Technical feasibility](#5-technical-feasibility)
6. [Economic feasibility](#6-economic-feasibility)
7. [Legal feasibility](#7-legal-feasibility)
8. [Operational feasibility](#8-operational-feasibility)
9. [Schedule feasibility](#9-schedule-feasibility)
10. [Cost estimates](#10-cost-estimates)
11. [Risk analysis](#11-risk-analysis)
12. [Sensitivity analysis](#12-sensitivity-analysis)
13. [Conclusion and recommendation](#13-conclusion-and-recommendation)
14. [Appendices](#14-appendices)

## 1. Executive summary

<!-- Guidance: Half a page: the question, the alternatives, the overall scores, the recommendation and any conditions. Write it last. -->

This study assessed whether [organisation] should [proposed action].
[N] alternatives were evaluated across the TELOS dimensions. The
highest-scoring alternative is [alternative], with a weighted score of
[N.N] out of 5. The study recommends **[Go / Conditional go / No-go]**.

| Alternative | Weighted score | Estimated cost | Feasible? |
|---|---|---|---|
| *Example:* A1 Do nothing | 2.15 | 0 capital, rising run cost | No |
| *Example:* A2 Upgrade existing warehouse system | 3.15 | 420,000 | Yes, with conditions |
| *Example:* A3 Cloud warehouse management system | 4.1 | 610,000 | Yes |

## 2. Background

<!-- Guidance: What triggered the study? Describe the current situation, the problem and any earlier attempts. -->

[Describe the current situation, the business problem, the trigger for
the study (growth, regulation, failure, opportunity), and any previous
studies or decisions.]

*Example:* "Order volume at the Northern distribution centre grew 46% in
two years. The current warehouse system is a 2012 on-premises product
that cannot support wave picking or carrier integration, and peak-season
backlogs reached 3.5 days in December."

## 3. Objectives and scope

<!-- Guidance: State what the study must answer, not what the project must deliver. Keep the scope boundary explicit. -->

### 3.1 Study objectives

1. Determine whether [solution type] is technically achievable with
   [constraints].
2. Estimate whole-life costs and benefits for each alternative.
3. Identify legal, regulatory and contractual obstacles.
4. Assess operational readiness and the impact on staff and processes.
5. Establish whether delivery by [target date] is realistic.

### 3.2 Scope

- **In scope**: [sites, processes, systems, user groups]
- **Out of scope**: [areas not assessed, with reasons]
- **Constraints**: [budget ceiling, deadlines, mandated technologies]
- **Assumptions**: [for example, current headcount stays flat]

### 3.3 Decision criteria for the study outcome

The study outcome is decided by explicit thresholds agreed with the
sponsor before any scoring starts. Writing them down early prevents the
thresholds from drifting to fit a favoured answer.

| Outcome | Threshold |
|---|---|
| Go | Weighted score of 3.5 or more, no dimension scored below 3, positive NPV in the base case |
| Conditional go | Weighted score of 3.0 or more, any dimension at 2 has a credible mitigation with an owner and a date |
| No-go | Weighted score below 3.0, any dimension scored 1, or negative NPV in the base case |

### 3.4 Stakeholders consulted

| Stakeholder | Interest | Method | Date |
|---|---|---|---|
| *Example:* Distribution centre manager | Throughput and staffing | Interview and site walk | YYYY-MM-DD |
| *Example:* Finance business partner | Capital budget and payback | Workshop | YYYY-MM-DD |
| *Example:* Picking team leads (6) | Day-to-day usability | Focus group with handheld demo | YYYY-MM-DD |
| [Stakeholder] | [Interest] | [Method] | [Date] |

## 4. Alternatives and assessment method

<!-- Guidance: Describe each alternative in enough detail that it can be scored. Then define criteria, weights and the scoring scale. -->

### 4.1 Alternatives considered

| ID | Alternative | Description |
|---|---|---|
| A1 | Do nothing | Continue with current system and manual workarounds |
| A2 | [Alternative] | [Description] |
| A3 | [Alternative] | [Description] |

### 4.2 Criteria, weights and scale

Each criterion is scored from 1 (not feasible) to 5 (fully feasible
with low risk). The weighted score for alternative $a$ is:

$$
S_a = \sum_{d} w_d \cdot s_{a,d}, \qquad \sum_d w_d = 1
$$

| Dimension | Weight $w_d$ | Key criteria |
|---|---|---|
| Technical | 0.25 | Fit with architecture, maturity, integration effort, skills |
| Economic | 0.30 | NPV, payback, affordability |
| Legal | 0.15 | Regulatory compliance, contracts, data protection, licensing |
| Operational | 0.20 | Process fit, user acceptance, support model |
| Scheduling | 0.10 | Ability to meet the deadline, critical path risk |

### 4.3 Scoring summary

| Dimension | Weight | A1 | A2 | A3 |
|---|---|---|---|---|
| Technical | 0.25 | 2 | 3 | 4 |
| Economic | 0.30 | 2 | 3 | 4 |
| Legal | 0.15 | 3 | 4 | 4 |
| Operational | 0.20 | 2 | 3 | 4 |
| Scheduling | 0.10 | 2 | 3 | 5 |
| **Weighted score** | 1.00 | **2.15** | **3.15** | **4.10** |

### 4.4 Evidence and data sources

Scores must rest on evidence rather than opinion. For each dimension,
record what was examined and how reliable it is, so that a reviewer can
see which scores are firm and which are judgement calls.

| Evidence | Used for | Reliability |
|---|---|---|
| *Example:* Six weeks of warehouse transaction logs | Throughput baseline, benefit estimates | High |
| *Example:* Two vendor demonstrations and three reference calls | Technical and operational scores | Medium |
| *Example:* Internal legal memo on data transfers | Legal score | Medium, pending external review |
| [Evidence] | [Dimension or estimate] | [High / Medium / Low] |

## 5. Technical feasibility

<!-- Guidance: Can it be built or bought, integrated and run with the technology and skills available? Name evidence: proofs of concept, vendor references, architecture reviews. -->

| Criterion | A2 finding | A3 finding | Score A2 | Score A3 |
|---|---|---|---|---|
| *Example:* Integration with ERP | Custom interface required, 3 months | Standard connector available | 3 | 4 |
| *Example:* Scalability to 2x peak | Requires new hardware | Elastic capacity | 2 | 5 |
| *Example:* Internal skills | Existing team familiar | Training needed, 6 weeks | 4 | 3 |
| [Criterion] | [Finding] | [Finding] | [1-5] | [1-5] |

[Summarise technical risks and any proof-of-concept results.]

## 6. Economic feasibility

<!-- Guidance: Compare costs and benefits for each alternative over the same period and discount rate. Show the formula and inputs. -->

Net present value over $T$ years at discount rate $r$:

$$
NPV = \sum_{t=1}^{T} \frac{B_t - C_t}{(1+r)^t} - C_0
$$

| Measure | A1 | A2 | A3 |
|---|---|---|---|
| Initial cost $C_0$ | [amount] | [amount] | [amount] |
| Annual benefits $B_t$ | [amount] | [amount] | [amount] |
| Annual running costs $C_t$ | [amount] | [amount] | [amount] |
| NPV at [r%] over [T] years | [amount] | [amount] | [amount] |
| Payback period | [n/a] | [N years] | [N years] |

[Explain the main benefit drivers, such as labour hours saved,
throughput gains or avoided penalties, and their sources.]

## 7. Legal feasibility

<!-- Guidance: Identify laws, regulations, contracts and licences that permit, restrict or block each alternative. This is an issue list for counsel, not legal advice. -->

| Area | Requirement or issue | Impact on alternatives | Action |
|---|---|---|---|
| *Example:* Data protection | Customer addresses processed by a cloud vendor | A3 needs a data processing agreement and transfer assessment | Legal review by YYYY-MM-DD |
| *Example:* Existing contract | Current vendor contract has 12-month notice | A3 cannot go live before notice period ends | Serve notice by YYYY-MM-DD |
| *Example:* Health and safety | New picking layout changes walkways | All alternatives need a site risk assessment | H&S officer sign-off |
| [Area] | [Issue] | [Impact] | [Action] |

## 8. Operational feasibility

<!-- Guidance: Will it work in practice? Consider processes, people, culture, support and service continuity during change. -->

| Criterion | Finding | Score A2 | Score A3 |
|---|---|---|---|
| *Example:* Process fit | A3 supports wave picking natively; A2 needs workarounds | 3 | 4 |
| *Example:* User acceptance | Pilot users rated A3 handheld flow 4.3 of 5 | 3 | 4 |
| *Example:* Support model | A3 vendor provides 24x7 support; A2 relies on two staff | 2 | 4 |
| [Criterion] | [Finding] | [1-5] | [1-5] |

[Describe stakeholder views, training needs, and how operations
continue during transition.]

## 9. Schedule feasibility

<!-- Guidance: Can it be delivered by the required date? Show the critical path and the buffer. -->

| Milestone | A2 date | A3 date | Constraint |
|---|---|---|---|
| *Example:* Contract signed | YYYY-MM-DD | YYYY-MM-DD | Procurement takes 8 weeks |
| *Example:* Go-live before peak freeze | YYYY-MM-DD | YYYY-MM-DD | Freeze starts 1 October |
| [Milestone] | [Date] | [Date] | [Constraint] |

The indicative schedule for the leading alternative is shown below.

```mermaid
gantt
  title Indicative schedule for A3
  dateFormat YYYY-MM-DD
  section Procure
  Vendor selection     :a1, 2026-01-05, 8w
  section Implement
  Configuration        :a2, after a1, 10w
  Integration and test :a3, after a2, 6w
  section Go-live
  Pilot zone           :a4, after a3, 3w
  Full site            :a5, after a4, 2w
```

## 10. Cost estimates

<!-- Guidance: Break costs into one-off and recurring, state the estimating basis and the accuracy range (for example -15% to +30%). -->

| Cost item | Type | A2 | A3 | Basis of estimate |
|---|---|---|---|---|
| *Example:* Software licences | Recurring | 45,000 | 120,000 | Vendor quotes, YYYY-MM |
| *Example:* Implementation services | One-off | 180,000 | 260,000 | Fixed-price proposals |
| *Example:* Hardware and devices | One-off | 140,000 | 90,000 | Catalogue prices |
| *Example:* Internal staff time | One-off | 95,000 | 110,000 | 1.2 FTE for 9 months |
| *Example:* Contingency (15%) | One-off | 62,000 | 70,000 | Policy rate |
| **Total one-off** | | [total] | [total] | |
| **Total recurring per year** | | [total] | [total] | |

Estimate accuracy: [range, for example -15% to +30%], based on
[estimating class or method].

## 11. Risk analysis

<!-- Guidance: List the risks that could make each alternative infeasible. Score with the same scale across alternatives. -->

| ID | Risk | Alternative | Likelihood (1-5) | Impact (1-5) | Score | Mitigation | Owner |
|---|---|---|---|---|---|---|---|
| FR-01 | *Example:* Vendor cannot meet go-live before peak freeze | A3 | 3 | 5 | 15 | Contractual milestone with penalty; pilot by August | @pm |
| FR-02 | *Example:* Legacy hardware fails during upgrade | A2 | 3 | 4 | 12 | Spare server, rollback plan | @it-ops |
| FR-03 | [Risk] | [Alt] | [1-5] | [1-5] | [L x I] | [Mitigation] | [@owner] |

## 12. Sensitivity analysis

<!-- Guidance: Show which assumptions could change the recommendation. Vary one input at a time and record the result. -->

| Variable | Base case | Low case | High case | NPV A3 low | NPV A3 high | Changes ranking? |
|---|---|---|---|---|---|---|
| *Example:* Labour savings | 8 FTE | 5 FTE | 10 FTE | 140,000 | 720,000 | No |
| *Example:* Licence price increase | 0% | 0% | 25% | 410,000 | 290,000 | No |
| *Example:* Go-live delay | 0 months | 0 | 6 months | 410,000 | 180,000 | Yes, A2 leads if delay over 9 months |
| [Variable] | [Base] | [Low] | [High] | [NPV] | [NPV] | [Yes / No] |

Re-weighting check: [state whether the ranking holds when each TELOS
weight is moved by plus or minus 0.10].

## 13. Conclusion and recommendation

<!-- Guidance: State the verdict for each dimension, the overall recommendation, conditions and the next decision point. -->

| Dimension | Verdict for preferred alternative |
|---|---|
| Technical | [Feasible / Feasible with conditions / Not feasible] |
| Economic | [Verdict] |
| Legal | [Verdict] |
| Operational | [Verdict] |
| Scheduling | [Verdict] |

**Recommendation:** [Go / Conditional go / No-go] for [alternative].

[Explain in two or three paragraphs why the evidence supports this
verdict, which dimension carries the most uncertainty, and what would
have to change for the recommendation to reverse. Refer back to the
switching points found in section 12 and the highest-scoring risks in
section 11. If the verdict is no-go, state whether a smaller scope, a
later date or a different alternative deserves a fresh study.]

- **Conditions**: [for example, data processing agreement signed before contract award]
- **Next step**: [for example, prepare full business case by YYYY-MM-DD]
- **Decision needed from**: [forum and date]

## 14. Appendices

<!-- Guidance: Attach evidence that supports scores and estimates. -->

- Appendix A: Detailed scoring worksheets [link]
- Appendix B: Vendor quotations and references [link]
- Appendix C: Proof-of-concept report [link]
- Appendix D: Interview and workshop notes [link]

## Standard and licence note

Based on the widely taught TELOS feasibility framework (technical,
economic, legal, operational and scheduling) and common project
appraisal practice. This template is original text written for this
collection and reproduces no text from any textbook or standard. This is
a document format, not financial or legal advice. Template licence: MIT.