Three engagements, described by type. No client is named and no figure comes from a client’s internal reporting.
A change portfolio and a risk register run on different clocks. The portfolio moves weekly; the register moves in the week before a committee. That gap is where an attestation becomes difficult, because the attestation asks what was true and the register records what was last written down.
A statutory insurer subject to the Victorian Government Risk Management Framework was carrying the portfolio most large insurers now carry. A multi-year replacement of a core operational platform. An enterprise analytics programme, cyber security and digital identity uplifts, infrastructure lifecycle renewal, integration and automation work, records and information management. And an operating model change running underneath all of it. Nine mandatory risk-management requirements and twelve security standards apply across that, and an executive has to sign to say they were met.
The insurer chose to build the capability at portfolio level rather than strengthen it project by project. That meant working with me on frameworks at portfolio, programme and project level — and on the policies, procedures and training that make a framework something people operate rather than something they acknowledge. Risk practitioners and project risk champions were placed inside the delivery teams rather than beside them, which is what allows a register entry to move when something happens. Control effectiveness was tested rather than accepted as asserted. More than 150 staff and executives went through the training. The crisis management and business continuity protocols were redesigned, then tested, and what the test exposed was written back into them.
The frameworks now carry the organisation’s annual attestations against the Victorian Government Risk Management Framework and the Protective Data Security Framework. Executive and Board Committee reporting was rebuilt around them, so what arrives supports a decision rather than records a position.
Every document migration gets sold as a transformation, and about half of them should not be. A firm that wants the practice it already has, on a platform that is still supported, is buying continuity. Redesign the workflow on the way across and it costs them months they did not budget, and goodwill they cannot get back. A firm that genuinely needs the workflow rethought, and receives a faithful copy of the old one instead, has bought a platform and kept the problem.
A legal technology consultancy implemented a proprietary document management platform for international law firms, financial services and capital markets firms, publishers and property consultancies — clients whose data was confidential by default and in several cases regulated. The book split roughly evenly between the two modes. Clients rarely arrived knowing which one they were asking for. The two have different risk profiles and different success tests. They have almost nothing in common except the data.
I led delivery across that book, which in practice meant making the determination before design started and then defending it. A lift-and-shift runs on fidelity: the test is whether a practice can find on Monday what it filed on Friday, and the discipline is refusing every improvement that would put that at risk. A transformation runs on adoption: the workflow is rebuilt, the exceptions are designed rather than inherited, and the test is whether people take the new path when nobody is watching. Calling it wrong is expensive in both directions, and the client is not always the best judge of which one they need.
Both modes ran end to end — initiation, systems design, migration, deployment, handover and support — to ISO 27001 and ISO 27005, on data that could not be exposed in the course of moving it. Technical design assurance sat with me either way: whether a design met the requirement and would operate in the environment it was destined for, which is a different question from whether it resembled the last one. The technical staff on each implementation reported through me. Where a client asked for robotic process automation or AI on migrated data, the answer was sometimes no. A transformation dressed as a feature is still a transformation. Pricing it as a feature is how implementations overrun.
More than ten implementations completed as transformation, with the workflow rebuilt rather than reproduced. The rest landed as lift-and-shift, which is what those clients had paid for and what they should have been sold. The documentation and risk practice built across the book outlasted the engagements that produced it.
Most transformation deadlines are negotiable in practice, whatever the plan says. Regulatory ones are not, and the difference shows up in how readiness gets assessed: a movable date invites optimism, a fixed one requires evidence.
Brexit handed an international fashion retailer a fixed date and three problems arriving together — the payment systems, the financial processes built on top of them, and cross-border operations across a global estate. None of the three could be sequenced after the others, and the date applied to all of them equally.
The retailer started from an impact assessment across the affected operations and planned from what it found, rather than working backwards from the deadline, which is the more common and less survivable approach. New payment systems went in and the financial processes around them were rebuilt to match. Third-party vendors delivered a same-day click-and-collect capability to the same plan, under management rather than on trust. Financial data was prepared for audit as the changes landed instead of afterwards.
Payment and financial processes operated under the new arrangements from the day they took effect. The retrospective the retailer ran afterwards is the step most programmes skip, and what it found was written down.