Worked example library

Feasibility Report Examples: Criteria, Evidence & Decisions

Start with the worked examples to see complete reasoning, then use the shorter pattern library for variation. Level guidance and frameworks show how the same task changes as the evidence, audience, or assignment becomes more demanding.

Guide Examples 8 Templates

Before you copy

What to notice in the examples

A strong feasibility report makes the decision test explicit, compares the proposal against realistic criteria and alternatives, distinguishes evidence from assumptions, shows material risks and dependencies, and reaches a conditional or negative conclusion when the evidence does not justify proceeding.

Define the proposal and the exact feasibility question before researching solutions.
Choose criteria that actually determine viability in the situation and explain how each criterion will be evaluated.
Include the status quo or do-nothing option when it is a real alternative.
Use comparable evidence across options and surface assumptions, dependencies, uncertainty, and missing data.
Conclude with proceed, do not proceed, or proceed under stated conditions rather than treating every study as a sales document.

Worked format lab

See complete reasoning, not just isolated lines

Use these fuller examples to see what changes between a recognizable pattern and a finished piece of writing. The examples are original or explicitly illustrative, so they demonstrate structure without inventing real-world evidence.

Worked example 1Abridged feasibility report

Illustrative internal knowledge-base project.

Question: Is a six-week pilot of structured support handoffs feasible for two teams?

Criteria
Technical: can the existing ticket system capture three required fields without custom development?
Operational: can agents complete the fields without materially extending handoff time?
Schedule: can configuration, training, and measurement begin within two weeks?
Measurement: can clarification messages and response delay be compared with the current process?

Findings
The existing system supports required fields through configuration. Operations estimates a training requirement of one 30-minute session per team. Historical data provide a baseline for clarification messages, but response-delay measurement requires one new dashboard field. No legal or customer-facing process change is planned in the pilot.

Conclusion
The pilot is feasible within six weeks if the dashboard field is available before measurement begins. Proceed conditionally; if that dependency slips by more than one week, move the pilot start rather than shorten the measurement period.

Why it works: The report uses explicit criteria and a conditional recommendation instead of treating feasibility as a vague yes/no opinion.

Worked example 2Preferred solution → neutral feasibility question

Illustrative rewrite.

Weak: This report proves that the new platform is the best way to modernize support.

Stronger: This report evaluates whether replacing the current support platform is feasible within the organization’s 12-month migration window, staffing capacity, security requirements, and recurring-cost ceiling. It compares replacement with targeted process changes and the current platform so the recommendation does not assume migration is necessary.

Why it works: The revision separates the decision problem from the preferred solution and creates comparable criteria.

Prompt → finished structure

See the decisions between the assignment and the final form

These transformations make the hidden planning step visible so the template does not become a fill-in-the-blanks substitute for judgment.

Transformation 1Idea → feasibility study

Starting material: Starting material is a preferred project idea and a target launch month.

Decisions
Convert the idea into a feasibility question, define binding criteria before collecting evidence, include status quo and realistic alternatives, label estimates, and identify what result would make the project not feasible.

Result: Finished structure: question → criteria → evidence/alternatives → constraints → sensitivity → go/no-go/conditional recommendation.

Transformation 2Optimistic forecast → conditional result

Starting material: Draft assumes adoption, cost, and delivery all meet best-case estimates.

Decisions
Replace point estimates with evidence-backed ranges where possible, identify the dependency that controls schedule, and state the conditions that must hold for the positive conclusion.

Result: Finished structure: feasible only if [conditions], with a next validation step and stop condition.

Depth by level

Increase the reasoning, not just the word count

Level	What changes	Quality test
Preliminary feasibility	Test the biggest potential deal-breakers with a small number of explicit criteria and label estimates clearly.	The report should identify what must be learned before a larger commitment.
Formal feasibility study	Compare alternatives consistently across technical, operational, financial, schedule, and other relevant criteria with assumptions and risk visible.	The conclusion must follow the criteria even when the preferred idea performs poorly.
Investment / high-stakes feasibility	Add sensitivity analysis, independent evidence, specialist review, implementation dependencies, and explicit stop conditions.	Irreversible decisions require stronger evidence than a classroom or exploratory report.

Reusable frameworks

Start from the decisions the format requires

Framework 1

Observation → function
1. What can the viewpoint actually perceive?
2. Which 1–2 details matter now?
3. What do those details change in image, pace, relationship, or action?
4. What interpretation remains uncertain?

Framework 2

Generic → specific revision
Generic line: [x]
Observable evidence: [x]
Context/constraint: [x]
Unnecessary inference removed: [x]
Revised line: [x]

Software migration feasibility: compare platform capability, data migration complexity, security requirements, staff capacity, recurring cost, and cutover timing before recommending a pilot.

New service feasibility: test demand evidence, staffing, operating process, budget range, capacity, and regulatory review needed rather than relying on stakeholder enthusiasm.

Facility change: compare renovation, relocation, and status quo using capacity, schedule, disruption, cost range, and accessibility requirements.

Automation proposal: distinguish tasks technically automatable from tasks that still require judgment, quantify implementation effort as an estimate, and make review/exception handling part of operational feasibility.

Course project feasibility: define available time, data access, equipment, participant access, and method constraints before choosing a research plan that cannot be completed.

Vendor feasibility: separate vendor-claimed capability from capabilities demonstrated in the organization’s test environment and document unresolved integration dependencies.

Conditional result: recommend proceeding only if a six-week pilot reaches the agreed adoption and error thresholds; otherwise retain the existing process.

Negative result: conclude that the proposed launch window is not feasible because a mandatory dependency cannot be completed before the deadline, while identifying a later feasible window.

Turn an example into your own writing

Keep the underlying decision or pattern, then replace the subject, evidence, relationship, constraints, and tone with details that belong to your situation. If your final line still works after swapping only one noun, it may be too close to the example.

What to notice in the examples

See complete reasoning, not just isolated lines

See the decisions between the assignment and the final form

Increase the reasoning, not just the word count

Start from the decisions the format requires

Related writing guides