John Fordham

Methodology

How I run an engagement.

Ten phases from setup to after release, the practices that run through all of them, and the principles underneath.

Every engagement is shaped by what the organisation already has, how much time there is, and what has been tried before. The phases below are not a template to be run end to end on every programme. They are the full set, and most engagements use some of them properly rather than all of them thinly.

What does not vary is the order of the logic. Understand the service before redesigning it, design it before costing it, and cost it before building it. The phases are not a schedule, though. They overlap, and discovery regularly changes the question badly enough that the scope has to go back and be reset. Where programmes actually go wrong is the handover between two phases, where the thinking quietly gets lost.

The phases

Setup to delivery

  1. 01

    Setup

    Agree what the engagement is for before any research starts.

    Activities

    • Scope and success criteria agreed with the sponsor
    • Data request issued in the first week — analytics, sales and service data, existing research, system documentation
    • Stakeholder map across business, operations and technology
    • Research plan and interview schedule
    • The questions the research has to answer, agreed before it starts
    • Governance, cadence and reporting line established

    The data request goes out first — it reliably takes longer to come back than anyone expects, and stalls the analysis if it is left until it is needed.

    Outputs

    Engagement scope · data request · research plan · stakeholder map · success measures

  2. 02

    Discovery

    Find out how the service actually works, from the inside and from the outside.

    Activities

    • Review of the data, analytics and documentation returned against the request
    • Cross-functional stakeholder interviews
    • Customer interviews
    • Outside-in and competitor research
    • Journey research
    • Synthesis into candidate themes, grouped as pain points and opportunity areas

    A running log of the top themes is kept as the interviews land, rather than waiting for one synthesis at the end.

    Outputs

    Interview findings · theme log · pain points and opportunity areas · competitive position

  3. 03

    Current state mapping

    Make the whole system visible at once, so people are arguing about the same picture.

    Activities

    • Journey mapping for the priority journeys, from the customer’s side and the organisation’s side together
    • Validation workshops with the people who run the service day to day
    • Consolidation into a single service blueprint

    The blueprint carries the customer steps, the organisation’s steps, the systems underneath, and bands for pain points and opportunities running the full width.

    Outputs

    Current-state journey maps · service blueprint · prioritised journeys

  4. 04

    Future state and operating model design

    Design what the service should become, then test it before anyone commits to it.

    Activities

    • To-be journey mapping and future-state blueprint
    • Operating model implications — the roles, processes and operational constraints that have to change before anything can ship
    • Design sprints or workshops, run per stage of the journey
    • Low-fidelity wireframes where the argument needs to be seen rather than described
    • Clickable prototypes for the flows carrying the most risk
    • Feasibility tested with the engineering team before the design is committed to
    • Validation with users, and with the teams who will have to run it

    The prototype is the specification. It is cheaper to argue with several linked screens than with a written document that no two people read the same way.

    Outputs

    To-be journeys · future-state blueprint · operating model changes · wireframes and prototypes · validated concept

  5. 05

    North Star Backlog

    Turn the opportunity themes into something leadership can fund and a team can pick up.

    Activities

    • Opportunity themes grouped into the strategic epics that carry the transformation
    • Epics arranged against the journey stages, with the objectives and key moments written above them
    • An initiative card per epic: what it is, its business impact across acquisition, engagement, revenue and retention, the goals it moves, and the features it contains

    Deliberately not a list of user stories. It sits between the strategy deck and the delivery backlog — fundable by leadership, breakable down by a team.

    Outputs

    North Star Backlog · initiative cards · feature cards

  6. 06

    Prioritisation and roadmap

    Sequence the work against what actually constrains it.

    Activities

    • Scoring across value, requirement complexity and operational complexity, each assessed separately
    • Operational constraints surfaced explicitly — warehousing, carriers, contract notice periods, procurement lead times
    • Dependency mapping
    • Release shaping into a phased roadmap

    The scores stay separate rather than collapsing into one number, so a sponsor can argue with the weighting rather than with the conclusion.

    Outputs

    Scorecard with the workings visible · prioritised roadmap · dependency and constraint log

  7. 07

    Business case

    Make the investment arguable.

    Activities

    • Benefits quantified against the success measures agreed at setup
    • Cost and effort estimation
    • Options and trade-offs, including platform and vendor choices and what happens if nothing is done
    • Board pack and presentation

    Framed as a discussion with the decision still open, rather than a verdict to be ratified.

    Outputs

    Business case · board pack · funded scope

  8. 08

    Change and adoption

    Get the organisation ready for what is coming.

    Activities

    • Impact assessment across the affected teams and roles
    • Process and policy changes identified and owned
    • Communications plan
    • Training and support material

    Adoption is where the business case either lands or does not. It is planned before release rather than after it.

    Outputs

    Change impact assessment · comms and training plan · adoption measures

  9. 09

    Delivery

    Stay past the recommendation.

    Activities

    • Requirements written as features, user stories and acceptance criteria
    • Backlog ownership and refinement
    • Board management and standups
    • Prioritisation with client leadership
    • Design iteration with the delivery team
    • Staged releases
    • Measurement against the success criteria set at the start
    • Adoption measured after release, not assumed

    Requirements trace back to the research wherever they can, which is what stops the backlog drifting.

    Outputs

    Requirements and backlog · working releases · measured outcomes

  10. 10

    After release

    The engagement ends. The service does not.

    Activities

    • Benefits reviewed against the business case, including the ones that missed
    • Backlog refreshed from live behaviour rather than from the original research
    • Themes that have changed fed back into the North Star Backlog
    • Handover and capability transfer, so the client’s team can carry it without me

    This is where the loop closes. What the service actually does once people are using it is better evidence than anything gathered in discovery, and it should change the plan.

    Outputs

    Benefits review · refreshed backlog · handover

Constants

The practices that run end to end

Principles

Five things I hold to.

  1. Evidence rather than opinion Every recommendation has a line back to something somebody said, or something the data showed. Where it does not, it is a preference, and it gets labelled as one.
  2. Strategy that somebody can build Strategy nobody can build is an expensive document, and delivery without evidence behind it is guesswork. The test of a direction is whether a team could pick it up on Monday.
  3. The shopfront only works if the operation does What the customer experiences is decided as much by warehousing, contracts and the people answering the phone as by the interface in front of them. Designing one without the other is how a programme ships on time and fails anyway.
  4. Decisions made in the open Show the workings, not just the answer. A recommendation somebody can argue with is one they can also own, and the argument is better had before the build than during it.
  5. Stay past the recommendation The gap between the research and the release is where most of the thinking is lost. The way to stop that is to still be there.