By: Doug Houghton, JBT Chalfont

Doug is a Sales Manager with JBT. He works primarily with food and beverage customers based in the United States. 

Have you ever heard the term “three guys in a pool?” It refers to the age-old process in which multiple bidders all receive a request for proposal (RFP) and are “tossed into the pool” in the competitive bidding process. Here, vendors attempt to drown each other. They beat each other down on price, dive deep into engineering details, and generate fixed price proposals that account for every nut and washer in the proposed system. The bidders produce a 100-page proposal that no one really wants to read. Then, the end-user typically eliminates one vendor, and the process starts all over again. Finally, a sole survivor climbs to the side of the pool, seemingly victorious, only to be thrown back into the pool by a procurement group. The crushing reality is that most of the bidders spend vast amounts of resources, human capital, and time only to get nothing for their effort.

Water polo

Meanwhile, the competitive bidding process also affects those who initiate it. End-users learn about several different vendors, and most often, they have a favorite after only a few discussions. But instead of moving forward with their favorite vendor, they must sit at the edge of the pool and watch as their favorite vendor tries to drown the competitors. They can’t get the ball rolling on their project and ultimately lose out on some of the benefits of the equipment they desperately want. Then, even if their favorite emerges from the pool victorious, they watch as their procurement team pushes the vendor back into the water, where they may potentially drown again.

Throughout this process, the buyer assumes that they will get the best system solution for the best price. The three guys in the pool all get the same RFP, the same data, and the same opportunity to visit the site. As a result, the buyer ideally receives proposals that truly compare “apples to apples.” In reality, this is never the case. All too often, the RFP isn’t clear and is open to interpretation. The data may not be accurate and thus open to misinterpretation.

water-recreation-diving-pool-underwater-swim-1331001-pxhere.com

Let me give you an example – recently I was working with a client on large automated guided vehicle (AGV) system at one of his company’s production facilities. All the bidders were given the same data set. However, the data was interpreted one way by my team and a totally different way by a competitor. This misinterpretation caused a difference in AGV count by almost 10 vehicles! When the client asked us to explain our results, we showed the client how we had analyzed the data and line rates. Fortunately, we had spent a fair amount of time with the client reviewing their data during the bidding process, and in the end, the client agreed with our interpretation of the information. If they had chosen the competitor, then the system would not have been able to maintain throughput. They would have ended up spending more money in the long-term to make the system work.

By throwing three guys into the pool, you want to an even comparison. But, as evidenced by my recent experience, this often doesn’t happen because of the constraints placed on the suppliers in the pool. We’re all making an informed decision, but it might not be the same one. In all likelihood, what you really want out of the competitive bid process is the right solution at a fair price. That’s where the FEED process comes in.

What is FEED?

The RFP is designed to reduce risk for the buyer. We have noticed, though, that the vendor can be impacted negatively, too. The FEED process helps to eliminate risk for both the buyer and the vendor.

hand-game-play-number-red-black-599456-pxhere.com

Front-end engineering design (FEED) is a project-development process focused on producing enough information to enable decision-makers on both sides of an agreement to buy-in on a project. This means that both parties can assess risks and make resource decisions without over-extending commitments in the process. FEED uses a stage-gate process, whereby a project must pass through formal gates at well-defined milestones before receiving funding to proceed to the next stage.

FEED 1

In FEED 1, each party (vendor and client) only expends the energy and resources needed to reach the point of making a decision to proceed. They do their “due diligence.” Everyone knows that FEED 1 will not produce a fully-designed and fully-engineered solution – this would result in an over-extension of resources. FEED 1 should only commit enough resources to bring the client to a decision-point, where they choose one vendor over others. It provides decision-makers with a level of comfort in a vendor while ensuring the vendor’s concept and pricing is in line with the return on investment (ROI) and project goals. The buyer is able to make a decision regarding a vendor’s concept and budget pricing. At this point, the buyer chooses a partner.

The deliverables for a FEED 1 proposal include:

  • Preliminary
    • Schedule
    • Layout
    • Vehicle count
    • Throughput calculation
    • Scope of work
    • Software interface definition
  • Detailed
    • Description of process flow
  • Budget price estimate of +/- 10%

The intent of FEED 1 is not to develop a fully-designed system and detailed pricing, rather to provide enough information to allow the buyer to make a decision.

FEED 1 reaches its end-gate when a customer commits to expend more resources, which is represented by a down-payment. This down-payment serves as the gate needed to progress into FEED 2.

FEED 2

FEED 2 commences with a purchase order (PO) issued by the client in order to fund more work. This financial commitment is only large enough (typically 10% of the FEED 1 estimate) to complete the work of FEED 2, which helps avoid the over-commitment of resources by either party. FEED 2 strives to eliminate risks to both parties as technical staffs from each party deeply and thoroughly analyze the project. Each party can now commit more resources because vendor selection and funding has occurred.

 Once the vendor receives a PO, the client holds a kick-off meeting at the project site. Representatives on both sides (vendor and buyer) who attend this meeting include:

  • Management
  • Project Management
  • IT/software
  • Operations
  • Sales
  • Procurement

Business people working on a laptop

The meeting begins with a salesman reading the detailed description of the process flow (from the FEED 1 estimate). During this reading, any questionable items are recorded in corresponding areas within an action-list book. Upon completion of the reading, the groups break into focus groups and take the action-list book with them. The groups then work through the list, making decisions on items requiring further investigation, eliminating easily-answered questions, and/or clarifying misunderstandings. Both parties keep the action-list book, and it becomes part of the overall project.

In the end, the vendor and the buyer work together to design the correct system, with the right functionality, correct interfaces, and ROI requirements. The result is reduced risk for both vendor and buyer.

The entire FEED 2 process occurs within a time limit, typically 60 days. Legal and financial terms and conditions are negotiated to agreement throughout the FEED 2 process. The final gate test for resolution of FEED 2 is a contract and purchase order for the full project amount minus the FEED 2 down-payment.

Deliverables of the FEED 2 process include:

  • Definitive
    • Schedule
    • Layout
    • Vehicle count
    • Throughput calculation
    • Scope of work
    • Software interface definition
  • Detailed
    • Description of process flow
    • Functional specification
    • Terms of sales

At the end of the FEED 2 process, a client will issue a final PO for the entire price of the proposed system and commissioning of their system begins.

The End Result

Working through this process with a client in the food and beverage industry, they realized during the reading of the general description that even their internal team did not fully understand their process. We were able to work together to identify a cost effective solution for them. Had we not utilized the FEED process with them, this issue could have ruined the entire project. We were also able to design an AGV for them that offered more functionality to their operation. Again, this saved them money and improved their ROI. In the end, the final FEED 2 price was less than the FEED 1 budget price. We reduced risk and provided a system that was exactly what the client needed.