ERP Implementation On Schedule, On Budget
Introduction
Enterprise resource planning (ERP) system implementation projects have a storied history of running over-schedule and over-budget. There are key ways to manage the project that can reduce the risk of a schedule and budget bust, particularly in the areas of data conversion and software testing. Some projects seem doomed to a budget and schedule overrun from the start, due to naïve expectations of the software buyers and from the conflicts of interest that software vendors and the system implementors who run the projects bring to the table.
Data Conversion
Moving required data from your old ERP to a new one may seem like a simple exercise of extracting data, playing with it a little, and then loading it into the new system, but it is the single-most complex set of activities on an ERP implementation and presents the single greatest risk to hitting a go-live on schedule.
Each ERP system has a unique set of complexities in how it holds data, so software buyers need to be involved in how data is mapped from the old system to the new, often driving changes to long-standing policies that were created due to limitations of an older ERP system. Clients often take the opportunity during a system implementation to change the way they name wells and leases, which can stretch out conversion timelines as decisions are made and data is updated. Some of this effort can be automated, but some require research on the software buyer’s part to pull well files or lease records.
There are a few best practices that can reduce the risk of a schedule delay related to data conversion issues as you approach go-live.
Iterative Data Loads with Accelerated First Load
Most system implementors use iterations of data loads (called “mock conversions”) to maximize the quality of data conversion at go-live. There are normally two to four iterations of mock loads, with the intent of improving the quality and completeness of the data as go-live approaches. This iterative approach allows key users to see their own data in the new system and to see the result of configuration and data mapping decisions they made, driving improved quality for each successive mock conversion. Unresolved issues are tracked with increasing scrutiny as go-live approaches to ensure that the software buyer’s project leadership team understands the risks as go-live approaches. We are comfortable saying that no ERP project in the history of the universe has had zero data issues at go-live. The goal is to focus on the issues that will cause the most difficulty at go-live and clear them before the production environment data load is done just prior to go-live. Magnum Forge follows this approach and, in addition, we recommend accelerating the first mock load (“Mock 1”) to the earliest time possible in the project. It is tempting (and common) to load Mock 1 data without having all the data ready, resulting in multiple data sets not being seen by key users until Mock 2 or even Mock 3. These are the data sets that will push your go-live back.
Key User Ownership of Data
Most of our clients approach data validation in a similar fashion: they want us to provide a structure for validating data (often this means that we prepare step-by-step procedures for validating each data set) and they want us to manage their users to validate the data as they provide sign-off on good results and note issues that go into the queue to correct. We have found that having Magnum Forge consultants perform a thorough review of converted data prior to releasing it to our clients to validate pays excellent dividends. First, if the load is so flawed that we really do not want our clients to waste their time on it, we find that quickly.
Second, we see things in the data that we want to ask our clients about that they may not notice. Third, we have a strong sense of what issues they should find and, if they do not find them, we know that key user needs help to validate future mock conversions. Your key users are busy. They have their day jobs and they have consultants hovering over them to complete their project tasks. Some will take full ownership for the quality of converted data for their modules and need little supervision. For those who do not, our supervision makes it clear that poor data validation work on their part will come back to them to be corrected – for the good of the project and to increase their ownership of their converted data.
Software Testing
Testing the new ERP system is required to make sure that the results of each business process performed in the system meet the expectations of our client’s key users. Unfortunately, poor testing is another leading culprit in a delayed ERP implementation. It may seem over the top to test every scenario for every business process your company runs but the breadth and complexity of these systems make it necessary. If testing is light, the number of issues that may arise at go-live now that you are “really testing the software” is so large that you end up with problems across most departments that bring the project team to a standstill. You can end up with so many issues for the software vendor to correct, your systems implementor to correct, and your key users to test that very little gets fixed quickly and you are forced into some difficult prioritization decisions.
We use a few best practices that help reduce this risk and also deliver ancillary benefits for our clients:
Test Everything and Use it as Extended Key User Training
The more scenarios you test early in the project, the more issues you identify long before go-live. If you operate in six states, test severance tax reporting and lease obligations in all six states. Test deep functionality scenarios like prior period adjustments for both volume changes and owner changes. The more you can flesh out early, the better the chance that the critical issues can be corrected early in the project. If you can engage your key users at a constant slow-burn of testing during the first few months of the project, they become proficient and comfortable with the new system before go-live, and can support their departments after go-live when you are trying to wind down the software vendor and systems implementor resources to stay on budget. This investment pays well as you get stabilized on the new system.
Run Complex, Cross-Department Test Scenarios
Most projects test basic, single-department business processes like creating a new lease or adding a fixed asset but running complex, cross-department business processes is often left off the list either to keep costs low or through oversight. Running the more complex scenarios leads to two positive results for our clients. First, the interaction during testing between departments tends to identify more scenarios as users ask each other about recent situations and how they would handle them in the new software. The second positive result achieved from running the complex, cross-department scenarios is the communication between key users. As they talk with each other about how things will work on the new software, they increase the key users’ buy-in for the new software and the processes that support it. These discussions also tend to drive the adoption of automated workflow tools (either in the new software or third-party), leading to better communication and fewer process stalls. Examples of the processes are creating a new well (that typically touches land, operations, division order, revenue, and JIB) and simulating a monthly accounting close (which crosses multiple areas in corporate accounting).
An important corollary to the theory of rigorous testing involves enhancements that the software buyer requests from the software vendor. Many clients go into a project with a mindset that they will request few or no enhancements to the software. This mindset is normally driven by the buyer’s desire to keep implementation costs low (the software vendor often charges for enhancements) and the belief that the software should be robust enough to handle their business needs. As the early days of the project unfold, it is common for key users to identify potential enhancements as they understand the new software better. We have rarely seen software vendors who are able to deliver all requested enhancements by the original go-live date. The enhancements tend to arrive late in the testing phases of the project, and there are always issues with the new code. If the software buyer deems these enhancements to be critical, the go-live date is at risk because the testing for this code started late, and it is new code, so it will have a lot of issues. Software buyers should make every effort to keep enhancement requests to a minimum to stay on schedule.
Expectations and Incentives
It is quite common to start an ERP implementation with some or all of the key stakeholders (the software buyer, the software vendor, and the systems implementor) knowing that the agreed-upon budget will be too little to deliver the level of quality the software buyer wants. Each player contributes to the problem. Software buyers have little experience with implementation projects and their expectations for what it will cost to have high-quality data, rigorous testing, and well-trained users are frequently too low. There are certainly software buyers who understand the real cost of professional services to run a quality project and choose to target a lower cost with the understanding that the quality will suffer.
It seems that most software buyers just underestimate the number of hours required to provide a clean go-live with few issues or they find the cost of a high-quality implementation to be too high to take to their boss for approval.
There are other considerations for software buyers. Some recognize that they do not normally buy services at this scale, so they are leery of being taken to the bank by the consultants and software vendor. We have had one client, who asked us to cut our proposal in half, saying that he would rather have us “manage him up” than for him to have to “manage us down.”
Software vendors are aware of this general problem, but have no motivation to address it during the sales cycle and project planning period. Software vendors sell software licenses and professional services (implementation and support). Some vendors focus more on services than others, but they are all clear that license sales drive the success of the company.
Software salespeople are under pressure to hit quarterly sales targets and they view a high price tag for implementation services (their own or a systems implementator’s) as a threat to the deal because the overall price tag is seen by the client as too high. When asked by a potential buyer if they really need a few million dollars in professional services, the sales person, trying to salvage the software license sale, finds it easy to say, “We have many clients who implement our software with little or no services” without commenting on the results of those projects and the level of satisfaction those clients have with the implementation.
Sales targets and incentives for salespeople mean that the software vendor has no motivation to be transparent about the cost of implementing their complex software. It is better for them that their client go-live ugly than lose the sale.
Systems implementors have a similar conflict of interest when faced with a client who is driving the hours and cost down. The systems implementor knows how many hours the client will need to be successful, but they do not want to lose the deal if the client sees the cost as too high. Systems implementors will cut the hours in their proposal to a greater degree than cutting their rates to get to a number the client will accept, knowing that the client will eventually decide they need more help and agree to a change order. We experience this at Magnum Forge frequently and we try to advise our clients based on their best interests, but if they are firm about getting the cost down, we will drop our cost to stay in competition. A recent example illustrates the nuances in these discussions. We had a repeat client who moved to the CIO role at a new E&P company and he engaged us to propose an ERP implementation. We delivered the proposal and he called our Managing Partner to advise that we were competing for this work and our competitor was undercutting our proposal by 33%. Our rates were similar, so the difference was the number of hours we each said they needed to be successful. Our repeat client said that his CFO would never approve our cost in light of the other proposal. He said he wanted us to do the work and advised us to cut our proposal by one-third to match our competitor’s proposal. He said he would “manage the CFO” once it became clear that the amount of services they needed would be higher than our proposal. The project came in about 2% north of our original proposal (prior to the 33% reduction). In this situation, our repeat client CIO knew what it would cost to run the project, but he was worried that his new boss would not and we all agreed to a project that was too lean on services to get the job done, eventually leading to a budget overrun.
Other Considerations
There are many other factors that can push out the schedule and budget of a project and are important to consider:
Stage Containment
Complex projects have a large number of tasks and many dependencies between those tasks. Stage containment is the practice of fixing all issues as they arise (that stage of the project) before moving to subsequent stages where the issue may have a greater impact or keep work in the next phase of the project from being done thoroughly or at all. A common example from data conversion is finishing Mock 1 with some data sets not converted and validated. Allowing this to happen reduces the time that you have to correct any issues when the data is seen for the first time.
Key User Engagement
There are many reasons for seeking strong engagement of key users during the project: improved configuration and data transformation decisions, more rigorous testing, and having key users who are ready to deal with most user issues in their department at go-live. Failure to keep key users engaged can lead to a lack of confidence in key users, who are often department managers, as go-live approaches. If the key users have not had strong hands-on involvement with the new software, the decisions that affect their department, and the status of open issues, they are often skeptical that the company is ready to go-live and they can influence project leaders to push go-live for a month or two, increasing costs. The more key users are involved in each project phase, the better they understand the new software, the key design and data decisions, and the process changes involved with the new software.
Learn more about keeping your project on schedule and on budget.
Email us at info@magnumforge.com to see how we can help.
