The ERP Implementation Partnership: Human Factor vs. Tools & Procedures
We all have implementation methodologies and the tools that go along with them. While debating the merits of particular tools and the advantages of increased sophistication versus user buy-in, we can agree that our project tools are necessary components in a successful implementation.
That said, there are more interesting components in a project. Once the necessary tools and procedures are in place, the human factors that shape a project without ever seeing a mention in the project charter or a single status report play a vital role in the outcome. Though the human factors may not always be controlled, an awareness of them may improve project outcomes. It is worth openly discussing the motivations that clients and implementers have for pushing their points of view.
The Feature Cull
Consider the different motivations for including features in a project. It is important to consider why you want what you want, and to separate wants from needs:
1. Obvious Business Requirement
Let's use credit card processing as an example. We are going to buy an ISV, add training and consider PCI compliance issues. We will not need to discuss this if we already know this is going to happen.
2. Parent Company Requirement
Time to suck it up and get it done. At least we don’t have to spend that much time talking about it, we just have to do it.
3. Legacy Requirement
Let’s realize this package is not your old package. In fact it would do a lousy job of imitating your package, while it is very good at being itself. It’s time to find out if this requirement still exists in the new package and if possible replace it with stock functionality.
4. Feature in the new package advertising
You might be saying, "Look, we have a warehouse module and are licensed to use it." That means you have paid for it. We can implement it, but if you pretty much know where to put stuff when it arrives and where to get it when you need it, then you don’t need this function and even worse it will require more staff and more steps for every transaction to collect and control information that will only ever be stored. Avoiding immediate implementation of subsystems in the package will benefit us all.
5. The Old Report Set
The company has been functioning with a trusty set of reports. It is so tempting to implement everything. The down side is that go-live is the operational day on which you and your entire company know the least about the new package. Every day after that, your knowledge and experience about what the software can do and what you really need in this new world will grow. Every report that you can delay is going to be specified by someone with increased knowledge and that will result in a better work product.
Consider The Team
As implementers, we need to respect the situation that client staff are in. They face a deluge of information about the new product and they still have their original day jobs.
I recently had a client that had the benefit of a friendly company in the same business that was already using our software, sending a really experienced user to help with the new implementation. The friend was a little shocked that the new client had not yet seen the AP check process amongst other ordinary functions. That process had been demonstrated more than once, and it was only when the friend returned a month later and found incomplete retention of his training that he realized what was going on. The perfectly talented new client staff were in information overload, with relatively few people carrying out many tasks. This common state is the strongest argument for spending time on a feature cull. By unloading the team a little, you are potentially pushing them back to a work load where there efficiency has not been completely compromised.
Phase 2
As implementers, we want to accurately define a minimal set of required features. This really is in your interest, but when we show up for that initial analysis phase we may have general industry knowledge and implementation experience, but we might not know the subtleties of your business - your business that you live and breathe. Ironically you are our best hope in separating the wants from the needs, but it takes a very open mind to accomplish the task. You bought an impressive feature list, but that doesn’t mean that implementing every part of it will result in a better outcome.
One useful strategy for a smooth implementation avoids dismissing ideas out of hand with all of the concomitant hard feelings by creating a “Phase 2” list. When questionable tasks are found, they do not have to be dismissed, if possible they may be converted from needs to wants and placed on that list. After the initial go-live, the list will be reviewed by the ever more experienced staff and higher quality decisions will result.
ERP Implementation Partnership Summary
The common goals shared by the client and the implementer in an ERP implementation partnership are the real glue that bind the parties involved and determine its success. While completely necessary, the software and services contract was only signed by a handful of people, the project will require effort from many more.
After that contract is signed and we arrive on site to begin an analysis, there are still a lot of decisions to be made. Typically the client’s head is brimming with features from the existing system and all the others packages that were reviewed prior to the decision. As I read feature lists for ERP systems and their add-ons, they all sound good. What could be wrong with adding more beneficial features? The problem lies with the unanticipated effects of these extras. There may be some, such as a robust credit card handling system that are simply not negotiable. Many others may be critical for some businesses, but not necessarily for yours.
A client is stepping out on the ledge of change when they kick off a project and change is bad. To be clear, change is expensive, time consuming and painful and completely necessary given that the consequences of not changing are disastrous.
I look forward to seeing you in that kickoff meeting and then getting down to a productive argument about what to leave in and what to take out.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.