The purpose of Implement is to:
Put live what you have built and to support the business for a short time once you’ve built it
You’re so close now. I’m excited for you.
You’re nearly ready to put live what you’ve built.
In the Implement stage of Deploy we’ll help you go live safely and describe how you support the business after go live.
A: Check everything that you wrote down in comms in your entry criteria in has come true (We’ll talk about exit criteria shortly)
Remember our new tool from Comms – Schedule IT? The tool that allows colleagues and customers to book service appointments.
We defined three really important things that we needed to do before go live.
As a minimum we said:
How did that testing actually go? Did the team that built it say that it’s now ready? Hopefully the answer is yes, because if it’s not available to download for customers, customer comms criteria really isn’t ready yet. We’re not ready to say to customers, “Go and use it.”
We also asked that testing UAT (User Acceptance Testing) criteria must be met for appointment bookings and amendments.
When users tested the app, was there any problems with it? Did any problems come out of that testing?
Are there any serious defects there that we noted down?
Are there any deal breakers that would stop us moving forward?
Lastly, we said that 40% of our Ops team need to be trained and fully competent in how to use the app and how to support customers. Did that happen?
If the answers to all three things is yes, then you’ve met your criteria.
You are ready to go live!
But if you’re not, if the answer to any of those things are no, then you’re not ready. Because before in Comms, we said that these were the most important things that needed to make sure about before you go ahead.
If you’re all good in the ‘what’ and the ‘how’ sections that you’ve got there on the left hand side, you can start marketing to your customer. You’re going to start communicating to your customers and colleagues. And you’re pretty much ready to go.
Our experience is it’s a good idea to get some proof. There can be a tendency for some to think that the criteria is box ticking or insignificant. They can play lip service and say, “Oh yeah, I’ve done that.” And they’ll do it later. Or they won’t done it. Sometimes people don’t get to these things but say they have. So, always ask for proof that things have been done.
Q: How can you be sure the entry criteria about having the Op team trained is 40% done?
A: Ask for the training feedback forms from the trainer, make sure that you’ve got a record of who was scheduled to attend and who actually attended.
It’s important because the next thing you’re going to do with that proof is you are going to go to your Sponsor and you’re going to ask them to either go (or not). You need to be sure.
Time for a meeting with your Sponsor to supply the evidence of readiness and the steps you’ve taken to get it this far. You’ll also include your recommendation on whether they should go live or not, based on the success rates, as defined in Criteria, in Comms. Your recommendation is key because it helps the sponsor make the decision quickly, but you’ve got to be able to stand by that, which is why some evidence is important.
Let’s say the sponsor has said, “It’s a go”
There’s only one thing left to do, launch your product. Well done. You can relax. Or can you… ????
Not quite. In the next part, I’ll explain how you’ll launch successfully and manage it.
Is anyone is looking at this and thinking, “Great, time for a launch party”?
We’re not ready to crack open the champagne just yet.
You wouldn’t get this far if you hadn’t already put some serious thought, time and effort into actually launching the thing that you’re going to launch.
When I say launch, there will be an ‘event’ to launch it and that event will need managing.
In A, B and C of our method, we are growing and nurturing this product.
In this example, we are incubating a baby, making sure the baby is growing.
You’ve read some books, but your midwife is generally the expert. And she’s going to be checking in with you along the way to make sure that you are making the right progress.
At first (go live), you might spend a few days in hospital after delivery, getting some expert care. The midwife will be giving you advice about what to do when you get home with this new, special person. Likewise, after the launch of a project, you still need to make sure things are ok before you send the baby home or ‘handover to the business’ to take care of.
Even after the birth, taking the baby home, your midwife will still call in on you to make sure things are ok.
Eventually, the business, wean itself off the project which is what we’re going to talk about in E, Embed.
We planned the birth for the product and that’s exactly what we’re going to do in event management.
This ‘house’ is what good event management looks like. Across the top we have the whole thing, event management. The bottom part is your foundations, to remind you to never neglect the most basic things of launching your event.
As the Project Manager, that could be as simple as agreeing where you need to be on launch day. At home or in the office? Will I have access to the building? Does it need to be done overnight when customers are more scarce? Will the team have access to some good Scooby snacks to keep them going through the night?
The middle is all around event planning, what you do when the thing goes live.
Picture this. You’ve launched. Your support lines are open and you’re ready to help. Perhaps it’ll go well and be quiet, but you’re ready just in case. It won’t usually be enough to say, “No news is good news” during an implementation event. You might be asking users to check in to tell you everything looks okay or they might even be ringing in. Or you might be asking them for evidence and info.
Your sponsor will want to know how it’s all going. You might be meeting every four hours to check in with them, or maybe once a day instead of your usual fortnightly steering meeting? In a highly complex situation, you might have dress rehearsals or pilots, or you could have hundreds of people involved. In something smaller, you’d scale it accordingly.
But the moral of the story here is: this is an event and it won’t run itself.
You’ll usually have someone who’s running the event for you. Interestingly, this role has some parallels to other industries, such as firefighting, where you’ve usually got an event commander who’s responsible for organising everyone at the scene of a fire.
The Project Manager might be your event lead or event commander. If you were doing some sort of IT release or technical development, you might have to keep an eye on how it’s going for maybe a couple of days, maybe 24 hours a day, a couple of days a week. One person won’t be able to do that all the time for you. So that’s why we sometimes have rotas and others to help.
Immediately after you go live, you might have temporary roles just for the period of the event or for a short time to tide you over until things have settled down. You might have someone who’s dedicated to managing incidents for you. Likewise, someone needs to keep an eye on the measurements and give you regular updates and data on how things are going.
Remember anything can and usually does happen. It isn’t always related to the product that you’ve launched or the app that you’ve just put out there into the wild. A few years back now, I was involved in a big IT event for a well known bank. It took place at the weekend because the weekend was quieter and there was less customer traffic then. And we had this team of people ready to support the business. We weren’t the tech that was doing the IT changed, but we were there to support the business.
We had to be in the office near Liverpool Street at eight o’clock on a Saturday morning. Three people were late. They didn’t sleep in. It’s simply because they weren’t used to traveling in on a Saturday. Transport for London do all a lot of their improvement work and engineering work at the weekend. It just took them longer to get in, which is why sometimes it’s good to do a dress rehearsal.
Often these events are done together in one site or somewhere where you can be close to the action if possible. But it doesn’t have to be, and it can’t always be like that. But if you’ve got sites and rooms to book, get all that done in advance and check it all ahead of the events as well. You might be relying on new telephone numbers that you’ve published, and make sure everybody knows where to find them and make sure any of your extra governance meetings are all booked in well in advance.
The domestics are, in my humble experience, super important and as important as switching stuff on and making sure stuff is coming through the pipe properly. If you’re in on a Sunday morning for go live, don’t assume security will let you into the building. Remember, you’ve never worked on a Sunday evening before.
Similarly, the operations team are coming in on a Monday morning and you’ve worked all weekend and been sat in their desks. And the vending machine’s empty because you have been raiding it all weekend. They won’t be very pleased at break time. So just try and make sure that those extra things are considered. They can make a big difference.
Last, but not least, We don’t want folk getting hangry. So catering is indeed important. I think as well on a more serious note when people are working hard and they’re perhaps in an intense environment, they might not have time to go and grab anything. So some catering will be important.
Let’s have a little look at the event plan itself.
An event plan really is just a list of things that need to happen to make sure that the event runs smoothly. You might have nine lines in your plan or you might have 27,000 lines in a hugely technical piece. But you still need to write it down and you still need to have given thought to it in advance.
Organising a wedding is a good example of the importance of event planning. They are similar because you have work to do before, during and after. You wouldn’t leave this stuff to chance. You’d create your plan up front. You wouldn’t be leaving it to the day to make sure that your hairdresser knows where to be and what time to be there. You’d make sure the best man has picked up the suits. You wouldn’t leave stuff to the last minute.
In this plan, you’re just listing who is doing what, and when it’s needed. It’s as simple as that. You’re publishing the plans in advance. You’re making sure that you are using your buddies to help you create that plan so that you don’t miss anything.
Then publish it to the right people and make sure it’s got those before, during and after elements. Just common sense, right? Well, if it’s common sense, why doesn’t everybody do it? So just get that plan noted down.
This this is exactly what it says on the tin. “Is everything looking well or isn’t it?”
It’s about about checking that your business still works as expected after you’ve implemented the change to go live. Let’s say it’s nine o’clock in the morning and your thing has been switched on.
In some cases, you’ll have knowledge and facts. In others, you’ll have an expectation regarding when this is going to happen. So having those checks in advance will help you predict outcomes in a much better way. Is this what you expect to see and when you expect to see it?
You might have the business checking in with you. It’s not a “No news is good news” scenario. It’s more like “You’ve got to ring me and tell me everything’s okay” scenario. We’re not reporting by exception immediately after go live. You should pay much closer attention to it.
Decide what these checks are up front and share that with the right people. Then, put them in your event plan and make sure you’re really clear about what you expect the outcome to be.
Where you’re asking the business to come to you and confirm that checks are made, you might ask for evidence for mission critical checks.
Things can go wrong. This is the biggest section of implement, so brace yourself because this is more than just simply ringing IT help desk.
Despite your testing, things can and will go wrong. Sometimes the subtlety of moving from a development environment in kind of an IT implementation to a live environment can just be the difference it needs for something to look different in live, because the version control wasn’t maintained or something like that at.
There could be other problems on the day. Folk like to assume that it’s the new thing that you’ve switched on that’s caused the problem. And it might be. But I’ve had many an incident call with colleagues where they say, “Oh, we’ve gone live. And now my printer won’t work.” And then you say, “Well, was it working last week?” “No.” “Well, it’s not the go live event then!”
It could be your go-live event; but it might not be your go-live event. But the issues are important and understanding the root cause of the issue is key because ultimately, that could put your ability to roll out this product at risk. It could mean it takes longer to meet your exit criteria. In total, this could mean the whole project takes longer and costs more money. And remember, you are in charge of that so it’s important.
You could come across all sorts of issues and they can cover anything from building issues to unexpected colleague absence, third party issues, technology stuff that impacts our customers. It won’t prevent them all, but you can make sure that you’re ready to deal with them.
You can use them as a useful way to learn more about how things work and get fixes resolved quickly. Plus, you’re a very responsible project manager, so you won’t want to just dump and run and leave the business with a load of open problems. You want to get them sorted. It’s not just the issue. It’s also about how you deal with it.
It’s quite normal to provide extra support immediately after launch. And remember this is new to everyone so you’ll get people ringing in with incidents that turn out not to be incidents. It’s still very new to people. So it’s normal for them to need a bit more TLC and as the PM, you want to make sure it’s landed well.
That’s why there’s usually a separate issue management process to your business as usual issues. You want to be able to identify the issues that are most likely to be attributed to the launch of your product, so you can let your Sponsor know.
“We’ve got three issues and they’re all because of the product”
or
“We’ve got three issues, and two of them look like they might be down to this launch. One of them we are not sure about.”
But that’s the sort of data and information that they’ll need. And naturally, you’ll need to establish the root cause of those incidents and fix them as soon as possible.
Sometimes you might establish the root cause of a problem, but it might be that the fix to that root cause takes a little bit longer. And if that’s the case, you sometimes might need to ask the operations team or someone to put in a temporary workaround until the fix is done. Even in that scenario, and I’ve come across that lots of times, you can’t always fix things in a jiffy.
You’ll still need to use your governance to make decisions regarding issue closure, where you’ll be showing your sponsor and the people in your RACI what you’re doing to fix a problem. Give them dates by when it’ll be fixed. You’ll be explaining your temporary workaround and prove to them that you’ve communicated it to the operations team, that type of thing. An issue is usually only ever closed when your sponsor agrees that you’ve done all you can and that the root cause has been resolved.
The truth is that things almost never go as you anticipate them to. Forgetting to get the key from security so you can get into a building is not a major failing in a multimillion-pound project, but it shuts you down as effectively as having a massive IT crash.
A dress rehearsal can prevent problems.
You’ve tested the product, but there are plenty of other things that can go wrong. You want to de-risk your live event as much as possible. And practice as close to real life as possible to see if there’s anything that you do differently on the big day.
A bit like that example I gave earlier of coming in on the tube to Liverpool Street and arriving late because it’s a Saturday. A dress rehearsal would probably have shown that, or at least it might have made us think about engineering works on the day and that type of thing.
Backout plan, those words you never want to see but they’re so important to prepare for. There are times in life when you need to surrender, give up, admit defeat. No one likes it, but it does sometimes happen. So, you need to develop a back out plan because you want your back out to be an honorable surrender, not a panicked escape.
Also, you’re thinking damage limitation at this time folks, and about your reputation. You’ve got to stay in control of the situation because people tend to get a bit panicky when you say, “Uh oh, it’s not working. We need to stop before we go any further.” It’s human to channel a lot of energy into panic and worry about that. Whereas if you can just pick your plan off the shelf, it’s a lot easier.
The back out plan is the list of things that you’ll do to reverse what you have already changed, and to restore a product or a situation, whatever it is you’re implementing, to a former state. That could be a really quick thing, but you always make a note of this in advance so you don’t have to dither on it if the worst happens. You also need to have considered, in advance what your point of no return is.
Work backwards to make sure there’s enough time to undo everything that you’ve already done. If you put that decision point in too early, then you won’t have got far enough to know whether it’s been a success or not. Likewise, if you put that decision in too late, you won’t have time to undo it all.
It all depends on what you’re implementing.
