Feasibility Assessment¶
At a glance
- Purpose: Decide whether a project can be done — technically, operationally, financially, legally, and in the time available — before committing to it.
- Use it when: Between the business case and the charter, and again if a major constraint changes. Feasibility answers "can we?", not "should we?" and not "will we?".
- Owner: The project manager or a small assessment team, with each dimension owned by the person who can judge it.
- Related: Module 02 · Lab 04
How to use this template¶
- Assess five dimensions separately. A project is often feasible on four and blocked on the fifth, and it is the blocked one that decides.
- For each dimension, state the verdict (feasible / feasible with conditions / not feasible) and the evidence — not an opinion.
- Name the condition that would change a verdict. Feasibility assessments that say "yes" or "no" without naming the condition cannot be acted on.
- Identify the single binding constraint — the one that governs the others — and test it first.
- Record what you would have to not do to make an infeasible dimension feasible. That is usually a scope trade, and it belongs in the recommendation.
- Keep it short. A feasibility assessment is a decision aid, not a research report.
Field descriptions¶
| Dimension | What it asks | Evidence to look for |
|---|---|---|
| Technical | Can it be built with available technology and skills? | A prototype, a spike, a vendor's documented capability, a named person who has done it |
| Operational | Will the organisation be able to run it and change its processes? | Staff availability, training needs, process ownership, support model |
| Financial | Is the money available, and is the case positive? | Budget authority, lifetime cost, funding source for operations |
| Legal and regulatory | Is it permissible, and what obligations attach? | The current version of the applicable rule, confirmed with the responsible office |
| Schedule | Can it be delivered in the time available? | Capacity arithmetic, external lead times, dependency on others' queues |
| Binding constraint | Which of the above governs the rest? | The one where relaxing it changes every other verdict |
Blank template¶
# Feasibility Assessment — [Project name]
| | |
| --- | --- |
| **Assessed by** | [Names and roles] |
| **Date** | [YYYY-MM-DD] |
| **Recommendation** | [Proceed / Proceed with conditions / Do not proceed / Return for re-scoping] |
## 1. Technical feasibility
| | |
| --- | --- |
| **Verdict** | [Feasible / Feasible with conditions / Not feasible] |
| **Evidence** | [Prototype result, prior project, vendor documentation, named expertise] |
| **Condition that would change this** | [Specific and observable] |
| **Unknowns** | [What you could not determine, and how you would determine it] |
## 2. Operational feasibility
[Same four fields. Address who will run it, how their process changes, and whether they have
agreed to it.]
## 3. Financial feasibility
[Same four fields. Cover total cost of ownership, not only build cost, and name the budget
holder who has confirmed availability.]
## 4. Legal and regulatory feasibility
[Same four fields. State which specific requirement applies and who confirmed its current
version. Do not state a legal position you have not verified.]
## 5. Schedule feasibility
[Same four fields. Include the capacity arithmetic and any external lead time or queue.]
## 6. The binding constraint
[Which dimension governs the others, and why. What would have to change for the project to
become feasible, and what would that change cost?]
## 7. Recommendation
[Proceed / proceed with conditions / return for re-scoping / do not proceed — with the
conditions listed. If the answer depends on a scope reduction, say which scope.]
## 8. Conditions to be met before the charter is signed
| # | Condition | Owner | Due |
| --- | --- | --- | --- |
| 1 | [Condition] | [Role] | [YYYY-MM-DD] |
Worked example¶
A partial assessment of the campus event portal from Lab 01, with assumptions invented for teaching:
| Dimension | Verdict | Evidence | Condition |
|---|---|---|---|
| Technical | Feasible | Standard web application; single sign-on already used elsewhere | Reuse the existing authentication library rather than build one |
| Operational | Feasible with conditions | IT office has agreed to host; moderation process not yet agreed | Staff moderation workflow agreed before launch |
| Financial | Feasible | Within the director's delegated budget | None |
| Legal | Feasible with conditions | Event listings and images involve publishing rights | Confirm image-consent approach with the records office |
| Schedule | Feasible with conditions | One developer at one day per week against roughly 20 person-days | Security review booked in week 1, not week 8 |
The binding constraint is schedule, because it is the dimension that would force the others to change: a shorter runway would remove the moderation workflow and the image-consent step from the release, and technical feasibility depends on the security review having time.
Common mistakes¶
- Assessing only the technical dimension. Most failures are operational, financial, or legal, and technical feasibility is the easiest to confirm.
- Verdicts with no evidence. "The team can build it" is not evidence; a prototype or a named experience is.
- Stating legal conclusions you have not verified. Say which office confirmed the requirement, and when.
- Treating feasibility as permanent. It changes when technology, budget, regulation, or capacity changes — reassess if a major constraint moves.
- Answering "should we?" That is the business case. Feasibility is only about whether it can be done.
- No conditions. An unconditional "feasible" gives the project no protection when the condition fails.