How to Scope a Software Project Without Technical Knowledge

Begin with a short description of the current situation. Explain what people do today, which tools they use, where delays or mistakes occur, and what the business is unable to do.

Avoid making the solution the problem statement. “We need a mobile app” is a proposed format. “Customers cannot see service progress without calling us” is a problem that may be solved through a portal, notifications, or another approach.

Include why the project matters now: growth, customer demand, operational cost, compliance, a new business model, or limitations in existing software.

List each user group and the outcome they need. Customers may submit requests and check status. Employees may process work. Managers may assign, approve, and report. Administrators may configure access and settings.

Choose the primary user for the first release. A product can support several roles, but one workflow should usually anchor the scope.

Describe device and environment: desktop office, mobile field work, public kiosk, weak connectivity, multiple languages, assistive technology, or time-sensitive customer use.

Write the process as a sequence. What starts it? What information is collected? Who acts next? What decisions occur? What can go wrong? What marks completion? What record or notification is produced?

Use a real example and include exceptions. For a property enquiry: visitor selects a listing, submits contact details, lead is created, assigned, qualified, matched with options, scheduled for viewing, and marked won or lost.

A simple flowchart, numbered steps, or screen sketches are sufficient. The goal is shared understanding, not formal notation.

Rules include required fields, calculations, assignment, deadlines, approval thresholds, status changes, notifications, eligibility, and visibility. Explain them with examples.

List the information created or used: customer details, files, inventory, prices, messages, payments, locations, employee records, or reports. Identify sensitive data and who should see it.

Do not design the database. Describe the business meaning and relationships. For example, one customer can have multiple projects, and each project can have multiple tasks and files.

A must-have is necessary for the core user to complete the main outcome, for the business to operate safely, or for the main hypothesis to be tested. Everything else should be challenged.

Prioritise complete workflows over isolated features. It is better to support one request from submission to completion than to build several disconnected dashboards and settings pages.

Use categories such as first release, next release, later, and not planned. Record why each item is placed there. This helps prevent scope growth during design and development.

Acceptance criteria state the observable behaviour required for a feature. They can be written in plain language: “When an administrator assigns a request, the selected employee can see it in their active queue and receives a notification.”

Include failure and permission behaviour. What happens when required information is missing, an external service fails, or an unauthorised user attempts the action?

Good acceptance criteria improve estimates, reviews, testing, and handover because both sides understand the expected result.

Constraints may include budget, deadline, existing technology, hosting preference, supported devices, legal requirements, languages, branding, internal skills, or a customer commitment.

Dependencies include access to APIs, data, third-party approvals, content, subject-matter experts, hardware, payment providers, and stakeholder decisions. Identify who owns each dependency and when it is needed.

Unresolved dependencies should appear as risks or assumptions in the estimate rather than being silently ignored.

Some requirements describe how the product should operate rather than a visible feature. These include security, privacy, performance, availability, backups, accessibility, audit logs, browser support, data retention, and expected scale.

You do not need to prescribe the technical solution. Explain the business expectation: “The service must remain usable during business hours,” “customers must not see another customer’s data,” or “managers need a record of approvals.”

Quality requirements can materially change architecture and cost, so discuss them before estimates are final.

A useful project brief can be concise. Include the problem, goals, users, workflow, first-release priorities, data, roles, integrations, constraints, success metrics, examples, and open questions.

Attach existing spreadsheets, forms, reports, screenshots, brand assets, and sample data. Real artefacts reduce ambiguity more than elaborate business language.

Ask the developer to convert the brief into user flows, wireframes, architecture decisions, delivery phases, risks, assumptions, and an estimate.

Do not copy a competitor’s complete feature list. Their product may serve different users, scale, contracts, and history. Do not specify technology because a framework is popular unless you have a real organisational constraint.

Do not leave the budget and deadline unspoken. A developer cannot make sensible trade-offs without knowing the boundaries. Do not treat every stakeholder request as equally important.

Finally, do not expect the first scope to be perfect. Discovery should expose assumptions and refine the plan before expensive development begins.