Managing Your JD Edwards Upgrade Project: Six Practical Principles for Success

Six Practical Principles for a Successful JD Edwards Upgrade Project

Dan Barford, Vice President of Project Delivery at Terillium

When it comes to delivering a successful JD Edwards upgrade, you can forget about “best practices.” To succeed, you need real, practical techniques that involve the entire project team. Below I’m sharing the most important principles for managing your upgrade project.

Related Resources

Video: How to Plan for a JDE Upgrade

Top 10 Finance Optimizations for JD Edwards

The Importance of Having the Right People on Your ERP Project

3 Ways to Unlock the Value of CafeOne in JD Edwards

Prepare by Planning

As soon as you know an upgrade is on the horizon, start planning. Begin defining the scope and timeline for the project. Determine what type of upgrade you’re doing. Most upgrades can be placed into one of three upgrade types: technical (typically referred to as a “like for like”), functional (a technical upgrade with some additional process improvements or functional enhancements) and transformational (essentially “starting from scratch”).

Other aspects of the upgrade that you will need to define include:

  • Project “controls” – including a plan for: communicating project progress and concerns, change management, risk management, task management, issue resolution, and documentation of the project.
  • Project deliverables: what are the end results that will equal success.
  • Project resources: identify the key individuals who need to be involved, and what deliverables they will be responsible for throughout the project.
  • Define the key benefits and objectives that are important during the upgrade. Measure those benefits to determine how successful the project was.

 

An essential tool to setup during the planning phase, and use throughout the upgrade, is an online project collaboration hub where documentation, issues, calendars, action items, milestones, status reports, and other important information can be accessed by the team.

“As a leader of an upgrade project you have to first make the plan, then stay committed to the plan.”

Pick the Right Project Team

There are a few principles to keep in mind when selecting your upgrade project team. The first rule of thumb is that key resources, who you may think can’t be spared from their day-to-day responsibilities, are usually prime candidates for the upgrade project. They tend to have the most knowledge of a particular department or process. A second part to this principle is when picking your team, also make plans for who can fill in for core project team members where needed during the upgrade.

It’s important to know your executives and staff, and to pick the right personalities for the team. Along with having the right skillsets, positive attitudes can go a long way in managing a successful upgrade project. You’ll need advocates on the team who understand the project and why it’s important, these team members are often called “Change Agents.” These resources are motivated, driven and are willing to do things differently. No naysayers, please.

Other considerations that you need to include when picking your project team:

  • Core team members: the key people who will be actively involved from start to finish.
  • Subject matter experts: these resources aren’t necessarily part of the core team – they are important people who down the line can help with specific areas of the project.
  • IT team members: IT needs to be committed to the upgrade, including business analysts, system admins and other IT staff.

 

Identify the “Critical Path”

The critical path includes all the work that needs to be accomplished to ensure the functionality of critical business processes. This usually includes:

  • Retrofitting modifications to ensure functionality in the upgraded system.
  • Planning for third party integrations – what tasks need to take place to make sure these integrations work post go-live.
  • Scheduling end user training – another critical component for a successful upgrade.
  • Identifying the most critical business processes – things like payroll processing, invoicing or continuing the company tradition of 100% on time shipments.

Do ALL of the Tests (but not every time you test)

Failing to adequately test can take an otherwise successful upgrade project and turn it into a nightmare. Keep in mind the importance of documentation, testing types, and conducting a testing audit:

  • Documentation: if you don’t already have business process documentation this needs to be done throughout the upgrade project. Having a collection of business process documents is a must-have before testing.
  • Testing types: before go live the team needs to conduct unit tests, integrated tests, user acceptance tests – these should be identified as project milestones.
  • Testing audit: have someone, potentially outside of the project team, conduct an audit of the planned testing scenarios and track progress throughout testing.

 

The purpose of the testing strategy during your upgrade is to properly test the proper amount at the proper time. At the beginning, the project team should be focused on validating the upgrade, without as much concern for tracking the results of specific scenarios. As the project progresses, the testing will become more detailed, building up to a simulated “day in the life” of the business. One sign that you’re not testing enough is to look at the documentation and the list of planned tests. If it’s a short list, you might be missing something. It’s essential, too, that at least one round of integrated testing occur in the production environment. This will allow the production environment to receive a “test drive” prior to go live and can prevent issues that wouldn’t be identified until after everyone is in the new system.

During testing keep track of statistics and system performance, including the pass/fail ratio. Not everyone on the team has to be involved in every test. Unit testing might only involve IT. Integrated testing might include the core team and subject matter experts.

Place an Emphasis on Training

The training needed during an upgrade project can depend on the version of JDE you’re upgrading from – for example, an upgrade from EnterpriseOne 9.1 to 9.2 would involve less training than an upgrade from XE to 9.2.

In general, regardless of version, once users are in the system there is a similar look and feel to what they’re used to seeing. The training focus becomes General Navigation and the new user interface benefits and features. Things like UX One, Enterprise Search, Watchlists and Notifications bring immediate value.

From a tactical perspective, it’s important to think about the following for user training:

  • Who needs to be trained.
  • What topics need to be covered in training.
  • Where are the people located that need to be trained – will it be in-person training or online.
  • How will the training we delivered – will the format be classroom style or another format (consider how the people involved will learn best).
  • When does training need to take place.

 

Some training needs to happen throughout the project, and should definitely happen before testing milestones. For end-users, it’s important to schedule training at the right time: too soon before go live and they might forget some of the training, however if you wait until too late you risk end-users not being trained before go live.

Make (and use) a Go Live Support Strategy

The final phase of an upgrade is to have a strategy that includes a detailed plan for cutover, go live and end user support. This plan needs to be practiced and documented. Key considerations include:

  • Timing: how much time is needed to convert all the data and prepare the production environment for final validation.
  • Support strategy: who will team members contact in the event of an issue, and how; have resources been strategically deployed to locations or departments for Level 1 support.
  • Issue management: leverage the project collateral and team collaboration tools that have been established to log, prioritize and track issues.

 

Setup procedures that will save time and frustration, for example establish a command center with a “hotline” or direct support number to eliminate delays in reaching the right people.  Often times this means bypassing standard help desk policies for a few days after going live.  It’s important to publish these procedures so that everyone is aware of the support strategy and the operating hours for the command center.

Other Important Factors to Ensure Success

Don’t try to do too much

Some businesses try to use the upgrade project to introduce change – for example changing a certain business process. This can cause issues, prolong the project, and really put the project at risk. Projects that focus on the upgrade – then make a plan for continuous improvement (changing processes and other enhancements) tend to be the most successful. Consider building a three-to-five year strategic roadmap that includes the upgrade but also includes future improvements.

Build a strategic roadmap

The strategic roadmap includes the upgrade, along with other future plans. Document everything that is on your JDE “wish list” and create a phased approach for how you will achieve everything on the list over time.

Reward your hard working team

Team members involved with the upgrade project are going to be working late nights and on weekends. Make sure to reward and recognize them for their efforts.

It all comes back to planning

The old saying “Plan to work, and work the plan” is really relevant for upgrade projects. Managing the project all ties back to the planning. As a leader of an upgrade project you have to first make the plan, then stay committed to the plan. This involves controlling the scope and any change requests that come up. They might seem small, but they can snowball. Work the plan, don’t introduce new items or changes unless it’s absolutely necessary. While every project is unique, adhering to these principles will put you in a position to deliver a successful upgrade.

About the Author | Dan Barford


Dan is Vice President and in charge of Project Delivery at Terillium. He has over 19 years of experience helping hundreds of customers implement and upgrade Oracle applications.