How do I distinguish a project brief from a proposal when both describe an idea?

They answer different questions. A brief answers, “What are we trying to address, and what would the work include?” A proposal answers, “What should we do about it, and why choose that approach?”

A brief defines the problem or opportunity, intended outcome, audience, boundaries, constraints, and questions that still need resolving. It can describe an idea without claiming that idea is the best solution.

A proposal recommends a particular approach, explains the reasoning, describes what it would take, and states the approval or next step being requested. It can refer to a brief rather than repeat all its detail.

If readers need to understand or agree on the problem, start with a brief. If they need to decide whether to proceed with a plan, write a proposal.

Give each document a distinct job. A brief can include:

1. Purpose: What prompted the work?
2. Problem or opportunity: What needs attention, and for whom?
3. Intended outcome: What change would be useful?
4. Scope: What is included and excluded?
5. Constraints and assumptions: What limits, dependencies, or unconfirmed details matter?
6. Open questions: What needs clarification?

A proposal can include:

1. Decision requested: What should the reader approve or choose?
2. Recommended approach: What would be done, and why?
3. Alternatives: What other plausible paths were considered?
4. Work and resources: What activities, people, time, or budget are anticipated? Label estimates as estimates.
5. Risks and uncertainties: What might affect the plan?
6. Next step: What happens if the reader agrees?

The brief can remain open about the solution; the proposal should make its recommendation clear. If the proposal changes the brief’s scope or adds an assumption, flag that change.

Suppose a team is considering improving how new staff find internal process guidance. The example is illustrative, not a claim about any real organization.

Brief excerpt

• Problem to explore: New staff report difficulty finding guidance. The reasons and extent are not yet established.
• Intended outcome: Make relevant guidance easier to locate.
• Scope: Review current guidance and how it is organized. Creating new software is outside scope for now.
• Open questions: Which staff groups are affected? Which materials are in scope? How will the team assess whether changes help?

This defines the work without assuming a cause or choosing a solution.

Proposal excerpt, based on that brief

• Decision requested: Approve a short review of the guidance structure and a small reorganization proposal.
• Approach: Inventory the in-scope materials, then draft a revised grouping for staff to review.
• Rationale: This stays within the brief’s scope while exploring whether organization is worth addressing.
• Estimate: Add a planning estimate, owner, and assumptions; do not present these as confirmed commitments.
• Next step: If approved, confirm the reviewers and materials.

The proposal turns the brief’s boundaries and open questions into a specific decision. It does not claim that reorganization will solve the problem.

If both are needed, make the brief the shared foundation and the proposal the decision layer. They can be separate documents or clearly labeled sections in one file. Keep the problem statement consistent, refer back to the brief instead of repeating it, and make any changes to scope visible.

If the problem is unsettled, do not make the proposal sound more certain than the brief. You could propose a discovery step, such as reviewing relevant documents or comparing possible problem definitions, rather than recommending a full solution prematurely. State what decision that step would enable and what remains unknown.

Before drafting, ask: “Who will read this, what decision do they need to make, and do we need agreement on the problem before choosing an approach?” The answers help determine whether you need a brief, a proposal, or both.