SunTech SolutionsPublished · SunTech Solutions
Why estimates go wrong before anyone opens a laptop
When a business asks three developers for a quote and gets three numbers that differ by a factor of five, the usual conclusion is that somebody is overcharging. Usually all three priced something different, because the request left most of the decisions to them: one assumed a login for every customer and one assumed none; one priced the connection to the accounting package and one left it for later. The spread is not the developers' judgment. It is the brief's silence.
A brief is not a specification. A specification is what you and a developer write together once you have chosen each other. A brief is one page, in your own words, that lets a stranger price the right thing and ask the right questions. Here is what goes on it.
1. The problem, in one paragraph, without naming a technology
Describe what hurts, not what you think the cure is. "Our quotes take two days because three people have to be asked, and we lose jobs to faster competitors" is a brief. "We need a CRM with a quoting module" is a guess at a solution, and it steers every proposal toward a CRM whether or not that is the cheapest fix. Say what is slow, wrong, lost or typed twice, and roughly what it costs you, in hours or in business.
2. Who uses it, and how often
Count them and describe them. Five office staff all day is a different system from two hundred customers twice a year, and a technician on a phone in a basement is different from a bookkeeper at a desk. The number of users decides the architecture and the hosting; the kind of user decides how much of the budget goes into making the thing obvious rather than merely functional.
3. How it is done today, with the spreadsheet attached
Nearly every process that needs software already runs on something: a spreadsheet, a shared inbox, a paper form, a whiteboard. Attach it. The columns of the spreadsheet are the data model nobody wrote down; the paper form shows which fields are mandatory in practice; the inbox shows who hands off to whom. A developer learns more from one real, slightly embarrassing spreadsheet than from an hour of description, and a brief that hides the current mess hides the job.
4. Must-haves and nice-to-haves, in separate lists
Two short lists, and be strict about the first. A must-have is something without which you would not use the system at all. Everything else is a nice-to-have, including features you are fairly sure you want. The reason to separate them is that a good proposal will offer a first version built from the must-haves alone, and you cannot judge that offer unless you have already said which is which.
5. Where the data comes from, and where it has to go
List every tool the new system would exchange data with: accounting, payment processing, email marketing, the website, a supplier's portal, a barcode scanner. For each, say whether the exchange is a nightly export or a live connection, and whether you already have an account and know the login. Integrations are where estimates diverge most and are often the single largest item, so six names on the brief are worth more than any other line on it.
6. Languages, devices and places
If your staff or customers work in more than one language, say which, and whether both have to be there on day one. Say what devices the system has to work on and where: a warehouse without reliable Wi-Fi is a requirement, not a detail. In Canada, bilingual means English and French for some audiences and English and Chinese for others, and the two are not the same amount of work.
7. The constraints you already know about
A date that matters, such as a season, a trade show or the end of the contract on the tool you are leaving. Rules you have to follow: how long records must be kept, whether data may leave Canada, whether a regulator audits you. Things you already own and will not change: the domain, the accounting package, the email provider. Each of these removes an option from the proposal, which is the point.
8. A budget range, honestly
Businesses hesitate to name a number for fear the quote will rise to meet it. In practice the opposite happens: without a range, a developer has to guess whether you want the version that costs a few thousand dollars or the one that costs fifty, and often prices the one you did not mean. Give a range and say what it is based on, even if that is only "what the workaround costs us in a year". A good developer will tell you what fits inside it and what does not.
9. What done looks like
Write down how you will know the system works, in terms of your business rather than its features. "A quote goes out the same day, from one screen, and the numbers match the accounting package" is a test anyone can run on launch day. Three or four sentences like that are your acceptance criteria, and they prevent the most common end-of-project argument, which is about whether the thing that was built is the thing that was meant.
10. Who decides
Name the person who can answer questions during the build and the person who signs off at the end, and say if they are different. Projects stall when every question goes to a meeting. If the person who knows the process is not the owner, say so, and make sure both have read the brief.
What to expect back
A proposal built on a brief like this should answer the same ten points in its own terms: a fixed scope that lists what is excluded as clearly as what is included; a first version, and what it leaves for later; the assumptions it rests on, such as which connections use an account you already have; who owns the code and the data; a maintenance arrangement after launch; and questions. The questions are the best sign. A developer who reads a good brief and has nothing to ask has not read it.
How to compare two estimates
Compare scope before price. Put the proposals side by side and check that they built the same thing from the same must-haves and the same integrations; if one includes the accounting connection and the other says "phase two", the prices are not comparable until you adjust for it. Then look at ownership, the size of the first version, how progress will be shown along the way, and what maintenance costs. Only then look at the number, and prefer the proposal that explained its assumptions over the one that was merely lower.