You have a business problem, a budget and a deadline — but what will you have at the end, and how would you prove it? FORT is Cooper Agile's answer: a structure that turns a problem into an outcome you can inspect, test and keep.

FORT has four stages. FRAME defines the problem, baseline, constraints and acceptance criteria. ORCHESTRATE assembles the people, systems and tools. REALISE builds, integrates and tests the agreed capability. TRANSFER deploys it appropriately, documents it, trains your people and hands it over. A FORT is a typically two-week delivery cycle; larger programmes need several linked FORTs. That is a deliberate constraint: a full enterprise transformation does not fit in a fortnight, whatever a method claims.

FRAME: define before you build

FRAME is where the project earns credibility. Before anything is built, the team writes down:

  • The problem, in business terms, and the workflow or outcome it affects.
  • The baseline — how the process performs today, so improvement is provable later.
  • The constraints — budget, time, systems that cannot change, compliance boundaries.
  • The acceptance criteria — the written conditions for calling the work done, agreed with the outcome owner.

The discipline matters because ambiguity found in week one costs days; found in week six, it costs months. FRAME is also where scope honesty lives: if the problem cannot be bounded to one cycle, the first FORT's deliverable is a sharper definition, not a half-built system.

ORCHESTRATE: assemble people, systems and tools

ORCHESTRATE turns the FRAME into a working arrangement. Who is needed, from our side and yours? Which systems does the work touch, and what access and approvals are required? Which tools and services fit the constraints and your existing estate? ORCHESTRATE also sets how decisions are made during REALISE: who approves a scope question in day three, and how fast. The trade-off is preparation time: a day or two spent orchestrating feels slow, and beats mid-cycle improvisation.

REALISE: build, integrate, test

REALISE is the visible part: building the capability, integrating it with your systems, and testing it against the acceptance criteria — not a vague sense of "working". Progress is shown with working software, not status slides. Because the acceptance criteria were agreed in FRAME, "are we done?" has an answer, not a negotiation. Where reality disagrees with the FRAME, that surfaces as a decision with a traceable record.

TRANSFER: deploy, document, train, hand over

TRANSFER is what makes the outcome durable. The capability is deployed appropriately — a staged rollout, parallel run, or human-in-the-loop start, depending on risk. Documentation is written for the people who will operate the work; training happens with real users on the real system. Handover means a named person on your side can run, extend and troubleshoot the outcome without us in the room; if not, TRANSFER is not finished.

The governance model in plain language

Underneath the stages sits a chain every decision and artefact must answer to:

  • Intent — what outcome we agreed to pursue.
  • Behaviour — what it should do to serve that intent.
  • Work — the changes made to produce that behaviour.
  • Evidence — tests and measurements showing the work does what it claims.
  • Outcome — the result against the baseline and acceptance criteria.
  • Learning — what we now know, fed into the next FORT.

Each link has a practical control: agreed acceptance criteria (Intent, Outcome), human review (Behaviour), testing (Evidence), traceable decisions (Work), clear handover (Learning). FORT's contribution is consistency — the chain is walked every time, which is what makes linked FORTs compound instead of drift.

A worked example: one FORT, end to end

Illustrative example: a growing services firm wants enquiry emails captured into its CRM without a day of manual retyping. FRAME: the problem is lead-to-CRM entry; the baseline is a two-week measurement of delay to entry and share of records needing correction; the constraints include an unchanged CRM, data-protection requirements and a fixed budget; acceptance criteria are faster median entry, fewer corrected records, and a human approving every record before creation. ORCHESTRATE: one senior engineer and one of the firm's office staff, a sandboxed mailbox feed, the CRM API, and a daily five-minute decision stand-up. REALISE: the draft-extraction capability is built and integrated, tested against historical emails with known correct fields, and reviewed daily with the human approver — corrections become test cases. TRANSFER: a staged go-live with the approver in the loop, runbook and documentation handed to the named internal owner, a training session, and an end-of-cycle review against the acceptance criteria. The whole FORT is two weeks. Support triage next would be a second, linked FORT, with the first FORT's learning folded into its FRAME.

Speaking Agile? FORT maps to the sprint cadence

If your teams run Scrum or Kanban, the outer shape will be familiar. The name is deliberate: a FORT is a fortnight — one two-week cycle, the length of a classic sprint, running the plan-deliver-review-improve rhythm every Agile team knows. A sprint is a FORT; sprint planning plus a definition of done is Frame; backlog refinement and team assembly is Orchestrate; the sprint itself is Realise; review, retrospective and handover is Transfer. Our Delivery Coordinator plays the Scrum Master role — guarding the cycle and the evidence trail.

What FORT adds is not new ceremonies but a tighter contract: traceable decisions, acceptance criteria agreed before work starts, and a handover your team can actually operate. FORTs work inside your existing Agile process rather than replacing it, and we don't claim certifications we don't hold.

Constraints and trade-offs

FORT is honest about its costs:

  • Two weeks forces smallness. Work that cannot be decomposed is not FORT-shaped; the method will tell you so, which some find uncomfortable before useful.
  • FRAME takes effort from you. The baseline and acceptance criteria need an owner on your side who knows the process. Up-front senior involvement is the price of senior results later.
  • Continuous visibility removes hiding places. Working evidence means weak work is exposed early — a change of tone for teams used to milestone reports.
  • Handover is not free. Documentation, training and parallel running consume cycle time. Cutting them converts a durable outcome into a dependency on us — what FORT exists to avoid.

Your action checklist

  • Pick one problem and state it in one sentence, in business terms.
  • Ask whether it fits a two-week cycle; if not, scope the first FORT as a definition exercise.
  • Measure the baseline before anything changes.
  • Write acceptance criteria your outcome owner will sign.
  • Name your people, access and decision-makers before work starts.
  • Demand working evidence during delivery, not status reports.
  • Define what "handed over" means and who receives it.

If you have a problem that might be FORT-shaped, our technical review pressure-tests the boundary, baseline and acceptance criteria with you — so the first FORT starts from a definition that survives contact with delivery.