Twenty-six years on the front line. Not all of it went well.

What didn't go well

I have watched testing get compressed because the build slipped. I have watched boards treat the initial funding envelope as a final number, then act surprised when the Full Business Case came in higher at the end of design — at which point the sponsor needs the CEO to sign off the delta, asks Procurement to review it for top cover, and £350k of stall accumulates while the SI team and contractors hired to push the programme forward sit on the bench, billable and idle, somehow ending up the ones blamed for the overrun. I have watched a Programme Manager replaced at month four because the steering committee had lost confidence weeks before and hadn't said so. None of these were unrecoverable. All of them cost more time, money or trust than they needed to.

What I learned from each of those — slowly, and not always the first time — is in Keystone.

The eight-level testing structure with explicit role distinctions exists because managing the test cycles — and the defects they surface — is a demanding skill, best placed in the hands of a battle-hardened Client Test Manager who will fight to keep progress moving, knows how to test forwards of blockers, and won't let the SI fix at the SI's pace.

The two real board gates — and the deliberate refusal to label every checkpoint along the way as a "gate" — exist because gate-inflation is what board sponsors do when they want to feel in control of a programme they don't understand.

The four business case checkpoints exist because committing to build at the end of Discovery, with no firm SI pricing, is the most reliably expensive moment in an ERP programme.

What's in Keystone — and why

Keystone is not a methodology I invented. It's one I have refined for twenty-six years across twenty-plus programmes and projects — keeping what works under load, discarding what doesn't, codifying the role distinctions, governance gates and testing structure that most SI methodologies blur.

The pre-drafted artefacts philosophy came from running too many workshops where the conversation was "what should we do?" instead of "is this draft right?".

I've made sure the Change Management workstream is properly embedded in the method. Like the often-forgotten Client Test Manager, the Change Lead is a specialist role no mid-to-large ERP implementation should attempt without. They see the change through to the end alongside the Benefit Owners, and plan and co-ordinate training and communications with the surrounding team. Far too often I've watched transformation leads ask for change management, then — when the change person arrives — have no clear sense of what "good" looks like.

The same years also taught me how methodology gets used as cover. Senior SI people have told me openly that they won't test the system because doing so "puts them on the hook." Others run their own methodologies dense enough that only they can navigate them — owned by them, understood by them alone. On more than one programme, getting the system properly tested meant paying a testing premium high enough to be off-putting, at which point many clients quietly settled for less. Keystone is opinionated because the alternatives are unhelpful. It is open because the patterns shouldn't be locked behind a day rate.

A note on how the site was built. The methodology is mine, codified across the years and programmes above. The written method pages, the artefacts, the decks and the Command Centre were drafted with AI as a writing partner, then checked back through experience. I have used AI increasingly over the last two years, starting with a Client-side contract in 2024 where it accelerated requirements gathering, document generation and meeting synthesis. The judgement on what holds and what doesn't remains mine. The tool helped me get the pages out at a pace a solo consultant otherwise couldn't.

Why publish it openly

I'm not selling Keystone. The methodology is free to use, adapt, or teach. I sell my time, on the programmes that benefit from someone who has seen this shape of problem before and has a structured way of working through it. None of that makes me the knight on a white horse. I'm only ever as good as the teams I work with — but what's on this site gives anyone who wants to use it a better chance of success, even if only partly adopted.

Publishing the method openly means the conversation with a prospective client starts with "is this the right framework for what I'm trying to do?" rather than "what is your methodology?". That's a more honest place to start.

If the method is useful to someone who isn't a client of mine, that's a fair outcome. If it's useful to a partner organisation that wants to adopt it, also fair. The asset I trade on is judgement; the methodology is a way of demonstrating that the judgement is real before you've spent any money on it.

Three programmes, three patterns

Details are anonymised. The patterns aren't.

D365 Finance & CE recovery — international not-for-profit

A £58m-revenue not-for-profit operating across 32 countries had attempted a D365 Finance implementation that had stalled with foundational problems. The original build had stood up only two legal entities when the organisation required thirty-two. The result: weeks-long month-end cycles, manual reconciliation across ledgers, and 32 entities submitting reconciliations via Excel to the central finance team for upload. The trial balance couldn't be signed off with confidence. The system didn't reflect how the organisation operated — or how it paid its tax around the world.

In parallel, a D365 CE implementation covering Customer Service, Sales, Marketing, Product, and back-end e-commerce was being planned in isolation. Four separate project plans for four separate workstreams, with no unified view — which meant no cross-platform testing, no integration planning, no coordinated change, communications, or training. There was no data lead and no data to load. The £5.1m programme budget was being eroded by BAU activity that had attached itself to the programme without its own funding.

What changed. Over 14 months as Programme Manager / Programme Director: replaced the CE Project Manager, introduced a dedicated Finance Project Manager, restructured the team to separate programme and BAU funding, selected the SI, wrote the Statements of Work, and rebuilt the plan as a unified multi-pillar programme. At senior level, navigated three changes of COO (who doubled as Executive Sponsor), multiple CIOs, a new Head of Transformation, and a finance leadership team under pressure from organisation-wide funding constraints. The executive team had been disengaged, treating the programme as an IT project.

Recovery depended on re-establishing governance — Terms of Reference, executive sign-off on requirements and to-be processes, a solid business case, and strong SI commercials aligned with Procurement. Benefits were mapped using OKRs and tied back to the plan.

Outcome. Both the Finance and CE implementations went live successfully. Month-end moved from a weeks-long manual exercise to a controlled, system-supported process. The finance team regained confidence