Dynamics NAV: The 3 T’s of Go-Live Success
I just recently assisted a client of ArcherPoint with an upgrade to Microsoft Dynamics NAV 2016. Being on site, I noticed a handful of things that amazed me regarding the upgrade. There were no “end of the world” fires! There were no users yelling, “I can’t do my job!!” There were no “I can’t find this,” or “NAV is totally broken,” or “This new system stinks” being screamed by frustrated users. The go live was more like a waiting for problems that would never come.
The client’s project manager and I enjoyed a cup of coffee and discussed what new features would be available to them with the upgraded database. It was really a pleasant experience. This is the way every go live should be. The majority of the times it is not.
I thought I would share what I learned from this project to help prepare for your implementation and go lives. This client invested in what I am calling the 3 T’s of Go Live Success: Testing, Training, and Transitioning. And the investment paid off.
A significant investment was made in acquiring and setting up a new system. In addition to that investment, however, you need to invest in testing, training, and transitioning for your go live to be successful and to protect your investment in your new system.
“T” Number 1: Testing
Test the system thoroughly. I recently overheard this: “You’re going to find all of the problems with the software; it just depends if you want solve them when you have the luxury of time to get them right.”
If you invest time testing the system before you go live, you should find issues. If testing doesn’t produce issues, then test harder. These issues can and should be resolved before you go live. The benefit of resolving issues before going live are twofold:
- You will have the luxury of time to solve them correctly, without systems being shut down.
- You will not need to perform any correction of the data, which is sometimes required with some issues.
Testing can be a very tedious task, or it can be made a bit more fun by challenging users. I have, in previous testing scenarios, set up a “Bug Bashing” contest. In Bug Bashing contests, we created a certificate for the champion bug basher and a nominal prize ($50.00 gift card to a local restaurant).
What the Bug Bashing did was challenge the users to find where the system wasn’t working appropriately. These tasks really made the users explore every aspect of their job to ensure that the system performed as required. I have found that the investment of a few gift cards and sheets of paper have paid off in many different ways. It challenged the users to explore, to try to break the system, and to inadvertently learn the system—which leads to the second “T” of Go Live Success: Training.
“T” Number 2: Training
The power users of a system can test it thoroughly, but if they are not aware of what they are supposed to do, then the project is for naught. It is a critical task that users are aware of how to use the system. They must understand the ability to log into the system, the user interface, and their tasks and roles in the system.
This training needs to involve the power users, as they will be available to answer any questions about your processes better that an outside consultant can. The power users will also get a flavor of the type of questions that users will present. This can prove to be an area that may need testing again.
When preparing user training, consider the following:
- What are the user roles – will they have enough knowledge to do their jobs?
- Are there any modifications that the users may need to be aware of?
- Can we create some checklists or process documents to assist the users with their tasks?
- How does a user log into the system? How do they log out?
- Are there any process or procedural changes that users need to know? Where can they discuss these changes? Procedure changes often spur debate, which ultimately makes your systems and processes better.
- When training, allow adequate time for users to ask questions. Allow for a follow up to the training for additional questions. Keep in mind that some users may not feel comfortable asking questions in front of their peers, but need answers.
- Offer a timeline of when the upgrade or new system will be available. You don’t need to be 100% accurate, but provide a short timeline like, “In the next month we hope to be…”
- Time the training to be relatively close to the go-live date, or at least provide a playground where users can familiarize themselves with the system. People tend to forget what they learned if they do not put their knowledge into practice.
- Keep in mind that change can sometimes be intimidating and could bring about some trepidation. Keep users calm and aware that things will be better in the long run. Be optimistic during training.
Training not only serves the purpose of teaching your users, but also keeping the lines of communication open. Investing in training will reduce some major go-live stress and fears. It is critical that we make the users aware of the change, and investing in training will pay off. That is why it is one of the 3 Ts.
“T” Number 3: Transition Planning
We have a plan for testing our new system and a plan for training users. The third T is to have a plan for the transition.
Every upgrade and implementation I have worked on has had a series of steps that needed to be followed. This checklist of tasks should be a part of the plan, but not the entire plan. In transaction plans, some additional pieces that should be considered are the following:
- Prepare a checklist of the steps and/or actions that need to occur.
- Prepare a list of all of the players who need to work on the cutover. Make sure that ways to contact these people are included in the list.
- The most successful projects have had a dress rehearsal that looks at the timing and events required for the transition.
- Contact any outside auditors or accounting personnel to see what may be required for data verification. Identify how you are going to obtain the data required (what reports, what parameters of reports etc.), and test running the reports in your old system and new system to determine how long this step takes.
- Identify a method to prevent users from logging into the legacy system. Nothing aggravates users more than spending a day working in their old system, only to find out that they should have been in the new system.
- Determine a go/no-go point and who can make this decision. Make sure that they are aware of when they can make this decision and obtain sign-off.
- Prepare a fallback position. Users can typically use the old system if new system is not ready.
- Prepare a communication plan. This includes a way to let users that start early on the go-live date to log into the new system. Identify the users to contact with login and processing issues.
- Prepare a back-up of the legacy system and a back-up of new system. Verify that back-up strategies are operational. Verify that restoration of a backup is functional as well.
- Keep a list of issues as they arise. Sometimes issues can be overwhelming, and keeping a list will help ensure that the issues are at least reviewed. Be prepared to prioritize these issues if needed to determine which need to be resolved first.
Prepare to have a busy day. You probably will not, especially if your team has tested everything trained everyone, and followed the transition plan.
Your organization has invested a significant amount of money and time in getting a system ready for your users. These 3 Ts can help ensure your success on go-live day. Implementing a new system or upgrading a system can be stressful. By investing the time to test, train and transition, you can minimize the risks…and celebrate a successful go-live day.
Contact ArcherPoint to discuss how we can help you with your NAV implementation or upgrade.