Planned, tested,
approved, supported.
How work moves from a requirement to a running system: the development methodology, the quality checks before release, the change control around production, and the support process once it is live.
Six phases,
working software every two weeks.
Each phase ends with something you can review and approve, so decisions are made early and in writing. Build work runs in two-week iterations with a demonstration at the end of each.
- 01
Discovery
Stakeholder interviews, review of the current systems, data and constraints, and agreement on what success looks like.
Output: Requirements, risks and a delivery plan you approve
- 02
Design
Architecture, data model, integrations, security controls and user experience, reviewed with your technical and business owners.
Output: Design documents and clickable prototypes
- 03
Build
Work in two-week iterations. Each ends with a demonstration on a staging environment and a reprioritized backlog.
Output: Working software every two weeks
- 04
Test
Automated and manual testing, accessibility and performance checks, security review and your user acceptance testing.
Output: Test results and written sign-off
- 05
Deploy
A scheduled release through your change process, with a rollback plan and support on hand during and after go-live.
Output: Go-live, runbooks and handover
- 06
Support
Ongoing maintenance, security updates and improvements under a support agreement, or a full handover to your team.
Output: Service reports and a maintained system
Nothing ships
on trust.
- Definition of doneA change is done when it is reviewed, tested, documented and demonstrated, not when the code is written.
- Automated testsUnit, integration and end-to-end tests run on every change in continuous integration; a failing test blocks the release.
- Every screen sizeInterfaces are checked at desktop, tablet and phone widths before they ship.
- AccessibilityPublic and staff-facing interfaces are built and tested against WCAG 2.1 AA.
- Performance and securityPage speed, query performance and common security weaknesses are checked before release, not after complaints.
- User acceptanceYour users test on staging against agreed scenarios, and nothing goes live without your sign-off.
Every production change
approved and reversible.
Where you run a change advisory board, we bring our changes to it. Where you do not, this is the process we follow.
- 01
Request
Any change to scope, or to a production system, starts as a written change request: what, why and who asked.
- 02
Impact assessment
We assess the effect on scope, cost, schedule, security and other systems, and how the change would be reversed.
- 03
Approval
Your named change authority approves or declines. Nothing proceeds on a verbal request.
- 04
Scheduled release
Approved changes go out in an agreed window, tested on staging first, with the rollback steps written down.
- 05
Review
After release we confirm the change worked as intended, and record it in the change log you can see.
Three kinds of change
- StandardPre-approved, low-risk and routine, such as a password reset or adding a user. Logged, without a separate approval each time.
- NormalAssessed and approved through the steps above before it is scheduled.
- EmergencyNeeded to restore service or contain a threat. Approved by your on-call authority, documented and reviewed the next business day.
Triaged by severity,
measured every month.
| Severity | What it means | How it is handled |
|---|---|---|
| S1 Critical | A business-critical service is down or a security incident is in progress, with no workaround. | Worked continuously, around the clock, with your contacts updated at agreed intervals until resolved. |
| S2 High | A major function is degraded or a group of users is blocked; a workaround may exist. | Worked as the top priority during business hours, and after hours where your agreement covers it. |
| S3 Normal | A single user or non-critical function is affected. | Worked in order of receipt during business hours. |
| S4 Request | A question, a small change or a planned task. | Scheduled with you, or handled as standard change. |
- Three ways inPhone, email and a support portal, or your own ticketing system if you prefer we work in it.
- Targets in writingResponse and resolution targets for each severity are set in your agreement's service level schedule, and reported against monthly.
- Root causeRepeat incidents and every S1 get a root-cause review, so the same failure is fixed once.
- Monthly reportingTickets, targets met, patch and security status, and the trends behind them, in a report your leadership can read.
The rest of how we operate.
Tell us what
needs building.
We will come back with a phased plan, the testing and change approach for your environment, and a fixed price per phase.