ERP PROJECT RESCUE
- Home
- ERP PROJECT RESCUE
Is your ERP Project proceeding as planned?
When Enterprise Resource Planning implementation projects first begin, it means the long purchasing cycle has finally ended. All those surveys, quotes, demonstrations, and evaluations are concluded. Everyone has their own idea of how great it will be to finally have a modern system. Upper management expresses their commitment to eliminate any barriers that may present themselves. There is usually a “kickoff” meeting, where estimated hours are revealed, and the timeframe is outlined.
Unfortunately, reality soon creeps in. According to a study carried out by the Gartner Group, 70 percent of all ERP projects fail to be fully implemented even after three years. Many are not even “live” after that amount of time.
There are many causes for this to be true. In the next section, we’ll examine the most important ones.
Keeping track of the project through active Project Management is crucial. Unfortunately, many ERP implementation projects fail, or take much longer than budgeted for, because companies sometimes believe they can supervise the vendor’s implementation staff without the assistance of an outside consulting project manager. For many reasons, that is seldom the case. Enterprise Resource Consulting can manage the project and get it on track
Warning Signs of an ERP Project in Need of Rescue
From a helicopter view, there are only a few factors one needs to keep track of to produce a successful ERP implementation. They are functionality, resources, and schedule. If one is watching those factors carefully from a ground view, warning signs often appear.
Here are the top ten warning signs of impending ERP implementation failure:
- Lack of cooperation
- Management team members late for, or absent from meetings
- Team members become reassigned to other projects
- Core team members failing to achieve their project commitments on time (or at all)
- Excessive functionality allocated to “phase 2”
- Fluctuating project priorities by management
- Mission creep
- Ongoing schedule delays
- Vague project status reporting
- Non-availability of accurate plan-versus-actual budget
Effective Project Managers recognize the signs of failing projects and address the root causes. There are always underlying issues. How many of these do you recognize from your implementation project?
- Lack of accountability
- Unrealistic projected completion dates
- Delays caused by management postponing decisions on crucial issues
- Postponements of project updates and/or status meetings
- Core team members taking vacations at inopportune times
- Project tasks seem to be low priority
- Project manager given responsibility without authority
- Upper management failed to get staff input before the system was purchased
- Low morale
- Excessive mention of how the legacy system is better or easier at certain things
- Excessive unanticipated programming changes
- Some users seem to be afraid for their job
- Training issues
- Infrastructure issues
- Project status seems ambiguous
- Excessive finger-pointing
- Unclear implementation methodology
- Constantly shifting project target dates
- Unresponsive project management
- Unclear or incomplete business requirements
- Difficulty finding the owner of various issues
- Project status reports are late or missing
- Over budget with no end in sight
- Project paralysis
- Indefinite expectations
- Lack of direction
- Project sponsorship is low
If your project has more than a few of these problems, it could very well be in need of rescue. Once it is realized that the ERP project is at risk of failing, we must develop a plan to get back on track. The normal tendency is to continue, and hope that the project issues will somehow resolve themselves – often while looking for whom to blame.
Assuming the hardware and software are a reasonable fit for the business, Enterprise Resource Consulting will perform a focused assessment. A rescue plan can then be created if the project is believed to be worthy of saving. It is at this point that bringing in an unbiased outside resource can be of most value. It’s important to realize that the same forces impeding progress will also cause an assessment to fail. Let’s interrupt the project and evaluate the situation.
The Assessment
Prioritization, organization, sorting, and allocation for the project must be conducted by an independent and objective outsider. Internal resources have been at it for a long time, and have proven to be inadequate. Ordering them to do better is highly unlikely to succeed. Enterprise Resource Consulting will swiftly amass and analyze the facts and the situation, and proffer a recommended course of action to upper management. The rescue package will be based on the input and requirements of the various business units. It must be be comprehensive, and consider the culture of the company. An evaluation of the original project critical success factors, as well as any business change since the original project launch must all be factored in to this assessment.
Since Enterprise Resource Consulting will be new to the situation (a good thing), a new assessment of how the software needs to be adapted to suit the business is in order. Since a great deal of time has already been expended on the new system, and everyone is much more familiar with it, the new assessment will occur much more quickly than the original one.
We’ll also need to examine the financial situation, and perform a re-budgeting of the project. The money already committed, wisely or not, is in the past.
The Rescue
It’s now time to create a Rescue Plan. Based on our assessment, we’ll “reassemble” the manner in which the project will be managed. It’s highly important for all concerned to witness the quick, successful resolution of issues, especially at the beginning of the rescue. We make sure that everyone, for the first few weeks at least, plans on working as late as necessary. Nothing propagates success like success. This includes upper management whose quick decisions will be vital to the endeavor. There is not one checklist of items which will insure success. The approach will depend and vary based on personal experience and observations of the ERC project manager.
Your Enterprise Resource Consulting Project Manager must have the authority to make and enforce critical project decisions. Here are some of the steps we’ll require.
- An action plan must be created and agreed to by all of the key players, including the software vendor.
- Institute Project Management controls including a running list of both open and closed issues. The closed issue list serves to remind everyone of the progress being made.
- There must be a regularly scheduled Project Status Meeting, with a specific agenda distributed ahead of time. Key players need the ability to add items to the agenda. It needs to be clear that meetings are mandatory. To that end, everyone should receive an Outlook reminder each week. It’s important to keep the length of the meetings to thirty minutes or less, and only review items of general interest. Additional breakout meetings should be scheduled for items pertinent to specific people. These meetings are best held immediately following the Project Status Meeting.
- Requested programming changes must be channeled through the department managers, not the users. They must be quoted by programming, and approved by Enterprise Resource Consulting and upper management. Hours spent on each must be tracked and compared to the quote. Likewise, the completion dates must be tracked and compared to the estimate. It’s very important to consider future software versions when deciding if a change should be made. The manager requesting a change must formally approve each. (An email will do.)
- One or two people opposed to change can cause serious damage to the project. The Enterprise Resource Consulting project manager must get to know everyone, and look for and deal with any potential problems. Upper management will be invaluable to this effort.
- Training must be thorough, and confined to departmental “super users”, usually the manager. Attempting to train all the users will ensure that nobody in the department sees the entire picture. If the super user is unsure of exactly what each user does, and why, now is the perfect time to learn. If necessary, they will have to find the time to shadow each user for a day.
- Some software functions are not mission critical. There should be a discussion among all the key players to decide which are better left to a “phase 2”. Make sure that a phase 2 list is published and available to everyone in order that nothing is forgotten.
- Consolidate all documentation on a common server and create a shortcut for everyone.
- Make sure that the software vendor is aware of, and on-board with all of the above. They may need to reallocate their resources, and more information will help them do that. This may impact project deadlines, so make sure to include their input at the beginning.
