The end of the beginning
Moving from development to support
When it comes to ending a transformation programme, it’s the little things that matter. As you transition from development to support, you are highly likely to be focused on the big stuff that needs to be tweaked/fixed/polished/delivered. But you’ll also need to keep an eye out for the twiddly bits on your clipboard with the Monumental Checklist of Things We Mustn’t Forget. It’s usually the little bits that make all the difference.
What are they, then? For me, there are six strands of activity you need to think about for transition. And within those, there are few easy-to-forget things that it’s essential to remember….
1. Don’t skimp on the communication
Everybody involved now needs to hear one more time the current position/destination/route/steps/ timing/etc, etc, etc. Interestingly, the communications piece here is often more straightforward than it has been at many previous stages - finally, after all these years, you’re seeing concrete reality approaching. Hallelujah – cue flags, bunting and a modestly-sized brass band. So go for your life with your Directorial Briefing Packs, customer interface seminars, staff countdown newsletters… whatever you think needs communicating.
But don’t forget the points-to-note reminders – which are very often about process change. For example, Eric will have been told that the report he usually runs on a Monday will now be out on a Tuesday and in a different format. But it’s wise to remind him and prepare him for the change now, a little way out, so that it is expected and more-normaller when it comes.
2. This is not just engagement; it’s active engagement
Yes, you’ve told everyone everything they need to know. At least twice. But for years, your project has been conceptual and a-long-way-in-the-future. Now it’s coming to life.
So the next consideration is to check everyone who matters – and that might be almost everyone involved – is actively engaged with this project. You need everyone switching on their full wattage to share knowledge and believe this now involves them. So for example:
BAU needs to be involved super-early, months before the go-live. Their processes work well now and they’ll have been involved in designing the new processes, but let’s get them thinking about all the ramifications of the new processes. They’ll spot problems, but they’ll also have ideas and solutions, ensuring accidents don’t happen.
Or take training. Of course you’ve thought of training. But here’s an idea - what might be done now to make all system users responsible for their own learning about the new system, so that they are, er, obliged to be actively engaged?
3. The dress rehearsal
Of course you’ll be chewing your way through ITIL – the giant ITIL manual on transition is taken as read. Implementing the prescribed steps and checks will avert most disasters.
But there’s always something that any amount of checks cannot avoid. So it’s cue spotlights: full dress rehearsal time. You’ll need costumes, props, and everyone knowing their lines. You need to involve key stakeholders, power-users and all the kit. You need the run-through to check what’s (not) working, what’s (not) connecting, and what’s fallen through the gap in the floorboards and cannot be prised out even with the breadknife and a bent coathanger.
Alongside that is remembering to check that there are the right resources in place to be able to cope, e.g. in BAU. Or whether in fact you need sign-off on more resources, followed by high-speed hiring and up-to-speeding. And, er, who’s going to do that?
You’ll also need to remember to tell everyone what we’ve got in the cupboard – what’s the service catalogue of all the offerings within the new system? And what’s the knowledge-base – how will system users find out the answers to their questions? Who can help them with what types of queries?
4. Prepare for problems
I think it’s easy to avoid preparing for a problem. We don’t forget about this, but we Transformers don’t like telling the sponsor/client that something might go wrong – it tends to make people a touch antsy. We also like to believe we’ve thought of everything (we write long lists on clipboards, you know, to be sure). But in fact, back in the real world, however much thought and innovation and testing and care we’ve used, the system ain’t going to be Grade AAA+ Class 1 perfect when it launches. With a lot of care and a bit of luck, any problems will have the status of snags and hiccups. But even these are still A Problem.
If A Problem happens, you’re aiming to score zero on the Headless Chicken Scale. You’ll need to be instantly prepared so that you know whose problem it is; and what they’re going to do about it.
That means you need to remember to create and discuss a Problem Escalation Protocol, which states at precisely what level the issue is the responsibility of the CIO; the Programme Sponsor; the Board and the CEO. Think of “discussing discomfort” as an essential part of your communication campaign and it might be a bit easier to talk about it…
5. Perfection is a work in progress
Despite all the above anticipatory thinking, you’re going to need a second edition of the new system far sooner than you’d planned. It’ll become clear on Day 2 that some stuff isn’t quite perfect. In fact, you probably already know some of the stuff that’s going into the Second Edition before launch.
Therefore, before you launch, you’re going to need a plan to fix all the stuff that wasn’t quite 100% by the time you went live. With space in it for the stuff you then found out didn’t meet the users’ expectations. Which means you need a plan for the second release date, even before you start…. Oh, and that means you’re straight back in development, and needing another delivery plan, too. Launch is the end of the first journey and the start of the second journey. Don’t forget to put that in big letters in your communications’ campaign.
Carry lessons over for the next time. Especially in multi-point/stage transformations, you will need constant objective assessments of lessons learned at every stage. In the relief of getting the ruddy thing out of the door, don’t forget to learn, review and change it for next for time. Once again, there’s no shame in not being perfect the first time – but shame on you if you make the same mistake twice.
6. It’s the little things…
And finally: don’t forget the printers – or whatever peripheral matter it is that you’ve probably forgotten, because smart people forget simple things. You need to check your fangle-dangle new system is configured so it speaks to the printers, or fits on the desks, or recognises the passwords, or isn’t scheduled to launch on Easter Monday.
The best way to do this is to ask a nice realistic person who has had nothing to do with the project to give you some suggestions of where their capable-but-IT-amateur eye thinks it might go wrong. They’ll be far more likely to spot the schoolboy error than you will from your ivory tower on the eighth floor.
This is an extract from Mark Aikman’s book Uncommon Sense: Alternative Thinking on Digital Transformation
Amazon location: https://www.amazon.co.uk/Uncommon-Sense-Alternative-Thinking-Transformation-ebook/dp/B08KSG513Q
Apple location: https://books.apple.com/gb/book/uncommon-sense/id1536877985
