Scope your software before anyone writes a line of code

The scope template

Fill it in yourself, or with whoever will build it. Anything you cannot answer yet is worth knowing now, rather than halfway through the build.

1. 1.The problem

   Software that fixes nothing in particular gets built wrong, then paid for twice.

   • What is going wrong today, in one or two sentences?
   • What does it cost: hours a week, orders lost, errors made, money chased late?
   • Who feels it most?

2. 2.What success looks like

   A goal you can check stops the project drifting.

   • What will be true three months after launch that is not true now?
   • Which number will you look at to know it worked?

3. 3.People and roles

   Who sees what is decided now, not after launch.

   • Who will use it: owners, office staff, drivers, customers?
   • What must each role be able to see and do, and what must they not?
   • How many people in each role, today and in two years?

4. 4.What it must do

   Sorting features by importance is what keeps a first release small and on time.

   • Must have: without these, the first release is useless.
   • Should have: important, but the first release can go live without them.
   • Could have: pleasant, and the first to go if time runs short.
   • Won’t have (this time): written down so nobody assumes it is included.

5. 5.Data

   The records are the business. Moving them is part of the job, not an afterthought.

   • What records exist today (customers, jobs, invoices, stock) and where do they live?
   • What has to be brought across, and how far back?
   • Who checks the moved figures against the originals?

6. 6.Connections to other tools

   Every connection is work, so each one is named and agreed.

   • Which tools must it talk to: email, WhatsApp, payments, accounting, a website?
   • Does each one have an API, and who holds the account?

7. 7.Documents it produces

   Invoices and statements are where mistakes cost money and trust.

   • Which documents: invoices, statements, reports, delivery notes?
   • In which languages, and on whose letterhead?
   • Which tax rules apply (VAT, TRN, withholding)?

8. 8.Where it runs

   Phone, desktop, several sites or no internet: each changes how it is built.

   • Phone, desktop, or both?
   • One office, several branches, or people on the road?
   • Does it have to work without an internet connection?

9. 9.Limits

   Knowing the limits up front stops the scope promising what the budget cannot pay for.

   • Is there a date it must be live by, and why that date?
   • What budget range is realistic?
   • Any rules it has to meet: tax, data protection, industry regulation?

10. 10.Ownership and handover

    You should never need permission to use your own software.

    • Are the code, hosting, domain and accounts in your name?
    • How are backups taken, where are they kept, and has a restore been tested?
    • Who fixes problems after launch, and how fast?

11. 11.Phases and sign-off

    Paying and approving in phases keeps both sides honest.

    • What is in phase one, and what comes later?
    • How is each phase checked and signed off before the next starts?

ERP and CRM selection scorecard

Name up to three options, for example two packages and a custom build. Score each from 1 (poor) to 5 (excellent) on every line, and set how much each line matters to you. The weights shown are a starting point. Changing them is the whole exercise.

How to use them well

• Score with the people who will use the system every day, not only the people paying for it.
• Score packages on a trial with your own real records, never on a demo run on the seller’s sample data.
• For the five-year cost line, run the numbers in the build vs buy calculator first.
• A difference of a few points is a tie. Break it on the criteria with the highest weights.