How to Scope a Custom Software Project

The business problem

Start with the problem, not the solution. In two or three sentences:

• What is happening today that is unacceptable?
• Who is affected?
• What would be different if the problem were solved?

A scope that begins with “we want a portal” is harder to build against than a scope that begins with “our clients currently email requests that we track in a spreadsheet, and we lose about one in ten because it never gets acknowledged.”

Users and stakeholders

For each type of person who will use the software, document:

• Their role in the organization.
• What they will use the software to do.
• How often they will use it.
• What device they will use it on.
• Their level of technical comfort.

If the users are external (clients, vendors, contractors), also document how they will get access and how support requests from them will be handled. Name the internal stakeholders who approve decisions as well — not just the people who use the system day to day.

The current process

Describe how the work is done today, even if the answer is “it is not done, or it is done informally.” A prior workflow audit pays off here — attach it to the scope document if one exists.

Two failure modes to avoid:

• Describing an idealized version of the process rather than the real one.
• Describing the process only from the perspective of the person who reports on it, rather than the people who do it.

The desired outcomes

State what the software must produce for the project to be considered successful:

• Concrete outputs (records, documents, reports, notifications).
• Measurable improvements where they can be committed to honestly (for example, “requests are acknowledged within one business day”).
• Any regulatory or contractual outputs that must be preserved.

Avoid outcomes that cannot be measured or verified. “The team is happier” is a real goal but a poor acceptance criterion. Reviewing how Northbridge scopes and delivers work early helps calibrate what outcomes a scoped engagement can commit to.

Must-have versus optional features

For every proposed feature, mark it as:

• Must-have. The software cannot be considered complete without it.
• Optional. Desirable but not required in the first version.
• Future. Not in scope for this engagement.

Ruthless triage here is the single most valuable scoping activity. Every “must” adds cost and time. If everything is a must, nothing is a priority.

Integrations

List every other system the software must read from or write to, and confirm:

• Whether the integration is required at launch or later.
• What the direction of data flow is.
• Who owns the other system.
• Whether the other system exposes a supported API.

Integration decisions often decide the feasibility of the whole project. Do not defer them. The companion API integration planning guide covers what to confirm before committing.

Data migration

If the software will replace or supplement an existing system, document:

• What data must be migrated on day one.
• What data can be migrated later or archived.
• The current state of the data (clean, messy, duplicated).
• Who is responsible for cleaning it, if cleaning is needed.

Assume data migration takes longer than expected. It almost always does.

User permissions

List the roles the software will support and, for each role, what it can and cannot do. Even a small internal tool usually has at least three: administrator, editor, viewer. Larger systems have more, and the permission matrix should be written down before design begins.

Security considerations

At the scoping stage, document:

• What kinds of data the software will handle.
• Any regulatory constraints (privacy law, sector-specific rules).
• The organization's baseline security requirements (single sign-on, audit logging, access review).
• Any explicit exclusions (“this system will not handle payment card data”).

Security decisions belong in the scope, not in a separate conversation after the design is fixed. Northbridge documents its own posture in the trust practices.

Reporting

Reporting is often underscoped and expensive to add later. For each report or dashboard, document:

• The audience.
• The questions it must answer.
• The data sources.
• The refresh frequency.
• Any export requirements.

If the reporting requirements are vague, mark them as future scope and build the base system first.

Acceptance criteria

For each must-have feature, write acceptance criteria in the form “when X happens, the system does Y, and someone can verify it by Z.” Acceptance criteria are the contract between the business and the build team. They turn subjective satisfaction into objective verification.

Vague acceptance criteria (“the feature works well”) produce disputes. Specific criteria (“a request submitted through the client form appears in the internal dashboard within one minute and triggers an email to the assigned owner”) produce agreement.

Delivery phases

Break the project into phases with a clear definition of what is in each. The first phase should be small enough to deliver in weeks, not months, and should include the smallest useful version of the system. Later phases can add features that are valuable but not blocking.

Phased delivery reduces risk. It also gives everyone a chance to see the system in use before committing to features that turned out to be less important than they seemed on paper.

Dependencies

Document what the project depends on outside the build team's control:

• Access to systems and administrative accounts.
• Availability of subject-matter experts for questions and reviews.
• Timely decisions from stakeholders.
• Third-party licenses, subscriptions, or hosting arrangements.

Dependency delays are the most common cause of missed timelines. Naming them up front helps everyone plan.

Exclusions

An underrated section. Explicitly document what the project will not do. Examples:

• “This system will not replace the accounting system.”
• “This system will not include a native mobile application in the first phase.”
• “This system will not process payments.”
• “This system will not include public marketing pages.”

Exclusions prevent scope creep by making it obvious when a new request is outside the agreement.

Change control

Every real project changes. Agree in advance how changes will be handled:

• Who can propose a change.
• Who approves it.
• How its impact on scope, cost, and timeline is documented.
• How the schedule is adjusted when a change is approved.

Change control is not bureaucracy. It is the mechanism that keeps a project honest as it evolves.

Ownership and maintenance

Custom software does not end at go-live. Before building, agree who owns the system afterwards, how it will be monitored, how often it will be reviewed, and what the budget is for ongoing changes. A system without a named owner will decay regardless of how well it was built.

Documentation and handoff

Plan the handoff from the beginning: user documentation for the people who will run the system, administrative documentation for the people who will maintain it, and a short operational runbook for the common failure cases. Handoff is a phase, not a courtesy at the end.

What a good scope document looks like

Short is better than long. A good scope document is usually:

• Twenty to forty pages, not two hundred.
• Written in the language of the business, with a technical appendix if needed.
• Reviewed and signed off by both the business owner and the build lead.
• Attached to any proposal or contract, so both sides know what “the project” means.

If the scope document takes longer to write than the smallest useful phase would take to build, something has gone wrong.

A reasonable next step

Northbridge scopes custom software projects through structured proposals for larger engagements and through fixed-scope products such as the Workflow Review for narrower questions. The right entry point depends on how well the problem is understood today. When it is understood, request a proposal is usually the fastest path.