Most software projects that run late do not fail in the coding. They fail at the start, when the scope is a two-page list of features that everyone reads differently, and at the end, when nobody agreed what "finished" means. The good news is that both problems are preventable. A well-scoped project is not one with a longer requirements document. It is one where the business and the developer share a clear picture of the problem, deliver in visible steps, and know in advance how work will be accepted and supported. This article sets out a practical structure you can use with any supplier.
Start with the problem, not the feature list
"We need an inventory module with barcode support and reports" is a solution. The problem underneath might be: "We regularly promise delivery dates based on stock that is not actually there." That second sentence is far more useful. It tells everyone what success looks like and lets the team find the simplest way to achieve it.
Before any proposal, write down:
- The problem in one or two sentences, in business terms.
- Who feels it: which roles, how often, at what cost.
- What success looks like: something you could observe or measure after go-live.
- What is out of scope, explicitly. This list prevents more arguments than any other.
Phase 1: Discovery
Discovery is a short, paid phase before the build, usually a few weeks depending on size. Its purpose is to replace assumptions with facts. A good discovery includes:
- Process walk-throughs with the people who do the work, on site where possible.
- Collection of real documents: forms, reports, spreadsheets and sample data.
- An integration list: every system the new software must talk to, and how.
- Simple screen sketches or clickable prototypes of the main flows, reviewed with users.
- A prioritised backlog, split into "must have for first release" and "later".
- Risks and assumptions, written down and owned.
- A phased plan and estimate based on all of the above.
Discovery also tests the working relationship. If the supplier does not ask difficult questions in these weeks, they will not ask them later either.
The cheapest place to change a system is on a whiteboard. The most expensive is in production.
Phase 2: Phased delivery
Break the build into releases that each deliver something usable. The first release should be the smallest version that solves the core problem for real users, not a demo, not a prototype.
For example, a production tracking system might be phased as:
- Order entry and basic status tracking for one product line.
- Floor-level scanning for that line, with daily reports.
- Extension to other lines, plus integration with accounts.
- Dashboards, alerts and buyer-facing reports.
Each phase has its own scope, estimate and acceptance. If priorities change, and they will, you adjust the next phase rather than unpicking the current one.
Demos every two weeks
Work in short cycles, commonly two weeks, and end each cycle with a live demonstration of working software to the business owner and key users. Not slides, not screenshots: the real system, on real or realistic data.
Regular demos do three things:
- They expose misunderstandings while they are still cheap to fix.
- They give the business a steady, honest view of progress.
- They build user familiarity long before go-live, which makes training easier.
For the business, the obligation is to attend, with the right people, and to give clear feedback. A demo nobody attends is a missed checkpoint.
Managing change without losing control
New ideas will appear during demos. That is a good sign. Handle them with a simple rule: every change request is written down, estimated, and either swapped for something of similar size in the current phase or moved to a later one. Scope grows only by decision, never by drift.
Acceptance: define "done" before you start
For each phase, agree acceptance criteria in advance. Good criteria are specific and testable:
- "A store user can receive a roll against a purchase order and print its label in under one minute."
- "The daily report matches the manual count for five consecutive working days."
- "Users without approval rights cannot approve a purchase above the set limit."
Then set an acceptance window: a fixed period of user acceptance testing, run by your people on agreed scenarios, with defects classified by severity. Critical defects must be fixed before sign-off; minor ones can be scheduled. Without this structure, acceptance becomes an open-ended negotiation.
Warranty and support: plan for life after go-live
Software is used for years after it is delivered. Agree these points in the contract, not after the first problem:
- Warranty period. A defined period after go-live during which defects in delivered scope are fixed at no extra cost.
- Support terms. How issues are reported, response times by severity, and working hours.
- Maintenance. Security updates, backups, monitoring and hosting responsibilities.
- Enhancements. How new features are requested, estimated and scheduled.
- Ownership and handover. Who owns the source code and data, and what documentation is delivered.
A scoping checklist
- Is the problem written in business terms, with a measurable definition of success?
- Is there an explicit out-of-scope list?
- Has a paid discovery phase been planned before committing to the full build?
- Is the first release small enough to deliver in a few months and useful on its own?
- Are two-weekly demos scheduled, with named business attendees?
- Is there a written change process?
- Are acceptance criteria and a testing window agreed for each phase?
- Are warranty, support, hosting and code ownership in the contract?
- Is there a named business owner with authority to make decisions quickly?
The last point matters most. Projects slow down when every decision waits for a meeting. A named owner who can say yes or no within a day keeps the whole plan on track.
Where RAED fits
This is how we run our own projects: paid discovery, phased releases, demos every two weeks, agreed acceptance criteria, and a defined warranty and support period, with ownership of code and data agreed in writing from the start.
