A T-Plan workshop example for a manufacturing team

A roadmap workshop is easier to prepare when the team can name the choice it needs to make. In this example, a pump manufacturer must decide which monitoring approach deserves a field pilot, what product functions it should provide and what evidence is required before committing to rollout.

The team also agrees a twelve-month planning horizon and the equipment family in scope. It invites commercial, product engineering, maintenance, operations and finance perspectives. Each participant brings evidence and assumptions that the others may not have.

T-Plan uses four connected workshop perspectives: market, product, technology and charting. The first examines external and internal drivers, before the subsequent discussions connect product responses and technology options. [1]

For the fictional pump case, begin with unexpected stoppages, short installation windows and demanding operating conditions. Ask which equipment types and customer groups each affects. Separate a verified need from a participant's expectation.

Record where the evidence came from and its limits. An interview with one maintenance manager may generate a useful hypothesis. It does not establish how every customer operates. Assign the most consequential gaps to a person who can investigate them.

Translate the drivers into product functions and attributes. Detect deterioration. Fit existing equipment. Operate in the specified environment. Agree what each statement means, then examine how it contributes to the driver.

Engineers may prefer the term product functions to product feature concepts. Use the vocabulary the group understands and distinguish the desired function from a particular component or technology. That prevents a preferred solution from silently becoming the requirement.

Bring forward candidate sensing approaches, mounting methods and enclosure concepts. A linking grid helps the group discuss which functions they support, where adverse effects arise and which relationships remain unknown.

In our example, neither sensing approach is ready for a field commitment. Define a representative bench trial, the acceptance criteria and the comparison that would make a choice defensible. Include installation constraints and support needs, not just sensor specifications.

Arrange the driver, function, technology and work relationships against the planning horizon. Make the dependency between qualification, pilot and rollout decision visible. Roadmapping architecture helps connect these layers; the dates should reflect the actual decision sequence. [2]

Check specialist capacity and the funding boundary before treating the pilot as committed. Close with decision owners, evidence actions and review triggers. Decide who maintains the map and which future meeting will use it. The R2 research addresses the design of this wider roadmapping system. [3]

The workshop pack contains a decision brief, an evidence register, a functions-to-options grid, a roadmap worksheet and a resource check. Start with the worked example, then replace its assumptions with your own organisation's evidence.