MENTARA
Company

Six phases, and the gate at the end of each one.

Every firm has a six-box delivery diagram. What differs is what must be true before a programme leaves each phase, and who has authority to say it is.

What this page is for

Delivery methodologies are close to interchangeable at the level of the diagram. Frame, design, mobilise, deliver, adopt, improve — or discover, define, build, run — the shape is common industry property, and no supplier should claim credit for it.

The differences that matter sit between the boxes: what must be demonstrably true before work moves on, who is empowered to declare it true, and what happens when it is not. Those decide whether a programme is still recoverable in month eight, and they are usually the parts left out of a framework page.

So this describes the gates as well as the phases, and the section after it sets out where the model compresses for smaller work and where it deliberately does not.

The principle

The framework is the gates, not the phases.

A phase that ends because the calendar says so has not ended. It has been abandoned part-way, with its unresolved questions carried silently into the next one. Most programmes that fail visibly in month eight actually failed at an earlier gate that nobody was empowered to hold shut.

MENTARA runs a flexible framework rather than a fixed methodology. On its own that is a weak claim — every firm says it. The specific commitment is this: each phase has an exit condition agreed before the phase begins, the exit condition is written in terms that can be evidenced rather than asserted, and the engagement lead named in your proposal is the person who declares it met or not met.

Where an exit condition is not met, there are three legitimate options: extend the phase, reduce the scope, or proceed knowingly with the gap recorded as an accepted risk that has a named owner and a review date. The decision is yours in every case. The option not available is closing the phase quietly and carrying the gap forward unrecorded, because that is the specific mechanism by which a programme becomes unrecoverable without anyone noticing.

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.

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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

The framework is not the reason to choose a supplier.

In proportion

Every competent firm can produce a diagram like this one, and a good delivery lead inside your own organisation could run the model without us. It is published so you can see how we intend to work before you commit — not because the phases are proprietary, which they are not.

The part actually worth evaluating is narrower: who holds the gate, whether they are senior enough to hold it shut against commercial pressure, and whether the decisions get written down as they happen. All three are answerable in a conversation.

See how engagements are priced

Describe how your programme is organised today.

Share the business context, constraints and expected outcome. MENTARA will identify the relevant accountable route.

One partner. One plan. Measurable outcomes.