What a good software project brief actually contains

A project brief should answer three questions before it talks about technology.

What is broken today? Describe the process, not the tool. Who does what today, where does it slow down, and what does it cost you?

What does better look like? Give us a measurable outcome — time saved, errors reduced, revenue recovered.

What must not break? Existing integrations, data you cannot lose, compliance constraints.

Everything else — stack, architecture, timelines — follows from those answers. When those three are clear, the technical conversation becomes short.