Approach · The Omnexa Method
A clear route from uncertainty to a working system.
The six-stage Omnexa Method
Phase 01: Understand
Identify business goals, users, processes, risks and technical constraints.
- Key activities
- Stakeholder interviews
- Process walk-throughs
- Review of systems, data and contracts
- Client involvement
- Access to the people who do the work
- Existing documentation and system access
- Main deliverables
- Findings summary
- Current-state maps
- Initial risk list
Decision gate — Is the problem understood well enough to define a first release?
Phase 02: Define
Turn findings into priorities, requirements, scope and measurable outcomes.
- Key activities
- Prioritization workshops
- Requirement and acceptance writing
- Outcome definition
- Client involvement
- A decision-maker to settle priorities
- Agreement on success measures
- Main deliverables
- Prioritized backlog
- Scope statement
- Success criteria
Decision gate — Do we agree what is in, what is out and how success will be judged?
Phase 03: Design
Plan the experience, system architecture, data flows and delivery sequence.
- Key activities
- Interface and journey design
- Architecture and data modelling
- Delivery sequencing
- Client involvement
- Feedback on prototypes
- Confirmation of integration access
- Main deliverables
- Prototypes
- Architecture record
- Delivery plan and estimate
Decision gate — Is the design buildable, affordable and approved?
Phase 04: Engineer
Build in focused cycles with demonstrations, testing and visible progress.
- Key activities
- Short delivery cycles
- Automated testing
- Regular demonstrations
- Client involvement
- Attendance at demonstrations
- Timely answers to open questions
- Main deliverables
- Working increments
- Test results
- Release notes
Decision gate — Does the system meet the agreed acceptance criteria?
Phase 05: Introduce
Prepare data, teams and infrastructure for a controlled release.
- Key activities
- Data migration rehearsal
- User training
- Release and rollback planning
- Client involvement
- Data owners for validation
- Users available for training
- Main deliverables
- Migrated data
- Training material
- Go-live checklist
Decision gate — Are people, data and infrastructure ready for go-live?
Phase 06: Improve
Monitor performance, resolve issues and evolve the system over time.
- Key activities
- Monitoring and support
- Usage review
- Enhancement planning
- Client involvement
- Feedback from users
- Input on next priorities
- Main deliverables
- Service reports
- Improvement backlog
- Maintained documentation
Decision gate — What should the next cycle of improvement address?
The method in practice
01
How discovery works
Discovery is a short period of structured listening. We talk to the people who sponsor, use and support the system, watch the current process where possible and review the systems and data involved.
- Interviews and working sessions, scheduled around your teams
- Walk-throughs of real tasks, including workarounds
- Review of existing systems, integrations and documentation
- A written findings summary you can share internally
02
How scope is defined
Scope is written down in plain language before a build is estimated. Each requirement has an owner, a priority and an acceptance condition, so everyone can see what is included and what is deliberately left for later.
- Prioritized backlog with must-have and later items
- Explicit list of what is out of scope
- Assumptions and dependencies recorded
- Success criteria agreed with the decision-maker
03
How design decisions are documented
Significant choices — architecture, data ownership, third-party services, security trade-offs — are captured in short decision records. They explain the options considered and why one was chosen, so the reasoning outlives the conversation.
- Lightweight architecture decision records
- Interface designs linked to the requirements they satisfy
- Data model and integration diagrams kept current
- Decisions that need your approval flagged clearly
04
How progress is demonstrated
Engineering runs in focused cycles. Each cycle ends with a demonstration of working software in a shared environment, not a slide describing it, followed by a short written summary.
- Regular demonstrations to stakeholders
- Access to a test environment between demos
- Written cycle summaries: done, next, risks
- Open questions tracked with an owner and date
05
How quality is verified
Quality is checked continuously. Automated tests run on every change, code is reviewed by another engineer and acceptance is confirmed against the criteria agreed during scoping.
- Automated unit, integration and end-to-end tests
- Peer code review on every change
- Accessibility and security checks during development
- User acceptance testing with your team
06
How releases are handled
Releases are planned and rehearsed. Data migration is practised in advance, a go-live checklist is agreed and a rollback route exists before anything reaches production.
- Release checklist and owner for each step
- Migration rehearsal with validation
- Rollback plan written before go-live
- Post-release monitoring and a short review
07
How ongoing support works
After launch, systems need care. Support is agreed in writing — response routes, priorities, maintenance rhythm and how improvements are scheduled — and reviewed regularly.
- Agreed response routes and priorities
- Planned maintenance and updates
- Monthly review of incidents and improvements
- Documentation kept current as the system changes
08
What clients need to provide
Good outcomes depend on a few things only you can provide. We keep requests focused, and we say early if a dependency is putting the timeline at risk.
- A decision-maker who can settle priorities
- Time from people who do the work being changed
- Access to systems, data and existing documentation
- Timely feedback at demonstrations and decision gates
09
How changes in scope are managed
Priorities change, and that is normal. When new needs appear we describe the change, its effect on time and cost and the options — swap, add or defer — so you can decide with full information.
- Written change notes with impact
- Options to swap, add or defer work
- No change proceeds without your approval
- Backlog and plan updated so the record stays accurate
Reference
The Omnexa roadmap sheet
| Stage | Purpose | Deliverables | Decision gate |
|---|---|---|---|
| 01Understand | Identify business goals, users, processes, risks and technical constraints. | Findings summary, Current-state maps, Initial risk list | Is the problem understood well enough to define a first release? |
| 02Define | Turn findings into priorities, requirements, scope and measurable outcomes. | Prioritized backlog, Scope statement, Success criteria | Do we agree what is in, what is out and how success will be judged? |
| 03Design | Plan the experience, system architecture, data flows and delivery sequence. | Prototypes, Architecture record, Delivery plan and estimate | Is the design buildable, affordable and approved? |
| 04Engineer | Build in focused cycles with demonstrations, testing and visible progress. | Working increments, Test results, Release notes | Does the system meet the agreed acceptance criteria? |
| 05Introduce | Prepare data, teams and infrastructure for a controlled release. | Migrated data, Training material, Go-live checklist | Are people, data and infrastructure ready for go-live? |
| 06Improve | Monitor performance, resolve issues and evolve the system over time. | Service reports, Improvement backlog, Maintained documentation | What should the next cycle of improvement address? |
Use your browser’s print dialog to save this page as a PDF.
START A CONVERSATION
Build a technology environment that works as one.
Tell us what you are creating, improving or replacing. Omnexa will help translate it into a clear technical direction.