The Ideal ERP RfP

Having worked on “both sides of the fence” I have produced and responded to hundreds, if not thousands (certainly feels like it), of RfPs related to ERP. Now, I think, it is time to reflect on what my ideal RfP would look like. And let’s be clear: I am pretty sure there is no-such-thing as an ideal RfP, but in the following I have tried to compile the dos and don’ts I have learned over the years.

Why use an RfP in the first place?

Obviously, in the European public sector, use of RfPs is pretty much mandatory so let’s focus on private sector RfPs. From a corporate procurement perspective being able to accurately describe the required services and have potential service providers compete for these services makes perfect sense. And in many cases, this is a sensible approach. However, implementation of an ERP solution is usually very complex and often slightly unpredictable due to a number of factors including:

• Requirement ambiguity.
• Process maturity.
• Change readiness.
• Lack of governance.
• The team’s ability to work together.
• Complexity of integration with other systems.
• Availability of resources.
• Politics (plain and simple).
• Etc…

The list goes on…

I think it is fair to say that even with all the good intentions in the world, a response to an RfP only represents the service providers best guess and should not necessarily be taken at face-value. However, a targeted RfP can still be a good tool for evaluating potential service providers and driving a market dialogue.

In the following, I have tried to share my experience and personal opinion on what makes a good RfP – or not.

A proposal – not a fixed offer

The clue is in the name. We are asking the service provider to produce a proposal – not a fixed and complete offer. Accepting this fundamental proviso makes the process more productive for all parties. Instead of making the service provider focus on achieving the highest evaluation score, design the RfP to force the service provider to propose the best solution (based on their experience) and raise concerns relating to requirements and conditions that drive cost, risk and complexity. Perceived risks and complexity are the main cost drivers for a service provider so if they are not recognised and addressed early, they will come back and bite you later in the form of change requests.

System selection

In the interest of expediency, and maybe fairness, I have seen quite a few RfPs seeking proposals for both system (product) and services at the same time. In an ideal world it makes sense to couple selection of the system with selection of the service provider. However, in my experience this is not ideal. Ideally, the client should engage with software vendors to evaluate the fitness-for-purpose of the solutions in the market first. This way, when it comes to describing requirements and what the client expects from the system, the RfP can be made much clearer and not make allowances for lack of product knowledge. It is certainly valuable to do some market research before writing up the RfP. The ecosystem surrounding each product is unique and it is difficult to cater for those differences in a single document.

Selection criteria

Over the years I have seen many schemes for evaluating a proposal. Ranging from simply focusing on price to extremely complex spreadsheets that combine factual price data, functional fit evaluation with subjective demonstration scores. Interestingly, I have yet to meet a service provider that can implement a given solution substantially faster than their competitors or make the solution do something other people can’t. Often, the price is actually more a reflection of the service provider’s willingness to take risks and its creativity in interpreting requirements. Actually, it may be better to evaluate the service provider in terms of:

• Robustness and reliability.
• Domain experience.
• Ability to manage the project.
• Experience from similar clients.
• Track record in terms of staying the course.
• Project team and staff attrition.
• Risk management.

Why did day rates not make the list? Because, failing to deliver on the above criteria are much more likely to materially affect the total cost than day rates are.

The requirements specification

Ah yes, the fabled requirements specification. I would like to think that it is universally acknowledged that the requirements specification repeatedly fails to comprehensively describe the needs of a company. Over the years, I have seen requirements specifications fail in relation to:

• Not adequately describing the implicit requirements i.e. requirements that the client expects the system to be able to handle without explicitly stating them. Are they included or not? Who can say?
• Describing requirements in an ambiguous fashion leaves substantial room for interpretation.
• Describing requirements in a way that does not allow the service provider to use the solution to its full potential.
• Emphasising requirements that are not material to the performance of the company but may represent complex process scenarios.

I have actually yet to see a requirements specification that served as adequate input to the actual delivery of the system.

Timeline

Often the service provider is asked to provide a timeline for the project. This may be accompanied by a proposed go-live date by the client. Most times, the service provider will seek to meet this go-live date on the presumption that this is what the client wants.

Instead, in my view, the client should ask: how long did it take other clients to undertake similar projects?

If the answers does not tally with the client’s expectations, the next question the client you ask itself is: why do I think I can do it substantially faster?

A lot of factors may influence the timeline, but it will require serious and detailed dialogue to work out the actual timeline for a project based on:

• The complexity of the project.
• Whether the project introduces new technologies for the service provider.
• The methodology applied.
• How mature the client’s project organisation is.
• How many resources the client can allocate to the project.
• Seasonal variations in the company.
• Availability of the service provider’s specialists.
• And the list goes on…

What is the alternative to an RfP?

This is actually an interesting question, and I am not sure I have the perfect answer. The RfP certainly have its place when it comes to seeking answers to commodity questions such as:

• Day rates.
• Financial stability and performance of the service provider.
• The service provider’s experience and track record.
• Timeline based on experience from similar clients.
• Broad estimates based on experience from similar clients.
• The service provider’s approach, tools and methodologies.
• Terms (legal) and conditions.

Based on this information, the client can form a shortlist of potential candidates.

Instead of using the requirements specification as a document for fixed responses, the client can invite each service provider to demonstrate a number of use cases based on those requirements. Allow the service provider to challenge the requirements to show the product’s full potential.

Based on their performance, down-select two preferred candidates and allow them access to your organisation to clarify the requirements and write-up a proposal based on their own approach and methodology.

This is probably how I would approach it, if I was in a position where I had to implement a new system. The RfP seems to be a subject where people have different opinions, so please share your views…