How to scope a software project when you are not technical

The most common reason a software project goes wrong is not technical. It is that the people who understood the work and the people who built the software never quite described the same thing to each other, and nobody noticed until delivery.

You do not need technical knowledge to prevent that. You need to describe your own process precisely, which is something you are already qualified to do.

Describe the work, not the software

The most useful thing you can bring to a first meeting is not a feature list. It is a description of what happens today.

Write down one process, end to end, as a sequence of who does what:

A parent comes to the office to pay fees. The clerk looks up the student in the register. The clerk checks whether a concession applies, which is on a printed list in the drawer. The clerk writes a receipt in the receipt book, tears off the counterfoil, and enters the amount in the daily collection sheet. At the end of the day the accountant totals the sheet and compares it against the cash.

That paragraph tells a competent developer more than a twenty-item feature list, because it contains the things a feature list leaves out — the printed concession list, the counterfoil, the daily reconciliation.

Do this for your three or four most important processes. It is a few hours of work and it is the single highest-value thing you can do.

Include the exceptions

The exceptions are where projects break. Every process has them and they are usually not written down anywhere, because everyone involved simply knows.

• What happens when a student joins mid-term?
• What if a parent pays part now and part later?
• Who can override the fee, and what happens then?
• What happens at year end that does not happen any other month?

Write these down. If a vendor's proposal does not account for them, they have scoped a simpler system than the one you need, and the difference will surface as change requests.

Separate needs from wishes

Sort everything into three groups and be honest about it:

1. **Cannot operate without it.** If this is missing on day one, we cannot use the system.
2. **Should have soon.** Real value, but the institution functions without it for a few months.
3. **Would be nice.** Genuinely useful, no urgency.

Insist the vendor prices the first group separately. This does two things: it gives you a smaller, likelier-to-succeed first phase, and it reveals whether the vendor can distinguish essential from decorative — which tells you a lot about how they will behave later.

What to ask for in the proposal

• **A written scope** listing deliverables in plain language, not technical terms
• **A fixed cost** for that scope, and a stated day rate for anything outside it
• **A timeline with intermediate points** where you will see something working
• **What is explicitly not included** — this is the most useful section and the one most often missing
• **The annual maintenance figure**, before you sign the delivery contract
• **What is required from you**, in hours and from whom

The questions that expose a misunderstanding

Ask these of any vendor before signing. The answers tell you whether they listened.

1. **Describe our fee process back to me.** If they cannot, they have not understood it, and no amount of feature agreement fixes that.
2. **What did you find unusual about how we work?** A vendor who has paid attention will have noticed something. "Nothing, it is all standard" means they were not listening.
3. **What is the riskiest part of this project?** Every project has one. A vendor who claims none has either not thought about it or is not telling you.
4. **What will you need from us, and when?** If the answer is "nothing much", the project will stall the first time a decision is needed.
5. **What happens if we are wrong about a requirement halfway through?** There is a right answer — it gets re-scoped and re-quoted — and you want to hear it before it happens rather than during.

The thing worth doing before any of it

Have somebody who does not do the job read your written process and try to follow it. Where they get stuck is where your process is undocumented rather than complex.

Fix that first. It is cheaper than software, and it is the only way to be sure you are asking for the right thing.