How I Work

The page in three sentences

Engagements run end to end, from Phase 0 through hypercare exit. The first conversation is a thirty-minute diagnostic.

The seven-phase framework applies to every mandate. Commercial models include fixed-scope, retained advisory, managed service, and fractional programme directorship.

Three risks recur in programmes that have gone sideways. They are listed at the bottom of this page.

Jump to

Mandate scope

Delivery framework

• One problem statement that a non-technical senior leader can read and agree describes the problem they are facing. If I cannot write it, we are not ready to scope a solution
• Map where value sits in the operation before any solution conversation. Where decisions are made under uncertainty. Where the cost of a wrong decision is measurable
• Plot stakeholders by influence, interest, and likely resistance. The engagement for a UK water utility had five executives with divergent priorities. All mapped before the first workshop
• Governance structure live before work begins. Programmes where the steering committee is constituted two months in, after the first crisis, are common enough that the structure is a Phase 1 deliverable
• Change control defined in the commercial agreement. Not added when the first scope change arrives

Problem framing

Before scoping, three questions: where decisions get made under uncertainty, what it costs when they are wrong, who owns the outcome. The answers define the use cases. Not the technology catalogue.

AI governance architecture

On a flagship NOC programme I reframed the mandate from building AI to orchestrating decisions with AI support. Human-in-the-loop workflows, model risk controls, and explainability requirements were in the architecture before a model was trained. Governance retrofitted after build is not governance.

Operating model design

The operating model is how the organisation runs the solution after I leave. I design it before delivery completes. At a UK water utility, the product-centric model, value streams, and LPM practices were embedded before go-live. The 75% lead time reduction held in steady state.

Commercial and P&L accountability

40%+ margins across a £5.5M portfolio. 42.6% on the utility engagement. 80% proposal win rate. Commercial and delivery performance tracked in the same meeting.

Change management as a delivery discipline

Change budgeted at the same order as technical delivery. Adoption of a computer vision safety AI required a change impact assessment, tiered sponsorship, role-specific training, and AI ethics protocols.

Executive and C-suite alignment

A UK national utility had five executives with competing priorities across technology, service, platforms, and delivery. Workshops surfaced the conflicts. One transformation vision. Joint ownership of the roadmap in the steering committee.

Programme leadership

Fixed-scope mandate with defined outcomes

I hold accountability from Phase 0 through hypercare exit. Commercial and delivery performance are tracked in the same meeting, not reported in separate decks.

Fractional programme leadership

Accountability without a full-time hire

Two to three days a week over six to twelve months, for organisations that need AI delivery accountability but cannot justify a full-time hire yet. Same governance architecture as a full mandate. The structure is fractional not the accountability.

Managed service

Ongoing operational accountability beyond initial build

Accountability extends past go-live into steady-state operation. Service levels, exit terms, and IP ownership are defined before build begins, not negotiated after the first issue. DecIQ® operates under this model for capital-intensive operators in Nigeria and the UK.

Advisory with governance

Existing programme needing governance architecture

Where a programme is in motion but governance is absent or broken, I design and activate the accountability layer. This is not a review. It requires the authority to implement, the access to change programme structure, and the client's commitment to act on what the governance design reveals.

This engagement type is scoped only if the organisation has genuine decision authority at programme level. Advisory without authority to implement is not an engagement model offered.

Data quality is worse than the initial assessment suggested

I run a structured data quality assessment on real samples before scoping begins. On one programme the crude quality variability central to the value case only became visible once we assessed actual assay data, not the data dictionary. That happened in Phase 1.

Change management is under-resourced relative to technical delivery

I budget change at the same order as technical delivery. A 5% change allocation against a full build budget produces a platform that works and an organisation that does not use it. I have seen that pattern in programmes I was called into late.

Most complex integration is deferred to the build phase

I prototype the hardest integration in Phase 2. On one engagement the CI/CD pipeline integration was prototyped before we committed to the operating model design. Failing it at proof of concept would have changed the scope. Failing it at programme would have changed the commercial position.

Hypercare exited on a calendar date rather than evidence

I have declined to exit hypercare when the criteria were not met. The steering committee approves exit, not the project manager, the delivery director, or the client sponsor alone. Three criteria have to hold: no critical incidents open, adoption tracking against plan, operations team running the system in steady state for the agreed period.

Scope changes accepted without commercial impact assessment

I write change control into the commercial agreement from day one. On one programme the client requested additional FinOps work mid-delivery. I scoped it as a new statement of work: £250k in added revenue with no impact to the current timeline. Agile delivery does not mean scope is free.

AI model performance in production differs from testing

On one programme a root cause classification model carried a specific risk: misclassifying a critical deviation as routine could delay mitigation at real operational cost. I tested it on production-representative data in Phase 2 and built confidence-scored output into the UI, so operators saw the model's certainty alongside its recommendation. Drift monitoring was live from go-live.