Presenting Recommendations: Communicating Findings to Stakeholders

Alex: Today we're covering the important skill of presenting recommendations to stakeholders. Sam, this brings together research and communication skills, doesn't it?

Sam: It does, and it's where a lot of the value of a project is realised. Doing excellent research and analysis is only worthwhile if you can communicate your findings and recommendations in a way that enables stakeholders to understand them, believe them, and act on them. The best analysis in the world, poorly communicated, achieves nothing.

Alex: What makes a recommendation credible?

Sam: It must be clearly connected to the evidence. A recommendation like 'the organisation should migrate to a cloud-based database' is only convincing if it's supported by evidence that demonstrates why this is the right choice: cost comparisons, performance data, security assessment, risk analysis, and a clear articulation of the business benefits. Recommendations without evidence are just opinions.

Alex: How should a final report be structured?

Sam: The standard structure for a professional project report typically begins with an executive summary: a one-page overview of the key findings and recommendations that busy stakeholders can read without reading the full document. Then an introduction providing context. A methodology section explaining how the research was conducted. A findings section presenting what you discovered. A discussion section analysing those findings in the context of the literature and the organisation's situation. And a recommendations section setting out your proposed courses of action, supported by the findings and discussion.

Alex: What about presenting findings verbally, in a presentation setting?

Sam: A presentation needs to be structured to fit the time available and the audience's needs. For a stakeholder presentation, I'd suggest starting with the context and the question you were addressing, moving to the key findings with visual support, then presenting your recommendations with clear justification. Allow time for questions and discussion, which is where the real value often lies. Your slides should be clean and uncluttered; use them to support your points, not to reproduce your report.

Alex: How do you handle difficult questions or challenges to your recommendations?

Sam: Preparation is the key. Think through the most likely objections to your recommendations before the presentation and prepare responses. If someone challenges a finding, refer back to your evidence rather than becoming defensive. If someone asks a question you genuinely don't know the answer to, say so and offer to find out; trying to bluff through a question you can't answer damages your credibility far more than acknowledging the limit of your knowledge.

Alex: Any advice on tailoring communication to different audiences?

Sam: Know your audience's priorities and concerns. A board-level audience cares primarily about strategic impact, cost, and risk. A technical audience wants to understand the methodology, the data quality, and the technical viability of recommendations. A user audience cares about what will change for them and whether the solution will actually be usable. Adapt your language, level of detail, and emphasis accordingly.

Alex: Brilliant. Thanks Sam. We move into Unit 7 and Software Development Lifecycles next.