Why Oracle EBS Projects Fail? and How to Fix Them - Part I

The start of a new year is often a good time to reassess the status of your Oracle E-Business Suite (EBS) environment, and how effective its current structure is to your company. As a mission-critical system, considerable time and attention should be devoted to maintaining, improving, and optimizing EBS. While most tasks are relatively routine in nature, sometimes — either due to organizational changes, updates in management and regulatory reporting requirements, or the need to upgrade — 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, 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 2016 and beyond.

Here are some 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 affects future work steps and the 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.

2. Lack of Training

Many times, the problems encountered and potential user-borne issues result from inadequate training in a particular EBS feature or function. 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 both 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 (money, 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 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.