How To Write A Project Brief That Gets You An Accurate Estimate

Start with the problem you are solving, not a list of screens. Which people will use this, with what frequency, and what does the process look like without it? A vendor who knows what you are trying to achieve often proposes an alternative that costs less; one who only sees a list of screens prices the list as written.



Describe the scope as concrete flows: a walk through each important path. Equally important, write down what you are not building. An explicit list of exclusions prevents more friction at delivery time than the rest of the brief combined. Mark too which items are decided and which may still change — estimators price uncertainty, and pretending everything is fixed helps nobody.



List the constraints. These include the platforms and services involved, existing databases and their quality, regulatory obligations, traffic expectations, target platforms and stacks you cannot change. If there is a hard date, say what depends on it: a team is usually able to cut the right scope to meet it outsourcing services, provided they hear about it early.



Write down what the word done means for the important items. Clear acceptance criteria do not need formal language: a short list describing the expected behaviour will do. This one section reduces acceptance testing considerably and best aso service closes off the usual argument at handover.



Finally, state what you want in the response. Require a breakdown by feature or module, a written list of assumptions, whatever the team considers risky and an optimistic and a pessimistic figure. Read a wide range as a signal about the brief: it normally identifies where your description is thin. From there rewrite that part and ask again — the next version tends to be much more reliable.