01

Begin with job roles, not a list of tools

A leader, an operational specialist and a developer have different needs. Leaders need to understand limitations, prioritise use cases and assess risk. Specialists need clear prompting, output review and repeatable practice. Choose everyday tasks with process owners and translate learning goals into observable skills, such as producing a summary whose claims have been checked against its source.

02

Build exercises with permitted information

Prepare exercise material before the workshop. Use synthetic text, public data or an approved sample. Removing a customer name alone may not be sufficient: prices, identifiers, contracts and workflow details can also be sensitive. Participants need explicit approved-tool and data-entry rules rather than having to decide on the spot what may be uploaded to an external service.

03

Evaluate the output, not just the prompt

Include a review stage in each exercise. Is the answer relevant? Does it add unsupported information? Does it recognise missing evidence? Ask participants to critique and improve a weak answer and explain why they accept or reject it. This builds a more durable skill than memorising one prompt template, because tools and models change while review and limitation awareness remain necessary.

04

Connect learning to a working practice

Attendance and end-of-session satisfaction are not sufficient evidence of learning. Set comparable tasks before and after training, then compare quality, errors and the ability to explain decisions. Give each team a bounded use case, a review owner and a way to report problems. Subsequent learning can follow that feedback. The goal is usable capability, not an unmeasured productivity promise.

05

A sample report-summarisation exercise

Choose a short public or synthetic report. Set the task as follows: use only the supplied text to identify three main points and two uncertainties; identify the supporting passage for each point; acknowledge insufficient evidence; add no outside figures or conclusions. Participants then compare the answer against the reference and identify an unsupported claim. The deliverable includes the corrected summary, an error list and reasons for corrections. This is an illustrative teaching exercise and does not describe any customer project.

06

What should be assessed before and after a workshop?

Prepare equivalent baseline and final tasks. Use four explicit criteria: task relevance, fidelity to the source, recognition of limitations and permitted-data handling. Define examples of acceptable and unacceptable answers to reduce subjective grading. Completion time may be recorded, but a fast incorrect answer is not learning success. Assign a team owner to maintain templates and handle usage questions afterwards. Tool selection, in-person or online delivery and technical depth should follow the needs assessment rather than one standard programme for every organisation.

This article presents the Roham team’s general approach. Each project’s scope is defined around its own requirements.
All insights