RFP QAs Round 4.xlsx
XLSX spreadsheet 27 KB Posted
- Attached to
- Customer Satisfaction Survey (CSS) RFP
- Solicitation number
- HTC711-20-R-R021
View the file
Other files
Show all 34
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Q&As
| Q# | Q&A Round | Topic | RFP Document & Para | Question | Answer | |
| 188 | 4 | Ramp-up Plan | PWS section 1.7 | How does the new CLIN structure reconcile with the requirement under 1.7 regarding new interfaces for future task orders? | At this time, the Government requires an interface for triggering and an interface for responses, which will be used to connect any subscriber system approved by the Government. Para 1.7 outlines the fact that the Government could require additional distinct interfaces in the future. Should that transpire, a contract modification will be executed to update the quantity required. | |
| 189 | 4 | Interface | Appendix 4 | Can the Government explain how the potential for three (previous, current, and next) versions of the trigger service fit within the current scope of work? It is our understanding that the interface (for DPS and/or MilMove) would be complete following ramp-up. | Proposed versioning of web services should follow best practices. Different approaches (e.g. SOAP or REST) have different complexities. The Government will evaluate the proposed approaches. The Government anticipates the trigger service will be system agnostic and based on the approach outlined in the PWS. | |
| 190 | 4 | Interface | Appendix 4 | Why does the Government anticipate new functionality will be added to each interface, so that previous, current, and next versions may all be required following ramp-up? | The Government does not anticipate changes to functionality. The interfaces are expected to have persistent function (trigger or response). Laws, Regulations, and policies can change and that might drive a change in trigger or response or payload. The COTS products used to create and sustain web services will change over time (e.g. security patches, version upgrades, etc.). These changes can impact web services and consuming systems. Security protocols can change as threats emerge. The Government expects experienced providers to understand these and perhaps other drivers and propose accordingly. | |
| 191 | 4 | Interface | Appendix 4 | How much involvement will the Government/interfacing partners have in interface design? | The government expects proposals to include collaboration. For example, integration with the Defense Logistics Agency's Global Exchange for routing responses will have certain requirements. | |
| 192 | 4 | Interface | Appendix 4 | Can we understand this requirement to mean that all new interfaces must not break existing interfaces? If this understanding is correct, can the Government update the language to remove references to "versions" or correct our understanding? | To be proposed. The Government expects the contractor to ensure changes made to web services do not break the respective information exchanges. Different approaches to web services have different complexities which will impact versioning. The Government expects contractors experienced in this space will understand those differences and propose accordingly. | |
| 193 | 4 | Interface | Government Q&A #24 | Can the Government clarify whether it expects separate interfaces for DPS and MilMove or one interface for both? | The government expects a single web service for triggering that will be consumed by multiple systems (e.g. DPS, MilMove, etc.) submitting triggers to initiate surveys. | |
| 194 | 4 | Interface | Appendix 4 | Are the two interfaces described in the reference text the trigger and the response, or two sets of triggers and responses? | The government expects a single web service for triggering that will be consumed by multiple systems (e.g. DPS, MilMove, etc.) submitting triggers to initiate surveys. Only one response destination is anticipated. | |
| 195 | 4 | Interface | Appendix 4 | Will an equivalent description language such as WADL or OpenAPI be acceptable? | To be proposed. | |
| 196 | 4 | Interface | Appendix 4 | Can the Government verify that DPS supports WSDL 2.0? | Yes, if the CSS contractor uses WSDL 2.0, DPS would provide trigger information based on the web service as defined by the CSS contractor. | |
| 197 | 4 | Ramp-up Plan | PWS section 1.7.1 | To clarify: Are the downloadable reports mentioned in section 1.7.1 examples of what will be sent to the data warehouse or should they be considered monthly reports with additional analysis to include figures, text, and tables? | As a minimum, one downloadable report shall contain all data elements planned for transition to the data warehouse and in a format useful for analysis or importing (e.g. CSV, Excel, etc.) | |
| 198 | 4 | Ramp-up Plan | PWS section 1.7.1 | Are downloadable reports identified in PWS 1.7.1 meant to be an example of the data that will be transferred to the Government Data Warehouse? | One downloadable report shall contain all data elements planned for transition to the data warehouse and in a format useful for analysis or importing (e.g. CSV, Excel, etc.) | |
| 199 | 4 | Ramp-up Plan | PWS section 1.7.1 | Are downloadable reports identified in PWS 1.7.1 to be available only during Ramp-Up or are they to be available to the Government for the duration of the contract? | The feature should persist so it can be used when needed (e.g. web service unavailable, testing new survey questions, etc.). | |
| 200 | 4 | Question Deisgn | Appendix 2 / RFP pg 58 | If we were to design a survey question about "reassembled if disassembled at origin," could we provide a sixth survey response option of "Not Applicable (N/A)?" | Survey question design is unique to each offerors technical approach. Questions can be changed or altered as supported in each offerors approach. | |
| 201 | 4 | Atch 7 CSS Task Order 0001 PWS Amend 2 | 1.3 System Integration | Will the government clarify that the single API connection between the government’s system of record (i.e., DPS or MilMove) will be based on an open API framework provided by the offeror, such that the mapping of trigger data/ metadata will be performed by USTRANSCOM according to what is required by the offerors CSS System? | Client systems providing triggers to the CSS will be required to do so using the CSS web service once that service is operational and accepted by the Government. | |
| 202 | 4 | Round 3 | N/A | Comment: The Government mentions “going through a DAAS” in questions 138, 139 and 151 to get to the IGC. Question 151 states “it will go through the GeX. There is no mention of a “DAAS” anywhere in the solicitation. There is insufficient detail in Appendix 3 to assist industry to better understand the changing/clarified interface/integration requirements that have occurred in RFP amendment and discussed in multiple Q&A responses. | ||
| Questions: 1) Can the Government please provide an explanation of what the “DAAS” is referring and how it related to connecting to the CSS contractor to or “through” GeX and the IGC? 2) Can the Government clarify what is stated in the response to question 151 regarding going through the GeX vice in questions 138 and 139 where it states CSS data goes through the DAAS? 3) Would the Government please provide a more detailed Appendix 3 drawing with respect to Systems Triggering and Systems Response that need to be separately priced in in the new CLIN 005 and CLIN 006?. | 1) https://www.dla.mil/HQ/InformationOperations/DAAS/Offers/GEX/ |
2) The DAAS proides routing services for payloads transiting the GeX
3) The Government expects companies experienced with APIs and web services will find the narrative suffcient to prosse how those interfaces will be implemented.
| 203 | 4 | Appendix 4 | 1. Triggering Paragraph | Comment: The Government expects this to be a web service and the offeror to maintain up to three versions of the service (previous, current and next) | |
| Question: Can the Government please provide a more detailed explanation of what is meant by “up to three versions of the service (previous, current and next”? | The Government does not anticipate changes to functionality. The interfaces are expected to have persistent function (trigger or response). Laws, Regulations, and policies can change and that might drive a change in trigger or response or payload. The COTS products used to create and sustain web services will change over time (e.g. security patches, version upgrades, etc.). These changes can impact web services and consuming systems. Security protocols can change as threats emerge. The Government expects experienced provides to understand these and perhaps other drivers and propose accordingly. | ||||
| 204 | 4 | Q&A Responses | N/A | Comment: Appendix 4 states No matter how many entities connect via the trigger, all the data will be fed to the GEX. Response to IGC Q&A responses states that data must go through the DAAS and/or GeX to the IGC | |
| Questions: 1) Please confirm whether all PWS 1.6 reports are also required to go “through” the GeX/DAAS to the IGC or are some reports to be sent separately to the COR via another medium? 2). Please clarify what medium should be used to deliver bi-monthly ramp up and monthly CDRL reports? | 1) All response data will be transported by the GeX using the DAAS to IGC. |
2) All deliveries should be electronic, either by email or via API (e.g. the responses delivered electronicall to GeX/DAAS).
| 205 | 4 | Appendix 4 | N/A | Comment: Appendix 4 states: The CSS contractor is to build two (2) interfaces to support two (2) external information exchanges, trigger and response. Although two triggering systems are called out here, the triggering interface shall be used to connect any subscriber system approved by the Government. This sentence appears to state that the Government may require the contractor to any new system (s) that are approved by the COR, but are currently not known or scheduled in the base year. | |
| Questions: Can the Government confirm that the two external systems referenced are DPS and MilMove? If not please explain what is meant by this requirement? 2) Can the please clarify whether industry should factor these unknown systems and timeframe required into their Base Year ramp-up cost in CLIN 005/CLIN 006 or expect a follow on TO or mod to be negotiated when Government requirements are known? | 1) Two of the systems consuming the web service will be DPS and MilMove. Additional systems submiting triggers is also possible. |
2) System connections will be added IAW the contract Ts&Cs. The Government expects the cost of connecting additional triggering systems to the trigger web service to be proposed and priced in advance.
| 206 | 4 | Attachment 2 | N/A | Comment The amendment changed the POP dates to begin 1 Jan 2021. However, the pricing sheet still indicates a contract start of 1 Dec for the base year and each of the option year. | |
| Question: Please clarify. | Pricing sheet will be amended to reflect the updated Period of Performance. | ||||
| 207 | 4 | Attachment 2 | N/A | Comment: It appears that the Government deleted the previous Systems Integration/Integration CLIN 005 and split the requirement to conduct system integration into two separately priced CLINS. New CLIN 005 appears to be focused on all system trigger connections that may be required for past, current and future systems that must be completed during the ramp up period in the base year. New CLIN 006 appears to be focused on the system response aspects of the integration, however no changes were made to the System Integration paragraph of the PWS and the requirements for the Response section requirements of the amended Appendix 4 are vague. | |
| Questions: 1) Can the Government please provide an explanation for why the previous CLIN 005 was split into two separate CLINS? 2) Can the Government please provide clarification on what specific requirements are to be priced to support the system response section of Appendix 4? | The CLIN was split beucase there are two kinds of integration. 1) The Trigger, which the Government expcts will be a web service and consumed by more than one Government and/or commercial system, and 2) the response, which the governmnt expects to terminate only in the GeX using the DAAS to transport the response payloads to a data warehouse. |
Splitting the CLIN allowes for better price fidelitiy and recognizes the different in connection types.
| 208 | 4 | Appendix 4 | 1 Systems Triggering | Comment: In appendix 4 under "1. Trigger" the government states that the CSS contractor should provide a WSDL for the implemented the API. Questions: Does this imply that the government expects the CSS contractor to implement a SOAP API or would the government also accept a REST API? If the government is willing to accept a REST API implementation then would the government accept Swagger (https://swagger.io/) as a means of documenting this REST API? | To be proposed. Either architcture is acceptible and exposing the documentation via swagger is similarly acceptible. |
| 209 | 4 | Amendment 1 | Page 4 | Page 4 Paragraph 1 states "... Each volume shall include a cover page including offeror name, title of proposal, volume number, and solicitation number." Regarding Volume IV- Price, is a cover page and table of contents required? If so, how might we input a cover page on the excel document that is locked for changes or copying? | Simply submit a cover sheet in Microsoft Word or Adobe PDF with the pricing sheet. |
| 210 | 4 | Amendment 1 | Page 10 | Regarding Volume IV- price, is a narrative of the pricing required? | A narrative of the pricing is not required. Should offerors choose to submit a narrative, they may do so with the pricing sheet. |
&"Times New Roman,Regular"&12Global Household Goods Q&As
RFP #HTC711-19-R-R004
File details come from the government source that posted it. Updated .