The U.S. Forest Service is engaged in an ongoing effort to modernize and simplify their permitting processes. One facet of this effort is an online permitting application, or making the applications for many Forest Service permits available online.
The objective of this Performance Work Statement is to develop an online permitting module focused on Christmas tree sales. Every winter, many national forests sell “tags” for Christmas tree cutting (“tag” is the term for a Christmas-tree-specific permit). After purchasing a tag, members of the public can travel to parts of nearby national forests to cut down a tree from a designated area. Currently, the tags are only available for purchase at Forest Service offices and local retailers. The application being developed will enable people to purchase and print Christmas tree tags from home, offering a much better user experience.
This module must be centered on the needs of its end users, including:
- Members of the general public purchasing Christmas tree tags
- Forest Service law enforcement officers and forest protection officers
- Forest Service special forest product managers
The Christmas tree module will extend the existing application developed for the special use permit intake module. As such, it will use a Angular 4 frontend, a Node.js server (connected via RESTful services), and a PostgreSQL database.
This application will initially be used by four pilot forests: the Arapaho & Roosevelt, Mt Hood, Flathead, and Shoshone National Forests, but should be built so as to scale across multiple forests, districts, and permit administrators. Eventually, the Forest Service may consider making the application available to additional types of end users and permittees.
To fulfill the objectives for performance of this task order, the Vendor must meet the user needs described in the following subsections. Please note that, in subsequent sprints, we may refine these objectives to ensure we’re continually meeting user needs. In agreement with the product owner, we may modify, add, retract, or reprioritize user stories to reflect additional research.
In general, a Christmas tree permitting system would support collecting a customer’s payment information and issuing them a paper permit.
The Vendor must build a custom software module off of the existing online permitting platform using agile methods that fulfill the following user stories or new user stories as the client and the vendor agrees:
- Find areas in national forests near me where I can cut Christmas trees.
- Get a permit that’s valid for one time use (by being only valid for a particular day, for example).
- Be directed to Pay.gov to pay for my tags.
- Print a Christmas tree tag from my personal computer so I can avoid visiting a Forest Service office.
- Receive instructions about where to appropriately place my printed tag in my vehicle so law enforcement officers can see it from a distance.
- Receive a set of rules and guidance on how and where to safely cut a Christmas tree in the forest I pick. (For example, this guidance will help me understand road conditions, areas where cutting is allowed, and so on.)
- Receive an email so I know what online permits may be used that day.
- See a printed permit displayed in a public member’s car, and know whether each customer has a valid permit for a given day.
- See forest-specific instructions on each permit, so I know the permittee has been advised of the terms of their permit.
- Retrieve a list of who have a valid permit, so that I can respond to calls from LEOs and FPOs in the field.
- Enter a manual permit number generated by a legacy timber system to associate with a batch of Christmas tree tags.
- Retrieve the number of tags that have been issued since the manual permit number was last set.
- Customize the warnings and instructions included in my forest’s online sales form.
- Build as a modular component to the existing intake module.
- Integrate with the U.S. Treasury Pay.gov payment system.
- Work will be conducted in two-week sprints and reviewed at the end of each sprint for acceptability per the Quality Assurance Surveillance Plan (“QASP”) before moving on. The Vendor and Government may mutually agree to alter sprint length as needed.
- Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end), with all artifacts from usability testing and/or other research methods with end-users being made available at the end of every applicable sprint.
- All software code delivered under this order shall comply with the 18F open source policy in effect as of the date of award.
- All software code delivered under this order shall comply with the 18F Accessibility Guidelines in effect as of the date of award.
- The contractor will use the US Web Design Standards..
- The contractor will develop and deliver a Forest Service specific style guide similar to this NASA fork based on the US Web Design Standards.
- All dependencies (and licenses for dependencies) must be listed.
- All major functions must be documented inline.
- Code must be stored in a version-controlled, open-source repository, with all code needed to run the front-end of the prototype available in that repository.
- All Contractor Key Personnel, employees, agents, subcontractors, and subcontractor personnel who will have access to documents or data during the performance of their duties under the contract shall execute the attached Non-Disclosure Agreement and return it to the CO within 5 calendar days of award and before being given access to such information or documents.
The Government’s team and the Contractor’s team will hold a Post Award Orientation Conference (“Vendor Kickoff”) within 10 calendar days of Award. The Government’s team will include the Contracting Officer (“CO”), the Contracting Officer’s Representative (“COR”), the TTS Product Lead, and the Product Owner (“PO”).
Ideally, this will be physically located in Washington, DC, but may be done virtually. The purpose will be to review and clarify the project’s objectives and the Government’s expectations. Additionally, the Government will address any questions the Contractor may have. Discussion topics shall include, but not be limited to: Introduction of the Contractor and Government staff Understanding of the workflow Project management expectations Agreement on communication methods Discussion of any other relevant specific concerns Finalizing Contractor Teaming Arrangements (CTAs)/Subcontractor arrangements
The Contractor’s Project Manager / ScrumMaster shall be responsible for daily operations as well as coordinating and communicating with the TTS Product Lead. Daily operations may include: Daily standup via Google Hangouts, Zoom, appear.in, or other web-based video chat software Chat operations via Slack Manage and update user stories and workflow tasks in a shared project management system, such as Trello
The Contractor must provide invoices on a monthly basis.
Ensure and agree that all deliverables, products, licenses, designs, data, documentation, tests, user research notes, source code, configuration settings and files, and materials developed throughout this call order will be the property of the U.S. Government and in the public domain. Two weeks prior to call order conclusion, provide a brief transition plan for all deliverables, products, and materials in coordination with the TTS Product Owner and COR. Coordinate with the TTS Product Owner and COR, and potentially another contractor, and implement the transition plan. Provide any other reasonable assistance to the Government to stand-up the application.
During the transition to the Government or a new contractor, the Contractor shall perform all necessary transition activities. Expected transition activities may include, but not be limited to: Continuation of full services to TTS and other customers Participation in meetings with the Government or a new contractor to effect a smooth transition and provide detailed information on the operation of all deliverables, at COR and the TTS Product Lead's discretion Training of new personnel, either Government or a new contractor, during transition period Appropriate close-out of any outstanding technical and related performance elements for this task
The final report shall include a list of sprint tasks completed, documentation, and a link to the code repository developed for TTS. Should the Contractor be terminated prior to the end of the period of performance, the Contractor shall transfer all project materials to the COR and the TTS Product Lead within two weeks of the COR and the TTS Product Lead’s request.
This application will extend the Forest Service online permitting system to include the sale of Christmas trees. To satisfy the needs of members of the public, law enforcement forest protection officers, and Forest Service special forest product managers, the vendor will provide the following deliverables by the conclusion of performance.
| DELIVERABLES | DUE DATES | CONTENT DESCRIPTION |
|---|---|---|
| Code repository of product | Ongoing with every applicable sprint | Version-controlled open source code repository that comprises product that will remain in the public domain |
| Issues in repository from usability testing | Ongoing with applicable sprint | Usability or other issues discovered via usability testing and documented in the project’s source control system |
| Design deliverables | Ongoing with every applicable sprint | Mock-ups and/or design files if applicable, or design changes reflected in the development product |
| Issues from user testing | Ongoing with applicable sprint | Issues raised by user testing |
| Development product | Ongoing with applicable sprint | In-progress development product, accessible on the web via staging server / development server |
The Vendor must provide a team of qualified personnel — people whose knowledge and experience allows them to successfully perform the work outlined in this task.
Proposed personnel must have a strong technical experience base in the following:
Technology stack as described in Section 2.1.
Using human-centered design methods to build and test form-driven, web-based applications. Human-centered design practices include: Research, such as (but not limited to) contextual inquiry, stakeholder interviews, and usability testing User experience design Front-end development Sketching, wireframing, and/or prototyping Visual design Content design
Mobile-first approaches, performance budgeting, and progressive enhancement Building and testing public facing sites and tools Open-source software development Cloud deployment - for demonstration hosting Open-source login/authentication services Agile and Scrum methodologies Low-bandwidth environments Managing and securing PII
For this task the following Key Personnel are necessary (as detailed at https://agile-labor-categories.18f.gov)
- Product manager
- Interaction designer / user researcher / usability tester
- Offerors must choose only one of any of these three labor categories as the third key personnel position: technical architect / backend developer / frontend developer
- Offerors must choose only one of any of these three labor categories as the fourth key personnel position: Writer / Content Designer / Content Strategist
In the event a Key Personnel member becomes unavailable during the course of the solicitation and evaluation process, the Contractor shall immediately notify the Government and provide a substitute individual with resume that fits within all the guidelines outlined in section 5.0.
In the event a Key Personnel member will be substituted, the Contractor shall provide complete resumes for proposed substitutes, and any additional information requested by the Contracting Officer no later than 5 business days after notifying the Government of the need for a substitution. Proposed substitutes should have comparable qualifications to those of the persons being replaced. The Contracting Officer will notify the Contractor within 15 business days after receipt of all required information of the consent on substitutes. No change in fixed unit prices may occur as a result of Key Personnel substitution.
The following milestones are provided for this solicitation.
| No. | Due Dates | Acquisition Event |
|---|---|---|
| 1 | June 22, 2017 | Solicitation Released |
| 2 | June 29, 2017 by 3:00PM EST | Questions about Solicitation Due |
| 3 | July 12, 2017, 2017 by 1:00PM EST | Written Quote Submissions Due |
If you’d like to ask questions or comments about this RFQ, you must submit them as issues in our GitHub repository at https://github.com/18F/bpa-fs-xmas-trees no later than the date above, to allow the Government sufficient time to respond. All questions and comments will be publicly available. Please subscribe to the repository if your firm would like updates about changes and comments. Questions or comments received after the required deadline will not be answered. Any changes to this RFQ or attachments will be posted as an amendment on GSA eBuy.
Quotes must be valid for at least 60 calendar days after the quotation response date. Information provided in the quotation must be concise, specific, and complete.
During this process, Offeror(s) shall direct all written or verbal communications to the contract specialist. Communications with other officials may compromise the competitiveness of this acquisition and, for this reason, aren’t allowed.
Offerors are required to submit a Potential Organizational Conflict of Interest Statement (COI). If the Offeror has any potential organizational conflicts of interest, they must provide a statement describing the potential or actual COI with their quote. The information in this statement must be accurate and complete so that a CO can assess the nature of the potential conflict of interest.
Finally, Offerors must provide their COI responses in the appropriate field of the provided Google Form in order to be considered for award.
To make the process easier for potential Offerors, we have provided a Google Form for the written technical quote portion of submissions. Please note that each Offeror can enter only one submission (no alternate quotes will be allowed). All offers must be received no later than the due date indicated above.
Written technical quotes will only be accepted via the provided Google Form.
The Google Form is available here.
- Technical understanding and approach
Offerors should describe their understanding of the performance objectives for the requirements (described in full in Section 2). Offerors must also provide a comprehensive staffing plan based on their technical understanding of and approach to the requirements, along with an estimate of the time their team will need to complete the requirements (known as an estimated level of effort). The estimated level of effort must include a breakdown of labor categories, including team members’ titles, number of personnel, and hours.
All proposed skill levels/labor categories need to align with the offeror’s aBPA award. Offerors must provide price-related information separately via the eBuy system (in other words, not as part of the written technical quote).
- Key personnel.
The offeror must provide a list of key personnel. This list will include each team member’s name, title, contact information, and proposed duties and roles, along with resumes for each proposed key personnel member in accordance with Section 4.2 of this solicitation.
Each proposed team member’s resume should include the following:
A summary of the person’s experience and capabilities A summary of the person’s technical background Educational history Work experience Accomplishments relevant to the solicitation For technical architects, backend developers, frontend developers, and user researchers, a link to the person’s GitHub repository.
If an offeror or teaming partner would like to include, as part of their key group of personnel, someone they’re not currently employing, they’ll need to include a letter of intent signed by that person (in accordance with Section 4.2 of this solicitation).
-
Though resumes and letters of intent don't impact the total page limit for the quote, please make sure all resumes are no longer than one page.
-
Similar experience - code repository submission
To be considered for award, offerors must provide links to the relevant version controlled repositories (public or credentialed) in the proper field in the Google Form.
Code repositories submitted must meet the following requirements: They must be for projects completed within the last three (3) calendar years. They must have staffing profiles of at least four full-time equivalent (FTE) personnel. They can cover performance periods of no more than six (6) months. The projects must have been delivered by one of the following: The Offeror A teaming partner (proposed in response to this solicitation) Proposed key personnel
In addition, we will express a strong preference for Offerors who submit code repositories that are: Publicly available In the same runtime language as proposed as the existing online permitting platform (AngularJS and Node.js). Proposed key personnel were involved Include design artifacts and the results of user research Feature projects that are roughly similar in terms of size, scope, and complexity.
When you submit repositories, please describe how the offeror’s team was involved in the development.
Written technical quotes that fail to include any of the items required above will not be considered for award.
If potential offerors plan to use any Contractor Teaming Arrangements (CTAs) or subcontractor arrangements, then they must provide a description of these arrangements. These descriptions should list company names, personnel, and the parts of performance to be provided. Because CTAs and subcontractor arrangements are not the same, offerors must clearly state whether they’re proposing a CTA or subcontractor arrangement. If the offeror is not proposing any such arrangements, they don’t need to take any additional steps here.
Offerors should complete both tabs of the pricing template. The first tab is for the base period of six months and the second tab is for the option period of three months. For purposes of pricing the option period, the offeror should assume continued performance by all members of the proposed team at full operating capacity for the duration of the three month option period.
Offerors must submit a separate price quotation using the provided worksheet template in the eBuy system. The price quotation must be received no later than the due date indicated above.
All proposed labor rates must be consistent with the terms, conditions, and rates of your aBPA. Proposed labor rates must be fully burdened and include profit, fringe benefits, salary, indirect rates, and the GSA Contract Access Fee (CAF).
| No. | AGENDA ITEM | MAXIMUM TIME |
|---|---|---|
| 1 | Introductions | Approximately 5 minutes |
| 2 | Open Technical Session | 40 minutes |
| 3 | Closing Remarks and Frequently Asked Questions | 5 minutes |
No part of these verbal presentations - for example, discussions and negotiations - constitutes a procedure in FAR Part 15. For this reason, the Government is not obligated to and does not intend to determine a competitive range, conduct discussions, and request quote revisions.
The verbal presentation consists of an unstructured question and answer session on technical factors. The entire verbal presentation will take place remotely via video chat and/or teleconference.
Offerors will not be able to use or present slides, graphs, charts or any other written presentation materials, including handouts.
During the Open Technical Session, the Offeror will respond to Government’s questions related to the technical aspects of the Offeror’s proposal.
Introductions will be used solely for introducing team member’s names and roles on both the Government and vendor teams. Time for introductions will not be allocated to business development purposes.
Although the technical factors are identified in the RFQ, the core questions are not listed there. Offerors must be prepared to answer questions about the technical aspects of their respective quotes. The goal of these presentations is to assess the technical abilities of the proposed Key Personnel and further elaborate on their proposed technical approach to accomplish the objectives of this task.
This part of the verbal presentations will not exceed 40 minutes. The Contracting Officer will strictly enforce this time limit on all presentations. There will be no follow-up session for further questions after this part of the presentation.
The session will conclude with closing remarks and responses to frequently asked questions for Offerors.
Verbal Presentations will take place via video chat, though audio may be substituted as needed. The Government will coordinate and set up the meeting space accordingly (providing dial-in information or links using a tool such as Zoom or Appear.in).
The Government will schedule the date and time of the verbal presentations with each Offeror after the solicitation closing date and receiving each Offeror’s quote submission. The Government reserves the right to reschedule any Offeror’s verbal presentations date at the discretion of the contracting officer.
Proposed Key Personnel must participate in the verbal presentation. Otherwise, the Offeror will be considered non-responsive and excluded from further consideration.
Offerors may include as many participants as are necessary. Offerors should note that the Government will be asking technical questions during the verbal presentation, so non-technical personnel may not need to attend.
All proposed Key Personnel currently employed by the Offeror or its teaming partners must attend the session - the Government is most interested in hearing from staff who will have a direct role in completing the task.
After the presentations, vendors must email the meeting organizers the names of everyone who attended.
The following will be used to evaluate technical quotes:
The government will review the materials supplied via the responses to the Google Form, including GitHub profiles, example projects, and resumes for proposed personnel for strength of experience in the required skills and knowledge outlined in Section 4 above. The composition of the proposed team is the most important consideration in the government's selection.
We will review the responses to the questions in the Technical Quote to ensure they demonstrate an understanding of the requirements outlined in the PWS and the strength of the proposed user-research and Agile development practices, strong technical approach, and staffing plan.
We will use the verbal presentation to validate how the proposed team accomplished what was done in written submission states. Questions will seek to clarify statements and activities described in the Technical Quote. The verbal presentation will also evaluate how effective the proposed team communicates.
A reasonable price that is consistent with industry standards and the vendor’s proposed approach, but not necessarily the lowest. We intend to pick the vendor that has the best technical factors rather than the lowest price. If we have to choose between the two, technical will significantly outweigh price.
We will review the responses to the questions in the Technical Quote to ensure they demonstrate an understanding of the requirements outlined in the PWS, particularly section 2.1 (the ability to work with the existing tech stack here will be important), and the strength of their proposed user-research and Agile and development practices.
We will also review company and personnel GitHub profiles, example projects, and resumes for proposed personnel for strength of experience in relevant projects.
We will review of Google Form responses for the strength and feasibility of the proposed technical approach, the level of knowledge in the specified technical stack in section 2.2 that is possessed by the personnel put forward by the vendor and within the repositories provided as examples, and the ability of the team to get along with one another and the Government’s team.
We will assess the verbal presentation to validate the technical approach put forward in the written presentation and verify how the proposed team will accomplish it. The verbal presentation will also evaluate how effectively the proposed team communicates and whether there are any intangibles (such as corporate culture and individual personality factors) about the team that may not come out in a written document.
We intend to select a vendor that puts forward the most sensible (“best”) technical approach, Key Personnel that can fulfill the objectives, a reasonable price (not necessarily the lowest), the ability to not only work the way we want (open source, user-centered design, Scrum, etc.) and work well together, but also the ability to work well with the particular personalities that exist on the Government’s team (based on interactions during the verbal presentation).
This task order is a Firm Fixed Price for the services offered on the schedule priced at hourly rates.
Note: The Government intends to use all of the hours proposed by the successful offeror during the period of performance. If it becomes clear during performance that there is a discrepancy between the hours awarded and those needed to complete the work, the Government may, at its option, require delivery of any remaining hours on additional user stories within the scope of the work described in this PWS. The Government may also modify the order to extend the period of performance to allow for delivery of the hours awarded, or may end the work and modify the order to reduce the total number of hours to reflect those delivered. In no event will the vendor be compensated for undelivered hours.
The period of performance is six months and a three month option period.
Option for Increased Quantity—Separately Priced Items The Government may require the delivery of the services herein for an optional period of three months, in the quantities and at the prices stated in the offeror’s schedule. The Contracting Officer may exercise the option by written notice to the Contractor at award or within the performance period of the order.
The primary place of performance will be at the Contractor’s facility.
Business core hours shall be 1000 to 1800 EST, Monday through Friday, on Government-scheduled work days. The Contractor may set their own work hours except that the Contractor shall be available for technical contact by the Government between the hours of 1000 and 1800 EST on Government work days.
The following Points of Contact (POC) applicable to this order will be identified during the Vendor Kickoff meeting.
Contracting Officer (CO) Contract Specialist (CS) Contracting Officer Representative (COR) Technical Point of Contact (TPOC) Product Owner
Please refer to the roles and responsibilities listed on our BPA Roles and Responsibilities Page
Vendors are advised that TTS will publish documents associated with this requirement on a publicly-available website, including any Requests for Quotation (including amendments), Question and Answer exchanges with vendors (source-identifying information removed), and other relevant information that is not confidential or proprietary in nature or source selection sensitive information that would otherwise implicate procurement integrity concerns.
Upon award, TTS will publish the total price of the selected proposal and certain non-source-identifying data (for example, the number of offers, the mean price, median, and standard deviation of price). During the performance of this call order, TTS will similarly publish source code, data related to project management (for example, user stories, milestones, and performance metrics), and top-line spending data.
FAR 52.203-18 Prohibition on Contracting with Entities that Require Certain Internal Confidentiality Agreements or Statements-Representation (JAN 2017)
FAR 52.203-19 Prohibition on Requiring Certain Internal Confidentiality Agreements or Statements (JAN 2017)
- Pricing Template
- Proposed Quality Assurance Surveillance Plan (QASP)
- Non-Disclosure Agreement
- SF1449