As a mission-critical system, considerable time and attention should be devoted to maintaining, improving, and optimizing your Oracle® E-Business Suite (EBS) system. Whether you’re planning for an upgrade or new implementation, looking into a move to the Cloud, completing a post-M&A consolidation, or simplifying your EBS footprint, reviewing and recognizing common Oracle project management failures and their respective best solutions can ensure that your projects succeed.
Here are eleven specific and common reasons why Oracle projects fail:
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. But proper documentation is important. 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, or potential user-borne issues, result from inadequate training in a particular EBS feature or function. Training will not only help users learn features, but it will also improve overall business efficiencies. 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. 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. 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.
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 an EBS upgrade 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.
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.
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, 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 users can understand the impact before the next one is implemented.
7. Weak or Undefined 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.
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. 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 they 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 EBS, and the more difficult future implementation and execution will be. 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. For example, 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.
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.