Feasibility & Cost-Benefit Analysis

The Feasibility Report & Recommendation

18 min Lesson 9 of 10

The Feasibility Report & Recommendation

After weeks of interviews, spreadsheet modelling, risk workshops, and technical spikes, the analyst has accumulated a mountain of findings. The feasibility study is only complete when those findings are assembled into a single, coherent decision document that management can actually act on. That document is the feasibility report — the culminating deliverable of the entire feasibility process.

In this lesson we look at how to structure the report, what each section must contain, how to frame the recommendation clearly, and how to present findings to a mixed audience of executives, technical leads, and operations managers — illustrated through a running example of HealthLink, a 120-seat private clinic group that has spent eight weeks studying whether to build a custom patient booking and EHR integration system.

Core purpose of the report: The feasibility report does not merely summarise findings — it translates analytical evidence into a defensible recommendation that tells decision-makers exactly what to do next and why. Without that recommendation, all the preceding analysis has no clear landing point.

Why the Report Format Matters

Feasibility findings are consumed by at least three very different audiences at once. The executive sponsor wants a one-page verdict with headline numbers and the key rationale. The technical lead needs enough technical depth to validate assumptions. The operations manager needs to understand what will change for staff. A well-structured report uses a layered architecture: an executive summary up front for leadership, detailed appendices at the back for specialists, and the body serving the middle audience.

Poorly structured reports — those that bury the recommendation on page 18, or that present raw data without synthesising it into conclusions — routinely result in deferred decisions, requests for "more analysis," and eventually the project dying on a committee's agenda. Structure is not bureaucracy; it is the mechanism by which analysis converts into action.

Standard Feasibility Report Structure

While organisations differ in their templates, most professional feasibility reports follow a consistent seven-section architecture:

The seven-section feasibility report structure and its three audience tiers — executives read sections 1 & 6, managers read the full body, specialists dive into the appendices.

Section 1 — Executive Summary

This is the most important section and must stand alone. An executive who reads nothing else should walk away knowing: what was studied, what the analyst recommends, what it will cost, and what the main risk is. For the HealthLink clinic, the executive summary might open:

HealthLink Feasibility Study — Executive Summary (example excerpt)

We evaluated three options for replacing the clinic's paper-based booking process: (A) build a custom system, (B) license an off-the-shelf platform, and (C) subscribe to a SaaS booking service. All three are technically feasible. Option B delivers the strongest economics — a projected 3-year NPV of $184,000, a payback period of 14 months, and an ROI of 62% — while carrying the lowest implementation risk. We recommend Option B with the condition that a HIPAA Business Associate Agreement is executed with the vendor before contract signing.

Notice what is not in the executive summary: methodology details, interview transcripts, raw cost tables, or technical architecture notes. Those live in the body and appendices.

Section 4 — Findings by Dimension

This is the analytical heart of the report. For each feasibility dimension, present a one-to-two-paragraph verdict with supporting evidence. Avoid raw data dumps — synthesise the evidence into a clear conclusion for each dimension and each option.

For example, the operational feasibility finding for HealthLink Option A might read: "Clinic reception staff expressed strong willingness to adopt a digital booking tool (survey: 87% supportive). However, the IT team (currently two people) could not absorb the ongoing maintenance burden of a custom system without at least one additional hire, estimated at $65,000/year — a cost not included in the original Option A estimate."

Scoring matrix tip: After the per-dimension findings, include a scoring matrix that rates each option across each dimension (e.g., 1–3 scale: 1 = fails, 2 = marginal, 3 = strong). This gives readers a visual comparison before the recommendation section, and it forces the analyst to make explicit judgements rather than vague conclusions.

Section 5 — Options Compared

Present the options side by side. A scoring matrix is the clearest format. For HealthLink:

HealthLink scoring matrix — Option B (Licensed Platform) scores highest overall, with Option C tied on total but weaker economically over a 5-year horizon.

Section 6 — The Recommendation

The recommendation section is where the analyst stakes their professional credibility. It must do three things:

State the preferred option clearly and without hedging. "We recommend Option B — the licensed platform from VendorX." Not "Option B appears to have advantages that may warrant further consideration."
Summarise the key reasons in two or three bullet points tied back to the findings. Do not repeat the entire analysis — reference it.
List conditions or next steps. If the recommendation depends on specific conditions being met — a legal review, a budget reallocation, a vendor negotiation outcome — state them explicitly and assign ownership.

For HealthLink, the recommendation section concludes: "We recommend Option B subject to three conditions: (1) Legal executes a HIPAA BAA with the vendor by 15 March; (2) Finance approves the $48,000 implementation budget in the Q2 cycle; (3) Operations assigns a project champion from the reception team. If any condition cannot be met within 60 days, the project should be deferred to the next planning cycle."

Common pitfall — the "weasel word" recommendation: Under political pressure, analysts sometimes write recommendations that avoid committing to any option, framing everything as "it depends" or "further study is needed." This is a report failure. If the feasibility study cannot produce a recommendation, it has not been completed — go back and resolve the unresolved trade-offs, or document clearly that no option is currently feasible and state what would change that verdict.

Presenting the Report to Stakeholders

Most feasibility reports are accompanied by a 20-minute presentation to a decision committee. The presentation is not a slide-by-slide summary of the report — it is a decision facilitation meeting. Structure it as: (1) one slide on the problem context, (2) one slide per option with the headline score, (3) one slide with the recommendation and conditions, and (4) a call to action: a formal vote or written sign-off. Allow 10 minutes for questions.

Prepare for three predictable challenges: the executive who advocates for the option you did not recommend, the technical lead who disputes a technical finding, and the finance director who questions the NPV assumptions. For each, have the supporting appendix slide ready and be prepared to walk through the assumption, not to change the conclusion mid-meeting.

Distribute the report 48 hours before the meeting. Stakeholders who read the report in advance ask sharper questions and make better decisions. Distributing it the morning of the meeting guarantees a longer, less productive discussion.

After the Decision — What the Report Becomes

Once the sponsor signs off, the feasibility report becomes a foundational reference document for the project that follows. The assumptions and scope boundaries stated in the report anchor the subsequent requirements specification. The risk register in the appendix becomes the starting point for the project risk management plan. The financial model becomes the baseline against which actual costs are tracked.

Teams that discard the feasibility report once the project is approved routinely find themselves re-debating decisions that were already made — "why are we building this ourselves instead of buying something?" — because the rationale was never institutionalised. Keep the approved report in the project repository and link to it from the project charter.

Quality check before submission: Before submitting the report, ask yourself these four questions: (1) Does the executive summary stand alone? (2) Is the recommendation stated without hedging? (3) Does every major claim have a source or evidence reference? (4) Have you disclosed assumptions and limitations honestly? A report that answers yes to all four is ready for review.

Summary

The feasibility report is the analyst's most important deliverable in the pre-project phase. It translates weeks of multi-dimensional analysis into a decision-ready document structured for three distinct audiences. The seven-section architecture — executive summary, background, methodology, findings, options comparison, recommendation, appendices — gives every stakeholder what they need without forcing them to wade through material that is irrelevant to their role. The recommendation must be clear, evidence-backed, and honest. Once approved, the report becomes the bedrock reference for all subsequent project work.