Business-first discovery
Every engagement starts with the process and the outcome. Product selection follows the requirement rather than preceding it.
Delivery approach
Nine stages, each with a defined output
Engagements can start at any stage, but no stage is skipped silently. If we are moving straight to build, we will say which assurances you are choosing not to buy.
Lifecycle
From discovery to continuous improvement
Each stage lists the deliverables it produces. If we cannot name the output, the stage does not belong in the plan.
-
Discover
Understand the business process, the constraints and the outcome being sought, with the people who own them.
Process maps Stakeholder map Problem statement Success criteria -
Assess
Establish the current technical and data reality: platform state, integrations, permissions, content condition and readiness.
Current-state assessment Readiness rating Risk register Effort ranges -
Design
Produce the solution architecture, functional design, data and integration model and security approach, with decisions recorded.
Solution architecture Functional design Security design Decision records -
Build
Implement in reviewable increments, favouring configuration and keeping the solution deployable from day one.
Configured solution Automations and integrations Deployment pipeline -
Validate
Functional, integration, accessibility, security and performance testing, with user acceptance run against real scenarios.
Test evidence Accessibility report Defect log Acceptance sign-off -
Deploy
Release through a controlled path with rehearsed cutover, rollback plan and defined hypercare.
Cutover plan Rollback plan Release notes Hypercare model -
Adopt
Support the behaviour change the solution depends on: enablement, champions, communications and reinforcement.
Enablement material Champion network Communication plan Adoption measures -
Operate
Run the solution against agreed service expectations, with monitoring, incident handling and administration.
Runbooks Monitoring Service reporting Administration model -
Improve
Maintain a funded backlog informed by usage, feedback and platform change, released on a regular cadence.
Enhancement backlog Release cadence Usage insight Roadmap review
Governance
Applied throughout, not at the end
Solution architecture
A named architect owns the technical shape of the solution and records the decisions that shaped it.
Security by design
Identity, permission and data protection design are established during design, and reviewed before release.
Platform governance
Environment strategy, policy, ownership and lifecycle are designed alongside enablement rather than after an incident.
Quality assurance
Testing produces evidence across functional, integration, accessibility, security and performance dimensions.
Adoption and enablement
Change activity is planned from design, targeted at specific behaviours, and measured by what people do.
Continuous improvement
Post-launch enhancement is planned and funded, with a backlog owned by a named product owner.
Estimation
Ranges, with the assumptions attached
Effort is estimated with optimistic, most likely and pessimistic values, and contingency applied according to assessed complexity and risk. The assumptions and exclusions travel with the number into delivery, so change control has a baseline to work against.
- Work broken down to a level where the estimate can be challenged
- Three-point estimation with contingency justified by assessed risk
- Assumptions and exclusions recorded as data, not prose in an email
- Estimates revisited at defined points, with variance explained
- Change requests assessed against the recorded baseline