Go live is one of the most important milestones in any digital transformation but how do you know if you're ready and well prepared for your go live? That's what we want to talk about here today.
Go live is one of the most important milestones in your project plan but a lot of times organizations don't fully understand whether or not they're ready and whether or not they've done the necessary preparation for go live. Additionally, and more importantly, they don't understand what the potential risk is if they get their go live wrong. Frequently, organizations are flying blind, they're going in to go live “HOPING” that they have a successful go live, so they hold their breath and hope for the best but what they should be doing instead, is making sure that they have a framework for ensuring that they're ready and if they're not ready, knowing what it is they need to do to get ready. What we want to do today is talk about five things that you should be doing to make sure you're prepared for your go live.
To start, it helps to create a go/no go checklist. If you're not familiar with the go/no go checklist, it's essentially a series of activities and milestones that you need to make sure you've completed before your go live. The key here is to identify everything that needs to be in that go/no go checklist, it's also important to recognize that it's not a simple check or uncheck sort of response, a lot of times what you do, is you evaluate different criteria and parameters that you know you need to have in place before you go live, oftentimes it's not a matter of “did I do it or not” it's a matter of “how well did I do it.”
For example, if you look at something like testing, you may check the box and say “yes, we did our testing” but when you dig into it, you find that you did your testing but you didn't do it as thoroughly as you should have. Testing is just one example of something you want to make sure is in your go/no go checklist. There's a whole host of other activities and areas you want to include in there as well but the whole idea with the go/no go checklist is first of all, to make sure you understand what you have and haven't completed and where your work needs to be done. Additionally, making sure that you have alignment and transparency into where the risks are so in other words, we're not trying to sugarcoat anything, are the things we need to be completed actually completed? Are the things we haven't completed, are we all okay with the risks that we're about to take on if we were to go live on X date?
A go/no-go checklist is typically something you would do 30 to 60 days out from your planned go live. Many organizations will start it even earlier and some organizations will do the go/no go checklist multiple times. For example, they might do it one time and find that they're not ready for go-live and so they'll go remediate some things, they'll do the go/no go checklist again and find that now they're ready and comfortable with the risk of moving forward. The go/no-go checklist is a key foundational aspect of making sure that you're prepared for your go live.
One of the most important preparations that you can do for your go live and something that should be included on your go/no-go checklist, is testing of the solution or solutions that you're deploying. You want to make sure that the solution you're about to roll out is tested not only from a technical perspective but also from a functional and business perspective. There's multiple phases and multiple iterations of testing, typically your first phase of testing is going to be the more technically focused testing to make sure that the way the software is configured, works for an individual transaction or an individual myopic business process, within an end-to-end process.
Once you've done that technical testing, then you need to implement integration testing that looks at more end-to-end processes. It looks at not just one transaction or one piece of a workflow but it looks at an entire end-to-end business process workflow, ensuring that the data and the workflows within the system work from a technical perspective. Finally and perhaps most importantly, is a user acceptance testing or as it sometimes referred to as “conference room pilots” and this is where the rubber meets the road. This is where we've said the technology works, we've tested it technically, we've done the integration testing, now we've got to test to make sure it works for the business, make sure that we've thought through the different scenarios, the different exceptions, the different things that we do every day in our operations that we want to make sure we've tested in the system.
Inevitably, when we go through these three phases of testing, we're typically doing so with a series of test grips, we're documenting the results of the test grips, we're documenting where the problems are, where the breakdowns or uncertainties are and we're figuring out how to address and fix those problems. When it comes to preparing for go live, we want to make sure that we've thoroughly tested the system and really mitigated that risk of having a material operational disruption at the time of go live. This is a key reason why so many transformations fail, it is because they didn't fully test the solution, they didn't test it from a business perspective and they didn't consider all the different scenarios that they need to consider as part of their transformation.
The next step In ensuring that you're prepared for your go live is to ensure that you've completed adequate training and user adoption. Often times, organizations have a checklist of people that they want to train, they have a checklist of courses or modules or support they want to provide to ensure that they're trained and they simply check the box whether or not the person completed a training course. What they really need to be doing however is, instead, measure user adoption and really look at how well people understand the system, how well they understand the business processes and how comfortable they are with the system.
Now, of course, end users and employees are not going to be 100% comfortable with the technology on day one of go live but you want to know that there's some basic level of comfort and that you've seen enough competency in using the new processes and technologies that you feel comfortable that there won't be a material operational disruption at the time of go live.
Instead of checking the box on whether or not someone completed a training, instead, measure how many transactions are completed successfully or how quickly a series of transactions might be completed, that'll give you some quantitative measures to understand things like “40 percent of our staff doesn't understand or doesn't pass a simple competency test for this technology.” Therefore, we probably need to do more remediation training before we go live and this is something that you want to apply to the entire organization, at least for anyone that's impacted by the technology and process changes that are about to be rolled out.
Another important aspect of go live preparation is organizational readiness. In other words, how ready is the organization for the changes that are about to be deployed? We've already talked about some components of organizational readiness, for example, when we talk about training and user adoption, that's a subset of a broader organizational readiness but there's other components of organizational readiness as well.
For example, we want to make sure that people not only know how to use the technology and how to complete transactions within the technology but we also want to make sure that they understand how the processes work, we want to make sure they understand what their new job roles and responsibilities are, if there's any sort of managerial changes or job description changes that need to happen as a result of this new environment we're migrating to.
Additionally, we want to make sure that we've addressed technical aspects of organizational readiness, that we've defined the architecture and the integration points and built the competency for the IT department to provide support to the organization going forward. We want to make sure that we have support people within the business and really just make sure that we have that safety net laid out to the organization so that we're ready for the go live. That way, when there are curveballs or speed bumps along the way, we have a plan to address them and we have the organization ready for the change.
One good way to measure organizational readiness is to conduct a series of organizational readiness assessments throughout the implementation so you can see how the needle is moving and how you're progressing. This is a two-pronged approach. We'll do a quantitative survey as well as qualitative focus groups to really understand how ready people are, where the anxieties and fears are and what concerns and challenges they anticipate in the post, go live environment. That should be an important input into your overall organizational assessments.
Go lives can be very significant events, they are typically the moment of truth, when the rubber meets the road, we flip the switch and we go to work on a Monday morning using the new technology, the new processes, the new data, the new system, the new organizational roles and responsibilities, etc.
If we've done our jobs right and we've prepared well, it doesn't need to be disruptive, it doesn't need to be catastrophic or dramatic, it could end up being a sort of a natural, organic, transition to a new system. The problem is so many organizations are not ready to actually go live. They haven't done adequate preparation and that creates a lot of drama and problems during go live.
No matter how well you plan and prepare for your go live, inevitably, there's going to be hiccups and speed bumps along the way. Someone's not going to understand how a transaction gets completed, someone doesn't have the right security profile set up that they thought they did, some integration point isn't working, some data wasn't migrated correctly from the old system. There's almost always sticking points or migration errors, so you want to make sure that you have a solid and well-defined support plan.
If I'm an end user and I'm using the system and I run into one of these problems, who do I go to? Do I have support available to help me? People that are experts in the system, people that were presumably part of the core project team, that are heavily involved in designing the system, they're heavily involved in training people on how to use the system? We want to make sure that we have people to help us during that critical post go live support period.
This support team usually is a combination of the outside consultants that helped you implement the system, as well as your internal users and your internal project team members. It's really important that you use both. You certainly want to lean on outside consultants because presumably they're the experts in the technology that you're deploying but you really need people that understand the business and the technology, that's typically your internal people as well so it's usually a combination of internal and external resources that constitute the support team. You want to make sure you have that well-defined prior to going live with your new technology.
If you are looking to strategize an upcoming transformation or are looking at selecting an ERP system, we would love to give you some insights. Please contact me for more information email@example.com