7 Tips for a Successful Go Live

How do you prepare for a successful go-live? That is a question we often get at Apps Associates. Our Customers often ask what are some of the key factors that have the biggest impact on a successful go-live. Implementing a software package that affects just about every aspect of your organization can be a demanding process for many and can prove to be even more stressful if not properly planned, managed, and executed.

I have highlighted seven key tips that can contribute to a successful go-live. Taking into consideration the following tips below, can help ensure your project goes live smoothly.

1. The Beginning of the Project
Ensure that the right personnel is scheduled to be involved during critical stages of the project. It is imperative to designate a super user. A super user is a significant member of your team, who will be responsible for making key decisions relating to the sub ledger application(s) that they are responsible for. They should have a strong and deep understanding of your organization’s processes. Furthermore, this person will ultimately be responsible for comprehensively understanding the software application under their purview.

If feasible, backfill as much as possible each of the designated super user’s day-to-day activities with another resource. Depending on the complexity of the project, a super user may find themselves consumed on the implementation project and will need to weigh the demands of the project, to the day-to-day necessities to maintain ongoing operations. If it is not possible to backfill that person’s duties, the project should be properly planned around operational processes that a super user can’t avoid (e.g. month end/quarter end closing).

2. Data Cleansing
If your organization is currently creating customers and suppliers and it is known that they contain duplicate records, inactive records, and incorrect attributes, bringing this data over from another system (yes, even an existing Oracle r12 instance), won’t magically resolve your issues. Often customers may find that instead of resolving any type of problems you may have, it instead, could make your conversion that much more complex! This is an activity that can begin well before the consultants walk in the door, and would be greatly encouraged to be well on the way, even before the formal project begins.

3. Chart of Accounts Redesign
Changing a foundational element, like a chart of accounts redesign should be one of the first activities on a project. Why is this the case? There are typically a series of workshops to work through the purpose (and number) of the segments to be created, and then building out the values within each segment, with consideration to the parent/roll up values that will be used to support things like reporting, controls (e.g. Cross-Validation Rules), and allocations. This structure will touch every aspect of your subledger applications, and should be as close to finalized as possible, leading up to the beginning of the configurations for these other subledgers.

4. Dedicating Enough Time to Prep Data for Conversion and Interfaces
Properly planning and mapping out legacy data in preparation for mission critical cycles of the implementation is a must. A full cycle of conversions should be taking place during the test cycles of SIT (System Integration Testing), and UAT (User Acceptance Testing, the last cycle of testing that occurs prior to go live), to properly identify where issues may reside. The actual conversion of this data however, is just a first step. End users should be expected to reconcile the data that has been converted, as well as perform a detailed analysis of the converted and interfaced data to ensure that the quality of this data meets their needs. For any interface processes that have an impact on third party systems (think banks), please allow for a longer lead time, as in many cases, the users of your organization don’t have an impact on when they can expect feedback on the acceptance of this data for these other sources. One final recommendation is to not use stale data from test cycle-to test cycle when validating conversions and interfaces. Using this approach may well prove to bite back at you, when the time for go-live occurs.

Given this, it is highly recommended to use the most current data possible. This will serve two purposes: The first is ensure that any other underlying/relating conversions are supporting the conversion/interface being tested. The second is to make sure that the existing setups will support this related batch of data.

5. Dedicating Enough Time to Testing
Don’t just go through the motions and ‘check the boxes’ on the test scripts. This is a great opportunity to learn about the system that will be with your organization long after the consultants roll off. Additionally, think of real-world examples that should be tested. By the time the organization is at the UAT (User Acceptance Testing) cycle, reading through the test scripts, without understanding the real world impact of what you are trying to accomplish, isn’t a good sign of things to come.

6. Don’t Forget About Reporting!
Don’t wait until the last minute to start this aspect of the initiative, as there may be iterative cycles that are needed, before the report is what your company is looking for. After a report has been developed, the end user should have performed a reconciliation of this new report to ensure accuracy. This is also an opportune time to ‘clean house’ on any legacy reports that are currently not utilized, and will not be needed when going to your new system.

7. Go Live
‘Go/No-Go’ – This activity should be closely analyzed and a discussion should be taking place with the key stakeholders relating to the current issues/roadblocks that are outstanding prior to making the decision of whether to go live with your new system.

The following questions below should be taken into consideration on whether this is the proper time to go-live, or if further remediation may be necessary:

• Have all of the issues relating to the quality of the data that is to be converted, been resolved? A relatively small amount of data that falls out during conversion can be entered manually, but if the amount of data that gets kicked out is too large for this approach, then this can be a critical impediment to the go-live process.
• For those that have a high volume of data to convert or to be interfaced, has a stress test been adequately performed to see if the time line for converting data fits within your schedule? Have you performed a proper stress test of high volume data that will be interfaced into or out of, your applications? What is the plan for data that has failed import, and are the steps to correct, practical in approach?
• Are end users properly trained on what is expected of them, not only during the go-live cycle, but after you have gone live?

By this time, a checklist with an established timeline of how long conversions and interfaces take to execute should have been already been established during the SIT/UAT test cycles, and should serve as the bedrock for the go-live schedule, as well as post-go live activities.

• For conversions with high volumes of data, this becomes even more critical, as you may find that working in different shifts throughout the day may be required, as one set of converted data may need to be a predecessor before another set of data is converted.
• As soon as there is a firm awareness of the work schedule, be transparent to the team that is working during the go-live cycle, so that they can plan accordingly.

While this is not a comprehensive list by any means, not taking into consideration the items listed above, may prove detrimental to your project. To learn more about how Apps Associates can help you check out our website or download our data sheet.