26 Jan ERP Fail – The RFP (P) – Recipe for Poor Performance
Every failed ERP implementation probably started with a comprehensive RFP that took weeks or months and endless dollars to create and complete.
Think about it.
The Request for Proposal (RFP) has long been the standard tool used to initiate the search for a new ERP software vendor and corresponding implementation partner.
Typically RFP’s come in two flavors:
A “real” RFP will typically give an overview of the company looking for a new ERP solution in varying levels of detail but always provide lengthy lists of detailed requirements. Often in a checklist format or conveniently presented in a spreadsheet. I often joked that I just used an Excel Macro to answer “Yes” to every requirement in replying to RFP’s. Just like everyone else but with less effort.
Additionally, RFP’s typically ask for software and implementation plans, costs and references from the responding companies.
In many cases, “BS” RFP’s are published. In these cases the selection of the software and implementation partner have already been decided and RFP’s are issued as a sanity check or to cover the fact that a decision has already been made. In this case, unsuspecting partners amount to what is commonly referred to as column fodder where their responses are tabulated in a spreadsheet intended to favorably highlight the responses of the favored supplier that has the inside track on winning the business.
It is not unheard of that key management involved in the RFP selection wants to add a certain product to their work resume and slants the search in the direction of that product. Business owners and other managers are of course in the dark as to this “hidden” requirement but live with the consequences.
A good rule of thumb for implementation partners and software companies answering an RFP:
- Only when you have helped develop or write them (wink…wink)
- As a training exercise for new sales people
In the case where you are dealing with a real RFP the intention of the client is usually to narrow list of potential software solutions and providers to move to the next phase of the Vendor Olympics: the equally worthless “software demo” (a complete discussion in itself).
Upon receiving the RFP, the software and service partner typically has one goal: make it to the next step of the buying process.
Some typical “tricks” of the trade in responding to RFP’s:
- Responding “yes” to every requirement
- Quoting industry standard implementation costs and time frames
- Providing lists of “professional” references or none at all on the theory that references are only provided to impending customers. Lot Lookee-Lou’s.
A professional reference is a client that you provide with above and beyond the call of normal duty services for free or at a reduced rate in exchange for using them as a reference account. For many companies this is much easier than actually having a good installed base.
One of the biggest con men that I ever met in the industry claimed that he would hand a prospect his customer list from his accounting system and let them randomly call anyone they wanted. That was an impressive pitch. Of course no one was ever handed a real customer list.
Ironically a real test of your capabilities as a service company is when can point to clients where the implementation hit one or more rough spots. Clients that can speak to your performance when the train runs off the tracks, as it often does in ERP projects, provide a much better reference. They can speak to how you react as a company when the going gets rough. The ERP implementation business is brutally difficult and how you respond in an emergency is the true test of your client commitment.
But back to the RFP.
One of the primary features of every RFP that I have ever seen and thrown in the trash can is the “Requirements List”. These are typically generated in one of two ways or by a combination of:
- Asking every user or department to compile a list of must have capabilities for the new software and compiling those lists.
- Using Google to find one of many pre-packaged lists readily available on the internet. Surprisingly these are often provided by software providers or their trusted advisors and are formatted in such a fashion that their product will be reviewed favorably.
If you have been in ERP business long enough and are good at you job you will typically learn more about a company’s requirements from a statement like, “we are a distributor of automotive parts” than you will from reading the requirements list.
Requirements list will often include subjective and obvious items such as:
- Software must be easy to use.
- Ability to cut vendor checks.
All software is easy to use, just read the marketing brochures and if you can’t cut checks for vendors why are you in the ERP software business?
The real problem however with a list of requirements is that a company runs on processes and not individual functions or functional islands. How those processes are handled in the software is the real issue.
To illustrate with an example that everyone may be able to relate to, imagine you are going to build a new home for your family. You gather the crew around the kitchen table and ask everyone individually as to what they have to have and/or would like to have in the new home. If you then hand those combined lists to multiple builders and ask them to build your home you will get wildly different results. Some may be pleasing and some may be OK while others are wholly unacceptable.
The key missing step is the architect! That person that combines art with science to take your list of requirements and combines them into a functional and pleasing design by combining your unique requirements with standard home features in a way delights your family.
Back in the day, conventional business wisdom said to learn to play golf because important deals are made at the country club not in the boardroom.
I guess that actually happened to me one time at a Microsoft sponsored golf outing where I was introduced to the owner of a distribution company that had outgrown his Microsoft Dynamics GP software. His management team was in the process of developing an RFP for a new ERP solution because they were literally afraid that his current system would explode at any minute.
Being of a curious nature, and without enough money in the bank to retire, I asked him what his issues might be. I figured that there would be some fundamental error in their deployment that would be easily fixed by our team of highly experienced GP talent and as a result we would have a new satisfied client. I was also trying to figure out if I could send a COV to his cell phone mid-round (industry insider joke…ask your Dynamics Partner).
Unfortunately he began to explain a business model that almost made my head explode instead of his software and wonder how it was possible that they could even manage their accounting in GP never mind the complex inventory costing calculations and transactions that he described.
One fact stuck out to me immediately as he described his business, without dimensional inventory, no software would address the resulting reporting and reconciliation nightmares that they had to deal with on a daily basis. All of the problems that he described were symptoms of this basic but complex requirement.
This made me think that there might be a real opportunity to assist him but my guess was that as the president/owner of the company he might be too far removed from the day to day operations to be able to pin point the operational flaw in his GP software but that his management team understood the issue clearly.
I offered to review his RFP to see if there were any areas where I might be able to help him with his new software search.
Interestingly enough their RFP was a standard boiler plate effort focused on standard distribution requirements. The fundamental element required to fix all of his problems, dimensional inventory, was nowhere to be found in the RFP.
Going to market with that document was the usual recipe for disaster. It focused on general capabilities that any decent distribution system should handle without ever addressing the core issue. Standard RFP responses would have focused on fixing symptoms and demonstrating “value” and never come close to sniffing out the real problem.
The RFP process is a disastrous way to kick-off a software search. Unless you are in a specialized industry that only five people in the world understand there is a commercially available software product that can handle the vast majority of your business needs right off the shelf.
Long lists of requirements lovingly compiled and presented to software companies and implementation partners will do very little to insure a successful ERP implementation. At best it will prolong the process and make it more expensive while providing a false sense of security because all of our boxes were checked “yes”.
Here is my ideal RFP template and process:
Dear [insert product name} implementation team manager,
We are in the [insert business type here] industry and will be implementing a new ERP solution that we hope to have up and running by [insert date].
What makes us special in our industry are the following items:
- [Everyone loves “top ten” lists but let’s focus on the top three]
We are setting aside two to three day time slots for your implementation team to walk our key business stake holders through our major business processes on your vanilla software.
Please do not have any sales or pre-sales technical people contact us.
As experts in the [insert industry type] it is our expectation that you will be able to quickly and efficiently show us how to run our business without any preliminary “fact gathering”.
The following time slots are available for you to select:
We look forward to working with you and your team on this critical project.
Poor Individual Put In Charge of the Selection ERP Project
Now there is an RFP process that would get to the heart of the requirements and quickly and efficiently narrow the field to only serious and capable solution partners.
You are welcome.