If you are reading this article, most likely you fit into one of two categories right now: a) you’ve been chosen by your organization to be one of the leaders to kick off an ERP system change-out project for your organization, or b) you’ve just come through one, and are wondering if anyone else has experienced what you’ve just been through.

Most likely, you have already read a lot, or have been through a lot on the subject matter, so I’m not going run through the already publicized lists available around the web. I have chosen several lessons below that hit me a little stronger than all the rest, and ones that had a large impact on our team as we progressed through our project.

Whether you view your company’s selection of you for the ERP Team as a curse or a blessing, one thing is for certain – you will arrive on the other side a more seasoned and different person professionally. The time you spend with a core group in a cross-functional manner with full dependence on one another will change the way you think and interact in the workplace. Knowing that a miss-step on your part can have large impacts on the health of the organization after Go-Live can be sobering, but on the flip side – knowing that getting it right means that your company can be more profitable long-term, can be hugely rewarding.

So, let’s review a few lessons I picked up along the way, that will hopefully help the next team up to bat for this workplace challenge and opportunity:

1. Picking the Team is Critical

If you happen to be in a position of decision making on who will be on the team to bring a new ERP system on line for your company, take the time to do this action item well. Your ultimate level of success depends upon it.

YOUR INTERNAL TEAM:

• Resist the urge to pick only the most seasoned and most respected members of the organization. First off, they are busy people, and no matter how much commitment you might get to have them on the team, they may be little more than internal advisors rather than team doers. Secondly, they may not be great team players, and lastly, they may just be the hardest to convince that we need to make a change in the first place.

• Take a chance on several “unknowns” for the team. They may be new comers to the organization, or younger staff that is just getting started. You will find them inquisitive, having different experiences to draw from, and less inhibited by the “we can’t do it that way” thought process that typically manifests in those with the company for a long time. Either way, you will bring balance to the team, and more than likely a much needed “hidden” talent or ability that the team will really be in need of.

• Choose strong and courageous functional team leaders. Select leads that think through the problems and who are willing to speak their mind when they know they are right, but also able to allow others to help them understand or change direction when needed. Choose team leaders who are not afraid to roll up their sleeves and work at getting things done and are committed to the necessary deadlines.

• Make sure that any part time or full time internal team members you choose are 100% behind the overall project. The last thing you need is a team member acting in a subversive manner when interacting with the rest of the organization, and casting doubts on the reasoning and the finished product in the minds of co-workers. If a team member doesn’t truly believe in the project, don’t let them on it, even if they are the most knowledgeable.

YOUR EXTERNAL TEAM:

Just as critical as the team the company assembles internally, you need a very strong team from the outside. Let’s face it, if a company and its staff goes through a major deployment project more than twice in a career – you probably picked the wrong software in the first place. That also means that you will struggle with the experience needed to do this right. You need partners that can make sure you are successful and point you in the correct direction when you are wrong or just don’t know what to do next.

• Make sure the solutions partner has experience in your industry. The last thing you need is a third party who knows nothing about the industry you work in and what is important in it. Since this is usually decided fairly early on, do the research on the consulting / deployment team before the software demo is conducted. Does the third party have the critical to success elements your team needs?

• Investigate the actual consultants that will be imbedded with your staff and require sign-off on each one of them before kicking off the first phase of deploying the chosen software. Make sure each consultant has worked on several deployments of the chosen software. The last thing you need is a high priced consultant with only 20% more knowledge than you on the subject matter. Our team did this due diligence, however there were still several items we didn’t bargain for, that I would like to warn the reader of:

1. Find out how long the recommended consultant has worked for the company you are working with. The software consulting world is one where many are “hired guns” and go where the next project takes them. Fast growing consultant firms or software partners many times resort to locating available resources outside their core team to join a new project. We found this to be very problematic as the consultant’s team did not work well together and did not use the same systematic tools / methods across functional groups, when the team that was assembled for us was not all from the partner company. You want to know that every recommended team consultant has worked through at least one project for the company before signing off on them.
2. Build it into your contract that unless both parties agree to a change, that the starting consultant(s) must finish the job, and will not be permanently moved over to another project that is starting up during yours. While a consultant can and probably will be engaged on more than one project during the timespan of your deployment project – you need them there, you will need the synergy of having a common consultant. It will ultimately cost you less billable hours also.
3. Know where the home base is for your consultants. You could be paying up to 8 hrs per week in travel costs if they are coming from half way across the country. If they are – you’ll never get a full week of “boots on the ground” with you.

• Find out if your solutions partner has a separate consultant team that is deployed to work on and solve post Go-Live issues. If so, build it into your contract to have them come in and audit all of the modeling and setups of your system at several points along the project. On the most recent project I was on, we had multiple issues that caused a lot of problems that could have been caught way before launch, just because that team sees all of the problems after the fact – find out what kind of lessons learned loop exists within the consultant organization between modeling consultants and the post Go-Live triage team. If they can’t present one – develop your own process to use and triangulate information from both consultant teams. This was one of the biggest things we learned way too late.

2. Strong Management Engagement Throughout is a Must

As a team selected and tasked by an upper management team, it may be all but impossible to unilaterally red flag a project and stop work if you don’t think you have full management and organizational support, but having that support all the time and at 100% is vitally important.

If the team is not “feeling the love” from everyone on management and believing that the management team has just as much at stake as you do in the success of the project – there should be some way to hit the pause button and figure out how to proceed.

First indications of strong support should come from the simple observation of where the requirement to do this project is coming from. A good upper management team will be the ones that recognize the need first, and begin the challenge to make the change. If an IT team or other is the one beating the drum for the change project – then beware of long-term support issues.

Because a project of this sort tends to be a very long duration, attention fatigue is bound to set in. Other issues in the organization begin to compete for resources as the project drags on. Potentially, financial pressures start to draw the management team to focus attention elsewhere. Any or all of these things are potential signs of problems ahead.

Another indication of waning management support is attendance at pre-determined report-out sessions. If you are not getting 100% attendance, along with active Q&A sessions where tough questions are presented, beware of the attention fatigue. Also, management should always be asking what they need to do to help in an identified situation, not just asking what you as a team are going to do about it.

Typically, as a project draws nearer to the Go-Live date, more and more resources need to be pulled in to get it done and to also prepare the entire organization for the coming change through testing, training, etc. If there is any hesitancy at all to commit to those resource needs as things come to a head – beware…

A project of this magnitude and overarching impact on the organization HAS to be priority one.

3. You Must Master Change, Just not Manage It

As we began our ERP project, we understood the concept of managing change; we understood that it was important to set expectations, develop a culture of “change is good” and to keep communication open to help the organization prepare for it. We even contracted outside help to consult and run sessions with sub-teams to help them prepare for change. We thought we were pretty much on top of the game with this risk element.

However, change comes in many different forms, and quite frankly some things that “changed” for us were things we just had no control over. The cumulative effect of those change elements began to take their toll, and ultimately hurt the outcome for our team.

When you consider managing and mastering the impacts of change as you go through what could be a multi-year project, consider everything that could change for you, and what your response needs to be to it. Ask yourselves, what will be the point that we re-evaluate the entire project if a change element(s) occur?

Here is just a partial list of things that happened during our ERP implementation project:

1. The company went from being very profitable when we started the project, to consecutive years of losses
2. The finance consultant changed (5) times
3. Nearly 50% of the upper management staff departed the company, including the VP in charge of the project
4. Several key part-time team members left the company
5. The consultant’s project manager changed (3) times
6. The scope of the list of elements being deployed at Go-Live were scaled back
7. Project was delayed twice.
8. A new company division and plant location was added during deployment.

Some change is good, other types of change are detrimental to a project and its team. Be aware of the changes going on in the organization, and make sure your management team is working with you each time there is a change that impacts your goal of a successful launch. At each project report-out and checkup, make sure there is an honest dialog about change impact and take action, together.

4. Do It for the Right Reasons (and understand the impacts)

Let’s face it: Changing the software that runs an entire company from quote / order receipt to payment collection is a huge risk to any organization. The more custom systems that exist to run the current business environment only increases that risk. To make the decision to spend millions of dollars, and to commit valuable people resources to this project verses developing the next generation company widget or bringing on the next profitable account is a big deal.

So many companies feel like they have to justify a project like this by some hardcoded spreadsheet ROI analysis. Others look at their growth potential and how much they are being held back and determine they need it for the next level. Others still are constantly in pursuit of faster transactions by their staff, and others beyond that are looking for more data to run the business the way they desire. Just beware and triangulate the generic cost savings reasoning provided by a solution provider, as it doesn’t always reflect what is really going on in your company.

What I have to comment on here based on my experiences may be the most controversial in this article, but doing this big of a project for the right reasons is how your success as a team will be judged long-term.

My best advice? List out all the reasons your organization feels like it has to have in a new ERP system. Rank them in order of importance. Now, select any combination of (2) reasons out of the top (5) and ask yourself the question – if we didn’t get these (2) items at the end of the project, would the project still be considered a success? Change the selections and ask yourself the question again. What combination would cause the organization to consider it a failure if they didn’t get them? I will suggest that at least (2) of your top (5) reasons will probably not come to pass in the first year or two of a new implementation, if at all. Do you still want to do the project?

Our ERP project was based off of the need for more and better BI Reporting, lower cost of overhead (labor / inventory), and the issue of eliminating custom homegrown spreadsheets and databases attached to the main ERP system to run the business. We wanted “ease and speed”. For some reason, I always got a little uneasy feeling with the “ease and speed” goal. Until you run the game-plan at game speed, you really don’t know how it is going to work out…

So how did it work out for us? Well, as a team we worked very hard to eliminate home grown solutions in our ERP eco-sphere. The problem was that out of the box market solutions can do the same job, but not as tailored as the custom homegrown solution was. So while we got a much more robust solution for future grown that was integrated into the core system – it took longer to make transactions – so our actual “mouse-clicks” increased, and subsequently labor demands increased.

BI Reporting is one of those areas very important to all organizations, but it doesn’t seem to be understood as such by partner consultants, nor is it focused on by them during an implementation. I think that they tend to ignore the years of work that went into data extraction and manipulation for the old system and gloss over how much work it will be to re-invent those elements in a new system if they are key business metrics. Usually it takes another third party solution to do reporting, metrics and data extraction well in the newer ERP systems, and our team couldn’t take that on pre Go-Live. So, reporting was next to nothing for the first several months following Go-Live for us. It felt like we went back to the stone ages as far as planning and managing the inputs and outputs for the new system. Needless to say, even though the system was working acceptably for such a huge project after deployment, not having enough line of sight metrics and data was not viewed well by managers expecting “more” from their new system.

The fact of the matter is, it took a long time to mature your old system, it could even take longer to mature your new and more complex (and more versatile) new system. Can the organization tolerate the growth pains of the first year after deployment or is it looking for immediate returns on that investment? If the organization can’t wait for the long-term improvements, then maybe it’s not ready for the journey yet. Possibly it needs to wait for a more pressing, and demanding reason to have to do the system change-out.

5. Data Migration is a Bigger Project Than You Think

Data rich and dependent organizations beware. Data migration can be a long and laborious portion of the project. Usually listed as just part of a long checklist of things to accomplish for the project, it doesn’t seem that big of a deal going into it. In the end – you can and will get this part of the project 100% correct. You have to. Nothing will work unless you do, so the risk is not about doing it wrong, or missing something big – your testing, testing, testing will sort all of that out.

No, the risk is all about missed deadlines and delays. It takes a lot of time for programmers, testers and consultants to go through the repeated process of code writing, migration event execution, team testing, problem identification, and relooping all over again to fix code and logic issues. Months can go by with just a few reloop iterations.

Our team ultimately spent the most of its time on data migration. We had a whole Sharepoint workflow process designed to manage the issues from problem identification through final sign-off and code promotion. The process, communication, and reporting was first class, but the complexity of some of the problems and the hours needed to resolve them were at times mind-boggling. Few outside the project understood how much effort was needed to get this right.

We were moving from an old AS400 based system to a new MS-SQL system with much more functionality. Data migration was anything but just moving data from one place on the old system to a new database address on the new one. In most cases, we called it “data creation” verses “data migration” as there were more empty spaces in the new system that needed data that our old system simply didn’t have. Logic based on several pieces of old data was used to develop a new piece of data through the migration code development process, and that wasn’t easy.

One last piece of advice here – make sure that pre-ERP projects are developed throughout the organization to clean up old data in the old system before data migration begins. Our team defined and executed over 60 pre-ERP projects where data was fixed through reporting and manual intervention before data migration even began. If that had not been done, migration would have been even longer of a project than it was.

Final Thoughts

Success of an ERP System change cannot be honestly measured at month one, two, or three after Go-Live. Expectations for that time period should only be about whether the organization survived the first couple months. There will be bumps and bruises, and metrics will not look as good as they were just previous to implementation. Set those expectations up front and just commit to making each day better by fixing each issue as they come up.

There are many horror stories out there about how some big name companies had big problems implementing. Most likely your project will not have catastrophic problems for your organization – but there will be challenges to work on. That is just part of the journey. Get your team and organization’s expectations set correctly early and then repeat it often. Prepare everyone for the long-haul and stop occasionally and celebrate the smaller milestones. And make sure you get the chance to celebrate the milestone of Go-Live even with challenges that look daunting. Just because you have things to work on post Go-Live doesn’t mean the project was a failure. If you made theory become reality and didn’t shut the business down on day 14 after Go-Live, then it was a great project!

© Kevin Shope

Comments are closed.