Not a rigid methodology. Just how I think.

Every organisation and every engagement is different. But the shape of the thinking stays consistent, and it's worth seeing before you decide whether we'd work well together.

The method

Five stages, one way of thinking

  1. Understand

    Before proposing anything, I make sure I understand the organisation: the problem as different people experience it, the people involved, and the existing systems. This stage is mostly listening, reading and asking uncomfortable questions, like why a form exists, or who actually uses that report.

  2. Analyse

    I map processes end to end, trace dependencies between systems and teams, and identify bottlenecks, inefficiencies and opportunities. This is where the picture becomes something you can see, discuss and challenge, a map beats a meeting every time.

  3. Design

    Next, practical improvements and clearer ways of working. The test for every recommendation is simple: can the people who have to live with it understand it and adopt it? If it only works in a slide deck, it doesn't work.

  4. Build

    Where a project needs it, I turn recommendations into real things, digital systems, websites, workflows, documentation, implemented properly and handed over with everything your team needs to run it.

  5. Improve

    After implementation, I review what changed and whether it did what it was meant to do. Systems work isn't finished at launch, it's finished when the improvement holds up in real use, and the next opportunity is visible.

Working principles

What working together looks like

Direct access

No account managers, no layers, no telephone games. When you work with Bradford Independent, you work with the person doing the analysis, from the first conversation to the final handover.

Plain English

No consulting buzzwords. If a recommendation can't be explained simply, it hasn't been thought through properly. Documents are written to be read, not to be billed by the page.

Honest scope

Sometimes the right answer is "you don't need me for that". I'd rather tell you that in the first conversation than sell you a project that doesn't pay for itself.

Evidence over opinion

Recommendations trace back to observed facts, mapped processes, system behaviour, conversations with the people doing the work. Not instinct, and not whatever the loudest voice in the room said.

See whether this way of working fits

The first conversation is where you find out. Tell me what's happening, what you're trying to achieve, and where you're getting stuck.

Or go straight to the source