DRAFT
InCommon and Internet2 invite the community to respond to our request for proposal entitled: [TITLE HERE]
Introduction
InCommon
The documentation associated with this request for proposal consists of this document and related software requirements linked below.
RFP Response Schedule
Responses to this RFP should be submitted electronically to admin@incommon.org by XXX Eastern Time on XXX May XXX, 2013.
April 15, 2013 - Release and distribution of RFP
April 17, 2013 - Community Webinar on RFP
May 15, 2013, 9:00 am EST - deadline for submitting proposals
June 1, 2013 - Finalists interviewed, if necessary
June 15, 2013 - Vendor selected
Questions can be sent to admin@incommon.org until May 8. They will be answered in a FAQ on this wiki.
Project Phasing
There are 5 key phases to this development Project.
- Delivery of design and architecture
- Discussion: Detailed design and architecture review
- Delivery of code
- Discussion: Detailed code review outlining how the final code differs from the Design presented earlier.
- Community testing and bug fixing
- Acceptance of code
- Optional post-project support
Project Requirements
The software requirements for this RFP can be found at XXXXXX.
Internet2 requires an open development process using the Shibboleth Development list to ensure alignment of finished product.
The delivered software must be open sourced and contributed to the Shibboleth Consortium and Project. [I would think that I2 would "own" the software upon completion of the work, then I2 could contribute to the Shib Consortium. Either way, it would be licensed for open source; do we want to specify a particular license and copyright notice to be put in the code? - DHW]
Communication and Documentation Requirements
The organization awarded the project will have the following communication and documentation requirements:
- Weekly communications with InCommon staff and/or designated community collaborators during the project.
- Delivery of documentation including: Design and Architecture document, Java document, wiki page outlining configuration and logging options.
Submissions
Proposals should include the information outlined in this section; our ability to interpret and apply your proposal to these questions will factor into our decisions.
- Describe in detail the organization's proposal to address the requirements outlined in this RFP, including details such as technologies to be used. Include your approach to unit testing.
- Provide a timeline for the completion of this proposal, including start and finish dates and project phases.
- Describe the fee structure and how Internet2 will be charged.
- Provide a brief history and profile of the organization. Provide a list of the organization's Higher Education clients; include contact name, telephone number, website location, services provided and length of service.
- Detail your experience supporting Higher Education and Open Source Communities.
- Provide evidence of the organization's experience and work with Shibboleth software.
- Describe the project process and methodology including sample deliverables from past projects of similar size and scope. Document examples of the organization's experience in designing/developing each of the project requirements.
- List the project team and short biographies of each team member. If using freelancers or outside resources please indicate them as such; we reserve the right to approve/disapprove of selected resources. Indicate how many full time staff are employed by your organization.
- Provide a communication plan between your organization and Internet2 during the project.
- Please provide an unsigned copy of your standard service contract for our review and any additional stipulations of which we should be aware.
- As an optional component, include a proposal of how the software could be supported after it is delivered to Internet2. If you propose to offer support to campus adopters directly, please include your terms and rates.
Response Review
As Internet2 is a community-driven organization, the review team will not only include Internet2 staff, but also members of the higher-education community.
Internet2 understands that RFP responses will contain competitive data. The responder should coordinate any NDA requirements prior to submission where an appropriate NDA does not already exist. Responders should highlight sensitive and non- shareable information in their response or provide a mechanism for community review team members to obtain a NDA agreement with the responder. Any NDA process must be lightweight in nature to facilitate swift review. (Thoughts about this paragraph? AW)
Assessment Criteria
A RFP assessment team will review the responses using the following criteria:
- Degree of experience working with and knowledge of the Shibboleth software.
- Degree of experience working with the Higher Education and Open Source Communities and InCommon.
- Level of cost effectiveness of the proposal and timely delivery of software.
- Ability to deliver the software as described in the RFP and in the organization's proposal.
- Qualifications of the staff identified to work on the project.
- Level of communications proposed between InCommon and the organization.
- Alignment of the contract with Internet2 legal parameters.
- Flexibility and cost-effectiveness of the optional support proposal.