11 Reasons Oracle E-Business Suite projects fail and how to fix them

tel: 407.591.4950 | toll-free: 1.888.943.5363 | web: www.eprentise.com
11 Reasons Oracle® E-Business Suite
Projects Fail (And How to Fix Them)
an eprentise white paper

11 Reasons Oracle® E-Business Suite Projects Fail (And How to Fix Them)
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 2
© 2014 eprentise, LLC. All rights reserved.
eprentise® is a registered trademark of eprentise, LLC.
FlexField Express and FlexField are registered trademarks of Sage Implementations, LLC.
Oracle, Oracle Applications, and E-Business Suite are registered trademarks of Oracle Corporation.
All other company or product names are used for identification only and may be trademarks of their respective owners.
Author: Helene Abrams
Published: January 09, 2012
www.eprentise.com

As a mission critical system, considerable time and attention should be devoted to maintaining,
improving, and optimizing your Oracle E-Business Suite (EBS) system. While most tasks are relatively
routine in nature, sometimes—either due to organizational changes, the need to upgrade, or due to
changes in management and regulatory reporting requirements—a change is needed in your EBS system
that requires the initiation of a more complex project.
Even with the best of intentions, planning, and hard work, complex EBS projects can fail for a variety of
reasons. Whether you’re planning for an R12 upgrade or reimplementation, completing a post-M&A
consolidation, implementing OBIEE or Hyperion, or simplifying your EBS footprint (or more), reviewing
and recognizing common Oracle project management failures and their respective best solutions can
ensure that your projects succeed in 2012 and beyond.
Here are eleven specific and common reasons why Oracle projects fail, including advice on how to prevent
them in advance.
1. Poor Documentation
Many well-intentioned teams start their project planning and implementation process with good
documentation practices but get distracted or lazy into the project. Proper documentation is important
for several reasons:
 Tracking decisions made and reasons for making them
 Tracking changes to the scope of work and how it effects future work steps and final product
 Educating users on successful post-launch usage
 Helping future teams understand your work, reasoning, and specific implementation steps
 Identifying opportunities for greater efficiency further into the project, or the next go-around
Create a standard for documentation at the beginning of your project, and hold team members
accountable for completing documentation requirements as well as keeping them at and above the
standards required. Consider using a Run Book as well to document what steps are done and how long
they’re taking as a look-back for current and future users.

Figure 1: Sample of a Cutover Run Book
2. Lack of Training
Many times the problems encountered or potential user-borne issues result from inadequate training in a
particular EBS feature or function. For example, many users started using project accounting in R10, aren’t
familiar with the new features and reports, and don’t feel that they are able to track their projects
accurately without a project segment in their chart of accounts. A week of training will not only help users
with new features but will improve overall business efficiencies.
Oftentimes, this includes multi-media presentations, live demos, and hands-on practice to get users
familiar and comfortable with the day-to-day and periodic tasks they will be required to execute moving
forward.
Before promulgating user documentation or training, it’s also a good idea to choose a representative
from the among the business users base to review materials first. Ideally this should be someone who
uses EBS on a daily basis. They can help you see the materials from an end-user point of view and can
help make adjustments to ensure that the training, documentation, and instructions are user-friendly and
will lead to a successful training.
3. Unrealistic Budgets or Timeline
Just because your organization requires a major Oracle EBS improvement project—even if that project has
already been funded—doesn’t mean that all required budgets have been adequately identified and
secured. Too often, budgets are unrealistic and too low for the work required. Before starting any

significant project, ensure all resources (dollars, people, etc.) are identified and available during the
expected project duration.
If your project is underfunded, it’s at risk for not being completed. Go over budget and the extra
expenditures could deem the project a failure (no matter what the other outcomes). Underfunded
budgets can also force you to cut corners (like shortening or eliminating test phases) that could increase
the risk of errors and unintended outcomes.
After building your first draft of the project budget, go through and ensure you’re not being too idealistic
about timing, resources required, and whether or not you need outside help to complete the project. Be
especially thorough in reviewing the need for outsourced resources to help with implementation or other
specific steps/components of the project, and include in your budget who is responsible for monitoring
and tracking those resources as well. If you are not sure about the resources and budget required, obtain
several estimates from people that have experience with the same size and scope of your project. It would
be unrealistic to expect that your team knows what a reimplementation project would look like, or how
much it would cost, if they’ve never done a reimplementation.
Many project managers are successful in estimating hard dollar costs of their projects, but they fail to
adequately identify and secure the “soft” costs, made up primarily of allocations of existing, internal
resources, of the project . Without budgeting for all hard and soft costs, your project may become
significantly delayed or come to a grinding halt altogether. Underestimating the budget is generally not
intentional, though consulting companies will sometimes “lo-ball” the estimate, assuming once they are
into the project they will be able to do change requests and increase the costs.
4. The Right Resources Aren’t Assigned or Available
It’s difficult to participate in a project and also do your regular job. It sometimes seems that a few people
in the organization are asked to do everything. Be realistic when assigning people to different project
responsibilities and allocating their time, and recognize when external skills would be more efficient even
though the cost might be higher. For example, hiring resources for the upgrade to R12 may seem more
expensive than having your DBA try to do it internally, but consultants who perform upgrades day-after-
day develop a variety of “lessons-learned” and ways to streamline the process. Additionally, it does not
make sense to have your internal DBA spend months on learning to do something that he or she will
never need to do again. The time could be better spent on other projects.
Be explicit, before beginning the project, what internal resources are required for execution. This includes
people, infrastructure, hardware, and software. Even if new allocations and additions aren’t needed (that
would require hard dollars), it’s important not to assume that existing resources can quickly or easily be
allocated to your project.
Think through the different roles required to execute as well as the required in-project time and duration
of the project. Then secure commitments from these resources and their owners/managers before
implementation.

5. No Project Champion
Few complex, large-scale Oracle projects are ever successfully completed without someone in the C-suite
or other high-level position endorsing and prioritizing the project and its outcomes for the business. Your
executive sponsor is critical in ensuring that other lines of business and cross-departmental resources are
made available and prioritized to successfully plan, manage, and complete your project.
This is particularly important for IT projects, where dependencies across business units can make or break
both the success of the project as well as how quickly and efficiently it can be managed and implemented.
IT can initiate many different projects, but without the support of the business they won’t be successful. A
project champion can help prioritize projects based on the business needs and then promote the
successes within the organization, both in terms of measurable results and in obtaining buy-in from
different parts of the organization.
Help the project champion understand the impact your project will have on the organization and how its
successful completion will make him or her an internal hero or heroine for supporting it.
It’s also important to ensure that the project champion and executive sponsor understand the scope and
resources required to achieve the desired business outcome. This understanding will ensure that
resources are available both at the beginning and throughout the course of the project. Otherwise, it’s far
too easy for other priorities to creep in and steal critical implementation resources.
6. Scope is Inappropriate
Many ambitious project managers try to bite off more than they can chew. For example, it’s often much
easier to test and verify a single ERP vs. multiple areas at once. It’s probably not the best idea to change
operating systems, upgrade to R12, and change your chart of accounts all at the same time. You are
shooting at a moving target that introduces a lot of instability with each of the processes. Isolate changes
so that they can be tested individually and the users can understand the impact of one change before the
next one is implemented.
Break up your project into smaller projects (try for projects that can be completed in 4-6 months,
especially early on) to get success and demonstrate momentum. Those early wins can often gain
additional credibility and resources to tackle bigger chunks of the entire project. Long projects lose
momentum, delays occur because of changing priorities, the requirements change, budgets get cut, and
resources are reassigned to the next project or leave the organization, so costs increase.
7. Poor or Inappropriate Metrics
If you know the outcome you’re seeking, you should also be able to define it. And if you can’t define
success based on a single or small set of key metrics, it will be difficult not only to “sell” the projects
internally to those who will approve budget and resources, but also to communicate success and
completion at the end of the project.

Appropriate metrics include benchmarks and baselines for where you’re starting, in addition to success
metrics at the end and key milestones along the way. Use all three of these metrics (baselines, milestones,
and completion metrics) to make your case up-front and rally budget, resource, and executive support.
Specific metrics to focus on include return on investment (ROI), cost savings, and resource reductions.
Include reduction in the number of staff or time required for a particular operation (like reducing closing
time from 8 days to 3 days, or days sales outstanding from 20 days to 9 days) and reduction the number
and complexity of spreadsheets required. Tie the project to metrics identifying cost savings.
As you communicate metrics at various stages of the project, leverage a communication plan created up-
front that details who needs to know what, the levels, channels, and frequency of project update
communication, etc.
8. Lack of Adequate Testing
Problems will always pop up if you haven’t adequately tested not only the completion of your project, but
also the use cases of those who will be interacting with the software on a daily and periodic basis moving
forward. Be sure to build a test plan that includes both the day-to-day activities and the periodic activities
– financial reporting, currency revaluation, patch application, and so forth – so that ongoing product
support and success isn’t compromised.
We have one customer that successfully executed a chart of accounts change by completing the mapping
autonomously, resolving all exceptions, and going into production with zero errors. However, the team
managing the project didn’t engage the users at all—they had done no testing until after the new chart of
accounts was in their production system Monday morning following the go-live. It was not a happy
situation, and the well-intentioned IT person who did the work actually had to roll back from the
production environment, give the users time to test, and then go live again a few weeks later.
Make sure that your testing includes reports, upstream and downstream interfaces, customizations,
enhancements, and workflows. Be sure to budget for testing resources in your up-front planning and
resource allocations as well.
9. Change of Personnel
Especially for long-term and complex projects, it’s inevitable that the people involved will change. Key
people get hired away, change organizations, quit, retire, or otherwise leave the project. Without
adequate planning, documentation, and role definitions, these personnel changes can not only grind
execution to a halt but also make it incredibly difficult to pick back up the project and/or key components
without adversely affecting execution and budget.
Ensure not only complete documentation of each contributor’s role but also ongoing status reports of
what’s been done, what’s left to do, what issues new personnel need to be aware of, etc. If possible,
ensure that comprehensive transition reports and meetings between departing and incoming personnel
are completed as well.

10. Trying to Implement Overly Complex Solutions
It is tempting in many Oracle EBS implementations to over-engineer custom solutions, especially when
unique business needs and requirements are involved. However, the more custom you make your
implementation, the more you get away from the core functionality of E-Business Suite, and the more
difficult future implementation and execution will be.
For example, many companies (as they grow or go through M&A activity) end up with multiple instances
that are either separately managed or tied together through complex, custom bridge systems and
reporting tools. Instead of spending time and resources implementing third-party reporting, consider
consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a
consistent calendar.
Don’t assume that what couldn’t be done two, three, or five years ago can’t be done now. Start with your
business requirements and research specific solutions on the current market that can more elegantly
address your needs while staying as close to the native functionality of Oracle and E-Business Suite as
possible.
11. Not Understanding the Business Drivers For Change
Too often, IT projects become a standard part of doing business (especially in large organizations) without
being rooted in business drivers and objectives. Take the time up front to plan the project and to ensure
consistent understanding and consent on the business drivers requiring change.
Is the project focused on helping the database-driven organization keep up with the pace and growth of
business operations? Remember that a successful project will change the way the business operates.
Those changes often necessitate new processes for complying with regulatory requirements, additional
procedures for governance of shared data, and mitigation of new risk factors. Include governance, risk,
and compliance management as part of the project plan.
Engage the business users directly, at the beginning of and throughout the project, to avoid isolating IT
projects from the business users and their objectives. Leverage your product champion and ensure the
right people are all engaged and on board up front. The IT department of one of our large customers had
planned to consolidate their instances for several years; however, it wasn’t until the business made a case
that the project got funded.
Just as important, keep those business drivers top of mind for the entire execution team over the course
of the project to ensure that changes and triage don’t happen in a vacuum. Constant reminders of
business drivers help to prevent consideration of overly-cumbersome changes when a more elegant
implementation (simpler reporting, single instances) can serve the same purpose.
Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs
without looking at the big picture and what was accomplished.

Curious?
For more information, please call eprentise at 1.888.943.5363 or visit www.eprentise.com.
About eprentise
eprentise provides transformation software products that allow growing companies to make their Oracle® E-Business Suite (EBS) systems
agile enough to support changing business requirements, avoid a reimplementation and lower the total cost of ownership of enterprise
resource planning (ERP). While enabling real-time access to complete, consistent and correct data across the enterprise, eprentise
software is able to consolidate multiple production instances, change existing configurations such as charts of accounts and calendars,
and merge, split or move sets of books, operating units, legal entities, business groups and inventory organizations.

11 Reasons Oracle E-Business Suite projects fail and how to fix them

More Related Content

What's hot (18)

Similar to 11 Reasons Oracle E-Business Suite projects fail and how to fix them (20)

More from eprentise (20)

Recently uploaded (20)

11 Reasons Oracle E-Business Suite projects fail and how to fix them