All resources

Planning

A project brief that gets you a better proposal

October 6, 20263 min read

Use this guide, “A project brief that gets you a better proposal”, to plan your next steps. You do not need a technical specification to start a useful project conversation. You do need to describe the problem, the people affected and what a successful first release should accomplish. A short, clear brief helps a delivery team ask better questions and explain the tradeoffs behind its proposed scope.

Key takeaway

Describe the business outcome and essential user journey before listing features or choosing a technology.

01

Explain the problem in everyday language

Describe what happens today and why it needs to change. Perhaps enquiries are hard to track, customers cannot find the right information or staff repeat the same manual task. Include the people affected and the cost of leaving the situation unchanged. Keep the opening focused on the problem rather than assuming a particular tool is the answer.

02

Choose a useful first outcome

Name what should be easier after launch and how the team will recognise that result. Examples include a clearer route to enquiry or a single place to track an operational handoff. Avoid broad promises such as improving everything at once. A focused outcome gives the team a practical way to evaluate design and development decisions.

03

Describe the main users and their tasks

List who will use the website or application and what each person needs to do. Include staff roles as well as visitors or customers. Explain approvals, exceptions and handoffs that are easy to miss in a screen list. One short example of a real workflow can be more useful than a long catalogue of imagined features.

04

Show the existing setup

Share relevant information about the current website, hosting, business software and any integrations. Identify who owns the source files, content and accounts. Explain which systems must stay in place and what can change. Do not include passwords or secret keys in the brief; the team can agree a safe access process when it becomes necessary.

05

Separate essentials from later ideas

Make two lists: what the first release needs and what could wait. Include timing constraints and a budget range if you have one. References can help explain a style or interaction, but clarify what you like about them rather than asking for an entire site to be copied. The aim is a shared understanding of priorities.

06

Ask for a complete proposal

Request the scope, assumptions, responsibilities, milestones and acceptance process in writing. Ask how changes will be assessed and what the handover includes. Include hosting and ongoing care in the conversation so the business knows what happens after launch. A useful proposal makes uncertainties visible instead of hiding them behind a single attractive price.

Your next-step checklist

  • Write the current problem and desired first outcome
  • List users and their most important tasks
  • Describe the existing systems and ownership
  • Separate launch essentials from later improvements
  • Include timing constraints and relevant references
  • Ask for scope, responsibilities and handover in writing

Put this guide to work.

Tell us about your goals and current setup. We can help you discuss the requirements and plan a suitable next step.

Discuss your project