Understand how your engagement will move from an agreed requirement to delivery and handover. Each stage has defined responsibilities, evidence to review and a decision about what happens next.
Company
How we plan, deliver and hand over technology work
Understand how your engagement will move from an agreed requirement to delivery and handover. Each stage has defined responsibilities, evidence to review and a decision about what happens next.
How we can help
The principle
The framework is the gates, not the phases.
Agree the evidence needed to complete each stage before that stage begins. Record who accepts it and how unresolved risks or changes will be handled. The framework can be scaled to the engagement while retaining clear ownership, acceptance criteria and handover.
The model
Six phases, each with what has to be true to leave it.
The activities are ordinary and deliberately so. The exit condition is the part that constrains us.
01 Frame — context and priorities
Establish the business outcome, the stakeholders, the constraints and the decisions that genuinely need making. Exit condition: the problem, the intended outcome and the known unknowns are written down and agreed by the people funding the work, including the assumptions we have not been able to test.
- Define the outcome and how it will be judged
- Map users, services and operating context
- List assumptions, dependencies and evidence gaps explicitly
02 Design — target state and roadmap
Translate the agreed priorities into architecture, operating model, scope and sequence. Exit condition: a target state and a prioritised roadmap that a different competent team could pick up and act on, with acceptance criteria and controls agreed rather than deferred.
- Define target capability and the experience it supports
- Agree design principles, controls and non-functional requirements
- Sequence the roadmap against dependencies and value
03 Mobilise — team and governance
Establish ownership, ways of working, measures and decision routes before delivery volume arrives. Exit condition: roles, decision rights, thresholds and escalation timings are agreed in writing, and environments, access, backlog and delivery controls are ready rather than promised.
- Confirm roles, responsibilities and decision rights
- Set reporting that leads with decisions, risks and dependencies
- Prepare environments, access, backlog and delivery controls
04 Deliver — incremental execution
Build, configure, migrate or implement in increments small enough to be judged on evidence. Exit condition, per increment: it meets its acceptance criteria and its controls in an environment that resembles production, demonstrated rather than reported.
- Demonstrate working increments on a predictable cadence
- Validate against acceptance criteria agreed before the build
- Keep risks, dependencies and decisions visible as they move
05 Adopt — transition and readiness
Prepare users, operations and support teams to own the change. Exit condition: the receiving teams can run it without us — evidenced by them doing so through a defined period, rather than by a completed training register.
- Support communication, role readiness and service transition
- Complete operational handover including runbooks and known issues
- Measure early adoption and resolve what the first weeks surface
06 Improve — continuous learning
Use evidence from live operation to prioritise what comes next. Exit condition: none — this is the phase that does not close, and the point at which continuing with us should be a live choice rather than a default renewal.
- Review outcomes against what was agreed in Frame
- Address technical and process debt deliberately
- Maintain a governed improvement roadmap with named owners
Proportion
Where the model compresses, and where it must not.
A six-phase framework applied at full weight to a six-week piece of work is governance theatre, and you are charged for it. These are the parts we scale down and the parts we hold constant.
Scales with the size of the work
Reduced or merged on smaller engagements without materially increasing risk.
- Frame and Design merge into one short phase where the problem is well understood and bounded.
- Documentation reduces to decisions and interfaces rather than a full artefact set.
- Governance forums reduce in number and frequency, matched to how often decisions actually arise.
- Roadmaps shorten in horizon rather than being maintained speculatively.
- Reporting becomes a short written update rather than a pack and a meeting to present it.
Does not scale down
Held constant regardless of engagement size, because these are what keep the work recoverable.
- One named accountable lead, on the smallest engagement as much as the largest.
- Decision rights and escalation thresholds agreed before work starts.
- A decision record kept as the work proceeds, and handed to you.
- Acceptance criteria agreed before an increment is built, not negotiated at the demonstration.
- Security, privacy and accessibility handled inside the increment rather than deferred to a hardening phase.
- Exit and transition planned at mobilisation, so leaving us is never an event we control.
Principles
The rules the framework is built on.
Stated as rules rather than aspirations, because each one is refusable — a client can decline any of them, and then at least both sides know where they stand.
- Business outcomes and decision quality come before technology activity, including our own.
- Accountability, acceptance criteria and escalation routes are made explicit before delivery volume arrives.
- Security, privacy, accessibility and operability are addressed inside delivery rather than in a phase at the end.
- Progress is demonstrated in working increments wherever the nature of the work permits it.
- Documentation exists to support decisions and operation; where it stops doing that, it stops.
- The model adapts as evidence changes, and the change is recorded rather than absorbed quietly.
Reasonable questions
What a delivery lead usually asks about this.
Do you insist on agile, or on any particular methodology?
No. The framework is deliberately methodology-neutral, because the binding constraint is usually organisational rather than a choice between Scrum and stage gates. Where you already run a delivery method that works, we operate inside it.
What we do hold to is the gate discipline described above and the decision record. Both are compatible with iterative and stage-gated delivery alike.
We already have a delivery framework. Does yours replace it?
It should not. Where you have a working framework, ours becomes a way of describing what we owe you inside yours — the exit conditions we hold ourselves to, and the decisions we record.
Two competing frameworks on one programme is a real failure mode. The resolution should be that the client's governs, unless there is a specific reason it cannot.
What happens when a phase gate is not met?
The engagement lead says so in writing, with the three options set out: extend, reduce scope, or proceed with the gap recorded as an accepted risk with a named owner and a review date.
The decision is yours. What will not happen is the phase closing quietly with the gap carried forward, which is the thing this discipline exists to prevent.
Does this apply to Workforce Solutions engagements as well?
In a reduced form. Where we are providing capacity rather than owning an outcome, the phases compress considerably — but the constants in the right-hand column above still apply: a named contact, agreed decision rights, and a defined transition when the engagement ends.
Where an engagement combines delivery and hired capacity, both sit under the same lead and the same plan rather than being coordinated by you.
How does this interact with the commercial model?
Directly. The phase determines which commercial structure is sensible: framing and design work is poorly suited to fixed price, and a well-specified increment is poorly suited to open-ended time and materials.
The available structures, and how change is priced once work is under way, are set out on the engagement and pricing page.
07
Evaluate the framework through the proposed work
In proportion
Discuss how the stages apply to your requirement, who will lead them and what evidence will be available at each review. Your existing delivery method can remain the governing framework, with MENTARA responsibilities defined inside it.
One partner. One plan. Measurable outcomes.