1

STATE OF WASHINGTON

DEPARTMENT OF SOCIAL AND HEALTH SERVICES PO Box 45811, Olympia WA 98504-5811

DATE: January 19, 2018 TO: RFP #1723-641 – CSD Mobile Application Bidders FROM: James O'Brien, Solicitation Coordinator

DSHS Central Contracts and Legal Services SUBJECT: Amendment No. 2 – Bidder QA – Part 2

DSHS amends the RFP #1723-641 solicitation document to include:

- Bidder’s Questions and Answers

2

Bidder’s Questions and Answers RFP #1723-641

Question #1: Can companies from outside the United States apply for this solicitation? A: No. Only U.S.-based companies will be considered for this contract.

Question #2: Will the vendor need to come to Washington State to participate in meetings? A: The work is to be performed on site, inclusive of meetings, development, training / coaching and other work.

Question #3: Can we perform the tasks related to the RFP outside of the United States? A: No. All work must be performed within the United States.

Question #4: Can we submit proposals via email? A: Proposals may be submitted via email but must also be submitted in hard copy per paragraph 8, Submission of Responses, on page 28 of the RFP.

“In addition to emailing an electronic copy of their Responses to the Coordinator, Bidders shall submit six (6) paper copies of their Responses for use by the evaluation panel. Paper copies should be exact duplicates of the documents Bidder has emailed to the Coordinator. Paper copies should be organized in the same order as the electronic response, placing Attachments B – E, completed and signed, as applicable, in their alphabetical order based upon the letter corresponding to the Attachment. Information about mailing and delivery of Responses can be found online at: https://www.dshs.wa.gov/fsa/central-contract-services/proposal-delivery-methods]”

3

Question #5: Regarding Section B, Contract Requirements, #5 Bidder Minimum Qualifications, subsections (a) and (b). Is it mandatory that the vendor three (3) years of experience developing apps (a) and completing deployments (b) be exclusively for Health & Human Services governmental agencies, or is equivalent experience with commercial or private sector entities acceptable as well? A: Yes, Bidder qualifying experience must be exclusively for developing and deployment mobile application solutions for Health and Human Services governmental entities.

Question #6: Would the agency be open to looking at an eForms solution (accessible through mobile devices) vs. a mobile application? A: No, an eForms solution will not be considered. The agency’s strategic direction is to offer services through mobile applications. Additionally, a federal grant was secured with that premise.

Question #7: Would DSHS consider a licensed, configurable, commercial-off-the-shelf (COTS) software solution approach that would be configured and integrated using an agile methodology, as opposed to the custom development approach outlined in your RFP? A: DSHS would consider a COTS solution if it could be demonstrated that it is fully compatible with our current architecture and vision for this mobile application. We envision some native functionality for document upload and other features mentioned in the RFP but will also be tied to the existing Washington Connection (WaConn) website for clients’ access to the Client Benefit Account (CBA). WaConn will not be replaced nor will all its functionality be moved into a native mobile application in the foreseeable future. But we desire a somewhat seamless appearance to clients of integration between the two applications (mobile and WaConn).

Question #8: As allowed under Section C.6, would DSHS consider removing the mandatory requirement for “a cross-platform mobile development tool such as Xamarin or Kony”? We believe this restricts participation of vendors that offer native mobile applications that are “compatible with IOS 9.x and Android 5.x and later mobile operating systems” but are not developed using a cross-platform development tool. A: DSHS will not remove the requirement for use of a cross-platform mobile development tool. At this time DSHS/ESA does not have mobile application experience, has not decided on its long-term maintenance and operations strategy for the mobile application, and must keep its options open for maintaining the app in-house. Maintenance of separate code bases for different mobile operating systems would put DSHS at a

4

disadvantage both in having to obtain or develop resources with more skills or by having to pay increased fees to maintain multiple bases.

Question #9: Do we need to create the application using native platform specific SDK (XCode/Swift, Java) or can use common code base (Hybrid App using technology like Xamarin, etc.)?

A: Development of a common code base by use of a cross-platform development tool is required per pg. 11, para. 3, Project Scope – Mandatory Requirements, of the RFP.

Question #10: Does DSHS have web based back-end/database to support mobile apps or do we have to develop the web based back-end/database from scratch?

A: This is the first mobile application for clients of DSHS/ESA/CSD and therefore there are no existing web-based back-ends / databases for the purpose of supporting mobile apps. Its only web-based application to support these client services is Washington Connection (WaConn), which is a front end with interfaces to multiple State databases containing client account information.

Question #11: DSHS would like to convert Waconn online application portal (https://www.washingtonconnection.org/) into a responsive website so that it will open in mobile apps only or looking to have some functional development/changes in user account section/other sections of the website?

A: At this time it is known that DSHS must make parts of WaConn adaptive-responsive in order to work better with mobile applications. This change is planned but will likely not be implemented until October 2018. Other changes to WaConn to support mobile applications are not planned at this time but DSHS remains open to proposals that would bring value to clients of the mobile application. WaConn development is done in-house because of its dependency on our ACES system and its release process.

Question #12: Also is making the WaConn website responsive within the scope of the project for which we need to provide cost estimate or it is out of scope for this RFP release.

A: WaConn changes are out of scope of the RFP. WaConn development is done in-house because of its dependency on our ACES system and its release process.

5

Question #13: How many types of admin (super admin, sub admin) users will be there in the back-end?

A: DSHS has no predefined expectations for how many types of administrative users there will be in the back-end and is open to design alternatives. Ideally, as many configuration options or communication management functions would be available to business users / product owners as possible, as opposed to requiring skilled IT resources.

Question #14: What would be a maximum time line to complete the mobile apps?

A: DSHS desires production implementation of the mobile application as close to October 2018 as is feasible. Multiple issues need to be considered including, but not limited to, grant parameters, project vs. maintenance and operations time under the grant, minimum viable product, release and iteration plans to be developed in consultation between DSHS and the vendor, application readiness, and potentially State-side functionality delivered through our quarterly ACES release process that encompasses Washington Connection (WaConn) development.

Question #15: Resources will work Onsite or Offsite?

A: Resources will need to work onsite with DSHS’ project team.

Question #16: Do we need to give resource, time estimation and cost for mobile apps Future Functionalities also? (16. Project Scope – Future Vision / Desired Functionality, listing in attachment A).

A: Estimates, etc. do not need to be given for functionality in para. 16, Project Scope – Future Vision / Desired Functionality. These are listed solely to give bidders and the eventual vendor an idea of our future vision that might impact their earlier design choices.

Question #17: Can you elaborate on the following two requirements? They seem to suggest that the app needs to surface data directly from WaConn.

“2) The Mobile Application shall provide a seamless integration to Washington Connection that allows clients to see their case information, and supports the following: view their benefits statuses and amounts, and determine if it is time to reapply for their benefits.

6

(3) The Mobile Application shall support communication from WaConn and Barcode to clients’ mobile devices for important case related notifications such as reminders, information, requests, and due dates, via notifications such as email, SMS text, and push notification.”

A: For (2), clients must access their Client Benefit Account (CBA) through the Washington Connection (WaConn) website for functions like those listed because the State’s security infrastructure, Secure Access Washington (SAW), does not support mobile applications. ESA plans to convert parts of WaConn to be adaptive-responsive for this purpose but this likely won’t happen until October 2018.

For (3), DSHS does not currently utilize email, SMS text, or push notifications to communicate with clients even though some email addresses and cell phone numbers have been collected and we plan an ACES system change to better identify cell phone numbers for future use. We remain open to design alternates to utilize this contact information but the information itself will be collected mostly through WaConn and ACES and stored in those and other State systems. Additionally, the State remains open to design alternatives allowing push notifications through the native portion of the mobile application that may be of a generalized nature, e.g. public service announcements.

Question #18: Would you accept a web based, cross-platform solution that met the requirements of the RFP instead of a true mobile application? A: No, a web-based solution will not be considered. The agency’s strategic direction is to offer services through mobile applications. Additionally, a federal grant was secured with that premise.

Question #19: Please share your technology and software development standards that are available, including, Agile application life cycle management tools (e.g., JIRA or Axosoft), Continuous Integration and Continuous Deployment (e.g., Jenkins), source code repository (e.g., Github, SVN), defect tracking, Integration and API management service (e.g., MuleSoft, Apegee), Performance Testing, Push Notification Server / service, UI design standards (e.g., existing color palette, branding, design patterns). A: DSHS/ESA has little Agile development experience. It does not have published development standards for Agile or mobile applications that would apply to the vendor’s work in response to this RFP. Nor does it have them for Washington Connection (WaConn) or Barcode where the work will be done by ESA resources. We have none of the Agile-focused lifecycle tools mentioned. We have no Push Notification Server / Service as we currently do not communicate with clients via email or SMS text, or through push notifications via mobile applications, for Client Benefit Account (CBA) issues. Our electronic communication with clients is limited to user account registration. We have no UI design standards for mobile applications. DSHS has Administrative Policy No. 15.18.1, “Content and

7

Visual Design Standards for Internet Websites and Public-Facing Web Applications”. We are currently working with DSHS Communications on some of these design issues including a logo and branding and may attempt to give the mobile application an appearance similar to WaConn.

Question #20: What tools does DSHS have that it uses for virus scanning for documents uploaded into Barcode? Will DSHS be able to leverage those tools for this mobile application? A: There is no virus scanning for Barcode documents that are received today via fax. DSHS desktops and servers utilize McAfee for virus scanning which will be available for Microsoft Windows based assets. There is no client side malware protection available.

Question #21: How or with what service are automated emails sent by DSHS today? A: DSHS/ESA currently does not communicate with clients via email. Some systems communicate with clients using WaTech (different State agency) provided email services.

Question #22: How or with what service are automated SMS messages sent by DSHS today?

A: DSHS/ESA currently does not communicate with clients via SMS messages.

Question #23: RFP Section D, Instructions Regarding Content, Format and Submission of Written Responses, page 26 states that responses should be in 12-point font. However, bullet 3 Attachment D states that bidder’s must respond using Attachment D, which is in 11 point font. We assume that using the preset 11 point font is acceptable. Is this a correct assumption? A: Using the preset 11-point font in Attachment D is acceptable.

Question #24: With the 50 page limit to Attachment D, we assume the following items are to be provided as attachments not included in the page count: Attachment D 2.d, Resumes; Attachment D 3.g, Technical Documentation samples; Attachment D 3.h, Training Material samples; Attachment D.3.o, Proposed .mpp.

A: The following are allowable as exceptions, not to be counted toward the 50-page limit for the bidders’ responses: resumes, samples of technical documents and training materials, and project plans. DSHS is not

8

interested in receiving generic marketing or other materials not germane to responding to a specific item in the Attachment D, questionnaire.

Question #25: Please provide additional information/documentation regarding connection to SAW. A: Secure Access Washington (SAW) is controlled by Washington Technology (WaTech) and we are unable to share its documentation but it shouldn’t be necessary to do so. SAW is currently not usable for authentication through / by native mobile applications, nor is there a foreseeable roadmap for it to be so. Access to Washington Connection (WaConn) utilizing SAW is already available and there are plans to improve the user experience by making WaConn adaptive – responsive, however this won’t occur until at least October 2018. Users accessing WaConn through the mobile application will utilize SAW via WaConn.

Question #26: In section 3.d.6 on page 14 of the RFP document, the current link to DSHS administrative policy provided does not work. Please provide a copy of DSHS policy 15.18.1 or the correct link. A: It will be shared with the Apparent Successful Bidder (ASB) prior to contract execution.

Question #27: Please confirm that DSHS plans to provide all the software, hardware, and hosting of all environments that are needed to develop, test, implement, and deploy the mobile application. A: DSHS/ESA is not knowledgeable of all the software, hardware, or environments that may be considered necessary for mobile application development, etc. or how they may need to be architected with respect to the State Government Network (SGN) and the Internet. We would attempt to provide all that is required but cannot commit to unknowns at this time. We lack a robust test environment that mimics our production environment inclusive of all applications and interfaces. Lacking mobile application experience, we are not setup with an infrastructure for that purpose and will have to work with the eventual vendor to determine the specific needs and how best to fulfill them.

Question #28: Please confirm that DSHS plans to provide at a minimum the following environments: Development, integration test environment, UAT environment, Staging Environment, and Production Environment. If not, please list the environment that will be provided by DSHS. A: DSHS/ESA has development, test, training, and production environments but lacks knowledge of whether they will be adequate for mobile application development, etc. Lacking mobile application experience, we

9

are not setup with an infrastructure for that purpose and will have to work with the eventual vendor to determine the specific needs and how best to fulfill them.

Question #29: Please provide a copy of DSHS Information Security Manual as listed in section 3.f.3 on page 15 of the RFP document. A: It will be shared with the Apparent Successful Bidder (ASB) prior to contract execution.

Question #30: We could not find guidelines for implementing Captcha within the OCIO policy 188 on Accessibility as described in section 3.f.8 on page 15 of the RFP document. Please share the reference to this guideline. A: The requirements for CAPTCHA implementation and to follow OCIO Policy 188, Accessibility, are separate requirements that happen to be adjacent to each other in the RFP. DSHS has no known guidelines for CAPTCHA implementation.

Question #31: Please provide architecture/documentation, of the systems we are expected to integrate to e.g., Barcode, SAW that is described in section 3.h on page 15 of the RFP document. A: DSHS/ESA does not share system architecture documentation with outside entities. What documentation exists and is necessary will be shared with the eventual vendor. Mobile Application integration with SAW will not be required for this initial project or for the foreseeable future. Whether it becomes so in the future is to-be-determined.

Question #32: From section 3.i on page 16 of the RFP document, how many DSHS team members (developers, QA, DevOps) are expected to be part of the mobile app scrum team composition working side by side with the vendor team? A: The specific number of DSHS team members to the mobile application Agile team is yet unknown but will likely include a Project Manager, Product Owner, Business Analyst and/or Program Manager, 1-2 Developer(s), and others, as needed.

Question #33: From section 3.j.4 on page 16 of the RFP document, several State of Washington apps exist. Is the intent to re-use existing store developer accounts or to establish a new one? A: While several State of Washington mobile applications exist, none are owned or controlled by DSHS/ESA/CSD who is the predominant customer

10

for this application. Additionally, none have the same security implications or limitations as the one proposed. Therefore no re-use is expected.

Question #34: From section 3.p.3 on page 18 of the RFP document, does the State have an Identified Product Owner? Have they attended Agile training including Product Owner training?

A: DSHS does have an identified Product Owner (PO). This will be their first time in this role. They have not yet attended any Agile training, either generalized or specific to the PO role. Providing this training and coaching is part of this RFP.

Question #35: From section 3.p.3 on page 18 of the RFP document, will the designated product owner have the authority to make design decisions during sprints and throughout the implementation? A: DSHS is aware of the need for the Product Owner (PO) to be accessible to the team and to have authority to make design and other decisions in real or quick time. This will be the first time the PO is in that role and the first time the customer business unit will participate at this level in an Agile team. Communicating roles and responsibilities has begun but will require continuous monitoring and coaching to ensure implementation supports the needs of the team.

Question #36: B.3.b.(1) (pg 12) states: The specific design is to be determined.

a. Do you expect the Contractor to provide User Interface design services as part of this RFP? b. Are there any current plans for usability testing of the interface?

A: a. Yes, User Interface design services are expected as part of this RFP. b. Usability testing is expected but there are no specific or detailed plans. DSHS expects the vendor to build in at least one round of usability testing per paras. B.3.d.(7) and B.3.j.(1). Parameters of usability testing are to be determined in consultation between DSHS/ESA and the vendor.

Question #37: B.3.b.(1).(c) (pg 12) states: Any conversion or cleanup of images must happen before this confirmation.

o Does the app need to support “image cleanup”? If so, what kind of tools are envisioned?

A: Yes, this application needs to support image cleanup. Documents that are scanned by the mobile application should automatically be “deskewed” and “despeckled” without user intervention. Once “deskewed” and “despeckled”, the image should be presented to the user as a 200 DPI Black and White PDF. The user should be given the option to view each

11

page of a multi-page image, and also rotate and save individual pages for proper orientation. Other image manipulation options are not necessary. Once the image is accepted by the user, it shall be submitted to the destination system.

Question #38: B.3.b.(3) (pg 12) states: The Mobile Application shall support communication from WaConn and Barcode to clients’ mobile devices. We understand that the Contractor will work with you to define the APIs.

o Do you have a proposed list of API calls (use cases) that we will need to support?

A: DSHS does not have a list of proposed API calls to support any part of the mobile application requirements.

Question #39: B.3.b.(4) (pg 12) states: The Mobile Application shall integrate with Google Maps.

o Is there a requirement to integrate with Apple Maps on iOS? A: No, there is not a requirement to integrate with Apple Maps on iOS. We intend to use Google Maps on both mobile operating system platforms.

Question #40: B.3.i.(3) (pg 16) states: The Contractor shall train and coach select State staff throughout Mobile Application planning, development, and support.

a. How many staff do you project? What are their current roles? b. What processes and tools does Washington State DSHS currently use?

A: a. The specific number of staff to be trained is yet to be determined but could range between 8 and 50. Assigned project roles at this time include Project Manager, Product Owner, Program Manager, Business Analyst, Developer, and Quality Assurance Analyst. How many of each, and whether other organizational roles, such as Tester, are to be trained has not been determined and will depend upon their contribution to or participation in the project as well as what opportunities are presented to train others in the peripheral organization(s) for future Agile projects or maintenance and operation of this CSD Mobile Application product. Coaching would be required for the immediate Agile project team – those participating in stand-up meetings or other vital support roles. b. DSHS/ESA has not established any processes or tools for mobile application or Agile development projects.

12

Question #41: Does the app need to support any local business logic (e.g., can’t upload a previously submitted form, can’t submit if a certain deadline has passed) or will all rules be implemented on the server and communicated to the app? A: We do not expect to place limits on what clients upload other than reasonable limitations on the size, file format, and volume of uploads to protect system stability. Other business logic for the mobile application has not been developed. Their consideration, development, and mechanisms for implementation and communication will likely be done in consultation between DSHS and the vendor.

Question #42: WaConn offers a number of functions via the web. Will the app need to support something similar? For example:

o See If I Qualify o Create Washington Connection Account o Create Client Benefit Account o Find help in my community o Find emergency services

A: The mobile application will not duplicate any of these or other functions currently offered through Washington Connection (WaConn). There is currently a security / authentication constraint related to Secure Access Washington (SAW) that prevents duplication of sensitive functions in a native mobile application.

Question #43: Does the app need to support any local search functionality? Or integrated search with web-based results? A: No search functionality is anticipated at this time but theoretically could be added to a product backlog at the discretion of the Product Owner.

Question #44: Does the app need to support any offline functionality? If so, please describe. A: Much of the mobile application’s functionality will require being online, e.g. anything delivered through the Washington Connection (WaConn) website. However, DSHS has no predetermined design specifications related to online vs. offline functionality. Some of the required and desired functions could be offered offline by design, e.g. displaying field office locations and office hours, in-app help / training / FAQs, or possibly document photography and storage in a mobile application album folder for later online use. This theoretical offline function for photography and storage could be in conflict with another current requirement to delete images taken with the application immediately after upload, so those requirements would have to be reviewed and de-conflicted, as necessary.

13

Question #45: Are there any internal functions or roles envisioned for the app? If so, please describe. A: DSHS has no preconceived internal functions or roles but it would be favorable if such functions and roles existed, allowing for some configuration or push notifications to be controlled by select business users and taking the burden off of IT resources.

Question #46: What Washington State DSHS and IT personnel will be assigned to this project? What are their skills/roles? What amount of time will they be available to the project? A: DSHS staff assigned to this project at this time include a Project Manager allocated at near 100%, a Product Owner with this project among their primary responsibilities and notification given to them and their organization that their access and authority is vital to project success, a Program Manager representing the predominant customer business unit, a Business Analyst with primary responsibilities for Washington Connection (WaConn) in addition to other IT responsibilities, one or more Barcode developers responsible for architecting and delivering their technical components and coordinating with vendor resources for interoperability of image upload and Barcode technical solutions, a vendor Quality Assurance Analyst who will probably not participate regularly in stand-up meetings but will likely attend occasionally or may interview vendor team members. All of these resources are experienced in their present roles and all or most have at least several years’ State experience. The team has very little Agile experience, however. Additionally there are ACES Developers and possibly Testers who will not participate routinely with the project team. ACES products will be dependencies for some mobile application functionality. The Testers’ role, if any, has not yet been determined.

All other terms and conditions in this Solicitation remain the same.