Shane Ian Murphy: Preparing a Cambridge Project Brief for an Outside Reader

A project can make perfect sense to the people developing it and remain difficult for anyone else to assess. The team remembers the meetings, discarded options and explanations behind each document. An outside reader sees only what has been sent. My starting point for a useful project brief is to ask which parts of that shared memory need to become visible on the page.

I am Shane Ian Murphy, also known as Shane Murphy, formerly of Cambridge and formerly of Limitless Mobile, where I was co-founder and Chief Business Development Officer. This commentary draws on my earlier UK commercial background. The example below is hypothetical and does not describe an actual client project, financing application or completed transaction.

Give the reader an entry point

Imagine a small Cambridge workshop considering a portable display kit for exhibitions. Its team has sketches, a supplier estimate and photographs of equipment it already owns. A colleague outside the project has been asked to review the proposal. Before opening the attachments, that colleague needs to understand the intended decision.

I would begin the brief with the problem, the proposed response and the present stage. Perhaps the existing display is difficult to transport and the team wants to explore a smaller arrangement. Is the request for comments on the idea, permission to obtain a prototype or a decision about ordering equipment? Those are different requests. A reader should not have to infer which one has been made from the presence of a price estimate.

Describe what exists now

The next paragraph should distinguish current evidence from planned work. A sketch is a sketch. A supplier's description is a supplier's description. A physical prototype would answer different questions. The brief becomes misleading if these different kinds of material are presented as though they establish the same thing.

In our workshop example, the estimate might describe dimensions and materials while leaving packing arrangements unresolved. I would state that limitation beside the estimate's purpose. It is more useful to explain what a document can support than to imply that including a document settles every related question.

Organise attachments around questions

A document index should help the reader find an answer. Instead of listing filenames alone, add a short description of the question each attachment addresses. The sketch may explain the proposed arrangement. Photographs may show the current equipment. The estimate may describe a supplier's proposed scope. This gives the reader a reason to open each item.

I would also include its version date and the person responsible for clarifying it. If several versions remain relevant, explain their relationship. A reviewer should not have to compare two similar filenames to guess which describes the current proposal. Keeping an older version can be useful, but its purpose should be explicit.

Make the unresolved work concrete

An open question should describe what is missing and how it affects the next decision. “Transport needs work” is less helpful than “The proposed cases have not yet been checked against the vehicle the team intends to use.” The second statement points towards an action that someone can understand and assign.

For each significant uncertainty, I would identify the next information-gathering step and who is expected to take it. This is not a demand to eliminate all uncertainty before discussion. It is a way to make the discussion useful. Some questions may be resolved by reading existing material; others may require a demonstration or a different specialist.

Preserve reasons for choices

The team may have rejected a larger design because two people could not move it comfortably through the intended entrance. An outside reader who sees only the smaller design might suggest returning to the earlier option. A short explanation of the constraint helps the reviewer contribute without repeating a discussion the team has already had.

The explanation should leave room for challenge. Record the reasoning and its supporting information, rather than presenting an earlier decision as beyond examination. If the constraint changes, the record should make it possible to see which conclusion needs reconsideration.

End with a usable response

I would close the brief by asking for the particular response needed next. In the hypothetical workshop, the reviewer might be asked whether the proposal explains the transport problem clearly enough to justify preparing a prototype. That is more focused than an invitation to comment on everything.

A good project brief is an introduction to the work at its present stage. It gives an outside reader the context to ask better questions, locate relevant evidence and understand what remains undecided. For a Cambridge team sharing a proposal with a UK colleague or a more distant collaborator, that shared starting point can make the next conversation more productive.

Author background: https://shanemurphy.co.uk/career

This author-origin business commentary was prepared with AI assistance.