Before the programme, understand the work

A training request often arrives in the language of tools: Power BI, automation, AI, a particular platform, or a list of features people want to learn.

That is useful input, but it is not yet enough to design a good programme.

Before deciding what to teach, I find it more useful to understand the work the participants are actually responsible for. What are they trying to produce? Which decisions are they expected to make? Where does the current process become slow, inconsistent or difficult? And what would need to change for the training to be considered useful after the classroom session is over?

Those questions usually change the shape of the programme.

Start with the work, not the tool

A tool can support many different kinds of work. The same Power BI course can mean very different things for an analyst building reports, a manager consuming dashboards, or an IT team responsible for data models and governance.

The same is true for AI and automation. “Learn AI” may mean writing better prompts, creating content more efficiently, automating repetitive processes, or understanding how human review should fit into an AI-enabled workflow.

If the work is unclear, it is easy to build a technically correct programme that is only loosely connected to what participants need to do afterwards.

Understanding the work first creates a better boundary around the problem. It helps separate what participants genuinely need from what is merely interesting to demonstrate.

Understand who is doing the work

Audience matters for more than difficulty level.

Different groups often own different parts of the same process. A business user may define the requirement and review the output. A specialist may build the workflow. A manager may approve the final decision. An IT or data team may be responsible for the environment in which everything operates.

A useful programme should reflect those distinctions rather than treating everyone as the same type of learner.

This affects examples, exercises and even the vocabulary used in the classroom. It also makes responsibilities clearer. Participants should leave understanding not only what a tool can do, but which parts of the work they are expected to own.

Find the decision points

One of the most useful questions in programme design is: where does a person still need to make a decision?

This becomes especially important with automation and AI.

Some steps can be made deterministic. Some can be assisted by AI. Others still require judgement, approval or accountability from a person.

If those decision points are identified early, exercises become much more realistic. Instead of demonstrating a sequence of features, the programme can show how a process moves from input, to automation, to review, to an accountable final decision.

That difference matters because a workflow that runs successfully is not necessarily a workflow that an organisation is ready to rely on.

Constraints are part of the design

The desired outcome is only one side of the problem. The other side is the environment in which the programme has to work.

Time is limited. Participant capability varies. Data may not be available. Production systems may not be appropriate for training. Security or internal processes may limit what can be demonstrated. Some concepts may need to be practised in a sandbox before they can be considered operational.

These constraints should not be treated as inconveniences to work around after the curriculum is written. They are part of the curriculum design itself.

Sometimes the right outcome is not “participants can deploy this immediately.” It may be “participants understand the workflow, can practise it safely, and know what would still be required before operational adoption.”

That is a more modest claim, but also a more useful one.

Tools come later

Once the work, audience, decision points and constraints are understood, choosing tools becomes much easier.

The tool is then serving a defined purpose inside the programme rather than becoming the programme itself.

This is also why discovery matters so much in enterprise training. A good programme is not simply a catalogue of topics arranged into a timetable. It is a structured response to a particular type of work, performed by particular people, within a particular set of constraints.

The better that context is understood before the programme starts, the more likely the classroom experience is to connect with what participants actually need to do afterwards.