How To Write A Project Brief That Produces A Realistic Quote

Start with the problem you are solving, not your preferred technology. What kind of user will use the system, how often, and what happens today? An estimator who grasps the purpose can propose an alternative that costs less; one who only sees the requirements as given prices exactly what you asked for.



Describe the scope as concrete flows: who does what, and what happens next. Just as important, write down what you are not building. An explicit exclusion list removes more disagreement later than almost anything else in the document. Indicate as well which parts are firm and which are still open — the difference changes the price, and concealing the open questions helps nobody.



Set out your constraints. The list covers the platforms and services involved, existing databases and their quality, regulatory obligations, user volumes, supported browsers or hire php unit testing developers devices and any technology you are committed to. If there is a hard date, say what depends on it: a hire dedicated development team can often rearrange the plan to meet it, but not if the date is a secret.



Say what done means feature by feature. Clear acceptance criteria need not use formal language: a plain-language note setting out the expected behaviour is sufficient. That one addition shortens the review at the end dramatically and removes the usual argument at handover.



One last thing, say what you expect back. Require a task-level breakdown, the assumptions behind each number, the main risks and a low number and a high number. Take a broad range as useful information rather than evasion: it usually points to where your description is thin. Then tighten that section and ask for a new estimate — the second estimate will be far closer to reality.