5.1 Prepare to Deliver

Last updated on 2026-03-13 | Edit this page

Overview

Questions

What should you do (and not do) when presenting to others?
How should you communicate with a non-technical audience?
What should be included in the project presentation?
What are the scoring criteria for the presentation?

Objectives

Describe techniques and approaches for communicating and presenting to a non-technical audience
Briefly describe the criteria for delivery assessment
List the key topics the delivery presentation needs to cover
Within teams decide on panel presentation structure
Decide who will be responsible for presenting each aspect and other roles for the session
Develop a presentation for panel review session

Earlier in the course we covered the importance of effective communication with clients. This is also important when presenting delivery of a final solution - as a completed project - to clients, since it provides the ultimate opportunity to clearly demonstrate the value of the product and show how it meets the client’s requirements and goals.

Such presentations allow the development team to explain key design decisions, highlight features, and showcase how the software can be used in practice, helping to build trust and confidence in the solution. The presentation also creates a space for feedback, questions, and clarification, ensuring that the client understands the delivered system and that any final issues or expectations can be addressed.

Challenge

Class Exercise: Compare and Contrast

15 mins.

Watch the following two videos as a class, and note down in the shared class document any feedback, either positive or what could be improved:

NB: these YouTube videos were created by Learning Resources at the University of Bedfordshire.

Show me the solution

First video:

Didn’t introduce themselves
Hadn’t tested or set up the presentation equipment before the presentation
Appeared to check their phone
Not relevant or unprofessional pictures
Very little eye contact with the audience
Spoke too fast at points
Had their back to the audience and crossed their arms while presenting
Mostly read the content on the slides verbatim
Presentation used a loud colour scheme, and font/text sizes that were inconsistent and very difficult to read
Distracting animations in the presentation
Impolitely asked questions and interrupted when they answered

Second video:

Introduced themselves and the topic at the start of the presentation
Consistent use of a clear font and appropriate font size
Paced their delivery
Gave additional relevant detail on each point in the slides
Used open body language, facing the audience
Good eye contact with the audience
Allowed time for questions at the end

Delivering an Effective Client Presentation

Presenting to a non-technical audience video - Simon Hettrick

Given the technical nature of developing a software solution, presenting a final product to a non-technical audience can prove a challenge!

Callout

Focus on Value!

Clients are typically more interested in how the software meets their requirements, solves their problems, and delivers benefits to their organisation. Excessive technical explanations can make the presentation difficult to follow and will distract from the key messages, and risk losing the audience’s engagement, which is especially true if they do not have a technical background.

Instead, keep the presentation focused on functionality, usability, and business impact, using clear language and demonstrations that show how the system supports the client’s goals.

A successful client presentation clearly communicates the outcome of a project, and effectively demonstrates how the developed software meets the client’s requirements and objectives. They provide an opportunity to showcase the functionality and value of the solution, explain key design decisions, and ensure that the client understands how the software is used in practice.

In addition to the comments made in the video, consider the following when planning and writing a delivery presentation:

Have a clear narrative - it should be clear what will be presented, and what is being presented, within a logical and clear structure
Focus on value - emphasise how the solution solves the client’s problem and improves their outcomes, highlighting key features and benefits
Explain design decisions - summarise important technical or architectural designs where relevant, whilst avoiding overlong technical rabbit holes that explain the technical journey but detract from clarity
Address quality - where relevant, show how you followed a sound development process and engineering practices to ensure a quality product
Be honest about any solution limitations - as well as challenges encountered, and how you overcame them
Prepare for and encourage feedback - invite the client to ask questions or suggest potential future refinements, anticipating likely concerns or queries in advance

It’s also typical to deliver a demonstration of the product to the client, demonstrating the key features and highlighting how - in practical terms - the software will provide value to the client. It’s important to not only focus on the software’s desired functionality, but also the requestd non-functional characteristics of what is being delivered, e.g. documentation and reproducibility of results.

Many of the points above also apply to delivering an effective demonstation, but also consider the following:

Plan a simple, clear narrative - structure the demo around a simple and realistic scenario or tasks whilst highlighting benefits, instead of covering unrelated features
Use realistic data - demonstrate the system using meaningful data or scenarios that reflect real use
Explain what you are doing - talk through each step so the client understands what is happening, how the software works, and why it matters
Keep the timing under control - cover the most compelling aspects of the demo first, so you have the option of cutting less important benefits if you run out of time
Practice the demo beforehand - rehearse the sequence to avoid the “demo curse”, and exclamations of “it hasn’t done that before!”

Panel Scoring Criteria

The panel members will use the following criteria to evaluate presentations. Note the balance of marks allocated across the different areas. In particular, the presentation/demo and agile-based teamwork areas make 60% of the total marks.

Presentation and Product Demonstration (30%)

Is it a clear and understandable presentation?
Is there a logical flow and structure to the presentation?
How engaging was the presentation?
Did the presentation finish within its allotted time?
How effectively, and to what extent, were presentation duties divided well across team members?
As a team, how effectively did the group handle the Q&A?

Agile-based teamwork (30%)

Is there a clear definition and distribution of roles across the team?
Generally, how well did the group appear to work together as a team in the project? e.g.
Communication, task delegation, identify and address challenges
To what extent, and how well, did the team employ the Scrum agile approach, techniques, and practices taught throughout the course? e.g.
- Techniques: user stories, MoSCoW prioritisation, task estimation, sprints, backlog refinement
- Meetings: sprint planning meetings, daily scrum meetings, sprint review, sprint retrospective
- Artifacts: product backlog, sprint backlog, definition of done
How effectively did the team make use of the client meeting? e.g. manage the agenda, clarify and prioritise requirements, manage expectations
To what extent did the team take on board any advice given by their mentor?

End product (20%)

To what extent does the product achieve the stated goals of the project? e.g. to what extent is the developed software
- Usable for its intended purpose?
- Reusable, modifiable and extensible?

Software engineering practices (20%)

To what extent, and how well, did the team employ the software engineering techniques, tools, and practices taught throughout the course? e.g. Git collaborative workflow (inc. pull requests and code review), automated unit testing, continuous integration, documentation, release management Was the team’s choice of software licence well justified?

Discussion

Group Exercise: Nosce te Ipsum - Know Thyself

20 mins.

Similarly to retrospectives conducted after a single sprint, when preparing for a client presentation it really helps to reflect and identify where you have done well overall throughout the project, and what could have gone better. This feeds into your planning, and helps to ensure you play to your strengths whilst mitigating your weaknesses.

(10 mins) Think back to your sprint retrospectives and general experiences. In your teams discuss, decide and note down in your group shared document what you think your key strengths are for each of these areas of the scoring criteria:

Your developed software product and how it meets the clients needs
How you developed the software within using the agile Scrum approach (and how effectively you worked as a team)
How well you employed the software engineering practices, tools, and techniques taught throughout the course

Aim to roughly order each list, putting the most compelling, strongest items at the top. Given the small scale of the group project, feel free to embellish slightly!

(10 mins) Repeat the above activity, but this time focus on your weaknesses, and what you could have done better.

Discussion

Group Exercise: Prepare your Presentation!

90 mins.

As a group, prepare a short presentation that showcases what you have developed over the week, and how you’ve done it.

As a team, decide on a structure to the presentation and who will be responsible for presenting each aspect (and any other roles for the session).

Using the panel scoring criteria above to help guide the content, the presentation should include (but aren’t limited to):

Brief recap of the project goals
How the product meets the stated goals of the project
How the team employed the Scrum agile approach, techniques, and practices
How the team employed software engineering tools and practices
Short demonstration of the product, highlighting how it meets the project goals
Short Q&A session at the end

Key Points

Client presentations demonstrate the final value of the delivered software and how it meets client requirements and goals.
Presentations provide an opportunity for questions, feedback, and clarification from the client.
Effective presentations should have a clear narrative and logical structure.
Focus on value, usability, and business impact rather than excessive technical detail.
Briefly explain important design choices and development quality practices.
Be transparent about limitations or challenges and how they were addressed.
A product demonstration should show realistic scenarios, clear explanations, and meaningful data.
Preparation and practice are essential to ensure a smooth, engaging, and well-timed presentation.