1. RFX Process Introduction

All organizations have procurement requirements to address products and services that are central to the business mission. This RFx Process Module introduces a structured approach to RFx management to expedite and speed the complex procurement process. It provides the NaaS Operator with background information, methodologies, and templates to execute a wide variety of RFx initiatives. A properly formalized RFx process helps to define what services vendors/suppliers can deliver and the market price for these services under fair competition. The use of the RFx process is important to control costs and ensure a specific vendor is competitive for a specific scope of work.

Different alternatives are possible depending on the main objective and required outcome of the process. Request for Information (RFI) is a formal inquiry in the marketplace for information, typically concerning expressions of interest, capacity, capability, and availability of contractors to undertake and bid on work described in the solicitation. A Request for Proposal (RFP) is a formal invitation containing a scope of work that seeks a formal response (proposal) describing both methodology and compensation to form the basis of a contract. In practice, an RFP tends to include more detailed and comprehensive information. Request for Quotation (RFQ) will be used to request a quotation of well-defined products and services.

The ultimate goal of the RFx process is to get to a contractual agreement with the selected Vendor(s). Goal can also include establishing a Master Services Agreement (MSA) for the provision of products and/or services during an elapsed period of time (typically multi-year). This period can be fixed and determined in the agreement or can be undetermined and renewed every year.

The RFx Process Module creates awareness of the RFx processes, guides NaaS Operators to define and implement the process, and provides generic templates for the RFx documentation. This RFx documentation becomes then an input for specific RFx instances, which will be used in other modules of the NaaS operational areas.

1.1 Module Objectives

The objective of the RFx Process Module is to support NaaS Operators with the implementation of RFx processes to procure external products and/or services. The module has the following specific objectives:

1. Provide a general overview of the end-to-end RFx process to ensure sufficient information and expertise to implement an RFx process.
2. Enable NaaS Operators to develop an RFx Framework that can be applied to various functional areas to drive domain-specific procurement processes.
3. Provide NaaS Operators with guidance and methodologies to facilitate Vendors evaluation and selection including the usage of weighting and comparison tools.

1.2 Module Framework

The Module Framework in Figure 1 shows the modules included in the Supply Chain Management area. Almost all NaaS Operator functional areas may require at some point the implementation of an RFx process to procure products or services for which has been determined that a 3^rd Party solution is required.

The RFx Process Module provides a generic framework for understanding and customizing the RFx process and developing RFx documentation. Modules in other streams will benefit from the generic RFx framework to produce RFI/RFP/RFQ document instantiations tailored to their specific needs.

Figure 1. Module Framework

Figure 2 shows the steps in the RFx Process, which drives the development of the RFx Process Module. The end to end process is discussed at a High Level in Section 1 of the outline. Then a deep dive for each phase (Preparation & Execution) and templates for documentation are provided along with guidelines for customization in Sections 3 to 5.

Figure 2. RFx Process

The rest of the module is structured in five sections. In Section 2, a complete end-to-end overview of the RFx process is included, providing the reader with a contextual approach to the rest of the module. The module continues in Section 3 with a more detailed description of the activities in the RFx Preparation phase. Then, Section 4 examines the activities of the RFx Execution phase, from initial data collection to Vendor evaluation and selection. Finally, Section 5 provides a comprehensive instantiation of the RFx document, from the preliminary notification to vendors to a contract award template. This RFx document will constitute the main vehicle to request and receive information from the Bidders.

2 RFx Process Overview

The RFx processes provide a view of the market capabilities to respond to the NaaS Operators needs. Depending on the type of request from the NaaS Operator, and RFI, RFQ or RFP process will be advisable. At a high level, a comparison between the RFx processes can be established based on the level of detail of the scope of work description, the timing of the process and the detail of the response, as summarized in Table 1.

RFIs are suitable to establish feasibility and vendor characterization. An RFI is less specific and includes less information than other processes. The advantage of the RFI is its simplicity, being easier to prepare and faster to respond.

RFQs are appropriate when the scope of work is clearly defined, and the NaaS Operator is seeking for a cost comparison.

RFPs are required when an in-depth, multi-dimensional comparison between vendors is required. RFPs are the adequate process when there are different alternatives to implement the scope of work and the NaaS Operator is looking for an end-to-end comparison between the available solutions in the market. Once the solution is established, RFPs are followed by a request for quotes, on the basis of the approved solution.

In all cases, the RFx Process will start with a Preparation phase, in which the Scope of Work of the process is established by the Project Sponsor in a Project Chart. Once approved within the NaaS Operator, the RFx Project Team will be created. The composition of the RFx team will include a Project Sponsor, a Project Manager (PM) and a business and technical Subject Matter Experts (SME). The preparation phase finishes with the identification of the vendors to which the RFx process will be addressed.

In the RFx Execution Phase, the requirements of the solution are defined, including the technical, commercial or legal specification. These requirements are translated into a formalized RFx Document, which is structured differently for each process type (RFI/RFP/RFQ) around a common framework. The definition of the RFx structure is described in section 4.2 of this module.

Finally, the RFx Evaluation Phase consists of the assessment of the received responses. Based on such responses, the RFP team will make a recommendation to the project sponsor on the vendor selected for contract negotiations, solution purchase or capability validation.

3 RFx Preparation Phase

The RFx preparation phase is depicted in Figure 3. Once a Business Need has been identified, a Project Sponsor is designated to initiate the RFx process by setting the RFx Scope and defining a Project Chart. The Project Sponsor is the owner of the project, typically a management role in the organization or group where the business need has been detected.

With the project objectives already established, an RFx Project Team is created with the Project Sponsor, a Project Manager and Subject Matter Experts, as needed. The Sponsor is responsible for providing resources and support to the project, with the Project Manager being the person in charge of daily activities.

Figure 3. RFx Preparation Phase

The sections below describe the activities developed during the RFx Preparation. The roles and responsibilities of team members are summarized and templates for the process outputs are included for customization by NaaS Operators.

3.1 RFx Scope & Project Chart

The RFx Scope establishes the Business Need that the RFx process is trying to resolve. The RFx Scope presents a description of the environment, pre-existing considerations, a high-level estimation of timelines and the format of the agreement, such as time and materials, equipment supply, professional services or a turnkey end to end project. Based on the type of RFx type, the considerations in Table 2 must be contemplated when writing the scope to ensure alignment between the request and the expected response. The scope description must provide all details needed to properly understand the technical and commercial needs, the project limitations and constraints and, in general, any additional information which may be relevant to the vendors.

Once the business need is formalized as an RFx scope, the project Sponsor presents a Project Charter to formally commence the project and designate the Project Manager who will be responsible for the complete execution of the process. The Project Charter is a short document that contains the essence of the project. It states the project scope, the business need being addressed, the project schedule and the structure of the team being responsible for its completion.

The Project Charter Template provides a predefined format for the Chart, which can be easily tailored to the specific RFx process.

3.2 RFx Project Team Creation

After the definition of the Project Charter, an RFx Project Team will be put together to provide support to the RFx process. The RFx Project Team is composed of the following profiles:

• Project Sponsor: It is responsible for resolving the business need through the RFx process. Defines the project charter and designates the Project Manager. Provides final approval to the project plan. Provides support to the Project Manager on internal coordination within the NaaS Operator.
• Project Manager (PM): It is responsible for the complete and timely execution of the RFx Project. The PM will establish contact with the vendors as required and will be responsible for producing and delivering the RFx documentation, answering the vendor queries and receiving the vendor responses. May delegate activities on technical or commercial subject matter experts.
• Subject Matter Experts (SMEs): They are experts in specific areas of knowledge relevant to the RFx process. They will be consulted by the PM and may need to write the parts of the RFx documentation under their area of expertise. SMEs do not need to be permanent members of the RFx team.

Once the RFx team is defined, the process of identifying and pre-qualifying vendors commences. This is a prerequisite to the submission of documentation to targeted vendors to avoid the involvement of suppliers, which would be unable to deliver the project scope.

3.3 Bidders Identification and Pre-Qualification

The Bidder Identification phase is used to identify potential vendors that can satisfactorily respond to the RFx process. Module Procurement Process and Vendor Management further develops the process of identifying vendors as part of the Procurement process.

The NaaS Operators should invite to respond vendors with previous and successful experience on a similar scope of work with the NaaS Operator or their competitors. In the absence of previous references, the NaaS Operator must request a list of potential partners to the local authorities, local Chambers of Commerce and professional associations. Market research through online directories or web searches is also a valid mechanism to detect potential partners.

The different sources for Bidder Identification are examined in the following subsections.

Previous Vendors

– Identify among previous vendors those with capabilities and experience (with the NaaS operators or other similar companies) that are deemed adequate to address the Scope of Work.

– Request current vendors on business areas that may be related to the scope of work for potential partners.

– Use contacts in other providers and even in competitors to obtain references from possible vendors.

Local Authorities:

– Contact local authorities for qualified vendors on the area of interest. Local authorities may have directories of companies grouped by area of expertise, company size and years of experience.

Chambers of Commerce:

– Contact the Chamber of Commerce for information similar to the one stated for local authorities.

– In some markets, there may be national, regional and local organizations of the Chambers of Commerce. Depending on the project scope, some or all of the should be contacted.

Professional Associations:

– Identify and contact professional associations based on the required area of knowledge / expertise.

– Same as for the Chambers of Commerce, some markets may have national, regional and local branches of the associations.

Web Searches:

– As a complement to the above sources, direct web searches for vendors should be performed. The searches could be addressed to directory portals or to discover web sites presenting the vendor capabilities.

The potential bidders shall be sent an invitation letter, such as the example contained in the Invitation Letter Template. This letter provides the vendor with an abstract of the project scope and relevant RFx dates. The provided format will be populated with an abstract of the scope of work, information on the relevant dates of the process and the contact points at both the NaaS Operator and the vendor.

Those vendors who have confirmed interest in responding to the RFx process shall be submitted a Pre-Qualification Form as the one included in the Pre-qualification Template. This form provides key questions that the NaaS Operator will use to determine the suitability of the vendor to address the project scope. This qualification form will include technical, commercial and legal questions with the objective to short-list the number of companies receiving the final RFx document.

The Pre-Qualification Form can be modified by the NaaS Operator by adding or removing questions as they appear relevant to the process. The vendor shall be provided with an Excel form only containing the questions in the Pre-qualification Template. When the responses are received, the NaaS operator will insert them into the template to allow for a side by side comparison between vendors.

Selected vendors will enter into the RFx Execution Phase and will receive the RFx documentation. Disqualified vendors shall be sent a thank-you letter to ensure proper relationships are maintained for future processes.

⇐ Previous

4 RFx Execution phase

In the RFx Execution Phase, a formal document is written to compile the scope of work, technical, commercial and legal requirements, and the relevant process dates. The RFx document may be complemented with addendums and references to internal or external specifications to complement the information that the vendors will require to provide an adequate response. This written document plus its addendums is often referred to as the RFx Package.

The RFx Execution Phase begins with the recollection of the information that will be shared with the vendors, which will include the scope of work, technical and financial requirements, process dates, and the points of contact during the RFx process, etc. These inputs to the RFx Document development process are further discussed in section 4.1 below.

The RFx Document Development phase consists of the construction of the RFx package by consolidating all the inputs into a single document (plus addendums), which will be shared with the vendors. The RFx Package must be self-contained, with all references being either included in the package or publicly available.

In the RFx Distribution phase, the RFx Package will be distributed to the pre-qualified vendors. Once distributed, the NaaS operator will be receiving and answering queries related to the process, which may include meetings and presentations when required to ensure a full understanding of both the request and the responses.

After reception of the responses to the distributed package, the vendor evaluation process will begin, as described in section 4.4.

4.1 RFx Information Collection

The PM designated during the RFx Preparation phase is responsible for organizing the gathering of the information that will be required to develop the documents that compose the RFx Package. Not all the recollected information will be part of the package; some components may be used as complementary, internal clarification or to provide context to the process.

The checklist in Table 3 below provides a reference listing of the information that the NaaS Operator should compile prior to formalizing the RFx document. When defined as part of the general procurement process of used in prior RFx, some of the items in the checklist will have already been compiled and should be reused to ensure consistency with the NaaS Operator Procurement Process and Vendor Management module.

Note that, for small projects and when no purchase is forecasted in the short term (e.g. under RFI processes) some of the items in this list may be omitted or simplified.

4.2 RFx Document Development

The RFx Document Development phase considers the development of the document(s) that compose the RFx Package, which contains all the information required by the vendors to provide a response to the RFx request.

The main input to this process is the list of documents compiled during the RFx Information Collection phase. Other relevant inputs are consultancy to SME for specific information on the scope of work and lessons learnt from previous RFx processes. Other PlayBook Modules also would include RFx templates, tailored for each business need.

The RFx document is framed according to the outline in Table 4 below, where the applicability of each section to each one of the RFx processes is also captured on the RFI/RFP/RFQ columns. This outline is developed in detail, together with a complete template, in section 5:

4.3 RFx Distribution

The RFx Distribution process delivers the RFx Package to the bidding vendors and manages the reception and response to the queries and clarification requests.

As part of the information to the bidders described in section 5.1, the NaaS Operator will inform about the timeline and format for vendor queries.

The Bidders Queries and Responses Template document provides a template that the vendors can use to submit their questions. The template provides a spreadsheet where each row will be used to request clarification on a single item.

Upon reception of the queries from all bidding vendors, the NaaS operator will combine all responses into a single response document with the same formatting, which will be submitted back to the bidders. The query response shall include no indication on which vendor formulated which question but will allow all vendors to receive all responses and thus obtain homogeneous feedback from the NaaS Operator.

4.4 Vendor Evaluation & Selection

The Vendor Evaluation & Selection process defines the rules to rank and prioritize the responses from the technical and commercial point of view.

Upon reception of the vendor responses, the RFx Project Team will initiate the evaluation of the responses. If required, additional SMEs could be temporarily included in the project team to assist in the evaluation process.

The inputs to the evaluation process are the responses to the mandatory criteria, the responses to the weighted criteria and the price proposal, following the guidelines summarized in the table below. The response items under the weighted criteria consideration can be further divided into Capabilities and Approach. The Capabilities response describes the vendor experience on similar projects in the past. The Approach response addresses the specific requirements of the RFx process and describes how the vendor plans to resolve the scope of work.

The evaluation guidelines in Table 5 are later implemented in the Vendor Evaluation Matrix Template which permits a side by side comparison between the vendor proposals

Once the individual response components (Mandatory Criteria, Weighted Criteria and Price) have been determined, the overall responses are evaluated according to the following RFx Evaluation Process:

1. Proposals that fail to meet the Mandatory Criteria are discarded.
2. Proposals are evaluated for Weighted Criteria (Capabilities and Approach, see section 5.3), and points scored in each section. Proposals failing to meet the minimum score in any of these sections are discarded.
3. Proposals with an abnormally low price are discarded (below 33% of the average price from all proponents)
4. The remaining proposals are evaluated for Price according to the following formula:

5. A complete evaluation score is assigned to these proposals by adding the points scored on each section, and the proponents are ranked in descending order.

The Commercial Quotation Template provides a sample of the document that vendors will populate with pricing for the items requested in the RFx Process. The template must be updated by the NaaS operator before submission with a detailed description of the items for which pricing is requested.

5 RFx Document

The RFx Document compiles all the information that the bidding vendors require to respond to the NaaS Operator request. This document presents the business need driving the scope of work, and presents the vendor with the technical, commercial, and legal requirements that define the request under a section with Information for Bidders. The Scope of Work is defined in detail, considering the type of RFx process. The RFx Document also includes a description of the response format and the instructions to submit such response under the Bid Proposal Preparation and Submission section. Finally, specific sections in the RFx Document describe the Proposal Evaluation process and the mechanism for Contract Award, which includes a draft of the final contract.

The RFx Document sections are developed in the following paragraphs. An RFx Document Template is also part of this module as a reference. The template has been developed around an RFP process, which is the most complete of the three possibilities (RFI/RFQ/RFP) discussed in this Module. The NaaS Operator may customize such template following the indications in the sections below and the applicability correspondence in Table 4. Because RFIs are a significantly simpler process, a specific RFI Document Template is also included in this module.

5.1 Information for Bidders

The Information for Bidders section provides the vendor an overview of the RFx Process, including a Statement of the problem or business need to be solved by the RFx process, information regarding the timing and place to submit RFx responses, and the point of contact for communications between the vendor and the RFx Project team. It also includes instructions to Bidders to issue process queries and management of possible modifications to the RFx.

This section informs the respondents about the scope and conditions of the RFx process. The outline described here is used in the RFx Document Template to establish the document structure.

The Introduction Section provides a brief introduction to the NaaS Operator, its mission and vision, and the business need that has been detected and the RFx process is attempting to resolve.

The Statement of Purpose section establishes what is the goal of the process (identify potential vendors, obtain proposals for solutions, receive prices for items or services) and what is the level of commitment of the NaaS Operator with the outcome of the process (e.g. initiate a more detailed RFx, purchase goods or services, obtain market information).

The Project Schedule defines time constraint s around the goal of the project, such as deadlines on the delivery of the products or services.

The RFx Timeline and Review Process section informs about the time constraints of the RFx process, the intermediate milestones and the target date for project assignment, when applicable.

The Point of Contact section defines the contact person(s) for any RFx related queries, and the mechanisms and timeline to issue those queries, including predefined querying formats when applicable.

5.2 Scope of Work

The Scope of Work section includes all mandatory and desirable requirements stating the specific needs of the RFx process. This information must be consistent with the RFx Statement of Purpose and provide all details needed to properly understand the technical and commercial needs, the project limitations and constraints, both in time schedule as well as in the budget. It also communicates additional non-functional requirements that the vendor is expected to meet, such as expectations around testing and training requirements associated with the proposed solution and documentation requirements that the vendor must provide.

This section will contain the information described in the outline below; the RFx Document Template includes such outline in the corresponding RFx section, complemented with companion test and predefined timelines that should be customized by the NaaS Operators on each RFx process.

The outline of the RFx Scope of Work must include the following elements:

1. Scope of Work
• Statement of Scope: Describe in detail the current situation (i.e. current contract, company situation) and why the product or services are required; set out the objectives or goals of the services and other material information not included elsewhere. Provide details about the project, including features, functionality, deliverables and performance standards
• Technical Requirements: Provide a summary of the technical requirements for the service or product and refer to an addendum with a full description of all technical specifications that the solution must fulfill to be considered. Include references to international standards as appropriate.
  
  • Technical specifications
  • Health and Safety requirements
  • Environmental requirements
  • Testing and Acceptance

  The
  technical requirement specification must include:

1. The criteria for entry, which includes a full description of the minimum and recommended requirements.
2. The execution requirements, which may include the need for interim deliveries and/or validations on the product and service.
3. The acceptance criteria, which specify the testing and validation requirements that must be fulfilled to consider the product or service as properly delivered.
• Project Documentation: All project-related documentation, generated by the vendor to fulfill the scope of work of the RFx
• Training Requirements: Need for the vendor to train the NaaS Operator to make good use of the items delivered as part of the RFx.
• Warranties: Applicable guarantees on materials, resources and tools used by the vendor to deliver the RFx scope. The vendor further warrants that the products and services provided hereunder will conform to the requirements of this Agreement.
• Project Plan: When required to implement the solution, the vendor must provide a detailed project plan. The project plan must include a description of project phases, relevant milestones, time plan and resource plan which ensures the delivery of the products and services covered by the Scope of Work of this RFP on a timely basis, with all delivery being completed and ready for acceptance according to the project schedule
• Project Governance: The vendor must provide a description of the oversight function that encompasses the project life cycle. It must include the definition of the meetings policy and periodicity, the reporting approach, the mechanisms for risk and issue management, assurance, and project management control processes. When required and applicable, the NaaS Operator may impose Service Levels to define the availability of the solution in working condition. The NaaS Operator will define a RACI matrix to clearly identify the responsibilities of the vendor, the NaaS Operator or any other affected stakeholder in the execution of the project.

5.3 Bid Proposal Preparation and Submission

The Bid Proposal Preparation and Submission chapter provides the Proponent with instructions about the formatting and structure of the submission of their responses and the documents and sections which are requested to be included. This Section will contain the following elements:

2. Bid Proposal Preparation

2.1. Requirements for Proposals: This section specifies the format and structure of the documents that will be sent to the NaaS Operator. All vendors must adhere to this structure to facilitate assessment and comparison between proposals.

2.2. Statement of Compliance: This Statement provides certainty on the interpretation of the responses. The vendor must explicitly confirm understanding and compliance with the mandatory requirement, the criteria for entry, execution and exit and the responsibilities (RACI) matrix mentioned in section 5.2 of this PlayBook.

2.3. Vendor Capabilities: The proponent must provide references to previous RFP processes, projects, commercial relations or partnerships that are relevant to demonstrate the ability of the vendor to address the Scope of Work of this RFP.

2.4. Approach: This section is very specific to each RFP process; the NaaS Operator specifies here the requirements for response delivery, and how such responses must be structured.

2.5. Price: This section refers to the proposed price for the above-mentioned approach. The Commercial Quotation Template document may be used as a reference to how prices could be presented.

5.4 Proposals Evaluation

The Proposals Evaluation chapter provides vendors with a description of the evaluation and selection process. It creates awareness of events such as the creation of an Evaluation Committee within the RFx Project Team from proposal assessment. Occasionally, the Evaluation Committee may choose to make use of the expertise of outside consultants in an advisory role.

The Evaluation Criteria is here exposed to vendors, addressing price, technical compliance, and other factors. Proposals will be evaluated considering the criteria set forth in section 4.4.

After reviewing the proposals, the evaluation committee may ask one, some or all the Respondents to clarify certain aspects of their proposals. A request for clarification may be made in order to resolve minor ambiguities, irregularities, informalities or errors. Clarifications cannot correct any deficiencies or material omissions or revise or modify a proposal, except to the extent that correction of apparent mistakes results in a modification.

5.5 Contract Award

The Contract Award chapter provides references to Terms and Conditions as well as generic contract items, which are further developed in the NaaS Operator Procurement and Vendor Management module. The specification of the legal documentation bound to the RFx process is heavily influenced by the national, regional and local regulations, and may significantly vary from country to country.

The content of the Contract Award section must contain the following elements:

3. Contract Award

3.1. Contract Terms and Conditions: Expected start and end date of the contract, renewal options, payment terms, plus incentives or penalties based on the vendor’s performance.

3.2. Service Requirements: An extensive list of services provided by the vendor, which are not explicitly captured on the Contract.

3.3. Related Documents: An indication of additional documents applicable to the agreement, as defined in the NaaS Operator Procurement Processes.

Short List Negotiation

Once the evaluation process has been completed, the NaaS Operator may enter into negotiations with the best-ranked vendor when it is in the NaaS Operators best interests and to maximize the NaaS Operators ability to get the best value. This negotiation phase is not mandatory, and in principle, it would be limited to sizable processes where there are opportunities for additional savings.

Therefore, the vendor is advised to always submit its best technical and price proposal in response to the RFP since the NaaS Operator may make a contract award based on the content of the initial submission, without further negotiation and/or BAFO (Best and Final Offer) with any Respondent.

All contacts, records of initial evaluations, any correspondence with Respondents related to any request for clarification, negotiation or BAFO, any revised technical and/or price proposals, the Evaluation Committee Report and the award recommendation, will remain confidential until a Notice of Intent to Award a contract is issued.

Best and Final Offer (BAFO)

After evaluating bid proposals, the NaaS Operator may enter into negotiations with one Respondent or multiple Respondents. The primary purpose of negotiations is to maximize NaaS Operators ability to obtain the best value based on the mandatory requirements, evaluation criteria, and cost.

Multiple rounds of negotiations may be conducted with one Respondent or multiple Respondents. Negotiations will be structured by the NaaS Purchase Group to safeguard information and ensure that all Respondents are treated fairly.

Similarly, the NaaS Operator may invite one Respondent or multiple Respondents to submit a best and final offer (BAFO). Said invitation will establish the time and place for submission of the BAFO.

Any BAFO that is not equal to or lower in price than the pricing offered in the Respondents original proposal will be rejected as non-responsive and the NaaS Operator will revert to consideration and evaluation of the Respondent’s original pricing.