Just Released: a 10 step process to help you with your next software implementation.

When a company decides to implement new software, a business case is created showing the Return on Investment (ROI) of the project. The leaders of the company agree it is a good idea to proceed with removing the current system and implementing a new system to make the business run faster, more efficient and provide transparency across business units.

Unfortunately, for many of these companies, the rollout won’t go as planned. Money will be wasted, the project will be improperly managed, and upper management may not support the project to the end. The focus will be on the technical side, the software’s capability; its bells and whistles. Preparing the organization with a training and implementation plan will be pushed aside.

The project will fail.

Don’t allow your project to fail.

My goal in writing this four part series is to share the important lessons I learned when I implemented Oracle in numerous countries. Hopefully you have read the first three articles prior to diving into the fourth and final phase of the Training and Implementation Plan. If not, I encourage you to read them. I don’t want you to feel like you are reading the end of a book without first getting to know the plot and its characters.

Whether you’re a CEO, CFO, CIO, Director of IT, Project Manager or simply involved in an enterprise software implementation, use this information to be successful. Don’t allow the project to fail because end-users were neglected and the focus was on the technology of the software.

Even if you’re in the midst of a project, you can still take certain phases of this plan to augment your implementation.

The fourth and final phase in the Training and Implementation Plan is Final User Training and Certification. As the name implies, users will be given a final session of training and then given an exam or assessment. Throughout this article I will use exam and assessment interchangeably.

Why? Over the years of preparing organizations for go-live, I found that people reacted to each word differently. If I mentioned “exam” people sometimes tensed up before taking the exam and didn’t perform well. If I mentioned “assessment” people sometimes didn’t think the word carried as much weight as “exam” and so they would not take the exam seriously. I digress.

Now that we have all four phases identified, let’s see how they look together:

Phase 1: Face to Face Training and User Assessments
Phase 2: Monthly Web Meeting and Mini CRP Sessions
Phase 3: User Proficiency Tasks
Phase 4: Final User Training and Certification

Now this looks like a thorough and well thought out training and implementation plan! Imagine taking this plan to your boss or the CIO and showing them exactly what the plan is for getting the organization ready for a new software implementation. Do you think he or she would be impressed?

Final User Training and Certification

This fourth phase is a culmination of the three prior phases. Its purpose is to certify that users are, in fact, ready to use the system on day one. How does this certification take place? After UAT has been conducted and the users have accepted the current configuration of the system, conduct a certification training session with said users in a test instance.

When should this training occur? It should take place approximately one week before go-live and the length of the training session commensurate with the amount of material that needs to be covered. It will serve as an end-to-end walk through of all the functions users will be performing in the new system.

For example, a user who is responsible for client billing will need end-to-end training on setting up the customer, creating billable and non-billable items, entering quantities, creating invoices, correcting invoices, and closing out the project when all the activity has been completed. It is important to accurately plan the agenda and segregate users by function during this training. Example: purchasing, supply chain, finance, etc. will each have their own sessions.

At the end of this training, the user will take an exam that is created and administered by the core team. The exam will be created using Google Forms (as demonstrated in Phase 3) and is a comprehensive exam that includes both practical and theoretical questions. The length of the exam and types of questions should be representative of what a user would know after using the system for 8-12 months.

If this sounds unreasonable, it’s not. The goal of the Training and Implementation Plan is to transfer as much knowledge from the core team to the user base. Wouldn’t it be nice if all of users were as proficient as the core team? If they were, go-live would be a non-event and no one would be worried about whether the organization is ready, right?

There’s a reason this plan is so comprehensive: implementing company-wide software, especially ERP’s, is not without risk. There are thousands, often millions, of dollars at stake. Not only that, jobs are at stake too. High level executives who made the decision to implement an ERP put their job and reputation on the line. If the implementation is a failure, so too are the executives — as unfortunate as it may be. I’ve seen CIO’s lose their job because of a failed ERP implementation. An average Oracle and SAP implementation will take a minimum of 1 1/2 to 2 years to implement from the time of project kick-off. This is a significant amount of time, money and resources to put on the line when it comes time for go-live.

Regarding the certification exam, the training and exams should be administered on site where the user base is located. If your company is based in the USA but is rolling out the software to a group of users in Belgium, members of the core team will travel to Belgium to deliver the training and administer the exams. The reason for this is obvious: it costs less to send a small team to Belgium than it does to send a large user base to the USA for training. To be certified using the system, users need to achieve a passing rate of 75%. Ensure a member of the core team has taken the test first and correctly answered every question. This first entry in the spreadsheet will be the “answer key”. Once you have an answer key created, you can grade the exams.

Below is a snippet of one certification exam I used during the Oracle rollouts. If you would like to see the full form, click here.

After each person has submitted their responses, sit down with them individually to review the results. If a person failed the exam, work with he or she privately to determine if the reasons were related to not knowing the content or simply nerves when taking an exam. Allow them to retake the exam after speaking with them. Always be encouraging and positive when working with the users during certification.

What if a person simply cannot pass the exam even after multiple tries? This could happen and did happen to me during rollout #1. After we completed the training session, we spoke with this person’s supervisor and advised him of the results. It was decided this person would be retrained privately and retake the exam. She ended up passing this time — barely. After go-live, we sent a member of the core team to her location to support her since we knew that her level of proficiency was low, compared to her peers. Remember how I mentioned in Phase 1 that the level of skill required to operate in systems like Oracle and SAP are often higher than what was required of the legacy system being replaced? That was the case for this person. Despite being retrained and retaking the exam, she could not adequately work in the new system. Her supervisor ended up re-purposing her to another function within the organization that did not require heavy use of Oracle.

Now that all of the users are have been certified, the four-phase plan is complete and there is nothing left to do, right? Well, not exactly. While the user base is 100% ready to go, there are still some important tasks that need to be completed before “hitting the switch”. I would be remiss if I neglected to mention that a good cutover strategy is needed to ensure the success of a software implementation.

What is a Cutover?

So what exactly is a “cutover”? Simply stated it is a move from one defined state to another. With regard to software implementations, it is the move from one system to another — for example: from a legacy system to SAP. A cutover plan is designed to minimize the ongoing risk of moving from one system to another. It is the process of identifying key activities that need to be performed prior to moving to the new system. Some examples of these activities are: loading inventory items into the new system or creating and setting up projects in the new system prior to go-live. It also includes the task of migrating code from a development or test instance to the production instance.

Once these activities have been identified, they become tasks that are assigned to key stakeholders of the project. These stakeholders can be anyone from a project lead to a controller who has to ensure the books are reconciled prior to moving to the new system. When developing a cutover plan, you will want to identify key activities well in advance so that the core team and stakeholders can agree on the tasks and be aware of when they need to be completed.

It’s a good idea to lay out this plan in both task format and calendar format. In the task format, list the following items with each activity needing to be performed:

Task name
Start Date
Finish Date
System (legacy or new)
Resource (group or person)

Everyone needs to have a copy of this task list. Ensure there is oversight and follow up to make sure the tasks are getting completed by the finish date.

While adequate planning is the best form of preparation, there also needs to be a section in the cutover plan where a critical decision is made by a key stakeholder: move forward with the new system or rollback to the legacy system. Go or no go. This means that you need to have decision checkpoints along the way during the cutover process. For example, a piece of code that was migrated to production is not working and is requiring a significant amount of troubleshooting. Do you hold off on go-live until this code is functioning or do you press forward with go-live and create a temporary work-around to this process? These types of issues need to be considered in your cutover plan.

Another key part of the cutover plan is the ramping down of business in the legacy system prior to transitioning to the new system. Projects need to be closed out, payments need to be applied to A/R balances, and items need to be received against open PO’s. There are a number of things that need to occur as part of the ramping down process. A good illustration of this was created by Mahesh Vallampati, a Practice Principal at Keste:

The graph is fairly self-explanatory but as you can see, business ramps up prior to go-live. This is due to all of the cutover activities that need to be completed (like those open PO’s I mentioned above). You can also see that productivity in the business is dropping just before go-live. This is because cutover activities have been completed and the user base is ready to use the new system. Once go-live has occurred, there is a controlled business ramp up in the new system. People become comfortable with the system and the project teams roll out parts of the system in small phases. After a period of time, business volume returns to normal and all is well within the company.

There’s also a cutover perspective from those in IT and those who are part of the core project team. Both of these groups have a set of cutover activities that need to be completed prior to go-live. This could include the migration of code, completing setups within the new system or bringing new servers online. Here’s another graphical representation from my friend Mahesh:

The activities for this group also increase prior to go-live as they are in the trenches executing the well thought out cutover plan and wrapping up last minute configurations of the system. They are utilized immediately after go-live to support business ramp-up. As activities in the new system increase and business returns to normal, the IT team moves to a steady state support of the business. As you can see with line Y-Z, there was always a steady state support of the business from IT via the ubiquitous Service Desk.

This is the cutover plan from both the business perspective and an IT/core team perspective. These charts provide a useful illustration as to what is going on within a company leading up to go-live. Feel free to use these charts to communicate to your users and stakeholders — it helps put everyone on the same page leading up to the event.

Managing Change

As with the need to mention a cutover strategy, it is also prudent that I mention another important component to implementing software and that is change management. There is a large amount of information out there on the web with regard to change management. Over 92,000 titles on amazon, in fact. Yes, 92,000. Have a look:

You might have a favorite book or theory regarding change management and I’m not here to challenge it. Therefore, I am not going to devote a lot of time on the subject. However, I do believe change management is a critical success factor for any major company project; especially for enterprise software projects.

Due to the scope of the Oracle rollouts, it was important for us to identify where everyone was on the “change curve”. The company was divided into four regions: North America, Asia Pacific, Latin America, and EMEA (Europe Middle East and Africa) and there were three planned rollouts. Latin America and EMEA were combined during the third rollout. These regions contained the end-users, the organization, a.k.a the money makers. It was these individuals who received our attention and were the most important to the success of our project.

In addition to the regions, there were company executives and members of the core team who were involved in the decision making process from the beginning. Let’s have a look at the chart below to see where people were at different phases of the project.

The project kicked off 2010 and as you can see, the executives and core team were at the height of the change curve with “Informed Pessimism” which turned to “Hopeful Realism” and “Informed Optimism” as we neared our first rollout which was in North America (Note: go-lives dates indicated by the apex of the curves). This was because they were kept informed about the progress of the project and whether or not we would be ready for the first go-live. Notice how that green line representing the executives ticks upward during the next two launches but by the third rollout their focus returned to the daily issues of running the business. By the third rollout, we predicted the executives would be returning to running the company after being successful with the first two launches.

You’ll also note how the regions reacted to each go-live. Latin America and EMEA didn’t even register a pulse for the first rollout in North America because they were still a year away. Asia Pacific showed some “Informed Pessimism” during the first launch and after we completed the North America implementation.

Our team shared this chart every opportunity we could with both the executives and the users throughout the implementation. It provided individuals with information about what to expect during the milestones of the project. With this information and the Training and Implementation Plan, it helped foster change within the organization.

On-Site Support

The final piece to a successful software implementation is providing on-site support at key locations within the organization. It’s important that a member of the core team is sent to locations where there is a large user base or a location that generates a lot of revenue/transactions. While there will be Subject Matter Expert (SME) on site, it’s still wise to put a member of the core team on site to assist with any issues that may arise. If you can, put someone at each location.

Psst! Let me tell you a secret: there will be issues at go-live. No matter how much testing or planning is done, inevitably something goes wrong in the system. Especially if it’s a large scale ERP like Oracle or SAP. I’m not referring to “show-stoppers” that halt the project altogether. I’m talking about bugs in the system. You may have to create temporary work-arounds until the bug is fixed.

Having a member of the core team on-site at go-live gives a significant morale boost to end-users. Even though you have thoroughly prepared people for the big day, there is going to be anxiety about what will happen on Day One. I cannot tell you how many times I was thanked for being on-site during the big launch and how it alleviated tension within the office.

In addition to providing on-site support during go-live, I highly recommend having a core member of the project on-site during the first month-end close. As there will be anxiety about go-live, the same can be said for the first closing of the books. Ensure there is someone on site a couple of days before the last business day of the month and have them stay at least a week after to support month-end.

Conclusion

Phase 4 of the Training and Implementation Plan is Final User Training and Certification. Final User Training and Certification should take place about a week prior to go-live to ensure information and knowledge remains fresh for the trainee. Users are allowed to retake the test as long they understand the reason they missed the questions. There is a fine balance between someone failing and then getting the answers from the core team and subsequently passing the exam versus someone who really doesn’t know the answers to the questions.

While the Training and Implementation Plan will successfully prepare the organization for go-live, it’s still necessary to have a good cutover plan to ensure all activities and transactions are completed in the legacy system prior to switching over to the new system. Be sure to create critical checkpoints during the cutover as part of the “go/no-go” decision strategy. Just because you have to rollback to the legacy system for a period of time does not mean your implementation is a failure — it means you are wise. However, continuing on with the implementation when there is a non-functioning essential feature will result in a failure unless it can be fixed quickly.

Be aware of where people are on the change curve. Communicate to them where they are now and where they can expect to be at various phases during the rollout. Use the chart I provided as template for your project.

On-site support at go-live and month-end is a success factor and will boost morale with the user base.

By now you should realize that large scale software projects involve risk, money, time and resources. ERP software is complicated. It’s bulky, rigid, unforgiving and requires custom code. When businesses choose to implement a new ERP, it has a tremendous impact on the organization.

Research has shown that a user training curriculum is always the most underestimated budget item in an ERP implementation and will typically cost 10-20% of the overall budget. It will also involve 10-20% of the personnel within the organization. Therefore:

TRAINING IS IMPORTANT

Don’t ignore the need to train personnel. It’s easy to get caught up in all the cool things the software can do but it can’t replace your workforce — no matter how hard you try. And your technical consultants aren’t the right people to train the organization. Hire the right person or firm to do the training and preparation of your people.

Don’t let your software project, be it ERP, CRM or otherwise, show up as a statistic in the “failure” category and become a Harvard case study. Instead, use this Training and Implementation Plan to be a success and let Harvard do a case study on how to successfully implement enterprise software.

Too many documented failures already exist.