Now, the confession that earned me the lesson.
For a good stretch of my early career, I was quietly confident that I had "change management" well in hand. I sent the announcement emails. I ran a training session — a decent one, with biscuits. I may even have written a paragraph in the project plan under a heading marked Adoption, and considered the box firmly ticked.
What I was actually doing, of course, was a little communication and a little training, and mistaking the two for the whole discipline. The structured version — the one that seriously reckons with what users actually need and prefer, with industrial relations, with the regulatory and operational realities that quietly decide whether anything gets taken up at all — that, I assumed, was for other people. Another building, another budget line, presided over by someone with a lanyard and a slide deck full of butterflies unfurling from cocoons. A worthy thing, no doubt. Just not my thing.
I was a project manager, you see, and my remit felt gloriously narrow: deliver the thing. Scope, time, cost. Build it, reach go-live, ring the little bell, update the RAID log one final time, and retire with the quiet satisfaction of a job concluded. Adoption was something a couple of well-judged emails would take care of on the way out the door.
I was mistaken. What follows is a composite, but I assure you every beat of it has happened to me, in one guise or another, more than once.
Communication and training are not the same as change. Picture a system I once delivered. It was, if I may say so, rather handsome. On time. On budget. Every requirement ticked, every test passed, a closure report so immaculate you could have hung it in the Tate. We went live on a Friday. I felt, briefly, magnificent. By the following Wednesday, almost no one was using it. The team had quietly migrated back to their weathered, colour-coded spreadsheets — the very spreadsheets the handsome new system had been built to retire. The emails had gone out. The training had happened. But none of it had reckoned with how they actually did their jobs, what they'd need in order to give up the old way, or what would make the new way feel even faintly safer than the familiar one. I had sent communications and run a session. I had not delivered a change.
Which is why the people side and the delivery side run on the same track, from the first planning session onwards. Project management gets you the output: the system, the process, the reshuffled team. Change management is the quieter art of turning that output into something people genuinely take up, so that it becomes a real benefit rather than an expensive monument to good intentions. The two are rails of the same line. And here was my error precisely: I laid the delivery rail with enormous care, dropped a couple of sleepers where the change rail ought to have gone — an email here, a training slot there — declared the line open, and then affected great surprise that the train declined to move.
And the surest way to lay that second rail properly is to understand the human impact early, and factually. Here I must acknowledge a debt. I trained with Kerrie Smit of Agencia Change, who rewired a good deal of my thinking. Her model begins from a deceptively modest idea: know your change, and its real human consequences, early and factually — not as a vague "comms plan" bolted on at the death, but as a proper Change Impact Assessment that sets out who is affected, how, and what they will genuinely need in order to shift their behaviour, including the industrial, regulatory and operational realities that a round of emails never so much as touches. She speaks of moving from process expert to strategic partner — from ticking off deliverables to genuinely bridging the gap to adoption. If you carry away one idea about change management, let it be hers: it is a matter of behaviour, not paperwork.
I shall not attempt to reproduce her model here — partly because it is hers to teach, and partly because she does it rather better than I ever shall. If change is your world, or you are a project manager who has known one too many of those quiet Wednesdays, do go and read her: agenciachange.com.
So where does SSLM come into it? It builds that thinking in, modestly and by design. SSLM is a simple, low-maintenance framework, and it treats change as a proper member of the plan rather than an afterthought loitering by the exit. Benefits are baselined at the outset, so adoption — real user needs, real constraints, and all — is something you are aiming at from day one, not something you stumble upon, with a sinking feeling, at closure. There is a lightweight ADKAR-based change guide in the pack to get you moving, and the whole model assumes that "done" means used, not merely delivered. For anything larger — a true transformation, a genuinely reluctant audience, thorny industrial or regulatory terrain — that is exactly the moment to bring in a specialist such as Kerrie.
The honest summary, then, is the same point I opened with: I spent years mistaking a little communication and a little training for change management itself — the mint left on the pillow, taken for the meal. It is nothing of the sort. It is a second main course, set at the same table — and if you leave it in the kitchen, your guests will most certainly notice. Plan for it, properly, from the start. Your Wednesdays will be all the better for it.