Development Process Guide
A software project moves through discovery, design, build, verification, release and support, and most overruns trace back to a handover between those stages that nobody owned. This guide describes each stage, the decision it ends with, and what a buyer should expect to see before it is allowed to close.
Start your project
Why stages matter more than methods
Teams argue about agile versus waterfall, but buyers are rarely hurt by the label. They are hurt when nobody can say what has been decided, what is still open and who must decide it next. A good process makes those three things visible at all times, whatever the ceremonies are called.
The six stages in order
Discovery
Turns a goal into a testable scope: users, constraints, risks, and a first view of cost and sequence. Ends with a signed-off outline of what will and will not be built.
Design
Produces the interaction design and the technical design together, so that nothing is drawn that cannot be built within the constraints found earlier.
Build
Delivers working software in short increments, each demonstrated to the people who will use it, with automated tests written alongside the code.
Verification
Confirms the product meets written acceptance criteria, including security, performance and accessibility checks agreed at the start.
Release
Moves the product into use with a rehearsed deployment, a rollback plan and a named owner on both sides.
Support
Covers fixes, monitoring and planned improvement after launch, under terms agreed before the build begins.
What should exist before each stage closes
- Discovery: a written scope, a prioritised list of outcomes, a risk register and an agreed way to handle change.
- Design: approved flows, a data model, an architecture diagram and a list of external dependencies.
- Build: a working increment every cycle, a visible backlog and test results that anyone can read.
- Verification: a traceable list of acceptance criteria with a pass or fail against each.
- Release: a deployment runbook, a rollback procedure and a communications plan for users.
- Support: an agreed contact route, a defined way to classify issues and a handover of documentation.
Share the outcome you need and Renvric will recommend the smallest useful next step.
Where projects usually go wrong
The common failures are quiet ones. Acceptance criteria are never written, so completion becomes a matter of opinion. A third-party integration is assumed to be simple until the build reveals an undocumented limit. A decision-maker is absent from demonstrations, and a change they would have rejected is discovered at launch.
Each is cheaper to prevent than to repair, which is why Renvric favours short written decisions over long meetings.
Roles across the stages
Client
Owns the outcomes, supplies a decision-maker with authority, and responds to questions within the agreed time.
Renvric
Owns delivery of the agreed scope, reports progress honestly and raises risks as soon as they are known.
Shared
Change control, acceptance, and the choice of when a stage is complete.
A worked example
Consider a logistics firm replacing a spreadsheet-based dispatch process. Discovery might establish that three depots work differently, so the first release serves one depot only. Design confirms the route data comes from a third-party service with rate limits. Build proceeds in fortnightly increments, each shown to a dispatcher. Verification includes a rehearsal with real data, and release is timed for a quiet week.
Related areas to explore: Business Process Automation, Intelligent process automation and Document process automation.
Common questions
Who is this guide for?
It is for buyers and sponsors of software projects who want to know what a sensible process looks like without becoming engineers. Technical leads can use it as a checklist when comparing the process described by different suppliers against what they expect to see.
What do I need to bring to start?
A statement of the outcome you want, who will use the product, any fixed dates or regulations, and the systems it must work with. A rough budget range is useful. Missing detail is normal; surfacing it is the purpose of discovery.
Does the process change for small projects?
The stages stay, but the artefacts shrink. A small project may have a scope of a couple of paragraphs, a single design review and a short acceptance list. What should never be dropped is written acceptance criteria and a named person who can say yes.
Is this agile or waterfall?
Neither label is the point. Discovery and verification are planned up front, while build proceeds in short increments with working software shown regularly. The test of any process is whether you can see progress, decisions and risks at any moment without asking for a special report.
Who can answer questions about applying it?
Write to info@renvric.com with a short description of your project and the stage you are at. A delivery lead can say what artefacts you should expect, or arrange a consultation to review a proposal you have received from another supplier.
Keep exploring
If you already have a process, use the stages as a checklist and note where an artefact is missing. If you do not, a short discovery is usually the cheapest way to produce the first three.