Skip to content

Overview

AM's Technology department turns ideas into released software through one operating model. This page is the map. The rest of the section walks through it.

Four phases

Phase Purpose What comes out
Discovery Confirm that a proposed piece of work is valuable, viable and feasible A prioritised objective on the roadmap
Design Agree what will be delivered and how A solution design and a plan to deliver it in small increments
Implementation Build, test and release (see Delivery and Release and deployment) Working software in the hands of users
Operation Run, support and measure what we released Stable systems and evidence of the value delivered

The phases are not a straight line. Discovery carries on while we design. Detailed design carries on while we build. What we learn in operation feeds the next proposal.

From idea to release

An idea becomes released software through four lifecycle phases. Ideas progress through proposals, validation, candidates, a roadmap, an objective, features and backlog items, and releases, while learning from operation feeds the next discovery proposal. what we learn feeds the next proposal Discovery Design Implementation Operation Ideas Proposals Validation viability, feasibility Candidates Roadmap Now, Next, Later Features and backlog items Releases Objective about 3 months

Anyone can write a proposal. A proposal is validated for viability (is it worth doing now?) and feasibility (can we do it?), then becomes a candidate. Candidates are prioritised onto the roadmap as objectives in Now, Next or Later. An objective is scoped to about three months and has one or more measurable outcomes. A delivery team breaks outcomes into features, features into backlog items, and releases them in small increments.

The Roadmap and objectives page covers the first half of that line; Delivery and Release and deployment cover the second.

Three habits that hold it together

Objectives are small. An objective is scoped as tightly as it can be while still meeting our quality standards, and rarely runs longer than about three months. A team normally has one objective in active implementation at a time.

One source of truth per objective. Every objective has a canonical objective document that says what it is, why we are doing it, what is in and out of scope, and how we will know it worked. Three dashboards, for the roadmap, for outcomes and for releases, show progress to anyone in the business who wants it, and staff can subscribe to changes.

Cross-functional teams own it end to end. A delivery team brings product, software engineering, test engineering, design and operations expertise together and is responsible for its objective from discovery to support. Specialists work inside and alongside teams as consultants and enablers, never as gates. See Teams and roles.

Why we have structure at all

The structure exists to do three things: prevent critical flaws reaching users, keep information flowing to the people who need it, and protect the autonomy of teams to decide how they work. We keep the rules to the fewest that achieve those three things. Where a rule stops serving them, we change it.

Working with us

If you are elsewhere in AM, Working with us says how to propose work, raise an issue and follow what is coming.

Where the detail lives

This section describes the shape of how we work. Step-by-step procedures, templates, tool configuration and team-level agreements live in our internal Knowledgebase.