Turn report findings into justified recommendations
Compare realistic responses to report findings, justify a bounded recommendation and trace it into responsibilities, dependencies and review evidence.
About 12 min read · Allow extra time for the practical checks
A report finding tells the reader what the evidence shows. A recommendation asks someone to do something because of it. The difficult work sits between those sentences: deciding which response is justified when more than one action is possible.
“Improve communication” does not make that decision. Neither does a precise-sounding instruction with an invented budget or an unexplained deadline. A useful recommendation identifies the problem it addresses, compares realistic responses and explains why the proposed action is preferable under the report’s evidence and constraints.
This guide develops that choice through a fictional option-to-action trace. It is not a universal report template. Check whether your assignment requires recommendations, where their justification belongs and how much implementation detail is expected. An analytical report may stop at an interpretation; a problem-solving report may require a proposed response.
Start with the problem the report actually established
Before listing solutions, write the finding, its location and the limit that matters for action. Then state the problem narrowly enough that you can test whether each option addresses it.
Keep three moves separate:
- Finding: a checked observation from the report’s evidence base.
- Interpretation: what that observation means for the report’s purpose, with uncertainty retained.
- Recommendation: the response you propose after evaluating alternatives.
If the first move is weak, a confident third move cannot repair it. Return to the evidence or narrow the proposal. The results-and-discussion guide covers the separate task of distinguishing observed findings from their interpretation.
Monash University’s case-report guidance separates evaluating alternatives, selecting a response and planning implementation. It also warns against diagnosing one problem and recommending an answer to another. Its structure is task-dependent, not a requirement for every report.
Build a bounded fictional evidence pack
Everything about Northbank Equipment Library below is invented teaching material. The organisation, records, feedback and planning constraints are fictional, not findings about a real service.
The fictional brief asks for a feasible response to avoidable request clarification while preserving online, telephone and in-person access. It permits a recommendation and an outline implementation plan, not an approved service change.
The supplied report pack contains:
- F1, Findings §3.1: during four weeks, 24 of 80 online loan requests were returned for a missing pickup day or time window. The other 56 were not returned for that reason; this does not establish that all 56 became completed loans.
- F2, Process review §3.2: the online form has an optional free-text pickup note, although staff need a pickup window to check availability. A separate help page already asks users to provide it.
- F3, Feedback §3.3: six of ten voluntary respondents said the pickup instruction was unclear. Their responses do not establish the views of all users or explain every returned request.
- C1, Brief constraints: telephone and in-person requests must remain available. The report does not quantify their clarification workload.
- C2, Resource position: staff time, form-editing effort and accessibility performance have not been measured. No change budget or staff allocation has been approved.
The observed return proportion is 24 ÷ 80 = 30% of online requests in that period. It is not a service-wide failure rate, a cancellation rate or an estimate of the effect of a redesigned form.
A defensible problem statement is: “Online requests sometimes reach staff without information needed to check a pickup slot, creating a clarification step.” The mismatch between an optional field and an operational requirement is a plausible point for improvement. The pack does not prove that unclear wording caused all 24 returns.
“Users lack digital skills” would invent a cause. “The library needs a new booking platform” would jump to a purchase before comparing responses. Neither belongs in the recommendation simply because it sounds like an explanation.
Set criteria before choosing your favourite option
Choose criteria from the brief, problem and evidence. For this fictional decision, useful questions are:
- Does the option address the missing pickup information at the point it is needed?
- Does it preserve the required access routes and avoid introducing an untested barrier?
- What staff or technical resources does it depend on?
- Can it be tried, reviewed and reversed without assuming a full rollout?
Some criteria are constraints, not advantages to trade away. Here, preserving telephone and in-person access is stipulated by the brief. A proposal that closes those routes cannot earn its way back through a high convenience score.
Do not add a numerical scoring system merely to make a judgement look objective. If your task requires weighted scoring, explain who chose the weights, use evidence for ratings and show whether reasonable changes alter the preferred option. Unknown cost is not a zero-cost score. In this example, a qualitative comparison exposes the important uncertainty more honestly.
Compare genuine alternatives on the same basis
Include current practice where it is a real choice, and consider a proportionate information-gathering response when uncertainty prevents commitment. Do not make the preferred option win by comparing a carefully designed proposal with deliberately absurd alternatives.
The following matrix is an original organising aid, not a validated decision instrument. The options and judgements belong only to the fictional pack.
On a narrow screen, scroll the table sideways to read every column.
| Option | Fit to the diagnosed problem | Trade-off and unresolved dependency | Decision |
|---|---|---|---|
| A · Retain the form and rely on the existing help page | Preserves the current process, but does not change the optional field at the request point. F2 shows that the separate instruction already exists. | Avoids a form change; retains the observed clarification issue. Continuing the current process is not evidence of no staff cost. | Keep as the fallback while permission and feasibility are checked. Do not present adding the same help instruction as a new intervention. |
| B · Test a clearer pickup prompt within the current form | Directly addresses the field/requirement mismatch in F2. A prototype would explain the needed day/window and what to do if the user cannot specify one. | May reduce missing information, but that benefit is untested. Wording, error handling, accessibility and editing effort need checking before a live pilot. | Preferred for a staged test, conditional on access, technical and resource checks; not approved for full rollout. |
| C · Have staff contact each online requester before availability checking | Could obtain missing information through conversation without depending on a revised prompt. | Adds a contact step even for requests that already contain the information. Required staff time, reachability and delay are unmeasured. | Do not select as the default on this evidence. Retain individual clarification where needed; reassess if the form route proves unsuitable. |
The comparison does not establish that B is cheapest or most effective. It establishes why B is the most closely targeted candidate to investigate first, while preserving A as the interim process and C as a possible response to unresolved access needs.
If a new platform were added as a fourth option, the report would need evidence that the current system cannot support the necessary change, plus proportionate information about migration and resource implications. An impressive product name is not that evidence.
The University of Portsmouth’s report-writing guidance offers two useful checks: can the proposed action realistically be done, and is it already being done? In this example, the second question prevents repackaging the existing help page as the solution.
Write the recommendation with its selection rationale
A recommendation can be direct without pretending that a test has already succeeded. Compare:
Weak: Northbank should install a compulsory pickup selector immediately. This will eliminate delays and improve satisfaction.
Revised: Northbank should first seek approval for a small test of a clearer pickup prompt within its existing online form. The optional field conflicts with the pickup information staff need (§3.2), and 24 of 80 online requests required clarification for missing day/window information (§3.1). A prompt-level test targets that mismatch more directly than relying on the existing help page, while avoiding the blanket additional contact step proposed in option C. The benefit remains untested. A live pilot should proceed only after the proposed wording, alternative contact route, accessibility, editing effort and staff capacity have been checked and approved by the responsible decision-maker.
The revised version names the action and its evidence, explains the comparison and identifies a gate. It does not say that the voluntary feedback proves a cause, that a required selector is necessarily accessible or that approval already exists.
If your report must apply a course theory, explain how the relevant concept helps interpret the problem or compare the options. Cite the actual source and test the fit; do not attach a theory name after making the decision. See connecting case evidence to a course theory for that distinct reasoning task.
Trace the proposal into action without inventing authority
A detailed plan is useful only if readers can tell which parts are known, proposed or unresolved. “The IT team will deliver this next Friday for $200” is not an implementation plan when nobody supplied that commitment or estimate.
UNC Charlotte’s From Findings to Action connects evidence with realistic choices, responsibilities, resource implications and subsequent review. The trace below applies that general principle; its stages and timings are fictional teaching choices, not the university’s prescribed method.
On a narrow screen, scroll the table sideways to read every column.
| Stage and proposed responsibility | Action and dependency | Evidence or decision required |
|---|---|---|
| 1 · Library manager, proposed decision owner | Review the option comparison and decide whether a prompt test may be scoped. Confirm who can approve form and operational changes. | Recorded scope and actual owner; permission to investigate is not permission to deploy. Budget and staff allocation remain unresolved. |
| 2 · Desk lead with the form maintainer, proposed collaborators | Prepare a blank prototype; check wording, field behaviour, the route for uncertain pickup times and accessibility. Estimate editing and support effort. | Feasibility/access findings and resource estimate. Do not launch if an access problem or unsupported dependency remains. |
| 3 · Responsible manager, subject to stage 2 | Decide whether to approve a four-week live pilot. This duration is a proposal, not a supplied operational commitment. Agree review criteria before starting. | Approved pilot scope, responsibilities and resource cover, or a recorded hold/revision. Telephone and in-person access must remain. |
| 4 · Desk lead and manager, proposed review roles | Check implementation and review the pilot record before deciding to retain, revise or stop the change. | Online-request total, missing-window returns, clarification workload and access issues, using authorised existing records and proportionate reporting. No proven effectiveness is assumed. |
The plan deliberately stops where evidence or authority stops. If the assessment requires a cost estimate, obtain a defensible basis or state the limitation and seek guidance. Do not fill an empty cost cell with an invented quotation. If the proposal cannot be made feasible within the brief, revise the option rather than hiding the dependency in an appendix.
Separate implementation evidence from outcome evidence
Two different questions belong in the review:
- Was the action implemented as intended? For example, was the approved wording present, did the alternative contact route work, and were staff following the agreed process?
- What happened afterwards? For example, how many online requests arrived, how many were returned for missing pickup information, and what clarification burden or access problems were observed?
A screenshot of the changed prompt would answer part of the first question, not the second. Fewer returned requests would not automatically prove that the change caused the difference. Request volume, user mix or other process changes could also matter.
Compare both counts and denominators with the fictional baseline of 24 returns among 80 online requests. Keep the counting unit and reason for return consistent. A lower count during a much quieter period is not automatically an improvement in the return proportion. Do not generalise online results to the unmeasured telephone and in-person routes.
Before any real pilot, the responsible people would need to agree acceptable access, workload and information-completeness criteria and what would trigger revision or stopping. Those thresholds are not supplied in this pack. Their absence is an unresolved planning decision, not permission to declare success afterwards using whichever measure looks favourable. Record only information you are authorised to use; a report does not create permission to circulate requesters’ personal records.
Audit the chain in both directions
Read from finding to action: does the proposed response address the problem, or has the report drifted into a more attractive but different project? Then read backwards from each recommendation to its evidence, comparison and material limit.
Before finalising the recommendations, check:
- The actual brief calls for the proposed kind of action.
- Each recommendation has a precise finding or analysis locator.
- Plausible alternatives have been compared against the same relevant criteria.
- The selection explains trade-offs and rejection or deferral, not just preference.
- Existing practice is not presented as a new intervention.
- Proposed owners, timing, estimates and dependencies are distinguished from commitments.
- Unknown causes, costs and benefits remain unknown rather than becoming persuasive claims.
- Implementation checks and outcome review answer different questions.
- Unmet permission, feasibility or evidence gates remain visible.
For a stand-alone policy communication, first plan the brief around the intended decision-maker. That task establishes the reader’s remit, current decision and relevant evidence; it is not solved by shortening this option comparison or assuming the reader can approve the proposed action.
Once the choice is justified in the report, carry its action and consequential limits into the executive summary. That is a separate condensation task: the summary should not introduce a stronger recommendation than the body supports. Keep essential selection reasoning in the body; use appendices only for relevant, permitted supporting detail.
Where external support is permitted, academic writing support can help you test the reasoning and organisation of a recommendation based on your own evidence and decisions. Unclear meaning should become a question to the author, not an invented justification. Your assignment requirements, evidence and final judgement remain yours.
