Authored by: Michael Gibby and Bill Anderson, CPA
Throughout an implementation project, the users of a new system are often eagerly anticipating the transformative ‘go-live’ day when their operational challenges will be resolved, as if by magic. However, following this milestone, the organization may still find itself faced with low user adoption and a support team dealing with complaints and pain points.
Ensuring that your team is taking the proper, holistic approach to implementation will not only reduce or eliminate go-live challenges, but also will ease change management and training, reduce costs and help avoid go-live date changes.
An implementation project is a carefully orchestrated series of activities, and organizations go astray when they MOVEIT incorrectly as follows:
- Methodologies: Business processes are not documented, or those who did document the future processes did not really know how the work is done. A misleading process may actually be more harmful than a missing document!
- Optimize: Instead of true transformation, Leadership, Subject Matter Experts (SME’s) and Users approach the implementation as a “lift and shift”, with all reports and processes handled and executed identically to the legacy technology.
- Verify: Testing is a Check-the-Box activity. When the wrong users test; teams and modules don’t work together to accomplish end-to-end testing that achieves requirements; testers miss the forest for the trees; data and volume are not realistic; and 20% of the processes get 80% of the time.
- Educate: End User Training and Change Management is overlooked, so only SME’s are experts at go-live and Users haven’t experienced the knowledge transfer necessary to perform business processes.
- Intermediary: The Consultant is not the right person to communicate the positive message of organizational change between teams. This is exacerbated by teams that do not feel empowered, cultures that encourage placing blame on individuals, and where Users look to avoid implementation project responsibilities.
- Task-Focused: Reports and Data Conversion both require a hard look at not only what needs to migrate, but also whether the new system requires mapping or updates to present information required for Users to accomplish day-to-day tasks. If you ask for all of the data, you may end up with no actionable information.
Implementation challenges can all be addressed with proper project governance and leadership, starting from the very first Kickoff meeting. Every system implementer has some twist on an implementation project approach, but the general process and sequencing is:
- Kickoff, create alignment on SME’s responsibilities and project governance
- Process Mapping, Requirements Gathering
- Test cycles:
- Conference Room Pilots (CRPs) with topics discussed in isolation, around a conference room table
- System Integration Test (SIT), with topics connected to some extent, with integrations working, and possibly in real production environments with more end users involved
- User Acceptance Test (UAT), with topics completely connected, all integrations and reports working
- End User Training may begin during SIT and proceed through cutover.
- Cutover and Go Live
From the very first meeting, avoid issues with transforming business processes by identifying the right SME’s to optimize processes during implementation and ensuring they have the proper project allocation. It would be better to delay the start of a project to hire backfill and train them on the day to day, than to muddle through with a distracted and overworked SME. Even at this stage, you need to explain the importance of testing cycles—if you don’t test it, then you cannot expect a function, task, report or integration to magically appear and work.
An example of this is a project which experienced two Go Live date changes when:
- SME’s weren’t sure they had authority to sign off on requirements and process maps
- Many SME’s attended some meetings, but not all; topics had to be re-hashed in additional scheduled calls before consensus could be reached
- SME’s signed off on requirements and process maps, but overlooked critical tasks for business operations that were discovered in SIT or UAT
You can simplify process mapping by starting with standard requirements, like APQC, to guide you and avoid overlooking tasks. Also, ensure the team knows that just because you have documented the process for current state, does not mean that this will be the process implemented in Cloud applications.
Cloud projects start from the seeded functionalities, and then you compare the current state to the application. There will be many differences, which you need to divide into real gaps, and change control items. For example, your current state may involve using an email to send an approval request and waiting on the reply before taking a manual step. In your new ERP, the notification may be sent within the application and automatically acted upon after the approval action. This would be a change control item because the overall goal of the task is still met, just differently.
Meanwhile, if your current process relies upon a field of data to store the density of an object, but the application only has fields to store height, width and depth, then this is a gap. Gaps must still be categorized and prioritized; some may be overcome by reporting or minor configuration changes, while others may require integrations and page customizations. It may also be that just because something is done or available in the legacy system, does not mean it is really required for the business process.
By stating the limitations on customizations in the Statement of Work (SOW), you can help avoid significant time spent on customizations that are not required. An SOW without limits clearly stated encourages the implementation teams to never say no; but the increased workload for always adding more integrations, reports and customizations (RICE objects) encourages pushing go live dates. The 80/20 rule comes into play here to not focus on creating overly complicated solutions for edge cases while asking ‘why won’t this work?’ when reviewing standard features.
When it comes to test cycles, there are usually 2 or more CRP cycles. By the second, you should have a solidified list of test scenarios and scripts to be used for later test cycles. This means Users need to know, if they ask for new features in later cycles, there is limited room to add. Think of it like a funnel; at CRP1, you may make changes to 50% of the application. By UAT, you may make changes to nothing. In between, there is a sliding scale reducing at each test cycle.
The 80/20 rule continues to apply in testing cycles, when you prioritize integrations and reports and data conversion targets for SIT1 vs SIT2. Your most used and critical integrations and reports should be slotted for SIT1, where lesser used systems may be ready by SIT2.
Testing cycles are a golden opportunity to make sure that your SME’s didn’t miss the mark. By incorporating other Users, who are trained on the expectations, you can validate that your processes were documented and the system will really work for the day to day lives of the end users. However, avoid missing the forest for the trees. For example, even in SIT1, you can expect some things to not work properly. If you stop the session at the first sign of trouble or get overly worried about minor details like missing logos or data columns out of the expected order, you create delays that may cascade.
This is another moment to ensure that your users have sufficient time to dedicate to the project. Testing is not a step you can delegate to consultants. You need your employees validating and confirming the configured system will achieve requirements. If they don’t have time to test, then your go-live date is at risk. Plus, knowledge transfer occurs through user participation in the implementation project and users participating in test cycles can deliver the positive message of change back to the rest of the user community! This gets more critical by SIT2 and UAT, where true end to end testing is required. If your procurement team and your accounts payable team can’t all get in a room together to test, and try to keep it as unit testing, then you increase your risk of issues later.
Far too often, client teams don’t talk directly to each other; it’s not uncommon for people in one department to meet colleagues that work a floor above or below, for the first time in an implementation meeting. When consultants are passing messages back and forth, especially those instructing someone to do something related to their day job, it causes confusion and highlights the lack of collaborative culture. During the weeks after go-live, there will be plenty of moments when you need support from a coworker, so the time to form those friendships is during or before an implementation project.
Finally, implementations fail when Users are more focused on reporting on problems, than they are about solving them. An attitude and culture of formal, continuous improvement, where issues are a great opportunity to learn and improve, rather than a moment to lose focus or place blame, is key for a successful implementation as well as strong business growth. Users need to expect to learn new ways to do things, and bring positive input and attitude so daily frustrations can be continually improved with minor changes on a regular cadence after go-live. Just like the birth of a child, the go-live date is not the end, but merely the beginning. And the skills for process mapping, solutioning, testing and implementing, are key for internal users to continue those changes for the long run to maximize the value returned for the investment.
In summary, planning your moves before you MOVEIT is a crucial step that should never be skipped. Investing time into proper planning and approach for your ERP implementation project increases your chances of an on time, on budget go live with high user satisfaction and long term success.
About the Authors:
Michael Gibby is a Senior Manager at Huron Consulting Group leading Oracle Fusion supply chain implementation projects. He may be reached at LinkedIn
Bill Anderson, CPA, is a Managing Director at Huron Consulting Group, guiding Oracle Fusion and other full scale implementation projects. He may be reached at LinkedIn
They work together to help clients achieve successful Oracle Fusion Cloud ERP implementation projects in the higher education, healthcare, and commercial spaces.