Using an Agile Procurement Process to Help You Get Your ERP Procurement Right
I have sat through too many awkward RFP interviews and demonstration days. The evaluators are cautious, unsure what they are allowed to say. The proponents are equally guarded, worried that an off-the-cuff answer could cost them the opportunity.
Some of that caution is understandable. Procurement teams have legitimate concerns about fairness, legal challenges and public scrutiny – and are wary about saying or doing the wrong thing. As one client put it recently: "Keep me from getting sued and off the front page of the newspaper."
But a process designed primarily around fear rarely produces the best decision.
In any procurement process, being a fully informed buyer is the most important thing. Last-minute surprises are undesirable.
When you procure an enterprise resource planning system, you are buying software – yes, but you are also buying the expertise of the implementing team and ideally innovation and innovative approaches.
The procurement process should therefore help you answer questions that a requirements matrix cannot:
Is this the right approach and solution to implementing my ERP solution given today's technology market?
Does the implementation team have the skills (soft and technical) to help us get this implementation right?
Does my RFP allow me to get apples-to-apples pricing and bids?
These are not just soft considerations. They are central to whether an ERP implementation succeeds.
Where the conventional RFP falls short
Most RFPs follow a familiar sequence. The buyer defines its requirements and releases them to the market. Proponents submit questions, and the buyer issues addenda. When the RFP closes, submissions are checked against mandatory requirements and passed to an evaluation team. Evaluators score independently, reach a consensus and create a shortlist. Shortlisted proponents may be invited to demonstrate their products, often by following a prescribed script and evaluation rubric that only considers the actual product.
Following the demonstrations, the buyer completes the evaluation, opens the pricing and awards the contract to the highest-scoring proponent.
The process is intended to be fair, consistent and defensible. Those are essential goals—but for a complex ERP project, the process can still leave critical questions unanswered and cause the buyer to miss important opportunities to ensure it selects the best solution.
When it comes to complex ERP systems, a written RFP can only convey so much, and the resulting proposal can only tell you so much. A scripted product demonstration, whether it lasts half a day or two days, rarely resolves every uncertainty or allows the buyer to understand what a proponent can truly offer.
When preparing the original requirements, the buyer doesn't always have all the answers; they may still be unclear about data migration, project phasing, timelines, responsibilities, licensing or the fit between proposed modules and actual needs, or worse, may specify an approach that doesn't make sense in today's market. On the other side, the proponent may also be working from incomplete assumptions about the organization.
In other words, both parties may be approaching a major commitment without a true shared understanding of what that commitment involves.
A more useful alternative – Agile Procurement with CCMs
This is where an agile procurement process — often called an RFP with a best and final offer, or "BAFO" — can be especially valuable.
The early stages in an agile procurement process remain rigorous. Proposals still pass through mandatory requirements, scored criteria, demonstrations and financial evaluation. The difference is around a gradual refinement of the buyer's requirements as it engages in confidential discussions with proponents through the process, allowing for an iterative bidding approach as buyer requirements are refined and clarified, typically after the field has been narrowed to a small number of proponents, sometimes two or three and, where the process permits, potentially one.
After an initial evaluation of bids, proponents and the proposed product, there is typically a down-selection to a limited pool of proponents. The buyer will move into commercially confidential meetings, or CCMs. These meetings create room for an open conversation with shortlisted proponents. In a recent RFP, the purpose of the commercially confidential meetings, or CCMs, was described as follows:
to allow open, solution-oriented discussions regarding the Bidder's Bid and its alignment with the buyer's needs,
to clarify aspects of the Bid,
to explore potential enhancements, innovations, or risk mitigations,
to identify areas where adjustments to the RFP may better align the Bid to the buyer's needs, improve value for money and minimize post-award misunderstandings, and
for the buyer to present its critical contract requirements and to obtain an understanding of each Bidder's preliminary position and willingness to accept those terms or their proposed adjustments.
While the discussions can be targeted, they need not be tightly controlled. The goal is to learn from one another with a view to ensuring that the ultimate goal of getting the best solution at the best value is met.
Through these discussions, the buyer learns more about the proposed team, solution and delivery approach and, equally importantly, options for enhancing approaches to the solution and the project. The proponent learns more about the buyer's organization, constraints and priorities. Both sides can identify and correct assumptions prior to a final bid submission being delivered and before those assumptions become contractual commitments—or project problems.
The discussion might cover:
project phases and timelines;
the scope and sequence of data migration;
the division of responsibilities between the organization and the implementation partner;
modules that were included but may not be needed;
capabilities the buyer needs that were not included;
user counts and licensing assumptions; and
services, such as change management, that the buyer may decide to deliver internally.
By the end of the meetings, your team should understand the written proposal and demonstrations far more clearly. You should know how the solution fits your needs, how the financial proposal is constructed and what the proposed partnership may feel like in practice.
You enter the next stage better educated, with a deeper understanding of market offerings, individual proponent constraints and pricing models, and better positioned to ensure you receive apples-to-apples proposals and pricing built on a shared understanding of the requirements.
Turning the conversation into a comparable offer
Following the commercially confidential meetings, the buyer will typically issue revised requirements in the form of a BAFO RFP to the remaining proponents. The objective of revised requirements is to ensure the technical proposal reflects what the buyer needs, and the BAFO pricing is as informed and reliable as possible. The BAFO RFP records the changes and refinements that emerged during the CCM discussions.
Typical clarifications may adjust the timeline, scope, user counts, licensing assumptions or allocation of responsibilities. The important point is that every remaining proponent receives the same formal information needed to prepare its best and final offer on a consistent basis.
The BAFO proposal from each proponent typically restates the relevant parts of the original proposal, incorporates and highlights any changes resulting from the updated requirements and provides revised pricing. Because the proponents now understand the requirement more fully, their offers should be more accurate and easier to compare. Instead of evaluating proposals built on materially different assumptions, the buyer gets much closer to an apples-to-apples comparison.
When more than one proponent remains, the process also preserves competitive tension. The proponents know they are close to selection and may sharpen their pricing or strengthen other aspects of their offer.
The evaluation team then reconvenes. Using the framework outlined in the RFP, it calculates the final technical scores and financial scores based on the revised submissions. That process identifies a preferred proponent and leads into contract finalization.
The draft contract may be shared and discussed during the confidential-meeting stage. If so, potential issues may be identified early. Contract negotiation is not eliminated, but it is less likely to reveal a fundamental disagreement at the time of award.
Fairness and humanity are not opposites
Making an RFP more human does not mean making it casual or inconsistent. It does not mean giving one proponent information that others do not receive, abandoning the evaluation framework or allowing personalities to replace evidence.
It means designing a fair, documented process that recognizes what you are actually buying and ensures the final proposals are equivalent and can be evaluated on a true apples-to-apples basis.
Your procurement process should give you a meaningful opportunity to develop a complete understanding of the offerings and to leverage the expertise of the market while adapting to variations in approaches to solutions and pricing.
If it does not, you may end up with a defensible decision on paper but the wrong solution in practice.