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.
