End-of-year budgeting is here again and your project that has been postponed for several years has finally been made a priority. As with many, the project needs to be started before the actual year-end so that the funds can be separated across two fiscal years. Unfortunately, time is running out and you need to send out a request for proposal (RFP/RFQ) as soon as possible. To do this, you gather the few drawings you have, even though they are not up to date, and try to gather your thoughts on how to write the scope of work.
I receive a lot of different types of RFP's that are written by purchasing agents, entry-level engineers, GC's, EPC's, potential bidders claiming it was an unbiased FEED study...HA!..and many others. The majority have the same issues that cause unfair and unhelpful submissions for your project. The purpose of this blog is to offer a few thoughts on how to be more successful writing your RFP and receiving qualified "apples to apples" proposals back from your recipient pool. As the writer, I acknowledge that I am a typical "bidder" for control systems integration projects and that there are always exceptions.
It seems that this should go without saying, but it is very important that the information in the RFP is accurate and complete. Using an internal or external resource is fine but they must know or be able to quickly learn the system, scope, and goals in order to provide the data for the RFP. If you are a procurement agent, adding a scope paragraph that only states to 'upgrade the system' will not be sufficient.
Scenario: Customer XYZ needs their current SCADA system upgraded to the latest version for Windows 7 compatibility. It is necessary to gather the current software licenses to determine the upgrade path, which has been provided on the RFP. What if, at some point in the lifespan of the system, a 3rd party vendor installed a custom closed source data management software package. If you receive bids without that very unique detail (because you may not have known), the system will not run, downtime will extend, you may not gain access to the source code and have to create another custom solution. Also, new documentation may be necessary and the project could be extended by several weeks. In other words, a complete project failure.
Although this example is a little extreme, it does happen (and did…), especially when your bidders are "held at bay" by the walls of purchasing and RFP electronic submittal software.
What I have learned over the years is that the only way to reduce cost is to reduce scope. The small differences in vendor rates and travel time do not affect the final prices very much. That is why whenever there is a large variance between proposals, you should see red flags. It means that there is a good chance that one of the bidders did not understand the scope and therefore did not include portions of the requirements in the price.
I personally prefer bullet point scope definitions. Individually identify the specific duties to be performed and the expectations you have for each of those duties. Do not generalize! Be as specific as possible. The more detail you can give, the more accurate the proposals and the less risk of change orders after the fact.
Provide existing control system architectures and future expected architectures. This is critical to your suppliers understanding of the scope of work. Again, the more detail, the better the submissions. Generally, a supplier will want to know the relationship of how each piece of hardware and software are connected. At times, it also helps to identify communication protocols and distances; perhaps for choosing between copper and fiber cables for your ICS network.
It is not necessary to provide fancy 3D models of everything, just a simple one line will do just fine. Below is a portion of a simple control system architecture. Something is better than nothing, so at least draw out the main control system components and put a logical connection line between each component that is physically connected in the plant environment. This is not meant to be a physical dimensional representation, just a logical connection diagram.
Although it should go without saying, most integrators have more than one customer and stay very utilized. When it comes to control system projects, suppliers need time not only to design and build but also to receive the materials. You can never assume a 4-6 week lead time, especially when you want a custom item. Give yourself 10 weeks for materials and always ask for each vendor's project duration calendar. Compare each calendar the same way as the proposals. If something is way off then it is possible that there has been a misunderstanding of scope or expectation.
An example of a portion of a duration schedule is below outlining task name, start date, end date, predecessors, and duration. All of these items are critical to understanding feasible timelines.
There is a wide range of options for developing a material list including low and high-end materials, multiple products for achieving results, and "add-on" possibilities that could change how the project is implemented. I find that companies tend to be happier with their proposal submissions when a preliminary BOM is given to each bidder. Any flaw in the BOM can easily be changed and updated to all bidders or can be adjusted after the fact. In either case, your proposal request will generate more accurate proposals due to the fact that each bidder will price the same materials and only their markup will show. That is why you are bidding right?
A single BOM also gives the bidder the opportunity to provide options that are much clearer. In many cases, this is a simple add/deduct section in the proposal where each bidder can suggest alternative methods for cost savings or future proofing. If you prefer a single manufacturer such as Rockwell, Siemens, or Emerson, ask for the local business unit or distributor to provide you a suggested BOM. This helps keeps things straightforward and allows for your materials for the project to stay within your region, which the distributor has to support anyways.
It seems to be quite common to have a pre-bid meeting just a few days after RFP release. Unless being used to eliminate bidders, this is completely unrealistic if your goal is to get the best price for your project while lowering risk. I suggest having the pre-bid meeting near the middle of the timeframe with no less than one week after RFP release. Likewise, it doesn't make sense to have that meeting the day before project deadline either.
Also, consider a bidder query form that is online and shared with all bidders such as Google Sheets. Be sure not to give edit permissions to bidders on the answer form but just allow input of questions on one form, then answer them on another. All inputs are tracked and this provides very efficient communication and higher proposal accuracy. If using electronic bid software, make sure that everyone is comfortable with the process and understands how to submit and receive information. Remember, most suppliers work with a dozen different online portals and many are not user-friendly. There have also been cases where one bidder could see other bids before the deadline, so this must be tested prior to project start.
I know that the low price seems to be the nicest looking bid, but there are many factors that make up a project. The highest weighted consideration should be risk, not price.
Create a weighted qualitative checklist that allows you to rank your proposal based on what is important to you. In any area of a proposal that throws that checklist out of balance, ask the supplier to explain in more detail. You can add anything to your checklist, even intangibles such as trust and bidder personalities. The company that is awarded the project should be your partner and you will have to be able to work with them throughout the project lifecycle.
A successful project is built on communication. Be sure to give all of your relevant information to your prospective bidders up front and never assume that leaving a critical piece of the project out will result in a lower cost. Most companies that I have worked with or competed against have been honest, hard-working, and strive to maintain a high level of quality. Do not be the roadblock in your organization, but instead, put in the work so that the project goes smoothly and under budget.
Eli Jenkins is a Business Development Manager with Cross Company's Integrated Systems Group for the Atlantic Region. He graduated from Berea College with a BS in Applied Science and Mathematics and has a background in chemical manufacturing, control system integration, and consultant sales. Eli has a passion for solving problems and helping customers reach their goals.
Learn how our team helped Jack Daniel's Distillery build a process facility from the ground up.