Oracle Tier 1 Consulting Partner
Fulfillment Management
Apparel Managment
Support On Demand
Linked In

JDE Internal OneWorld Implementation

The Battle of Project PROOF

Payoff Idea

Do the very thing they recommend to their customers - improve operational efficiency, operational effectiveness, and the bottom line through intelligent application of the product's capabilities. That's the crusade that JD Edwards embarked upon. During an interview with Brian McKeon, JDEdwards' Group VP of IT - Application Services, we spoke of the challenges even a software house has when implementing their own software. Mr. McKeon shared what JD Edwards learned when migrating from one version of the software to another, how they adhered to the "no modifications" rule, what the most difficult process was, and how they would have done things differently to obtain the global perspective. Get a perspective on how even the bravest system implementation soldiers, and generals, will admit the difficulty of staying on time, on budget, and within scope of the original plan. Learn how Mr. Joe Customer is not the only warrior fighting the implementation battle and how JDEdwards team structure and steering committee commitment helped them weather the storm and end up under budget. As of June 2003, JD Edwards' implementation is complete and they are in what Mr. McKeon called "stabilization" mode. See how the battle of PROJECT PROOF was won.

The Territorial Army

In 2001, J.D. Edwards, one of the world's top 3 providers of Enterprise Resource Planning software, began the process of calling all soldiers across the empire to duty. The company began an 18-month project to upgrade internal systems to a single technological platform and to improve process integration. The software itself provides an unprecedented level of functional integration and technical flexibility. J.D. Edwards had always used its own software, but had not implemented it in a fully integrated, process-driven manner. Project PROOF provided a single, integrated, web-based platform for J.D. Edwards's primary production systems and to facilitate process integration while showcasing our latest and greatest software. In essence, it is PROOF-positive that OneWorld® serves as an ideal foundation for Process Reengineering to Optimize Operational Functionality.

Targeted applications included call handling, sales order processing, maintenance billing, revenue accounting, time entry, contract service billing, fixed assets, accounts payable, procurement, expense management, financial reporting, payroll, HR, and others. J.D. Edwards's production systems run on a central computer complex located in Denver, CO. Most applications were global deployments with users in each of the company's operating theaters - US, Canada, Latin America, Europe / Middle East / Africa (EMEA), and Asia Pacific. Depending on the application, the number of users can vary to include the entire employee population of over 5000.

The medals of honor for this project would be given for achievement of the following key performance indicators:

Toward that end, the team was organized by process area (Procure to Pay, Order to Invoice, Manage the Business, Workforce Management, and Services) and for each process area there were two leaders - an IT Team Lead heading the corresponding systems configuration and implementation team, and a designated user organization director / manager responsible for the users who provided subject expertise and conducted user-based tests. Over the whole project was a Steering Committee comprised of Executive VPs responsible for each of the organizations involved with this project - Sales, Services, IT, HR, Financials, Support, and International.

Project PROOF's objectives were varied and sometimes conflicting - establish technological infrastructure, mature the product, support process integration, showcase OneWorld®, and support the strategic initiatives of J.D. Edwards. One significant by-product of this project is that the company's senior executives now have actually experienced an internal implementation of their software and can now relate much better to the customers in this respect.

Shape, Respond, Prepare Now

Assessing the strategic environment, the generals of this army determined the possible opportunities and challenges. Therefore, in the early part of 2002, J.D. Edwards's management team established four focused strategies that would drive decision-making throughout the organization:

The executives also recognized that the underlying tactics to support these strategies would require a technological infrastructure embracing a new level of systems and organizational integration.

Although J.D. Edwards has always used its own ERP software to support back-office operations, implementation of various applications over the years had evolved in a silo fashion mirroring the organization itself. This also had an impact on marketing because the internal implementation of J.D. Edwards World and OneWorld® software did not represent what was recommended to customers. Some production systems were based on World Software and some were on OneWorld® software. Thanks to the co-existence capabilities of these products, a single integrated database was used. However, the original implementations tended to focus on the specific applications each was intended to serve, and were not carried out to take advantage of the degree of integration afforded by World and OneWorld®.

The PROOF project was specifically intended to address the issues of integration and standardization. Representatives from all geographies in which J.D. Edwards operates were included on the PROOF team. The project team was comprised of process teams, each of which was specifically responsible for all applications within a given major process area. Process owners were identified and assumed major responsibility for effecting the process enhancements necessary to drive operational efficiency, including process integration across functional boundaries.

Divide and Conquer

Mobilizing early is what saved Finland from the Soviet troops in October of 1939 when the Soviets were stopped at the Finnish prepared positions. But what do you do when the enemy is already in your homeland? Similarly, besides concentrating on the corporate strategies, PROOF project planning also had to accommodate the following:

The PROOF Project's scope includes the following:

Generally speaking the deployments were originally scheduled by geography although there are several exceptions for specific applications:

PROOF Deployments
Geography Timeframe
US/Canada September - November, 2001
EMEA April - May, 2002
Asia Pacific July - August, 2002
Latin America September - October, 2002

Regardless of the timing, representatives from all geographies had been actively involved in the project from the beginning.

I. Execution Route

  1. Line of Attack
    • The PROOF battalion had a choice of using either J.D. Edwards's Implementation Approach Methodology (IA), or the more recently developed OneMethodology. Considering that the bulk of the project work involved migrating existing systems from World to OneWorld®, that the team members were already intimately familiar with the product, and that a number of implementation activities were already underway, the consensus was to use IA. However, considering the process improvement focus of the project, the Solution Modeler tool (which is an integral part of OneMethodology) was utilized as much as possible to facilitate process design and review. Mr. McKeon commented that "This decision supported our strategy of making use of the JDEdwards' products, tools, and people". This may be an appropriate methodology approach for a World customer thinking of migrating to OneWorld. It allows for the better of 2 proven methodologies to be used while making efficient use of intellectual property and existing tools.
  2. Assembling the Troops
    • Just as the British were challenged in World War I to bring the Commonwealth nations together as one, determining JD Edwards' Project PROOF team makeup presented interesting challenges. The project was based in Denver, Colorado. Most of the Application Services organization was already involved in various aspects of implementation and/or support of existing production systems, so it was a natural choice to include most of these individuals on the PROOF Team.
    • Considering the key objective of driving internal processes towards best business practices, it was critical to identify senior managers in user departments to serve as process owners for the major process areas addressed - OTC (Order to Cash), MTB (Manage the Business), PTP (Procure to Pay), WFM (Workforce Management), and Services. These process owners identified individuals within their organizations who would serve as team members from the user organizations "and bridge the gap between business and IT," as Mr. McKeon explained. "This bridge is 1 of the 2 reasons the project was a success".
    • The entire team structure was defined to facilitate and stimulate communication. Frequent (weekly and bi-weekly) meetings were held with various segments of the PROOF team to ensure that all interested parties are apprised of the latest thinking and plans.
    • The effectiveness of the implementation team would have been significantly muted, however, without the support of a strong Steering Committee. Mr. McKeon repeatedly emphasized this as the other reason for Project Proof's victory, i.e. the importance of the PROOF Steering Committee role and structure. The committee consisted of the senior executive responsible for each organization impacted i.e., it is comprised of J.D. Edwards's CFO, CIO, Executive VP of Sales and Services, CTO / Group VP of Development, VP of Human Resources, VP of Customer Advocacy, Director of International Operations, a field Consulting Services Manager, a field Global Enterprise Manager, and the PROOF Project's Program Manager. "Project status meetings were placed on the schedules of the executives one year in advance. Additionally, the meetings were held at 7AM before the work day began in an attempt to minimize distractions. Lastly, the meeting would be rescheduled if more than 1 officer was not able to attend." When Mr. McKeon was challenged about difficult it must have been to keep the execs focused, especially during these turbulent times in the software industry, his response was "budget constraints and the 'check and balance' of their peers helped keep them motivated. Also, very experienced project managers got the issues to the execs before the meetings so that preparation was possible."
  3. The March of the Foot Soldiers
    • In accordance with the J.D. Edwards Implementation Methodology, the project was divided into the following six major phases: Define, Train, Configure, Model, Go-Live, Refine. This methodology also included using a phased, activity-based approach as depicted by the diagram. Mr. McKeon explained, "A workshop is generally for defining and refining business processes and our action labs are about defining data. Very similar to our software, we've separate the data from the applications. Next, we have the Project Management Tool, which is the heart of OneMethodology. Not only is it the tool and repository for managing the project, it's also used to scope and estimate your project as well as be the central hub for communication between the project team."
    • The CIO and Steering Committee closely monitored the following key performance indicators:
      • targeted go-live dates
      • on-time / on-budget delivery of application deployments
      • related process enhancements
    • Whether or not to create prototypes has always been a source of debate among veteran implementers. Mr. McKeon credited the demo-ing of the software before going live as a key step in the lifecycle of the project.
  4. Environmental Hygiene
    • Imagine the difficulty in maintaining worldwide environmental order during wartime? It’s like trying to implement effective and user friendly software while maintaining the “global vanilla” rule. This seems like a simple goal but it had far-reaching implications. “Vanilla” in this case meant no modifications to package programs. New reports were defined and development of some interface programs were developed, but this did not involve modification of any OneWorld® programs. In a few cases, after approval by the Steering Committee, ancillary programs were developed to satisfy a requirement for which there was no reasonable workaround.
    • In order to maintain the “vanilla” rule, a formal procedure was established for requesting changes:
      • User submitted proposal for change including justification for the request
      • PROOF Program Manager submitted related impact statement – negative / positive impact proposed change will have on project timing, costs, resources, etc.
      • Request went through approval process up to Executive VP responsible for that user organization
      • If he/she approved, that Executive VP presented proposal to the Steering Committee. Typically, a designee was present to discuss details and defend the request.
      • This procedure emphasized the fact that only absolutely essential change requests would be considered, and that senior management was actively engaged and held each other accountable for the business justification.

II. How to achieve those medals of honor?

Brian McKeon spoke of these as critical success factors:

  1. User Engagement
    • This was accomplished by virtue of the "process team" setup. Process Owners have responsibility for process change, process and system validation, final system acceptance, etc. Team Leads are responsible for delivering the system specifically configured to support the operational processes for their respective areas. Collectively, all Process Owners and Team Leads worked with the IT counterpart to ensure that the final product supports the targeted levels of integration across functions, geographies, languages, and cultures. However, when asked what he would have done differently in retrospect, Mr. McKeon responded, "I would have made each power user's bonus contingent on the success of the project."
  2. No new modifications; eliminate old ones
    • The final tally of modifications that were approved represented 10% of those that were submitted, per Mr. McKeon's estimations. The rest of the requests as well as old modifications that were not ported over during the migration resulted in a process change. "Each process change actually took place because the executives made sure it did", said Mr. McKeon.
  3. Control Scope
    • Mr. McKeon credited the involvement of the executives and the strict software modification review process as the reason this was achieved. "Project PROOF was completed 1 month over but under budget."
  4. Active and consistent executive support
    • While this theme resounded, Mr. McKeon would have changed 1 element of the team structure. "The project was deemed as an 'IT project' because the CIO was the sponsor. User acceptance would have been less of an obstacle if the CFO or COO was the project sponsor."
  5. Maintaining Global View
    • The PROOF Team was challenged to balance communication of sufficient information to keep the EMEA, Asia Pacific, and Latin America extended-team members fully apprised without overwhelming them with superfluous information.
    • Each Process Team had established scheduled conference calls with their international counterparts. These calls were conducted two to four times each month. In addition, cross-functional teleconferences are conducted two to four times each month. These typically involved representatives from all process areas - team members, users, managers, and any interested parties.
    • The results weren't exactly as planned however. When asked what JDEdwards would have done differently, one of Mr. McKeon responses was that "gathering all international requirements in advance would have been very useful. While we had a good idea of the localization requirements of each nation, the unique legal requirements, which had to be accommodated, were challenging given the phased approached by geography. If we know about them up front, appropriate actions would have avoided some difficulties."

III. No man's land

  1. The land between the 2 front lines
    • End user buy-in to the concept, timing, planning, etc. is critical to any implementation project. User representatives from those regions were identified and through teleconferences and correspondence, they were kept apprised and their input was solicited. They were involved, but not fully engaged - a critical difference which does impact buy-in, which in turn over the long run impacts the perceived credibility of any implementation's core team members. Mr. McKeon blamed this on the project deadline and localizations. "Both served as an excuse not to follow the 'Enterprise Model'."
  2. The Wild Cards
    • Throughout the life cycle of any project, there are always unanticipated events and influences that must be dealt with. Those that faced the PROOF team were:
      1. JD Edwards' acquisition of YouCentric, a CRM product - PROOF would have to upgrade to new systems software that included an unusually high number of enhancements. Undertaking such an upgrade in the middle of an implementation project is normally not recommended and is guaranteed to cause significant delays. Delay of the CRM project was not an option and showcasing our latest product and software environments was an executive objective, so there was really no choice but to expand PROOF's scope to include this additional work.
      2. Achieving the tender balance of using the individuals with appropriate skills, determination, intelligence, and vision on Project PROOF while they were maintain company profitability and growth. Also, a number of field consultants were members of the PROOF team, in spite of the fact that their remaining in the field would have made it easier for their managers to achieve mandated revenue targets.
      3. The objective is implementing an appropriate solution, not meeting a particular schedule. On several occasions, go-lives had to be postponed for various reasons - tests identified critical errors, user organizations required additional time to complete training, other critical tasks prevented user organization from providing necessary levels of support, etc.
    • The decision to postpone a go-live is always painful, but the feeling of failure is substantially offset by the knowledge that forcing the issue would have made matters much worse.

IV. Adherence to Budget

Overall, in spite of some delays in go-lives, actual costs have remained below budget.

Whatever happened to those generals?

Now the million dollar question - Having lived through an implementation of their own software, what was the biggest lesson the executives learned? Mr. McKeon responded, "A better understanding of the SAR (Software Action Request) escalation processes, and the impact the software updates, service packs, and releases have on the customer." He went on to explain that the PROOF team "beta-ed" the updates and had to wait in the same queue as the customers for requested enhancements.

Victory is Declared

Why did JD Edwards do it?

There seemed to be 2 predominant reasons - first and foremost - sell more software. Mr. McKeon pointed out "Strong reference potential, mature and evolve our web product, better understanding of the customer experience, drive internal processes toward better business practices, lay the foundation that allows the company to meet future needs."

The second was that JD Edwards is the best example customer with:

Why should anyone else do it?

Whether it is JD Edwards or any other software you decide to implement, the essential element is that you decide, decide to continuously strive to improve your technological infrastructure, decide to support your industry's best practices, and decide to maintain your company's value proposition to your customers.

No project is ever absolutely perfect. Each will have their own nuances that will teach each project member - from the foot soldier all the way up the ranks to the general - yet another lesson to add to the never ending "Implementations Dos and Don'ts" list.

About the Author

Joanne Ferrier is the Business Development Manager for Minardi Consulting Group, a J.D.Edwards alliance partner. Joanne also teaches at St. Peter's College and the University of Phoenix Online.