The first programme brief does not need to contain every answer. It needs to make the next conversation useful. A few well-chosen details can help an institutional team and its partners understand the proposed work without creating a document that is difficult to maintain.
Give the work a clear institutional home
Start with the institution, location and programme lead. Describe the teams that are expected to participate and the reason the institution is exploring the capability.
Name a person who can coordinate the conversation across those teams. Their first responsibility is to bring the right questions together, rather than resolve every technical issue themselves.
A brief becomes easier to use when each statement has an owner. Mark which information is confirmed, which is an estimate and which is still awaiting a discussion.
Describe the baseline in plain language
Summarise the setting the programme would enter. Include relevant facilities, existing methods, available roles and the systems already used to document work.
Separate what is available today from what might be added. If a detail has not been checked, say so. An explicit unknown is more useful than a confident assumption that partners interpret differently.
Use a simple inventory where it helps the conversation. The aim is to make the baseline understandable, not to imply that the presence of a particular instrument makes the institution ready.
A clear brief turns a broad ambition into a conversation with named questions and owners.
Five things to include
Institution and location
Give partners enough context to understand where the programme would sit.
Capability and intended scope
Describe what the team wants to explore and the boundaries of that discussion.
Current baseline
Summarise existing people, facilities, methods and operating systems.
Questions for review
List the decisions or uncertainties that the first conversation should address.
Programme lead and participants
Identify who coordinates the brief and which teams should be involved.
Keep the brief easy to revise
Use a document that the team can update as the discussion develops. Record the date, owner and the next action for questions that remain open.
Avoid turning the initial brief into a promise about implementation. A feasibility conversation may change the scope, the sequence of work or the participants involved. The brief should make those changes visible.
A useful closing question is simple: what information would make the next decision easier? Give that question an owner and a clear place in the document.
